matplotlib-devel Mailing List for matplotlib

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> (That is the official form of currency on this list, isn't
 Darren> it?)
Well, I don't know if I ever mentioned this here, but Perry actually
mailed me a doughnut via snail mail once, after I repeatedly snubbed
him for welching on a bet. So I guess that does make it the official
currency.
JDH

On Friday 17 March 2006 14:51, Andrew Straw wrote:
> John Hunter wrote:
> >>>>>>"Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> I just had a thought. os.system will yield the exit
> > Darren> status, but the stdout, stderr messages automatically get
> > Darren> passed on to sys.stdout. I think I could temporarily
> > Darren> redirect sys.stdout long enough to catch that information
> > Darren> behind the scenes. Is there a reason not to pursue this
> > Darren> route?
> >
> >I think it may be ill-advised for a library to be mucking around with
> >sys.stdout, since the calling application may be doing the same.
>
> Sorry I missed this thread while working on fixes to _subprocess.c in
> MPL svn. (Only required on win32.)
>
> First, I didn't realize there was an extension module involved, either.
> This is because it's a platform-dependent (win32) requirement, and I
> don't frequently use Windows. I agree this makes it a harder choice to
> include.
>
> Second, I believe the page pointed to by Darren is out-of-date: the most
> recent update to subprocess.py is from Feb 21, 2005, while in Python svn
> the most recent update is September 23. I've updated our svn repository
> to the most recent subprocess and hopefully made a few robustness
> improvements.
>
> Third, if we (Darren) determines subprocess isn't needed, after all, we
> can rip it out again. (My feelings won't be hurt.) I'm just concerned
> that he's going to re-implement what they've already done. Wouldn't it
> just be easier to see what aspects of it are win32-dependent tread
> carefully? After all, the whole purpose of the module is exactly so that
> all this stuff is done by subprocess, and if there are win32-dependent
> issues remaining, it's most likely that there's a good reason (like its
> simply not possible on win32).
I've been banging my head against this all day. There are other solutions that 
will help usetex get by, but subprocess does exactly what we need. So Andrew, 
if you were able to get the subprocess extension code to work properly in the 
mpl tree, I'll owe you a doughnut. 
(That is the official form of currency on this list, isn't it?)

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Sorry I missed this thread while working on fixes to
 Andrew> _subprocess.c in MPL svn. (Only required on win32.)
No worries, I've been flip-flopping so fast it's hard to keep up :-)
It looks like you've already done the hard part. After the next build
we can test it on win32 and other platforms and re-enable the
subprocess stuff in backend ps and texmanager when we are convinced
it's working.
Thanks!
JDH

John Hunter wrote:
>>>>>>"Darren" == Darren Dale <dd...@co...> writes:
>>>>>> 
>>>>>>
> Darren> I just had a thought. os.system will yield the exit
> Darren> status, but the stdout, stderr messages automatically get
> Darren> passed on to sys.stdout. I think I could temporarily
> Darren> redirect sys.stdout long enough to catch that information
> Darren> behind the scenes. Is there a reason not to pursue this
> Darren> route?
>
>I think it may be ill-advised for a library to be mucking around with
>sys.stdout, since the calling application may be doing the same.
> 
>
Sorry I missed this thread while working on fixes to _subprocess.c in
MPL svn. (Only required on win32.)
First, I didn't realize there was an extension module involved, either.
This is because it's a platform-dependent (win32) requirement, and I
don't frequently use Windows. I agree this makes it a harder choice to
include.
Second, I believe the page pointed to by Darren is out-of-date: the most
recent update to subprocess.py is from Feb 21, 2005, while in Python svn
the most recent update is September 23. I've updated our svn repository
to the most recent subprocess and hopefully made a few robustness
improvements.
Third, if we (Darren) determines subprocess isn't needed, after all, we
can rip it out again. (My feelings won't be hurt.) I'm just concerned
that he's going to re-implement what they've already done. Wouldn't it
just be easier to see what aspects of it are win32-dependent tread
carefully? After all, the whole purpose of the module is exactly so that
all this stuff is done by subprocess, and if there are win32-dependent
issues remaining, it's most likely that there's a good reason (like its
simply not possible on win32).

Andrew Straw wrote:
> (The following point may be moot, given that Darren has now removed a
> subprocess dependency... Darren -- does your code depend on it anywhere
> else?)
> 
Actually, I only masked all of the subprocess code. It is still there, 
if we find a way to make this work.
> I discovered that subprocess.py on win32 depends either on _subprocess
> (a C extension) or pywin32 (another Python package). Given that we don't
> want another Python package to depend on, I've taken the liberty of
> adding _subprocess and hopefully enabling the right conditional build
> statements for it.
>
> 
Thank you Andrew, for giving this a shot.
> However, I haven't actually been able to test my action, because I
> haven't tried building it and installing it on Windows with Python <
> 2.4. If someone could please attempt to do this and make sure our
> subprocess.py works, that would be great. The easiest way to do this
> would be:
>
> 
I would do this myself, but the last straw leading to my flight from 
windows was the difficulty I had compiling mpl from source.
> 1) download MPL from svn
> 2) compile and install MPL with Python < 2.4
> 3) inside python try "import subprocess"
> 4) respond back to the list with your outcome
> 

(The following point may be moot, given that Darren has now removed a
subprocess dependency... Darren -- does your code depend on it anywhere
else?)
I discovered that subprocess.py on win32 depends either on _subprocess
(a C extension) or pywin32 (another Python package). Given that we don't
want another Python package to depend on, I've taken the liberty of
adding _subprocess and hopefully enabling the right conditional build
statements for it.
However, I haven't actually been able to test my action, because I
haven't tried building it and installing it on Windows with Python <
2.4. If someone could please attempt to do this and make sure our
subprocess.py works, that would be great. The easiest way to do this
would be:
1) download MPL from svn
2) compile and install MPL with Python < 2.4
3) inside python try "import subprocess"
4) respond back to the list with your outcome
Cheers!
Andrew

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I just had a thought. os.system will yield the exit
 Darren> status, but the stdout, stderr messages automatically get
 Darren> passed on to sys.stdout. I think I could temporarily
 Darren> redirect sys.stdout long enough to catch that information
 Darren> behind the scenes. Is there a reason not to pursue this
 Darren> route?
I think it may be ill-advised for a library to be mucking around with
sys.stdout, since the calling application may be doing the same.
JDH

On Friday 17 March 2006 13:07, Darren Dale wrote:
> On Friday 17 March 2006 12:08, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> which contains only one directory with the following
> > Darren> files: AUTHORS TODO pep.txt setup.py test_subprocess.py
> > Darren> MANIFEST.in _subprocess.c setup.cfg subprocess.py
> >
> > Hmm, this is starting to make me nervous.... I didn't realize
> > extension code was going to be involved. I thought we were dealing
> > with a single python file.
> >
> > If it starts to look like distributing subprocess across platforms is
> > non-trivial and we need it, I'll switch my vote to +1 for revamping
> > backend_ps and backend_agg to delay import of texmanager until needed
> > and leave it to texmanager users to make sure they install subprocess.
>
> I think we need to catch the exit status. As Nils discovered, there are
> opportunities for latex and friends to fail silently and give strange
> results (\frac{1}{2} vs $\frac{1}{2}$). Other errors will result in missing
> temporary files (like dvi's and png's), which are not as difficult to track
> down, but still a pain in the butt.
>
> I just had a thought. os.system will yield the exit status, but the stdout,
> stderr messages automatically get passed on to sys.stdout. I think I could
> temporarily redirect sys.stdout long enough to catch that information
> behind the scenes. Is there a reason not to pursue this route?
Would this work across platforms? It works on linux and windows:
exitstat = os.system('tex --version > temp.txt' )

On Friday 17 March 2006 12:08, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> which contains only one directory with the following
> Darren> files: AUTHORS TODO pep.txt setup.py test_subprocess.py
> Darren> MANIFEST.in _subprocess.c setup.cfg subprocess.py
>
> Hmm, this is starting to make me nervous.... I didn't realize
> extension code was going to be involved. I thought we were dealing
> with a single python file.
>
> If it starts to look like distributing subprocess across platforms is
> non-trivial and we need it, I'll switch my vote to +1 for revamping
> backend_ps and backend_agg to delay import of texmanager until needed
> and leave it to texmanager users to make sure they install subprocess.
I think we need to catch the exit status. As Nils discovered, there are 
opportunities for latex and friends to fail silently and give strange results 
(\frac{1}{2} vs $\frac{1}{2}$). Other errors will result in missing temporary 
files (like dvi's and png's), which are not as difficult to track down, but 
still a pain in the butt. 
I just had a thought. os.system will yield the exit status, but the stdout, 
stderr messages automatically get passed on to sys.stdout. I think I could 
temporarily redirect sys.stdout long enough to catch that information behind 
the scenes. Is there a reason not to pursue this route?
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> which contains only one directory with the following
 Darren> files: AUTHORS TODO pep.txt setup.py test_subprocess.py
 Darren> MANIFEST.in _subprocess.c setup.cfg subprocess.py
Hmm, this is starting to make me nervous.... I didn't realize
extension code was going to be involved. I thought we were dealing
with a single python file.
If it starts to look like distributing subprocess across platforms is
non-trivial and we need it, I'll switch my vote to +1 for revamping
backend_ps and backend_agg to delay import of texmanager until needed
and leave it to texmanager users to make sure they install subprocess.
JDH

On Thursday 16 March 2006 14:55, Charlie Moad wrote:
> This is sneaking in for python2.3 and windows. Here is the code
> culprit below. We'll have to look into where this _subprocess module
> is supposed to be coming from.
>
> For now you can download
> "http://effbot.org/downloads/subprocess-0.1-20041012.win32-py2.3.exe"
> from "http://effbot.org/downloads/". I'll post a new python2.3 build
> shortly that includes this.
The full subprocess source is available here: 
http://www.lysator.liu.se/~astrand/popen5/
which contains only one directory with the following files:
AUTHORS TODO pep.txt setup.py test_subprocess.py
MANIFEST.in _subprocess.c setup.cfg subprocess.py
Would someone well versed with distutils please advise me on which of these 
should be added to the mpl tree and where? (Note: Their setup.py file uses 
py_modules, which if I remember correctly is not backwards compatible with 
python 2.2.)
Thanks,
Darren

On 16/03/06, Fernando Perez <Fer...@co...> wrote:
>
> Well, the problem is here:
>
> + cd
> /scratch/local/home/fperez/tmp/lsrc/matplotlib/build/bdist.linux-i686/rpm=
/BUILD
> + cd matplotlib-0.87.2dev_r2151
> + LANG=3DC
> + export LANG
> + unset DISPLAY
>
> That last line unsets the DISPLAY variable, so it doesn't matter who is
> running it, it will never work. I had tested this before mailing both as=
 root
> with X11 properly configured and as my own user, but obviously with this =
unset
> in there, nothing I do can help.
 IMO rpm is right and the test is wrong. It does not make any sense
to require a running X just to check that pygtk is installed.
> The mysterious part is why bdist_rpm /used/ to work for mpl as of 0.83.2.=
 It
> could be either that a change in mpl's build made it more sensitive to X1=
1
> issues than before, or that Fedora3 updated its rpm build scripts between
> those days and today, and that now they do this 'unset DISPLAY'. But giv=
en
> that on Ubuntu and Mandriva it's working OK, I wouldn't worry too much ab=
out
> it. Having that feedback was a good outcome of this thread, even if I ca=
n't
> upgrade in our lab :)
 The usual trick in rpms it to require a nest X to test for pygtk.
> Cheers,
>
> f
--
Jos=E9 Ab=EDlio