[Numpy-discussion] Recent umath changes

David Cournapeau david@ar.media.kyoto-u.ac...
Wed Dec 17 21:58:07 CST 2008


Charles R Harris wrote:
>
> The declarations were for the SPARC. Originally I had them up in an
> ifdef up top, but I got curious what different machines would do.

I still don't understand what exact problem they solve. Since the
declarations are put when HAVE_FOO is defined, the only problems I can
see are problem in the detection code or a platform bug (I seem to
remember for SPARC, this was a platform error, right ?). In either case,
it should be solved elsewhere (at worst, for platform specific, this
should be done within #if PLATFORM/#endif).

> They shouldn't cause a problem unless something is pretty strange.

They do; the default rule should be not to put any external declaration,
because they are heavily toolchain/platform specific. I removed a lot of
them from the old code when I refactored this code, and putting them
back almost totally alleviate my effort :) To quote python code itself
(pyport.h):

/**************************************************************************
Prototypes that are missing from the standard include files on some systems
(and possibly only some versions of such systems.)

Please be conservative with adding new ones, document them and enclose them
in platform-specific #ifdefs.
**************************************************************************/

> The undefs I put where they are for similar reasons, but there was a
> strong temptation to move them into the if statement where they used
> to be.

Could you be more specific ? I want to know the actual error they were
solving.

> Let's say curiousity got the best of me there. They shouldn't affect
> anything but macros and I didn't want the function declarations do be
> interpreted as macros.

"Shouldn't affect" is not good enough :) The default rule should be to
avoid relying at all on those distinctions, and only care when they
matter. Doing the other way around does not work, there alway be some
strange platform which will break most assumptions, as rationale as they
can be.

>
> Worth knowing ;)  It works on the windows buildbot but that is running
> python 2.4.

Ah, it is 2.4 ! I was wondering the exact combination. It does not work
with  the platform SDK 6.1 (which includes 64 bits compiler), and this
results in a compiler segfault. The problem is particularly pernicious,
since the segfaults is not seen directly, but put in a temp file which
itself causes problem because two processes try to access it... One of
the nicest build failure I have ever seen :)

> Speaking of which, the BSD buildbot needs nose (I don't know what
> happened to it),  the windows box is showing the same old permissions
> problem, and one of the SPARC buildbots just times out unless you
> build during the right time of day. We are just hobbling along at the
> moment.

Windows problems at least are not specific to the buildbot.

>
> Sorry for the late reply, the network was down.

No problem,

David


More information about the Numpy-discussion mailing list