My response to something Grégoire sent me this off-list is below. My off-list response to him bounced. I see no reason why he would mind me posted it up so I take the liberty to do so. Apologies if Grégoire feels otherwise. Not something I generally like to do, but see no reason in this case why he would be all sensitive to it. Art
-----Original Message----- From: Arthur [mailto:ajsiegel@optonline.com] Sent: Saturday, March 25, 2006 10:29 AM To: 'Grégoire Dooms'; 'Arthur' Subject: RE: [Edu-sig] Properties use case
-----Original Message----- From: Grégoire Dooms [mailto:dooms@info.ucl.ac.be]
What is the question you ask here ? Do you want a certification that you have done your PyGeo The Right Way (tm) ?
No. I see no issues and have some confidence in my overall design. People with more depth on some of these issues than I seem to be concerned that I am overconfident. I am simply trying to understand better why.
*I* raised none of these questions. I raised what I understood to be a very specific, and - yes - technical issue about Numeric's typing mechanism. *I think* that *if* Numeric were to accept my custom type as a pseudo-complex type rather than something as general as a Python object, and processed it *as if* it were equivalent to a Python complex primitive, no harm would come to the calculations being performed and my ideas for the design I am pursuing, and am generally comfortable with, would proceed in an optimal manner. I am not *sure* that this is true. But even that question is not the question I raised. I was simply hoping to get far enough to be able to get some sense of whether it is true. I would be curious to learn why it is not, if it is not. But have no way of learning that if it is not even implementable.
My question whether was and is - Is anyone aware, or could imagine, a mechanism that would allow me to coerce Numeric to process my custom type as a complex primitive while maintaining object identity?
I have taken the silence as a *no*, a not terribly surprising *no*, and have begun to think about the implications of that *no* on my overall thinking about my overall design.
I take reasonability for my design, but feel it not responsible to look-the-other-way when folks more experienced than I seem to have reasons to doubt its integrity - from the little I have said about it. Doubts have been raised and I am not looking-other-other-way.
How do you store the dependency graph ? Is it cycle free (a DAG) ? How do you decide which objects need to be repainted when an other object is changed ? What is the overall design of the application ?
Other then not knowing what a DAG is, I feel that the other issues you raise are under control in some reasonable way. Part of the Fun (tm) of doing PyGeo has been not just to find my way to solutions - first I needed to find my way to the issues. Eventually the issues seem to identify themselves, and in general the one's you raise have done so.
Nothing yet (before these discussions) raised to me the issue of the thread safety of my geometric objects. Therefore I have not considered it to be an issue.
I call the style in which I have approached the development of PyGeo - tongue-in-cheek - Naïve Programming. It's been a fascinating experience.
But I am sincerely trying to inquire whether there could be something fundamental I have missed by this approach - only because the issue has been raised - presumably sincerely - by others. Perhaps it is so subtle as to be unidentifiable except under Extreme Circumstances (tm). Perhaps it doesn't exist.
No I do not lock my circle.
Do you use threads ?
In one sense, and it depends.
There is the *option* of running a TK control panel that provides functioning to control more aspects of the interactivity with the rendering window than can be controlled directly from the rendering window itself. These are more in the nature of changing some global settings on-the-fly, then they are about interactivity with the rendering and interactivity on a micro-second by micro-second basis - which, whether the control panel option is or is not selected - run together in one thread. In my conception of what is taking place, at least.
Thanks for your interest in my question/dilemma.
Best, -- Grégoire
Arthur wrote:
My response to something Grégoire sent me this off-list is below. My off-list response to him bounced. I see no reason why he would mind me posted it up so I take the liberty to do so. Apologies if Grégoire feels otherwise. Not something I generally like to do, but see no reason in this case why he would be all sensitive to it.
No I do not lock my circle.
Do you use threads ?
In one sense, and it depends.
There is the *option* of running a TK control panel that provides functioning to control more aspects of the interactivity with the rendering window than can be controlled directly from the rendering window itself.
AFAIK, you won't have any problems as Tk is single threaded and explicitely forbids to call any Tk related function from an other
No problemo. I just forgot to cc the list. thread. So unless you spawn an other thread yourself and make it interact in a non-atomic way with your objects you should be safe as the Tk mainloop will call your functions/methods in a sequential way.
Thanks for your interest in my question/dilemma.
You are welcome. -- Gregoire
participants (2)
-
Arthur -
Grégoire Dooms