Trouble Shooting Color Change

[gdev]

I have assigned my students a problem where they need to use a shape to be the on off button. If you click the shape it changes from green to red or vice versa to indicate stop or go. The button is initally red, when clicked changes to green but when clicked again I get an error when changing it back to red. I have no idea what is going on. I attatched the file below. Please help.

[DickBaldwin]

I have assigned my students a problem where they need to use a shape to be the on off button. If you click the shape it changes from green to red or vice versa to indicate stop or go. The button is initally red, when clicked changes to green but when clicked again I get an error when changing it back to red. I have no idea what is going on. I attatched the file below. Please help.

Hello gdev,

The good news is that I don't see anything that is obviously wrong with your program.

The bad news is that I believe you have stressed the concurrent programming capability of Alice beyond its breaking point. The first revised program that I attached relieves some of that stress and runs successfully. However, it isn't very satisfying in terms of your objective.

Even in Java, which is the underlying language of Alice, where it is possible to write code that executes a great deal of control over what is going on, multithreaded or concurrent programming is one of the most difficult kinds of programming to do correctly. It is often much easier to get it wrong than it is to get it right. In addition, the failure modes are often much more obscure than the failure mode in your program. (Often it is the customer who discovers the failure.) In fact, entire books have been written on how to correctly do concurrent programming in Java.

Since Alice is a language within a language, and Alice supports some degree of concurrent programming, it is no surprise to me that it is possible to write Alice programs that get crosswise with the underlying concurrent programming capabiliies of Java and fail.

Unfortunately, when that happens in Alice, you don't get much in the way of helpful diagnostic information. Finding and fixing the problem is pretty much a matter of continuing to eliminating things until the problem goes away. Of course, experience helps in the troubleshooting process, but it can still be very difficult. After some effort along that line, I discovered that eliminating the doTogether block in your while something is true event handler would eliminate whatever it is that is causing the problem. My rationale was to eliminate as much concurrent programming as I could in an attempt to eliminate the cause of the problem. Unfortunately, that also eliminated the overall effectiveness of your animation. It caused the cars to take turns, which is obviously not what you were after.

I believe that the second file that I attached below will do the job that you intended to do. It isn't as elegant as your original version that is based on the while something is true event, but it is much safer.

Hope this helps.
Dick Baldwin

[DrJim]

For a similar problem and solution, take a look at the thread http://www.alice.org/community/showthread.php?t=543&highlight=walk .

The error messages for that case looked similar to what I get for the bumper cars. I never did figure out what the "fix" actually fixed - and no one else offered a suggestion. My best guess is that when the condition for the "event while" ceased to be true, the methods were stopped with some indicies in an undetermined state - leading to the error message.

I've had at least one discussion (with Chuck) as to when the "event while" condition is actually evaluated - clearly it occures very quickly after the condition becomes false - which intuitively seems that it must stress the concurrent method capabilities of the underlying program.

A "solution" often seems to be to have the "event while" just do something simple, like set a condition variable to false and then use that variable to terminate regular while loops in the methods that are controlling lots of animation - this puts the end points of these loops at a much more deterministic position.

I didn't take time to look at the code in detail to see how hard this might be to try - but it's a possibility.

[DrJim]

(Often it is the customer who discovers the failure.)

See the attached for the wrong way for a customer to find a software problem (system level, in this case). It could have been worse - the pilot walked away from the crash unhurt.

[DickBaldwin]

I extracted the avi file from the zip file but for some reason neither RealPlayer nor Windows Media Player could play it. The complaint was missing codecs with none available for downloading.

Dick Baldwin

[DrJim]

I extracted the avi file from the zip file but for some reason neither RealPlayer nor Windows Media Player could play it.
Dick Baldwin

Hopefully you can play this one - if not I'll dig up the URL I downloaded it from.

[DickBaldwin]

Awesome

[DickBaldwin]

I've had at least one discussion (with Chuck) as to when the "event while" condition is actually evaluated - clearly it occures very quickly after the condition becomes false - which intuitively seems that it must stress the concurrent method capabilities of the underlying program.


Without being able to analyze the underlying Java code produced by the Alice code, I don't believe it is possible to know what causes these failures. The diagnostics that are available by asking for more details on the error screen would only mean something to the folks who created the Java class libraries under which Alice is running.

For example, the attached program contains three while events plus a bunch of doTogeher blocks and it runs with no problem on my computer. The coach, the dancer, and the fan all run concurrently in while events with no problems.

When writing multi-threaded code in Java, things remain fairly easy and safe as long as no two threads share a common resouce, such as a variable, an array, or some other data structure such as a list or a hashtable. However, when two or more threads share a common resource, you really have to understand how to use synchronization, or producer-consumer concepts to write so called thread-safe code. For example, much of the code in the standard Java library is not thread-safe, and this is stated in the documentation.

My suspicion is that when one of these Alice programs fails due to concurrent programming problems, the system that turns Alice code into Java bytecode has done so on a basis that is not thread-safe, probably because some common resource is being shared by two or more threads and the required synchronization is not being handled properly. Once again, however, without seeing how the threads are being constructed, it is difficult, if not impossible to know exactly what is going wrong.

However, I would be amazed if the folks on the Alice team had succeeded in writing a language within a language that was immune to problems of this sort where multi-threaded programming is concerned, so I'm definitely not faulting them about this.

Dick Baldwin

[gdev]

Thanks everyone for your help and comments. What I posted was actually one of my students work. I had written one myself that was little "cleaner" and worked fine but I couldn't figure out the difference between mine and the students other than how collision was detected. Thanks again.

[DrJim]

For example, the attached program contains three while events ...(and) all run concurrently ... with no problems.


Thanks for the nice example. Demonstrating my basic ability to make good code inoperable :cool: - 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 :o ).

[DickBaldwin]

Thanks for the nice example. Demonstrating my basic ability to make good code inoperable :cool: - 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 :o ).

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.:confused:

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

[DrJim]

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.

[DickBaldwin]

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/guide/misc/threadPrimitiveDeprecation.html

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

Dick Baldwin

[DickBaldwin]

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

[DickBaldwin]

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

[DrJim]

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.

[DickBaldwin]

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.:rolleyes:

Dick Baldwin

[DrJim]

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. :o )