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? I've done a fair amount of testing on the branch (0.91.3), particularly looking at all the PDF and SVG output from backend driver, and these backends are in the best shape I've ever seen them. I don't use these backends in my daily work, so haven't fully appreciated all the incremental progress that has been made. They are both now fully feature compliant, which is amazing to me (thanks to Mike and Jouni and everyone who did all the nitty gritty work here). I did notice a bug in SVG and PS for the first time, where the polar lines are not clipped to the polygon axes background ( I filed it at http://sourceforge.net/tracker/index.php?func=detail&aid=1977271&group_id=80706&atid=560720). I think we should take a crack at fixing these since the branch is otherwise in such good shape that we could perhaps go a long time w/o another maintenance release. On the trunk (0.98), the bug I am most concerned with is http://sourceforge.net/tracker/index.php?func=detail&aid=1976887&group_id=80706&atid=560720 . I find these jaggedy fonts in rotated text particularly grating, so I want to track this one down. So let's focus on clearing these bugs (and anything else the other devs raise), hopefully in the next couple days, and then push out the maintenance release followed by the pre-release of the branch. I'll also work on getting the site docs ready to go. On the issue of numpy 1.1: I am still not clear if our old binaries are broken. This came up in another thread on OS-X. If our binaries are broken with numpy 1.1 we need to move with a release ASAP, and these comparatively minor bugs should not hold us up. If they are not, I prefer to take a day or two and try and clear the above bugs first. I tested the mpl 0.91.2 win32 exe installer with the numpy 1.1 exe installer and had no troubles. Is the situation on OS-X different? Please advise. JDH
On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? [...] > So let's focus on clearing these bugs (and anything else the other > devs raise), hopefully in the next couple days, and then push out the > maintenance release followed by the pre-release of the branch. > > I'll also work on getting the site docs ready to go. On tuesday we ran into a spot of trouble at work, I've been having to put in extra hours and work at home in the evening to try to handle it. Unfortunately I probably won't be in a position to help with docs and bugs until the weekend.
On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? > > [...] > > > So let's focus on clearing these bugs (and anything else the other > > devs raise), hopefully in the next couple days, and then push out the > > maintenance release followed by the pre-release of the branch. > > > > I'll also work on getting the site docs ready to go. > > On tuesday we ran into a spot of trouble at work, I've been having to put > in extra hours and work at home in the evening to try to handle it. > Unfortunately I probably won't be in a position to help with docs and bugs > until the weekend. There is a bug in texmanager that I need to fix before we release 91.3 or 98pre. I'll try to squeeze it in this morning.
On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > > On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? > > > > [...] > > > > > So let's focus on clearing these bugs (and anything else the other > > > devs raise), hopefully in the next couple days, and then push out the > > > maintenance release followed by the pre-release of the branch. > > > > > > I'll also work on getting the site docs ready to go. > > > > On tuesday we ran into a spot of trouble at work, I've been having to put > > in extra hours and work at home in the evening to try to handle it. > > Unfortunately I probably won't be in a position to help with docs and > > bugs until the weekend. > > There is a bug in texmanager that I need to fix before we release 91.3 or > 98pre. I'll try to squeeze it in this morning. It looks like my problem is fixed on the branch and the trunk, thanks to Mike for helping sort out the merge. Darren
On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > > > On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? > > > > > > [...] > > > > > > > So let's focus on clearing these bugs (and anything else the other > > > > devs raise), hopefully in the next couple days, and then push out the > > > > maintenance release followed by the pre-release of the branch. > > > > > > > > I'll also work on getting the site docs ready to go. > > > > > > On tuesday we ran into a spot of trouble at work, I've been having to > > > put in extra hours and work at home in the evening to try to handle it. > > > Unfortunately I probably won't be in a position to help with docs and > > > bugs until the weekend. > > > > There is a bug in texmanager that I need to fix before we release 91.3 or > > 98pre. I'll try to squeeze it in this morning. > > It looks like my problem is fixed on the branch and the trunk, thanks to > Mike for helping sort out the merge. Looks like something else just turned up in ticker.py on the trunk. Somebody replaced minus signs with unicode, a good idea, but it breaks latex if unicode support is not enabled for usetex. I don't have time to fix it. File "monte_carlo.py", line 37, in <module> show() File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", line 66, in show figManager.canvas.draw() File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", line 133, in draw FigureCanvasAgg.draw(self) File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 255, in draw self.figure.draw(self.renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in draw for a in self.axes: a.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in draw a.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in draw tick.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in draw self.label1.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in draw Text.draw(self, renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in draw bbox, info = self._get_layout(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in _get_layout line, self._fontproperties, ismath=self.is_math_text(line)) File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 127, in get_text_width_height_descent Z = texmanager.get_grey(s, size, self.dpi) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 366, in get_grey pngfile = self.make_png(tex, fontsize, dpi) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 300, in make_png dvifile = self.make_dvi(tex, fontsize) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 269, in make_dvi texfile = self.make_tex(tex, fontsize) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 248, in make_tex fh.write(s) UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position 290: ordinal not in range(128)
On Thu, May 29, 2008 at 10:46 AM, Darren Dale <dar...@co...> r > Looks like something else just turned up in ticker.py on the trunk. Somebody > replaced minus signs with unicode, a good idea, but it breaks latex if > unicode support is not enabled for usetex. I don't have time to fix it. I just committed a fix for this -- when you get a minute, let me know if it works for you. We should get a usetex example in backend_driver... JDH
I'm happy to deal with this, but I wonder about the best path. Is it reasonable to assume that we have unicode support available in LaTeX and can just turn it on always, or do we need to (for instance) convert all the Unicode minus signs back into "-" and put the whole thing inside "$ $" (something that I suspect will be tricky in general also). Or, should we just back this minus sign stuff out (again), until we have a good general solution? BTW -- this change is only on the trunk, which is still expected to have some rough edges. Personally, I'm less concerned about fixing this asap than if it were on the maintenance branch. Cheers, Mike Darren Dale wrote: > On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > >> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: >> >>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: >>> >>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? >>>>>> >>>> [...] >>>> >>>> >>>>> So let's focus on clearing these bugs (and anything else the other >>>>> devs raise), hopefully in the next couple days, and then push out the >>>>> maintenance release followed by the pre-release of the branch. >>>>> >>>>> I'll also work on getting the site docs ready to go. >>>>> >>>> On tuesday we ran into a spot of trouble at work, I've been having to >>>> put in extra hours and work at home in the evening to try to handle it. >>>> Unfortunately I probably won't be in a position to help with docs and >>>> bugs until the weekend. >>>> >>> There is a bug in texmanager that I need to fix before we release 91.3 or >>> 98pre. I'll try to squeeze it in this morning. >>> >> It looks like my problem is fixed on the branch and the trunk, thanks to >> Mike for helping sort out the merge. >> > > Looks like something else just turned up in ticker.py on the trunk. Somebody > replaced minus signs with unicode, a good idea, but it breaks latex if > unicode support is not enabled for usetex. I don't have time to fix it. > > File "monte_carlo.py", line 37, in <module> > show() > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", > line 66, in show > figManager.canvas.draw() > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", > line 133, in draw > FigureCanvasAgg.draw(self) > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 255, in draw > self.figure.draw(self.renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in > draw > for a in self.axes: a.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in > draw > a.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in > draw > tick.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in > draw > self.label1.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in > draw > Text.draw(self, renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in > draw > bbox, info = self._get_layout(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in > _get_layout > line, self._fontproperties, ismath=self.is_math_text(line)) > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 127, in get_text_width_height_descent > Z = texmanager.get_grey(s, size, self.dpi) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 366, in get_grey > pngfile = self.make_png(tex, fontsize, dpi) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 300, in make_png > dvifile = self.make_dvi(tex, fontsize) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 269, in make_dvi > texfile = self.make_tex(tex, fontsize) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 248, in make_tex > fh.write(s) > UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position > 290: ordinal not in range(128) > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Disregard this -- I think John's solution looks good. Cheers, Mike Michael Droettboom wrote: > I'm happy to deal with this, but I wonder about the best path. > > Is it reasonable to assume that we have unicode support available in > LaTeX and can just turn it on always, or do we need to (for instance) > convert all the Unicode minus signs back into "-" and put the whole > thing inside "$ $" (something that I suspect will be tricky in general > also). Or, should we just back this minus sign stuff out (again), until > we have a good general solution? > > BTW -- this change is only on the trunk, which is still expected to have > some rough edges. Personally, I'm less concerned about fixing this asap > than if it were on the maintenance branch. > > Cheers, > Mike > > Darren Dale wrote: > >> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: >> >> >>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: >>> >>> >>>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: >>>> >>>> >>>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? >>>>>>> >>>>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>>> So let's focus on clearing these bugs (and anything else the other >>>>>> devs raise), hopefully in the next couple days, and then push out the >>>>>> maintenance release followed by the pre-release of the branch. >>>>>> >>>>>> I'll also work on getting the site docs ready to go. >>>>>> >>>>>> >>>>> On tuesday we ran into a spot of trouble at work, I've been having to >>>>> put in extra hours and work at home in the evening to try to handle it. >>>>> Unfortunately I probably won't be in a position to help with docs and >>>>> bugs until the weekend. >>>>> >>>>> >>>> There is a bug in texmanager that I need to fix before we release 91.3 or >>>> 98pre. I'll try to squeeze it in this morning. >>>> >>>> >>> It looks like my problem is fixed on the branch and the trunk, thanks to >>> Mike for helping sort out the merge. >>> >>> >> Looks like something else just turned up in ticker.py on the trunk. Somebody >> replaced minus signs with unicode, a good idea, but it breaks latex if >> unicode support is not enabled for usetex. I don't have time to fix it. >> >> File "monte_carlo.py", line 37, in <module> >> show() >> >> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", >> line 66, in show >> figManager.canvas.draw() >> >> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", >> line 133, in draw >> FigureCanvasAgg.draw(self) >> >> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", >> line 255, in draw >> self.figure.draw(self.renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in >> draw >> for a in self.axes: a.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in >> draw >> a.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in >> draw >> tick.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in >> draw >> self.label1.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in >> draw >> Text.draw(self, renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in >> draw >> bbox, info = self._get_layout(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in >> _get_layout >> line, self._fontproperties, ismath=self.is_math_text(line)) >> >> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", >> line 127, in get_text_width_height_descent >> Z = texmanager.get_grey(s, size, self.dpi) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 366, in get_grey >> pngfile = self.make_png(tex, fontsize, dpi) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 300, in make_png >> dvifile = self.make_dvi(tex, fontsize) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 269, in make_dvi >> texfile = self.make_tex(tex, fontsize) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 248, in make_tex >> fh.write(s) >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position >> 290: ordinal not in range(128) >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
I agree, this looks good. I'd really like to get a 98pre out soon, so I can distribute my own project which requires it. On Thursday 29 May 2008 12:04:29 pm Michael Droettboom wrote: > Disregard this -- I think John's solution looks good. > > Cheers, > Mike > > Michael Droettboom wrote: > > I'm happy to deal with this, but I wonder about the best path. > > > > Is it reasonable to assume that we have unicode support available in > > LaTeX and can just turn it on always, or do we need to (for instance) > > convert all the Unicode minus signs back into "-" and put the whole > > thing inside "$ $" (something that I suspect will be tricky in general > > also). Or, should we just back this minus sign stuff out (again), until > > we have a good general solution? > > > > BTW -- this change is only on the trunk, which is still expected to have > > some rough edges. Personally, I'm less concerned about fixing this asap > > than if it were on the maintenance branch. > > > > Cheers, > > Mike > > > > Darren Dale wrote: > >> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > >>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > >>>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > >>>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter 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? > >>>>> > >>>>> [...] > >>>>> > >>>>>> So let's focus on clearing these bugs (and anything else the other > >>>>>> devs raise), hopefully in the next couple days, and then push out > >>>>>> the maintenance release followed by the pre-release of the branch. > >>>>>> > >>>>>> I'll also work on getting the site docs ready to go. > >>>>> > >>>>> On tuesday we ran into a spot of trouble at work, I've been having to > >>>>> put in extra hours and work at home in the evening to try to handle > >>>>> it. Unfortunately I probably won't be in a position to help with > >>>>> docs and bugs until the weekend. > >>>> > >>>> There is a bug in texmanager that I need to fix before we release 91.3 > >>>> or 98pre. I'll try to squeeze it in this morning. > >>> > >>> It looks like my problem is fixed on the branch and the trunk, thanks > >>> to Mike for helping sort out the merge. > >> > >> Looks like something else just turned up in ticker.py on the trunk. > >> Somebody replaced minus signs with unicode, a good idea, but it breaks > >> latex if unicode support is not enabled for usetex. I don't have time to > >> fix it. > >> > >> File "monte_carlo.py", line 37, in <module> > >> show() > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", > >> line 66, in show > >> figManager.canvas.draw() > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.p > >>y", line 133, in draw > >> FigureCanvasAgg.draw(self) > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > >> line 255, in draw > >> self.figure.draw(self.renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line > >> 792, in draw > >> for a in self.axes: a.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line > >> 1452, in draw > >> a.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line > >> 680, in draw > >> tick.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line > >> 179, in draw > >> self.label1.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 761, in draw > >> Text.draw(self, renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 295, in draw > >> bbox, info = self._get_layout(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 195, in _get_layout > >> line, self._fontproperties, ismath=self.is_math_text(line)) > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > >> line 127, in get_text_width_height_descent > >> Z = texmanager.get_grey(s, size, self.dpi) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 366, in get_grey > >> pngfile = self.make_png(tex, fontsize, dpi) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 300, in make_png > >> dvifile = self.make_dvi(tex, fontsize) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 269, in make_dvi > >> texfile = self.make_tex(tex, fontsize) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 248, in make_tex > >> fh.write(s) > >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in > >> position 290: ordinal not in range(128) > >> > >> ------------------------------------------------------------------------ > >>- This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Matplotlib-devel mailing list > >> Mat...@li... > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 dar...@co... office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu
John Hunter wrote: > 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. To what bug do you refer? There seem to be related zoom-to-rect bugs in both the trunk and the branch. In both, zooming in to a region comparable to, or smaller than, a "pixel" (meaning a grid cell in the data array), gets unbearably slow. In the branch, it has the additional characteristic of fading out. I think this bug may be inherent in Agg, and has been around indefinitely. Or are you referring to some other bug? Eric > > JDH > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Thu, May 29, 2008 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
> To what bug do you refer? There seem to be related zoom-to-rect bugs in
> both the trunk and the branch. In both, zooming in to a region comparable
> to, or smaller than, a "pixel" (meaning a grid cell in the data array), gets
> unbearably slow. In the branch, it has the additional characteristic of
> fading out. I think this bug may be inherent in Agg, and has been around
> indefinitely.
Yes, this is a problem in either the _image or _backend_agg
implementation, not agg itself, and should be fixed.
But I was referring to a different problem. In the thread:
"[Matplotlib-users] matploblib communication problem, graphics
question" I wrote about a zoom to rect bug (I'll paste the relevant
bit below), but for the life of me I can't replicate it on my machine
here (TkAgg). I'll have to test at home on wxagg on OSX which is
where I was having the problems:
Here was the OP:
In testing this stuff, I found a bug bug in image handling on the
trunk -- if you zoom to part of an image with zoom-to-rect, the part
that you get zoomed to is not the part you select. This is most
apparent if you load an image with easily recognizable features, eg a
picture of a person. This problem is on the trunk but not the branch
-- here is some example code:
In [8]: fig = plt.figure()
In [9]: ax = fig.add_subplot(111)
In [10]: ax.set_aspect('auto')
In [11]: X = imread('/Users/jdhunter/Desktop/IMG_0907.JPG')
In [12]: ax.imshow(X, origin='lower', aspect='auto')
Out[12]: <matplotlib.image.AxesImage object at 0x112586b0>
In [13]: ax.figure.canvas.draw()
In [14]: ax.cla()
In [15]: ax.set_aspect('auto')
In [16]: ax.imshow(X, origin='upper', aspect='auto')
Out[16]: <matplotlib.image.AxesImage object at 0x11258690>
In [17]: fig.canvas.draw()
I went ahead and called it 0.98.0. I am getting a parallels image updated so I can do the windows builds, but it is getting late. I will get those cranked out tomorrow. The source and mac builds are up though. I got two internal compiler errors on the 0.98.0 build, which I fixed by replacing -O3 with -Os on those two commands only. I also updated the MANIFEST.in file to include agg24 instead of agg23. - Charlie On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote: > 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 >
Were the internal compiler errors on the Mac? Can you share them? It would be nice to work around these in a cleaner way if possible. Cheers, Mike Charlie Moad wrote: > I went ahead and called it 0.98.0. I am getting a parallels image > updated so I can do the windows builds, but it is getting late. I > will get those cranked out tomorrow. The source and mac builds are up > though. I got two internal compiler errors on the 0.98.0 build, which > I fixed by replacing -O3 with -Os on those two commands only. I also > updated the MANIFEST.in file to include agg24 instead of agg23. > > - Charlie > > On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote: > >> 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 >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Yeah. I am totally updated with 10.5.3 and the latest dev tools. They have been talked about for a while on the list, but I just wanted to record what I ran into during the builds. I'll reproduce those errors after I get the windows builds done tonight and shoot them this way. - Charlie On Fri, May 30, 2008 at 8:19 AM, Michael Droettboom <md...@st...> wrote: > Were the internal compiler errors on the Mac? Can you share them? It would > be nice to work around these in a cleaner way if possible. > > Cheers, > Mike > > Charlie Moad wrote: >> >> I went ahead and called it 0.98.0. I am getting a parallels image >> updated so I can do the windows builds, but it is getting late. I >> will get those cranked out tomorrow. The source and mac builds are up >> though. I got two internal compiler errors on the 0.98.0 build, which >> I fixed by replacing -O3 with -Os on those two commands only. I also >> updated the MANIFEST.in file to include agg24 instead of agg23. >> >> - Charlie >> >> On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote: >> >>> >>> 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 >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > >
On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote: > I went ahead and called it 0.98.0. I am getting a parallels image > updated so I can do the windows builds, but it is getting late. I > will get those cranked out tomorrow. The source and mac builds are up > though. I got two internal compiler errors on the 0.98.0 build, which > I fixed by replacing -O3 with -Os on those two commands only. I also > updated the MANIFEST.in file to include agg24 instead of agg23. Hey Charlie -- thanks for getting these two releases out. I think we should probably hide them, though, until the windows binaries are up, since it will confuse windows users who follow the link to the latest releases but find no binaries. So if you are more than a few hours away from putting up the windows installers, let's hide these until they are ready. Thanks, JDH
Done. On Fri, May 30, 2008 at 10:06 AM, John Hunter <jd...@gm...> wrote: > On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote: >> I went ahead and called it 0.98.0. I am getting a parallels image >> updated so I can do the windows builds, but it is getting late. I >> will get those cranked out tomorrow. The source and mac builds are up >> though. I got two internal compiler errors on the 0.98.0 build, which >> I fixed by replacing -O3 with -Os on those two commands only. I also >> updated the MANIFEST.in file to include agg24 instead of agg23. > > Hey Charlie -- thanks for getting these two releases out. I think we > should probably hide them, though, until the windows binaries are up, > since it will confuse windows users who follow the link to the latest > releases but find no binaries. So if you are more than a few hours > away from putting up the windows installers, let's hide these until > they are ready. > > Thanks, > JDH >
Sorry for the delay but I am running into windows/gtk problems. I am getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk symbols. I can't seem to find which lib they are in either. I installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific version of gtk? I am thinking I might have to fall back to an older version. - Charlie On Fri, May 30, 2008 at 10:06 AM, John Hunter <jd...@gm...> wrote: > On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote: >> I went ahead and called it 0.98.0. I am getting a parallels image >> updated so I can do the windows builds, but it is getting late. I >> will get those cranked out tomorrow. The source and mac builds are up >> though. I got two internal compiler errors on the 0.98.0 build, which >> I fixed by replacing -O3 with -Os on those two commands only. I also >> updated the MANIFEST.in file to include agg24 instead of agg23. > > Hey Charlie -- thanks for getting these two releases out. I think we > should probably hide them, though, until the windows binaries are up, > since it will confuse windows users who follow the link to the latest > releases but find no binaries. So if you are more than a few hours > away from putting up the windows installers, let's hide these until > they are ready. > > Thanks, > JDH >
On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cw...@gm...> wrote: > Sorry for the delay but I am running into windows/gtk problems. I am > getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk > symbols. I can't seem to find which lib they are in either. I > installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific > version of gtk? I am thinking I might have to fall back to an older We are not targeting a specific gtk version and I am not sure that we need to be supporting gtk in win32 anymore. I used to distribute a gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is actively using this anymore (it is part of nipy now). We could do a test build w/o gtk and see if anyone complains, or simply revert back to the last gtk version that worked for you. In any case, I don't think you should burn a lot of time on it. If you can get a gtk enabled win32 build, great. If not, just disable gtk support. Our goal is to get rid of as much gui dependent extension code as possible anyhow. I think we've concluded that we can't get rid of the tkagg extension, but for the rest of the GUIs we should be able to use python buffer objects. Perhaps this will provide some impetus to develop a pure pygtk enabled gtkagg. JDH
Rolling gtk and pygtk back to 2.10 worked. https://sourceforge.net/project/showfiles.php?group_id=80706 I may be a little rusty on the builds, so please give them a try before the announcement. - Charlie On Sat, May 31, 2008 at 12:31 PM, John Hunter <jd...@gm...> wrote: > On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cw...@gm...> wrote: >> Sorry for the delay but I am running into windows/gtk problems. I am >> getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk >> symbols. I can't seem to find which lib they are in either. I >> installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific >> version of gtk? I am thinking I might have to fall back to an older > > We are not targeting a specific gtk version and I am not sure that we > need to be supporting gtk in win32 anymore. I used to distribute a > gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is > actively using this anymore (it is part of nipy now). We could do a > test build w/o gtk and see if anyone complains, or simply revert back > to the last gtk version that worked for you. > > In any case, I don't think you should burn a lot of time on it. If > you can get a gtk enabled win32 build, great. If not, just disable > gtk support. Our goal is to get rid of as much gui dependent > extension code as possible anyhow. I think we've concluded that we > can't get rid of the tkagg extension, but for the rest of the GUIs we > should be able to use python buffer objects. Perhaps this will > provide some impetus to develop a pure pygtk enabled gtkagg. > > JDH >