I had written -
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
Was able to spend some time on this today. Explored what I could find about threading and Tk, and learned (I think) - among other things - that the problem I was running into seems to (somewhat ironically) be the result of tcl implementing threading in 8.4 (and that the reason it was not cropping up on Windows is not a os issue, I'm thinking, but that tcl/tk is compiled on Windows without threading support) Whether the above is right or wrong ... I seem to have found a simple solution without going deeper in an implementation of threads, and qeues, and locks and semaphores and such. I start the TK thread from the VPython GTK Display class, sending "self" as a parameter to the Tk ControlPanel class. No problem here, as long as I don't try to start the TK mainloop from here. The Tk ContolPanel now has a reference to the Display and can send messages through that reference. The mainloop() call is from within __init__ of the Tk Control Panel. I had gotten that far before. Turns out, to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel class, so that now Display has a reference to the ControlPanel by which it can send messages of its events back in that direction. My first ever use of setattr. Knew it was there for something ;) Tidy and simple, I think. And I *do* have fun with Python. Art
Arthur wrote:
... to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel class, so that now Display has a reference to the ControlPanel by which it can send messages of its events back in that direction.
My first ever use of setattr. Knew it was there for something ;)
Hmmm.... Outside of playing with setattr, why not use: Display.control_panel = self -- -- Scott David Daniels Scott.Daniels@Acm.Org
On Sat, 2004-12-18 at 15:56 -0800, Scott David Daniels wrote:
Arthur wrote:
... to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel class, so that now Display has a reference to the ControlPanel by which it can send messages of its events back in that direction.
My first ever use of setattr. Knew it was there for something ;)
Hmmm.... Outside of playing with setattr, why not use:
Display.control_panel = self
Because then the solution to my Big Problem looks *too* simple ;) Interesting, relative to our prior exchange, that I needed to get some handle on the potential next-level-down solutions, before the obvious at-this-level solution dawned on me. Recently had explored what is involved in deepcopying a relatively complex class, before I realized that the actual solution to my actual problem needed no such hairy mechanism. Part of the problem of being half-smart when it comes to these things, is never being sure at what level the solution to my problem lies - the level at which I work comfortably or at a more occult (to me) level. On the other hand I am sometimes forced into some ingenuity in the use of what I *do* know, and feel I sometimes end up with something that avoids being more occult than necessary - whereas someone more comfortable at those levels may have immediately jumped there for a solution. Or not. Art
Arthur wrote:
On Sat, 2004-12-18 at 15:56 -0800, Scott David Daniels wrote:
Arthur wrote:
... to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel... My first ever use of setattr. Knew it was there for something ;)
Hmmm.... Outside of playing with setattr, why not use: Display.control_panel = self ... On the other hand I am sometimes forced into some ingenuity in the use of what I *do* know, and feel I sometimes end up with something that avoids being more occult than necessary - whereas someone more comfortable at those levels may have immediately jumped there for a solution.
OK, I was doing two things, (1) suggesting another simpler (more readable) form, and (2) honestly asking whether this was, in fact, a reasonable substitution, or whether there was a consideration that I hadn't understood. I always wind up with crappy code on my way to programs I like. Writing code, like writing English, is a process of inspiration and rework. I like the process in code, and hate the same process for writing English. Probably for two reasons. First, I have been harassed while writing English so often that I hear all such nonsense when I write. This is really the effect of bad teaching. Second, I am a prolific reader, and I very much appreciate good writing at the caliber of "the dozen best in a century." I read my writing and I notice a dramatic distance between my best and their (published) worst. Tough competition. -- -- Scott David Daniels Scott.Daniels@Acm.Org
Scott write -
Arthur wrote:
On Sat, 2004-12-18 at 15:56 -0800, Scott David Daniels wrote:
Arthur wrote:
... to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel... My first ever use of setattr. Knew it was there for something ;)
Hmmm.... Outside of playing with setattr, why not use: Display.control_panel = self ... On the other hand I am sometimes forced into some ingenuity in the use of what I *do* know, and feel I sometimes end up with something that avoids being more occult than necessary - whereas someone more comfortable at those levels may have immediately jumped there for a solution.
OK, I was doing two things, (1) suggesting another simpler (more readable) form, and (2) honestly asking whether this was, in fact, a reasonable substitution, or whether there was a consideration that I hadn't understood.
I appreciated your comment, and I hope you understand that I was poking fun at myself, because: 1. Your substation is simpler and more readable. 2. I see no reason it doesn't work exactly as well. 3 My post was patting myself on the back for finding a simple solution to my problem, when there was an obvious further simplification staring me in the face, and I was overlooking.
I always wind up with crappy code on my way to programs I like. Writing code, like writing English, is a process of inspiration and rework. I like the process in code, and hate the same process for writing English. Probably for two reasons.
PyGeo is on its eightieth round of refactoring. In my case the issue is three fold 1. the normal issues involved in finding one's way to simple, maintainable, readable and efficient code. 2. I am learning as I go - so I can have code refactored down to nearly its best form, based on what I know and find that new possibility open up, when I know more. 3. Python's evolution. Python2.3, e.g., may well present opportunities to simplifier the code that was not present in Python2.2. At my normal billing rates, PyGeo is a $1m project. ;) Art
participants (2)
-
Arthur -
Scott David Daniels