[Edu-sig] re: Pygeo, platforms, wx and Tk

[Arthur]

Doug, John, Tim, etal

Thanks for helping me kick this around.

Bottom line problem is that I am using threading without understanding
threads. I'm guessing my answer is somewhere in getting down a level into
the threads themselves, rather than trying to get away with only dealing at
the level of the objects being threaded.  

And now that I have a real problem to solve, I'll probably get down there
(eventually) and solve it

Like most of us, I'm sure, almost anything I understand about programming I
understand because I needed to understand it to solve a real problem. Even
if the problem is one self-imposed - like the PyGeo project.

But this is part of the reason that I think that the answer to the question
of more general programming literacy has to do with curricula integration.
To most students pursuing higher education, at least, the need to get their
mind around the concepts of, say, Calculus is a real problem.  They have not
chosen that problem any more than I have chosen the problem of threading. It
has chosen them.  They have to understand Calculus.  I think that
understanding a bit about programming can help them solve that problem, and
others of the kind.  

And it only at the point that they are solving *real* problems, even if only
for themselves, that they can get the sense of what it is to program and be
a programmer.

Art


> -----Original Message-----
> From: Douglas S. Blank [mailto:dblank at brynmawr.edu]
> Sent: Wednesday, December 15, 2004 12:16 PM
> To: John Zelle
> Cc: Arthur; edu-sig at python.org
> Subject: Re: [Edu-sig] re: Pygeo, platforms, wx and Tk
> 
> We have multiple threads interacting with a Tk window (Pyro Robotics).
> But it has proven very reliable---even without any locks of any sort. I
> did make sure that we only have one Tk interpreter; it is easy to
> accidently create more than one.
> 
> One situation does fail relably, however: on machines that have multiple
> processors, it seems that the Tk update code often steps on itself. I
> have tried to come up with a stripped-down example of the failure, but
> alas have not been able to pinpoint the problem.
> 
> -Doug
> 
> John Zelle wrote:
> > Arthur,
> >
> > In our VR work here, we do something very similar to what you are doing,
> > but in an impoverished way. We use a Tk panel to control simulations in
> > VPython. We have done this using threads and run on both Linux (our
> > primary platform) and Windows with no hitch. The main difference, I
> > think, is that we are not trying to communicate back from VPython to the
> > Tk panel. We can spin and zoom in the Vpython window, and control other
> > parameters through Tk. I guess I don't see any reason in principle that
> > the two-way communication shouldn't work.
> >
> > I suspect, can't tell without digging into your code, that the problem
> > is that you end up making Tk calls from two different threads. That is
> > strictly a no-no. It used to be the case that Tk calls could only be
> > made in the thread that did the Tkinter import. I think that it's now OK
> > to import, but only make calls in the thread the creates the main app
> > (calls Tk() to get the root widget).
> >
> > If you are not currently doing this, the next step to try is to create
> > the Tk interface in main program, and have that initial program call the
> > Tk mainloop. That means that the VPython stuff will actually be created
> > and run in the separate thread. As long as mainloop() is in your initial
> > thread (the one that imports Tkinter and grabs Tk()), I think that your
> > approach will work under Linux and Windows.
> >
> > If I get a little free time (hah!, it's finals week) I might try putting
> > together a little demo to see that this two-way communication works. By
> > the way, I hope you are using locks to protect any shared data across
> > the two threads.
> >
> > --John
> >
> > Arthur wrote:
> >
> >> Kent writes -
> >>
> >>> Thanks for the explanation. I didn't realize that the two panels are
> >>> using
> >>> different GUI frameworks.
> >>> I don't know how to make that work...
> >>>
> >>> Kent
> >>>
> >>
> >>
> >> Well, that's 2 of us anyway ;)
> >>
> >> I'm suspecting that I will have more flexibility when VPython moves
> from
> >> GTK1 to GTK2.  But that might too, be wrong.
> >>
> >> FWIW, Arnd had recently mentioned coming to a solution that included
> the
> >> ipython interactive shell, when Idle could not serve his needs -
> >> because of
> >> its use of sockets.
> >>
> >> It turns out I can't use ipython to serve my needs with VPython,
> >> because it
> >> suffers from the same disease as did the old Idle - and which Idle
> solved
> >> with the use of sockets. It closes when I close a VPython display
> >>
> >> Life sucks ;)
> >>
> >> Art
> >>
> >>
> >> _______________________________________________
> >> Edu-sig mailing list
> >> Edu-sig at python.org
> >> http://mail.python.org/mailman/listinfo/edu-sig
> >>
> >>
> >>
> >>
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
> >
> >
> 
> 
> --
> Douglas S. Blank,         Assistant Professor
> dblank at brynmawr.edu,            (610)526-6501
> Bryn Mawr College,   Computer Science Program
> 101 North Merion Ave,       Park Science Bld.
> Bryn Mawr, PA 19010  dangermouse.brynmawr.edu