[Openmcl-devel] My beach balls runneth over

[R. Matthew Emerson]

On May 19, 2009, at 2:45 PM, Ron Garret wrote:

> I regret to report that CCL 1.3 seems to still have some pretty
> serious bugs.  The UI is much improved, pretty much usable at this
> point.  But as soon as I lean on it (i.e. try to run some of Alexander
> Repenning's demos) it hangs  with the dreaded SBOD.  Sometimes it
> hangs without my even having to lean on it, just playing around with
> Hemlock (and by "playing around" I mean just editing, not hacking the
> Hemlock code).  On one occasion I ended up in the CCL Kernel
> debugger.  I have not yet played around enough to see if I can find a
> reliable way to reproduce the problem.  Many of the demos do work, but
> I have yet to go more than about 10 minutes at a time without a crash.
>
> My questions are:
>
> 1.  Is anyone else seeing this behavior or is it just me?  I can't
> imagine how Alexander was able to write this code if he was having the
> same experience I am.

I've been using the IDE full-time for the past few weeks, and although  
I've crashed it from time to time, this is usually due to me screwing  
up when calling foreign code.  Certainly I can use it to edit code for  
more than 10 minutes at a time without having it fall over.

I am running the trunk, so if you're running the 1.3 branch, you might  
try running the trunk too.  If anyone were to ask my opinion on  
whether to run 1.3 or the trunk, I'd normally recommend 1.3.  On the  
other hand, there is IDE work is happening in the trunk, and I don't  
quite know how or if that work should end up in 1.3.  So, it might not  
be such a bad idea for IDE users to run the trunk for now.

> 2.  If this is a known problem, what's the prognosis for getting it
> fixed?

I know it can be a lot of work, and you may not want to bother, but if  
you can come up with cases that demonstrate bugs, I'll (try to) fix  
those bugs

> 3.  Is there anything I can do when I encounter the SBOD to extract
> useful debugging information?

I start up CCL in a terminal, and then do (require 'cocoa).  If the  
event thread goes out to lunch (which is typically what a spinning  
beach ball indicates), it should at least show some sort of backtrace  
in the terminal.  This may or may not point to the problem, but it's  
better (though not much better) than nothing.