Re: Clozure CL 1.2 released - type of cocoa-application ?
On Sun, 21 Sep 2008, james anderson wrote:
>
> On 2008-09-21, at 15:17 , Gail Zacharias wrote:
>
>> There is some discussion of this in http://trac.clozure.com/openmcl/
>> ticket/208 and http://trac.clozure.com/openmcl/ticket/87. It looks
>> like the problem is not implementation as much as thinking it
>> through and deciding what's right.
>
> i don't know, but - reading those comments, maybe one is expecting
> too much from it.
> just reading the code, the notes, that output would go to the
> console, seem right-minded.
> if one puts a handled call to startup-ccl (or its equivalent) just
> before starting the event loop, that seems as late as possible before
> anything visible has happened. if something goes wrong, output
> appears on the console (somehow it's sometimes the ccl and sometimes
> the system console) and in any case the first listener appears. this
> is certainly enough to be useful.
>
What streams are used for I/O (for error message, break loops, etc.)
has more to do with what thread is doing the I/O (and what that
thread's bindings of *ERROR-OUTPUT*, *DEBUG-IO*, etc. are) than
with what other threads (and windows, and streams ...) exist when
the I/O happens.
To review some of the discussion in ticket 87 and elsewhere (as I
understand and remember it):
- it's clearly desirable for the IDE to load ~/ccl-init, and it
should do this in more-or-less then same way as it's done in
the TTY environment (in the initial listener thread, just before
that thread enters its REPL.) Any interactive I/O that occurs
while loading the init file should happen in the listener thread's
standard streams (which are connected to the listener window/its
buffer/whatever.) Whatever implements this would indeed do
something like what CCL::STARTUP-CCL does in the TTY environment;
in the IDE, the initial listener is created in response to
something like a "create new untitled document" event, so the
handler for that event could presumably say "if this is the
first time that this is being called in this session, persuade
the listener that's being created to load the init file." That
might be a little tricky, but it's not a hard problem.
- it's also desirable for the IDE to load some sort of IDE-specific
init file (which might contain editor customizations/key-bindings
and other IDE-specific stuff.) In a lot of cases, it might be
best if this other file ("~/ccl-ide-init" ?) loaded around the
time that the IDE initialized itself. (That might mean "just
before" or "just after"; I'm not sure.) At that point and on
the initial thread, there isn't really a great way to interact
with the user if things go wrong while loading that file.
It's probably not unreasonable to not even try to interact with
the user in that case (e.g., to just ignore errors and capture
any unexpected output that occurred while loading the IDE init
file) and to report problems later (pop up a dialog, or have the
initial listener tell you about missing/extra parens or undefined
functions in the IDE init file, whatever.) You might have more
options for some sort of interactive debugging if the IDE init
file loaded later (e.g., after the event loop was up and running),
and you might have more opportunities for customization if it
loaded later, so this is related to what kinds of customization
are possible via the mechanism, and there are tradeoffs there
and elsewhere.
Coming up with reasonable solutions to these issues isn't an
open-ended research project (knock wood), but it's probably not
a case of someone forgetting to add a few lines of code in the
right places. (In the case of loading ~/ccl-init in the initial
IDE listener, it's probably no more than a few dozen lines of
code; in the case of the IDE-specific init file, it probably
involves some head-scratching as well as some code.)
RSS Feed