[Edu-sig] Learn to Program in Ten Years

[Kirby Urner]

> 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