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 : Jeffrey.S.Whitaker@...236...
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 : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
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 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 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
···
On Wed, May 7, 2008 at 10:59 AM, Darren Dale <darren.dale@...143...> 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.
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
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
···
On Wed, May 7, 2008 at 1:21 PM, Eric Firing <efiring@...229...> 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.
I’m available to crank out some builds. I’ll keep my eyes peeled for the new numpy.
···
On Wed, May 7, 2008 at 1:21 PM, John Hunter <jdh2358@…149…> wrote:
On Wed, May 7, 2008 at 10:59 AM, Darren Dale <darren.dale@…143…> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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 <efiring@...229...> 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).
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 <efiring@...229...> 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).
matplotlib download | SourceForge.net
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
···
On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <mdroe@...31...> wrote:
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 <efiring@...229...> 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:
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).
matplotlib download | SourceForge.net
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
···
On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <mdroe@...31...> wrote:
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 <efiring@...229...> 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
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
···
On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <mdroe@...31...> 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."
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).
matplotlib download | SourceForge.net
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 <efiring@...229...> >>>> 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:
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
···
On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <mdroe@...31...> wrote:
Eric Firing wrote:
John Hunter 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
···
On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <mdroe@...31...> >> wrote:
--
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