mac-lisp-ide

mac-lisp-ide@common-lisp.net

19 discussions

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

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

01 Feb '04

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 >> >

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mac-lisp-ide