
Is there a plan to get SciPy 0.7 out the door? Numerous improvements have been made since the release of 0.6, which was 9 months ago. Whatever the faults of the current SVN (e.g. unittest that have been broken for over a month), are they not now preferable to those in 0.6? A release now would be helpful to those who want to use SciPy in the classroom this fall. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

Nathan Bell wrote:
Is there a plan to get SciPy 0.7 out the door? Numerous improvements have been made since the release of 0.6, which was 9 months ago. Whatever the faults of the current SVN (e.g. unittest that have been broken for over a month), are they not now preferable to those in 0.6?
A release now would be helpful to those who want to use SciPy in the classroom this fall.
My understanding is that a new scipy is released shortly after numpy. But no discussion has happened, and the bug list is long (180 bugs). I would say, but that's only my opinion, that unless scipy 0.6 cannot work with current numpy (1.1), it should not happen without more work (at least some bug triaging to see blockers). cheers, David

On Thu, Jun 19, 2008 at 22:15, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nathan Bell wrote:
Is there a plan to get SciPy 0.7 out the door? Numerous improvements have been made since the release of 0.6, which was 9 months ago. Whatever the faults of the current SVN (e.g. unittest that have been broken for over a month), are they not now preferable to those in 0.6?
A release now would be helpful to those who want to use SciPy in the classroom this fall.
My understanding is that a new scipy is released shortly after numpy.
Not without a release manager, it doesn't! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Robert Kern wrote:
Not without a release manager, it doesn't!
It was more or less implied when I mention the 180 bugs list and bug triaging :) So to be clearer: who wants to be a release manager ? It won't brings you millions, but will bring you fame and recognition. cheers, David

On Thu, Jun 19, 2008 at 10:15 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
My understanding is that a new scipy is released shortly after numpy. But no discussion has happened, and the bug list is long (180 bugs). I would say, but that's only my opinion, that unless scipy 0.6 cannot work with current numpy (1.1), it should not happen without more work (at least some bug triaging to see blockers).
Well, 180 tickets sounds like a lot until you consider that most if not all of them probably exist in 0.6 as well. Not to mention the 86 tickets that have been fixed in 0.7 and the fact that perhaps 50 of the remaining tickets are enhancements and tasks. IMO we should address the any blockers now and get 0.7 out ASAP. Nine months is too long to wait for new features/fixes to appear. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

Nathan Bell wrote:
Well, 180 tickets sounds like a lot until you consider that most if not all of them probably exist in 0.6 as well.
That sounds more as an argument against it than for it: having been sloppy before is not a justification to continue on a sloppy road.
IMO we should address the any blockers now and get 0.7 out ASAP.
Yes: that's basically what a release manager is supposed to do :) Someone else has to step in (I can't do it ATM). cheers David

On Fri, 20 Jun 2008 13:09:12 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nathan Bell wrote:
Well, 180 tickets sounds like a lot until you consider that most if not all of them probably exist in 0.6 as well.
That sounds more as an argument against it than for it: having been sloppy before is not a justification to continue on a sloppy road.
IMO we should address the any blockers now and get 0.7 out ASAP.
Yes: that's basically what a release manager is supposed to do :) Someone else has to step in (I can't do it ATM).
cheers
David
There are lots of duplicate tickets, e.g. http://projects.scipy.org/scipy/scipy/ticket/672 IIRC, some tickets can be closed already since they have been fixed in svn. Unfortunately, I can't close tickets so far. Nils

Nils Wagner wrote:
There are lots of duplicate tickets, e.g. http://projects.scipy.org/scipy/scipy/ticket/672
IIRC, some tickets can be closed already since they have been fixed in svn.
Unfortunately, I can't close tickets so far.
If you give the ticket numbers, most of the job would be done, and someone (me) could triage and close them accordingly. thanks, David

On Sat, 21 Jun 2008 16:13:29 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
There are lots of duplicate tickets, e.g. http://projects.scipy.org/scipy/scipy/ticket/672
IIRC, some tickets can be closed already since they have been fixed in svn.
Unfortunately, I can't close tickets so far.
If you give the ticket numbers, most of the job would be done, and someone (me) could triage and close them accordingly.
thanks,
David
David, Okay, here are some pending tickets. http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn. The patch attached to http://projects.scipy.org/scipy/scipy/ticket/593 works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice. Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642 #647 and #648 can be combined. #662, #663, #664, #665 are duplicates #672, #673, #674 are duplicates Cheers, Nils P.S. There are still some annoying test errors/failures in current svn http://projects.scipy.org/scipy/scipy/ticket/611 http://projects.scipy.org/scipy/scipy/ticket/584 http://projects.scipy.org/scipy/scipy/ticket/586 http://projects.scipy.org/scipy/scipy/ticket/587

Nils Wagner wrote:
David,
Okay, here are some pending tickets.
http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn.
The patch attached to
http://projects.scipy.org/scipy/scipy/ticket/593
works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice.
Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642
#647 and #648 can be combined.
#662, #663, #664, #665 are duplicates
#672, #673, #674 are duplicates
Thanks, I closed the dup, and also added a report on scipy trac to track open tickets with attachments (I have not taken a look at 593).
P.S. There are still some annoying test errors/failures in current svn
Yes. I may take a look at some of those later today, cheers, David

On Sat, 21 Jun 2008 17:58:57 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Okay, here are some pending tickets.
http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn.
The patch attached to
http://projects.scipy.org/scipy/scipy/ticket/593
works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice.
Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642
#647 and #648 can be combined.
#662, #663, #664, #665 are duplicates
#672, #673, #674 are duplicates
Thanks, I closed the dup, and also added a report on scipy trac to track open tickets with attachments (I have not taken a look at 593).
P.S. There are still some annoying test errors/failures in current svn
Yes. I may take a look at some of those later today,
cheers,
David
Hi David, Please can you also check the status of ticket http://scipy.org/scipy/scipy/ticket/413 I cannot reproduce the defect. The same holds for http://scipy.org/scipy/scipy/ticket/561 http://scipy.org/scipy/scipy/ticket/567 Nils

On Sat, 21 Jun 2008 17:58:57 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Okay, here are some pending tickets.
http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn.
The patch attached to
http://projects.scipy.org/scipy/scipy/ticket/593
works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice.
Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642
#647 and #648 can be combined.
#662, #663, #664, #665 are duplicates
#672, #673, #674 are duplicates
Thanks, I closed the dup, and also added a report on scipy trac to track open tickets with attachments (I have not taken a look at 593).
P.S. There are still some annoying test errors/failures in current svn
Yes. I may take a look at some of those later today,
cheers,
David
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
David, Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499 IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project. Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed. Nils

On Sat, 21 Jun 2008 12:30:13 +0200 "Nils Wagner" <nwagner@iam.uni-stuttgart.de> wrote:
On Sat, 21 Jun 2008 17:58:57 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Okay, here are some pending tickets.
http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn.
The patch attached to
http://projects.scipy.org/scipy/scipy/ticket/593
works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice.
Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642
#647 and #648 can be combined.
#662, #663, #664, #665 are duplicates
#672, #673, #674 are duplicates
Thanks, I closed the dup, and also added a report on scipy trac to track open tickets with attachments (I have not taken a look at 593).
P.S. There are still some annoying test errors/failures in current svn
Yes. I may take a look at some of those later today,
cheers,
David
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
David,
Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499
IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project.
Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed.
Nils _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
IMHO, ticket 670 is invalid. http://scipy.org/scipy/scipy/ticket/670 And there are many enhancements (see the list below) Other http://scipy.org/scipy/scipy/ticket/674 http://scipy.org/scipy/scipy/ticket/669 http://scipy.org/scipy/scipy/ticket/651 http://scipy.org/scipy/scipy/ticket/635 http://scipy.org/scipy/scipy/ticket/634 http://scipy.org/scipy/scipy/ticket/628 http://scipy.org/scipy/scipy/ticket/608 http://scipy.org/scipy/scipy/ticket/562 http://scipy.org/scipy/scipy/ticket/448 http://scipy.org/scipy/scipy/ticket/330 scipy.cluster http://scipy.org/scipy/scipy/ticket/612 http://scipy.org/scipy/scipy/ticket/426 scipy.fftpack http://scipy.org/scipy/scipy/ticket/474 http://scipy.org/scipy/scipy/ticket/268 scipy.integrate http://scipy.org/scipy/scipy/ticket/615 http://scipy.org/scipy/scipy/ticket/597 http://scipy.org/scipy/scipy/ticket/478 http://scipy.org/scipy/scipy/ticket/291 scipy.interpolate http://scipy.org/scipy/scipy/ticket/206 http://scipy.org/scipy/scipy/ticket/286 http://scipy.org/scipy/scipy/ticket/305 http://scipy.org/scipy/scipy/ticket/687 scipy.io http://scipy.org/scipy/scipy/ticket/354 scipy.linalg http://scipy.org/scipy/scipy/ticket/354 http://scipy.org/scipy/scipy/ticket/456 http://scipy.org/scipy/scipy/ticket/632 scipy.misc http://scipy.org/scipy/scipy/ticket/564 http://scipy.org/scipy/scipy/ticket/675 scipy.optimize http://scipy.org/scipy/scipy/ticket/285 scipy.signal http://scipy.org/scipy/scipy/ticket/386 http://scipy.org/scipy/scipy/ticket/457 http://scipy.org/scipy/scipy/ticket/475 http://scipy.org/scipy/scipy/ticket/648 http://scipy.org/scipy/scipy/ticket/650 scipy.sparse http://scipy.org/scipy/scipy/ticket/226 http://scipy.org/scipy/scipy/ticket/639 http://scipy.org/scipy/scipy/ticket/658 http://scipy.org/scipy/scipy/ticket/668 scipy.sparse.linalg http://scipy.org/scipy/scipy/ticket/18 http://scipy.org/scipy/scipy/ticket/231 http://scipy.org/scipy/scipy/ticket/261 http://scipy.org/scipy/scipy/ticket/358 http://scipy.org/scipy/scipy/ticket/418 http://scipy.org/scipy/scipy/ticket/452 scipy.special http://scipy.org/scipy/scipy/ticket/582 http://scipy.org/scipy/scipy/ticket/610 Nils

Hi, could you please also consider ticket #659? The attached patch solves the problem. You may also use the attached test script hyp1f1_test.py to verify the patch. Thank you! Best, Moritz On Jun 21, 2008, at 1:46 PM, Nils Wagner wrote:
On Sat, 21 Jun 2008 12:30:13 +0200 "Nils Wagner" <nwagner@iam.uni-stuttgart.de> wrote:
On Sat, 21 Jun 2008 17:58:57 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Okay, here are some pending tickets.
http://projects.scipy.org/scipy/scipy/ticket/591 can be closed. It is fixed in svn.
The patch attached to
http://projects.scipy.org/scipy/scipy/ticket/593
works for me. IMHO the ticket #593 can be closed, when the patch is applied in the trunk. However a test would be nice.
Duplicate of ticket #641 http://projects.scipy.org/scipy/scipy/ticket/642
#647 and #648 can be combined.
#662, #663, #664, #665 are duplicates
#672, #673, #674 are duplicates
Thanks, I closed the dup, and also added a report on scipy trac to track open tickets with attachments (I have not taken a look at 593).
P.S. There are still some annoying test errors/failures in current svn
Yes. I may take a look at some of those later today,
cheers,
David
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
David,
Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499
IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project.
Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed.
Nils _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
IMHO, ticket 670 is invalid. http://scipy.org/scipy/scipy/ticket/670
And there are many enhancements (see the list below)
Other http://scipy.org/scipy/scipy/ticket/674 http://scipy.org/scipy/scipy/ticket/669 http://scipy.org/scipy/scipy/ticket/651 http://scipy.org/scipy/scipy/ticket/635 http://scipy.org/scipy/scipy/ticket/634 http://scipy.org/scipy/scipy/ticket/628 http://scipy.org/scipy/scipy/ticket/608 http://scipy.org/scipy/scipy/ticket/562 http://scipy.org/scipy/scipy/ticket/448 http://scipy.org/scipy/scipy/ticket/330
scipy.cluster http://scipy.org/scipy/scipy/ticket/612 http://scipy.org/scipy/scipy/ticket/426
scipy.fftpack http://scipy.org/scipy/scipy/ticket/474 http://scipy.org/scipy/scipy/ticket/268
scipy.integrate http://scipy.org/scipy/scipy/ticket/615 http://scipy.org/scipy/scipy/ticket/597 http://scipy.org/scipy/scipy/ticket/478 http://scipy.org/scipy/scipy/ticket/291
scipy.interpolate http://scipy.org/scipy/scipy/ticket/206 http://scipy.org/scipy/scipy/ticket/286 http://scipy.org/scipy/scipy/ticket/305 http://scipy.org/scipy/scipy/ticket/687
scipy.io http://scipy.org/scipy/scipy/ticket/354
scipy.linalg http://scipy.org/scipy/scipy/ticket/354 http://scipy.org/scipy/scipy/ticket/456 http://scipy.org/scipy/scipy/ticket/632
scipy.misc http://scipy.org/scipy/scipy/ticket/564 http://scipy.org/scipy/scipy/ticket/675
scipy.optimize http://scipy.org/scipy/scipy/ticket/285
scipy.signal http://scipy.org/scipy/scipy/ticket/386 http://scipy.org/scipy/scipy/ticket/457 http://scipy.org/scipy/scipy/ticket/475 http://scipy.org/scipy/scipy/ticket/648 http://scipy.org/scipy/scipy/ticket/650
scipy.sparse http://scipy.org/scipy/scipy/ticket/226 http://scipy.org/scipy/scipy/ticket/639 http://scipy.org/scipy/scipy/ticket/658 http://scipy.org/scipy/scipy/ticket/668
scipy.sparse.linalg http://scipy.org/scipy/scipy/ticket/18 http://scipy.org/scipy/scipy/ticket/231 http://scipy.org/scipy/scipy/ticket/261 http://scipy.org/scipy/scipy/ticket/358 http://scipy.org/scipy/scipy/ticket/418 http://scipy.org/scipy/scipy/ticket/452
scipy.special http://scipy.org/scipy/scipy/ticket/582 http://scipy.org/scipy/scipy/ticket/610
Nils
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev

On Mon, Jun 23, 2008 at 3:19 AM, Moritz Helias <helias@bccn.uni-freiburg.de> wrote:
Hi,
could you please also consider ticket #659? The attached patch solves the problem. You may also use the attached test script hyp1f1_test.py to verify the patch. Thank you!
Added in r4468 -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

Sat, 21 Jun 2008 13:46:34 +0200, Nils Wagner wrote: [clip]
scipy.integrate http://scipy.org/scipy/scipy/ticket/597
This is a documentation fix. I committed now the patch I had submitted. The ticket can be closed.
scipy.interpolate http://scipy.org/scipy/scipy/ticket/206
This adds a wrapper for dblint from Dierckx's fitpack. I committed the patch I had submitted (including testcases). I think this ticket can be closed. -- Pauli Virtanen

On Mon, Jun 23, 2008 at 4:26 PM, Pauli Virtanen <pav@iki.fi> wrote:
scipy.integrate http://scipy.org/scipy/scipy/ticket/597
This is a documentation fix. I committed now the patch I had submitted. The ticket can be closed.
scipy.interpolate http://scipy.org/scipy/scipy/ticket/206
This adds a wrapper for dblint from Dierckx's fitpack. I committed the patch I had submitted (including testcases). I think this ticket can be closed.
Done -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

Nathan Bell wrote:
Done
Hi Nathan, Would you mind taking a look at all bugs for 0.7 milestone related to scipy.sparse; in particular, if you can't work quickly on enhancements, I think pushing them for 0.8 should be fine. Since scipy has not seen a release for a long time, I think we should focus primary on bug fixes, specially for scipy.sparse which has seen so much development since 0.6 thanks to you and others, cheers, David

On Mon, Jun 23, 2008 at 9:56 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would you mind taking a look at all bugs for 0.7 milestone related to scipy.sparse; in particular, if you can't work quickly on enhancements, I think pushing them for 0.8 should be fine. Since scipy has not seen a release for a long time, I think we should focus primary on bug fixes, specially for scipy.sparse which has seen so much development since 0.6 thanks to you and others,
I've pushed the enhancements forward to the 0.8 milestone. I don't know if/when I'll have time to resolve the remaining tickets in sparse.linalg, but I would feel comfortable releasing it in its current state. Before attacking ticket #553 we should probably update our SuperLU code in sparse.linalg.dsolve. The version we have [2] is older than but the most recent SuperLU 3.0 release [3]. [1] http://scipy.org/scipy/scipy/ticket/553 [2] http://scipy.org/scipy/scipy/browser/trunk/scipy/sparse/linalg/dsolve/SuperL... [3] http://crd.lbl.gov/~xiaoye/SuperLU/ -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

On Mon, Jun 23, 2008 at 23:06, Nathan Bell <wnbell@gmail.com> wrote:
On Mon, Jun 23, 2008 at 9:56 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would you mind taking a look at all bugs for 0.7 milestone related to scipy.sparse; in particular, if you can't work quickly on enhancements, I think pushing them for 0.8 should be fine. Since scipy has not seen a release for a long time, I think we should focus primary on bug fixes, specially for scipy.sparse which has seen so much development since 0.6 thanks to you and others,
I've pushed the enhancements forward to the 0.8 milestone.
I've added an "Unscheduled" milestone. Enhancement tickets that have no one working on them should probably have this milestone instead of bumping up to the next versioned milestone every time we roll around to a new release. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

While we're at it, ticket #681 is pretty trivial, and there's a fix in the ticket (by me). http://www.scipy.org/scipy/scipy/ticket/681 Oh, and hi everyone, that's my first participation in SciPy dev, and hopefully not the last. It's a great piece of software to use. -- http://yosefm.imagekind.com/Eclectic

On Tue, Jun 24, 2008 at 11:27, Yosef Meller <mellerf@netvision.net.il> wrote:
While we're at it, ticket #681 is pretty trivial, and there's a fix in the ticket (by me).
Thank you. Fixed in r4478.
Oh, and hi everyone, that's my first participation in SciPy dev, and hopefully not the last. It's a great piece of software to use.
Welcome! Glad to have you here. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Nils Wagner wrote:
David,
Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499
IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project.
Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed.
Ok, thanks for all this, Nils, this is really helpful. I have also pushed some non trivial enhancement to 0.8, we are down to 144. Unfortunately, scipy trac is not really responsive ATM, and trac is not convenient to triage bugs (there is no way to filter/set up bugs wo writing some SQL, what a pain). Time to go to bed for me, but if other people could spend some more time to triage 0.7 bugs, this would be helpful. cheers, David

On Tue, 24 Jun 2008 00:08:26 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499
IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project.
Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed.
Ok, thanks for all this, Nils, this is really helpful. I have also pushed some non trivial enhancement to 0.8, we are down to 144. Unfortunately, scipy trac is not really responsive ATM, and trac is not convenient to triage bugs (there is no way to filter/set up bugs wo writing some SQL, what a pain).
Time to go to bed for me, but if other people could spend some more time to triage 0.7 bugs, this would be helpful.
cheers,
David
Hi David, Just now I installed scipy '0.7.0.dev4465' There is a new error ====================================================================== ERROR: test_mio.test_gzip_simple ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/tests/test_mio.py", line 263, in test_gzip_simple actual = loadmat(mat_stream) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio.py", line 96, in loadmat matfile_dict = MR.get_variables() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", line 270, in get_variables getter = self.matrix_getter_factory() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", line 199, in matrix_getter_factory return self._array_reader.matrix_getter_factory() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", line 66, in matrix_getter_factory header['name'] = self.read_ztstring(data['namlen']) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", line 81, in read_ztstring return self.mat_stream.read(num_bytes).strip('\x00') File "/usr/lib/python2.4/gzip.py", line 230, in read chunk = self.extrabuf[:size] TypeError: slice indices must be integers beside the well known eror(s) ====================================================================== ERROR: test_huber (test_scale.TestScale) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", line 35, in test_huber m = scale.huber(X) File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 82, in __call__ for donothing in self: File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 102, in next scale = N.sum(subset * (a - mu)**2, axis=self.axis) / (self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) * Huber.c**2) File "/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", line 1007, in sum return sum(axis, dtype, out) TypeError: only length-1 arrays can be converted to Python scalars Two failures are still present ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/testing/decorators.py", line 81, in skipper return f(*args, **kwargs) File "/usr/lib/python2.4/site-packages/scipy/misc/tests/test_pilutil.py", line 25, in test_imresize assert_equal(im1.shape,(11,22)) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 137, in assert_equal assert_equal(len(actual),len(desired),err_msg,verbose) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 145, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 ====================================================================== FAIL: test_namespace (test_formula.TestFormula) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_formula.py", line 119, in test_namespace self.assertEqual(xx.namespace, Y.namespace) AssertionError: {} != {'Y': array([ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98]), 'X': array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49])} ---------------------------------------------------------------------- I am looking forward to a new scipy release. http://projects.scipy.org/scipy/scipy/query?status=new&status=assigned&status=reopened&milestone=0.7 Nils

On Tue, 24 Jun 2008 00:08:26 +0900 David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Nils Wagner wrote:
David,
Tickets #499 and #525 seem to be correlated as well. See http://scipy.org/scipy/scipy/ticket/525 http://scipy.org/scipy/scipy/ticket/499
IMHO http://scipy.org/scipy/scipy/ticket/308 can be closed. numexpr is now a stand-alone project.
Ticket 591 http://scipy.org/scipy/scipy/ticket/591 can be closed.
Ok, thanks for all this, Nils, this is really helpful. I have also pushed some non trivial enhancement to 0.8, we are down to 144. Unfortunately, scipy trac is not really responsive ATM, and trac is not convenient to triage bugs (there is no way to filter/set up bugs wo writing some SQL, what a pain).
Time to go to bed for me, but if other people could spend some more time to triage 0.7 bugs, this would be helpful.
cheers,
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
David, I looked through the remaining tickets http://scipy.org/scipy/scipy/ticket/308 can be closed. Invalid. http://scipy.org/scipy/scipy/ticket/414 can be closed. Invalid. http://scipy.org/scipy/scipy/ticket/653 belongs to scipy.io http://scipy.org/scipy/scipy/ticket/641 belongs to scipy.optimize http://scipy.org/scipy/scipy/ticket/628 belongs to scipy.signal http://scipy.org/scipy/scipy/ticket/651 belongs to scipy.signal http://scipy.org/scipy/scipy/ticket/577 belongs to scipy.signal http://scipy.org/scipy/scipy/ticket/497 belongs to scipy.stats Cheers, Nils

On Mon, Jun 23, 2008 at 12:57 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
I looked through the remaining tickets
http://scipy.org/scipy/scipy/ticket/308 can be closed. Invalid. http://scipy.org/scipy/scipy/ticket/414 can be closed. Invalid.
http://scipy.org/scipy/scipy/ticket/653 belongs to scipy.io
http://scipy.org/scipy/scipy/ticket/641 belongs to scipy.optimize
http://scipy.org/scipy/scipy/ticket/628 belongs to scipy.signal http://scipy.org/scipy/scipy/ticket/651 belongs to scipy.signal http://scipy.org/scipy/scipy/ticket/577 belongs to scipy.signal
http://scipy.org/scipy/scipy/ticket/497 belongs to scipy.stats
Thanks for figuring these out Nils. I've updated the tickets. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

Hi, Can I get someone to look at this #581 for 0.7 as well? I've put up a patch that fixes it for me. http://scipy.org/scipy/scipy/ticket/581 Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma

On Sat, Jun 21, 2008 at 3:16 AM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
P.S. There are still some annoying test errors/failures in current svn
Should be fixed in r4455
I have no idea how to solve this one
It appears that the _bspline extension module is being built (or rather not being built) with weave in a fairly convoluted manner.
I suspect the self.axis = ..... on line 100 is the source of the error. It sets axis to an array of floats, which is certainly wrong. I tried replacing self.axis with 'mu' but that failed too. I have no idea what the code is doing. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

On Sat, 21 Jun 2008 04:39:26 -0500 "Nathan Bell" <wnbell@gmail.com> wrote:
On Sat, Jun 21, 2008 at 3:16 AM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
P.S. There are still some annoying test errors/failures in current svn
Should be fixed in r4455
I have no idea how to solve this one
It appears that the _bspline extension module is being built (or rather not being built) with weave in a fairly convoluted manner.
I suspect the self.axis = ..... on line 100 is the source of the error. It sets axis to an array of floats, which is certainly wrong.
I tried replacing self.axis with 'mu' but that failed too. I have no idea what the code is doing.
-- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/
Hi Nathan, Here comes the output of scipy.test() '0.7.0.dev4455' ====================================================================== ERROR: test_mio.test_gzip_simple ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/tests/test_mio.py", line 263, in test_gzip_simple actual = loadmat(mat_stream) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio.py", line 96, in loadmat matfile_dict = MR.get_variables() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", line 270, in get_variables getter = self.matrix_getter_factory() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", line 199, in matrix_getter_factory return self._array_reader.matrix_getter_factory() File "/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", line 66, in matrix_getter_factory header['name'] = self.read_ztstring(data['namlen']) File "/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", line 81, in read_ztstring return self.mat_stream.read(num_bytes).strip('\x00') File "/usr/lib/python2.4/gzip.py", line 230, in read chunk = self.extrabuf[:size] TypeError: slice indices must be integers ====================================================================== ERROR: Failure: ImportError (cannot import name _bspline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/loader.py", line 363, in loadTestsFromName module = self.importer.importFromPath( File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_bspline.py", line 9, in ? import scipy.stats.models.bspline as B File "/usr/lib/python2.4/site-packages/scipy/stats/models/bspline.py", line 23, in ? from scipy.stats.models import _bspline ImportError: cannot import name _bspline ====================================================================== ERROR: test_huber (test_scale.TestScale) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", line 35, in test_huber m = scale.huber(X) File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 82, in __call__ for donothing in self: File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 102, in next scale = N.sum(subset * (a - mu)**2, axis=self.axis) / (self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) * Huber.c**2) File "/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", line 994, in sum return sum(axis, dtype, out) TypeError: only length-1 arrays can be converted to Python scalars ====================================================================== ERROR: test_huberaxes (test_scale.TestScale) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", line 40, in test_huberaxes m = scale.huber(X, axis=0) File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 82, in __call__ for donothing in self: File "/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", line 102, in next scale = N.sum(subset * (a - mu)**2, axis=self.axis) / (self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) * Huber.c**2) File "/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", line 994, in sum return sum(axis, dtype, out) TypeError: only length-1 arrays can be converted to Python scalars ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/testing/decorators.py", line 81, in skipper return f(*args, **kwargs) File "/usr/lib/python2.4/site-packages/scipy/misc/tests/test_pilutil.py", line 25, in test_imresize assert_equal(im1.shape,(11,22)) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 137, in assert_equal assert_equal(len(actual),len(desired),err_msg,verbose) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 145, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 ====================================================================== FAIL: test_autoalign_nmi_value_2 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/ndimage/tests/test_registration.py", line 176, in test_autoalign_nmi_value_2 assert_almost_equal(cost, -1.7973048186515352, decimal=6) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 158, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: ACTUAL: -1.797321600138216 DESIRED: -1.7973048186515352 ====================================================================== FAIL: test_namespace (test_formula.TestFormula) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_formula.py", line 119, in test_namespace self.assertEqual(xx.namespace, Y.namespace) AssertionError: {} != {'Y': array([ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98]), 'X': array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49])} ---------------------------------------------------------------------- Ran 2259 tests in 178.150s FAILED (errors=4, failures=3)
scipy.__version__
'0.7.0.dev4455'

Sat, 21 Jun 2008 16:13:29 +0900, David Cournapeau wrote:
Nils Wagner wrote:
There are lots of duplicate tickets, e.g. http://projects.scipy.org/scipy/scipy/ticket/672
IIRC, some tickets can be closed already since they have been fixed in svn.
Unfortunately, I can't close tickets so far.
If you give the ticket numbers, most of the job would be done, and someone (me) could triage and close them accordingly.
Still more: http://scipy.org/scipy/scipy/ticket/376 Can be closed: bug/feature in scikits.delaunay (Now #61 in scikits trac) -- Pauli Virtanen

On Mon, Jun 23, 2008 at 5:17 PM, Pauli Virtanen <pav@iki.fi> wrote:
Still more:
http://scipy.org/scipy/scipy/ticket/376 Can be closed: bug/feature in scikits.delaunay (Now #61 in scikits trac)
Done -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/

On Thu, Jun 19, 2008 at 9:19 PM, Nathan Bell <wnbell@gmail.com> wrote:
IMO we should address the any blockers now and get 0.7 out ASAP. Nine months is too long to wait for new features/fixes to appear.
Just a note: Jarrod, who is our fearless numpy release manager and I know also keeps a close eye on Scipy, is currently traveling quite a bit. I don't know his exact schedule, but he may actually be flying right now, and since it's a very long international flight, he might not pitch in for this discussion for a while. Cheers, f
participants (9)
-
David Cournapeau
-
Fernando Perez
-
Moritz Helias
-
Nathan Bell
-
Nils Wagner
-
Pauli Virtanen
-
Robert Kern
-
Ryan May
-
Yosef Meller