new release?

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 <jswhit@...196...> 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

-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options

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 Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> wrote:

Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?

> 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 Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> wrote:

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 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 <cwmoad@...149...> 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.

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 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 <cwmoad@...149...> 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.

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 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 <cwmoad@...149...> 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.

On Thu, May 29, 2008 at 10:46 AM, Darren Dale <darren.dale@...143...> 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 <cwmoad@...149...> >>>>> > 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
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 <cwmoad@...149...> >>>>>> >>>>>> >> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
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 <cwmoad@...149...> > >> > >> 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
>> Matplotlib-devel@lists.sourceforge.net
>> matplotlib-devel List Signup and Options

--
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

darren.dale@...143...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

We are now ready to do 0.98pre -- fire when ready Charlie.

JDH

···

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> wrote:

Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?

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

···

On Thu, May 29, 2008 at 12:09 PM, John Hunter <jdh2358@...149...> wrote:

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> 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.

John Hunter 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

···

On Thu, May 29, 2008 at 12:09 PM, John Hunter <jdh2358@...149...> wrote:

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> wrote:

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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

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()

···

On Thu, May 29, 2008 at 1:52 PM, Eric Firing <efiring@...229...> 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.

Just to confirm, I should use the version tag, "0.98pre"?

- Charlie

···

On Thu, May 29, 2008 at 1:09 PM, John Hunter <jdh2358@...149...> wrote:

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cwmoad@...149...> 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

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

···

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cwmoad@...149...> wrote:

Just to confirm, I should use the version tag, "0.98pre"?

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 <jdh2358@...149...> wrote:

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cwmoad@...149...> 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 <jdh2358@...149...> wrote:
  

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cwmoad@...149...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
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 <mdroe@...31...> 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 <jdh2358@...149...> wrote:

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cwmoad@...149...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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 Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cwmoad@...149...> 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.