Trouble Shooting Color Change

Originally Posted by DrJim

Thanks for the nice example. Demonstrating my basic ability to make good code inoperable - see the attached, which, when "D" is pressed and released, stops and gives an error message much the same as for as the walk and bumper car examples.

All I did was add an indexed loop to the dance method. Hence, when the "D" key is released, the method stops in mid-loop. Apparently this isn't a good idea as far as Alice is concerned (and I tend to agree - just wish the error message was clearer ).

This reminds me of when I used to go on business trips and land in a strange city late at night and be faced with driving and trying to read the street signs and read a map all at the same time. At least then I was able to get a map from the car rental agency. When something strange like this happens with Alice, there is no map to refer to, so it is guesswork all the way.

I have never been involved with a programming environment that had anything like a doTogether block so I don't have any historical knowledge to fall back on in this area. I wonder what the Alice dev team intended for the behavior to be when a loop is included inside a doTogether block. Then I wonder if the behavior that you get is what they intended for it to be. Probably not.

The attached file seems to confirm your belief that the problem arises when the while event terminates before the loop terminates. If you run this example and release the D-key during the wait period after the loop terminates and before the next execution of the method, no runtime error is generated.

Have you done enough testing to confirm that the use of a loop inside a doTogether block always, or almost always results in an error. I tried to think of an easy way to write a test case that would eliminate the while event from the picture but so far haven't figured out how to do that. Everything I have come up with would cause the loop inside the doTogether block to terminate in an orderly fashion.

Thanks,
Dick Baldwin

To answer the core question first: No I haven't done enough testing to confirm that the use of a loop inside a doTogether block always, or almost always results in an error. I've had this problem hit me in enough different ways, however, that my best guess is:

(1) The doTogether block really isn't key to the problem, although it does make it more likely to occur, since there are more threads running that can go wrong, and ….

(2) What's really scary is that I think an error is not necessarily always going to occur when, for example, you're using a while event and a mouse/keyboard action to turn a method on and off. If the various indices used by the method are stable when the action occurs - something that can often occur if there is only a short loop in a method with other long blocks of code (or pauses) - I don't think you'll get an error.

By the way, I don't think the indexed loop is the only thing that gives problems - at least I've also had trouble using poses this way, and there are some comments about them, which I've never really understood, in the bug list.

But again, I'm guessing. (I too would like a roadmap.) What I've been doing since I saw the problem with the walk code is to make sure (as best I can - often it's trial and error) that whenever I want to stop a method with an event, I do it so I know what state things stop in. (This seems like a good idea in general, regardless of the source problem.)

As I indicated earlier, I'll generally just use the while event to control a Boolean variable and then use that to actually start and stop the method(s) at a clearly defined point. I think the very fast, absolute stop one gets from using the while event is what causes the problem of things being left in an undefined state - hence the solution is to avoid that if at all possible - while still keeping the real time control the while event does allow.

Regarding the problems being duscussed involving a while event, since Java is the underlying language in which Alice was written, and apparently the downloadable version of Alice is based on Java 1.3, there is an interesting article at the following URL that describes changes made to Java in version 1.4

http://java.sun.com/j2se/1.4.2/docs/...precation.html

Pure speculation: Maybe Alice is effectively calling Thread.stop() when the user releases the key to terminate the while event.

Dick Baldwin

I can't explain why the sarah file fails and the latest one that you provided doesn't fail but I believe that it is simply a matter of chance. After numerous conversations with DrJim I have tentatively concluded the following:

At least two of the while events (and probably all of them) are inherently unstable. The liklihood of failure is enhanced if the method that handles the while event contains a doTogether block but I doubt that is a requirement for failure.

When I first became aware of this event type, my initial incorrect assumption was that when the specified state becomes true, the handler method is called. When the method returns, if the specified state is still true, the method is called again. If the specified state is not true when the handler method returns, the handler is not called again. I think that was a bad assumption.

I believe I can demonstrate that this is not the case. It appears that when the specified state goes false, the handler method is somehow forced to abort almost immediately without being given an opportunity to clean up after itself. (Possibly the thread that the handler method is running on is simply stopped.) Sometimes this results in a runtime error and sometimes it doesn't. I doubt that it is possible to write a process of any substance that can simply be forced to abort at any time without causing problems some of the time. There is a lot of chance involved at this point. Regardless, if this is the actual behavior of the while event, this is a bad program design.

Maybe the purpose of the begin and end phases of the while event is to make it possible for the programmer to write the handler method in such a way that it knows how to clean up after itself when forced to terminate, but without documentation, I have been unable to figure out a way to do this.

On the basis of the above, a second tentative conclusion of mine is that the programmer should probably avoid using the during phase of the while events. Rather, the begin phase could be used to cause a well designed method to begin execution, probably using an infine loop to continue executing the desired process until the end phase sets a flag telling the process to terminate. When that flag is set, the process should clean up after itself and terminate as quickly as possible but not until it has cleaned up after itself.

But then again, I'm relatively new to Alice and I may have this all wrong.

Dick Baldwin

Well, the situation is even worse than I thought. I was assuming (once again erroneously) that the end event for the event of type While any key is pressed would be fired when the user releases the key. That way, it could be used to clear a runFlag accessible by the event handler method to notify the event handler that it should terminate at the next available opportunity.

As it turns out, the end event isn't fired until either the event handler method terminates or the key is released, whichever occurs later.

Back to the drawing board.

Dick Baldwin

Originally Posted by gdev

Here is an example of code that accomplishes the same thing without the error message .... I can't imagine the "end abruptly" makes all the difference but maybe...

One more note/guess on this. I note that the "working" version of the code moves the cars with direct function calls while "sarah's" version calls methods which then calls the functions to do the move.

The latter approach is nice in that it does allow easy generation of variations and improvements on the car move methods. (It would be nicer if the methods were associated with the arena object, not the world. You could then save out the arena object and try the methods with the code for another world.)

However, it does add more levels of hierarchy to the method call that must be retraced and "stabilized" (Dick, maybe you can say this better) when the method is stopped - a possible reason the "end abruptly" may cause the problem.

Originally Posted by DrJim

However, it does add more levels of hierarchy to the method call that must be retraced and "stabilized" (Dick, maybe you can say this better) when the method is stopped - a possible reason the "end abruptly" may cause the problem.

I'm going to take a pass on this and say that if the code is effectively sending a thread.stop message to the Java thread on which the event handler method is running, that is a clear violation of Sun's recommendations for multi-threaded programming. It is sort of like letting your teenager ride in a car with a drunk teenage driver. Anything can happen, and something bad probably will.

Whatever the cause, this sort of behavior is clearly a bug in Alice, as you, DrJim have demonstrated with some very simple sample programs. It simply shouldn't happen, and the bug should be avoided, just as your teenager should avoid getting into a car with a drunk teenage driver.

Please forgive my graphic language, but I'm trying to emphasize the seriousness of this bug. My advice is, don't use any of the while events and don't allow your students use them either, except possibly While the program is running. With that one, if an error occurs when the conditional goes false, you won't care because the program will have already terminated anyway.

Dick Baldwin

I would probably be less harsh and say that:

"Alice is an instructional tool and was not designed for real-time, mission critical applications."

Things like this illustrate why such warnings appear - in very fine print - on nearly all commercial computer hardware and software. It actually seems like a good thing for a beginning programmer to learn - just so long as he is aware of the message in the lesson! (Of course, he may then decide to go into law instead. )