[Openmcl-devel] 12/20 Cocoa Questions

[Gary Byers]

On Sun, 18 Jan 2004, Bruce D. Nilo wrote:

> I have looked around on the mailing lists and such but can't find
> answers to some of
> the problems I am bumping into. These are probably due to my
> configuration being
> screwy, but I don't know for certain and would certainly appreciate any
> pointers on
> getting my configuration stable.
>
> I downloaded the 12/20 distribution via CVS and built a new image. I am
> running on
> OSX 10.2.6. (I am about to upgrade to 10.2.8 to see if it corrects some
> problems.)
>
> Firstly, when I bring up a listener and type (require "cocoa") all goes
> well and I get
> a listener. However if I type a lisp expression such as (+ 2 3) into
> the window I get
> the following error:
>
> dppccl[4574] Error in event loop: #<A Mac Pointer #x420A3720> is not an
> ObjC object

I just tried it and got 5.

There are 3 separate CVS trees:

clozure.com:/usr/local/tmpcvs/ccl-0.13	0.13 sources; match 0.13.7
clozure.com:/usr/local/tmpcvs/ccl-0.14	last 0.14 release + bug fixes
clozure.com:/usr/local/tmpcvs/ccl-0.14-dev very unstable, may not compile,etc

Lisp's notion of what it means to be an "ObjC object" is very different
in the "0.14-dev" CVS tree than in the released 0.14.  I'd be a little
suprised if the 0.14-dev Cocoa demo would work at all in 0.14-031220,
but if it sort of worked halfway this might be one of the ways it'd fail.

>
> Secondly, if I next start up aserve and then try evaluate (require
> "cocoa") I get a more
> severe problem:
>
>  > Error: Objective-C runtime exception:
>  >        XML parser error:
>  >        	Unexpected character ( at line 1
>  >        Old-style plist parser error:
>  >        	Expected terminating ')' for array at line 1
>  >
>  > While executing: CCL::CHECK-NS-EXCEPTION
> ;;
> ;; Process Initial(0) needs access to terminal input.

The initial process pretty much has to run the Cocoa event loop (Panther
strongly requires this, and Jaguar ... greatly prefers that it do so.)
If that process gets any sort of exception, it can't reliably stop
processing events and enter a break loop (it may need to be able to
process events in order for anyone to be able to type to a break loop.)
So, any condition that gets raised during the initial process's execution
is -supposed- to simply cause a message to be logged and the next event
to be fetched.

I'm not quite sure who'd be running a Cocoa XML parser at this point,
but I'm also not sure how the initial thread got convinced that it
should try to enter a break loop when the parser failed.
>
> Typing (:Y 0) does not successfully do anything since the listener
> (process 1) reclaim
> input focus almost immediately.

This is definitely a bug:  a thread's right to use the terminal input
stream is governed by a lock.  The (:Y n)  readloop command is supposed
to transfer ownership of that lock, but there isn't really an API for
doing it.  It unlocks the lock, sleeps for a while, and hopes that
some requesting thread (maybe even the one the user asked for) acquires
it.  There are other things that can go wrong here; this needs to be
rewritten, since it only works "reliably" in very simple cases.

>
> Thirdly, if I type (require "cocoa-inspector") in an environment that
> does not have aserve
> running  I get the following error in the listener - but the app window
> does appear, but has
> the same eval problems as case 1 described above.
>
>  > Error in process listener(1): Unbound variable: *OBJC-READTABLE*
>  > While executing: CHEAP-EVAL-IN-ENVIRONMENT
>

Arrgh.

When they were first written, the Cocoa demos used a modified readtable
so that (for instance) message sends were enclosed in square brackets:

[w "title"]

Things (including the cocoa-inspector demo) were rewritten in lispier
syntax some months ago, so the above looks like:

(send w 'title)		; the difference is more pronounced when there
			; are more args involved

and the low-level ObjC gunk ("objc-support.lisp") no longer creates
a separate *objc-readtable* (that was moved into a separate file.)
The main Cocoa demo sources don't try to set the readtable anymore,
but I missed "cocoa-inspector.lisp".  (It doesn't -need- to use the
old reader macros and hasn't in a while.)


> Any pointers would be greatly appreciated.
>
> Bruce
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>