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.

Cheers,

Alan

------

At 7:57 PM +0200 4/5/03, Stephane Ducasse wrote:
>Hi andreas
>
>>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
>>over time
>
>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
>>concurrent task.
>
>
>
>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 .....
>
>>
>>Cheers,
>>   - Andreas
>>
>>
>Prof. Dr. Stéphane DUCASSE
>http://www.iam.unibe.ch/~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 
>earth" Calvin&Hobbes
>
>"The best way to predict the future is to invent it..." Alan Kay.
>
>Open Source Smalltalks: http://www.squeak.org, 
>http://www.gnu.org/software/smalltalk/smalltalk.html
>Free books for Universities at 
>http://www.esug.org/sponsoring/promotionProgram.html
>Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html


--