[Edu-sig] The fate of vpython

[Dethe Elza]

On 10-Oct-06, at 3:54 PM, ajsiegel at optonline.net wrote:

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

Simplest case, you run it using GLUT.  You also have the option to  
use wx, pygame, or Cocoa (native OS X).  In any of these cases, you  
do not need to install or run X windows.

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

I agree that anything which claims to be (or emulate) VPython would  
have to behave the same (and as simply).  No argument there, I'm afraid.

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

Yes.  On OS X today it VPython does not do that.

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

I think you used to.  The ctypes-branch is quickly replacing the swig  
version, and ctypes is part of the python standard library as of  
Python 2.5.  I feel that ctypes is also easier to understand than  
either swig or boost, but maybe that's just me.

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

There is a series of steps you could use to build VPython using Fink  
that may or may not work anymore. The resulting VPython brings in  
lots of linux libraries and runs under X Windows (i.e., it neither  
looks, nor feels, nor runs like a native OS X application).  I'm not  
aware of any binary installer for this multistep process.  Despite OS  
X having a great OpenGL implementation (OpenGL is the basis for *all*  
graphics on OS X) and standards support, it is a second-class citizen  
in VPython's little world.

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

No one is debating this.

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

Maybe.  I think a pure-python (which PyOpenGL-ctypes will be, relying  
on nothing outside of the standard library) version of VPython would  
be useful, even if you need to go to a C++ version of VPython for  
Really Big Models.

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

A game hacker would likely dismiss Glut out of hand, because you  
would never use it for games.  You might use it for a windowing  
toolkit for physics students, though.  Perhaps there were other  
reasons for the VPython team not using Glut, so this is idle  
speculation.

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

Again, I think there could reasonably be multiple implementations, if  
someone were willing to write the code.  It works for ElementTree/ 
cElementTree/lxml.  The VPython API is not all that complex, after all.

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

I keep hoping that too (somebody other than me), but it hasn't  
happened yet.  Once I clear a few other projects off my plate I will  
roll up my sleeves and try again.

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

Arriving or departing?

--Dethe

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


Art is either plagiarism or revolution. --Paul Gauguin