[Openmcl-devel] Is this an OpenMCL 'problem'?

[Hamilton Link]

On Apr 7, 2006, at 2:30 PM, Phil wrote:

> Gary Byers wrote:
>
>>
>> I don't think that either of these approaches is entirely optimal.  I
>> think that I'd ultimately favor a mixture of the two: dropping into
>> the kernel debugger first, but providing an option to attempt to 
>> recover
>> by treating the exception as a lisp error.
>>
>
> I appreciate the detail on the options and rationale and it makes sense
> how and why it's being handled the way it is.  From a development
> standpoint, it would be nice if Slime handled the situation better (OT
> for this list so I'll take it over to slime).  From a deployment
> standpoint, does this approach preclude a graceful exit of an app? 
> (i.e.
> at least log the error and present the user with an error dialog before
> exiting)
>

GB always knows infinitely more about this than I do, so I'll let him 
suggest the _how_, but it seems like a sensible _what_ might be that 
even if memory got a proper thrashing, for situations where you 
survived as far as the kernel debugger invocation that function could 
be replaced in advance (by rebuilding the kernel, I'm thinking) with a 
routine that makes a couple of simple Carbon calls to pop up a dialog 
explaining what was going on, and give you a choice of dumping 
everything (invoke all the kernel dumping stuff) or quitting and 
sending a nastygram to the distributor.  I would be astonished if a 
C-level hack wasn't required.

There have been times where I have died right on past the kernel 
debugger, in which case I suspect if you had gotten ObjC running Aqua 
might take over and give the "this app has unexpectedly quit etc." 
message and otherwise a "segfault" or even less from the command line.

>>
>> ccl:examples;cocoa-backtrace.lisp uses NSOutlineViews and actually
>> doesn't do anything too complicated with them, but the rest of it
>> (dealing with "stack frame objects") is pretty obscure ...
>>
>
> I'll take a look at that code and, if I still can't get it going, start
> a new thread with specifics.
>

In the distant past I was the purveyor of such dubious bits of code as 
the cocoa-inspector and the (better, imho) rubix cube ObjC opengl demo. 
  If you get stuck on table views, etc. shoot me some mail at 
hamlink[splat]cs[dott]unm[dott]edu and I'll see if I can page some of 
that back in and help.

h

> Thanks,
> Phil
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>