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