Re: Visual Python, OS X source build, Homebrew dependencies

Currently there are many novice programmers using VPython, including
several thousand physics students being introduced to computational
modeling in the "Matter & Interactions" curriculum
(matterandinteractions.org). These users expect a standard install
procedure and a native look and feel. At the moment this is impossible
on the Mac because VPython is built on Carbon but 64-bit Python
requires a VPython built on Cocoa.

The problem is that Cocoa is required to be the primary thread,
whereas the VPython architecture requires the GUI component to be a
secondary thread. Until very recently there didn't seem to be any way
around this. Recently however, with lots of excellent help and advice
from the wxPython community, I've found a solution in principle,
though I haven't yet implemented it.

The scheme is bizarre but it works in a simple (non-VPython) test case
on all platforms, including Mac Cocoa. Suppose your program is in a
file that contains an import of visual and a rotating box in a
rate-limited while loop. The import of visual sets up the wxPython GUI
machinery but does NOT start the interact loop. The visual module next
imports your program (!) and after this import has its own infinite
while loop. Here's a sketch of the visual module:

* Set up GUI machinery
* Import user program
* while true: rate(30)

Note that if your program ends, execution falls through to the visual
module's while loop, which leaves the graphics window still active,
with zoom and rotate still available.

In your animation loop you call the rate function, which at
appropriate times calls a one-shot interaction with Cocoa, developed
by Robin Dunn, the creator of wxPython. This processes events and
renders the current scene. There are no threads! It's all done by
polling, and requires that animation loops contain rate statements,
something that's pretty universal anyway, and has seemed okay in the
new GlowScript project, too (glowscript.org). Moreover, it addresses
the current problem that a long scene setup may display a partial
scene due to interrupts by the secondary GUI thread.

(Minor point: any code in your program that precedes the import of
visual will be executed twice, which needs to be explained. This is
pretty innocent if the repeated code consists just of imports of
Python modules, because no calculations in those modules will be
repeated.)

What remains is a fair amount of work to replace the current GUI
machinery with this scheme, which has the added advantage of being
based on wxPython which will provide such features as pull-down menus,
etc.

Bruce Sherwood

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/