RE: [Edu-sig] Learn to Program in Ten Years
On Sun, 2004-12-26 at 15:43 -0800, Kirby Urner wrote:
As to wxPython, I'm afraid it just failed a test of some importance to me. VPython does not run interactively from PyShell or PyCrust. It just hangs. It does run interactively from the native prompt and from the Idle prompt.
Hence my cc to the wxpython dev list, mentioning VPython, and the "would be nice" prospect of integrating it more effectively.
But I think you are talking about something more ambitious than the issue that is my immediate concern. Simply running VPython as one would anything else from the prompt does not imply any real level of integration. On the contrary, it seems that the shell and VPython need to successfully get out of each others' way. And the problem is they don't. Subprocesses, threads, or something. Anything that moves toward real integration would I suspect need to have most of its work done from the VPython side. Apparently VPython is quirky, greedy as it is - since it gives a lot of things that don't normally have trouble, trouble. PythonWin I think is another example. Closing a VPython window closes the IDE with it. Idle went to some lengths to accommodate VPython and prevent this. But it complicated the Idle architecture considerably. As a response to John's concerns I tried to look at the code that runs a script from Idle - and you have threads talking to subprocesses talking to sockets. Totally out of my league to try to truly follow, which is a kind of a shame. I wonder what, if anything, could be done from the VPython side to make it friendlier, without it losing it's uniqueness. Understanding that part of that uniqueness is the fact that the display is just implicitly there. As you know,
import visual visual.sphere()
is sufficient to create not only a sphere() but an entire rendering context and display for itself. I am guessing that is accomplished in ways other programs needing to cooperate with VPython tend not to like. I am at a loss to chip in to finding a solution. But a weekend spent trying to get deeper into boost::python and GTK indicates some real interest in the problem, and at least good intentions ;) Art
But I think you are talking about something more ambitious than the issue that is my immediate concern.
Yes, true. I'm imagining a version of PyGeo with a fixed frame for VPython, and controls around the edges, more like a traditional app, with everything packed. I'd like to see that version, vs. the current approach of free-floating control panels in Tk. I'm thinking of a more buttoned-down, traditional look.
Simply running VPython as one would anything else from the prompt does not imply any real level of integration. On the contrary, it seems that the shell and VPython need to successfully get out of each others' way. And the problem is they don't. Subprocesses, threads, or something.
Yeah. Competing event loops probably.
Anything that moves toward real integration would I suspect need to have most of its work done from the VPython side. Apparently VPython is quirky, greedy as it is - since it gives a lot of things that don't normally have trouble, trouble. PythonWin I think is another example. Closing a VPython window closes the IDE with it. Idle went to some lengths to accommodate VPython and prevent this. But it complicated the Idle architecture considerably. As a response to John's concerns I tried to look at the code that runs a script from Idle - and you have threads talking to subprocesses talking to sockets. Totally out of my league to try to truly follow, which is a kind of a shame.
Whatever happened to the scenario in which VPython gets a big grant to improve a great deal? Didn't that pan out? It'd seem that one broad category that could use some work, in the VPython side, is "plays well with others."
I wonder what, if anything, could be done from the VPython side to make it friendlier, without it losing it's uniqueness. Understanding that part of that uniqueness is the fact that the display is just implicitly there. As you know,
I have the same question.
import visual visual.sphere()
is sufficient to create not only a sphere() but an entire rendering context and display for itself. I am guessing that is accomplished in ways other programs needing to cooperate with VPython tend not to like.
I bet you're right.
I am at a loss to chip in to finding a solution. But a weekend spent trying to get deeper into boost::python and GTK indicates some real interest in the problem, and at least good intentions ;)
Art
Yeah, s'been an interesting and productive thread. Thanks for keeping it turning. Kirby
participants (2)
-
Arthur -
Kirby Urner