matplotlib-devel Mailing List for matplotlib (Page 8)

I just noticed that the blit API in GTK* is causing a seg fault on my
desktop. Can anyone confirm this on another system. Has anyone made
any changes that you are aware of that might have affected this part
of the code? I am seeing problems with
examples/animation_blit.py and examples/poly_editor.py so it looks
like anything using the copy region / blit API in GTK is broken, at
least on my system. tkagg is working fine, so it is probably not a
problem on the agg side, and GTK and GTKAgg are both affected. I
don't use this functionality often, so I don't know how long the
problem has persisted. In fact, it is possible I have never tested it
on this system (solaris x86 with pygtk 2.6)
JDH

Some time ago, I talked about enabling mpl donations to raise money
for development. My goal is to promote donations with some reasonably
prominent info on the web page, and some emails as well, to raise
enough to fund a sprint. This is the blurb I wrote for the
donations page:
 All donations to matplotlib will be used to fund matplotlib
development. Our primary goal
 is to raise enough funds to finance a developer sprint to work on
new features, better
 installers and better documentation.
To enable donations, all project admins must opt in. In addition to
me, those are Charlie, Darren, Eric, Jeff and Michael and the opt in
page is at
http://sourceforge.net/project/admin/donations.php?group_id=80706.
The donations are set up to go into my paypal account, but if one of
you wants to create a dedicated account to handle these, that is fine
by me.
If anyone has concerns or suggestions, let me know. We get a fair
amount of web traffic and maybe we can raise enough money to do
something useful. I have no experience with donations so I have no
idea whether this is feasible, but it seems like it is worth a shot.
JDH

Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> Thanks for finding this. It was an x,y reversal indexing the mesh 
>> array. Fixed in r4565.
>>
>> Cheers,
>> Mike
>>
>> Jeff Whitaker wrote:
>>>
>>> Hi Michael: I've been testing basemap with the transforms branch. 
>>> All the examples now run, but the ones that use pcolormesh don't 
>>> work correctly. I've attached an example. In the trunk, using 
>>> either pcolor or pcolormesh produce an identical plot. In the 
>>> transforms branch, using pcolor produces the correct plot, but using 
>>> pcolormesh seems to scramble the image.
>>>
>>> -Jeff
>>>
>>
> OK - since you fixed that one so fast, here's another one! Seems like 
> images don't quite fill up the entire axes - running this script with 
> the transforms branch you'll see a white strip around the top and 
> right side of the image.
>
> -Jeff
>
> P.S. the data this script needs is in the basemap examples directory.
>
Michael: And one more - contourf will die if you there are no contours 
at the requested levels. The error message looks like this:
Traceback (most recent call last):
 File "plotprecip.py", line 52, in <module>
 cs = m.contourf(x,y,data,clevs,cmap=cm.s3pcpn)
 File "/Users/jsw/lib/python/matplotlib/toolkits/basemap/basemap.py", 
line 2425, in contourf
 CS = ax.contourf(x,y,data,*args,**kwargs)
 File "/Users/jsw/lib/python/matplotlib/axes.py", line 5017, in contourf
 return mcontour.ContourSet(self, *args, **kwargs)
 File "/Users/jsw/lib/python/matplotlib/contour.py", line 460, in __init__
 self.ax.add_collection(col)
 File "/Users/jsw/lib/python/matplotlib/axes.py", line 1140, in 
add_collection
 self.update_datalim(collection.get_datalim(self.transData))
 File "/Users/jsw/lib/python/matplotlib/collections.py", line 142, in 
get_datalim
 offsets, transOffset.frozen())
 File "/Users/jsw/lib/python/matplotlib/path.py", line 481, in 
get_path_collection_extents
 raise ValueError("No paths provided")
To trigger this, try running the plotprecip.py basemap example.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Michael Droettboom wrote:
> Thanks for finding this. It was an x,y reversal indexing the mesh 
> array. Fixed in r4565.
>
> Cheers,
> Mike
>
> Jeff Whitaker wrote:
>>
>> Hi Michael: I've been testing basemap with the transforms branch. 
>> All the examples now run, but the ones that use pcolormesh don't work 
>> correctly. I've attached an example. In the trunk, using either 
>> pcolor or pcolormesh produce an identical plot. In the transforms 
>> branch, using pcolor produces the correct plot, but using pcolormesh 
>> seems to scramble the image.
>>
>> -Jeff
>>
>
OK - since you fixed that one so fast, here's another one! Seems like 
images don't quite fill up the entire axes - running this script with 
the transforms branch you'll see a white strip around the top and right 
side of the image.
-Jeff
P.S. the data this script needs is in the basemap examples directory.
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Thanks for finding this. It was an x,y reversal indexing the mesh 
array. Fixed in r4565.
Cheers,
Mike
Jeff Whitaker wrote:
> 
> Hi Michael: I've been testing basemap with the transforms branch. All 
> the examples now run, but the ones that use pcolormesh don't work 
> correctly. I've attached an example. In the trunk, using either 
> pcolor or pcolormesh produce an identical plot. In the transforms 
> branch, using pcolor produces the correct plot, but using pcolormesh 
> seems to scramble the image.
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Michael: I've been testing basemap with the transforms branch. All 
the examples now run, but the ones that use pcolormesh don't work 
correctly. I've attached an example. In the trunk, using either 
pcolor or pcolormesh produce an identical plot. In the transforms 
branch, using pcolor produces the correct plot, but using pcolormesh 
seems to scramble the image.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Dec 3, 2007 9:10 AM, Michael Droettboom <md...@st...> wrote:
> I'm +1 on just removing the paragraph altogether. It only applies if
> someone did:
>
> python setup.py install --install-data=/some/weird/place
Yes, it should be removed. It predates the move of the data to
mpl-data in the matplotlib installation directory, and isn't really
needed anymore.
JDH

[Brought conversation back to matplotlib-devel list].
Mario Oschwald wrote:
> Hello
> 
> Michael Droettboom wrote:
>> Mario Oschwald wrote:
>>> This passage in the INSTALL file is misleading:
>>>
>>> Note that if you install matplotlib anywhere other than the default
>>> location, you will need to set the MATPLOTLIBDATA environment
>>> variable to point to the install base dir.
>>>
>> Was that necessary? I routinely install matplotlib to a non-standard
>> location, and have never set MATPLOTLIBDATA. If MATPLOTLIBDATA is not
>> set, it appears that matplotlib will look for the "mpl-data" directory
>> underneath the main matplotlib directory. (Which in your case is
>> /home/mo/mpl/lib/python2.4/site-packages/matplotlib/). I'm curious if
>> you get errors without specifying MATPLOTLIBDATA, and what the error is.
>> Perhaps the INSTALL docs should be updated to clarify that you only
>> need this if you install the data in a non-standard place *relative to*
>> the source code...
> 
> You are right - if I unset that variable the mpl-data directory is found
> automagically ;-) Stupid me for reading INSTALL files :-). That passage
> should definitely be updated to reflect that behaviour.
I'm +1 on just removing the paragraph altogether. It only applies if 
someone did:
	python setup.py install --install-data=/some/weird/place
Is that a common enough use case to confuse the matter? (Obviously 
MATPLOTLIBDATA should be mentioned elsewhere in the docs, but it seems 
too unimportant for the main INSTALL file.)
>>> Secondly this passage in matplotlib/mathtext.py
>>>
>>> 544 if cached_font is None:
>>> 545 try:
>>> 546 font = FT2Font(basename)
>>> 547 except RuntimeError:
>>> 548 return None
>> The intent of this code is "if the font isn't found, use a dummy
>> character." Since there are so many different font configurations, and
>> they're all a little brittle, I thought it better to warn and fail
>> gracefully than to fail completely (and users can always use the "-We"
>> to fail on warnings.) Otherwise, we run the risk of having some plots
>> not working on all installations (because of font limitations, etc.)
>>
>> However, the implementation isn't quite right because not all callers
>> expect and deal with the 'None' result correctly. I have fixed this in
>> -r4557. Can you please send a script that triggers this error, so I can
>> ensure my patch corrects for it?
> 
> OK, I can understand that. If you set the MATPLOTLIBDATA environment variable
> to some wrong directory and the font file is not found it crashes right here
> when trying to access the returned None object without a prior check:
> 
> 669 if symbol_name is None:
> 670 warn("Unrecognized symbol '%s'. Substituting with a dummy symbol."
> 671 % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
> 672 fontname = 'it'
> 673 cached_font = self._get_font(fontname)
> 674 num = 0x3F # currency character, for lack of anything better
> ->675 gid = cached_font.charmap[num]
> 
> Snipped stacktrace below:
> /home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py:671: MathTextWarning: Unrecognized symbol 'e'. Substituting with a dummy symbol.
> % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
> IN FONTMAP
> ---lots of parsing---
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 2243, in symbol
> char = Char(c, self.get_state())
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 1211, in __init__
> self._update_metrics()
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 1217, in _update_metrics
> metrics = self._metrics = self.font_output.get_metrics(
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 464, in get_metrics
> info = self._get_info(font, font_class, sym, fontsize, dpi)
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 567, in _get_info
> cached_font, num, symbol_name, fontsize, slanted = \
> File "/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mathtext.py", line 675, in _get_glyph
> gid = cached_font.charmap[num]
> AttributeError: 'NoneType' object has no attribute 'charmap'
> 
> You can trigger it with the attached script, provided you set the MATPLOTLIBDATA to something
> bad or remove the font file all together.
Thanks. r4557 fixes this. There will probably be another bugfix 
release (0.91.2 or something) in the near future that includes this change.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Mario Oschwald wrote:
> Hello,
> 
> first let me thank you for your excellent software - I think
> it is just wonderful and very pleasant to use.
> 
> Two small things came up when I installed 0.91.1 into
> my home directory (I didn't want to mess with the debian
> packages since they are usually very fast in updating them)
> 
> This passage in the INSTALL file is misleading:
> 
> Note that if you install matplotlib anywhere other than the default
> location, you will need to set the MATPLOTLIBDATA environment
> variable to point to the install base dir.
> 
> 
> Instead of setting MATPLOTLIBDATA to the base dir I specified
> with setup.py install --prefix /home/mo/mpl I had to set
> it to
> 
> /home/mo/mpl/lib/python2.4/site-packages/matplotlib/mpl-data/
> 
> for mathtext to find its fonts.
Was that necessary? I routinely install matplotlib to a non-standard 
location, and have never set MATPLOTLIBDATA. If MATPLOTLIBDATA is not 
set, it appears that matplotlib will look for the "mpl-data" directory 
underneath the main matplotlib directory. (Which in your case is 
/home/mo/mpl/lib/python2.4/site-packages/matplotlib/). I'm curious if 
you get errors without specifying MATPLOTLIBDATA, and what the error is. 
 Perhaps the INSTALL docs should be updated to clarify that you only 
need this if you install the data in a non-standard place *relative to* 
the source code...
> Secondly this passage in matplotlib/mathtext.py
> 
> 544 if cached_font is None:
> 545 try:
> 546 font = FT2Font(basename)
> 547 except RuntimeError:
> 548 return None
The intent of this code is "if the font isn't found, use a dummy 
character." Since there are so many different font configurations, and 
they're all a little brittle, I thought it better to warn and fail 
gracefully than to fail completely (and users can always use the "-We" 
to fail on warnings.) Otherwise, we run the risk of having some plots 
not working on all installations (because of font limitations, etc.)
However, the implementation isn't quite right because not all callers 
expect and deal with the 'None' result correctly. I have fixed this in 
-r4557. Can you please send a script that triggers this error, so I can 
ensure my patch corrects for it?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Bojan Nikolic wrote:
> Dear All,
> 
> I've placed some very simple colour bar patches at :
> 
> https://code.launchpad.net/~bojan-bnikolic/python2.4-matplotlib/bn-colourbar-patches
> 
> They make default shrink of the colour bar such that it is the same size
> as the image part of the figure. Merge if/as you see fit.
> 
> Best,
> Bojan
> 
Bojan,
Thank you for the suggested patches. Unfortunately, however, they do 
not in general solve the problem of size mismatch between the colorbar 
and the corresponding axes, as you will see if you try a variety of axes 
dimensions and aspect ratio settings. Your patch is equivalent to 
setting the default shrink to 0.8 instead of 1.0, and I agree that this 
is a better default. I did not use it originally simply for the sake of 
backwards and Matlab compatibility. I suspect that making the change 
will please more people than it will upset, though, so I will try it in 
svn after the switch to the transforms branch. I don't see any point in 
making little changes like this right now, when we are trying to 
stabilize a last release before that switch. Everyone has lived with 
the present default for a long time, and a few more weeks won't hurt.
A more general solution to the size-matching problem may emerge after we 
switch to the transforms branch, but to my mind it is fairly low priority.
Eric

Hello,
first let me thank you for your excellent software - I think
it is just wonderful and very pleasant to use.
Two small things came up when I installed 0.91.1 into
my home directory (I didn't want to mess with the debian
packages since they are usually very fast in updating them)
This passage in the INSTALL file is misleading:
Note that if you install matplotlib anywhere other than the default
location, you will need to set the MATPLOTLIBDATA environment
variable to point to the install base dir.
Instead of setting MATPLOTLIBDATA to the base dir I specified
with setup.py install --prefix /home/mo/mpl I had to set
it to
/home/mo/mpl/lib/python2.4/site-packages/matplotlib/mpl-data/
for mathtext to find its fonts.
Secondly this passage in matplotlib/mathtext.py
 544 if cached_font is None:
 545 try:
 546 font = FT2Font(basename)
 547 except RuntimeError:
 548 return None
Where an unfound font file is not reported but rather a None font object
is returned just causes a Null pointer exception to be raised very
shortly afterwards without the important info as to the
real reason. Maybe the RunTimeError should just be raised as is
or handled in a more informative manner?
Thanks again and sorry for my nitpicking,
Mario Oschwald

On Dec 1, 2007 8:15 AM, Bojan Nikolic <bo...@bn...> wrote:
>
> Dear All,
>
> I've placed some very simple colour bar patches at :
>
> https://code.launchpad.net/~bojan-bnikolic/python2.4-matplotlib/bn-colourbar-patches
>
> They make default shrink of the colour bar such that it is the same size
> as the image part of the figure. Merge if/as you see fit.
Eric, since you wrote the shrink code, I'll leave this one up to you...
JDH

On Dec 1, 2007 12:03 PM, Charlie Moad <cw...@gm...> wrote:
> Sorry for the delay. Apparently at some point the mingw compiler
> became default, and it was giving me problems since I was trying to
> build with the VS libpng and freetype. All binaries are posted now.
> Jon, you should probably send the announcement since I am a little out
> of touch with the changes since 0.90.
OK, I'll do this on Monday when more people are working and thinking
about python. Thanks again for the build!
JDH

 Sorry for the delay. Apparently at some point the mingw compiler
became default, and it was giving me problems since I was trying to
build with the VS libpng and freetype. All binaries are posted now.
Jon, you should probably send the announcement since I am a little out
of touch with the changes since 0.90.
- Charlie
On Nov 29, 2007 8:45 PM, Charlie Moad <cw...@gm...> wrote:
> So here's my plan. I just got an iMac a few weeks ago and I had to
> spend a little time getting parallels setup with VS2003... yada yada
> yada. I plan on cutting a 0.91.1 release tomorrow followed shortly by
> windows and mac builds. Hopefully nothing radical has snuck into the
> svn tree since the 0.91.0 build.
>
> - Charlie
>
>
> On Nov 28, 2007 8:32 AM, Charlie Moad <cw...@gm...> wrote:
> > My 1 year old only let me get the source release pushed last night and
> > build the mac release. I'll try to get the windows builds posted
> > tonight.
> >
> >
> > On Nov 28, 2007 8:23 AM, Rob Hetland <he...@ta...> wrote:
> > >
> > > On Nov 28, 2007, at 12:03 AM, John Hunter wrote:
> > >
> > >
> > > > I think native tcl/tk is preferable, but this is not a terribly
> > > > informed opinion. If you don't hear otherwise from someone else, just
> > > > build under that assumption.
> > >
> > > I am still having issues with Tk on my machine (native? version
> > > 8.4.7). In particular, event.key does not register (which I use
> > > quite a bit in my interactive grid generation tools). Not even the
> > > 'g' to toggle the grid. I also get an error when creating a figure
> > > instance:
> > >
> > > 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool():
> > > Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased
> > > with no pool in place - just leaking
> > > <matplotlib.figure.Figure instance at 0x711300>
> > >
> > > Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the
> > > latest svn.
> > >
> > > I don't think anyone else is experiencing this problem. I reported
> > > it earlier, and John said it works fine for him -- nobody else chimed
> > > in to say they had the same problem...
> > >
> > > I just wanted to be sure you all were aware of potential Tk problems
> > > before your release.
> > >
> > > -Rob
> > >
> > > ----
> > > Rob Hetland, Associate Professor
> > > Dept. of Oceanography, Texas A&M University
> > > http://pong.tamu.edu/~rob
> > > phone: 979-458-0096, fax: 979-845-6331
> > >
> > >
> > >
> >
>

Dear All,
I've placed some very simple colour bar patches at :
https://code.launchpad.net/~bojan-bnikolic/python2.4-matplotlib/bn-colourbar-patches
They make default shrink of the colour bar such that it is the same size
as the image part of the figure. Merge if/as you see fit.
Best,
Bojan
-- 
Bojan Nikolic