[Openmcl-devel] Is this an OpenMCL 'problem'?
hamlink at comcast.net
Fri Apr 7 22:59:01 EDT 2006
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
>> 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?
> at least log the error and present the user with an error dialog before
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.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel