[Numpy-discussion] Recent umath changes

[Charles R Harris]

Hi David,

On Wed, Dec 17, 2008 at 8:58 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> 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.
> **************************************************************************/
>

That's how I did it originally, that's why that section is up top. But I got
curious. So that can be fixed.


>
> > 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.
>

The undefs need to be there when the functions are defined by numpy, so they
only need to be in the same #if block as those definitions. I moved them out
to cover the function declarations also, but if those are put in their own
block for SPARC then they aren't needed.


>
> > 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 :)
>

The window buildbot was working, went off line for a few weeks, and showed
failures on return. It is a VMWare version, so maybe something was changed
in between.


>
> > 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,
>

And I still have network problems... What will the world do if the networks
collapse?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20081218/b16d7382/attachment.html>