matplotlib-devel Mailing List for matplotlib (Page 2)

Johann Cohen-Tanugi wrote:
> is basemap deferred as well? It is kinda 3D no?

I understand basemap is working reasonably well.  But Jeff Whitaker 
would know better than I.

> Second a color map or 
> contour plot is kinda 2D either...... unless I am confusing what you 
> mean by 2D : 2D in rendering or in data structure?

I mean 2D in rendering -- matplotlib is fundamentally built on top of 2D 
rendering APIs, which makes doing a lot of 3D things more 
computationally expensive and less flexible than a dedicated 3D plotting 
package.

> Anyway, I am probably not the motivated individual to tackle this work, 
> most of all because I do not know matplotlib internals, I am just a 
> user, albeit with coding abilities.

Well, anyone can jump in ;)  Unfortunately, I probably don't have the 
time for that now.  I believe John Hunter has some more fully-formed 
ideas about where 3D in matplotlib should go and where the best path may 
be going forward.

Cheers,
Mike

> Michael Droettboom wrote:
>> Yes, it is probably a good-sized chunk of work.  In the recent 
>> transforms overhaul, the 3d stuff was deferred, so it hasn't been 
>> updated to use the new "way of doing things".
>>
>> Just "getting it to work as it did before" is probably less work than 
>> "rethinking what 3D means in the context of matplotlib", which is a 
>> fundamentally 2D plotting environment.  And there was some thinking 
>> along the lines of "why bother with the former, if the latter may be 
>> on the horizon?..."  But I think it's going to take some motivated 
>> individual to step up and do either of these.
>>
>> Cheers,
>> Mike
>>
>> Johann Cohen-Tanugi wrote:
>>> is there a lot of work involved in getting it in? I can wait a bit, 
>>> or even try to help out.... It is not critical as I know plenty other 
>>> way to get the plot I want.... Just that  I love matplotlib and scipy
>>>
>>> best,
>>> Johann
>>>
>>> Michael Droettboom wrote:
>>>> The axes3d stuff is not currently working on the SVN trunk.  You 
>>>> probably want to use 0.91.2 or the v0_91_maint branch in SVN instead.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Johann Cohen-Tanugi wrote:
>>>>> hello,
>>>>> thanks for answering. I actually fail with the import :
>>>>> In [1]: from matplotlib import axes3d
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>> ImportError                               Traceback (most recent 
>>>>> call last)
>>>>>
>>>>> /home/cohen/bstw/<ipython console> in <module>()
>>>>>
>>>>> /usr/lib/python2.5/site-packages/matplotlib/axes3d.py in <module>()
>>>>>      14 from axes import Axes
>>>>>      15 import cbook
>>>>> ---> 16 from transforms import unit_bbox
>>>>>      17
>>>>>      18 import numpy as npy
>>>>>
>>>>> ImportError: cannot import name unit_bbox
>>>>>
>>>>> any idea?
>>>>>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> Message: 1
>>>>>> Date: Sun, 27 Jan 2008 22:18:00 +0000
>>>>>> From: "Neil Crighton" <nei...@gm...>
>>>>>> Subject: Re: [Matplotlib-users] plotting a series of 3D points and
>>>>>>     picker=True and 3D
>>>>>> To: mat...@li...
>>>>>> Message-ID:
>>>>>>     <637...@ma...>
>>>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>>>
>>>>>> I think scatter3D does what you want:
>>>>>>
>>>>>> from matplotlib import axes3d
>>>>>> import pylab as pl
>>>>>> fig = pl.figure()
>>>>>> ax = axes3d.Axes3D(fig)
>>>>>> ax.scatter3D(data[:,0],data[:,1],data[:,2])
>>>>>> ax.set_xlabel('X value')
>>>>>> ax.set_ylabel('Y value')
>>>>>> ax.set_zlabel('Z value')
>>>>>> pl.show()
>>>>>>
>>>>>> You could also change the colour and size of each point based on 
>>>>>> other
>>>>>> array values:
>>>>>>
>>>>>> col = ax.scatter3D(data[:,0], data[:,1], data[:,2], c=data[:,3],
>>>>>> cmap=pl.cm.jet, s=data[:,4])
>>>>>> cbar = fig.colorbar(col,shrink=0.9,extend='both')
>>>>>> cbar.ax.set_ylabel('axis 3 data values')
>>>>>>
>>>>>> Pretty nifty.
>>>>>>
>>>>>> Neil
>>>>>>
>>>>>>  
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> 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-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>

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

Interesting.  I can't reproduce this with Python-2.5 on Linux.  What 
version of numpy do you have installed?  Can you send your matplotlibrc 
file?

Cheers,
Mike

Jörgen Stenarson wrote:
> Hi,
> 
> I think there is a bug in the pdf backend (png-files save ok) that makes 
> plots crash when they contain a marker.
> 
> The attached script crashes on the last savefig. I have also attached a 
> traceback.
> 
> I run matplotlib-svn-4904 on windows with python 2.4
> 
> /Jörgen
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Yes, it is probably a good-sized chunk of work.  In the recent 
transforms overhaul, the 3d stuff was deferred, so it hasn't been 
updated to use the new "way of doing things".

Just "getting it to work as it did before" is probably less work than 
"rethinking what 3D means in the context of matplotlib", which is a 
fundamentally 2D plotting environment.  And there was some thinking 
along the lines of "why bother with the former, if the latter may be on 
the horizon?..."  But I think it's going to take some motivated 
individual to step up and do either of these.

Cheers,
Mike

Johann Cohen-Tanugi wrote:
> is there a lot of work involved in getting it in? I can wait a bit, or 
> even try to help out.... It is not critical as I know plenty other way 
> to get the plot I want.... Just that  I love matplotlib and scipy
> 
> best,
> Johann
> 
> Michael Droettboom wrote:
>> The axes3d stuff is not currently working on the SVN trunk.  You 
>> probably want to use 0.91.2 or the v0_91_maint branch in SVN instead.
>>
>> Cheers,
>> Mike
>>
>> Johann Cohen-Tanugi wrote:
>>> hello,
>>> thanks for answering. I actually fail with the import :
>>> In [1]: from matplotlib import axes3d
>>> --------------------------------------------------------------------------- 
>>>
>>> ImportError                               Traceback (most recent call 
>>> last)
>>>
>>> /home/cohen/bstw/<ipython console> in <module>()
>>>
>>> /usr/lib/python2.5/site-packages/matplotlib/axes3d.py in <module>()
>>>      14 from axes import Axes
>>>      15 import cbook
>>> ---> 16 from transforms import unit_bbox
>>>      17
>>>      18 import numpy as npy
>>>
>>> ImportError: cannot import name unit_bbox
>>>
>>> any idea?
>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Sun, 27 Jan 2008 22:18:00 +0000
>>>> From: "Neil Crighton" <nei...@gm...>
>>>> Subject: Re: [Matplotlib-users] plotting a series of 3D points and
>>>>     picker=True and 3D
>>>> To: mat...@li...
>>>> Message-ID:
>>>>     <637...@ma...>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> I think scatter3D does what you want:
>>>>
>>>> from matplotlib import axes3d
>>>> import pylab as pl
>>>> fig = pl.figure()
>>>> ax = axes3d.Axes3D(fig)
>>>> ax.scatter3D(data[:,0],data[:,1],data[:,2])
>>>> ax.set_xlabel('X value')
>>>> ax.set_ylabel('Y value')
>>>> ax.set_zlabel('Z value')
>>>> pl.show()
>>>>
>>>> You could also change the colour and size of each point based on other
>>>> array values:
>>>>
>>>> col = ax.scatter3D(data[:,0], data[:,1], data[:,2], c=data[:,3],
>>>> cmap=pl.cm.jet, s=data[:,4])
>>>> cbar = fig.colorbar(col,shrink=0.9,extend='both')
>>>> cbar.ax.set_ylabel('axis 3 data values')
>>>>
>>>> Pretty nifty.
>>>>
>>>> Neil
>>>>
>>>>  
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> 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-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>

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

Hi,

I have problem setting the axis limits when using a twinx plot. I assume 
it should be possible to set both x-axis limits after a pylab.twinx() 
call by issuing only one call to pylab.axis.

The attached tries to plot the same figure in two different ways the 
first way ends up with different x axis limits for the two plots. The 
second shows my workaround.

/Jörgen

Hi,

I think there is a bug in the pdf backend (png-files save ok) that makes 
plots crash when they contain a marker.

The attached script crashes on the last savefig. I have also attached a 
traceback.

I run matplotlib-svn-4904 on windows with python 2.4

/Jörgen

All,

The polar plot function ignores unitized data units in the v0.91-maint branch, I have yet to test it with the main branch.

Currently the xaxis and yaxis manage the unit conversion, but since a PolarAxes does not have and x and y Axis object there is
nothing to do the conversion and it gets skipped, one possibility is to have the PolarAxes manage a pair of converters for the
'theta' and 'r' axes.

I plan to really test out the main branch later this month and will give feedback if this exists in the main branch.

--James Evans

On Sun, Jan 27, 2008 at 11:43:16AM -0500, Darren Dale wrote:
> He also asked if it would be a good idea to render multiple figures into a tab 
> widget instead of creating multiple windows. Its an interesting idea, but 
> since the size of each figure may vary, it would mean each figure would have 
> to be rendered into a scrollable area. That might be a useful thing to do in 
> general, because we could then render figures that are larger than the 
> screen, but then we would need a new way to change the size of the canvas 
> because it wouldn't be coupled with the size of the window like it is now. 
> Maybe this is too disruptive a change.

In most cases the window containing a figure will be resizable, and the
graph will adjust itself accordingly.  Rendering onto a scrollable canvas
wouldn't be very useful because you see the data without seeing the axes, 
which is probably not what you want.

What is more of a concern is whether you want to see two figures at 
once (side by side) or whether you want to focus in on one figure to 
the exclusion of the others.  Even for the same dataset, you will want 
to switch between these modes of viewing.  This would seem to require 
a notion of 'figure groups' in the pylab interface to control which 
window the figure would be created in, combined with eclipse-like 
'tearable tabs' so you can rearrange the figures however you want.

   - Paul

> He also asked if it would be a good idea to render multiple figures into a tab 
> widget instead of creating multiple windows. Its an interesting idea, but 
> since the size of each figure may vary, it would mean each figure would have 
> to be rendered into a scrollable area. That might be a useful thing to do in 
> general, because we could then render figures that are larger than the 
> screen, but then we would need a new way to change the size of the canvas 
> because it wouldn't be coupled with the size of the window like it is now. 

True. I would wire the + and - keys to zooming actions that preserve the
aspect ratio, which I'd take to be the same as the aspect ratio of the
"host" window, even if there are scrollbars. This decoupling of aspect
ratio and resolution seems rather natural to me, from a user interaction
point of view.

-- O.L.

On Sunday 27 January 2008 11:43:16 am Darren Dale wrote:
> Hi Martin,
>
> On Sunday 27 January 2008 8:51:37 am Martin Teichmann wrote:
> > Some months ago, I proposed some improvements of the Qt4 backend,
> > especially using the Qt4 toolbar instead of writing our own hand-coded
> > toolbar, amongst other detailed changes. I was told that was bad timing,
> > as a new release was about to come out, and the project was in frozen. I
> > promised to come back, and here I am. All the details, including the
> > patches, can be found at the sourceforge patch request site, patch
> > request no 1828848 "Qt4 backend improvement",
> > https://sourceforge.net/tracker/
> > ?func=detail&atid=560722&aid=1828848&group_id=80706
> >
> > So, what do yall think about that, and is there someone willing to apply
> > this patch?
>
> Thank you for reminding me about this.
>
> Martin made some nice improvements for the qt4 backend using Qt4's native
> toolbars and status bars. There are a couple cosmetic changes in the pylab
> interface: the toolbar is a dock widget which appears at the top of the
> window by default, and the cursor coordinates are rendered in the status
> bar. But the widget still behaves the same way when embedded in another
> application. Nice work, Martin.
>
> He also asked if it would be a good idea to render multiple figures into a
> tab widget instead of creating multiple windows. Its an interesting idea,
> but since the size of each figure may vary, it would mean each figure would
> have to be rendered into a scrollable area. That might be a useful thing to
> do in general, because we could then render figures that are larger than
> the screen, but then we would need a new way to change the size of the
> canvas because it wouldn't be coupled with the size of the window like it
> is now. Maybe this is too disruptive a change.

I forgot to mention, I committed the patch to svn.

Hi Martin,

On Sunday 27 January 2008 8:51:37 am Martin Teichmann wrote:
> Some months ago, I proposed some improvements of the Qt4 backend,
> especially using the Qt4 toolbar instead of writing our own hand-coded
> toolbar, amongst other detailed changes. I was told that was bad timing, as
> a new release was about to come out, and the project was in frozen. I
> promised to come back, and here I am. All the details, including the
> patches, can be found at the sourceforge patch request site, patch request
> no 1828848 "Qt4 backend improvement",
> https://sourceforge.net/tracker/
> ?func=detail&atid=560722&aid=1828848&group_id=80706
>
> So, what do yall think about that, and is there someone willing to apply
> this patch?

Thank you for reminding me about this.

Martin made some nice improvements for the qt4 backend using Qt4's native 
toolbars and status bars. There are a couple cosmetic changes in the pylab 
interface: the toolbar is a dock widget which appears at the top of the 
window by default, and the cursor coordinates are rendered in the status bar. 
But the widget still behaves the same way when embedded in another 
application. Nice work, Martin.

He also asked if it would be a good idea to render multiple figures into a tab 
widget instead of creating multiple windows. Its an interesting idea, but 
since the size of each figure may vary, it would mean each figure would have 
to be rendered into a scrollable area. That might be a useful thing to do in 
general, because we could then render figures that are larger than the 
screen, but then we would need a new way to change the size of the canvas 
because it wouldn't be coupled with the size of the window like it is now. 
Maybe this is too disruptive a change.

Darren

Hi,

Some months ago, I proposed some improvements of the Qt4 backend, especially
using the Qt4 toolbar instead of writing our own hand-coded toolbar, amongst
other detailed changes. I was told that was bad timing, as a new release was 
about to come out, and the project was in frozen. I promised to come back, and 
here I am. All the details, including the patches, can be found at the 
sourceforge patch request site, patch request no 1828848 "Qt4 backend 
improvement", 
https://sourceforge.net/tracker/
?func=detail&atid=560722&aid=1828848&group_id=80706

So, what do yall think about that, and is there someone willing to apply this 
patch?

Cheers

Martin

So I have a (slightly) new plot type I would like to add to the 
matplotlib codebase, and I'd like to ask A) if people would be 
interested in the patch and B) what the best way to implement it would be.

I am currently calling the plot type "pcontourf"--it's essentially a 
pcolor, but instead of a continuous color spectra of value, it plots 
discrete levels of data like contourf does.  I find this kind of plot 
useful for model output--it displays the model grid, and also emphasizes 
data transitions, for example, between the negative and positive areas 
of a plot, better than pcolor.  Essentially it is just a contourf 
wrapper that, instead of calling contourf with values at the 'center' of 
a grid cell, calls contourf with points at the edges of the grid cell so 
you end up with rectangular areas.

If someone is actually interested in clean this up and put it into svn, 
my next question is where in the codebase would be the best place to put 
it so I can make a clean diff file?  pyplot.py?  I don't quite 
understand how the matplotlib module hierarchy works.

Jordan

Manuel Metz wrote:
> Hi,
> 
> might I ask again whether anyone can attend to update the doc-string of 
> the scatter function ?

Done, both in the trunk and the maintenance branch.  Thanks for the update.

Eric

Manuel Metz wrote:
> Hi,
> 
> might I ask again whether anyone can attend to update the doc-string of 
> the scatter function ?

Looks good to me so I tried to do it, but couldn't connect to the 
server.  I will try again later today.

Eric

Hi,

might I ask again whether anyone can attend to update the doc-string of 
the scatter function ?

Manuel

Manuel Metz wrote:
> There was a question on the matplotlib-users list about symbols in 
[snip]
> Btw: shouldn't the 
> "verts" keyword be removed, since marker=(verts,0) is equivalent ?

On Jan 19, 2008 7:21 AM, Chris Friedl <cfr...@gm...> wrote:
> Jeez ... OK, a second try without mentioning the word. (to evade the spam
> filters).
>
> Browsing the matplotlib wiki topical software page tonight I stumbled across
> a link to "that drug that men can use when they need some help below the
> waistline .... starts with the letter V"  placed next to a topic link. A
> page search revealed many more of the same. I hope whoever manages this page
> can clean it up. (btw - thanks for an awesome python package). cya


Could you post a link?  I haven't found this in the places I've looked.

JDH

I wonder if Eric's changes (which are quite different) fix David's 
scalar mask problem...?

Cheers,
Mike

Eric Firing wrote:
> Michael Droettboom wrote:
>> David Huard wrote:
>>> Hi,
>>>
>>> calling show returns the following error using the numpy maskedarray 
>>> branch. The figure is a quiver plot on a basemap instance.
>>
>> I haven't personally done any testing with the maskedarray branch 
>> myself, though I know Eric Firing has done a little.
> 
> I'm using it routinely, but have not been doing any great variety of 
> plots.  I might have hit that bug a few days ago, but if I did I worked 
> around it instead of investigating.
> 
>>
>>> /usr/local/lib64/python2.5/site-packages/matplotlib/path.pyc in 
>>> __init__(self, vertices, codes)
>>>     118                         len(vertices), self.code_type)
>>>     119                     codes[0] = self.MOVETO
>>> --> 120                 vertices = ma.compress(npy.invert(mask1d), 
>>> vertices, 0)
>>>     121                 vertices = npy.asarray(vertices)
>>>     122                 codes = 
>>> npy.where(npy.concatenate((mask1d[-1:], mask1d[:-1])),
>>>
>>> AttributeError: 'module' object has no attribute 'compress'
> I reported the absence, and Stefan van der Walt has already put a 
> version in svn.
> 
> The whole block of code can be streamlined and sped up a bit; I will 
> commit a change to do that.
> 
> Eric

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

Michael Droettboom wrote:
> David Huard wrote:
>> Hi,
>>
>> calling show returns the following error using the numpy maskedarray 
>> branch. The figure is a quiver plot on a basemap instance.
> 
> I haven't personally done any testing with the maskedarray branch 
> myself, though I know Eric Firing has done a little.

I'm using it routinely, but have not been doing any great variety of 
plots.  I might have hit that bug a few days ago, but if I did I worked 
around it instead of investigating.

> 
>> /usr/local/lib64/python2.5/site-packages/matplotlib/path.pyc in 
>> __init__(self, vertices, codes)
>>     118                         len(vertices), self.code_type)
>>     119                     codes[0] = self.MOVETO
>> --> 120                 vertices = ma.compress(npy.invert(mask1d), 
>> vertices, 0)
>>     121                 vertices = npy.asarray(vertices)
>>     122                 codes = npy.where(npy.concatenate((mask1d[-1:], 
>> mask1d[:-1])),
>>
>> AttributeError: 'module' object has no attribute 'compress'
I reported the absence, and Stefan van der Walt has already put a 
version in svn.

The whole block of code can be streamlined and sped up a bit; I will 
commit a change to do that.

Eric

David Huard wrote:
> Hi,
> 
> calling show returns the following error using the numpy maskedarray 
> branch. The figure is a quiver plot on a basemap instance.

I haven't personally done any testing with the maskedarray branch 
myself, though I know Eric Firing has done a little.

> /usr/local/lib64/python2.5/site-packages/matplotlib/path.pyc in 
> __init__(self, vertices, codes)
>     118                         len(vertices), self.code_type)
>     119                     codes[0] = self.MOVETO
> --> 120                 vertices = ma.compress(npy.invert(mask1d), 
> vertices, 0)
>     121                 vertices = npy.asarray(vertices)
>     122                 codes = npy.where(npy.concatenate((mask1d[-1:], 
> mask1d[:-1])),
> 
> AttributeError: 'module' object has no attribute 'compress'

This seems to work if you change it to npy.compress -- for both the 
"default" ma and the maskedarray branch.  I'll go ahead and commit this 
change, though there may be performance implications.

Cheers,
Mike

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

Hi,

calling show returns the following error using the numpy maskedarray branch.
The figure is a quiver plot on a basemap instance.

/usr/local/lib64/python2.5/site-packages/matplotlib/figure.pyc in draw(self,
renderer)
    696
    697         # render the axes
--> 698         for a in self.axes: a.draw(renderer)
    699
    700         # render the figure text

/usr/local/lib64/python2.5/site-packages/matplotlib/axes.pyc in draw(self,
renderer, inframe)
   1396
   1397         for zorder, i, a in dsu:
-> 1398             a.draw(renderer)
   1399
   1400         renderer.close_group('axes')

/usr/local/lib64/python2.5/site-packages/matplotlib/quiver.pyc in draw(self,
renderer)
    335         if self._new_UV:
    336             verts = self._make_verts(self.U, self.V)
--> 337             self.set_verts(verts)
    338             self._new_UV = False
    339         collections.PolyCollection.draw(self, renderer)

/usr/local/lib64/python2.5/site-packages/matplotlib/collections.pyc in
set_verts(self, verts)
    479     def set_verts(self, verts):
    480         '''This allows one to delay initialization of the
vertices.'''
--> 481         self._paths = [mpath.Path(v) for v in verts]
    482
    483     def get_paths(self):

/usr/local/lib64/python2.5/site-packages/matplotlib/path.pyc in
__init__(self, vertices, codes)
    118                         len(vertices), self.code_type)
    119                     codes[0] = self.MOVETO
--> 120                 vertices = ma.compress(npy.invert(mask1d), vertices,
0)
    121                 vertices = npy.asarray(vertices)
    122                 codes = npy.where(npy.concatenate((mask1d[-1:],
mask1d[:-1])),

AttributeError: 'module' object has no attribute 'compress'



Cheers,

David

Michael Droettboom skrev:
> Interesting.
> 
> Perhaps anything that throws an exception in the FT2Font constructor 
> (which a bad font or a missing font would both do), is throwing off the 
> reference count for the object and failing that assertion, rather than 
> passing the exception back to Python.  Only a theory.
> 
> What version of gcc are you using under mingw?
> 
I'm using gcc 3.4.5
/Jörgen

Interesting.

Perhaps anything that throws an exception in the FT2Font constructor 
(which a bad font or a missing font would both do), is throwing off the 
reference count for the object and failing that assertion, rather than 
passing the exception back to Python.  Only a theory.

What version of gcc are you using under mingw?

Cheers,
Mike

Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> It's possible -- the version of freetype in the win32_static.tar.gz 
>> package is 2.1.7.  I have 2.1.9 on my (working) Linux box.  Perhaps 
>> something between those point releases fixes this bug.  But it could 
>> be a lot of other things, too.
>>
>> I'm going to file a bug for this so it doesn't get lost.
>>
> 
> Great, in the meantime I'll just remove the orlando font, I don't use it 
> anyway.
> 
> I have also stumbled on another font related crash. If I run the 
> examples/font_table_ttf.py with a non-existing font name I get the 
> crash. I have attached the output with debug-annoying set. As you can 
> see from the output the crash message is the same.
> 
> /Jörgen
> 

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

Michael Droettboom skrev:
> It's possible -- the version of freetype in the win32_static.tar.gz 
> package is 2.1.7.  I have 2.1.9 on my (working) Linux box.  Perhaps 
> something between those point releases fixes this bug.  But it could be 
> a lot of other things, too.
> 
> I'm going to file a bug for this so it doesn't get lost.
> 

Great, in the meantime I'll just remove the orlando font, I don't use it 
anyway.

I have also stumbled on another font related crash. If I run the 
examples/font_table_ttf.py with a non-existing font name I get the 
crash. I have attached the output with debug-annoying set. As you can 
see from the output the crash message is the same.

/Jörgen

Yep.  I fixed that bug in the wrong way -- it needs to ignore existing 
limits on the first line, and then subsequently not ignore.  I think I 
have it working now with both your old example and this one.  (r4890)

Cheers,
Mike

Darren Dale wrote:
> I noticed another bug:
> 
> l1,=plot([1,2,3,4])
> l2,=plot([2,3,4,5])
> l1.set_ydata([3,4,5,6])
> l2.set_ydata([5,6,7,8])
> gca().relim()
> gca().autoscale_view()
> draw()
> 
> This sets the y limits to 5 and 8, rather than 3 and 8. Even if I change only 
> the ydata for l1, the limits are still calculated according to l2.
> 
> Darren
> 
> On Tuesday 22 January 2008 10:11:48 am Darren Dale wrote:
>> That did it, thanks Mike.
>>
>> On Tuesday 22 January 2008 08:09:37 am Michael Droettboom wrote:
>>> Thanks.  The "ignore existing data" flag was not getting set properly.
>>>
>>> Fixed in r4884.  Please let me know how that works for you.
>>>
>>> Cheers,
>>> Mike
>>>
>>> Darren Dale wrote:
>>>> In the trunk, I noticed that relim() followed by autoscale_view() do
>>>> not have the same behavior as they did with the old transforms branch.
>>>> For example:
>>>>
>>>> l,=plot([1,2,3])
>>>> l.set_ydata([4,5,6])
>>>> gca().relim()
>>>> gca().autoscale_view()
>>>> draw()
>>>>
>>>> used to produce the same output as
>>>>
>>>> plot([4,5,6])
>>>>
>>>> but now it is equivalent to
>>>>
>>>> plot([4,5,6])
>>>> ylim(1,6)
>>>>
>>>> Darren
>>>>
>>>> -----------------------------------------------------------------------
>>>> -- 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 noticed another bug:

l1,=plot([1,2,3,4])
l2,=plot([2,3,4,5])
l1.set_ydata([3,4,5,6])
l2.set_ydata([5,6,7,8])
gca().relim()
gca().autoscale_view()
draw()

This sets the y limits to 5 and 8, rather than 3 and 8. Even if I change only 
the ydata for l1, the limits are still calculated according to l2.

Darren

On Tuesday 22 January 2008 10:11:48 am Darren Dale wrote:
> That did it, thanks Mike.
>
> On Tuesday 22 January 2008 08:09:37 am Michael Droettboom wrote:
> > Thanks.  The "ignore existing data" flag was not getting set properly.
> >
> > Fixed in r4884.  Please let me know how that works for you.
> >
> > Cheers,
> > Mike
> >
> > Darren Dale wrote:
> > > In the trunk, I noticed that relim() followed by autoscale_view() do
> > > not have the same behavior as they did with the old transforms branch.
> > > For example:
> > >
> > > l,=plot([1,2,3])
> > > l.set_ydata([4,5,6])
> > > gca().relim()
> > > gca().autoscale_view()
> > > draw()
> > >
> > > used to produce the same output as
> > >
> > > plot([4,5,6])
> > >
> > > but now it is equivalent to
> > >
> > > plot([4,5,6])
> > > ylim(1,6)
> > >
> > > Darren
> > >
> > > -----------------------------------------------------------------------
> > >-- 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