What do people think of releasing 0.98 after numpy 1.1 is released this weekend? The main reason I'd like to do this (instead of releasing another 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is installed as an egg basemap (or any other toolkit) cannot be installed. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
I don't know if 0.98 has seen enough hammering to be a recommended stable release. (Just today, Matthias Michler pointed out a pretty significant bug with widgets related to the refactoring). I think a 0.98 release that is clearly labeled as beta would not be a bad thing to get it in the hands of more people who don't track SVN. I think a 0.91.3 release is probably also in order, since there are 23 bugfixes, most notably the wx saving bug. I think that release is important to push bugfixes out to distributions that already package 0.91.2 (e.g. Ubuntu Hardy). And as for the egg issue (which I'm completely ignorant of) -- is that something that could be fixed on 0.91.x without too much trouble? Is it something that once worked and is now broken? Cheers, Mike Jeff Whitaker wrote: > What do people think of releasing 0.98 after numpy 1.1 is released this > weekend? > > The main reason I'd like to do this (instead of releasing another > 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is > installed as an egg basemap (or any other toolkit) cannot be installed. > > -Jeff > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Michael Droettboom wrote: > I don't know if 0.98 has seen enough hammering to be a recommended > stable release. (Just today, Matthias Michler pointed out a pretty > significant bug with widgets related to the refactoring). I think a > 0.98 release that is clearly labeled as beta would not be a bad thing > to get it in the hands of more people who don't track SVN. > > I think a 0.91.3 release is probably also in order, since there are 23 > bugfixes, most notably the wx saving bug. I think that release is > important to push bugfixes out to distributions that already package > 0.91.2 (e.g. Ubuntu Hardy). > > And as for the egg issue (which I'm completely ignorant of) -- is that > something that could be fixed on 0.91.x without too much trouble? Is > it something that once worked and is now broken? > > Cheers, > Mike Mike: The egg issue required renaming matplotlib.toolkits to mpl_toolkits. We discussed this at the time, and decided it would cause too much code breakage to be included in 0.91.x. I'm OK with a 0.98 beta, but that's more work for Charlie to make extra installers and eggs. -Jeff > > Jeff Whitaker wrote: >> What do people think of releasing 0.98 after numpy 1.1 is released >> this weekend? >> The main reason I'd like to do this (instead of releasing another >> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is >> installed as an egg basemap (or any other toolkit) cannot be installed. >> >> -Jeff >> >> > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
On Wednesday 07 May 2008 11:18:22 am Michael Droettboom wrote: > I don't know if 0.98 has seen enough hammering to be a recommended > stable release. (Just today, Matthias Michler pointed out a pretty > significant bug with widgets related to the refactoring). I think a > 0.98 release that is clearly labeled as beta would not be a bad thing to > get it in the hands of more people who don't track SVN. I'm also in favor of a 0.98 release. Calling it beta is fine, I just need something other than svn to which I can point my users. Darren
On Wed, May 7, 2008 at 10:59 AM, Darren Dale <dar...@co...> wrote: > I'm also in favor of a 0.98 release. Calling it beta is fine, I just need > something other than svn to which I can point my users. I happy with both -- doing a 0.91.3 maintenance release and a 0.98.beta release. We don't have to do them at the same time, but it might be easier. Charlie? JDH
I'm available to crank out some builds. I'll keep my eyes peeled for the new numpy. - Charlie On Wed, May 7, 2008 at 1:21 PM, John Hunter <jd...@gm...> wrote: > On Wed, May 7, 2008 at 10:59 AM, Darren Dale <dar...@co...> > wrote: > > > I'm also in favor of a 0.98 release. Calling it beta is fine, I just > need > > something other than svn to which I can point my users. > > I happy with both -- doing a 0.91.3 maintenance release and a > 0.98.beta release. We don't have to do them at the same time, but it > might be easier. Charlie? > > JDH > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save 100ドル. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Michael Droettboom wrote: > I don't know if 0.98 has seen enough hammering to be a recommended > stable release. (Just today, Matthias Michler pointed out a pretty > significant bug with widgets related to the refactoring). I think a > 0.98 release that is clearly labeled as beta would not be a bad thing to > get it in the hands of more people who don't track SVN. > Getting out a 0.98 beta soon would help in getting it more widely tested, but it would be nice if that first beta passed the basic checks of working for all backend_driver tests on all the standard backends. As of the last time I looked, this was not the case. Eric
On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: > Getting out a 0.98 beta soon would help in getting it more widely > tested, but it would be nice if that first beta passed the basic checks > of working for all backend_driver tests on all the standard backends. > As of the last time I looked, this was not the case. both the branch and the trunk are running w/o error on my system. The branch is issuing some warnings related to the new hist changes. JDH
John Hunter wrote: > On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: > >> Getting out a 0.98 beta soon would help in getting it more widely >> tested, but it would be nice if that first beta passed the basic checks >> of working for all backend_driver tests on all the standard backends. >> As of the last time I looked, this was not the case. > > both the branch and the trunk are running w/o error on my system. The > branch is issuing some warnings related to the new hist changes. > > JDH They run, but the trunk does not make valid plots in all cases. Many things are fouled up in SVG. The quadmesh_demo.ps is broken. I have not checked pdf. Eric
On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <md...@st...> wrote: > The SVG examples all look good now, as does PDF and Agg (unless I'm missing > some small details in my quick scanning of the images). > > The problem with quadmesh_demo in the Ps backend seems to have been > introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with the > exception that strokes are being drawn around the masked-out quads. (That's > an easy bug to fix, however -- just return early from _draw_ps if "stroke" > and "fill" are both false). > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082 > > Since I don't recall the issues that r5802/r5803 were trying to solve, I'm > hoping that one of you could have a look at this and have a better idea > where it's going wrong... Eric and I were simultaneously working on a bug described in the thread "dpi-related positioning errors in Agg savefig" and ended up communicating off list. He committed the final fix, so perhaps Eric you could look at this and see where the logic needs to be updated. JDH > > Cheers, > Mike > > Michael Droettboom wrote: >> >> I'm making some progress on SVG -- all issues I've seen so far seem to be >> related to clipping. I'll let you know how it goes. Just a heads up to >> delay the release for now (unless I come across something that doesn't look >> like it can be fixed in a short amount of time.) >> >> Cheers, >> Mike >> >> Eric Firing wrote: >> >>> >>> John Hunter wrote: >>> >>>> >>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: >>>> >>>> >>>>> >>>>> Getting out a 0.98 beta soon would help in getting it more widely >>>>> tested, but it would be nice if that first beta passed the basic >>>>> checks >>>>> of working for all backend_driver tests on all the standard backends. >>>>> As of the last time I looked, this was not the case. >>>>> >>>> >>>> both the branch and the trunk are running w/o error on my system. The >>>> branch is issuing some warnings related to the new hist changes. >>>> >>>> JDH >>>> >>> >>> They run, but the trunk does not make valid plots in all cases. Many >>> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have not >>> checked pdf. >>> >>> Eric >>> >> >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > >
John Hunter wrote: > On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <md...@st...> wrote: > >> The SVG examples all look good now, as does PDF and Agg (unless I'm missing >> some small details in my quick scanning of the images). >> >> The problem with quadmesh_demo in the Ps backend seems to have been >> introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with the >> exception that strokes are being drawn around the masked-out quads. (That's >> an easy bug to fix, however -- just return early from _draw_ps if "stroke" >> and "fill" are both false). >> >> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082 >> >> Since I don't recall the issues that r5802/r5803 were trying to solve, I'm >> hoping that one of you could have a look at this and have a better idea >> where it's going wrong... >> > > Eric and I were simultaneously working on a bug described in the > thread "dpi-related positioning errors in Agg savefig" and ended up > communicating off list. He committed the final fix, so perhaps Eric > you could look at this and see where the logic needs to be updated. > > Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying to deal with something more specific to Postscript. Here's the commit note: "Alternative fix for ps backend bug; removes superfluous gsave/grestores." Cheers, Mike > > >> Cheers, >> Mike >> >> Michael Droettboom wrote: >> >>> I'm making some progress on SVG -- all issues I've seen so far seem to be >>> related to clipping. I'll let you know how it goes. Just a heads up to >>> delay the release for now (unless I come across something that doesn't look >>> like it can be fixed in a short amount of time.) >>> >>> Cheers, >>> Mike >>> >>> Eric Firing wrote: >>> >>> >>>> John Hunter wrote: >>>> >>>> >>>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: >>>>> >>>>> >>>>> >>>>>> Getting out a 0.98 beta soon would help in getting it more widely >>>>>> tested, but it would be nice if that first beta passed the basic >>>>>> checks >>>>>> of working for all backend_driver tests on all the standard backends. >>>>>> As of the last time I looked, this was not the case. >>>>>> >>>>>> >>>>> both the branch and the trunk are running w/o error on my system. The >>>>> branch is issuing some warnings related to the new hist changes. >>>>> >>>>> JDH >>>>> >>>>> >>>> They run, but the trunk does not make valid plots in all cases. Many >>>> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have not >>>> checked pdf. >>>> >>>> Eric >>>> >>>> >>> >> -- >> Michael Droettboom >> Science Software Branch >> Operations and Engineering Division >> Space Telescope Science Institute >> Operated by AURA for NASA >> >> >> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote: > Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying > to deal with something more specific to Postscript. Here's the commit note: > > "Alternative fix for ps backend bug; removes superfluous gsave/grestores." That's the one I am referring to also -- we started talking about some dpi related problems in the thread I referred to and meandered over to this other bug, which was caused by the draw_ps code not properly doing a gsave/restore wrapper if the object did not have a cliprect or a clippath. It was exposed by the quiver key object, which has a collection that uses offsets and no clipping. Eric and I separately committed a patch to make sure gsave/grestore was being called, but his was cleaner so his was the final version. But apparently something was left out... JDH
John Hunter wrote: > On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote: > >> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying >> to deal with something more specific to Postscript. Here's the commit note: >> >> "Alternative fix for ps backend bug; removes superfluous gsave/grestores." > > That's the one I am referring to also -- we started talking about some > dpi related problems in the thread I referred to and meandered over to > this other bug, which was caused by the draw_ps code not properly > doing a gsave/restore wrapper if the object did not have a cliprect or > a clippath. It was exposed by the quiver key object, which has a > collection that uses offsets and no clipping. Eric and I separately > committed a patch to make sure gsave/grestore was being called, but > his was cleaner so his was the final version. But apparently > something was left out... > > JDH Right. I will look at, today if at all possible. Eric
John Hunter wrote: > On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote: > >> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying >> to deal with something more specific to Postscript. Here's the commit note: >> >> "Alternative fix for ps backend bug; removes superfluous gsave/grestores." > > That's the one I am referring to also -- we started talking about some > dpi related problems in the thread I referred to and meandered over to > this other bug, which was caused by the draw_ps code not properly > doing a gsave/restore wrapper if the object did not have a cliprect or > a clippath. It was exposed by the quiver key object, which has a > collection that uses offsets and no clipping. Eric and I separately > committed a patch to make sure gsave/grestore was being called, but > his was cleaner so his was the final version. But apparently > something was left out... Yes, I misunderstood something in the original version. I *think* I have it all straightened out now. I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu feisty) chokes on the apostrophe in text, such as in table_demo and one or two others. I think this is just a crazy bug in this version of gs; you aren't having any such problems, are you? The problem does not appear with cairo.ps output because it encodes the text strings in some bizarre fashion. Eric
Eric Firing wrote: > John Hunter wrote: >> On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> >> wrote: >> >>> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were >>> trying >>> to deal with something more specific to Postscript. Here's the >>> commit note: >>> >>> "Alternative fix for ps backend bug; removes superfluous >>> gsave/grestores." >> >> That's the one I am referring to also -- we started talking about some >> dpi related problems in the thread I referred to and meandered over to >> this other bug, which was caused by the draw_ps code not properly >> doing a gsave/restore wrapper if the object did not have a cliprect or >> a clippath. It was exposed by the quiver key object, which has a >> collection that uses offsets and no clipping. Eric and I separately >> committed a patch to make sure gsave/grestore was being called, but >> his was cleaner so his was the final version. But apparently >> something was left out... > > Yes, I misunderstood something in the original version. I *think* I > have it all straightened out now. Looks good here. > > I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu > feisty) chokes on the apostrophe in text, such as in table_demo and > one or two others. I think this is just a crazy bug in this version > of gs; you aren't having any such problems, are you? The problem does > not appear with cairo.ps output because it encodes the text strings in > some bizarre fashion. Thanks. I've fixed this on the branch and trunk. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Michael Droettboom wrote: >> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu >> feisty) chokes on the apostrophe in text, such as in table_demo and >> one or two others. I think this is just a crazy bug in this version >> of gs; you aren't having any such problems, are you? The problem does >> not appear with cairo.ps output because it encodes the text strings in >> some bizarre fashion. > Thanks. I've fixed this on the branch and trunk. Mike, Thank you--so, is this a workaround for a gs bug, or does the single quote have some special meaning in postscript? When I first ran into the problem I googled and looked at some PS documentation, and I couldn't find anything indicating that the plain single quote character as a literal was forbidden. Eric
Eric Firing wrote: > Michael Droettboom wrote: > >>> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu >>> feisty) chokes on the apostrophe in text, such as in table_demo and >>> one or two others. I think this is just a crazy bug in this version >>> of gs; you aren't having any such problems, are you? The problem >>> does not appear with cairo.ps output because it encodes the text >>> strings in some bizarre fashion. >> Thanks. I've fixed this on the branch and trunk. > > Mike, > > Thank you--so, is this a workaround for a gs bug, or does the single > quote have some special meaning in postscript? When I first ran into > the problem I googled and looked at some PS documentation, and I > couldn't find anything indicating that the plain single quote > character as a literal was forbidden. 0x27 is fine as a literal, but it maps to "apostrophe", not "singlequote". The former isn't present in any of the Postscript tables of the fonts I looked at (Vera and the standard Windows fonts), so gs was crashing on the missing character. So, I just added a line to convert all apostrophes to singlequotes. Don't know if that's the right thing to do, but it works. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
I'm making some progress on SVG -- all issues I've seen so far seem to be related to clipping. I'll let you know how it goes. Just a heads up to delay the release for now (unless I come across something that doesn't look like it can be fixed in a short amount of time.) Cheers, Mike Eric Firing wrote: > John Hunter wrote: >> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: >> >>> Getting out a 0.98 beta soon would help in getting it more widely >>> tested, but it would be nice if that first beta passed the basic >>> checks >>> of working for all backend_driver tests on all the standard backends. >>> As of the last time I looked, this was not the case. >> >> both the branch and the trunk are running w/o error on my system. The >> branch is issuing some warnings related to the new hist changes. >> >> JDH > > They run, but the trunk does not make valid plots in all cases. Many > things are fouled up in SVG. The quadmesh_demo.ps is broken. I have > not checked pdf. > > Eric -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
The SVG examples all look good now, as does PDF and Agg (unless I'm missing some small details in my quick scanning of the images). The problem with quadmesh_demo in the Ps backend seems to have been introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with the exception that strokes are being drawn around the masked-out quads. (That's an easy bug to fix, however -- just return early from _draw_ps if "stroke" and "fill" are both false). http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082 Since I don't recall the issues that r5802/r5803 were trying to solve, I'm hoping that one of you could have a look at this and have a better idea where it's going wrong... Cheers, Mike Michael Droettboom wrote: > I'm making some progress on SVG -- all issues I've seen so far seem to > be related to clipping. I'll let you know how it goes. Just a heads up > to delay the release for now (unless I come across something that > doesn't look like it can be fixed in a short amount of time.) > > Cheers, > Mike > > Eric Firing wrote: > >> John Hunter wrote: >> >>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote: >>> >>> >>>> Getting out a 0.98 beta soon would help in getting it more widely >>>> tested, but it would be nice if that first beta passed the basic >>>> checks >>>> of working for all backend_driver tests on all the standard backends. >>>> As of the last time I looked, this was not the case. >>>> >>> both the branch and the trunk are running w/o error on my system. The >>> branch is issuing some warnings related to the new hist changes. >>> >>> JDH >>> >> They run, but the trunk does not make valid plots in all cases. Many >> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have >> not checked pdf. >> >> Eric >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
I forgot to mention -- A handful of SVG examples (polar_demo.py, specgram_demo.py) cause my Firefox 2.0.0.14 on RHEL4 to crash. These same files read fine in Inkscape 0.46. AFAICT, there is some sort of limit on the number of vertices in a path, as shortening them does help, but I couldn't find a reference to this bug online. Unfortunately, given that a path could be a closed polygon, simply chunking the path data into multiple elements isn't good enough. So a general solution will be tricky. I don't think this is worth holding off on the beta release (0.91.x has this same problem), but it's something to be aware of. Cheers, Mike Michael Droettboom wrote: > The SVG examples all look good now, as does PDF and Agg (unless I'm > missing some small details in my quick scanning of the images). > > The problem with quadmesh_demo in the Ps backend seems to have been > introduced by r5082. r5081 (on backend_ps.py alone) seems to work, > with the exception that strokes are being drawn around the masked-out > quads. (That's an easy bug to fix, however -- just return early from > _draw_ps if "stroke" and "fill" are both false). > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082 > > > Since I don't recall the issues that r5802/r5803 were trying to solve, > I'm hoping that one of you could have a look at this and have a better > idea where it's going wrong... > > Cheers, > Mike > > Michael Droettboom wrote: >> I'm making some progress on SVG -- all issues I've seen so far seem >> to be related to clipping. I'll let you know how it goes. Just a >> heads up to delay the release for now (unless I come across something >> that doesn't look like it can be fixed in a short amount of time.) >> >> Cheers, >> Mike >> >> Eric Firing wrote: >> >>> John Hunter wrote: >>> >>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> >>>> wrote: >>>> >>>> >>>>> Getting out a 0.98 beta soon would help in getting it more widely >>>>> tested, but it would be nice if that first beta passed the basic >>>>> checks >>>>> of working for all backend_driver tests on all the standard >>>>> backends. >>>>> As of the last time I looked, this was not the case. >>>>> >>>> both the branch and the trunk are running w/o error on my system. The >>>> branch is issuing some warnings related to the new hist changes. >>>> >>>> JDH >>>> >>> They run, but the trunk does not make valid plots in all cases. >>> Many things are fouled up in SVG. The quadmesh_demo.ps is broken. >>> I have not checked pdf. >>> >>> Eric >>> >> >> > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? - Charlie On Wed, May 7, 2008 at 11:07 AM, Jeff Whitaker <js...@fa...> wrote: > > What do people think of releasing 0.98 after numpy 1.1 is released this > weekend? > > The main reason I'd like to do this (instead of releasing another > 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is > installed as an egg basemap (or any other toolkit) cannot be installed. > > -Jeff > > -- > Jeffrey S. Whitaker Phone : (303)497-6313 > Meteorologist FAX : (303)497-6449 > NOAA/OAR/PSD R/PSD1 Email : Jef...@no... > 325 Broadway Office : Skaggs Research Cntr 1D-124 > Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save 100ドル. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote: > Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? We are now ready to do 0.98pre -- fire when ready Charlie. JDH
On Thu, May 29, 2008 at 12:09 PM, John Hunter <jd...@gm...> wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote: >> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? > > We are now ready to do 0.98pre -- fire when ready Charlie. 91.3 is now ready too. Since there is still a bug in zoom-to-rect for images in 98pre, let's make 91.3 the default visible to the users who just click on "download" and I'll make a link to the 98pre download section in the newsbox section of the web-page. JDH
Just to confirm, I should use the version tag, "0.98pre"? - Charlie On Thu, May 29, 2008 at 1:09 PM, John Hunter <jd...@gm...> wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote: >> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? > > We are now ready to do 0.98pre -- fire when ready Charlie. > > JDH >
On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote: > Just to confirm, I should use the version tag, "0.98pre"? My preference is to call it 0.98.0 unless Michael is feeling extra cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever ... JDH