Fixed installation and better error reporting

I just uploaded 1.1.20. It seems to fix the problems some people (me included) had installing into Eclipse 3.4.x. I’m nervous because the last release was the first with any installation problems and I didn’t do anything in particular to fix them. However, this one works and I know to test installation more thoroughly next time.

I had one report of a problem with the stack trace. Max didn’t find the test on the stack. I still don’t know what the problem was, but I have added a check that will write out the whole stack to the error log if the problem re-occurs. If you see a suspicious error long entry, please email it to me.

Next up: an ugly defect with a failing JUnit 3.8 test in an abstract superclass. I’m not sure where to place the failure marker. In the subclass makes sense, but where? In the superclass doesn’t make much sense, since it’s the subclass that had the problem.

It seems like the time for a dedicated Max view is approaching. With a view, the “where to put the marker?” question would be easier to solve. Wherever the marker went in the source files, it would also appear in the view. The other problem the view could solve is giving us a place to look after making and saving a change in a model file. When I’m editing tests, the in-situ feedback works great. When I’m editing model code, though, I have to wait to see if the project gets an error annotation or keep the Problems view open to see if tests passed.

This situation reminds me that user interface design is every bit as dependent on insight and inspiration as software design. You can know there is a problem for some time without knowing quite what to do about it. Careful observation of the problem can speed the appearance of a solution but so can experiments. I’ll be walking this tightrope over the next couple of weeks.