Trouble Shooting Color Change

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.

Originally Posted by 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.

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

For a similar problem and solution, take a look at the thread http://www.alice.org/community/showt...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.

Originally Posted by DickBaldwin

(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.

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

Originally Posted by DickBaldwin

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.

Awesome

Originally Posted by DrJim

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

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.

Originally Posted by DickBaldwin

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