[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
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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.
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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.
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
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
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@common-lisp.net and we can discuss adding you to the project.
--me
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@common-lisp.net if you have questions, or if you want to be added to the project.
--me
-
Brian Mastenbrook -
mikel evins -
Randall Beer