matplotlib-devel Mailing List for matplotlib

Marcin, 
> I have wx app with MPL plots embedded. There are two problems
> I noticed after upgrading wxPython to 2.6.1 and MPL to current
> CVS: When toolbar (i.e. NavigationToolbar2WX) has parent
> different then wx.Frame, (wx.Panel in my case), it crashes
> when clicking "Save" button. The problem is that wx.FileDialog
> has to have top level window as its parent. The workaround is
> eg. to set toolbar._parent=None (a dialog created with None
> parent window is given the application's top level window as
> parent)
I think it's a known feature of the Toolbars that they use a
Frame not a Panel, at least for the wx backend. It's hard for
me to get excited about this as I don't use the Toolbars, but if
you can send a patch that makes them work for a Panel, that's
fine with me.
> I haven't solved the second problem yet. It can be seen on
> simple_plot.py.. When I decrease window's size plot doesn't
> shrink like in GTK backend, and only part of the plot is
> visible. It used to work properly in older wx and MPL
> versions.
You didn't specify an OS, which probably means linux ;). I
don't see this problem on Windows or Mac, but haven't installed
wxPython 2.6.1 on linux yet.
--Matt

Hi,
I have wx app with MPL plots embedded. There are two problems I noticed
after upgrading wxPython to 2.6.1 and MPL to current CVS:
When toolbar (i.e. NavigationToolbar2WX) has parent different then wx.Fra=
me,
(wx.Panel in my case), it crashes when clicking "Save" button.
The problem is that wx.FileDialog has to have top level window as its par=
ent.
The workaround is eg. to set toolbar._parent=3DNone (a dialog created wi=
th
None parent window is given the application's top level window as parent)
I haven't solved the second problem yet. It can be seen on simple_plot.py=
.
When I decrease window's size plot doesn't shrink like in GTK backend,
and only part of the plot is visible. It used to work properly in older
wx and MPL versions.
Marcin
--=20
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr

I have been using matplotlib a few days now and think I it is great
but recently I have gotten hung up on a problem plotting negative
numbers.
I am trying to plot data where the y values are all negative. When I
do this I get the No positive data to plot error. I have tracked it
down to the following two line is
/matplotlib/ticker.py:
 if minpos<=3D0:=20
 raise RuntimeError('No positive data to plot')
It looks like for some reason Matplotlib wants positive values when it
does the axis scaling. I commented out the two lines and it works
like a charm now. My question is, do these two lines of code serve a
useful purpose. Does commenting them out break something else or is
this a change that can be incorporated back into the matplotlib
source?
Full stack trace=20
---> 33 splot.plot(x1, y1, "g", x2, y2, "r")
/home/tdennist/lib/python/matplotlib/axes.py in plot(self, *args, **kwargs)
 2524 lines.append(line)
 2525 lines =3D [line for line in lines] # consume the generator
-> 2526 self.autoscale_view()
 2527 return lines
 2528
/home/tdennist/lib/python/matplotlib/axes.py in autoscale_view(self)
 783
 784 locator =3D self.yaxis.get_major_locator()
--> 785 self.set_ylim(locator.autoscale())
 786
 787
/home/tdennist/lib/python/matplotlib/ticker.py in autoscale(self)
 819
 820 if minpos<=3D0:
--> 821 raise RuntimeError('No positive data to plot')
 822 if vmin<=3D0:
 823 vmin =3D minpos
RuntimeError: No positive data to plot
In [50]: exampleReturns.logHistogramPlot([1,2,3,4,0], 100)

On Thu, 2005年06月23日 at 10:58 -0600, Fernando Perez wrote:
> Nicholas Young wrote:
> > On Wed, 2005年06月22日 at 11:45 -0600, Fernando Perez wrote:
> > 
> >>os.environ['TEXMFOUTPUT'] = '/some/path'
> > 
> > 
> > According to the online docs
> > (http://docs.python.org/lib/os-procinfo.html) setting os.environ isn't
> > safe/available for all platforms. You can use the subprocess module to
> > set the environment of a subprocess under python 2.4 but I don't think
> > there's a simple way to do this and capture the output for earlier
> > versions.
> 
> Well, after reading that I get that os.environ _is_ writable everywhere, it's 
> just that it may leak memory in OSX/BSD. What's not always available is the 
> putenv() call, but python will find its way around it if needed.
To quote "If putenv() is not provided, this mapping may be passed to the
appropriate process-creation functions to cause child processes to use a
modified environment.". To me this implies that you have to pass
os.environ to a process-creation function supporting the env keyword
(os.execve, etc.) none of which seem to support capturing output. On
the other hand does anyone actually run mpl on a platform which doesn't
support putenv?
> Since this would be a once-only call, I think that leaking a few bytes is an 
> acceptable price to pay to prevent a crash if the user happens to be 
> positioned on a non-writable dir.
After reading an online copy of the freebsd man putenv it actually reads
"Successive calls to setenv() or putenv() assigning a differently sized
value to the same name will result in a memory leak." so setting this
once wouldn't be a problem.
So I was wrong and setting os.environ seems reasonable in this case -
but it seems sensible to be aware of the potential for causing problems
if anyone trys to get mpl working on an odd platform.
Nick

Nicholas Young wrote:
> On Wed, 2005年06月22日 at 11:45 -0600, Fernando Perez wrote:
> 
>>os.environ['TEXMFOUTPUT'] = '/some/path'
> 
> 
> According to the online docs
> (http://docs.python.org/lib/os-procinfo.html) setting os.environ isn't
> safe/available for all platforms. You can use the subprocess module to
> set the environment of a subprocess under python 2.4 but I don't think
> there's a simple way to do this and capture the output for earlier
> versions.
Well, after reading that I get that os.environ _is_ writable everywhere, it's 
just that it may leak memory in OSX/BSD. What's not always available is the 
putenv() call, but python will find its way around it if needed.
Since this would be a once-only call, I think that leaking a few bytes is an 
acceptable price to pay to prevent a crash if the user happens to be 
positioned on a non-writable dir.
Cheers,
f

Sorry for the long post, 2 things..
The first is that I am getting a compiler error on Solaris. This is
installing v0.80, I was wondering if anyone had seen this...
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:324:
error: `wmemcmp' undeclared (first use this function)
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:324:
error: (Each undeclared identifier is reported only once for each
function it 
appears in.)
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:
In static member function `static const wchar_t* 
std::char_traits<wchar_t>::find(const wchar_t*, size_t, const
wchar_t&)':
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:332:
error: invalid conversion from `const wchar_t*' to `wchar_t*'
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:332:
error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*,
wchar_t, 
size_t)'
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:
In static member function `static wchar_t* 
std::char_traits<wchar_t>::move(wchar_t*, const wchar_t*, size_t)':
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:336:
error: `wmemmove' undeclared (first use this function)
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:
In static member function `static wchar_t* 
std::char_traits<wchar_t>::copy(wchar_t*, const wchar_t*, size_t)':
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:340:
error: `wmemcpy' undeclared (first use this function)
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:
In static member function `static wchar_t* 
std::char_traits<wchar_t>::assign(wchar_t*, size_t, wchar_t)':
/work/net-local-b/sparc-sun-solaris2.8/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../include/c++/3.4.2/bits/char_traits.h:344:
error: `wmemset' undeclared (first use this function)
./CXX/Extensions.hxx: In constructor
`Py::PythonExtension<T>::PythonExtension() 
[with T = Py::ExtensionModuleBasePtr]':
CXX/cxx_extensions.cxx:92: instantiated from here
./CXX/Extensions.hxx:472: warning: right-hand operand of comma has no
effect
error: command 'gcc' failed with exit status 1
The second thing is that I wrote a speedometer widget. It is basically
a half pie chart with 3 color coded wedges, tick marks on the dial and
a needle that positions between 1 and 100 ( the value passed ). It's a
quick job ( esp. the mangled borrow from the arrow drawing code :)
designed to make small dial graphics for 'dashboard' type UIs. But
turns out I will not need it or work on it, so I'm sending it out there
for the community.
S
here is the dial.py listing..
#!/usr/bin/env python
"""
Make a dial
"""
from pylab import *
from matplotlib.patches import Patch, Rectangle, Circle, Polygon,
Wedge, 
Shadow, bbox_artist
from math import *
import os
# map to radian
degree_map = {}
degrees = range( 270, 360 ) + range( 0, 91 )
i = 0
for degree in degrees:
 degree_map[i] = degree
 i += 1
image_counter = 0
def make_dial( outdir, value ):
 global image_counter
 filename = 'dial_%s' % image_counter
 image_counter += 1
 
 # scale to 180 and map to radians
 value = value * 1.8
 degree = degree_map[int(value)]
 # make a square figure and axes
 fig = figure(figsize=(1,.5), edgecolor='white')
 ax = axes( [0, 0, 1, 2])
 ax.set_frame_on( False )
 ax.xaxis._visible = False
 ax.yaxis._visible = False
 s = Circle( (.5, 0), .5, facecolor='black' )
 ax.add_patch( s )
 if value <= 180 and value >= 130 :
 color = 'green'
 else:
 color = 'gray'
 w = Wedge((.5,0), .47, 0, 50, facecolor=color, edgecolor=color)
 ax.add_patch( w ) 
 if value < 130 and value >= 50:
 color = 'yellow'
 else:
 color = 'gray'
 w = Wedge((.5,0), .47, 50, 130, facecolor=color, edgecolor=color)
 ax.add_patch( w )
 if value < 50:
 color = 'red'
 else:
 color = 'gray'
 w = Wedge((.5,0), .47, 130, 180, facecolor=color, edgecolor=color)
 ax.add_patch( w )
 def _mark( degree, r1=.35, r2=.4, width=.01, color='white' ):
 
 x1 = sin( (degree*(pi/180))) * r1
 y1 = cos( (degree*(pi/180))) * r1
 x2 = sin( (degree*(pi/180))) * r2
 y2 = cos( (degree*(pi/180))) *r2
 x1 += .009
 x2 += .009 
 dx = x2-x1
 dy = y2-y1
 width = width
 arrow = array( [
 [ 0.0, 0.2 ],
 [ 0.0, -0.2],
 [ 0.8, -0.2 ],
 [ 0.8, 0.2 ] ] )
 L = sqrt(dx**2+dy**2)
 arrow[:,0] *= L
 arrow[:,1] *= width
 cx = float(dx)/L
 sx = float(dy)/L
 M = array( [ [ cx, sx],[ -sx, cx ] ] )
 verts = matrixmultiply( arrow, M ) + [x1+.5,y1]
 s = Polygon( [ tuple(t) for t in verts ], facecolor=color, 
edgecolor=color )
 ax.add_patch( s )
 _mark( 0 ) #not sure why, but it likes the extra mark call
 _mark( 0 )
 _mark( 20 )
 _mark( 40 )
 _mark( 60 )
 _mark( 80 )
 _mark( 340 )
 _mark( 320 )
 _mark( 300 )
 _mark( 280 )
 if value < 50:
 color = 'white'
 else:
 color = 'black'
 _mark( degree, 0, .48, .1, color )
 fullpath = outdir + os.sep + filename
 savefig( fullpath, dpi=30)
 return filename
if __name__ == '__main__': 
 make_dial( '.', 100 )
		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

On Wed, 2005年06月22日 at 11:45 -0600, Fernando Perez wrote:
> os.environ['TEXMFOUTPUT'] = '/some/path'
According to the online docs
(http://docs.python.org/lib/os-procinfo.html) setting os.environ isn't
safe/available for all platforms. You can use the subprocess module to
set the environment of a subprocess under python 2.4 but I don't think
there's a simple way to do this and capture the output for earlier
versions.
Nick

On Wednesday 22 June 2005 06:35 pm, Fernando Perez wrote:
> Stephen Walton wrote:
> > Fernando Perez wrote:
> >>Well, it could be something like $HOME/.tex.cache, where $HOME can be
> >>determined via a routine like the below (this is what ipython uses to
> >>try and guess a sensible value for $HOME):
> >
> > I *like* it.
>
> Though I'd personally vote for matplotlib holding $HOME/.matplotlib/ as a
> directory, and putting in there a tex.cache dir, the matplotlibrc file, and
> anything else it may need in the future.
I second that notion. In fact, I have been meaning to suggest this on the list 
for some time now. Thank for reminding me.
> I *really* don't like the idea that matplotlib will begin to put a bunch of
> differently named things under $HOME with various .foo names. Ipython also
> started with .ipythonrc, and I quickly moved to an .ipython/ directory,
> where I stuff anything I need. It's future-proof, clean, and gives an easy
> way for users to clean up if needed, without having to guess 'how many dot
> files/directories does this thing create'?
>
> So if you were to ask for my opinion, I'd vote +100 on matplotlib moving to
> a single directory for holding *ALL* user and configuration data, which
> would default to $HOME/.matplotlib, and which could be overridden if the
> $MATPLOTLIBDIR environment variable is defined. That's exactly how ipython
> works, so it must be the perfect solution :)
+101
Darren

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>Well, it could be something like $HOME/.tex.cache, where $HOME can be 
>>determined via a routine like the below (this is what ipython uses to 
>>try and guess a sensible value for $HOME):
> 
> 
> I *like* it.
Though I'd personally vote for matplotlib holding $HOME/.matplotlib/ as a 
directory, and putting in there a tex.cache dir, the matplotlibrc file, and 
anything else it may need in the future.
I *really* don't like the idea that matplotlib will begin to put a bunch of 
differently named things under $HOME with various .foo names. Ipython also 
started with .ipythonrc, and I quickly moved to an .ipython/ directory, where 
I stuff anything I need. It's future-proof, clean, and gives an easy way for 
users to clean up if needed, without having to guess 'how many dot 
files/directories does this thing create'?
So if you were to ask for my opinion, I'd vote +100 on matplotlib moving to a 
single directory for holding *ALL* user and configuration data, which would 
default to $HOME/.matplotlib, and which could be overridden if the 
$MATPLOTLIBDIR environment variable is defined. That's exactly how ipython 
works, so it must be the perfect solution :)
Cheers,
f

Fernando Perez wrote:
> Well, it could be something like $HOME/.tex.cache, where $HOME can be 
> determined via a routine like the below (this is what ipython uses to 
> try and guess a sensible value for $HOME):
I *like* it.

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>It may be simpler than that:
> 
> 
> So os.environ does change the environment under Python and its 
> children. The remaining question is what should TEXMFOUTPUT be? 
> /home/user/.tex.cache will not work across all platforms.
Well, it could be something like $HOME/.tex.cache, where $HOME can be 
determined via a routine like the below (this is what ipython uses to 
try and guess a sensible value for $HOME):
#----------------------------------------------------------------------------
class HomeDirError(Error):
 pass
def get_home_dir():
 """Return the closest possible equivalent to a 'home' directory.
 We first try $HOME. Absent that, on NT it's $HOMEDRIVE\$HOMEPATH.
 Currently only Posix and NT are implemented, a HomeDirError 
exception is
 raised for all other OSes. """ #'
 try:
 return os.environ['HOME']
 except KeyError:
 if os.name == 'posix':
 raise HomeDirError,'undefined $HOME, IPython can not proceed.'
 elif os.name == 'nt':
 # For some strange reason, win9x returns 'nt' for os.name.
 try:
 return 
os.path.join(os.environ['HOMEDRIVE'],os.environ['HOMEPATH'])
 except:
 try:
 # Use the registry to get the 'My Documents' folder.
 import _winreg as wreg
 key = wreg.OpenKey(wreg.HKEY_CURRENT_USER,
 
"Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders")
 homedir = wreg.QueryValueEx(key,'Personal')[0]
 key.Close()
 return homedir
 except:
 return 'C:\\'
 elif os.name == 'dos':
 # Desperate, may do absurd things in classic MacOS. May 
work under DOS.
 return 'C:\\'
 else:
 raise HomeDirError,'support for your operating system not 
implemented.'
Cheers,
f

Fernando Perez wrote:
> It may be simpler than that:
So os.environ does change the environment under Python and its 
children. The remaining question is what should TEXMFOUTPUT be? 
/home/user/.tex.cache will not work across all platforms.

Stephen Walton wrote:
> John Hunter wrote:
> 
> 
>>We might have to do something like
>>
>> os.popen('export TEXMFOUTPUT=/some/path; run some command')
>>
>>and then deal with platform and shell dependent differences in how to
>>set environment variables. Is there a better way? Me thinks it is
>>better to make this a FAQ and advise people working in non-writable
>>dirs to set this var themselves.
>>
> 
> I agree with this last. On Unix, you could do
> 
> os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')
> 
> and be pretty sure it would work on all systems. But Windows would be a 
> pain. I agree with the FAQ solution. This seems like a very rare 
> problem to me, to be honest.
It may be simpler than that:
planck[~/test]> cat env.py
#!/usr/bin/env python
import os
print 'before'
os.system('env | grep TEXMFOUTPUT')
os.environ['TEXMFOUTPUT'] = '/some/path'
print 'after'
os.system('env | grep TEXMFOUTPUT')
planck[~/test]> ./env.py
before
after
TEXMFOUTPUT=/some/path
planck[~/test]>
Cheers,
f

John Hunter wrote:
>We might have to do something like
>
> os.popen('export TEXMFOUTPUT=/some/path; run some command')
>
>and then deal with platform and shell dependent differences in how to
>set environment variables. Is there a better way? Me thinks it is
>better to make this a FAQ and advise people working in non-writable
>dirs to set this var themselves.
>
I agree with this last. On Unix, you could do
os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')
and be pretty sure it would work on all systems. But Windows would be a 
pain. I agree with the FAQ solution. This seems like a very rare 
problem to me, to be honest.

On Jun 21, 2005, at 1:09 PM, John Hunter wrote:
> Fernando> I also just saw pylab crash when a user was trying to
> Fernando> run with $PWD being something he didn't have write
> Fernando> access to. Are there any checks in the code to fall
> Fernando> back to /tmp or something sensible if texmanager can't
> Fernando> write the temp files it needs? Sorry for not giving a
> Fernando> traceback, but I only saw this on someone else's screen
> Fernando> while helping them, and for some odd reason it's not
> Fernando> happening on my box.
>
> This is probably failing on the tex/latex temporary files. I spent
> some time initially trying to figure out how to get these to go into
> ~/.tex.cache but didn't succeed. If anyone knows how to direct
> tex/latex to put the various *.aux, *.log, etc, files in a specified
> directory, pass it my way.
I get this when mpl complains about not being able to create a 
.ttffont.cache (or whatever it's called) file. I'll submit a bug on 
the tracker later.
Cheers!
Andrew

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> TEXMFOUTPUT Normally, TeX puts its output files in
 Stephen> the current directory. If any output file cannot be
 Stephen> opened there, it tries to open it in the directory
 Stephen> specified in the environment variable TEXM- FOUTPUT.
 Stephen> There is no default value for that variable. For
 Stephen> example, if you say tex paper and the current directory
 Stephen> is not writable, if TEXMFOUTPUT has the value /tmp, TeX
 Stephen> attempts to create /tmp/paper.log (and /tmp/paper.dvi, if
 Stephen> any output is produced.)
Hmm, that looks familiar -- I think I did come across that. But this
will be a bit of a pain to set from matplotlib, since we are making
calls to os.popen. We might have to do something like
 os.popen('export TEXMFOUTPUT=/some/path; run some command')
and then deal with platform and shell dependent differences in how to
set environment variables. Is there a better way? Me thinks it is
better to make this a FAQ and advise people working in non-writable
dirs to set this var themselves.
Thanks for the help...
JDH

John Hunter wrote:
>This is probably failing on the tex/latex temporary files. I spent
>some time initially trying to figure out how to get these to go into
>~/.tex.cache but didn't succeed. If anyone knows how to direct
>tex/latex to put the various *.aux, *.log, etc, files in a specified
>directory, pass it my way.
> 
>
 From "man tex" on FC3, the section on environment variables:
 TEXMFOUTPUT
 Normally, TeX puts its output files in the current 
directory.
 If any output file cannot be opened there, it tries to 
open it
 in the directory specified in the environment variable 
TEXM-
 FOUTPUT. There is no default value for that 
variable. For
 example, if you say tex paper and the current directory 
is not
 writable, if TEXMFOUTPUT has the value /tmp, TeX 
attempts to
 create /tmp/paper.log (and /tmp/paper.dvi, if any 
output is
 produced.)

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> This was in a long-running session with very large
> Fernando> memory allocations, but it dawned on me that
> Fernando> get_dvipng_version(self) should cache its return value.
> Fernando> There's no point in forcing a popen() call every single
> Fernando> time, is there?
> 
> It already does cache the version
> 
> def get_dvipng_version(self):
> if self.dvipngVersion is not None: return self.dvipngVersion
> sin, sout = os.popen2('dvipng --version')
> ...snip...
> 
> I think the reason it is failing in your case is that is each renderer
> creation creates a new TexManager instance. The cache should be on a
> class basis and not on a per instance basis (slaps self on head).
> Moving
> 
> self.dvipngVersion = None
> 
> to the class level and out of __init__ should suffice. I made this
> change, and similar changes in texmanager and backend_agg, so that
> caching is shared between instances. Update from CVS and let me know
> if everything still works :-)
swamped at the moment, but I'll let you know if I see problems when I 
get a chance.
> Fernando> I also just saw pylab crash when a user was trying to
> Fernando> run with $PWD being something he didn't have write
> Fernando> access to. Are there any checks in the code to fall
> Fernando> back to /tmp or something sensible if texmanager can't
> Fernando> write the temp files it needs? Sorry for not giving a
> Fernando> traceback, but I only saw this on someone else's screen
> Fernando> while helping them, and for some odd reason it's not
> Fernando> happening on my box.
> 
> This is probably failing on the tex/latex temporary files. I spent
> some time initially trying to figure out how to get these to go into
> ~/.tex.cache but didn't succeed. If anyone knows how to direct
> tex/latex to put the various *.aux, *.log, etc, files in a specified
> directory, pass it my way.
I don't really know, sorry. My texpertise is pretty limited, as you know :)
Thanks for the fixes!
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> This was in a long-running session with very large
 Fernando> memory allocations, but it dawned on me that
 Fernando> get_dvipng_version(self) should cache its return value.
 Fernando> There's no point in forcing a popen() call every single
 Fernando> time, is there?
It already does cache the version
 def get_dvipng_version(self):
 if self.dvipngVersion is not None: return self.dvipngVersion
 sin, sout = os.popen2('dvipng --version')
 ...snip...
I think the reason it is failing in your case is that is each renderer
creation creates a new TexManager instance. The cache should be on a
class basis and not on a per instance basis (slaps self on head).
Moving
 self.dvipngVersion = None
to the class level and out of __init__ should suffice. I made this
change, and similar changes in texmanager and backend_agg, so that
caching is shared between instances. Update from CVS and let me know
if everything still works :-)
 Fernando> I also just saw pylab crash when a user was trying to
 Fernando> run with $PWD being something he didn't have write
 Fernando> access to. Are there any checks in the code to fall
 Fernando> back to /tmp or something sensible if texmanager can't
 Fernando> write the temp files it needs? Sorry for not giving a
 Fernando> traceback, but I only saw this on someone else's screen
 Fernando> while helping them, and for some odd reason it's not
 Fernando> happening on my box.
This is probably failing on the tex/latex temporary files. I spent
some time initially trying to figure out how to get these to go into
~/.tex.cache but didn't succeed. If anyone knows how to direct
tex/latex to put the various *.aux, *.log, etc, files in a specified
directory, pass it my way.
Thanks,
JDH

Hi all,
I just had this crash in mpl:
/usr/lib/python2.3/site-packages/matplotlib/texmanager.py in 
get_dvipng_version(self)
 299 def get_dvipng_version(self):
 300 if self.dvipngVersion is not None: return 
self.dvipngVersion
--> 301 sin, sout = os.popen2('dvipng --version')
 302 for line in sout.readlines():
 303 if line.startswith('dvipng '):
/usr/lib/python2.3/os.py in popen2(cmd, mode, bufsize)
 614 def popen2(cmd, mode="t", bufsize=-1):
 615 import popen2
--> 616 stdout, stdin = popen2.popen2(cmd, bufsize)
 617 return stdin, stdout
 618 __all__.append("popen2")
/usr/lib/python2.3/popen2.py in popen2(cmd, bufsize, mode)
 145 specified, it sets the buffer size for the I/O pipes. 
The file objects
 146 (child_stdout, child_stdin) are returned."""
--> 147 inst = Popen3(cmd, False, bufsize)
 148 return inst.fromchild, inst.tochild
 149
/usr/lib/python2.3/popen2.py in __init__(self, cmd, capturestderr, bufsize)
 40 if capturestderr:
 41 errout, errin = os.pipe()
---> 42 self.pid = os.fork()
 43 if self.pid == 0:
 44 # Child
OSError: [Errno 12] Cannot allocate memory
This was in a long-running session with very large memory allocations, 
but it dawned on me that get_dvipng_version(self) should cache its 
return value. There's no point in forcing a popen() call every single 
time, is there?
I don't know the texmanager code, so I don't want to touch it myself. 
But if the idea is OK, a simple property tag is enough to cache:
In [3]: def cached():
 ...: try:
 ...: return cached.cachedvalue
 ...: except AttributeError:
 ...: cached.cachedvalue=42
 ...: return cached.cachedvalue
 ...:
In [4]: cached()
Out[4]: 42
I also just saw pylab crash when a user was trying to run with $PWD 
being something he didn't have write access to. Are there any checks in 
the code to fall back to /tmp or something sensible if texmanager can't 
write the temp files it needs? Sorry for not giving a traceback, but I 
only saw this on someone else's screen while helping them, and for some 
odd reason it's not happening on my box.
Cheers,
f

I built matplotlib on linux from source using:
python setup.py build
python setup.py install --home=3D/home/tom
when I try to import=20
>>> import pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/home/tom/lib/python/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/home/tom/lib/python/matplotlib/pylab.py", line 199, in ?
 import backends
 File "/home/tom/lib/python/matplotlib/backends/__init__.py", line 19, in =
?
 globals(),locals(),[backend_name])
 File "/home/tom/lib/python/matplotlib/backends/backend_gtkagg.py",
line 11, in ?
 from backend_gtk import gtk, FigureManagerGTK, FigureCanvasGTK,\
 File "/home/tom/lib/python/matplotlib/backends/backend_gtk.py", line 21, =
in ?
 from backend_gdk import RendererGDK
 File "/home/tom/lib/python/matplotlib/backends/backend_gdk.py", line 45, =
in ?
 from matplotlib._nc_backend_gdk import pixbuf_get_pixels_array
ImportError: No module named _nc_backend_gdk
When I look in the backends dir in
/home/tom/lib/python/matplotlib/backends i see the following files
which does not include the .so file for _nc_backend_gdk
__init__.py backend_gdk.py backend_qtagg.py
__init__.pyc backend_gdk.pyc backend_qtagg.pyc
_na_backend_agg.so backend_gtk.py backend_svg.py
_nc_backend_agg.so backend_gtk.pyc backend_svg.pyc
backend_agg.py backend_gtkagg.py backend_template.py
backend_agg.pyc backend_gtkagg.pyc backend_template.pyc
backend_agg2.py backend_gtkcairo.py backend_tkagg.py
backend_agg2.pyc backend_gtkcairo.pyc backend_tkagg.pyc
backend_cairo.py backend_paint.py backend_wx.py
backend_cairo.pyc backend_paint.pyc backend_wx.pyc
backend_fltkagg.py backend_ps.py backend_wxagg.py
backend_fltkagg.pyc backend_ps.pyc backend_wxagg.pyc
backend_gd.py backend_qt.py tkagg.py
backend_gd.pyc backend_qt.pyc tkagg.pyc
Is there something I am doing wrong?
-Tom

Hi,
Steve Chaplin <ste...@ya...> wrote:
> FigureCanvasSVG.print_figure() ignores the dpi argument and prints at a 
> fixed dpi of 72, why is that? I know PS has a native dpi of 72, but I 
> don't think that applies to SVG. SVG is scalable - its not limited
> to a single, fixed, pixel size.
I don't know the answer to your question but will address your comment
on PS. It is a fully scalable format. The elements in a PostScript file
are expressed in PostScript points, but that is nothing more than a
unit. That doesn't need to map to pixels. It just says that some element
that is described as 72 PostScript points long should take 1 inch once
printed (if you want to respect the size intended by the creator of the
PostScript file).
All this AFAIK, since I don't know the PostScript programming language.
BTW: PostScript point != point in general; for instance, in TeX, 1 point
 is 1/72.27 inch (therefore, a bit smaller than 1 PostScript point).
-- 
Florent

I noticed (using GTKAgg) that if I save a png and svg of the same Figure
the width, height of the output files do not agree.
FigureCanvasSVG.print_figure() ignores the dpi argument and prints at a 
fixed dpi of 72, why is that? I know PS has a native dpi of 72, but I 
don't think that applies to SVG. SVG is scalable - its not limited
to a single, fixed, pixel size.
Also the SVG files produces something like
<svg
 width="576.000000"
 height="432.000000" 
 ...
I think the width, height should be integers.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> My understanding is, the frontend does all its calculations
 Steve> in floating point and never uses fig.get_width_height()
 Steve> because its always dealing width width, height in inches
 Steve> and dpi.
 Steve> 'grep' shows that fig.get_width_height() is not used by the
 Steve> frontend, its only ever used by the backends so it does not
 Steve> really belong in Figure it belongs it FigureCanvas.
 Steve> The value of width/height in inches * dpi does not need to
 Steve> be integers, but what about the ACTUAL width, height values
 Steve> that the backends produce? The backends will either draw
 Steve> to the display with width, height in integer pixels, or
 Steve> create an output file png, ps, svg etc, which in most
 Steve> (all?) cases will have integer width, height. Does it make
 Steve> sense having an output file 1200.8 x 900.6? What use is the
 Steve> fractional point/pixel?
Hi Steve,
I don't see any use cases where one would use the floating point
values, so if you want to make the changes you propose, go ahead. Be
sure to note them in the CHANGELOG and in API_CHANGES.
Thanks,
JDH

John,
Attached is an updated QT backend (I started from a CVS sync yesterday). I 
can send you diffs if you like.
The main driver is to fix the problem with the plot not being the requested 
size when drawn on the screen. The toolbar was implemented as a dockable 
QToolbar whose location cannot be predicted until drawing time. This 
caused the toolbar to overlay the plot so the result was always a plot that 
was slightly shorter in height than the requested amount.
The following changes were made:
1) Changed the toolbar to be a horizontal bar of push buttons instead of a 
QToolbar and updated the layout algorithms in the main window 
accordingly. This eliminates the ability to drag and drop the toolbar and 
detach it from the window.
2) Updated the resize algorithm in the main window to show the correct size 
for the plot widget as requested. This works almost correctly right 
now. It looks to me like the final size of the widget is off by the border 
of the main window but I haven't figured out a way to get that information 
yet. We could just add a small margin to the new size but that seems a 
little hacky.
3) Changed the x/y location label to be in the toolbar like the Tk backend 
instead of as a status line at the bottom of the widget.
4) Changed the toolbar pixmaps to use the ppm files instead of the png 
files. I noticed that the Tk backend buttons looked much nicer and it uses 
the ppm files so I switched them.
Ted