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.