[Edu-sig] The fate of vpython

[ajsiegel at optonline.net]

----- Original Message -----
From: Dethe Elza 
Date: Wednesday, October 11, 2006 1:28 am
Subject: Re: [Edu-sig] The fate of vpython
To: davelist at mac.com
Cc: edu-sig at python.org, John Zelle 

> Dave wrote:
> 
> >> Just curious, is PyOpenGL easy to install for both Mac and 
> >> Windows? I know
> >> it's dead simple on most Linux distributions. I think it's 
> pretty 
> >> easy for
> >> Windows, but have no experience at all on the Mac.
> >
> > Someone has made binaries for it (and a number of other Python 
> add- 
> > ons) at:
> >
> > http://pythonmac.org/packages/py24-fat/index.html
> 
> Which makes it as easy to install on OS X as on Windows. 
> Building it 
> from source can be troublesome, but is far more tractable in my 
> experience than VPython.

We agree that building VPython is a PITA, for those few who need to build it.

We agree it would be better if it were les of a pain.

But I somehow got myself in the postion of defending poor little vpython.

Not to easy for me, since its 400k in funding has run out, and one would think we
would just be enjoying it, rather than worrying about how to keep it alive - 400k
later.

You install pyopengl on the Mac.  What windowing system are you running it on???

The magic of vpython (in the good and bads sense ) - or the world-onto-itself 
aspect - is that once built it is in fact a world onto it self, i.e. self-sufficent.

And one can do only:

>>import visual
>>spehere()

and one has a sphere in a window, with the window responding to mouse events
in expected ways.

"Vpython" using pyopengl, in order to remain vpython, would need to recreate
that behevaior.  In order to recreate that behavior it would need to do so with
respect to specifc windowing systems.

I keep thinking we are going around in circles.

More and better crossplatform back-ends for vpython, we agree.

But there is baby and there is bathwater.

The need to go further than that, because we are using the words "build"
and "install" willynilly and polemically as we wish, can't see where we are 
trying to get to.

Doesn't one need swig installed to build pyopengl??

Vpython is used extensively by physics departments where their students
are not expected to have anything more than basic literacy re computers.

It is easy to install, needs to be, has to be.  There is a binary for Mac as well -
but it requires fink, so granted if you have toi install fink for no other reason than
to use vpython, vpython is not easy to install on the Mac.  But that is
more the norm than the exception for free and open source projects it 
seems to me.

The fact is that pygeo pre-dates vpython and was originally rendered directly by
pyopengl.  I went to vpython for many good reasons - but since I had already
done the pyopengl work, not becuase it was "easy", or at least not
only becuase it was easy,  It was certainly faster. But also its window
is smart - one zooms from very near to very far effortlessly, but there is
some design in that effortlessness. The ability to work from the interactive prompt,
without worrying about windowing code, etc.  That is what make vpython vpython.

vpython without its windowing code can't be vpython, and pyopengl does
solv a thing there, but make us slower, to the point of being unreasonably
slow for some of the kinds of things vpython needs to do to be vpython.

Glut.

Thought of that and rejected it on the "it seems to easy" grounds.

David Scherer, the orignal author of vpython, I think was looking for the
simplest solutions, and he came to the project as a game hacker, I believe.

Just a guess that if glut could have worked he would have wnet that way.

Maybe I am wrong.

I guess the answer is the right open source answer.  Whoever does the
work gets to call the shots.

Just hope it's somebody - not other then, but in addition to - me.

All this from the Internet lounge in Seoul, Korea airport.

Art

> 
> Art wrote:
> 
> > Assuming that PyOpenGL *is* easy to install, we come back to 
> the same
> > question - an OpenGL windowing context, be it pygame, be it 
> wxWindows,> be it togl, be it gtkgl, be it whatever one does on 
> Mac. PyOpenGL
> > provides the functionality, given a windowing context, not the 
> 
> > windowing
> > context.
> 
> One problem with VPython is that it lives in a world all its 
> own, 
> unlike most Python libraries. PyOpenGL provides contexts for 
> PyGame, 
> for wx, and others (don't remember the whole list off-hand). If 
> VPython (or VPython-lite) were built on PyOpenGL it would 
> inherit all 
> of these abilities.
> 
> > And since much of the cross-platform complexity of vpython is 
> on the
> > windowing context issue, I see that solving that issue for 
> vpython 
> > is a
> > more direct approach to solving the problem. But again, to me 
> vpython> begins to lose its charm if we have to assume wxPython 
> installed, or
> > pygame installed, or Panda3d installed.
> 
> Well, there's assuming and there's assuring. A binary installer 
> for 
> VPython could simply make sure the necessary dependencies are 
> installed. A setuptools-based build chain could do the same.
> 
> > Togl across platforms???
> 
> The last time someone (Joe Heafner) tried to tackle this on the 
> VPython list, Bruce Sherwood replied:
> 
> > The fundamental issue has been discussed previously. Someone 
> with Mac
> > experience needs to write a small module to create a window 
> and handle
> > mouse and keyboard interactions. We have such modules for 
> Windows and
> > for Linux/Unix (alas, OpenGL doesn't provide this 
> functionality). 
> > In the
> > absence of this native-mode window/interaction module, we have 
> to limp
> > along using the Unix version, which means using X11.
> 
> Since that is exactly what GLUT provides, and GLUT is available 
> for 
> every port of OpenGL that I'm aware of, I don't even know where 
> to 
> begin with such a comment.
> 
> The other issue with VPython portability is threading. Instead 
> of 
> using Posix threads on Linux (which would *just work* on OS X), 
> they 
> pull in the gnome libraries for threading, adding an unneccesary 
> 
> dependency (in my opinion). GLUT alone doesn't really help with 
> 
> that, but it could be a (huge) step in the right direction.
> 
> --Dethe
> 
> "Why is Virtual Reality always posited in terms of space, when 
> time 
> is the only real commodity left?" --Rich Gold
> 
> 
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>