Help with morph and world refresh
Alan.Kay at squeakland.org
Sat Apr 5 18:07:39 UTC 2003
I still think that the Etoy control framework should be *adapted* for
this since it has been working perfectly well for 5 years. Or it
should be done in the context of the Croquet stuff.
At 7:57 PM +0200 4/5/03, Stephane Ducasse wrote:
>>Hm ... sounds almost like "I'm amazed to see how difficult it is to do a
>>stupid small program in Squeak which requires object orientation (ok, I
>>don't use objects)" ;-)))
>>For your example, you should actually come up with a model of what it is
>>your bots are doing.
>This is what I'm trying to do now because I always fall in the trap that
>I end up with concurrent objects executed in various implicit
>thread. I got the same problem with the animation for the turtle.
>The problem is that I want plain normal code to be able to be
>executed and not just a subset of well identified methods.
>Nathanael wrote several version of the AnimatedTurtle just because
>we had problem with the user interaction event and condition
>breaking the animation.
>>As you are talking about animation, you are also
>>talking about time. In other words - if you don't tell your bot how fast it
>>can do its work, then you're just assuming that it's infinitely fast and, of
>>course, you will not see any progress during the simulation. The best way to
>>handle this is by assocating time with the object directly so it can evolve
>Do you mean something similar to stepTime telling to a scheduler the
>frequency to be executed?
>>(not surprisingly, this is exactly what TeaTime in Croquet is
>>about) and effectively have the system visualize its state "as often as it
>>can" rather than explicitly.
>>Given that this is not exactly trivial (but noone said that graphics is
>>trivial, eh?!) you may want to have a more discrete model of what your bots
>>are doing (for example: "a bot can #go once per frame"). Given only a single
>>bot, then #displayWorld or similar in the right places will work perfectly
>>fine (and are utterly trivial). If you don't - e.g., you want users to be
>>able to interact with your objects, or have many of them - then you simply
>>have to be concurrent or how else would your objects _actively_ control what
>>is going on? So that, by the end of the day, your problem can only be solved
>>in a "good object-oriented way" if you realize that it is an intrinsically
>I know. I got exactly the same problem with my turtle morph
>(multiple turtle running in parallel with user interaction and world
>update)but the solution was rather complex. I would like to avoid to
>fall into that complex solution again
>So what would be solution? in the turtle I do not remember the
>number of approaches I tried like having one thread per object,
>object yielding .....
>> - Andreas
>Prof. Dr. Stéphane DUCASSE
> "if you knew today was your last day on earth, what would you do
>different? ... especially if,
> by doing something different, today might not be your last day on
>"The best way to predict the future is to invent it..." Alan Kay.
>Open Source Smalltalks: http://www.squeak.org,
>Free books for Universities at
>Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
More information about the Squeak-dev