visualpython-users

[Visualpython-users] Progress toward wxPython

[Bruce S. <Bru...@nc...>]

Some time ago I mentioned my intention to build a version of VPython
that uses wxPython to create the window, establish an OpenGL context
in that window, and handle keyboard and mouse events. This would make
it possible to discard the existing three platform-specific C++
components for dealing with these tasks (Windows, Macintosh, Linux),
because wxPython, based on wxWidgets, is platform-independent.

The need for this is somewhat urgent, because the Mac version of
VPython is based on the Carbon framework, which is no longer fully
supported. In particular, Carbon cannot be used with 64-bit
applications (one must use Cocoa), which means that at the moment it
is impossible to build a native-Mac (not Unix) version of VPython for
the Mac that can run with a 64-bit version of Python, and until very
recently there seemed to be no way to base VPython on Cocoa, for
technical reasons (see below).

I'm pleased to say that I've managed to get a basic wxPython-based
version to work, with the platform-specific C++ components replaced by
pure Python code. There are many remaining details to deal with, but
I'm able to display an animation, and to rotate and zoom the scene.
Progress.

Looking ahead, here are some comments about what a wxPython-based
version of VPython will look like.

First, it is likely that all animations will have to contain a rate or
sleep statement. This is due to a very technical issue. Cocoa requires
that Cocoa itself be the primary thread, whereas the current VPython
makes Carbon be the secondary thread. To turn this architecture
inside-out required some fancy footwork, and the summary statement is
that the visual module and your user code are likely to be in a single
thread, with no multithreading. This simplifies the VPython
architecture, but requires the user to use rate (or sleep) to allow
VPython to render the scene periodically. Without a rate statement in
an animation loop, nothing will appear on the screen until you exit
the loop, and then you'll see only the final state of the display. I
judge that the need for rate isn't serious, because almost all
animations necessarily contain a rate statement anyway, to make the
animation run at a roughly machine-independent speed. Experience with
GlowScript (glowscript.org), which also requires use of rate (because
JavaScript doesn't have threads), suggests that requiring a rate
statement isn't a significant burden.

Second, it should be possible to place a 3D animation anywhere in the
window, place other wxPython widgets in the same window (e.g. buttons,
sliders, text, etc.), and create normal pull-down menus for the
window. This suggests that VPython should have two new objects, a
"window" object (to hold menus and the various widgets), and a
"canvas" object (to provide the OpenGL context for the 3D animations.
The existing VPython "display" object would remain as a device that
creates a "window" object and places a "canvas" in the window in such
a way as to fill the window, as is the case currently.

Third, there currently does not exist a version of wxPython for Python
3.x, just 2.x, but on May 24, 2012, there was news that this is
forthcoming:

   http://www.blog.pythonlibrary.org/2012/05/24/wxpython-for-python-3-is-almost-here/

Fourth, presumably the new VPython will have the version number 6.00,
to emphasize a change in the definition of VPython, namely the
necessity to use rate in animations.

Bruce Sherwood

Re: [Visualpython-users] Progress toward wxPython

[Mark A. <dre...@gm...>]

On Fri, Oct 19, 2012 at 11:03 PM, Bruce Sherwood
<Bru...@nc...> wrote:
> I'm curious: I don't know what you're referring to when you say that
> the problem is Guido not accepting "visual as part of the standard
> library". What old debate are you referring to? (Incidentally, Guido
> has always said nice things to me about visual.)

I'll try to look it up, but is was about float division.  It seems
trivial but I remember afterwards how a whole segment of the python
community seem to disappear.   That is, before the faction VPython and
Python were in the same group, but afterwards VPython receded from the
python-dev community.

> I agree that making visual a part of the standard library would make
> sense. But the problem I'm trying to address wouldn't have been helped
> by visual being in the standard library -- there would still be the
> serious Carbon/Cocoa problem to be solved.

Yes, but I think the way VPython attracts young programmers, that
there would be a whole support network.

> Incidentally, you might be mildly amused by the "fancy footwork" I
> alluded to. Briefly, when the user program invokes the visual module,
> I set up the interact loop (Cocoa on the Mac), then I import the
> user's program! This makes Cocoa the primary thread (and only thread),
> which is a requirement of Cocoa. This also means that any user
> statements preceding the visual import will be executed twice, which
> is unlikely to be a problem (and can be documented), and no statements
> in the visual module will be executed twice because once a module is
> imported in a session, executable statements are not re-executed by a
> later import in the same session.

Thanks, that is interesting.  I have been debating some of the
abstract parts of these issues in the thread on event loops and
asynchronous support in Python (happening recently in the python-ideas
list with Guido).  I think one of these has to be given up
[multi-platform, speed, abstracted (uniform) API] -- at least until
there's a unified pythonOS that is also a WebOS...

Mark

Re: [Visualpython-users] Progress toward wxPython

[Bruce S. <Bru...@nc...>]

I can correct the history. David Scherer created VPython in the spring
of 2000 while a sophomore at Carnegie Mellon. The year before, he had
taken intro physics from Ruth Chabay and me (see
matterandinteractions.org), in which we had students write programs in
the 2D programming language cT I had created. Scherer proposed a much
improved 3D programming environment which, amid lots of discussion
with Chabay and me, he implemented.

Soon it became evident that a significant stumbling block was the fact
that in Python, as in so many languages (but not JavaScript) 1/2 was
0, not 0.5. This caused lots of trouble for our physics students, so I
proposed to the Python community that 1/2 be 0.5 instead of 0. That
was a trigger for lots of debate among Python developers, who
eventually found that they had their own reasons for making the
change.

There has never been a "VPython development community". in 2001
Scherer went off and founded a successful business. In 2002 I moved to
North Carolina State University, where an undergraduate student,
Jonathan Brandmeyer, got interested and made large contributions to
the further development and maintenance of VPython until he graduated.
In 2008 VPython needed significant work, and quite fortuitously
Scherer, between building companies, volunteered to work again on
VPython, and for about a year we collaborated on what became VPython
5.0 before he started a second company. All during these 12 years I
have been involved in development and maintenance, and for the past 4
years I've been the only major developer. (From time to time various
people have contributed in important but relatively small-scale ways.)

So the "VPython development community" has fluctuated between 1 and 2
people, and this infinitesimal group never "receded from the
python-dev community", of which it was never a part.

As for "VPython attracts young programmers", I've been disappointed
that Brandmeyer was the only new person, young or old, to get deeply
involved with VPython development after its creation.

I don't understand your pessimism, that one must abandon multiplatform
or speed or API. I would certainly like to see higher Python execution
speed, and I realize there are efforts under way. The new VPython will
certainly continue to be multiplatform, with the same API except for
rate being obligatory rather than optional.

As for a unified operating environment, I'll point to GlowScript
(glowscript.org), which is very similar to VPython but runs in a
browser. It is based on Javascript (or optionally CoffeeScript) and
uses in place of OpenGL (used by VPython) the similar 3D graphics
library WebGL, which is part of current browsers. GlowScript now has
capabilities roughly comparable to VPython. Not coincidentally, it has
been built by David Scherer and me, though Scherer has not been able
to work on it for some months, being deeply involved in his new
company (foundationdb.com). It has been a great joy to work in an
environment where thanks to being browser-based it was truly trivial
for GlowScript to work automatically on Windows, Mac, and Linux.

There was a recent event quite parallel to the 1/2 = 0.5 issue. In
JavaScript you cube a value x by writing Math.pow(x,3). Yuck. The
CoffeeScript developers had been considering whether to implement
x**3, and the additional arguments I presented pushed them over the
edge. There is a new CoffeeScript compiler to be released soon,
CoffeeScript Redux, which implements x**3. Here is a link to that
discussion:

   https://github.com/jashkenas/coffee-script/pull/2026

Bruce Sherwood

Re: [Visualpython-users] Progress toward wxPython

[Mark A. <dre...@gm...>]

On Sat, Oct 20, 2012 at 7:23 PM, Bruce Sherwood <Bru...@nc...> wrote:
> Soon it became evident that a significant stumbling block was the fact
> that in Python, as in so many languages (but not JavaScript) 1/2 was
> 0, not 0.5. This caused lots of trouble for our physics students, so I
> proposed to the Python community that 1/2 be 0.5 instead of 0. That
> was a trigger for lots of debate among Python developers, who
> eventually found that they had their own reasons for making the
> change.

Thanks for the recollection.  The reason I said it was a significant
break, is that with that debate/faction, [my sense was] a fork between
physicists, who were looking at high-level programming languages as
both a pedagogical tool and modeling tool (beyond its historical use
as a calculating tool), and the computer science crowd, who were
looking at languages from a completely different light within both CS
theory and programming language design (in which Python was a recent
and novel contribution), occurred because of an unresolved debate
about the importance of floating point (for the Phys crowd) and
historical "prejudices" in comp science crowd about having unambiguous
"round numbers".

To me, this was a bit split, and although it was relegated to the
__future__ and is the default in python3, the "future", if you will,
still hasn't seemed to have happened yet.

> There has never been a "VPython development community".

I understand that it has been small, but I don't know if you're aware
how much silent support you guys had in the simulation and modeling
crowd.  Though they weren't participating directly in vpython
development, they were waiting in the background -- hedging for a
major language adoption, so that they could [re-]invest their
"holdings", so to speak.   Much like a bunch of financial investors
eyeing at a new country which is evaluating a choice at instituting a
democratic, free-market system.  Judging from your message, I don't
think you ever saw that, but yet I know that it was there.  I think
Guido sensed it, but in the end his computer science bias simply won.
With that win, many turned away.

> So the "VPython development community" has fluctuated between 1 and 2
> people, and this infinitesimal group never "receded from the
> python-dev community", of which it was never a part.

This is the source of my lament, Bruce -- it was on the verge of
becoming a major synthesis and collaboration between two major groups
(comp sci and physics/modeling).

> As for "VPython attracts young programmers", I've been disappointed
> that Brandmeyer was the only new person, young or old, to get deeply
> involved with VPython development after its creation.

I meant that 3-d graphics, in the easy way that vpython makes it, adds
a very cool "gee-wiz" factor that is hard to beat.  Young programmers
eat that stuff up, and it acts as a magnet that attracts more
development.

> I don't understand your pessimism, that one must abandon multiplatform
> or speed or API.

I mean that the OS carries its *own* event model and sits between
python user-space and the hardware.   It has its *own* ideas of how
I/O should be scheduled, managed, and accessed (that is the *business*
of the OS after all!).  This makes it difficult to be multi-platform
without sacrificing either raw speed or consistent API abstraction
(two ends of the hardware <--> user "stack").

> As for a unified operating environment, I'll point to GlowScript
> (glowscript.org), which is very similar to VPython but runs in a
> browser. It is based on Javascript (or optionally CoffeeScript) and
> uses in place of OpenGL (used by VPython) the similar 3D graphics
> library WebGL, which is part of current browsers. GlowScript now has
> capabilities roughly comparable to VPython. Not coincidentally, it has
> been built by David Scherer and me, though Scherer has not been able
> to work on it for some months, being deeply involved in his new
> company (foundationdb.com). It has been a great joy to work in an
> environment where thanks to being browser-based it was truly trivial
> for GlowScript to work automatically on Windows, Mac, and Linux.

I've been following your developments with glowscript and with all the
hype of HTML5 and WebGL.  I like those experiments, because I think it
keeps vpython in the public consciousness to some degree, but I really
think WebGL will go the way of VRML (remember that?); i.e. a powerful
tool that no one knows how to exploit properly.

...Which bring me to the (real) point underlying all of this.  As you
might remember, I was at the Santa Fe Complex, trying to develop a
tool to make this nascent phenomenon of "hackerspaces" work -- a tool
to link people and projects together in a visual way, solving once and
for all the scaling problem that happens when you get to about a 1000
objects.   Slashdot, digg, del.icio.us, etc. -- all have suffered from
the "paucity of dimensionality" that HTML is.

Current HTML offers about 2.3 (fractal dimensions) of representing
linked data (i.e. "hypertext").  VPython (or WebGL, in theory), could
break the web about of the 2-d box and create a 3d *Presentation*
layer for the WWW allowing the visual cortex to make relationships
between data rather than hand-crafting RDF.  I call this Internet II,
and if I could just get the event-model understood in VPython, I would
have a working demo in short order, but that has been driving me up
the wall because the paradigm between my "python self" and my "vpython
self" is currently dissociated for reasons I've been alluding to.

Anyway, you don't need to break time away from vpython development,
but I do think it would re-vamp the web out of its current suburbia
and re-ignite the creative economy.

Thanks for your time,

MarkJ
Gothenburg, Nebraska

Re: [Visualpython-users] Progress toward wxPython

[Bruce S. <Bru...@nc...>]

Well, I may be completely oblivious and ignorant, but I really can't
imagine that there was some "split" involving VPython. The Python
developers rather quickly on the scale of things decided to make 1/2
be 0.5, for their own internal reasons. I think that the change had
little to do with the request from someone (me) who at that time had
no standing whatsoever, for the sake of something called VPython,
which at the time had close to zero users and was hardly known. It was
impossible for Python to make an immediate change, due to backward
compatibility issues. In my view that community has done an admirable
job in dealing with this issue, even though it has taken much longer
than one would prefer.

There could have been some kind of split between integer-oriented
computer scientists and floating-point-oriented computational
scientists, but about the major development numpy (and its
predecessors), not the minor development VPython. One could make
cogent arguments for numpy having been part of Python. Despite that,
there is a flourishing community of scientific Python users, the most
visible component being scipy.org and the Sage project. In recent
years there have been two whole issues of the journal "Computers in
Science and Engineering" devoted to Python. A few years ago one of the
astrophysics groups at NCSU abandoned the numerical package they had
been using and switched to Python. Etc. All of which says that the
computational modeling folk were not pushed away from Python by some
hypothesized resistance from Guido and fellow developers.

Bruce Sherwood

Re: [Visualpython-users] Progress toward wxPython

[C A. R. <an...@xt...>]

On Sat, Oct 20, 2012 at 9:47 PM, Mark Adam <dre...@gm...> wrote:
> On Sat, Oct 20, 2012 at 7:23 PM, Bruce Sherwood <Bru...@nc...> wrote:
>
>> As for "VPython attracts young programmers", I've been disappointed
>> that Brandmeyer was the only new person, young or old, to get deeply
>> involved with VPython development after its creation.
>
> I meant that 3-d graphics, in the easy way that vpython makes it, adds
> a very cool "gee-wiz" factor that is hard to beat.  Young programmers
> eat that stuff up, and it acts as a magnet that attracts more
> development.

perhaps a bit random...

vpython is actually the reason i forced myself to learn python.  i was
indeed fascinated by the simplicity and power of it all, and my foray
was a re-implementation of [ruby] gltail that i sadly never finished,
albeit learned a ton... been lurking on the list ever since...
something like 3-4 years or so.

i suppose i'm not suuuuper young @ 25yo; i've been a full-time
developer for ~5-6yrs -- the last two purely python -- i credit
portions of the latter to vpython's alluring brilliance, and the rest
to python's own inherent magnificence.

sadly i have not contributed much of anything concrete, due mostly to
the ever-lasting-excuse "lack-of-time" and "other-projects" and [...],
but i recently gave a demo of vpython for ~45 other developers
(Perl/PHP/JS primarily) at work that was extremely well received --
spheres orbiting a "gravity well" -- where each sphere represents (and
responds+morphs to) events/messages occurring on the company -wide
message queue (rabbitmq)... so after little more than ~200 lines of
glue and glitz, i demo'ed a real-time visualization of human
"busy-ness"... the events in question were ~600 call center agent
status changes (hold/waiting/busy/incoming/cool-down/etc) from a
facility several hundred miles away.

needless to say, and despite it's obvious simplicity and/or lack of
any real practical use, it still irradiated onlookers with "very cool
`gee-wiz` factor" and piqued the interest of everyone around --
non-developers alike -- and ultimately led to some
chatter/buzzing/exploring the possibilities.

apologies on the length; hopefully a little success story at the very
least!  even my 3yo son asks me to "play the balls" for him pretty
often still, and doing so gets many-a-"wows" and "that's cool dad"
sent my way :)

visual-python FTW!

-- 

C Anthony