From moore at bricoworks.com Mon Mar 1 09:22:47 2004 From: moore at bricoworks.com (Timothy Moore) Date: Mon, 1 Mar 2004 10:22:47 +0100 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: References: <8A5218F4-6AE4-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <01044C0B-6B62-11D8-9AD1-000A959839F8@bricoworks.com> On Mar 1, 2004, at 12:40 AM, mikel evins wrote: > 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'll get you guys write permission in the McCLIM tree. Do you have a lot of changes / hacks to the McCLIM front end? I would be a bit hesitant to check those without some thought. Tim From duncan at robotcat.demon.co.uk Mon Mar 1 09:26:37 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Mon, 1 Mar 2004 09:26:37 +0000 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: <01044C0B-6B62-11D8-9AD1-000A959839F8@bricoworks.com> Message-ID: <8A054A87-6B62-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> Just adding ":cocoa" to the port search path. But then, that's not a good name for the back end on several levels; the current back end is dependent on OpenMCL FFI bindings and it seems likely others may want to write a cocoa back end (say for SBCL) so we should probably refer to it differently (openmcl-cocoa? ccl?). But that's the only change in the front end. -Duncan On Monday, March 1, 2004, at 09:22 AM, Timothy Moore wrote: > On Mar 1, 2004, at 12:40 AM, mikel evins wrote: >> 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'll get you guys write permission in the McCLIM tree. Do you have a > lot of changes / hacks to the McCLIM front end? I would be a bit > hesitant to check those without some thought. > > Tim > > > _______________________________________________ > 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 Mon Mar 1 10:35:39 2004 From: mikel at evins.net (mikel evins) Date: Mon, 1 Mar 2004 02:35:39 -0800 Subject: [mac-lisp-ide] Whither CLIM/Cocoa? In-Reply-To: <8A054A87-6B62-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> References: <8A054A87-6B62-11D8-AC3B-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <2F22763A-6B6C-11D8-B232-000A958E5B06@evins.net> On Mar 1, 2004, at 1:26 AM, Duncan Rose wrote: > > Just adding ":cocoa" to the port search path. But then, that's not a > good name for the back end on several levels; the current back end is > dependent on OpenMCL FFI bindings and it seems likely others may want > to write a cocoa back end (say for SBCL) so we should probably refer > to it differently (openmcl-cocoa? ccl?). > > But that's the only change in the front end. > The only significant change, that is. The project also adds a new system-definition file, in order to provide for the idiosyncratic cocoa build process without hacking up the normal system.lisp. --me From bmastenb at cs.indiana.edu Tue Mar 23 16:16:19 2004 From: bmastenb at cs.indiana.edu (Brian Mastenbrook) Date: Tue, 23 Mar 2004 11:16:19 -0500 Subject: [mac-lisp-ide] Where /is/ everyone? Message-ID: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> Greetings all, This list has been dead for a while, so I'm wondering where everyone is? As I recall people were working on a few cool things: Clotho, McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how people have been doing on these! Brian -- Brian Mastenbrook bmastenb at cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From mikel at evins.net Tue Mar 23 17:04:37 2004 From: mikel at evins.net (mikel evins) Date: Tue, 23 Mar 2004 09:04:37 -0800 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> Message-ID: <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> On Mar 23, 2004, at 8:16 AM, Brian Mastenbrook wrote: > Greetings all, > > This list has been dead for a while, so I'm wondering where everyone > is? As I recall people were working on a few cool things: Clotho, > McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how > people have been doing on these! > Paul Lathrop got cvs access to Clotho and has added several small enhancements. I got Hamilton Link's express permission to include his inspector in Clotho, and to adapt it however we see fit. I wrote a syntax-coloring algorithm which seems acceptably fast, but needs some further debugging. I've had a little discussion with Gary and Randall about possible improvements to the Cocoa bridge, the goal being to solve the present problem that applications built with the bridge are tied to specific OS versions (for example, the recent release of OS X 10.3.3 required a recompile of Bosco-based apps; this seems a rather large inconvenience for anyone who wants to deliver an application based on the bridge). I spent a little time experimenting with various approaches to hooking OSX's event and threading frameworks at a lower level than Cocoa; next I plan to experiment with building SLIME's swank server into Bosco. The goal is to make it easier to control and augment Bosco-based apps (including Clotho and McCLIM.app) from an Emacs session. Duncan Rose and I merged McCLIM code and he made some further improvements to rendering (and fixed a bug I introduced in event-handling). I'm told I have commit privileges on the repository, but haven't yet checked in our code. I haven't advanced either of these projects in a couple of weeks because I've spent too much time on other things (notably, on writing code for the people who pay my salary). That will change soon, but I feel like I owe some time to the Hansa project, so I'm working on its game server right now. When I get to a stopping place on that, I need to spend a little time on Kenny Tilton's Cello, to see how hard it is to get it to build with OpenMCL. Then I mean to return to McCLIM and Clotho. I have in mind to debug and merge in Clotho's syntax-coloring code and then move on to a list of things that I think need to be done. I encourage any interested readers of this list to pitch in. Here's the list I sent to Paul Lathrop a little while back, with a few annotations. Paul's interested inn working on at least some of these. BUGS ---- - the application occasionally hangs or crashes; the cause of these anomalies needs investigation [this one seems to be fixed in the latest cvs version] - the build breaks at SAVE-APPLICATION about half the time, dropping into the Lisp kernel debugger. Continuing results in a good build, but it's very annoying. The likely cause is known, but we haven't figured out a better workaround than continuing from the kernel debugger. A better fix would be a great contribution. [this is a little better in recent cvs versions of OpenMCL] ADD-ONS ------- - a recent addition is Hamilton Link's Cocoa inspector. It has a fine windowing UI, but there is no UI to invoke it. Invention and construction of UI to inspect arbitrary text would be nice. So would extensions to (and of course bug-hunting in) the inspector itself. - Gary Byers has made a partial port of Portable Hemlock to Cocoa. Completing that port and integrating it with Clotho would be a great improvement. - I'd like to use Albert or something similar to generate documentation from the project. Albert does not presently work with the Clotho codebase. It would be great if someone could either teach Albert how to read Clotho's code or, in the worst case, write another tool that could do the job. - integrating any level of in-app support for Apple's OpenGL implementation would be nice. - trolling for and integrating other third-party extensions would be very useful. CODE BEAUTIFICATION ------------------- - the code for the listener and inspector are minimally changed from the Cocoa example code. Someone needs to read through it, look for opportunities to refactor, improve package organization, look for dead code, document undocumented code, check for unexported symbols that need to be exported and vice versa, move generally useful utilities into more generally-accessible places in the build, and just generally make the code prettier and better factored wherever that can be done. TESTS ----- - It would be awfully nice to get a unit-testing framework set up and build some suitable unit and integration tests for the various parts of Clotho. Clotho's pretty simple right now, but it won't be long before I'm going to want to see test results before deciding to release new versions. [I've used the xptest package in other projects; I think it would be fine for use in Clotho] NEW FEATURES ------------ There are a zillion that I think would be a good idea, but here are the short-term highlights, things I'd like to see getting implemented soon: - a nibfile reader/writer I'd like some Lisp code that can read and write nibfiles, to form the basis of Lisp-based tools to help build UIs with Clotho. [A few weeks back I hacked up a very simple reader; it was pretty easy. I think this would be a good starter project for someone with at least a little familiarity with either Lisp or Cocoa or both.] - a template-based Application bundle builder I want some tools that can construct a properly formed application bundle and put the Info.plist and other resource files in the right place, and fill in the contents from templates. The idea is that I want you to be able to pick "New Project" from a menu and have Clotho build the application bundle with the right names and version numbers and copyright info and all the rest, gathered from a dialog with the user. [This one should be pretty straightforward grunt work.] - version-control client code I'd like Clotho to be able to work with some suitable version control system (probably CVS, but I'd be open to discussing something like Arch) in a nice, integrated fashion [I have recent sources for metacvs and have promised to see if I can get OpenMCL to build it. If I can, then it might be interesting to integrate it with Clotho.] - syntax coloring I've got some syntax-coloring code partly built that is pretty fast (though as-yet unoptimized), but really doing it well is tricky. I wouldn't mind help with it if someone is very clever about it and willing to fuss will all the hairy edge cases, and get it integrated with the UI. [This is mostly done; there are two bugs to fix, one in handling strings in certain funny cases (e.g. when some form contains a literal #\"), and one in the interaction between the TextView and LayoutManager when applying the styles.] - documentation support Besides generating documentation, I'd like to get some support for nicely-integrated documentation readers, so that people can search the Common Lisp Hyperspec from within Clotho, with a keystroke, and so that you can quickly and easily search Clotho-specific and project-specific documentation. - browsing tools Class browsers, cross-referencers, change-managers; I'd like to see all these get built in. - debugger Decent integration between the GUI and the OpenMCL debugger would be a big win, and fairly tricky to implement. - Cocoa preferences support Clotho needs to write several user preferences to disk and read them on launch. Obvious first things to support are font and syntax-color preferences, init file name, and starting image. From gb at clozure.com Tue Mar 23 17:55:39 2004 From: gb at clozure.com (Gary Byers) Date: Tue, 23 Mar 2004 10:55:39 -0700 (MST) Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> Message-ID: <20040323100837.T4205@clozure.com> On Tue, 23 Mar 2004, mikel evins wrote: [...] > > I wrote a syntax-coloring algorithm which seems acceptably fast, but > needs some further debugging. I've had a little discussion with Gary > and Randall about possible improvements to the Cocoa bridge, the goal > being to solve the present problem that applications built with the > bridge are tied to specific OS versions (for example, the recent > release of OS X 10.3.3 required a recompile of Bosco-based apps; this > seems a rather large inconvenience for anyone who wants to deliver an > application based on the bridge). We discussed the idea of basing (most of) CLOS's notion of the ObjC world on information gathered from the interface files (instead of introspecting on a particular version of the Cocoa classes and finding it hard to change models on the fly when a new version comes along.) The first step in that plan would be to update the interface translator (to both use a much more recent version of the GCC frontend and to retain information about ObjC classes and methods.) That's a desirable step for many reasons, but I don't know how soon I'll be able to work on it; if anyone's interested in a Rainy Day Fun Project, I'd be glad to supervise ... [...] > > Here's the list I sent to Paul Lathrop a little while back, with a few > annotations. Paul's interested inn working on at least some of these. > > BUGS > ---- > > - the application occasionally hangs or crashes; the cause of these > anomalies needs investigation > > [this one seems to be fixed in the latest cvs version] There are a lot of problems that're exposed by the fact that the final step in deallocating an (real, not CF-based) NSObject involves calling a lisp callback (that's necessary so that lisp code can remove any lisp slots associated with the object; it can't really do that earlier.) This deallocation code can get called at surprising times (e.g., after a thread has exited: it may need to clean up thread-local storage); there are a number of complications created by these zombie threads, but the worst of those complications are caused by the fact that the function that set up special bindings for "foreign" threads hadn't been updated after changes in OpenMCL's special-binding code some months ago. Sometimes, that caused foreign threads to believe that they were the initial thread and that they should therefore behave a little differently during shutdown ... There's a fix to this function in CVS; it seems to cause the worst of these problems to go away. > > - the build breaks at SAVE-APPLICATION about half the time, dropping > into the Lisp kernel debugger. Continuing results in a good build, but > it's very annoying. The likely cause is known, but we haven't figured > out a better workaround than continuing from the kernel debugger. A > better fix would be a great contribution. > > [this is a little better in recent cvs versions of OpenMCL] I think that there was a DBG trap that was caused by an ill-advised timeout (a thread that wanted to QUIT interrupted the initial thread and waited a second or so for a response.) Delays in responding are sometimes normal, and the problems with QUIT seem mostly to be related to the zombie-foreign-threads issue mentioned above. I -think- that the DBG trap was removed in 0.14.1p1, but I may be blurring versions ... > > ADD-ONS > ------- > > - a recent addition is Hamilton Link's Cocoa inspector. It has a fine > windowing UI, but there is no UI to invoke it. Invention and > construction of UI to inspect arbitrary text would be nice. So would > extensions to (and of course bug-hunting in) the inspector itself. > Aside from the fact that there isn't a good way of invoking it, the biggest problems I see with Hamilton's inspector stem from problems with NSBrowser (especially in Jaguar): it's hard to see some things because of the browser's fixed-width columns. I like the idea of using an NSBrowser-like approach, and think that many of the problems can be overcome if you flip the NSBrowser around 90 degrees (replacing it with an NSScrollView to which a series of NSTableViews are appended.) These are famous last words, but that sounds embarrassingly simple. > - Gary Byers has made a partial port of Portable Hemlock to Cocoa. > Completing that port and integrating it with Clotho would be a great > improvement. I've been working on this for so long that I don't remember working on anything else ... It's coming along, but it's not all there yet. I'd started by having everything happen in the main event thread; that seemed to work fairly well, but it got very hard to implement things like incremental search without maintaining a lot of extra state information. A thread seemed like a good way of maintaining that state, but since switching to that architecture I've had more problems keeping the display (which happens in the main thread) in synch with the buffer (modified in the frame-specific Hemlock thread). I think that this is ultimately doable and it keeps getting better, but it's still buggy enough to be not-quite-usable. > > > - debugger > Decent integration between the GUI and the OpenMCL debugger would be a > big win, and fairly tricky to implement. I've done a backtrace window (as an NSOutlineView) that (again, "mostly") works. The window itself is fairly simple; the problems I've had (and the remaining bugs) are mostly caused by the difficulty of parsing one thread's stack from another thread. > > - Cocoa preferences support > Clotho needs to write several user preferences to disk and read them > on launch. Obvious first things to support are font and syntax-color > preferences, init file name, and starting image. I've got a scheme for tying lisp variables to keys in the NSUserDefaults database, so you can say things like: (def-cocoa-default *tab-width* :int 8 "Width of a tab stop, in characters") I suppose that if you edited the XML file manually lisp code would recognize the change and set *TAB-WIDTH* appropriately; this is really crying out for an NSPreferencesPane to present the information usably (and perhaps some more parameters to DEF-COCOA-DEFAULT to help such a preference pane group and present those options.) Writing a preference pane doesn't seem hard; writing an extensible preference framework seems more interesting and useful. From plathrop at nmu.edu Tue Mar 23 18:46:01 2004 From: plathrop at nmu.edu (Paul Lathrop) Date: Tue, 23 Mar 2004 13:46:01 -0500 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> Message-ID: <54CC2C58-7CFA-11D8-A727-000A9573C480@nmu.edu> On Mar 23, 2004, at 11:16 AM, Brian Mastenbrook wrote: > Greetings all, > > This list has been dead for a while, so I'm wondering where everyone > is? As I recall people were working on a few cool things: Clotho, > McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how > people have been doing on these! As Mikel Evins mentioned, I have been doing some small-time work on Clotho. Real life intervened for a while, which has kept me from getting any serious work done recently, but my calendar is opening up a bit, so expect more soon. --Paul Lathrop From plathrop at nmu.edu Tue Mar 23 18:54:29 2004 From: plathrop at nmu.edu (Paul Lathrop) Date: Tue, 23 Mar 2004 13:54:29 -0500 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> Message-ID: <83D18426-7CFB-11D8-A727-000A9573C480@nmu.edu> On Mar 23, 2004, at 12:04 PM, mikel evins wrote: > - the code for the listener and inspector are minimally changed from > the Cocoa example code. Someone needs to read through it, look for > opportunities to refactor, improve package organization, look for dead > code, document undocumented code, check for unexported symbols that > need to be exported and vice versa, move generally useful utilities > into more generally-accessible places in the build, and just generally > make the code prettier and better factored wherever that can be done. This is the project I was going to start on next. I was going to focus on the listener for the time being, but both are on the agenda. > - a nibfile reader/writer > I'd like some Lisp code that can read and write nibfiles, to form the > basis of Lisp-based tools to help build UIs with Clotho. > > [A few weeks back I hacked up a very simple reader; it was pretty > easy. I think this would be a good starter project for someone with at > least a little familiarity with either Lisp or Cocoa or both.] This is the new feature I am most interested in right now - I think it would be a great help in sharpening both my Lisp skills and my Cocoa skills. Any chance you could send me the code you hacked together just so I can get some ideas on a starting point? --Paul Lathrop From mikel at evins.net Tue Mar 23 18:54:45 2004 From: mikel at evins.net (mikel evins) Date: Tue, 23 Mar 2004 10:54:45 -0800 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <54CC2C58-7CFA-11D8-A727-000A9573C480@nmu.edu> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> <54CC2C58-7CFA-11D8-A727-000A9573C480@nmu.edu> Message-ID: <8D004216-7CFB-11D8-98D5-000A958E5B06@evins.net> On Mar 23, 2004, at 10:46 AM, Paul Lathrop wrote: > On Mar 23, 2004, at 11:16 AM, Brian Mastenbrook wrote: > >> Greetings all, >> >> This list has been dead for a while, so I'm wondering where everyone >> is? As I recall people were working on a few cool things: Clotho, >> McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how >> people have been doing on these! > > As Mikel Evins mentioned, I have been doing some small-time work on > Clotho. Real life intervened for a while, which has kept me from > getting any serious work done recently, but my calendar is opening up > a bit, so expect more soon. > See? Other people besides me (and of course Gary and Randall) can make productive contributions to Clotho. Go ahead; add some code. --me ---------- "[W]e were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" [Guy Steele, of Sun Microsystems Labs, about designing Java] From mikel at evins.net Tue Mar 23 18:57:31 2004 From: mikel at evins.net (mikel evins) Date: Tue, 23 Mar 2004 10:57:31 -0800 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <83D18426-7CFB-11D8-A727-000A9573C480@nmu.edu> References: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> <2AA89666-7CEC-11D8-98D5-000A958E5B06@evins.net> <83D18426-7CFB-11D8-A727-000A9573C480@nmu.edu> Message-ID: On Mar 23, 2004, at 10:54 AM, Paul Lathrop wrote: > On Mar 23, 2004, at 12:04 PM, mikel evins wrote: >> - the code for the listener and inspector are minimally changed from >> the Cocoa example code. Someone needs to read through it, look for >> opportunities to refactor, improve package organization, look for >> dead code, document undocumented code, check for unexported symbols >> that need to be exported and vice versa, move generally useful >> utilities into more generally-accessible places in the build, and >> just generally make the code prettier and better factored wherever >> that can be done. > > This is the project I was going to start on next. I was going to focus > on the listener for the time being, but both are on the agenda. It badly needs to be done, but go slowly; it's fragile code and it's a bit hard to find and fix the sources of breakage when you break it. > >> - a nibfile reader/writer >> I'd like some Lisp code that can read and write nibfiles, to form >> the basis of Lisp-based tools to help build UIs with Clotho. >> >> [A few weeks back I hacked up a very simple reader; it was pretty >> easy. I think this would be a good starter project for someone with >> at least a little familiarity with either Lisp or Cocoa or both.] > > This is the new feature I am most interested in right now - I think it > would be a great help in sharpening both my Lisp skills and my Cocoa > skills. Any chance you could send me the code you hacked together just > so I can get some ideas on a starting point? > It was just in-the-listener kinds of stuff to see if I could do it easily, but I'll try to send you something tonight. --me From duncan at robotcat.demon.co.uk Tue Mar 23 20:39:39 2004 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Tue, 23 Mar 2004 20:39:39 +0000 Subject: [mac-lisp-ide] Where /is/ everyone? In-Reply-To: <6B0579F6-7CE5-11D8-92F1-000A9599AF88@cs.indiana.edu> Message-ID: <34E9B5DC-7D0A-11D8-97D7-000A9577B8A2@robotcat.demon.co.uk> I'm still here too; it's been a little slow with the McCLIM Cocoa back end over the last couple of weeks, but hopefully things are moving again now. Currently the McCLIM Listener isn't really usable - this is my priority at the moment. Whilst not going into the same amount of detail as Mikel, here's what *needs* to be done, and what I'd like to do over the coming weeks:- + "Core" functionality needed to get the Listener working * scrolling (I'm working on this now) [1] * pixmap support * menus * flipping ink * keyboard events (currently only ASCII input works) + Other stuff to complete the back end * a couple of primitive drawing methods aren't implemented yet (ellipse + circle) * bringing it up to date with the latest McCLIM sources (Andy Heffner added scroll wheel support into McCLIM which should be easy to add into the Cocoa back end) * LOTS of tidying up (I'm still learning, and I think it shows!) * Native pane implementation - replace the standard McCLIM L&F with pretty Aqua as default in the Cocoa back end Once this is done I think it will be ready to checkin to the McCLIM repository. Depending on how long all this takes, I might push for committing it after the Listener runs but before everything else is done. Other than this, I want to work on finishing off McCLIM (it's not 100% complete as per the spec), including writing a comprehensive test suite. I'd like to see an CLIM editor, inspector, stepper and debugger (I don't think I'm alone in this) and also a documentation authoring / viewing tool would be nice. I've found some things in CLIM to be difficult to understand and whilst the code is always going to be the best documentation, some written documentation would be nice too. As far as the editor goes, there appear to be a couple of options. The first is just to use Emacs, but I'd like something that is CL (and integrated better into the overall environment - which also needs implementing[2]). Other alternatives include Hemlock, or waiting to see what others create and stealing that ;-) Another alternative that sounds interesting (to me) but which might not be practical would be to port the Dylan Deuce editor into CL + CLIM (there are many similarities between DUIM + CLIM, but also many differences. Whether it's possible to work around the differences or not remains to be seen). Since I'm working in OpenMCL, using the OpenMCL inspector as a base for a McCLIM inspector has some appeal. Obviously the UI elements would need reworking (this may well hold true for all these tools of course; if an MVC approach is followed to their development there's no reason the same basic application code can't be reused with different UIs atop). As to a stepper and debugger, I don't really have any ideas how to even start on these kinds of tools (and I suspect OpenMCL would need some hacking to permit highly-functional implementations too - but until I have time to sit down and trawl through its internals (that would be sometime in 2030 I think...) I'm just making wild guesses). -Duncan [1] In case you're wondering, the "scrolling problem of the day" is that McCLIM seems to perform scrolling by altering the scrollee's transformation and region. The functions that do this in CLX (clx:drawable-x etc.) appear to cause the server redraw the mirror automatically - not so in Cocoa, and using 'dispatch-repaint' in CLIM leads to infinite looping. Now I'm wishing I'd done the drawing in the Cocoa back end differently so I could just send a Cocoa "setNeedsDisplay". I guess more kludges are needed ;-) [2] It's possible (likely?) this will be "in" McCLIM already by the time I get around to it... On Tuesday, March 23, 2004, at 04:16 PM, Brian Mastenbrook wrote: > Greetings all, > > This list has been dead for a while, so I'm wondering where everyone > is? As I recall people were working on a few cool things: Clotho, > McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how > people have been doing on these! > > 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 >