matplotlib-devel Mailing List for matplotlib (Page 5)

>>>>> "James" == James Evans <jre...@ea...> writes:
 James> The patch is as follows: -- In several places arrays are
 James> initialized with a variable for the length. As per
 James> Stroustrup arrays can only be specified with constants or
 James> using 'new' .
Hey James, I notice you have 3 patches with the title 
 Strict C/C++ Conformance
Have all of these been resolved by the patch Andrew applied? If so,
I'll close them.
Thanks,
JDH

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> I've uploaded a patch to sourceforge that lets you control
 Jordan> the grid line attributes from the grid() function. So,
 Jordan> for instance, if you wanted red grid lines on one plot,
 Jordan> you can go grid(color='r')
Thanks Jordan, nicely done. I've committed this to svn revision 2159.
For all of the matplotlib developers (or potential developers!) out
there, we've fallen a bit behind on applying the sf patches and
resolving the reported bugs. Everyone try to pick a few off as you
have time.
Thanks,
JDH

>>>>> "Jos=E9" =3D=3D Jos=E9 Matos <jao...@gm...> writes:
 Jose> IMO rpm is right and the test is wrong. It does not make
 Jose> any sense to require a running X just to check that pygtk is
 Jose> installed.
In principle, I certainly agree with you. In practice, I think this
is harder than it sounds, because several of us have tried to make a
build/configure system that 1) works and 2) doesn't require X, and
obviously we have failed. Whle it certainly must be possible, we
clearly haven't found the right apporaches for GTK* and Tk*.
 >> 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 X11 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 given
 >> that on Ubuntu and Mandriva it's working OK, I wouldn't worry
 >> too much about it. Having that feedback was a good outcome of
 >> this thread, even if I can't upgrade in our lab :)
 Jose> The usual trick in rpms it to require a nest X to test for
 Jose> pygtk.
I'm not sure I understand this. We have the following
if BUILD_GTK:
 try:
 import gtk
 except ImportError:
 print 'GTK requires pygtk'
 BUILD_GTK=3D0
 except RuntimeError:
 print 'pygtk present but import failed'
The ImportError is designed to catch the case where pygtk is not
present and the RuntimeError is designed to warn but not fail if X is
not present. I'll do some testing tonight to see if I can isolate
where this is failing. =20
JDH

>>>>> "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

I've uploaded a patch to sourceforge that lets you control the grid line 
attributes from the grid() function. So, for instance, if you wanted 
red grid lines on one plot, you can go grid(color='r')
Jordan

Eric Firing wrote:
> Charlie Moad wrote:
> 
>>Fwiw, bdist_rpm just worked fine for me on Ubuntu.
> 
> 
> Same for me on Mandriva.
Thanks for the feedback: this is a Fedora3 box, so it may be specific to the 
version of the rpm build scripts in it.
I'll test at home on my ubuntu laptop tonight, but it's good to know that for 
others on modern distros it's working OK.
>>On 3/16/06, John Hunter <jdh...@ac...> wrote:
>>
>>
>>>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
>>>
>>> Fernando> pygtk present but import failed
>>> Fernando> Using default library and include directories for Tcl and Tk because a
>>> Fernando> Tk window failed to open. You may need to define DISPLAY for Tk to work
>>> Fernando> so that setup can determine where your libraries are located.
>>> Fernando> (setup.py:31070): Gtk-WARNING **: cannot open display:
>>>
>>>This looks like an X11 issue. Make sure you log in with ssh -X and
>>>that you can launch an X11 app from the build machine in the build
>>>environment. Sometimes you also need to set xhost. Eg if you are
>>>building as root, make sure you can launch an xterm as root before
>>>trying to install matplotlib.
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=C
+ 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.
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 X11 
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 given 
that on Ubuntu and Mandriva it's working OK, I wouldn't worry too much about 
it. Having that feedback was a good outcome of this thread, even if I can't 
upgrade in our lab :)
Cheers,
f

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.
> 
>
I noticed yesterday that the setuptools we have isn't the setuptools in 
Python (2.5) SVN which seems a pity -- there a number of cleanups, 
especially checking if a "variable is None" instead of "variable == None".
I'm not sure if there are any fixes for windows, but I don't remember any.
The comments at the top of the Python SVN version say the module should 
be kept compatible with Python 2.2, which I haven't verified. I would 
propose we update MPL to the newest version of subprocess, which is 
presumably that distributed in Python SVN. Also for the sake of finding 
this as an exact copy, I suggest really having it in a file named 
'subprocess.py' and make matplotlib/lib/subprocess/__init__.py have 
contents of "from subprocess import *". I hesitate to do this because 
there may be issues I'm not aware of. Are there any?
Otherwise, I can do this later today or tonight.

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.
if mswindows:
 import threading
 import msvcrt
 if 0: # <-- change this to use pywin32 instead of the _subprocess drive=
r
 import pywintypes
 from win32api import GetStdHandle, STD_INPUT_HANDLE, \
 STD_OUTPUT_HANDLE, STD_ERROR_HANDLE
 from win32api import GetCurrentProcess, DuplicateHandle, \
 GetModuleFileName, GetVersion
 from win32con import DUPLICATE_SAME_ACCESS, SW_HIDE
 from win32pipe import CreatePipe
 from win32process import CreateProcess, STARTUPINFO, \
 GetExitCodeProcess, STARTF_USESTDHANDLES, =
\
 STARTF_USESHOWWINDOW, CREATE_NEW_CONSOLE
 from win32event import WaitForSingleObject, INFINITE, WAIT_OBJECT_0
 else:
 from _subprocess import *
 class STARTUPINFO:
 dwFlags =3D 0
 hStdInput =3D None
 hStdOutput =3D None
 hStdError =3D None
 class pywintypes:
 error =3D IOError
else:
 import select
 import errno
 import fcntl
 import pickle
On 3/16/06, da...@in... <da...@in...> wrote:
> Hi All,
>
> I installed the new release for win32 and python 2.3 but
> every time that I import the pylab, I receive the
> following error:
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Python23>python FIRExample --verbose-helpful
> matplotlib data path
> C:\Python23\lib\site-packages\matplotlib\mpl-data
> $HOME=3DC:\Documents and Settings\a
> CONFIGDIR=3DC:\Documents and Settings\a\.matplotlib
> loaded rc file
> C:\Python23\lib\site-packages\matplotlib\mpl-data\matplotlibrc
> matplotlib version 0.87.2
> verbose.level helpful
> interactive is False
> platform is win32
> numerix Numeric 23.6
> font search path
> ['C:\\Python23\\lib\\site-packages\\matplotlib\\mpl-data']
> loaded ttfcache file C:\Documents and
> Settings\a\.matplotlib\ttffont.
> cache
> Traceback (most recent call last):
> File "FIRExample", line 2, in ?
> import pylab
> 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",
> line 23,
> in pylab_setup
> globals(),locals(),[backend_name])
> File
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py",
> lin
> e 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
>
>
> Also the User's Guide doesn't work. The pdf file seems to
> be damaged.
> Can you help me?
>
> Thanks in advance
>
> Daigos
>
>
> INFINITO ADSLFLAT 4 MEGA: SOLO 27,90 EURO AL MESE IVA INCLUSA IP STATICO,=
 BANDA GARANTITA 256Kbps ANTIVIRUS E FIREWALL INCLUSI NEL PREZZO
>
> http://adsl.infinito.it
>
>
>
>
>
> -------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Fwiw, bdist_rpm just worked fine for me on Ubuntu.
- Charlie
On 3/16/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Fernando" =3D=3D Fernando Perez <Fer...@co...> writ=
es:
>
> Fernando> pygtk present but import failed
> Fernando> Using default library and include directories for Tcl and T=
k because a
> Fernando> Tk window failed to open. You may need to define DISPLAY f=
or Tk to work
> Fernando> so that setup can determine where your libraries are locate=
d.
> Fernando> (setup.py:31070): Gtk-WARNING **: cannot open display:
>
> This looks like an X11 issue. Make sure you log in with ssh -X and
> that you can launch an X11 app from the build machine in the build
> environment. Sometimes you also need to set xhost. Eg if you are
> building as root, make sure you can launch an xterm as root before
> trying to install matplotlib.
>
> JDH
>
>
>
> -------------------------------------------------------
> 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
>

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> pygtk present but import failed
 Fernando> Using default library and include directories for Tcl and Tk because a
 Fernando> Tk window failed to open. You may need to define DISPLAY for Tk to work
 Fernando> so that setup can determine where your libraries are located.
 Fernando> (setup.py:31070): Gtk-WARNING **: cannot open display:
This looks like an X11 issue. Make sure you log in with ssh -X and
that you can launch an X11 app from the build machine in the build
environment. Sometimes you also need to set xhost. Eg if you are
building as root, make sure you can launch an xterm as root before
trying to install matplotlib.
JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> One little question: in my personal copy of this, I had
> Fernando> rebound the mouse events to have the rotation follow VTK
> Fernando> conventions. Wouldn't it be a good idea to be
> Fernando> VTK-compatible on this front?
> 
> It would -- want to dust off your developer permissions and test a
> commit to the new svn repo :-)
Well, I tried installing from SVN yesterday but couldn't because
./setup.py bdist_rpm
doesn't work anymore (it used to). So for now I'm holding back on mpl 
updates, I'm afraid. Here, I simply can't afford the time to do non-rpm 
installs, because I need to distribute installs to multiple machines in a 
clean and upgradable way. rpms do it perfectly, and for a long time, Numeric, 
old-scipy and matplotlib all accepted the above command happily. 
Unfortunately that's not true anymore of mpl (haven't checked numpy/scipy-new 
yet, as those will need actual code porting).
If anyone is interested in having a go at this, the error is (just the final 
part):
===================================================================
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.68255
+ umask 022
+ cd 
/scratch/local/home/fperez/tmp/lsrc/matplotlib/build/bdist.linux-i686/rpm/BUILD
+ cd matplotlib-0.87.2dev_r2151
+ LANG=C
+ export LANG
+ unset DISPLAY
+ env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build
pygtk present but import failed
Using default library and include directories for Tcl and Tk because a
Tk window failed to open. You may need to define DISPLAY for Tk to work
so that setup can determine where your libraries are located.
(setup.py:31070): Gtk-WARNING **: cannot open display:
error: Bad exit status from /var/tmp/rpm-tmp.68255 (%build)
RPM build errors:
 Bad exit status from /var/tmp/rpm-tmp.68255 (%build)
error: command 'rpmbuild' failed with exit status 1
===================================================================
It's really unfortunate that bdist_rpm stopped working, because it is really a 
tremendous help for those who want to distribute hand-made builds in their 
local environments, without having to wait for the upstream distributors to 
make official releases.
Up to 0.83.2 (last I had upgraded) this worked without a hitch.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> One little question: in my personal copy of this, I had
 Fernando> rebound the mouse events to have the rotation follow VTK
 Fernando> conventions. Wouldn't it be a good idea to be
 Fernando> VTK-compatible on this front?
It would -- want to dust off your developer permissions and test a
commit to the new svn repo :-)
Also, I notice that proj3d defines it's own dot and cross: by simply
replacing these with the ATLAS enhanced numpy versions, we might see a
significant performance boost.
JDH

John Hunter wrote:
> John Porter, author of the mplot3d functionality, has contributed his
> code to matplotlib, which is great news.
this is great, many thanks.
One little question: in my personal copy of this, I had rebound the mouse 
events to have the rotation follow VTK conventions. Wouldn't it be a good 
idea to be VTK-compatible on this front?
Cheers,
f

John Porter, author of the mplot3d functionality, has contributed his
code to matplotlib, which is great news.
I've committed the four required files into svn revision 2151
 art3d.py 
 axes3d.py
 axis3d.py
 proj3d.py
It would be nice to integrate this into pylab (plot3, scatter3, etc)
which create the required Axes3D instances and so on, as well as to
create some examples for the examples dir. I will get to this as I
have time, but if anyone wants to volunteer, fire away. There are a
number of examples and the bottom of Axes3D.py that you can follow.
Here are a couple of unresolved issues John identified in his email as
needing some attention
 One or two things are cleaned up w.r.t the previous version, but
 some of the auto-scaling is still a mystery to me. I also had some
 trouble with the label alignments on different backends...
Thanks John!
JDH