Thread: [matplotlib-devel] [John Porter <jporter@cambridgebroadband.com>] 3D plotting

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

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

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

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
>

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

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

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

On 18/03/06, John Hunter <jdh...@ac...> wrote:
>
>     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.

  I see what you mean. It makes sense. :-)
  I was talking about using xnest to make that code pass the test.
Clearly your approach is more appropriate. :-)

> JDH

--
Jos=E9 Ab=EDlio