"svn login" means "sourceforge id"
JDH
On Wed, Nov 25, 2009 at 10:57 AM, John Hunter <jdh2358@...149...> wrote:
On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <strawman@...36...> wrote:
Also, would you like svn commit access? That may just make things easier
-- John, what do you think? I think we can trust David.Absolutely -- send me an svn login and I can add him to the list of
committers if he wants to, else we can manage his patches.
Andrew Straw wrote:
I looked a little further, and it depends on the directory that the
tests are run from -- if I manually log into the build slave, I can
get the tests to run (in fact, one segfaults) if I try from a
different working directory. Anyhow, now that I have a handle on it, I
think I can probably get it working... Give me a couple days.
great.
As far as I'm concerned, that would be fine.
Is PyMODINIT_FUNC pulled in from Python.h?
Yes - the init func should always be 'tagged' by this macro. On Unix,
any function is exported in a shared library by default, but the
behavior is the opposite on windows, where a function without it will
not be visible from external code.
David
David Cournapeau wrote:
Andrew Straw wrote:
I looked a little further, and it depends on the directory that the
tests are run from -- if I manually log into the build slave, I can
get the tests to run (in fact, one segfaults) if I try from a
different working directory. Anyhow, now that I have a handle on it, I
think I can probably get it working... Give me a couple days.
great.
Well, now the scons branch tests run properly (until they hit a segfault on matplotlib.tests.test_axes.test_basic_annotate)
However, with svn r7985, the trunk fails to find the tests. This is so weird. There's nothing in that commit that I can see that should cause the failure, but it seems repeatable. r7984 doesn't have it and r7985 does. And it appears to be more or less the issue that the scons branch had. Sigh.
Don't forget to pass on your sourceforge username to John to get svn commit access. I think the scons build option should get merged into the trunk.
-Andrew
Could this failure be related to the bug filed by Christoph Gohlke (see tracker)? The change corresponds to r7985 and affects setupext.py. I’m not sure if the numscons build uses setupext.py, but it may be worth checking out.
-Tony
On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
However, with svn r7985, the trunk fails to find the tests. This is so
weird. There’s nothing in that commit that I can see that should cause
the failure, but it seems repeatable. r7984 doesn’t have it and r7985
does. And it appears to be more or less the issue that the scons branch
had. Sigh.
Tony S Yu wrote:
However, with svn r7985, the trunk fails to find the tests. This is so
weird. There's nothing in that commit that I can see that should cause
the failure, but it seems repeatable. r7984 doesn't have it and r7985
does. And it appears to be more or less the issue that the scons branch
had. Sigh.Could this failure be related to the bug filed by Christoph Gohlke (see tracker <http://sourceforge.net/tracker/?func=detail&aid=2903596&group_id=80706&atid=560720>\)? The change corresponds to r7985 and affects setupext.py. I'm not sure if the numscons build uses setupext.py, but it may be worth checking out.
Thanks Tony (and Christoph) -- this fixed it.
I wonder why I wasn't getting a more severe error on linux? This might offer a clue as to the testing weirdness we've been experiencing lately.
Anyhow, I got the tests passing on the buildbots again so that we should immediately be notified upon new failures. I think we need to work hard to keep the buildbots green so we can catch things like this.
-Andrew
On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
