[Openmcl-devel] Clozure CL 1.2 released - type of cocoa-application ?

[Gary Byers]

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.)