February 2004 - mac-lisp-ide@common-lisp.net

[mac-lisp-ide] Whither CLIM/Cocoa?
by Brian Mastenbrook 01 Mar '04

01 Mar '04

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(a)cs.indiana.edu http://cs.indiana.edu/~bmastenb/

5 9

[mac-lisp-ide] multiple-choice question
by Gary Byers 19 Feb '04

19 Feb '04

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(a)clozure.com

6 5

re: [mac-lisp-ide] multiple-choice question
by Paul Wallich 18 Feb '04

18 Feb '04

> 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

1 0

[mac-lisp-ide] Clotho 0.2 released
by mikel evins 16 Feb '04

16 Feb '04

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

1 0

[mac-lisp-ide] status of IDE projects
by mikel evins 11 Feb '04

11 Feb '04

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

1 0

[mac-lisp-ide] Moving forward...
by Brian Mastenbrook 10 Feb '04

10 Feb '04

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(a)cs.indiana.edu http://cs.indiana.edu/~bmastenb/

6 11

[mac-lisp-ide] Extending clotho
by mikel evins 07 Feb '04

07 Feb '04

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

2 4

[mac-lisp-ide] runloops, threads, etc.
by Gary Byers 06 Feb '04

06 Feb '04

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(a)clozure.com

4 9

[mac-lisp-ide] Clotho 0.1 release available
by mikel evins 04 Feb '04

04 Feb '04

[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

3 10

[mac-lisp-ide] Re: ideas and issues
by Timothy Moore 01 Feb '04

01 Feb '04

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

2 1