Fwd: [Openmcl-devel] How to make lisp slots in an objc class

[Gary Byers]

On Wed, 17 Mar 2004, Anders Conradi wrote:

> I meant to send this to the list, but used the wrong button
>
> Begin forwarded message:
>
> > From: Anders Conradi <beque at telia.com>
> > Date: tis mar 16, 2004  23:58:03 Europe/Stockholm
> > To: Randall Beer <beer at eecs.cwru.edu>
> > Subject: Re: [Openmcl-devel] How to make lisp slots in an objc class
> >
> >
> > On tisdag, mar 16, 2004, at 15:02 Europe/Stockholm, Randall Beer wrote:
> >
> >>> Thanks! That gets the class past the compiler. When I try to
> >>> initialize it it only works when I pass initargs to make-instance
> >>> (even though I have added initforms). How can I instantiate  objects
> >>> without passing initargs? I really want the object to be
> >>> instantiated from a .nib-file.
> >>
> >> The fix for initializing Lisp slots in OBJC-CLASSes from :INITFORM is
> >> in CVS and the OBJC-CLOS.LISP file is attached.
> >
> > Thank you! It seems as if I should start following CVS instead of
> > relying on version 14.1-p1 that I have now (slightly hacked with
> > generous bug-fixes from this list).
> >
> > Just one more question. (Yeah, right, like all pieces will fall into
> > place if I only get the answer to this question)
> >
> > Now I have conditions that are signaled on one side of cocoa and
> > caught on the other. The problem is that I loose valuable state. I
> > only get messages about "#<BOGUS object @ #x42AFE7AE> has no slots"
> > and a backtrace that originates from CHECK-NS-EXCEPTION. I would like
> > to get the backtrace on the side of cocoa that signaled the error.
> >

The "BOGUS object" probably has to do with the fact that pointer-typed
parameters to callback functions are stack-allocated by default.  (The
methods defined via DEFINE-OBJC-METHOD are callbacks, and parameters
of type :ID are pointer-typed.)  The handler that's reporting this is
running further up the stack, after the stack-allocated pointer's become
invalid.

There are several arguments against making pointers of type :ID be
stack-allocated by default; there may occasionally be cases where one
would want to avoid the overhead of heap-allocating (and canonicalizing,
and retaining) a pointer to an object that would otherwise be short-lived
(e.g., an NSEvent), but that should be the exception rather than the
rule.


> >  Is there any good way of entering the debugger instead of returning
> > to cocoa when a method implemented in lisp signals a condition? I
> > haven't gotten around to learning the lisp condition model so I am not
> > quite sure how to approach this.

One might prefer to at least be able to poke around in the dynamic
context in which the error occurred.

It's hard to do this in general, especially when the error happens on
the Cocoa event thread.  Eventually, "entering the debugger" might
involve the ability to process mouse clicks and key events; the event-
handling thread can either be processing those events or stuck in a
break loop, but it'd be hard for it to be in two places at once.

There's a commented-out call to CCL::DBG in the method that maps a
lisp condition to an NSException.  (It's supposed to be commented out;
it may not have been in a recent release ...).  That's usually not
at the point where the error was actually signaled, but it's dynamically
closer to it than the point where the event thread logs the error and
fetches the next event; uncommenting that and trying to debug with the
kernel debugger sometimes works (and sometimes doesn't.)

Having spent a lot of the last few weeks trying to figure out what one
of these after-the-fact error messages is talking about, I'd agree that
just muffling the error and fetching the next event is less than ideal.
Whatever -is- ideal would probably be a little different than just
entering a break loop in a listener; we might want/need a special way
for the event thread to interact with the developer without having to
process events to do so.

[I think that Mikel Evins' Bosco framework allows telneting into the
running application; I have some unreleased code that that provides
a listener-like "console" window to client applications.  If we knew
for sure that the event thread -could- interact with the developer
via one of these means, there could probably be some option that'd
force that kind of interaction (a break loop) on errors.]


> >
> > OK, I just realised that I have one more question. Is there anything I
> > can do to help? I know my lisp "skills" are severally lacking, and I
> > don't have that much time, but perhaps there is something simple I
> > could do. I have already written a simple temperature converter in
> > lisp with a cocoa interface. That might be nice as an example for
> > other newbies to this whole lisp and cocoa thing.
> >

I think that that'd be a great example.

Does it run independently of the demo IDE ?

> >>
> >> Randy
> >>
> >> <objc-clos.lisp>
> >
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>