matplotlib-devel Mailing List for matplotlib

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

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.

Cheers,
Mike

Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> Thanks.  Unfortunately, I'm not able to reproduce any problems with 
>> the font on Linux (see attached).  I suspect the problem may be 
>> Windows-specific, but I have no way of knowing at the moment.  I'll 
>> have to try this at home (no Windows at work), or maybe one of the 
>> other Windows gurus on this list wants to take it up.
>>
> 
> Could it be that the static compile libraries needs to be updated? I 
> rely on the precompiled versions.
> 
> /Jörgen

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