[mac-lisp-ide] Where /is/ everyone?
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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.
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.
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
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
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
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]
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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
_______________________________________________ mac-lisp-ide site list mac-lisp-ide@common-lisp.net http://common-lisp.net/mailman/listinfo/mac-lisp-ide
participants (5)
-
Brian Mastenbrook -
Duncan Rose -
Gary Byers -
mikel evins -
Paul Lathrop