From duncan at robotcat.demon.co.uk Sun Feb 1 14:58:24 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Sun, 1 Feb 2004 14:58:24 +0000 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: Message-ID: <1584D742-54C7-11D8-877D-000A9577B8A2@robotcat.demon.co.uk> On Saturday, January 31, 2004, at 10:19 AM, Duncan Rose wrote: > > On Saturday, January 31, 2004, at 12:23 AM, Timothy Moore wrote: > >> >> On Jan 31, 2004, at 12:34 AM, Duncan Rose wrote: >> >>> I think (hope) that the event loop requirements won't be *too* much >>> of an issue. Any threads in an application can be sent events, its >>> just that the run loop needs to be manually started for any threads >>> that aren't the main thread. I'll hopefully have a proof of this by >>> the end of the weekend. >> The main issue is that window system events are delivered only to the >> main thread and really have to be handled there too. AIUI. >> > > I'm not sure what AIUI means 8-) And I'm also not sure in this > context what "window system" events means... but under the assumption > we're talking about any events generated by the window system, I think > that these events get delivered to any thread that is running an event > loop (i.e. that has an executing run loop). I'll talk about this a > little more since I now consider we're back on topic for any threaded > GUI work in Cocoa, which will include any IDE we write irrespective of > whether it uses CLIM. > > I'll split the events into "send to object" and "send to thread" > events. Many mouse events (mouse left / right / other down and up, > scroll wheel, drag events) are sent directly to the NSView over which > they occurred, irrespective of the thread in which they are running > and irrespective of whether that thread has an executing run loop. My > experimental back end already responds to those (although I am only > passing mouse down / up events onto the rest of McCLIM at the moment). > > I think that many of the window events (exposed, resized, zoomed, > etc.) are sent to the target window (or to its delegate, at least) > irrespective of whether the NSWindow is running in the main thread or > has an executing event loop, but I have yet to write handlers for any > of these (this is my task for the w/end), so I'm not so sure on this > one. > I've looked at this in more detail now and can confirm that these window notifications get sent to the window's delegate irrespective of run loop and threading issues. > Other events are distributed to the main thread by default (I assume > at the moment that key down / up and mouse moved events (which have to > be explicitly enabled for the window(s) that want them) fall into this > category) but can be requested by any thread by it (the thread) > starting a run loop. > And I can debunk this. Now that I've fixed a little bit of brain-damage in the back end, key events and mouse motion events are sent direct to the NSWindow, again irrespective of run loop and threading issues. > Run loops can only be started by threads that *COCOA* recognises as > multithreaded. OpenMCL spins off posix threads (as is to be expected) > which can't by default execute run loops until the application informs > the window server that it is a multithreaded Cocoa app, by creating an > NSThread instance (which is free to immediately exit without doing > anything). The application (and any threads of that application) is > then considered to be multiprocessing and threads that do not have > executing run loops can start them and process any events in the event > queue. > > If you're interested, here's the code I use for getting Cocoa to > recognise my app as a threaded app in my toy back end: > > (unless (ccl::send (ccl::@class ns-thread) 'is-multi-threaded) > (ccl::send (ccl::@class ns-thread) > :DETACH-NEW-THREAD-SELECTOR (ccl::get-selector-for > "setHiddenUntilMouseMoves:") > :TO-TARGET (ccl::@class "NSCursor") > :WITH-OBJECT nil)) > > I hope you appreciate the inconsistent usage of @class (an example of > the lossage in the code ATM) 8-) > The above may be generally true (or maybe not), but I've now taken this code out of my back end and its behaviour is unchanged. So I now *do not* think that run loops or threading is an issue for Cocoa GUIs. The general structure of the back end I'm working on as it stands is as follows: 1. Click on the natty bundle icon (making use of the Bosco bundle from Mikel) 2. the application delegate does a (clim-listener:run-listener-process) in the application-did-finish-launching, running CLIM as a separate process 3. All the CLIM infrastructure gubbins gets started, including running the CLIM event loop in yet another thread When the NSApplication receives events, it distributes them to the NSWindow and NSView subclasses I defined in my McCLIM back end. I think that these calls are made in a different thread again, but I could be wrong. However, I can only assume that even though the window instances are created in a different thread to the main thread, they are still added to the main thread's responder chain. So at the moment, all I can say is: I don't understand quite what's going on or why, but things seem to be working. > The thing I'm not clear on at the moment, but that I hopefully will be > sure about in a couple of days, is a) whether this works at all 8-), > and b) whether this can cause events to be passed to multiple handlers > (e.g. if my NSView or NSWindow is tied up being drawn when key events > arrive in the window server queue, will the main threads run loop get > to pull them off the queue before the run loop I started for the > thread managing the view / window can do so? Or can *both* run loops > consume the event (sounds dodgy if so). Or is the event handling in > Cocoa clever enough to know that the thread in which the window / view > is running has a run loop started, and ensure that only it gets those > events? > I suspect that any run loop can process any events that are of an input type the run loop is sensitive to. The listener is event driven as far as the back end is concerned, which means there's nowhere in the back end that gets run on a regular enough basis to run a run loop. I did try the run loop approach yesterday, but couldn't get it to run in the same thread that was running when mouse down events were handled. This seems not to matter though when all the events *do* get delivered to where I want them delivered. > So I still have a ways to go to understand all this properly, but I'm > hoping I'll be done (with working (poor quality!) code and everything) > exploring this enough for my needs RSN. Whilst I can't say my understanding of all this is improving much, I can say that things seem to be working - and that is enough for me for the time being. The only remaining unknown is whether other McCLIM apps, when started from the listener, will behave wrt events. Time will tell 8-) (I'm also going to experiment with running McCLIM apps after doing a (require "cocoa") from openmcl rather than from the Bosco bundle; just to see if it works. I'd be willing to bet at the moment that it will work). -Duncan > >> >> http://www.nhplace.com/kent/PS/Ambitious.html >> > > Thanks for the reference, now I just need to read it and think it over > 8-) > > -Duncan > >> Here are the key points. As the user types input, the lisp code is >> calling read-char or whatever. So the input is "live;" for example as >> soon as the user finishes one argument of a command the prompt for >> the next argument can be output. So how can the user edit input? If >> the user backs the cursor up and makes a change, the editor throws >> out to a catch tag and restarts the function that was reading input. >> Now that function sees the edited input... >> >> Tim >> > From mikel at evins.net Sun Feb 1 16:50:32 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 08:50:32 -0800 Subject: [mac-lisp-ide] Clotho 0.1 release available Message-ID: [I sent this to the old list just as it was being moved; I'm re-sending because I haven't seen it delivered. --me] I packaged the current state of Clotho, my embryonic lisp IDE project, and have made it available for download. If you want to try it out or extend it, send mail to me and I'll tell you where to get it. (I'm not sending the URL in this message because I want to minimize the chance that sudden interest will make my server fall over, as happened when I first made Alpaca available). The 0.1 release of Clotho comes with a pre-built copy of the application, and all the sources and resources needed to build it. You will need a working copy of OpenMCL 0.14-031220 or later with the associated darwin-headers in order to build it. Clotho 0.1 is little more than an application wrapper around a simple listener, together with sources and a build framework. It should, however, serve as a point of departure for folks who want working code to extend. If there is interest, I'll make cvs access to the Clotho project available to people who want to work on the code. (Alternatively, I could set up Arch access, which might be better in some ways). I do need to tidy up a few loose ends in the cvs project; there is an inconvenience at present with the way that darwin-headers interact with the Clotho cvs project. --me From mikel at evins.net Sun Feb 1 16:58:00 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 08:58:00 -0800 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: <1584D742-54C7-11D8-877D-000A9577B8A2@robotcat.demon.co.uk> References: <1584D742-54C7-11D8-877D-000A9577B8A2@robotcat.demon.co.uk> Message-ID: On Feb 1, 2004, at 6:58 AM, Duncan Rose wrote: [snip] > The above may be generally true (or maybe not), but I've now taken > this code out of my back end and its behaviour is unchanged. So I now > *do not* think that run loops or threading is an issue for Cocoa GUIs. > > The general structure of the back end I'm working on as it stands is > as follows: > > 1. Click on the natty bundle icon (making use of the Bosco bundle > from Mikel) > 2. the application delegate does a > (clim-listener:run-listener-process) in the > application-did-finish-launching, running CLIM as a separate process > 3. All the CLIM infrastructure gubbins gets started, including > running the CLIM event loop in yet another thread > > When the NSApplication receives events, it distributes them to the > NSWindow and NSView subclasses I defined in my McCLIM back end. I > think that these calls are made in a different thread again, but I > could be wrong. However, I can only assume that even though the window > instances are created in a different thread to the main thread, they > are still added to the main thread's responder chain. > > So at the moment, all I can say is: I don't understand quite what's > going on or why, but things seem to be working. > This seems like a pretty good start. I have a Cocoa system definition that snaps into the McCLIM build system. You can load and build the McCLIM system in the normal way, and also build and load the Cocoa back end. If you do that, a McCLIM.app gets built in the same way that Bosco.app gets built. You can launch McCLIM.app and it starts up with a proper name and Dock icon. The app's runtime loads no nibs; it just sets up the bare minimum Cocoa event-processing environment (because it seems to me that nibfiles are not really congruent with the CLIM way of building interfaces). You can also load and run the CLIM listener--but then things break because the concrete classes that realize CLIM sheets and frames are not working. It seems like we have sort of two ends of the thing pretty well started; now might be a good time to combine them and check in to the McCLIM project so other people can contribute. It also seems like we're not that far from having a good start on a CLIM-based IDE if we can get the Listener and Goatee up and limping. I posted separately that I've packaged a 0.1 release of Clotho. Seems like that's two places to start. I don't see any reason we can't pursue both (and others as well) until it becomes clear that either one is a better idea than the other, or that each has its own use. From bmastenb at cs.indiana.edu Sun Feb 1 16:59:07 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 1 Feb 2004 11:59:07 -0500 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: References: Message-ID: On Feb 1, 2004, at 11:50 AM, mikel evins wrote: > Clotho 0.1 is little more than an application wrapper around a simple > listener, together with sources and a build framework. It should, > however, serve as a point of departure for folks who want working code > to extend. > > If there is interest, I'll make cvs access to the Clotho project > available to people who want to work on the code. (Alternatively, I > could set up Arch access, which might be better in some ways). I do > need to tidy up a few loose ends in the cvs project; there is an > inconvenience at present with the way that darwin-headers interact > with the Clotho cvs project. Hello Mikel! I'd be happy to host a mirror of Clotho on a server with unlimited bandwidth. Just let me know! I'd also be very interested in working on it via CVS. I don't know anything about arch myself, so I'll have to look for a tutorial if that's what you decide to use. Where will you be hosting this project? Thanks, Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From bmastenb at cs.indiana.edu Sun Feb 1 17:07:13 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 1 Feb 2004 12:07:13 -0500 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: References: <1584D742-54C7-11D8-877D-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <148EEA8A-54D9-11D8-9373-000A9599AF88@cs.indiana.edu> On Feb 1, 2004, at 11:58 AM, mikel evins wrote: > It also seems like we're not that far from having a good start on a > CLIM-based IDE if we can get the Listener and Goatee up and limping. This sounds great! Right now it looks like Goatee is kind of a bare-minimum solution; since gilberth is involved in hemlock too, the idea was that hemlock would eventually take over as the the McCLIM editor, leaving goatee for line editing. If in fact Hemlock becomes the best solution for a native Cocoa editor, is there any reason why we can't simply integrate it into a Cocoa McCLIM? That sounds like a way that the two projects could share a significant base of code. > I posted separately that I've packaged a 0.1 release of Clotho. Seems > like that's two places to start. I don't see any reason we can't > pursue both (and others as well) until it becomes clear that either > one is a better idea than the other, or that each has its own use. I don't see any reason why there wouldn't be a place for the two to coexist: CLIM for people working on a good (and quite possibly platform-independent) CLIM-model IDE, and Cocoa for those people who want a very Cocoa-ish development environment. There's no law against code sharing when we can :-) Hopefully even a native Cocoa IDE will be able to load CLIM too, so people can use it for writing CLIM programs. -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From mikel at evins.net Sun Feb 1 17:30:35 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 09:30:35 -0800 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: References: Message-ID: <57E34C2A-54DC-11D8-A4AB-000A958E5B06@evins.net> On Feb 1, 2004, at 8:59 AM, Brian Mastenbrook wrote: > On Feb 1, 2004, at 11:50 AM, mikel evins wrote: > >> Clotho 0.1 is little more than an application wrapper around a simple >> listener, together with sources and a build framework. It should, >> however, serve as a point of departure for folks who want working >> code to extend. >> >> If there is interest, I'll make cvs access to the Clotho project >> available to people who want to work on the code. (Alternatively, I >> could set up Arch access, which might be better in some ways). I do >> need to tidy up a few loose ends in the cvs project; there is an >> inconvenience at present with the way that darwin-headers interact >> with the Clotho cvs project. > > Hello Mikel! > > I'd be happy to host a mirror of Clotho on a server with unlimited > bandwidth. Just let me know! I'll send you the dmg out of band; it's about 7.5MB in size. > > I'd also be very interested in working on it via CVS. I don't know > anything about arch myself, so I'll have to look for a tutorial if > that's what you decide to use. Where will you be hosting this project? > Arch is nice, but not nearly as well-known as cvs. And folks would have to build it from source. I guess cvs is a better choice. As far as hosting, if a small number of people are actively committing, I could host it from my server. But I'm not averse to creating a Sourceforge project, or a common-lisp.net project, or ??? --me From mikel at evins.net Sun Feb 1 17:33:31 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 09:33:31 -0800 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: <148EEA8A-54D9-11D8-9373-000A9599AF88@cs.indiana.edu> References: <1584D742-54C7-11D8-877D-000A9577B8A2@robotcat.demon.co.uk> <148EEA8A-54D9-11D8-9373-000A9599AF88@cs.indiana.edu> Message-ID: On Feb 1, 2004, at 9:07 AM, Brian Mastenbrook wrote: > On Feb 1, 2004, at 11:58 AM, mikel evins wrote: > >> It also seems like we're not that far from having a good start on a >> CLIM-based IDE if we can get the Listener and Goatee up and limping. > > This sounds great! Right now it looks like Goatee is kind of a > bare-minimum solution; since gilberth is involved in hemlock too, the > idea was that hemlock would eventually take over as the the McCLIM > editor, leaving goatee for line editing. > > If in fact Hemlock becomes the best solution for a native Cocoa > editor, is there any reason why we can't simply integrate it into a > Cocoa McCLIM? That sounds like a way that the two projects could share > a significant base of code. No, and it's my intention that Alpaca and Clotho will also use Hemlock as soon as we can get it working properly. I pinged Gary about the state of his Hemlock conversion project, but I haven't heard back from him yet (which is unusual; perhaps he's offline for a bit). > >> I posted separately that I've packaged a 0.1 release of Clotho. Seems >> like that's two places to start. I don't see any reason we can't >> pursue both (and others as well) until it becomes clear that either >> one is a better idea than the other, or that each has its own use. > > I don't see any reason why there wouldn't be a place for the two to > coexist: CLIM for people working on a good (and quite possibly > platform-independent) CLIM-model IDE, and Cocoa for those people who > want a very Cocoa-ish development environment. There's no law against > code sharing when we can :-) > > Hopefully even a native Cocoa IDE will be able to load CLIM too, so > people can use it for writing CLIM programs. I agree with all of this. From bmastenb at cs.indiana.edu Sun Feb 1 18:31:35 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 1 Feb 2004 13:31:35 -0500 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: References: Message-ID: I'm having a look at the code here, which is also my first time actually looking at what Cocoa code looks like in OpenMCL. I have a few impressions: * The Cocoa interface seems very well done and very usable * Why is it that the Cocoa interface is internal to package CCL? This violates my sense of aesthetics :-) * This seems like an eminently hackable start. I'm now mirroring the Clotho 0.1 release at http://cs.indiana.edu/~bmastenb/misc/Clotho%200.1.dmg . Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From mikel at evins.net Sun Feb 1 18:50:53 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 10:50:53 -0800 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: References: Message-ID: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> On Feb 1, 2004, at 10:31 AM, Brian Mastenbrook wrote: > I'm having a look at the code here, which is also my first time > actually looking at what Cocoa code looks like in OpenMCL. I have a > few impressions: > > * The Cocoa interface seems very well done and very usable Folks should be aware that there are some caveats about building code with the Cocoa interface. I'm sure that everyone will rapidly run into the problem that, unlike a call to a Lisp function, a call to an Objective C methods cannot be compiled until the class and method referenced are first compiled. This restriction places some awkward limitations on load order, limitations that account for a few peculiarities in how Clotho and other Bosco-based applications are organized. The general rule of thumb is that you must sort your classes and methods to eliminate forward references in the load. When you can't eliminate forward references you can work around the limitation by interposing a call to a Lisp function instead of a reference to an Objective-C class or method, because you can refer to a Lisp function before it's defined. The Lisp function can then be defined later in the load order, after the Objective C class or method has been defined. There are several subtleties to using the bridge in its current form. For example, it defines a pseudovariable SELF, which, in Objective C methods refers to the object that owns the method. You cannot return or store the value of SELF and expect to use it; if you want to use it that way you must %COPY-MACPTR it first. I imagine people hacking this code will at first run into a bunch of gotchas like this. I'll be happy to help out wherever problems involve things I've already figured out. If Duncan has gotten McCLIM code drawing in Cocoa windows, then he's probably also a good person to ask about some of these problems, as he will have had to solve many of them in order to get that code working. > * Why is it that the Cocoa interface is internal to package CCL? This > violates my sense of aesthetics :-) My guess would be because most of Gary's work in in package CCL. :-) I see no reason we couldn't change it and put it in package cocoa (or whatever). > * This seems like an eminently hackable start. Good; I listed you as a project member in the proposal to common-lisp.net to create a Clotho project. :-) > > I'm now mirroring the Clotho 0.1 release at > http://cs.indiana.edu/~bmastenb/misc/Clotho%200.1.dmg . Thanks. I hope to hear soon from other people who want to hack it. From bmastenb at cs.indiana.edu Sun Feb 1 19:01:46 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 1 Feb 2004 14:01:46 -0500 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> Message-ID: <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> On Feb 1, 2004, at 1:50 PM, mikel evins wrote: >> * Why is it that the Cocoa interface is internal to package CCL? This >> violates my sense of aesthetics :-) > > My guess would be because most of Gary's work in in package CCL. :-) I > see no reason we couldn't change it and put it in package cocoa (or > whatever). The effective part of what I said was not "package CCL", it was "internal", which means that any code using it is also internal to CCL. That's what violates my aesthetics :-) >> * This seems like an eminently hackable start. > > Good; I listed you as a project member in the proposal to > common-lisp.net to create a Clotho project. :-) Thanks! -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From mikel at evins.net Sun Feb 1 19:07:43 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 11:07:43 -0800 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> Message-ID: On Feb 1, 2004, at 11:01 AM, Brian Mastenbrook wrote: > On Feb 1, 2004, at 1:50 PM, mikel evins wrote: > >>> * Why is it that the Cocoa interface is internal to package CCL? >>> This violates my sense of aesthetics :-) >> >> My guess would be because most of Gary's work in in package CCL. :-) >> I see no reason we couldn't change it and put it in package cocoa (or >> whatever). > > The effective part of what I said was not "package CCL", it was > "internal", which means that any code using it is also internal to > CCL. That's what violates my aesthetics :-) Oh, sorry, of course. From beer at eecs.cwru.edu Sun Feb 1 20:07:09 2004 From: beer at eecs.cwru.edu (Randall Beer) Date: Sun, 1 Feb 2004 15:07:09 -0500 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> Message-ID: <373A83AA-54F2-11D8-A377-000A95675D7E@eecs.cwru.edu> > On Feb 1, 2004, at 1:50 PM, mikel evins wrote: > >>> * Why is it that the Cocoa interface is internal to package CCL? >>> This violates my sense of aesthetics :-) >> >> My guess would be because most of Gary's work in in package CCL. :-) >> I see no reason we couldn't change it and put it in package cocoa (or >> whatever). > > The effective part of what I said was not "package CCL", it was > "internal", which means that any code using it is also internal to > CCL. That's what violates my aesthetics :-) The OpenMCL Cocoa bridge both currently resides in and is internal to CCL because the ObjC/Lisp interface in OpenMCL is still in flux. As some of you may know, Gary and I have been working on integrating ObjC into CLOS, so that ObjC objects can be created and manipulated as if they are (special kinds of) CLOS objects. In the current bleeding edge OpenMCL tree, CLASS-OF, FIND-CLASS, MAKE-INSTANCE, DEFCLASS, etc. basically work on ObjC classes and objects, and CLOS methods can be specialized on ObjC classes. There is still work to be done on invoking ObjC methods via generic functions and defining CLOS methods on them, as well as more completely hiding ObjC's retain/release machinery. There is also a lot of clean-up and fine-tuning to be done. As this work gets done, my hope is that this CLOS interface to Cocoa will eventually replace the Cocoa bridge (even though I wrote it!). Randy Beer From moore at bricoworks.com Sun Feb 1 20:32:05 2004 From: moore at bricoworks.com (Timothy Moore) Date: Sun, 1 Feb 2004 21:32:05 +0100 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: References: Message-ID: On Jan 31, 2004, at 11:19 AM, Duncan Rose wrote: > > On Saturday, January 31, 2004, at 12:23 AM, Timothy Moore wrote: >> The main issue is that window system events are delivered only to the >> main thread and really have to be handled there too. AIUI. >> > > I'm not sure what AIUI means 8-) And I'm also not sure in this > context what "window "As I Understand it" > system" events means... but under the assumption we're talking about > any events generated by the window system, I think that these events > get delivered to any thread that is running an event loop (i.e. that > has an executing run loop). I'll talk about this a little more since I > now consider we're back on topic for any threaded GUI work in Cocoa, > which will include any IDE we write irrespective of whether it uses > CLIM. > > I'll split the events into "send to object" and "send to thread" > events. Many mouse events (mouse left / right / other down and up, > scroll wheel, drag events) are sent directly to the NSView over which > they occurred, irrespective of the thread in which they are running > and irrespective of whether that thread has an executing run loop. My > experimental back end already responds to those (although I am only > passing mouse down / up events onto the rest of McCLIM at the moment). Perhaps I need to go back and review Cocoa a bit. What does it mean for an NSView to be "running in a thread?" What you say about events being sent directly to the NSView fits with my understanding of the situation i.e., the method that handles the event for the NSView runs in the thread of the main event loop. > > The thing I'm not clear on at the moment, but that I hopefully will be > sure about in a couple of days, is a) whether this works at all 8-), > and b) whether this can cause events to be passed to multiple handlers > (e.g. if my NSView or NSWindow is tied up being drawn when key events > arrive in the window server queue, will the main threads run loop get > to pull them off the queue before the run loop I started for the > thread managing the view / window can do so? Or can *both* run loops > consume the event (sounds dodgy if so). Or is the event handling in > Cocoa clever enough to know that the thread in which the window / view > is running has a run loop started, and ensure that only it gets those > events? > Same question, what is "the thread in which the view is running?" I wouldn't assume it's the thread that creates the view or that has the focus locked or whatever. Tim From duncan at robotcat.demon.co.uk Sun Feb 1 20:47:02 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Sun, 1 Feb 2004 20:47:02 +0000 Subject: [mac-lisp-ide] Re: ideas and issues In-Reply-To: Message-ID: On Sunday, February 1, 2004, at 08:32 PM, Timothy Moore wrote: .snipped. >> >> I'll split the events into "send to object" and "send to thread" >> events. Many mouse events (mouse left / right / other down and up, >> scroll wheel, drag events) are sent directly to the NSView over which >> they occurred, irrespective of the thread in which they are running >> and irrespective of whether that thread has an executing run loop. My >> experimental back end already responds to those (although I am only >> passing mouse down / up events onto the rest of McCLIM at the >> moment). > Perhaps I need to go back and review Cocoa a bit. What does it mean > for an NSView to be "running in a thread?" What you say about events > being sent directly to the NSView fits with my understanding of the > situation i.e., the method that handles the event for the NSView runs > in the thread of the main event loop. >> > >> The thing I'm not clear on at the moment, but that I hopefully will >> be sure about in a couple of days, is a) whether this works at all >> 8-), and b) whether this can cause events to be passed to multiple >> handlers (e.g. if my NSView or NSWindow is tied up being drawn when >> key events arrive in the window server queue, will the main threads >> run loop get to pull them off the queue before the run loop I started >> for the thread managing the view / window can do so? Or can *both* >> run loops consume the event (sounds dodgy if so). Or is the event >> handling in Cocoa clever enough to know that the thread in which the >> window / view is running has a run loop started, and ensure that only >> it gets those events? >> > Same question, what is "the thread in which the view is running?" I > wouldn't assume it's the thread that creates the view or that has the > focus locked or whatever. > That's a good question. I had assumed it was the same thread that ran the (in this case) listener application - since that's the thread that constructs the windows and sends the messages to put them up on the display. Theoretically, this thread shouldn't be handling events (at least by my understanding of a couple of days ago) but it seems that it is. Or that the views are in fact running in a different thread. Whether I need to differentiate between receiving events, distributing events, and handling events in this I'm not sure. I thought for a while I had this whole event / run loop thing pegged down reasonably well. It appears I was mistaken 8-) It wouldn't be too hard to insert some debug at a few different places to see exactly what's executing in which thread - and I'm going to do this at some point in the hope of understanding this better. -Duncan > Tim > From mikel at evins.net Sun Feb 1 21:09:37 2004 From: mikel at evins.net (mikel evins) Date: Sun, 1 Feb 2004 13:09:37 -0800 Subject: [mac-lisp-ide] Clotho 0.1 release available In-Reply-To: <373A83AA-54F2-11D8-A377-000A95675D7E@eecs.cwru.edu> References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> <373A83AA-54F2-11D8-A377-000A95675D7E@eecs.cwru.edu> Message-ID: On Feb 1, 2004, at 12:07 PM, Randall Beer wrote: >> On Feb 1, 2004, at 1:50 PM, mikel evins wrote: >> >>>> * Why is it that the Cocoa interface is internal to package CCL? >>>> This violates my sense of aesthetics :-) >>> >>> My guess would be because most of Gary's work in in package CCL. :-) >>> I see no reason we couldn't change it and put it in package cocoa >>> (or whatever). >> >> The effective part of what I said was not "package CCL", it was >> "internal", which means that any code using it is also internal to >> CCL. That's what violates my aesthetics :-) > > The OpenMCL Cocoa bridge both currently resides in and is internal to > CCL because the ObjC/Lisp interface in OpenMCL is still in flux. As > some of you may know, Gary and I have been working on integrating ObjC > into CLOS, so that ObjC objects can be created and manipulated as if > they are (special kinds of) CLOS objects. > > In the current bleeding edge OpenMCL tree, CLASS-OF, FIND-CLASS, > MAKE-INSTANCE, DEFCLASS, etc. basically work on ObjC classes and > objects, and CLOS methods can be specialized on ObjC classes. There > is still work to be done on invoking ObjC methods via generic > functions and defining CLOS methods on them, as well as more > completely hiding ObjC's retain/release machinery. There is also a > lot of clean-up and fine-tuning to be done. > > As this work gets done, my hope is that this CLOS interface to Cocoa > will eventually replace the Cocoa bridge (even though I wrote it!). > This raises a point about ongoing development of Clotho: I definitely think the way Randall Beer and Gary Byers are approaching the interface to Objective C is the desirable way to go (that is, making Objective C objects look like CLOS objects). Thus, as they progress with their work I'm going to want to change the way that Clotho works to use their new code. That's going to introduce soome thrash into the Clotho project, but I think in the end it'll be worth it. --me From mikel at evins.net Wed Feb 4 00:27:15 2004 From: mikel at evins.net (mikel evins) Date: Tue, 3 Feb 2004 16:27:15 -0800 Subject: [mac-lisp-ide] Clotho project at common-lisp.net In-Reply-To: References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> <373A83AA-54F2-11D8-A377-000A95675D7E@eecs.cwru.edu> Message-ID: Common-lisp.net has approved creation of the Clotho project. The project home page is at http://www.common-lisp.net/project/clotho/ Clotho 0.1, kindly hosted by Brian Mastenbrook, is now also available for download from the common-lisp.net project page. If you are interested in development of a Cocoa-centric IDE for common lisp, I invite you to download and examine Clotho 0.1. This initial release is extremely simple, but provides source code, a simple build framework, an application bundle and associated resource files, and basic instructions on how to add code to it. If you are interested in contributing to development of Clotho, please send mail to me at mevins at common-lisp.net and we can discuss adding you to the project. --me From mikel at evins.net Wed Feb 4 03:46:37 2004 From: mikel at evins.net (mikel evins) Date: Tue, 3 Feb 2004 19:46:37 -0800 Subject: [mac-lisp-ide] Clotho project checked in and tagged In-Reply-To: References: <8FDF51AF-54E7-11D8-A4AB-000A958E5B06@evins.net> <1506CA60-54E9-11D8-A9FF-000A9599AF88@cs.indiana.edu> <373A83AA-54F2-11D8-A377-000A95675D7E@eecs.cwru.edu> Message-ID: The Clotho 0.1 release is checked in to the common-lisp.net cvs repository. Follow the instructions at http://www.common-lisp.net/faq.shtml if you wish to check out the code. The 0.1 release is tagged Release_0_1. Please note that if you check it out from the CVS repository then you get all the sources and the application bundle, but you do not get the pre-built application; in order to run Clotho from the cvs checkout you must first have a working copy of openmcl 0.14-031220 (or later), with the corresponding darwin-headers, and must follow the included instructions to build Clotho. Also, after the first build, the OS X Finder may not realize at first that Clotho.app is launchable. To cure this problem, close all Finder windows and, from a Terminal window, execute touch Clotho.app on the application bundle. Afterwards the application should launch correctly. Send me mail at mevins at common-lisp.net if you have questions, or if you want to be added to the project. --me From mikel at evins.net Wed Feb 4 21:55:47 2004 From: mikel at evins.net (mikel evins) Date: Wed, 4 Feb 2004 13:55:47 -0800 Subject: [mac-lisp-ide] Extending clotho Message-ID: Clotho is now a functioning project on common-lisp.net. Clotho 0.1 is available and it builds and runs, but it's obviously very spartan in its current form. It seems appropriate to discuss what to do to it next to evolve it toward being a good Lisp development environment for Mac OS X. Here are my Top 5 desiderata for Clotho. Feel free to debate the merits of these, or the approaches I suggest for carrying them out, or to add other things you'd like to see. 1. Editor Clotho presently has only a very rudimentary editor, and only in its Listener window. It would be fairly straightforward to splice in the plain-text editor from Alpaca, which would have the advantages of being quick and easy, and of providing the same Emacs-like key-binding API that Alpaca uses. I could probably do that in an afternoon, but before I do, I'm going to have a bash at splicing in Portable Hemlock. I have Gary's sources from the OpenMCL bleeding-edge branch and have had a look through them. Gary accomplished the initial task of building hemlock without X11, and has wired it up to act as a text-storage layer in place of the normal Cocoa text storage. I can't use his sources unchanged because they rely on some of the new Objective C/CLOS work he and Randall Beers are doing for the next release, but I'm not discouraged; there isn't all that much code. I expect I'll experiment with it some time soon and decide whether it's better to wait for the next OpenMCL release or go ahead and try building a Hemlock-based editor into Clotho now. 2. Inspector Another obvious choice would be to work on splicing Hamilton Link's windowing inspector into Clotho. That also shouldn't take too long, and I think it's a good idea. I expect I'll do it soon if someone else doesn't. 3. Resource Manager As I've mentioned before, I'd like to see a few tools in Clotho that can read and write nibfiles, because of their importance in the Cocoa programming world. I'd like to see more tools than that, actually; one of the projects I worked on at Apple, SK8, extended MCL to provide fairly impressive viewers and editors for images, movies, sounds, and so on. Resource viewers and editors are a lot of work, so II sort of expect tools like this to be an ongoing project. 4. Debugger Clearly it's desirable to have a stepper and a debugger that can control breakpoints and display and edit stack frames in a nice way. 5. Application Builder The way things are right now you could use Clotho+Emacs to build a working application in about the same way I used Bosco+Emacs to build Clotho. That's kind of crude and not especially Lispy, though. Better would be if you could launch Clotho, write a bunch of Lisp code, and then ask Clotho to make a new application bundle with all the right resource files in the bundle. Then you could build your Whizzy app in Clotho, ask CClotho to save Whizzy.app and, abracadabra! you would have a new application ready to launch. That involves writing some code to make the application bundle, to get names and other strings from the user somehow and write them into the plist files, and so on. --me From beer at eecs.cwru.edu Thu Feb 5 14:56:17 2004 From: beer at eecs.cwru.edu (Randall Beer) Date: Thu, 5 Feb 2004 09:56:17 -0500 Subject: [mac-lisp-ide] Extending clotho In-Reply-To: References: Message-ID: <73847470-57EB-11D8-BD80-000A95675D7E@eecs.cwru.edu> > 5. Application Builder > The way things are right now you could use Clotho+Emacs to build a > working application in about the same way I used Bosco+Emacs to build > Clotho. That's kind of crude and not especially Lispy, though. Better > would be if you could launch Clotho, write a bunch of Lisp code, and > then ask Clotho to make a new application bundle with all the right > resource files in the bundle. Then you could build your Whizzy app in > Clotho, ask CClotho to save Whizzy.app and, abracadabra! you would > have a new application ready to launch. That involves writing some > code to make the application bundle, to get names and other strings > from the user somehow and write them into the plist files, and so on. Might it be useful to think of a Cocoa application as a special kind of Lisp system? If we had a ProjectBuilder sort of GUI for working with (ASDF or DEFSYSTEM) Lisp systems, then we could also use it to work with Cocoa applications. COCOA-APPLICATIONS could have additional file types associated with them, and could also responsd to a SAVE-COCOA-APPLICATION operation (perhaps by starting up another OpenMCL with a command line option set to load in the specified system and then SAVE-APPLICATION). Randy From mikel at evins.net Thu Feb 5 16:56:54 2004 From: mikel at evins.net (mikel evins) Date: Thu, 5 Feb 2004 08:56:54 -0800 Subject: [mac-lisp-ide] Extending clotho In-Reply-To: <73847470-57EB-11D8-BD80-000A95675D7E@eecs.cwru.edu> References: <73847470-57EB-11D8-BD80-000A95675D7E@eecs.cwru.edu> Message-ID: <4D47A1FA-57FC-11D8-B336-000A958E5B06@evins.net> On Feb 5, 2004, at 6:56 AM, Randall Beer wrote: >> 5. Application Builder >> The way things are right now you could use Clotho+Emacs to build a >> working application in about the same way I used Bosco+Emacs to build >> Clotho. That's kind of crude and not especially Lispy, though. Better >> would be if you could launch Clotho, write a bunch of Lisp code, and >> then ask Clotho to make a new application bundle with all the right >> resource files in the bundle. Then you could build your Whizzy app in >> Clotho, ask CClotho to save Whizzy.app and, abracadabra! you would >> have a new application ready to launch. That involves writing some >> code to make the application bundle, to get names and other strings >> from the user somehow and write them into the plist files, and so on. > > Might it be useful to think of a Cocoa application as a special kind > of Lisp system? If we had a ProjectBuilder sort of GUI for working > with (ASDF or DEFSYSTEM) Lisp systems, then we could also use it to > work with Cocoa applications. COCOA-APPLICATIONS could have > additional file types associated with them, and could also responsd to > a SAVE-COCOA-APPLICATION operation (perhaps by starting up another > OpenMCL with a command line option set to load in the specified system > and then SAVE-APPLICATION). > Yah; this is a good idea. --me From gb at clozure.com Thu Feb 5 21:47:40 2004 From: gb at clozure.com (Gary Byers) Date: Thu, 5 Feb 2004 14:47:40 -0700 (MST) Subject: [mac-lisp-ide] runloops, threads, etc. Message-ID: <20040205131527.H2541@clozure.com> I just subscribed to this list a little while ago and wanted to respond to a few things that I saw in the archives. I probably won't be able to attribute things too accurately, and I'm sure that I've missed parts of the discussion and may be replying to some things out of context. To the best of my knowledge, it's effectively the case that only one thread can fetch events from/communcate directly with the window server. Prior to Panther, this was the thread whose CFRunloop was the "main" CFRunloop (there's still some code in OpenMCL's Cocoa demo that tries to play around with this, and it used to be the case that something called an undocumented function - something like "_CFRunLoopSetMain" - to try to get around this. CF's "main" runloop ordinarily got created when CF was initialized, and it was associated with the thread that did that initialization.) Panther put an end to all this: the thread that's allowed to talk to the Window Server is the application's initial thread (the one that started out by calling main(), way back when) and none other. (Any other thread can certainly try to call NSApplication's nextEventMatchingMaskWhateverTheOtherArgsAre, but it'll get a NULL pointer back.) The basic model is that NSApplication's -run method loops around, getting events from the window server and propagating them through the responder chain. From what I understand, lots of other things go on between the time that the -run method asks for an event and the time that it's delivered: raw window server events arrive; some of them are passed to Carbon event handlers (which might in some cases call Cocoa methods), some are related to keeping the window server's model of what's on screen in synch with the application's (drawRect: methods get called at this time), etc. All of this is (by default) happening on the distinguished, blessed event thread. Some of the time of course, an NSEvent will eventually get returned to the caller. Tim Moore and I tried some experiments about a year ago to see if we could intercept window-specific events and dispatch them to handlers that ran in window-specific threads (the thinking was that this was a lot closer to McCLIM's CLX backend's behavior.) The idea sort of worked (at least halfway). One way in which I remember it failing was when clicking on a window close button: the (blessed) event thread was waiting for the window-specific thread to unlock the view focus so it could ... do whatever it does, and the window-specific thread was waiting for a mouse-up event that never came. It might have been possible to think a little harder and avoid this particular deadlock situation, but I got the strong impression that there were lots more deadlock situations waiting to happen. Apple had a Tech Note or similar document whose title was something like "AppKit is too thread-safe! Stop saying that it isn't !". That document enumerated a small number of reasonable-sounding guidelines; I don't think that it's too hard to follow them carefully and still see totally unreasonable behavior. I was trying a few months ago to build an NSTextView "manually" in some random (non-blessed) thread and it kept crashing; there could have been any number of reasons for that failure, but I eventually determined that as soon as I'd created an NSLayoutManager the blessed (if you'll pardon the expression) thread decided that that'd be a good time to do background glyph layout. (It wasn't ...). I couldn't find a reliable way of preventing that from happening; in Cocoa's implicit view of the world, an NSTextView could only be constructed in the blessed event thread by some event handler (why on earth would a compute-bound thread want to create an NSTextView or an NSLayoutManager ?) IIRC, I eventually wound up PROCESS-INTERRUPTing the event thread and asked it to make the NSTextView for me; that seemed to work fine. I'm not sure that I'm not just violently agreeing with points that other people have made; if people are thinking about bouncing events around between multiple lisp threads, I hope that they're aware of these issues and have thought of things that I'm missing. The conclusion I came to is that Cocoa is really designed to have just about all of the interesting UI stuff happen in its blessed thread, and if any other approach is possible it may go so far against the grain as to be impractical. Gary Byers gb at clozure.com From mikel at evins.net Thu Feb 5 22:00:45 2004 From: mikel at evins.net (mikel evins) Date: Thu, 5 Feb 2004 14:00:45 -0800 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: <20040205131527.H2541@clozure.com> References: <20040205131527.H2541@clozure.com> Message-ID: On Feb 5, 2004, at 1:47 PM, Gary Byers wrote: > I just subscribed to this list a little while ago and wanted to respond > to a few things that I saw in the archives. I probably won't be able > to attribute things too accurately, and I'm sure that I've missed > parts of the discussion and may be replying to some things out of > context. > > To the best of my knowledge, it's effectively the case that only one > thread can fetch events from/communcate directly with the window > server. Prior to Panther, this was the thread whose CFRunloop was the > "main" CFRunloop (there's still some code in OpenMCL's Cocoa demo that > tries to play around with this, and it used to be the case that > something called an undocumented function - something like > "_CFRunLoopSetMain" - to try to get around this. CF's "main" runloop > ordinarily got created when CF was initialized, and it was associated > with the thread that did that initialization.) > > Panther put an end to all this: the thread that's allowed to talk to > the Window Server is the application's initial thread (the one > that started out by calling main(), way back when) and none other. > (Any other thread can certainly try to call NSApplication's > nextEventMatchingMaskWhateverTheOtherArgsAre, but it'll get a NULL > pointer back.) > > The basic model is that NSApplication's -run method loops around, > getting events from the window server and propagating them through > the responder chain. From what I understand, lots of other things > go on between the time that the -run method asks for an event and > the time that it's delivered: raw window server events arrive; > some of them are passed to Carbon event handlers (which might in > some cases call Cocoa methods), some are related to keeping the > window server's model of what's on screen in synch with the > application's (drawRect: methods get called at this time), etc. > All of this is (by default) happening on the distinguished, blessed > event thread. > > Some of the time of course, an NSEvent will eventually get returned > to the caller. Tim Moore and I tried some experiments about a year > ago to see if we could intercept window-specific events and dispatch > them to handlers that ran in window-specific threads (the thinking > was that this was a lot closer to McCLIM's CLX backend's behavior.) > The idea sort of worked (at least halfway). One way in which I > remember it failing was when clicking on a window close button: > the (blessed) event thread was waiting for the window-specific > thread to unlock the view focus so it could ... do whatever it > does, and the window-specific thread was waiting for a mouse-up > event that never came. It might have been possible to think > a little harder and avoid this particular deadlock situation, > but I got the strong impression that there were lots more deadlock > situations waiting to happen. > > Apple had a Tech Note or similar document whose title was something > like "AppKit is too thread-safe! Stop saying that it isn't !". That > document enumerated a small number of reasonable-sounding guidelines; > I don't think that it's too hard to follow them carefully and still > see totally unreasonable behavior. I was trying a few months ago > to build an NSTextView "manually" in some random (non-blessed) thread > and it kept crashing; there could have been any number of reasons > for that failure, but I eventually determined that as soon as I'd > created an NSLayoutManager the blessed (if you'll pardon the > expression) > thread decided that that'd be a good time to do background glyph > layout. (It wasn't ...). I couldn't find a reliable way of preventing > that from happening; in Cocoa's implicit view of the world, an > NSTextView could only be constructed in the blessed event thread > by some event handler (why on earth would a compute-bound thread > want to create an NSTextView or an NSLayoutManager ?) IIRC, I > eventually wound up PROCESS-INTERRUPTing the event thread and > asked it to make the NSTextView for me; that seemed to work fine. > > I'm not sure that I'm not just violently agreeing with points that > other people have made; if people are thinking about bouncing events > around between multiple lisp threads, I hope that they're aware of > these issues and have thought of things that I'm missing. The > conclusion I came to is that Cocoa is really designed to have just > about all of the interesting UI stuff happen in its blessed thread, > and if any other approach is possible it may go so far against the > grain as to be impractical. > This all agrees with my understanding, except that you know more about the details than I do. My embryonic McCLIM back-end builds a normal OSX application bundle and starts a blessed event loop in the normal way; my theory is that the event loop can hand events to windows and views in the normal-for-Cocoa way and the event handlers on the windows and views can trigger McCLIM functions, marshalling data as needed. Duncan says he has some things sort of working by grabbing events himself, but it's possible he's living in the sort of twilight world that you describe above; I'm sure he'll weigh in on that. He and I have been discussing a merge; if debugging event-handling is holding him up, and it turns out to be the same sort of problem you described, then it's possible that in the forthcoming merge he and I can fix things by switching to the Cocoa-event-loop-centric model. --me From duncan at robotcat.demon.co.uk Thu Feb 5 22:39:03 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 5 Feb 2004 22:39:03 +0000 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: Message-ID: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> On Thursday, February 5, 2004, at 10:00 PM, mikel evins wrote: > > On Feb 5, 2004, at 1:47 PM, Gary Byers wrote: > >> I just subscribed to this list a little while ago and wanted to >> respond >> to a few things that I saw in the archives. I probably won't be able >> to attribute things too accurately, and I'm sure that I've missed >> parts of the discussion and may be replying to some things out of >> context. >> >> To the best of my knowledge, it's effectively the case that only one >> thread can fetch events from/communcate directly with the window >> server. Prior to Panther, this was the thread whose CFRunloop was the >> "main" CFRunloop (there's still some code in OpenMCL's Cocoa demo that >> tries to play around with this, and it used to be the case that >> something called an undocumented function - something like >> "_CFRunLoopSetMain" - to try to get around this. CF's "main" runloop >> ordinarily got created when CF was initialized, and it was associated >> with the thread that did that initialization.) >> >> Panther put an end to all this: the thread that's allowed to talk to >> the Window Server is the application's initial thread (the one >> that started out by calling main(), way back when) and none other. >> (Any other thread can certainly try to call NSApplication's >> nextEventMatchingMaskWhateverTheOtherArgsAre, but it'll get a NULL >> pointer back.) >> >> The basic model is that NSApplication's -run method loops around, >> getting events from the window server and propagating them through >> the responder chain. From what I understand, lots of other things >> go on between the time that the -run method asks for an event and >> the time that it's delivered: raw window server events arrive; >> some of them are passed to Carbon event handlers (which might in >> some cases call Cocoa methods), some are related to keeping the >> window server's model of what's on screen in synch with the >> application's (drawRect: methods get called at this time), etc. >> All of this is (by default) happening on the distinguished, blessed >> event thread. >> >> Some of the time of course, an NSEvent will eventually get returned >> to the caller. Tim Moore and I tried some experiments about a year >> ago to see if we could intercept window-specific events and dispatch >> them to handlers that ran in window-specific threads (the thinking >> was that this was a lot closer to McCLIM's CLX backend's behavior.) >> The idea sort of worked (at least halfway). One way in which I >> remember it failing was when clicking on a window close button: >> the (blessed) event thread was waiting for the window-specific >> thread to unlock the view focus so it could ... do whatever it >> does, and the window-specific thread was waiting for a mouse-up >> event that never came. It might have been possible to think >> a little harder and avoid this particular deadlock situation, >> but I got the strong impression that there were lots more deadlock >> situations waiting to happen. >> >> Apple had a Tech Note or similar document whose title was something >> like "AppKit is too thread-safe! Stop saying that it isn't !". That >> document enumerated a small number of reasonable-sounding guidelines; >> I don't think that it's too hard to follow them carefully and still >> see totally unreasonable behavior. I was trying a few months ago >> to build an NSTextView "manually" in some random (non-blessed) thread >> and it kept crashing; there could have been any number of reasons >> for that failure, but I eventually determined that as soon as I'd >> created an NSLayoutManager the blessed (if you'll pardon the >> expression) >> thread decided that that'd be a good time to do background glyph >> layout. (It wasn't ...). I couldn't find a reliable way of >> preventing >> that from happening; in Cocoa's implicit view of the world, an >> NSTextView could only be constructed in the blessed event thread >> by some event handler (why on earth would a compute-bound thread >> want to create an NSTextView or an NSLayoutManager ?) IIRC, I >> eventually wound up PROCESS-INTERRUPTing the event thread and >> asked it to make the NSTextView for me; that seemed to work fine. >> >> I'm not sure that I'm not just violently agreeing with points that >> other people have made; if people are thinking about bouncing events >> around between multiple lisp threads, I hope that they're aware of >> these issues and have thought of things that I'm missing. The >> conclusion I came to is that Cocoa is really designed to have just >> about all of the interesting UI stuff happen in its blessed thread, >> and if any other approach is possible it may go so far against the >> grain as to be impractical. >> > > > This all agrees with my understanding, except that you know more about > the details than I do. My embryonic McCLIM back-end builds a normal > OSX application bundle and starts a blessed event loop in the normal > way; my theory is that the event loop can hand events to windows and > views in the normal-for-Cocoa way and the event handlers on the > windows and views can trigger McCLIM functions, marshalling data as > needed. > > Duncan says he has some things sort of working by grabbing events > himself, but it's possible he's living in the sort of twilight world > that you describe above; I'm sure he'll weigh in on that. > Indeed - I went off on a bit of a tangent for a couple of weeks 8-) investigating events and run-loops and all that stuff. The only way I got it to work in the end was to get rid of all that stuff and implement a simple solution. Basically what I do is subclass NSView with Lisp objects using def-objc-class and override the event methods. Each of these event methods looks like: (ccl::define-objc-method ((:void :mouse-up event) lisp-view) (add-event-to-queue self event)) The add-event-to-queue method converts the Cocoa event into a CLIM event and appends it to a list; the McCLIM event processing pops events off the list when it wants them and does its stuff. This provides a mechanism allowing Cocoa to force events on the back end code, and for CLIM to request them as needed. It might be easier to implement this in send-event rather than implementing each event method individually, but I'm only at pre-pre-alpha stage currently. There is definitely mention in the Apple docs that all threads have a run-loop created for them, and that any thread that *starts* the run-loop can process events. So I don't think all is lost for handling events safely in a multi-threaded application. It may be the case that multiple run-loops can only be run if no inputs are shared; I didn't get far enough in my experimentation to say either way. That said, I still get the occasional Cocoa error, "Unable to unlock topmost reader" but that may be the way the back end is structured at the moment. Because CLIM keeps track of what's been drawn and what needs redrawing, I don't make use of the draw-rect method at all - so every drawing operation currently does a lock-focus and a focus release. This means (for drawing something like a scroll-pane) there are dozens of lock - draw - unlock operations in a very short period of time, which I suspect may cause the problems (it seems to happen mostly when there's lots of debug being output on a separate window). Hopefully this won't be (such) a problem when native panes are implemented (and I suspect there are ways around the problem anyway if necessary - but it's not a priority at the moment). So I'm not sure at the moment whether I have problems with events or not - there's still quite a way to go however. > He and I have been discussing a merge; if debugging event-handling is > holding him up, and it turns out to be the same sort of problem you > described, then it's possible that in the forthcoming merge he and I > can fix things by switching to the Cocoa-event-loop-centric model. > I'm actually getting very close to feeling ready to do a "release" (i.e. let somebody else see the code 8-). I'm waiting on implementing mouse moved events (hopefully will be done tonight), and getting user-input displayed in the window (key-up / key-down events are already received but seem to have no effect). The user-input display "problem" for me at the moment is I'm not clear on whether CLIM responds to a key event by drawing a glyph, or if I should draw the glyph on my own and then just report the key event to CLIM - so it may be quite straight-forward to resolve. I'll be looking at that tomorrow. Interestingly (or maybe not) CLIM and Cocoa provide very similar facilities for much of their windowing functionality. Unfortunately its done differently enough to be a bit of a pain. -Duncan > --me > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From duncan at robotcat.demon.co.uk Thu Feb 5 22:44:51 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 5 Feb 2004 22:44:51 +0000 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> Message-ID: > > Indeed - I went off on a bit of a tangent for a couple of weeks 8-) > investigating events and run-loops and all that stuff. The only way I > got it to work in the end was to get rid of all that stuff and > implement a simple solution. ... forgot to say: i.e. I do it the same way you would if you were writing an ObjectiveC Cocoa app that needed to respond to events - and ditched any manual manipulation. This wasn't clear from what I said - sorry for any people puzzling and then saying "but surely that's just the standard way to do it..." - yes, it would be. I guess 8-) -Duncan From mikel at evins.net Thu Feb 5 22:55:01 2004 From: mikel at evins.net (mikel evins) Date: Thu, 5 Feb 2004 14:55:01 -0800 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> References: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <541CB704-582E-11D8-B336-000A958E5B06@evins.net> On Feb 5, 2004, at 2:39 PM, Duncan Rose wrote: > There is definitely mention in the Apple docs that all threads have a > run-loop created for them, and that any thread that *starts* the > run-loop can process events. So I don't think all is lost for handling > events safely in a multi-threaded application. It may be the case that > multiple run-loops can only be run if no inputs are shared; I didn't > get far enough in my experimentation to say either way. > > There is a problem that the Window Server enqueues 'user' events for the main thread and no other. Other threads can create run loops and dequeue events, but under normal circumstances will never see 'user' events on their queues. The same holds true in Carbon as well. From mikel at evins.net Thu Feb 5 22:58:44 2004 From: mikel at evins.net (mikel evins) Date: Thu, 5 Feb 2004 14:58:44 -0800 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> References: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> Message-ID: On Feb 5, 2004, at 2:39 PM, Duncan Rose wrote: > The add-event-to-queue method converts the Cocoa event into a CLIM > event and appends it to a list; the McCLIM event processing pops > events off the list when it wants them and does its stuff. This > provides a mechanism allowing Cocoa to force events on the back end > code, and for CLIM to request them as needed. > > Seems like it should be possible to make a thread for CLIM that waits on this queue, so that each time you enqueue a synthesized event the CLIM thread wakes up and dequeues it. When you hand events to the CLIM code, do you tell Cocoa that the event was handled? Whichever way you answer there may be subtleties that could cause weird behavior; some events are meant to be handled by the first responder and that's it; others are meant to be maybe-handled by the first responder and then maybe handed off to one or more other responders. Finally, Command-key events traverse the responder chain *backwards* so that the application has first chance to process them. From duncan at robotcat.demon.co.uk Thu Feb 5 23:07:56 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 5 Feb 2004 23:07:56 +0000 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: Message-ID: <220B5D28-5830-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> On Thursday, February 5, 2004, at 10:58 PM, mikel evins wrote: > > On Feb 5, 2004, at 2:39 PM, Duncan Rose wrote: > >> The add-event-to-queue method converts the Cocoa event into a CLIM >> event and appends it to a list; the McCLIM event processing pops >> events off the list when it wants them and does its stuff. This >> provides a mechanism allowing Cocoa to force events on the back end >> code, and for CLIM to request them as needed. >> >> > > Seems like it should be possible to make a thread for CLIM that waits > on this queue, so that each time you enqueue a synthesized event the > CLIM thread wakes up and dequeues it. > > When you hand events to the CLIM code, do you tell Cocoa that the > event was handled? Whichever way you answer there may be subtleties > that could cause weird behavior; some events are meant to be handled > by the first responder and that's it; others are meant to be > maybe-handled by the first responder and then maybe handed off to one > or more other responders. Finally, Command-key events traverse the > responder chain *backwards* so that the application has first chance > to process them. > > Currently (disclaimer: pre-pre-alpha 8-) any event that's of a type CLIM would be interested in gets put onto the event list for CLIM. Any other events continue up the responder chain as normal. (This seems to be acceptable for most events. Mouse moved events get sent to the window irrespective of where the mouse is - CLIM probably isn't too interested in these if they don't happen over a CLIM window). I only handle key events in my lisp-window NSWindow subclass at the moment in any case, so *at the moment* it doesn't make any difference if they go up or down. There's no event handling in the NSApplication. I can't say I'm particularly happy with the way I'm handling events at the moment; or, to be honest, with the way I'm handling anything else either! (I'm thinking at the moment it may have been a bad idea to attempt to "Cocoaify" the CLX back end, which is what I've done in effect, rather than start from scratch.) -Duncan > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From duncan at robotcat.demon.co.uk Thu Feb 5 23:09:12 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 5 Feb 2004 23:09:12 +0000 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: Message-ID: <4F566FC3-5830-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> On Thursday, February 5, 2004, at 10:58 PM, mikel evins wrote: > > Seems like it should be possible to make a thread for CLIM that waits > on this queue, so that each time you enqueue a synthesized event the > CLIM thread wakes up and dequeues it. > > This is what is happening at the moment; but as yet, there's no waiting (just tight looping, ouch). -Duncan From moore at bricoworks.com Thu Feb 5 23:12:56 2004 From: moore at bricoworks.com (Timothy Moore) Date: Fri, 6 Feb 2004 00:12:56 +0100 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> References: <191D973B-582C-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> Message-ID: On Feb 5, 2004, at 11:39 PM, Duncan Rose wrote: > Basically what I do is subclass NSView with Lisp objects using > def-objc-class and override the event methods. Each of these event > methods looks like: > > (ccl::define-objc-method ((:void :mouse-up event) lisp-view) > (add-event-to-queue self event)) > > The add-event-to-queue method converts the Cocoa event into a CLIM > event and appends it to a list; the McCLIM event processing pops > events off the list when it wants them and does its stuff. This > provides a mechanism allowing Cocoa to force events on the back end > code, and for CLIM to request them as needed. > That's all fine. What I've been worried about all along is "events" going the other way. For example, the layout of the CLIM applications changes, so NSViews need to be deleted (perhaps) and resized. > It might be easier to implement this in send-event rather than > implementing each event method individually, but I'm only at > pre-pre-alpha stage currently. > > There is definitely mention in the Apple docs that all threads have a > run-loop created for them, and that any thread that *starts* the > run-loop can process events. So I don't think all is lost for handling > events safely in a multi-threaded application. It may be the case that > multiple run-loops can only be run if no inputs are shared; I didn't > get far enough in my experimentation to say either way. Do you want/need to use a Cocoa specific mechanism for passing messages between threads instead of the CLIM event queues? > > That said, I still get the occasional Cocoa error, "Unable to unlock > topmost reader" but that may be the way the back end is structured at > the moment. Because CLIM keeps track of what's been drawn and what > needs redrawing, I don't make use of the draw-rect method at all - so > every drawing operation currently does a lock-focus and a focus > release. This means (for drawing something like a scroll-pane) there > are dozens of lock - draw - unlock operations in a very short period > of time, which I suspect may cause the problems (it seems to happen > mostly when there's lots of debug being output on a separate window). > Hopefully this won't be (such) a problem when native panes are > implemented (and I suspect there are ways around the problem anyway if > necessary - but it's not a priority at the moment). You might think about keeping a pane's medium (view) locked from the first drawing operation up to the call to force-output in the code that waits for events. > >> He and I have been discussing a merge; if debugging event-handling is >> holding him up, and it turns out to be the same sort of problem you >> described, then it's possible that in the forthcoming merge he and I >> can fix things by switching to the Cocoa-event-loop-centric model. >> > > I'm actually getting very close to feeling ready to do a "release" > (i.e. let somebody else see the code 8-). I'm waiting on implementing > mouse moved events (hopefully will be done tonight), and getting > user-input displayed in the window (key-up / key-down events are > already received but seem to have no effect). The user-input display > "problem" for me at the moment is I'm not clear on whether CLIM > responds to a key event by drawing a glyph, or if I should draw the > glyph on my own and then just report the key event to CLIM - so it may > be quite straight-forward to resolve. I'll be looking at that > tomorrow. I'm not sure how much of CLIM you're using at this point, but CLIM does expect to draw the glyphs itself after a key event on a stream. > Interestingly (or maybe not) CLIM and Cocoa provide very similar > facilities for much of their windowing functionality. Unfortunately > its done differently enough to be a bit of a pain. > Sigh, yeah... Tim From duncan at robotcat.demon.co.uk Fri Feb 6 00:00:22 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Fri, 6 Feb 2004 00:00:22 +0000 Subject: [mac-lisp-ide] runloops, threads, etc. In-Reply-To: Message-ID: <755F316C-5837-11D8-9CAF-000A9577B8A2@robotcat.demon.co.uk> On Thursday, February 5, 2004, at 11:12 PM, Timothy Moore wrote: > > On Feb 5, 2004, at 11:39 PM, Duncan Rose wrote: >> Basically what I do is subclass NSView with Lisp objects using >> def-objc-class and override the event methods. Each of these event >> methods looks like: >> >> (ccl::define-objc-method ((:void :mouse-up event) lisp-view) >> (add-event-to-queue self event)) >> >> The add-event-to-queue method converts the Cocoa event into a CLIM >> event and appends it to a list; the McCLIM event processing pops >> events off the list when it wants them and does its stuff. This >> provides a mechanism allowing Cocoa to force events on the back end >> code, and for CLIM to request them as needed. >> > That's all fine. What I've been worried about all along is "events" > going the other way. For example, the layout of the CLIM applications > changes, so NSViews need to be deleted (perhaps) and resized. I'm hoping this will be fine, as long as CLIM redraws the sheets it resizes. >> It might be easier to implement this in send-event rather than >> implementing each event method individually, but I'm only at >> pre-pre-alpha stage currently. >> >> There is definitely mention in the Apple docs that all threads have a >> run-loop created for them, and that any thread that *starts* the >> run-loop can process events. So I don't think all is lost for >> handling events safely in a multi-threaded application. It may be the >> case that multiple run-loops can only be run if no inputs are shared; >> I didn't get far enough in my experimentation to say either way. > Do you want/need to use a Cocoa specific mechanism for passing > messages between threads instead of the CLIM event queues? I don't think that will be necessary. Events appear to be working ok at the moment (although perhaps not very efficiently...) >> >> That said, I still get the occasional Cocoa error, "Unable to unlock >> topmost reader" but that may be the way the back end is structured at >> the moment. Because CLIM keeps track of what's been drawn and what >> needs redrawing, I don't make use of the draw-rect method at all - so >> every drawing operation currently does a lock-focus and a focus >> release. This means (for drawing something like a scroll-pane) there >> are dozens of lock - draw - unlock operations in a very short period >> of time, which I suspect may cause the problems (it seems to happen >> mostly when there's lots of debug being output on a separate window). >> Hopefully this won't be (such) a problem when native panes are >> implemented (and I suspect there are ways around the problem anyway >> if necessary - but it's not a priority at the moment). > You might think about keeping a pane's medium (view) locked from the > first drawing operation up to the call to force-output in the code > that waits for events. I was trying to minimise the length of time I had a view locked for. Again, I'm not sure this is necessary but it seemed like a good idea at the time (I think locking a view will block the window server until the lock is released; it's possible it just locks the thread responsible for the locked view (maybe even likely) but I haven't experimented with this yet). I was thinking of maybe hunting out the drawing-intensive methods (which I think are in the pane realization code somewhere - I haven't looked yet) and creating :around methods which locked the focus, call next method, then unlocked focus. But again, I'm not far enough down the path to have tried any of this yet. >> >>> He and I have been discussing a merge; if debugging event-handling >>> is holding him up, and it turns out to be the same sort of problem >>> you described, then it's possible that in the forthcoming merge he >>> and I can fix things by switching to the Cocoa-event-loop-centric >>> model. >>> >> >> I'm actually getting very close to feeling ready to do a "release" >> (i.e. let somebody else see the code 8-). I'm waiting on implementing >> mouse moved events (hopefully will be done tonight), and getting >> user-input displayed in the window (key-up / key-down events are >> already received but seem to have no effect). The user-input display >> "problem" for me at the moment is I'm not clear on whether CLIM >> responds to a key event by drawing a glyph, or if I should draw the >> glyph on my own and then just report the key event to CLIM - so it >> may be quite straight-forward to resolve. I'll be looking at that >> tomorrow. > > I'm not sure how much of CLIM you're using at this point, but CLIM > does expect to draw the glyphs itself after a key event on a stream. Pretty much all of it. I think the problem may well be to do with my (CLIM) events in that case. The back end isn't being asked to draw glyphs after key down / up events are processed. Time to put some debug into the McCLIM "core" code and see what's happening to them... >> Interestingly (or maybe not) CLIM and Cocoa provide very similar >> facilities for much of their windowing functionality. Unfortunately >> its done differently enough to be a bit of a pain. >> > Sigh, yeah... > Tim > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From beer at eecs.cwru.edu Sat Feb 7 04:37:57 2004 From: beer at eecs.cwru.edu (Randall Beer) Date: Fri, 6 Feb 2004 23:37:57 -0500 Subject: [mac-lisp-ide] Extending clotho In-Reply-To: <4D47A1FA-57FC-11D8-B336-000A958E5B06@evins.net> References: <73847470-57EB-11D8-BD80-000A95675D7E@eecs.cwru.edu> <4D47A1FA-57FC-11D8-B336-000A958E5B06@evins.net> Message-ID: <670584B2-5927-11D8-9772-000A95675D7E@eecs.cwru.edu> >> Might it be useful to think of a Cocoa application as a special kind >> of Lisp system? If we had a ProjectBuilder sort of GUI for working >> with (ASDF or DEFSYSTEM) Lisp systems, then we could also use it to >> work with Cocoa applications. COCOA-APPLICATIONS could have >> additional file types associated with them, and could also responsd >> to a SAVE-COCOA-APPLICATION operation (perhaps by starting up another >> OpenMCL with a command line option set to load in the specified >> system and then SAVE-APPLICATION). >> > > Yah; this is a good idea. One other thing that might be interesting for someone to look into: F-Script (http://www.fscript.org/) allows a "live" interpreter to be embedded inside Interface Builder, allowing interaction with UI objects in Interface Builder (see http://www.macdevcenter.com/pub/a/mac/2002/07/12/embed_fscript.html? page=3). I wonder if it might be possible to use similar tricks to get OpenMCL talking directly to Interface Builder via a remote REPL, allowing a very tight interaction between the two in building GUIs. Randy From mikel at evins.net Sat Feb 7 05:00:19 2004 From: mikel at evins.net (mikel evins) Date: Fri, 6 Feb 2004 21:00:19 -0800 Subject: [mac-lisp-ide] Extending clotho In-Reply-To: <670584B2-5927-11D8-9772-000A95675D7E@eecs.cwru.edu> References: <73847470-57EB-11D8-BD80-000A95675D7E@eecs.cwru.edu> <4D47A1FA-57FC-11D8-B336-000A958E5B06@evins.net> <670584B2-5927-11D8-9772-000A95675D7E@eecs.cwru.edu> Message-ID: <86AF1483-592A-11D8-8E7E-000A958E5B06@evins.net> On Feb 6, 2004, at 8:37 PM, Randall Beer wrote: >>> Might it be useful to think of a Cocoa application as a special kind >>> of Lisp system? If we had a ProjectBuilder sort of GUI for working >>> with (ASDF or DEFSYSTEM) Lisp systems, then we could also use it to >>> work with Cocoa applications. COCOA-APPLICATIONS could have >>> additional file types associated with them, and could also responsd >>> to a SAVE-COCOA-APPLICATION operation (perhaps by starting up >>> another OpenMCL with a command line option set to load in the >>> specified system and then SAVE-APPLICATION). >>> >> >> Yah; this is a good idea. > > One other thing that might be interesting for someone to look into: > > F-Script (http://www.fscript.org/) allows a "live" interpreter to be > embedded inside Interface Builder, allowing interaction with UI > objects in Interface Builder (see > http://www.macdevcenter.com/pub/a/mac/2002/07/12/embed_fscript.html? > page=3). > > I wonder if it might be possible to use similar tricks to get OpenMCL > talking directly to Interface Builder via a remote REPL, allowing a > very tight interaction between the two in building GUIs. > Cool idea. I note that F-Script sources are available to study. I'll look into it. From bmastenb at cs.indiana.edu Tue Feb 10 14:21:49 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Tue, 10 Feb 2004 09:21:49 -0500 Subject: [mac-lisp-ide] Moving forward... Message-ID: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> Howdy folks, There hasn't been any activity here for a few days, so I'm wondering how people are doing - in particular I'm wondering if the McCLIM people found a way to start working together? Is work on Clotho waiting on changes to the cocoa interface? This is the impression I got but I'm wondering if it's a good idea to start working on other aspects of it (debugger, inspector). Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From mikel at evins.net Tue Feb 10 15:56:14 2004 From: mikel at evins.net (mikel evins) Date: Tue, 10 Feb 2004 07:56:14 -0800 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> Message-ID: On Feb 10, 2004, at 6:21 AM, Brian Mastenbrook wrote: > Howdy folks, > > There hasn't been any activity here for a few days, so I'm wondering > how people are doing - in particular I'm wondering if the McCLIM > people found a way to start working together? Duncan and are sharing a temporary cvs repository while we work out and merge a couple of issues. He reports that he's got the merged code doing what it's supposed to. I am delayed on further progress while I do what I am paid to do instead of testing the latest changes personally, but presuming that the last code I checked in works for him, and the latest changes he checked in work for me, we are close to ready to check the project into the main McCLIM repository. The McCLIM listener is working, after a fashion, on OpenMCL and Cocoa, though it needs further attention in several areas before anyone would really want to use it. > > Is work on Clotho waiting on changes to the cocoa interface? This is > the impression I got but I'm wondering if it's a good idea to start > working on other aspects of it (debugger, inspector). Clotho is waiting on my paying job, rather than on any further releases from Gary, but it is true that Gary is near a new release of OpenMCL. The new release will have a new version of the Objective C interface, the first to provide CLOS metaclasses that make Objective C classes and methods look like CLOS classes and methods. There is a caveat for us: the initial release probably will make apps built on Jaguar unlaunchable on Panther and vice-versa. There is likely to be a period, therefore, where we really want to have both Jaguar and Panther hosts available for building binaries (though perhaps it's early enough in Clotho's lifespan that we can get away with sources-only releases for a while). I did have time to build a small library of filesystem utilities to make the Clotho and McCLIM builds a little more robust; they are primarily intended to make it easier to copy the darwin-interfaces into the application bundle so that the built application is independent of the location of those interfaces in an installed OpenMCL, and so that it can run on a system where OpenMCL is not installed before Clotho or McCLIM is installed. I may have some time soon to check in my changes to the Clotho project, but there's a little integration work to do. Oh, and Apple's Java 1.4.2 release broke both my fop installation and, unaccountably, (perhaps indirectly), my copy of the 'open' command-line utility, so I spent some time last night backing up, wiping my disk, reinstalling Panther, and restoring my working environment. Joy. I think it likely that the next thing I do will be to splice Hamilton Link's windowing inspector into Clotho, though I also have some McCLIM-related tasks, and I want to spend some time seeing if I can hack up a version of portable Hemlock that works with Clotho. And I have some work to do on the Hansa game server as well. No rest for the weary. :-) --me From gb at clozure.com Tue Feb 10 16:29:59 2004 From: gb at clozure.com (Gary Byers) Date: Tue, 10 Feb 2004 09:29:59 -0700 (MST) Subject: [mac-lisp-ide] Moving forward... In-Reply-To: References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> Message-ID: <20040210092631.Y31420@clozure.com> On Tue, 10 Feb 2004, mikel evins wrote: > > > Clotho is waiting on my paying job, rather than on any further releases > from Gary, but it is true that Gary is near a new release of OpenMCL. > The new release will have a new version of the Objective C interface, > the first to provide CLOS metaclasses that make Objective C classes and > methods look like CLOS classes and methods. There is a caveat for us: > the initial release probably will make apps built on Jaguar > unlaunchable on Panther and vice-versa. There is likely to be a period, > therefore, where we really want to have both Jaguar and Panther hosts > available for building binaries (though perhaps it's early enough in > Clotho's lifespan that we can get away with sources-only releases for a > while). > Just to clarify: we didn't get methods integrated (yet). There's a terse (but hopefully correct) description of what works (and known limitations) in . Hopefully, the new release will be out later today. Gary Byers gb at clozure.com From bmastenb at cs.indiana.edu Tue Feb 10 16:42:08 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Tue, 10 Feb 2004 11:42:08 -0500 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <20040210092631.Y31420@clozure.com> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <20040210092631.Y31420@clozure.com> Message-ID: <1162846C-5BE8-11D8-B93C-000A9599AF88@cs.indiana.edu> On Feb 10, 2004, at 11:29 AM, Gary Byers wrote: > Just to clarify: we didn't get methods integrated (yet). There's a > terse (but hopefully correct) description of what works (and known > limitations) in . > > Hopefully, the new release will be out later today. Very nice! Are there plans to export the relevant symbols from CCL, so that it's easy to write cocoa code outside of the CCL package? That bothers my sense of aesthetics :-) Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From gb at clozure.com Tue Feb 10 17:03:10 2004 From: gb at clozure.com (Gary Byers) Date: Tue, 10 Feb 2004 10:03:10 -0700 (MST) Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <1162846C-5BE8-11D8-B93C-000A9599AF88@cs.indiana.edu> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <20040210092631.Y31420@clozure.com> <1162846C-5BE8-11D8-B93C-000A9599AF88@cs.indiana.edu> Message-ID: <20040210094306.O31468@clozure.com> On Tue, 10 Feb 2004, Brian Mastenbrook wrote: > > On Feb 10, 2004, at 11:29 AM, Gary Byers wrote: > > > Just to clarify: we didn't get methods integrated (yet). There's a > > terse (but hopefully correct) description of what works (and known > > limitations) in . > > > > Hopefully, the new release will be out later today. > > Very nice! Are there plans to export the relevant symbols from CCL, so > that it's easy to write cocoa code outside of the CCL package? That > bothers my sense of aesthetics :-) > > Brian > -- If we do this right, most Cocoa code will be written using symbols exported from the CL package, with occasional references to predefined Cocoa things exported from the NS package. Exactly what set of other infrastructure-layer things will need to be publicly accessible isn't yet clear. I understand that people with delicate sensibilities might be offended by the fact that a large part of this still isn't done right and is still a random hodgepodge of internal CCL package stuff. I don't believe that that concern justifies exporting a lot of randomness; people -should- view this as a moving target (at least until it stops moving as much as it has in the near past and is likely to in the near future.) Since it was documented (if not exported), the demise of CCL::DEF-OBJC-CLASS should probably be noted somewhere. (Ah, CCL::DEF-OBJC-CLASS, we hardly knew ye.) Having observed that moment of silence, it seems appropriate to move forward. Gary Byers gb at clozure.com From tfb at OCF.Berkeley.EDU Tue Feb 10 19:23:30 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 10 Feb 2004 11:23:30 -0800 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <20040210094306.O31468@clozure.com> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <20040210092631.Y31420@clozure.com> <1162846C-5BE8-11D8-B93C-000A9599AF88@cs.indiana.edu> <20040210094306.O31468@clozure.com> Message-ID: <16425.12210.433901.901147@famine.OCF.Berkeley.EDU> Gary Byers writes: > I understand that people with delicate sensibilities might be offended > by the fact that a large part of this still isn't done right and is > still a random hodgepodge of internal CCL package stuff. I don't > believe that that concern justifies exporting a lot of randomness; > people -should- view this as a moving target (at least until it stops > moving as much as it has in the near past and is likely to in the near > future.) That's a pretty good reason for not exporting the symbols. For others like myself, reaching for package nirvana, who try to avoid typing :: when possible, I'd recommend what I did for MCL's Open Transport library, which doesn't export its symbols from CCL: (in-package :mcl-net) (require :opentransport) (import '(ccl::open-tcp-stream ccl::opentransport-tcp-stream ccl::opentransport-binary-tcp-stream ...)) (export '(open-tcp-stream stream-connection-state stream-connectedp ...)) Now I just worry about using symbols from my own MCL-NET package. Plus, you get the benefit of having the chance to clean up the interface, which is probably even more important for a work-in-progress like OpenMCL's Objective-C support. From moore at bricoworks.com Tue Feb 10 14:36:26 2004 From: moore at bricoworks.com (Timothy Moore) Date: Tue, 10 Feb 2004 15:36:26 +0100 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> Message-ID: <81B695F8-5BD6-11D8-AA69-000A959839F8@bricoworks.com> On Feb 10, 2004, at 3:21 PM, Brian Mastenbrook wrote: > Howdy folks, > > There hasn't been any activity here for a few days, so I'm wondering > how people are doing - in particular I'm wondering if the McCLIM > people found a way to start working together? Yeah, if you guys want to put code for the Cocoa backend into the McCLIM tree, let me know. Tim From mikel at evins.net Tue Feb 10 20:24:34 2004 From: mikel at evins.net (mikel evins) Date: Tue, 10 Feb 2004 12:24:34 -0800 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <81B695F8-5BD6-11D8-AA69-000A959839F8@bricoworks.com> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <81B695F8-5BD6-11D8-AA69-000A959839F8@bricoworks.com> Message-ID: <24127998-5C07-11D8-85D3-000A958E5B06@evins.net> On Feb 10, 2004, at 6:36 AM, Timothy Moore wrote: > On Feb 10, 2004, at 3:21 PM, Brian Mastenbrook wrote: > >> Howdy folks, >> >> There hasn't been any activity here for a few days, so I'm wondering >> how people are doing - in particular I'm wondering if the McCLIM >> people found a way to start working together? > Yeah, if you guys want to put code for the Cocoa backend into the > McCLIM tree, let me know. > I sent mail to the McCLIM list about this; Duncan and I are merged and the Listener runs--sort of. It needs a lot of debugging and other work, but it seems worthwhile to check it in. There is a new Backend (currently called "Cocoa", but see below), whose structure is based on Bosco, and there is a new system-cocoa.lisp system definition and a few changes to the toplevel ports.lisp. The current name of the Backend is "Cocoa", but that's probably not right. For one thing, it's OpenMCL-specific; what if you get an SBCL-based Cocoa Backend working, for example? I'd be interested in hearing people's naming suggestions before we go committing a new directory to McCLIM. --me From moore at bricoworks.com Tue Feb 10 20:29:33 2004 From: moore at bricoworks.com (Timothy Moore) Date: Tue, 10 Feb 2004 21:29:33 +0100 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <24127998-5C07-11D8-85D3-000A958E5B06@evins.net> References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <81B695F8-5BD6-11D8-AA69-000A959839F8@bricoworks.com> <24127998-5C07-11D8-85D3-000A958E5B06@evins.net> Message-ID: On Feb 10, 2004, at 9:24 PM, mikel evins wrote: > > The current name of the Backend is "Cocoa", but that's probably not > right. For one thing, it's OpenMCL-specific; what if you get an > SBCL-based Cocoa Backend working, for example? I'd be interested in > hearing people's naming suggestions before we go committing a new > directory to McCLIM. > If a SBCL-based Cocoa backend appeared I'd really hope, in fact I would insist, that it share code with an OpenMCL backend unless some issue made that completely impossible. I don't think we need to worry about other Cocoa backends showing up any time soon :), but you could call it "MetaCocoa" or something. Tim From mikel at evins.net Tue Feb 10 20:36:07 2004 From: mikel at evins.net (mikel evins) Date: Tue, 10 Feb 2004 12:36:07 -0800 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: References: <76FED154-5BD4-11D8-B072-000A9599AF88@cs.indiana.edu> <81B695F8-5BD6-11D8-AA69-000A959839F8@bricoworks.com> <24127998-5C07-11D8-85D3-000A958E5B06@evins.net> Message-ID: On Feb 10, 2004, at 12:29 PM, Timothy Moore wrote: > On Feb 10, 2004, at 9:24 PM, mikel evins wrote: >> > >> The current name of the Backend is "Cocoa", but that's probably not >> right. For one thing, it's OpenMCL-specific; what if you get an >> SBCL-based Cocoa Backend working, for example? I'd be interested in >> hearing people's naming suggestions before we go committing a new >> directory to McCLIM. >> > If a SBCL-based Cocoa backend appeared I'd really hope, in fact I > would insist, that it share code with an OpenMCL backend unless some > issue made that completely impossible. I don't think we need to worry > about other Cocoa backends showing up any time soon :), but you could > call it "MetaCocoa" or something. > If nobody objects then I guess we can check it in as "Cocoa", on the understanding that code for future support of alternative lisps may require some reorganization (I always wince when I think about reorganizing directories in cvs). --me From duncan at robotcat.demon.co.uk Tue Feb 10 22:42:06 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Tue, 10 Feb 2004 22:42:06 +0000 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: Message-ID: <5A6A21D8-5C1A-11D8-9FB7-000A9577B8A2@robotcat.demon.co.uk> On Tuesday, February 10, 2004, at 08:36 PM, mikel evins wrote: > > On Feb 10, 2004, at 12:29 PM, Timothy Moore wrote: > >> On Feb 10, 2004, at 9:24 PM, mikel evins wrote: >>> >> >>> The current name of the Backend is "Cocoa", but that's probably not >>> right. For one thing, it's OpenMCL-specific; what if you get an >>> SBCL-based Cocoa Backend working, for example? I'd be interested in >>> hearing people's naming suggestions before we go committing a new >>> directory to McCLIM. >>> >> If a SBCL-based Cocoa backend appeared I'd really hope, in fact I >> would insist, that it share code with an OpenMCL backend unless some >> issue made that completely impossible. I don't think we need to >> worry about other Cocoa backends showing up any time soon :), but you >> could call it "MetaCocoa" or something. >> The current Cocoa back end shares a lot of code with the CLX back end - how much code can be shared above and beyond this depends on how an SBCL (or CMUCL now that's getting to work on OS X, or indeed a non-Free implementation) Cocoa interface might look; at the moment there's CCL:: peppered liberally over the code. I did initially start to put all the FFI methods into a separate source file and it might be worthwhile going back to that. My priority at the moment is to get it all working (obviously!) so I'm not really thinking about decent code separation currently. I'm intending on putting in a whole bunch more code when what's already there works "well enough" - at the moment I'm implementing the "McCLIM standard" look and feel and I want to implement a "Cocoa native" environment. I suspect much of the code will naturally separate out when I add this "Cocoa native" frame manager (I think this would not be straightforward to do with the code in its current state. I might be wrong about this though). Hopefully things will be clearer in another week. -Duncan > > If nobody objects then I guess we can check it in as "Cocoa", on the > understanding that code for future support of alternative lisps may > require some reorganization (I always wince when I think about > reorganizing directories in cvs). > > --me > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From duncan at robotcat.demon.co.uk Tue Feb 10 22:46:21 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Tue, 10 Feb 2004 22:46:21 +0000 Subject: [mac-lisp-ide] Moving forward... In-Reply-To: <5A6A21D8-5C1A-11D8-9FB7-000A9577B8A2@robotcat.demon.co.uk> Message-ID: > .snipped. > The current Cocoa back end shares a lot of code with the CLX back end > - how much code can be shared above and beyond this depends on how an > SBCL (or CMUCL now that's getting to work on OS X, or indeed a > non-Free implementation) Cocoa interface might look; at the moment > there's CCL:: peppered liberally over the code. On second thoughts this is quite misleading; the code isn't shared, it's cut and pasted so over time it's likely to diverge from the CLX code - so only a common heritage (rather than code) is shared. -Duncan .snipped. From mikel at evins.net Wed Feb 11 17:00:38 2004 From: mikel at evins.net (mikel evins) Date: Wed, 11 Feb 2004 09:00:38 -0800 Subject: [mac-lisp-ide] status of IDE projects Message-ID: Progress on the IDE projects: First, Gary Byers has released a new version of OpenMCL, version 0.14.1. This release has many bugfixes, better behavior with ANSI-compliance tests, and a major step forward in the Objective C bridge. On the other hand, it also means that Cocoa-related code, including Bosco and its derivatives, including both Clotho and the Cocoa backend for McCLIM, need overhauls to work with the new release. I intend to perform this overhaul as soon as possible; the current version of Bosco and its derivatives depend on the features in a range of CVS snapshots of 0.14, and that's undesirable. I think it's important to get them moved onto the released version as soon as possible. The new features of the Objective C bridge have many positive qualities (most important being that Objective C classes are now also CLOS classes), but the new code also introduces a problem for delivery of binaries: saved images are OSX-version-specific. In other words, if you build an application on Jaguar then it probably won't run on Panther, and vice versa. I believe this is a temporary situation, and most people that are using Bosco and its derivatives are building from source, but there may be a bit of a muddle if I get around to updating Alpaca before this issue is resolved in OpenMCL (to my knowledge, Alpaca is the only Bosco-derived application with users who don't build from source). For the moment, the Clotho IDE is unchanged. I've done some recent work on the build system for the Cocoa backend for McCLIM, and that work will also go into Clotho shortly. The major practical effect of the work is that the build process copies the Darwin interface databases into the built application bundle in a way that makes the Objective C bridge independent of the Lisp development system. To explain a little more fully: in old versions of Bosco-derived applications, you needed a copy of OpenMCL with the darwin-headers directory if you wanted to use the Objective C bridge interactively. That meant that, for example, Clotho and Alpaca could not use the macros and functions of the Objective C bridge unless the system on which they were deployed also had a copy of OpenMCL, with the darwin-headers directory where the app expected to find it. The new build system makes built applications more independent of their build environments by bundling a copy of the interfaces into the application itself. That means that you can, for example, expect to copy Clotho onto a new machine without a pre-existing copy of OpenMCL, and expect the Objective C bridge to work. Duncan got the McCLIM listener mostly up and functioning, albeit with significant cosmetic and autorelease-pool issues, and we're hacking on it in a privately-shared cvs repository until we get the go-ahead to commit it to the McCLIM repo. It might be a good idea for us to wait a bit longer before checking in, though, until I can get the overhaul done on Bosco and propagate the changes to Clotho and McCLIM.app. That way the checked-in McCLIM code will be based on a released version of OpenMCL. That's it from IDE land. If you're interested in working on either project (Clotho, the Cocoa-centric Lisp IDE, or McCLIM.app, the Cocoa backend for McCLIM), please drop me a line and I'll explain how to get started working on the code. --me From mikel at evins.net Mon Feb 16 22:39:13 2004 From: mikel at evins.net (mikel evins) Date: Mon, 16 Feb 2004 14:39:13 -0800 Subject: [mac-lisp-ide] Clotho 0.2 released Message-ID: The version 0.2 release of Clotho is tagged and released. Clotho is a Lisp programming environment for Mac OS X applications, written in Common Lisp. Clotho is built on OpenMCL 0.14.1 and the OpenMCL Objective C bridge. Clotho 0.2 is a very early release targeted at Lisp programmers who want to help develop an IDE for Lisp programming on Mac OS X. For more information about this goal and other projects that are intended to pursue it, see the mac-lisp-ide mailing list: http://common-lisp.net/mailman/listinfo/mac-lisp-ide You can download the Clotho 0.2 release from ftp://common-lisp.net/pub/project/clotho/Clotho_0.2.dmg ...or browse its CVS repository at http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=clotho Changes in the latest version of Clotho include: - Now based on the Bosco 0.5 framework - Now built on OpenMCL 0.14.1 - Added simple Listener history commands (M-p and M-n). - Ported key-handling from Alpaca. - Ported the initialization protocol from Alpaca - Ported the editor from Alpaca - Added source-file loading - Added Hamilton Link's Cocoa inspector window If you'd like to support the development of a great new open-source development environment for Common Lisp and Mac OS X, consider joining the Clotho project. You can find more information about Clotho at http://www.common-lisp.net/project/clotho/ For more information about Clotho and other projects to develop Lisp programming environments for Mac OS X, consider joining the Mac Lisp IDE mailing list. Information about the list is available at http://common-lisp.net/mailman/listinfo/mac-lisp-ide From gb at clozure.com Wed Feb 18 12:04:15 2004 From: gb at clozure.com (Gary Byers) Date: Wed, 18 Feb 2004 05:04:15 -0700 (MST) Subject: [mac-lisp-ide] multiple-choice question Message-ID: <20040218043159.G81563@clozure.com> Which of the following paradigms would people most like to see in a Mac lisp IDE ? (As used below, the term "window" means what [X]Emacs would call a "frame", i.e., a window-system window, and the term "view" means about what [X]Emacs would call a "window": some portion of a window-system window used to present a buffer and associated info (modeline, etc.)). a) traditional Mac/Cocoa behavior, where there's typically a 1:1 relationship between a buffer and a window and usually a single view per window; the distinction between a buffer/view/window is often nearly (and sometimes completely) blurred. b) traditional [X]Emacs behavior, where buffers can be presented in arbitrary views in arbitrary windows. c) (a) and (b) aren't mutually exclusive: the two paradigms can be integrated in an intuitive, usable fashion (perhaps by noting that (a)'s pretty much a proper subset of (b)). This is an essay question. d) both (a) and (b) are worth supporting, but they don't mix too well: a global preference should give the user a choice between (a) and (b). e) none of the above I personally lean towards (c), but I'm still working on the essay question. I think that it's fair to say that (a)'s simpler to fit into the Cocoa document-based application model, but I think that that model's general enough to support (b) as well. Gary Byers gb at clozure.com From duncan at robotcat.demon.co.uk Wed Feb 18 12:27:02 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Wed, 18 Feb 2004 12:27:02 +0000 Subject: [mac-lisp-ide] multiple-choice question In-Reply-To: <20040218043159.G81563@clozure.com> Message-ID: On Wednesday, February 18, 2004, at 12:04 PM, Gary Byers wrote: > Which of the following paradigms would people most like to see in a Mac > lisp IDE ? (As used below, the term "window" means what [X]Emacs would > call a "frame", i.e., a window-system window, and the term "view" means > about what [X]Emacs would call a "window": some portion of a > window-system > window used to present a buffer and associated info (modeline, etc.)). > > a) traditional Mac/Cocoa behavior, where there's typically a 1:1 > relationship between a buffer and a window and usually a single view > per window; the distinction between a buffer/view/window is often > nearly (and sometimes completely) blurred. > > b) traditional [X]Emacs behavior, where buffers can be presented in > arbitrary views in arbitrary windows. > > c) (a) and (b) aren't mutually exclusive: the two paradigms can be > integrated in an intuitive, usable fashion (perhaps by noting that > (a)'s pretty much a proper subset of (b)). This is an essay question. > > d) both (a) and (b) are worth supporting, but they don't mix too well: > a global preference should give the user a choice between (a) and (b). > > e) none of the above > > I personally lean towards (c), but I'm still working on the essay > question. I think that it's fair to say that (a)'s simpler to fit > into the Cocoa document-based application model, but I think that > that model's general enough to support (b) as well. > I'd vote for (c) too. Failing that, (b) alone would be my preference. But then, I've only recently started using Macs so maybe I'll change my mind with more exposure to "the Apple way". I'm not sure I understand why (c) is an essay question ... -Duncan > Gary Byers > gb at clozure.com > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From beer at eecs.cwru.edu Wed Feb 18 13:32:06 2004 From: beer at eecs.cwru.edu (Randall Beer) Date: Wed, 18 Feb 2004 08:32:06 -0500 Subject: [mac-lisp-ide] multiple-choice question In-Reply-To: <20040218043159.G81563@clozure.com> References: <20040218043159.G81563@clozure.com> Message-ID: I vote for (c) as well. As a long-time Mac user, I prefer (a), but (b) is occasionally useful. As long as I can set things up so that, by default, I get a new window every time I open a file, I'm happy. When I want multiple buffers in a window, something like a split-pane bar that I can drag down is very natural. On Feb 18, 2004, at 7:04 AM, Gary Byers wrote: > Which of the following paradigms would people most like to see in a Mac > lisp IDE ? (As used below, the term "window" means what [X]Emacs would > call a "frame", i.e., a window-system window, and the term "view" means > about what [X]Emacs would call a "window": some portion of a > window-system > window used to present a buffer and associated info (modeline, etc.)). > > a) traditional Mac/Cocoa behavior, where there's typically a 1:1 > relationship between a buffer and a window and usually a single view > per window; the distinction between a buffer/view/window is often > nearly (and sometimes completely) blurred. > > b) traditional [X]Emacs behavior, where buffers can be presented in > arbitrary views in arbitrary windows. > > c) (a) and (b) aren't mutually exclusive: the two paradigms can be > integrated in an intuitive, usable fashion (perhaps by noting that > (a)'s pretty much a proper subset of (b)). This is an essay question. > > d) both (a) and (b) are worth supporting, but they don't mix too well: > a global preference should give the user a choice between (a) and (b). > > e) none of the above > > I personally lean towards (c), but I'm still working on the essay > question. I think that it's fair to say that (a)'s simpler to fit > into the Cocoa document-based application model, but I think that > that model's general enough to support (b) as well. > > Gary Byers > gb at clozure.com > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From bmastenb at cs.indiana.edu Wed Feb 18 13:49:02 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Wed, 18 Feb 2004 08:49:02 -0500 Subject: [mac-lisp-ide] multiple-choice question In-Reply-To: <20040218043159.G81563@clozure.com> References: <20040218043159.G81563@clozure.com> Message-ID: <35C2E022-6219-11D8-B743-000A9599AF88@cs.indiana.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 18, 2004, at 7:04 AM, Gary Byers wrote: > Which of the following paradigms would people most like to see in a Mac > lisp IDE ? (As used below, the term "window" means what [X]Emacs would > call a "frame", i.e., a window-system window, and the term "view" means > about what [X]Emacs would call a "window": some portion of a > window-system > window used to present a buffer and associated info (modeline, etc.)). > > a) traditional Mac/Cocoa behavior, where there's typically a 1:1 > relationship between a buffer and a window and usually a single view > per window; the distinction between a buffer/view/window is often > nearly (and sometimes completely) blurred. > > b) traditional [X]Emacs behavior, where buffers can be presented in > arbitrary views in arbitrary windows. > > c) (a) and (b) aren't mutually exclusive: the two paradigms can be > integrated in an intuitive, usable fashion (perhaps by noting that > (a)'s pretty much a proper subset of (b)). This is an essay question. > > d) both (a) and (b) are worth supporting, but they don't mix too well: > a global preference should give the user a choice between (a) and (b). > > e) none of the above > > I personally lean towards (c), but I'm still working on the essay > question. I think that it's fair to say that (a)'s simpler to fit > into the Cocoa document-based application model, but I think that > that model's general enough to support (b) as well. I think my preference is c with a strong leaning in the "a" direction. So I guess I need to supply the essay: I have talked with several people on #lisp regarding what they like about emacs buffer management; for many of them, it boils down to the ability to keep many files open at once. However, I question the reasons that people want to keep fifty files open, and whether emacs buffer management solves this at all. Let's separate out the various components flying around here so we can reduce this problem to its core (if you don't know by now, I am an obsessive reductionist :-) : * Open Files, in-memory constructs containing the contents of a file with an associated location on disk where those (possibly edited) contents can be saved. * Anonymous files - just like open files, but no name associated to them. Typically manifested as "Untitled 5234235" in most programs. * Text forms: things which look like text documents but aren't really - only part of them is editable, there are buttons mixed in. See emacs's "customize" for an example. My instinct is to avoid these - why are they necessary in a real Cocoa editor? * Text presentation by the interface - windows containing primarily text that are being abused as a way of presenting some piece of information about the editor. For instance, the *Buffer List* buffer menu in Emacs. These are a consequence of emacs' text-based nature and should be avoided in favor of more visual presentations, I think. * Emacs buffers with no associated file - mostly like anonymous files, except they've got a name, and unsaved changes to them are not noted or treated as important by the interface. Bad bad bad bad bad. * Buffers - emacs's name for open files, text forms, and text presentation by the interface. Emacs has no concept of an anonymous file. Tools which try to simplify buffer management by necessity deal with all of these things. * Windows - split windows-in-windows in emacs-ese. * Frames - actual OS windows. Got all of that? My complaints about emacs buffer management mostly relate to the separation between windows / frames and buffers: opening up a new window or frame does not create a new buffer; closing a window or frame does not close the buffer. Actually closing the associated window or frame creates another problem - unless you have an open buffer list window on the screen, the file is no /nowhere/. I consider it Really Bad to have something as important to the user as an open document with unsaved changes with no on-screen indication that it exists. Even obscured windows can be quickly unhidden, but *gone*? That's, er, bad. So Emacs has this many-to-many mapping between buffers and visible, on-screen elements (I'll deal with the concept of buffer list in a bit). You can have a buffer in zero or more windows or frames, and windows or frames must point at a buffer, but they can all be pointing at the same buffer. As a user, I dislike this schizophrenia. The entire point of a graphical interface is to provide direct manipulation of the underlying components. Emacs buffer management, on the other hand, is the complete opposite of direct manipulation - the user-visible elements (windows and frames) have nothing to do with buffers! To rectify this situation I would propose that a set of rules be followed regarding buffers: * Buffers which refer to files or have important user-entered content should never be totally invisible or more than an Expos? away. * Buffers should appear in more than one window only by explicit user choice. * Multiple buffers should appear in one window only by explicit user choice. I'm not excluding the possibility of some kind of smaller representation for buffers here! Emacs's buffer list is not that direction however - I suspect that most of the people who do have fifty buffers open have some kind of grouping on those buffers and would prefer to organize them. It would be really nice to be able to organize buffers by "project", and use OmniWeb-like persistence on them (more on this in a minute). However, the rule for constructing such a buffer list is: * Any on-screen presentation of data whose ordering is chosen by the order a user has performed a set of actions and nothing else should be rearrangable. (This means you, Safari tab bar! grumble) In other words, we should try to maintain the concept of direct manipulation here even in the more extreme cases, through explicit means of managing larger number of buffers. In the most simple case, these rules reduce to option "a", but with more advanced buffer management it falls into option "c" territory. I highly recommend that anybody who wants to chip their two cents in on this go download the latest OmniWeb 5 beta and play with it for a while - - in particular, the tabs and the workspaces. Of course the tabs mechanism really isn't perfect here, but it is an example of allowing rearrangement where it ought to be allowed - and perhaps a model for multiple-buffers-in-a-window? Also play with the workspaces, and note that they can be set to be persistent on a per-workspace basis. Very useful, very cool. Brian - -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDNtVmnXQDi0istxEQLnpgCg9cGQ6w46pO7pojfSODxvGCoKCUgAoPIo Ir4qro2gjjh58rqVDMKgwcVt =Sbu3 -----END PGP SIGNATURE----- From pw at panix.com Wed Feb 18 16:19:49 2004 From: pw at panix.com (Paul Wallich) Date: Wed, 18 Feb 2004 11:19:49 -0500 Subject: [mac-lisp-ide] multiple-choice question Message-ID: <403390A5.6090307@panix.com> > Duncan Rose wrote: > On Wednesday, February 18, 2004, at 12:04 PM, Gary Byers wrote: > >> Which of the following paradigms would people most like to see in a Mac >> lisp IDE ? (As used below, the term "window" means what [X]Emacs would >> call a "frame", i.e., a window-system window, and the term "view" means >> about what [X]Emacs would call a "window": some portion of a >> window-system >> window used to present a buffer and associated info (modeline, etc.)). >> >> a) traditional Mac/Cocoa behavior, where there's typically a 1:1 >> relationship between a buffer and a window and usually a single view >> per window; the distinction between a buffer/view/window is often >> nearly (and sometimes completely) blurred. >> >> b) traditional [X]Emacs behavior, where buffers can be presented in >> arbitrary views in arbitrary windows. >> >> c) (a) and (b) aren't mutually exclusive: the two paradigms can be >> integrated in an intuitive, usable fashion (perhaps by noting that >> (a)'s pretty much a proper subset of (b)). This is an essay question. >> >> d) both (a) and (b) are worth supporting, but they don't mix too well: >> a global preference should give the user a choice between (a) and (b). >> >> e) none of the above >> >> I personally lean towards (c), but I'm still working on the essay >> question. I think that it's fair to say that (a)'s simpler to fit >> into the Cocoa document-based application model, but I think that >> that model's general enough to support (b) as well. >> > > I'd vote for (c) too. Failing that, (b) alone would be my preference. > But then, I've only recently started using Macs so maybe I'll change my > mind with more exposure to "the Apple way". Another vote for (c) here, with the note that (a) is not a subset of (b) unless you implement it that way. My concern is to have transparent access to the stuff in the windows from whatever lisp code I happen to hack together, and in my limited experience the very tempting route of using the cocoa text-handling functions to get something working quickly can make that transparency difficult. paul From mikel at evins.net Wed Feb 18 16:53:04 2004 From: mikel at evins.net (mikel evins) Date: Wed, 18 Feb 2004 08:53:04 -0800 Subject: [mac-lisp-ide] multiple-choice question In-Reply-To: <20040218043159.G81563@clozure.com> References: <20040218043159.G81563@clozure.com> Message-ID: On Feb 18, 2004, at 4:04 AM, Gary Byers wrote: > Which of the following paradigms would people most like to see in a Mac > lisp IDE ? (As used below, the term "window" means what [X]Emacs would > call a "frame", i.e., a window-system window, and the term "view" means > about what [X]Emacs would call a "window": some portion of a > window-system > window used to present a buffer and associated info (modeline, etc.)). > > a) traditional Mac/Cocoa behavior, where there's typically a 1:1 > relationship between a buffer and a window and usually a single view > per window; the distinction between a buffer/view/window is often > nearly (and sometimes completely) blurred. > > b) traditional [X]Emacs behavior, where buffers can be presented in > arbitrary views in arbitrary windows. > > c) (a) and (b) aren't mutually exclusive: the two paradigms can be > integrated in an intuitive, usable fashion (perhaps by noting that > (a)'s pretty much a proper subset of (b)). This is an essay question. > > d) both (a) and (b) are worth supporting, but they don't mix too well: > a global preference should give the user a choice between (a) and (b). > > e) none of the above > > I personally lean towards (c), but I'm still working on the essay > question. I think that it's fair to say that (a)'s simpler to fit > into the Cocoa document-based application model, but I think that > that model's general enough to support (b) as well. > (c), sort of. Primarily, the IDE's text windows should act like traditional Mac/Cocoa windows, but should add those parts of Emacs behavior that are not better handled by the normal Mac behavior, and that can be handled in a civilized fashion (about which more below). Things to cherry-pick from Emacs are being able to split a window so that you can see different parts of the same document in the window at the same time, or being able to split a window and see two different documents side-by-side. Things not to take from Emacs are text windows full of buttons and widgets for setting preferences, text windows used as menus, text windows used as UI for structured and linked documents, and so on. There are better ways with good support in Cocoa and wide currency in use. The area where Emacs really annoys me is in the use of panes in windows for 'inferior processes'. Presumably, a Lisp IDE will be concerned only about listeners and lisp processes. When I'm working in Emacs I generally keep a frame split, with an inferior lisp in the lower pane. That's not because it's the way I'd prefer it; I'd prefer to have the listener in a separate frame. However, if I do that, then inevitably some command I execute in the Lisp source buffer persuades Emacs that I would really prefer to have the inferior lisp displayed in a big honking pane in my source window. This is so annoying that I just knuckle under and let the stupid inferior lisp pane stay in the main window, thus defeating the purpose of having a separate listener frame, so I lose that frame. In general, Emacs does not respect the uses to which I put its various panes. It is forever deciding that it needs to take over some pane that I'm using for something else, in order to display something that it thinks is so important that I don't need to see the contents of my pane any more. We don't need to do stupid things like that; we have an entire taxonomy of UI widgets and customs that enable us to interact richly with the user without commandeering the user's windows. I would like to be able to split windows and see different text side-by-side. I would not like the IDE to, emacs-like, become confused about which things I want displayed in which frames. I would like to set up my working environment and have the windows obey my setup. I would not like to play musical panes. From tfb at OCF.Berkeley.EDU Thu Feb 19 09:07:45 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 19 Feb 2004 01:07:45 -0800 Subject: [mac-lisp-ide] multiple-choice question In-Reply-To: <20040218043159.G81563@clozure.com> References: <20040218043159.G81563@clozure.com> Message-ID: <16436.31969.470335.710109@famine.OCF.Berkeley.EDU> Gary Byers writes: > Which of the following paradigms would people most like to see in a Mac > lisp IDE ? I'd like to see (c), but with everything configured for (a). GNU Emacs can almost do (a), but it makes such heavy use of aweful pop-to- and switch-to- functions in such a variety of contexts, with so many dynamic variables affecting the outcome... that it's not quite possible to pull off (a). A focus on having (a) be the prefered state, with (b) as a supported alternative, would probably help in avoiding the Emacs situation. I'm not actually a big fan of (b). A useful variation is to have a 1:1 view:window relationship, with the possiblility of having a buffer in any number of view/windows. This is what Hemlock/X11 does by default. From bmastenb at cs.indiana.edu Sun Feb 29 17:26:45 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 29 Feb 2004 12:26:45 -0500 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? Message-ID: <72C3B87E-6ADC-11D8-A84C-000A9599AF88@cs.indiana.edu> Greetings fellow lispites, How is the McCLIM/Cocoa effort going? I haven't seen any news for a while and I'm dying to play with it (even if it doesn't work). Is there a CVS repository? Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From duncan at robotcat.demon.co.uk Sun Feb 29 17:58:59 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Sun, 29 Feb 2004 17:58:59 +0000 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: <72C3B87E-6ADC-11D8-A84C-000A9599AF88@cs.indiana.edu> Message-ID: It's... progressing 8-) Still some glitches in text display even (for some reason "class::object" is being rendered as "clas : object" on entry, though it does get updated correctly most of the time afterwards (it *only* affects repeat characters, the first being rendered and all others not (initially) - I'm hoping McCLIM is being too clever for my own good and this will be sorted once copy-area is implemented). Drawing lines + rectangles works, so you can do "show class superclasses" etc and get a sensible graph. Unfortunately scrolling isn't (dependent on copy-area again) so you can't see much of the graph if it's large. Mouse events work, so you can roll over the presentations and manipulate them. There's no pixmap support, and only key events involving printing characters are working at the moment. Event handling does a lot of busy waiting, and menus don't work. Other than that it's nearly usable ;-) -Duncan On Sunday, February 29, 2004, at 05:26 PM, Brian Mastenbrook wrote: > Greetings fellow lispites, > > How is the McCLIM/Cocoa effort going? I haven't seen any news for a > while and I'm dying to play with it (even if it doesn't work). Is > there a CVS repository? > > Brian > -- > Brian Mastenbrook > bmastenb at cs.indiana.edu > http://cs.indiana.edu/~bmastenb/ > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From bmastenb at cs.indiana.edu Sun Feb 29 18:15:46 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Sun, 29 Feb 2004 13:15:46 -0500 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: References: Message-ID: <4B5743FC-6AE3-11D8-A84C-000A9599AF88@cs.indiana.edu> On Feb 29, 2004, at 12:58 PM, Duncan Rose wrote: > It's... progressing 8-) Still some glitches in text display even (for > some reason "class::object" is being rendered as "clas : object" on > entry, though it does get updated correctly most of the time > afterwards (it *only* affects repeat characters, the first being > rendered and all others not (initially) - I'm hoping McCLIM is being > too clever for my own good and this will be sorted once copy-area is > implemented). > > Drawing lines + rectangles works, so you can do "show class > superclasses" etc and get a sensible graph. Unfortunately scrolling > isn't (dependent on copy-area again) so you can't see much of the > graph if it's large. Mouse events work, so you can roll over the > presentations and manipulate them. > > There's no pixmap support, and only key events involving printing > characters are working at the moment. > Event handling does a lot of busy waiting, and menus don't work. > > Other than that it's nearly usable ;-) > > -Duncan That sounds great! Is there a CVS repository available (even a non-private one)? -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From duncan at robotcat.demon.co.uk Sun Feb 29 18:24:41 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Sun, 29 Feb 2004 18:24:41 +0000 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: <4B5743FC-6AE3-11D8-A84C-000A9599AF88@cs.indiana.edu> Message-ID: <8A5218F4-6AE4-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> There is a private CVS repo at the moment. I guess there are a couple of options for making it available: 1. Find a CVS server that provides anon access for downloads 2. Post a (source) snapshot somewhere 3. Post a binary snapshot somewhere (according to Finder on my Mac, that would be 24MB give or take a few k) It's not really in a state where it makes sense to move into the main McCLIM repo (or maybe it does) and the build process is non-standard (from a McCLIM point of view) due to dealing with bundles and all that stuff so we'll have to write some docs (bah, I wanted to write a Concordia clone before doing that ;-). Maybe Mikel has some ideas in this area (he has significantly more experience of distribution than I) so hopefully he'll pitch in to the discussion. -Duncan On Sunday, February 29, 2004, at 06:15 PM, Brian Mastenbrook wrote: > On Feb 29, 2004, at 12:58 PM, Duncan Rose wrote: > >> It's... progressing 8-) Still some glitches in text display even >> (for some reason "class::object" is being rendered as "clas : object" >> on entry, though it does get updated correctly most of the time >> afterwards (it *only* affects repeat characters, the first being >> rendered and all others not (initially) - I'm hoping McCLIM is being >> too clever for my own good and this will be sorted once copy-area is >> implemented). >> >> Drawing lines + rectangles works, so you can do "show class >> superclasses" etc and get a sensible graph. Unfortunately scrolling >> isn't (dependent on copy-area again) so you can't see much of the >> graph if it's large. Mouse events work, so you can roll over the >> presentations and manipulate them. >> >> There's no pixmap support, and only key events involving printing >> characters are working at the moment. >> Event handling does a lot of busy waiting, and menus don't work. >> >> Other than that it's nearly usable ;-) >> >> -Duncan > > That sounds great! Is there a CVS repository available (even a > non-private one)? > -- > Brian Mastenbrook > bmastenb at cs.indiana.edu > http://cs.indiana.edu/~bmastenb/ > > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From joswig at lisp.de Sun Feb 29 18:34:15 2004 From: joswig at lisp.de (Rainer Joswig) Date: Sun, 29 Feb 2004 19:34:15 +0100 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: References: Message-ID: At 17:58 Uhr +0000 29.02.2004, Duncan Rose wrote: >It's... progressing 8-) Still some glitches in text display even (for some reason "class::object" is being rendered as "clas : object" on entry, though it does get updated correctly most of the time afterwards (it *only* affects repeat characters, the first being rendered and all others not (initially) - I'm hoping McCLIM is being too clever for my own good and this will be sorted once copy-area is implemented). > >Drawing lines + rectangles works, so you can do "show class superclasses" etc and get a sensible graph. Unfortunately scrolling isn't (dependent on copy-area again) so you can't see much of the graph if it's large. Mouse events work, so you can roll over the presentations and manipulate them. > >There's no pixmap support, and only key events involving printing characters are working at the moment. >Event handling does a lot of busy waiting, and menus don't work. > >Other than that it's nearly usable ;-) > >-Duncan Cool. Would it be possible to use two backends (Cocoa and X11) in one Lisp ? > >On Sunday, February 29, 2004, at 05:26 PM, Brian Mastenbrook wrote: > >>Greetings fellow lispites, >> >>How is the McCLIM/Cocoa effort going? I haven't seen any news for a while and I'm dying to play with it (even if it doesn't work). Is there a CVS repository? >> >>Brian >>-- >>Brian Mastenbrook >>bmastenb at cs.indiana.edu >>http://cs.indiana.edu/~bmastenb/ From duncan at robotcat.demon.co.uk Sun Feb 29 18:41:05 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Sun, 29 Feb 2004 18:41:05 +0000 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: Message-ID: On Sunday, February 29, 2004, at 06:34 PM, Rainer Joswig wrote: > At 17:58 Uhr +0000 29.02.2004, Duncan Rose wrote: > > Cool. > > Would it be possible to use two backends (Cocoa and X11) in one > Lisp ? > I don't see why not (well - I can see why not for the current state of the code) - this was something I was going to try once I'm a little further along. Certainly the CLIM spec indicates that this kind of thing *should* be possible (which I suspect you well know 8-). I'd also like to experiment with multi-heading too, which should also work (when the code is finished). In fact, I'm expecting to be able to run the following simultaneously: + one window in X11 through the CLX back end on the default screen + one window in Cocoa with the "standard" McCLIM L&F on the default screen + one window in Cocoa with the Cocoa L&F on the default screen + and all of the above on another screen also -Duncan >> >> On Sunday, February 29, 2004, at 05:26 PM, Brian Mastenbrook wrote: >> >>> Greetings fellow lispites, >>> >>> How is the McCLIM/Cocoa effort going? I haven't seen any news for a >>> while and I'm dying to play with it (even if it doesn't work). Is >>> there a CVS repository? >>> >>> Brian >>> -- >>> Brian Mastenbrook >>> bmastenb at cs.indiana.edu >>> http://cs.indiana.edu/~bmastenb/ > > _______________________________________________ > mac-lisp-ide site list > mac-lisp-ide at common-lisp.net > http://common-lisp.net/mailman/listinfo/mac-lisp-ide > From mikel at evins.net Sun Feb 29 23:40:21 2004 From: mikel at evins.net (mikel evins) Date: Sun, 29 Feb 2004 15:40:21 -0800 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: <8A5218F4-6AE4-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> References: <8A5218F4-6AE4-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> Message-ID: On Feb 29, 2004, at 10:24 AM, Duncan Rose wrote: > > There is a private CVS repo at the moment. I guess there are a couple > of options for making it available: > > 1. Find a CVS server that provides anon access for downloads > 2. Post a (source) snapshot somewhere > 3. Post a binary snapshot somewhere (according to Finder on my Mac, > that would be 24MB give or take a few k) > > It's not really in a state where it makes sense to move into the main > McCLIM repo (or maybe it does) and the build process is non-standard > (from a McCLIM point of view) due to dealing with bundles and all that > stuff so we'll have to write some docs (bah, I wanted to write a > Concordia clone before doing that ;-). > > Maybe Mikel has some ideas in this area (he has significantly more > experience of distribution than I) so hopefully he'll pitch in to the > discussion. > Right now, Duncan and I are working from a McCLIM source snapshot from a couple weeks back, exported, and checked into a private repository that I'm hosting. I merged in a recent copy of Bosco and then Duncan and I merged our code into that project, turning it into the current McCLIM/Cocoa project that Duncan previously decribed. I'd say that, on the one hand, the current state of the code is more annoying than anything else, but, on the other hand, thanks largely to Duncan's yeoman efforts, the McCLIM Listener on Cocoa really is a good stretch of the way toward working properly. It's not our intention to fork the code; it lives in a separate cvs repository right now largely because no one on the McCLIM list answered my queries about checking it in there. :-) I don't mind sharing the code right now, but people should be aware that it'll take work to get it running. If you want to just check it out and go then you probably shouldn't bother right now. On the other hand, I'm willing to package a snapshot if people are keen enough to do the work to get it running, and especially if it's likely to get more people hacking on the code. Of course, we really ought to check it into the main McCLIM repo soon, especially if people other than Duncan and me are going to hack on the code. Let me know if you just can't wait to get it; if there are people in that state of anticipation then I'll package it up. --me