matplotlib-devel Mailing List for matplotlib

On Wednesday 05 April 2006 18:46, Darren Dale wrote:
> On Wednesday 05 April 2006 18:42, Christopher Barker wrote:
> > Darren Dale wrote:
> > > Is it ok to change the current directory to .matplotlib/tex.cache,
> > > generate the tex files, and then change back to the original working
> > > directory?
> >
> > I think it's bad practice: it sure seems fragile. I don't like my
> > software to change my working directory.
> >
> > Why not have a TexTempDir attribute stored somewhere, and write
> > everything there?
>
> That's exactly what I'm trying to do. Or maybe I dont understand what you
> are suggesting.

I've looked into this more than once before, but this time around I finally 
found a real solution:

latex -output-directory=C:\texoutput -aux-directory=C:\tobedeleted foo.tex

Ok, moving on.

Ryan Krauss wrote:
> My understanding is that once NumPy is considered "stable", Enthought
> will switch to Python 2.4.

We will be switching to Python 2.4 as soon as our new build machine arrives and
we've tested Enthon on it. That should be in about two weeks.

Including numpy is a separate issue and will occur later, probably next month.

-- 
Robert Kern
rob...@gm...

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

On Wednesday 05 April 2006 18:42, Christopher Barker wrote:
> Darren Dale wrote:
> > Is it ok to change the current directory to .matplotlib/tex.cache,
> > generate the tex files, and then change back to the original working
> > directory?
>
> I think it's bad practice: it sure seems fragile. I don't like my
> software to change my working directory.
>
> Why not have a TexTempDir attribute stored somewhere, and write
> everything there?

That's exactly what I'm trying to do. Or maybe I dont understand what you are 
suggesting.

Darren Dale wrote:
> Is it ok to change the current directory to .matplotlib/tex.cache, generate 
> the tex files, and then change back to the original working directory?

I think it's bad practice: it sure seems fragile. I don't like my 
software to change my working directory.

Why not have a TexTempDir attribute stored somewhere, and write 
everything there?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Wednesday 05 April 2006 18:05, John Hunter wrote:
> >>>>> "Andrew" == Andrew Straw <str...@as...> writes:
>
>     Andrew> I actually sent out a request for win32 folks to test my
>     Andrew> presumptive patch some weeks ago:
>     Andrew>
> http://sourceforge.net/mailarchive/forum.php?thread_id=9967846&forum_id=361
>87
>
> In practice, posting a request to test a svn build on win32 will not
> work.  A slightly modified version of your request might read
>
>   1) download MPL from svn
>   2) compile and install MPL with Python < 2.4
>   3) spend two days figuring out step 2
      4) Give up and use linux

usetex will produce a number of files in the current directory, like .aux 
and .log. If the current directory is not writeable, then these files are 
written to .matplotlib/tex.cache.

Is it ok to change the current directory to .matplotlib/tex.cache, generate 
the tex files, and then change back to the original working directory?  Even 
if an error is encountered along the way, I could change back to the original 
working directory before passing the error along. 

Is it bad practice to do this?

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> I actually sent out a request for win32 folks to test my
    Andrew> presumptive patch some weeks ago:
    Andrew> http://sourceforge.net/mailarchive/forum.php?thread_id=9967846&forum_id=36187

In practice, posting a request to test a svn build on win32 will not
work.  A slightly modified version of your request might read

  1) download MPL from svn
  2) compile and install MPL with Python < 2.4
  3) spend two days figuring out step 2 
  4) inside python try "import subprocess"
  5) respond back to the list with your outcome

You'll likely have more luck leaning on Charlie or me to make a test
build for you, and posting a link to it for people to try.  

JDH

My understanding is that once NumPy is considered "stable", Enthought
will switch to Python 2.4.

On 4/5/06, Andrew Straw <str...@as...> wrote:
> John Hunter wrote:
>
> >>>>>>"Andrew" =3D=3D Andrew Straw <str...@as...> writes:
> >>>>>>
> >>>>>>
> >
> >    Andrew> Darren Dale wrote:
> >    >> As soon as I know that matplotlib builds subprocess correctly
> >    >> for windows computers with <python-2.4, I will unmask the
> >    >> subprocess code again in svn. Any ideas when we might have an
> >    >> answer to this question?
> >    >>
> >    Andrew> I suspect that there are relatively few Python 2.3 users
> >    Andrew> on Windows anymore, so I say unmask it now. (It's not like
> >    Andrew> the case in linux where big distros, e.g. Debian, are
> >    Andrew> still on Python 2.3. Windows doesn't have "distros", and
> >
> >enthought python is only built for 2.3 currently, as far as I can see:
> >
> >  http://code.enthought.com/enthon
> >
> >I think this is a pretty important constituency in the scientific
> >python crowd.
> >
> >
>
> OK, point taken.
>
> But still, given that I think I've fixed the bug, we should unmask it so
> we can see if I actually did.
>
> Still not willing to spend hours on my Windows box just to check legacy
> Python2.3 support,
> Andrew
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wednesday 05 April 2006 17:40, Matt Newville wrote:
> On 4/5/06, Mark Bakker <ma...@gm...> wrote:
> > In the scientific crowd (if I may count myself among them),
> > Python2.3 is still used a lot. The enthought distribution
> > is very popular for teaching classes. So please keep 2.3
> > support on win32 going for a little while longer.
>
> +1  -- is breaking backward compatibility  necessary?   In addition to
> the point above, python 2.4 uses a different compiler, and some
> home-built extensions may not have been ported over to the new
> compiler system yet.  I'm sure that's out of pure laziness (speaking
> for myself, anyway, but then I have a Windows box with working
> python2.2, 2.3, and 2.4), so I  suppose I can keep working with a
> python 2.3 and matplotlib ~0.87.1.

As far as I can tell, this discussion is coming up in the context of using the 
subprocess module. The reason Andrew added the module to the mpl source was 
to provide support for python-2.3. Maybe someone will correct me, but I dont 
think there is any reason to worry about continued support of python-2.3.

On 4/5/06, Mark Bakker <ma...@gm...> wrote:
> In the scientific crowd (if I may count myself among them),
> Python2.3 is still used a lot. The enthought distribution
> is very popular for teaching classes. So please keep 2.3
> support on win32 going for a little while longer.
>

+1  -- is breaking backward compatibility  necessary?   In addition to
the point above, python 2.4 uses a different compiler, and some
home-built extensions may not have been ported over to the new
compiler system yet.  I'm sure that's out of pure laziness (speaking
for myself, anyway, but then I have a Windows box with working
python2.2, 2.3, and 2.4), so I  suppose I can keep working with a
python 2.3 and matplotlib ~0.87.1.

--Matt Newville

I assume you're responding to my comment "I suspect that there are 
relatively few Python 2.3 users on Windows anymore, so I say unmask it 
now." Let me clear up any misunderstanding immediately -- this was not 
me proposing to drop support for Python 2.3 on Windows. It was merely me 
proposing that we (well, Darren Dale) keep going forward with (2.3 
compatible) development instead of being held back by a recently 
reported bug from a non-current version of matplotlib which I think is 
actually already fixed. That's what the "unmask it now" refers to -- 
unmasking Darren's latest work so it is active in the svn version of 
matplotlib.

I actually sent out a request for win32 folks to test my presumptive 
patch some weeks ago:
http://sourceforge.net/mailarchive/forum.php?thread_id=9967846&forum_id=36187

That exact test is still what's required for us to be sure my patch has 
worked, and apparently what the latest fuss is about.

Rest assured no one has any plans on disabling Python 2.3 support. My 
suggestion is simply not to hold back development due to lack of 
feedback from the win32 Python2.3 crowd. Mark, if you're willing act on 
that feedback request from a few weeks ago, that would be great.

Cheers!
Andrew

Mark Bakker wrote:

> In the scientific crowd (if I may count myself among them),
> Python2.3 is still used a lot. The enthought distribution
> is very popular for teaching classes. So please keep 2.3
> support on win32 going for a little while longer.
>
> Thanks,
>
> Mark

John Hunter wrote:

>>>>>>"Andrew" == Andrew Straw <str...@as...> writes:
>>>>>>            
>>>>>>
>
>    Andrew> Darren Dale wrote:
>    >> As soon as I know that matplotlib builds subprocess correctly
>    >> for windows computers with <python-2.4, I will unmask the
>    >> subprocess code again in svn. Any ideas when we might have an
>    >> answer to this question?
>    >> 
>    Andrew> I suspect that there are relatively few Python 2.3 users
>    Andrew> on Windows anymore, so I say unmask it now. (It's not like
>    Andrew> the case in linux where big distros, e.g. Debian, are
>    Andrew> still on Python 2.3. Windows doesn't have "distros", and
>
>enthought python is only built for 2.3 currently, as far as I can see:
>
>  http://code.enthought.com/enthon
>
>I think this is a pretty important constituency in the scientific
>python crowd.
>  
>

OK, point taken.

But still, given that I think I've fixed the bug, we should unmask it so 
we can see if I actually did.

Still not willing to spend hours on my Windows box just to check legacy 
Python2.3 support,
Andrew

It is a known bug and it's the one I think I've fixed[1]. As long as 
you're building from scratch, you might as well try the subversion 
repository. There's a nice Windows subversion GUI app called "tortoise 
svn", I highly recommend it.

Darren, there's no need to disable subprocess support because of this 
bug -- it should already be fixed.

[1] http://svn.sourceforge.net/viewcvs.cgi/matplotlib?rev=2156&view=rev

Mark Bakker wrote:

> Sorry I didn't give more details the first time; I thought
> this was a known bug.
> The error below is what one of my students got with 0.87.2, installing 
> on win32 from scratch.
> It worked fine after removing 0.87.2 and replacing it with 0.86.1.
>
> >>> from pylab import *
> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in ?
>     from pylab import *
>   File "C:\Python23\Lib\site-packages
> \pylab.py", line 1, in ?
>     from matplotlib.pylab import *
>   File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 219, in ?
>     new_figure_manager, draw_if_interactive, show = pylab_setup()
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\__init__.py", line 
> 23, in pylab_setup
>     globals(),locals(),[backend_name])
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
> line 9, in ?
>     from backend_agg import FigureCanvasAgg
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py", 
> line 86, in ?
>     from matplotlib.texmanager import TexManager
>   File "C:\Python23\Lib\site-packages\matplotlib\texmanager.py", line 
> 37, in ?
>     from subprocess import Popen, STDOUT, PIPE
>   File "C:\Python23\Lib\site-packages\subprocess\__init__.py", line 
> 366, in ?
>     from _subprocess import *
> ImportError: No module named _subprocess
> >>>
>
>
> On 4/5/06, *Andrew Straw* <str...@as... 
> <mailto:str...@as...>> wrote:
>
>     Mark Bakker wrote:
>
>     > Hello -
>     >
>     > As of the latest release (0.87.2), the _subprocesses error
>     > was not  fixed on win32,
>
>     Can you tell me what the _subprocess error is exactly (Could you
>     include
>     the traceback or compilation log?) or point me to somewhere it has
>     been
>     previously described?
>
>     I've done some work fairly recently (perhaps after the 0.87.2 release)
>     which I thought would have fixed the issue.
>
>

In the scientific crowd (if I may count myself among them),
Python2.3 is still used a lot. The enthought distribution
is very popular for teaching classes. So please keep 2.3
support on win32 going for a little while longer.

Thanks,

Mark

Sorry I didn't give more details the first time; I thought
this was a known bug.
The error below is what one of my students got with 0.87.2, installing on
win32 from scratch.
It worked fine after removing 0.87.2 and replacing it with 0.86.1.

>>> from pylab import *
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in ?
    from pylab import *
  File "C:\Python23\Lib\site-packages\pylab.py", line 1, in ?
    from matplotlib.pylab import *
  File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 219, in ?
    new_figure_manager, draw_if_interactive, show =3D pylab_setup()
  File "C:\Python23\Lib\site-packages\matplotlib\backends\__init__.py", lin=
e
23, in pylab_setup
    globals(),locals(),[backend_name])
  File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py"=
,
line 9, in ?
    from backend_agg import FigureCanvasAgg
  File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 86, in ?
    from matplotlib.texmanager import TexManager
  File "C:\Python23\Lib\site-packages\matplotlib\texmanager.py", line 37, i=
n
?
    from subprocess import Popen, STDOUT, PIPE
  File "C:\Python23\Lib\site-packages\subprocess\__init__.py", line 366, in
?
    from _subprocess import *
ImportError: No module named _subprocess
>>>


On 4/5/06, Andrew Straw <str...@as...> wrote:
>
> Mark Bakker wrote:
>
> > Hello -
> >
> > As of the latest release (0.87.2), the _subprocesses error
> > was not  fixed on win32,
>
> Can you tell me what the _subprocess error is exactly (Could you include
> the traceback or compilation log?) or point me to somewhere it has been
> previously described?
>
> I've done some work fairly recently (perhaps after the 0.87.2 release)
> which I thought would have fixed the issue.
>

John Hunter wrote:
>>>>>>"Andrew" == Andrew Straw <str...@as...> writes:
> 
>     Andrew> Darren Dale wrote:
>     >> As soon as I know that matplotlib builds subprocess correctly
>     >> for windows computers with <python-2.4, I will unmask the
>     >> subprocess code again in svn. Any ideas when we might have an
>     >> answer to this question?
>     >> 
>     Andrew> I suspect that there are relatively few Python 2.3 users
>     Andrew> on Windows anymore, so I say unmask it now. (It's not like
>     Andrew> the case in linux where big distros, e.g. Debian, are
>     Andrew> still on Python 2.3. Windows doesn't have "distros", and
> 
> enthought python is only built for 2.3 currently, as far as I can see:
> 
>   http://code.enthought.com/enthon
> 
> I think this is a pretty important constituency in the scientific
> python crowd.

We will be doing 2.4 releases in the next two weeks or so.

-- 
Robert Kern
rob...@gm...

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Darren Dale wrote:
    >> As soon as I know that matplotlib builds subprocess correctly
    >> for windows computers with <python-2.4, I will unmask the
    >> subprocess code again in svn. Any ideas when we might have an
    >> answer to this question?
    >> 
    Andrew> I suspect that there are relatively few Python 2.3 users
    Andrew> on Windows anymore, so I say unmask it now. (It's not like
    Andrew> the case in linux where big distros, e.g. Debian, are
    Andrew> still on Python 2.3. Windows doesn't have "distros", and

enthought python is only built for 2.3 currently, as far as I can see:

  http://code.enthought.com/enthon

I think this is a pretty important constituency in the scientific
python crowd.

JDH

Mark Bakker wrote:

> Hello -
>
> As of the latest release (0.87.2), the _subprocesses error
> was not  fixed on win32, 

Can you tell me what the _subprocess error is exactly (Could you include 
the traceback or compilation log?) or point me to somewhere it has been 
previously described?

I've done some work fairly recently (perhaps after the 0.87.2 release) 
which I thought would have fixed the issue.

Darren Dale wrote:

>As soon as I know that matplotlib builds subprocess correctly for windows 
>computers with <python-2.4, I will unmask the subprocess code again in svn. 
>Any ideas when we might have an answer to this question?
>
I suspect that there are relatively few Python 2.3 users on Windows 
anymore, so I say unmask it now. (It's not like the case in linux where 
big distros, e.g. Debian, are still on Python 2.3. Windows doesn't have 
"distros", and the Python 2.4 installer has been around a longish time 
now, Microsoft offers a free compiler compatible with the Python 2.4 
release from python.org which is not the case for Python 2.3. Finally, 
all the major packages I use are available, sometimes exclusively, in 
Windows binary packages for Python 2.4. I think these things indicate 
that Python 2.4 on Windows is now the dominant version.)

Also, any potential compilation error is going to bite them as soon as 
they try installing, so we should hear about it pretty quickly and be 
able to adjust setupext.py or whatever needs to be fixed.

Cheers!
Andrew

[I'm moving this discussion to matplotlib-devel.]

I just found the bug report that deals with the IDLE/pythonwin/subprocess 
issue: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1124861&group_id=5470&atid=105470

The bug is not assigned to anyone, but a workaround is listed: stdin, stdout, 
and stderr all have to be specified. I tested this on windows with IDLE and 
pythonwin, and it does appear to fix the problem:

from subprocess import Popen, PIPE, STDOUT
p = Popen('dir', shell=True, stdin=PIPE, stdout=PIPE, stderr=STDOUT)
stat = p.wait()
print p.stdout.read()

As soon as I know that matplotlib builds subprocess correctly for windows 
computers with <python-2.4, I will unmask the subprocess code again in svn. 
Any ideas when we might have an answer to this question?

Let me remind why it is important to use subprocess with an example. If I try 
to print some text but my latex syntax is incorrect, mpl needs to catch latex 
exit status and raise an error. subprocess is needed to do this in a platform 
independent way.

Darren


On Monday 20 March 2006 10:32, Randewijk P-J <pjr...@su...> wrote:
> Darren,
>
> I tried "idle -n" and got the same result:
>
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
> win32 Type "copyright", "credits" or "license()" for more information.
>
>     ****************************************************************
>     Personal firewall software may warn about the connection IDLE
>     makes to its subprocess using this computer's internal loopback
>     interface.  This connection is not visible on any external
>     interface and no data is sent to or received from the Internet.
>     ****************************************************************
>
> IDLE 1.1.2      ==== No Subprocess ====
>
> >>> import subprocess
> >>> process = subprocess.Popen(['dir'], shell=True,
> >>> stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
>
> Traceback (most recent call last):
>   File "<pyshell#1>", line 1, in ?
>     process = subprocess.Popen(['dir'], shell=True,
> stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
>   File "C:\Python\lib\subprocess.py", line 533, in __init__
>     (p2cread, p2cwrite,
>   File "C:\Python\lib\subprocess.py", line 593, in _get_handles
>     p2cread = self._make_inheritable(p2cread)
>   File "C:\Python\lib\subprocess.py", line 634, in _make_inheritable
>     DUPLICATE_SAME_ACCESS)
> TypeError: an integer is required
>
> PJR
>
> > -----Original Message-----
> > From: mat...@li...
> > [mailto:mat...@li...] On
> > Behalf Of Darren Dale
> > Sent: 20 March 2006 16:19
> > To: mat...@li...
> > Subject: Re: [Matplotlib-users] matplotlib-0.87.2 on Windows
> > - using subprocess.Popen()
> >
> >
> > On Monday 20 March 2006 09:03, Randewijk P-J
> >
> > <pjr...@su...> wrote:
> > > Darren,
> > >
> > > I prefer using PythonWin to IDLE. Any ideas how to solve the
> > > subprocess.Popen() problem using PythonWin? What about using
> > > "win32pipe"?
> >
> > I don't know how to solve it for pythonwin, maybe you could
> > investigate it
> > with a google search (thats how I learned about the problem
> > and the solution
> > for idle).
> >
> > I suppose win32pipe is part of pywin32. If that is the case,
> > I dont think I
> > can support using it; we are trying to eliminate
> > dependencies, not add to
> > them. Subprocess is acceptable because it is part of the
> > python-2.4 standard
> > library and we were able to add it to the mpl tree for older
> > versions of
> > python.
> >
> > Darren
> >
> > > -----Original Message-----
> > > From: Darren Dale [mailto:dd...@co...]
> > > Sent: 20 March 2006 15:52
> > > To: Randewijk P-J <pjr...@su...>
> > > Subject: Re: ASPN : Python Cookbook : Module to allow Asynchronous
> > > subprocess use on Windows and Posix platforms
> > >
> > >
> > > I forgot to mention, you may be able to avoid these errors
> >
> > by starting
> >
> > > idle with the -n flag.
> > >
> > > On Monday 20 March 2006 08:36, you wrote:
> > > > Aha!
> > > >
> > > > In both the IDLE & PythonWin (my default my using pylab)
> >
> > shells it
> >
> > > > fails... but not from the python shell...
> > > >
> > > > PJR
> > > >
> > > > > -----Original Message-----
> > > > > From: Darren Dale [mailto:dd...@co...]
> > > > > Sent: 20 March 2006 15:25
> > > > > To: Randewijk P-J <pjr...@su...>
> > > > > Subject: Re: ASPN : Python Cookbook : Module to allow
> >
> > Asynchronous
> >
> > > > > subprocess use on Windows and Posix platforms
> > > > >
> > > > >
> > > > > Also, are you running this from IDLE? If so, please try
> >
> > running it
> >
> > > > > from a regular python shell, or better, run a script
> >
> > from the dos
> >
> > > > > shell.
> > > > >
> > > > > On Monday 20 March 2006 08:06, you wrote:
> > > > > > This is what I get:
> > > > > > >>> import subprocess
> > > > > > >>> process = subprocess.Popen(['dir'], shell=True,
> > > > > >
> > > > > > stdout=subprocess.PIPE,stderr=subprocess.STDOUT)
> > > > > > Traceback (most recent call last):
> > > > > >   File "<interactive input>", line 1, in ?
> > > > > >   File "C:\Python\lib\subprocess.py", line 533, in __init__
> > > > > >     (p2cread, p2cwrite,
> > > > > >   File "C:\Python\lib\subprocess.py", line 593, in
> >
> > _get_handles
> >
> > > > > >     p2cread = self._make_inheritable(p2cread)
> > > > > >   File "C:\Python\lib\subprocess.py", line 634, in
> > >
> > > _make_inheritable
> > >
> > > > > >     DUPLICATE_SAME_ACCESS)
> > > > > > TypeError: an integer is required
> > > > > >
> > > > > > PJR
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Darren Dale [mailto:dd...@co...]
> > > > > > > Sent: 20 March 2006 14:49
> > > > > > > To: Randewijk P-J <pjr...@su...>
> > > > > > > Subject: Re: ASPN : Python Cookbook : Module to allow
> > > > >
> > > > > Asynchronous
> > > > >
> > > > > > > subprocess use on Windows and Posix platforms
> > > > > > >
> > > > > > >
> > > > > > > Hi P-J,
> > > > > > >
> > > > > > > On Monday 20 March 2006 7:39 am, you wrote:
> > > > > > > > Dear Darren,
> > > > > > > >
> > > > > > > > Maybe this could help solve the Windows problem with
> > > > > > >
> > > > > > > Popen()... don't
> > > > > > >
> > > > > > > > know about the 2.3 issue however...
> >
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/4405
> >
> > > > > > > > 54
> > > > > > >
> > > > > > > I'm not convinced that there is an issue with
> >
> > subprocess.Popen
> >
> > > > > > > in windows. I tested the following block on windows (with
> > > > >
> > > > > python-2.4)
> > > > >
> > > > > > > and it worked fine.
> > > > > > >
> > > > > > > import subprocess
> > > > > > > process = subprocess.Popen(['dir'], shell=True,
> > > > > > > stdout=subprocess.PIPE,
> > > > > > > stderr=subprocess.STDOUT)
> > > > > > > stat = process.wait()
> > > > > > > print process.stdout.read()
> > > > > > >
> > > > > > > I posted this to the list last week. Did you test it?
> > > > >
> > > > > --
> > > > > Darren S. Dale, Ph.D.
> > > > > Cornell High Energy Synchrotron Source
> > > > > Cornell University
> > > > > 200L Wilson Lab
> > > > > Rt. 366 & Pine Tree Road
> > > > > Ithaca, NY 14853
> > > > >
> > > > > dd...@co...
> > > > > office: (607) 255-9894
> > > > > fax: (607) 255-9001
> >
> > --
> > Darren S. Dale, Ph.D.
> > Cornell High Energy Synchrotron Source
> > Cornell University
> > 200L Wilson Lab
> > Rt. 366 & Pine Tree Road
> > Ithaca, NY 14853
> >
> > dd...@co...
> > office: (607) 255-9894
> > fax: (607) 255-9001
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking
> > scripting language that extends applications into web and
> > mobile media. Attend the live webcast and join the prime
> > developer group breaking into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&
>
> dat=121642
> _______________________________________________
> Matplotlib-users mailing list Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

On Wednesday 05 April 2006 11:40, Mark Bakker wrote:
> Hello -
>
> As of the latest release (0.87.2), the _subprocesses error
> was not  fixed on win32, and after the use of the save button
> on the toolbar, the figure was 'forgotten' in interactive mode.
> I recall some discussion about these on the list.
> I encountered these two bugs again this week while
> teaching a python class. Have these been fixed in svn?
> If not, any chance someone knows how to fix them?

The subprocess module code has been masked in svn. texmanager.py and 
backend_ps.py are the affected files. I dont know about the save button.

Darren

Hello -

As of the latest release (0.87.2), the _subprocesses error
was not  fixed on win32, and after the use of the save button
on the toolbar, the figure was 'forgotten' in interactive mode.
I recall some discussion about these on the list.
I encountered these two bugs again this week while
teaching a python class. Have these been fixed in svn?
If not, any chance someone knows how to fix them?

Thanks again,

Mark