[mac-lisp-ide] Where /is/ everyone?

[Gary Byers]

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.