A project of mine (http://scratch.mit.edu/projects/vnr/12853) behaves differently in the Java and desktop environments (like many other projects, apparently -- but my intent is to run an animation in the Java applet on a Web page). Everything works smoothly in the desktop; in the Java applet some timings are off, and some costume changes do not occur. Are there any workarounds for this (other than completely reconstructing my program flow to account for the differences) ?
Offline
The generic advice for making things work on both java and squeak implementations:
1) don't rely on the speed of execution for timing anything---use explicit wait statements or broadcast messages for synchronization.
2) make sure that every path through the body of a forever or forever if loop has a wait in it. This can be a "wait s seconds", "wait for <condition>", "broadcast and wait", "say for s seconds", ... If it is a "wait for <condition>" there needs to be something else on the path that waits for a mutually exclusive condition.
3) Make sure that the script works in presentation mode in the squeak implementation before trying it in the java implementation.
4) Expect the java implementation to be slower. (I don't know why the java implementation is so slow---perhaps daemons were not properly implemented and it is doing a lot of busy waiting??)
Offline
I appreciate the generic advice, and it'll certainly be helpful with future projects. Unfortunately (or fortunately?) there are no loops in this project (whether forever or repeat) and the scripts are positively dripping with waits, says, and thinks -- and the timing is still different in the squeak and Java executions. Have others noticed this kind of problem in these circumstances?
Offline
I think you could make this a lot more consistent and simpler if you let the start button drive everything using "broadcast and wait" blocks.
When start scan clicked
broadcast "start scan" and wait // this will wait until all "start scan" handlers are complete no matter how long they take
broadcast "row scan done" and wait
.
.
.
Then remove the other broadcasts from the end of other blocks.
I'm guessing that some handlers are reporting done before other handlers that received the same broadcast have actually finished.
Remember, handlers are not guaranteed to start at exactly the same time and some may be slightly slower than expected. If you depend on exactness of timing, you will be disappointed.
Offline