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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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
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
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
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
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@common-lisp.net http://common-lisp.net/mailman/listinfo/mac-lisp-ide
.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.
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
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 http://openmcl.clozure.com/Doc/cocoa.html.
Hopefully, the new release will be out later today.
Gary Byers gb@clozure.com
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 http://openmcl.clozure.com/Doc/cocoa.html.
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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 http://openmcl.clozure.com/Doc/cocoa.html.
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@clozure.com
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.
-
Brian Mastenbrook -
Duncan Rose -
Gary Byers -
mikel evins -
Thomas F. Burdick -
Timothy Moore