[Openmcl-devel] The AltConsole

Wed Apr 24 07:19:03 PDT 2013

The AltConsole is definitely useful for debugging in spite of some limitations. However, for OS X >= 10.7 it would be great if the AltConsole.app would just start up and open the actual console window instead of hanging CCL. Even for experienced developers it can be quite alarming to get the beach ball just because, perhaps, they left a print statement in some code. Would it be possible to have the AltConsole.app work around this and bring up the window without human intervention?

Alex

On Apr 24, 2013, at 5:02 AM, Gary Byers wrote:

> 
> 
> On Wed, 24 Apr 2013, Ron Garret wrote:
> 
>> 
>> On Apr 24, 2013, at 12:21 AM, peter wrote:
>> 
>>> At 10:40 PM -0700 13/4/23, Ron Garret wrote:
>>>> Why does CCL use the AltConsole instead of the OSX system logging facilities?
>>>> 
>>>> Just wondering.  I'm doing some development where I have to stop and restart CCL often and I end up with dozens of altconsoles in my dock.
>>> 
>>> It'd be rather useful if there was a flag that allowed background output to be sent to the Altconsole or the OSX console log. But I have a sense that this traffic redirection might need to be handled explicitly in our code.
>>> 
>>> But presumably we've the altconsole so some human interaction is possible with the CCL state which would not be possible in the console.
>> 
>> Yes, the AltConsole is very useful when a thread that isn't attached to a listener throws an exception, but routine logging (i.e. output to *terminal-io*) from such threads could still go to syslog.  But I guess the answer to my question is: the AltConsole has to be there anyway, so we might as well use it for logging.
>> 
> 
> [I think that the following is generally correct, but it's from memory.  If
> there are any nits to be picked, I'd be surprised if they're significant in
> any way.)
> 
> When running a Cocoa application, file descriptor 0 is associated with /dev/null
> (a pseudodevice that always returns EOF on input) and one or both of fds 1 and
> 2 are associated with the system logging service.  (I don't remember the exact
> details, and those details have changed from OSX release to release.)
> 
> When running the Cocoa IDE (or something derived from it), some code that runs
> at startup looks in the application bundle's resources for an "AltConsole.app"
> sub-bundle; if that sub-bundle and its executable are found, a bidirectional
> pipe is created and the executable is run with its fds 0 and 1 attached to
> one side of the pipe and the main applications fds 1 and 0 are redirected to
> the other the other end of that pipe.  (The altconsole executable is supposed
> to just listen for input on its fd 0 - output from the main application's fd 1 -
> and only start a simple Cocoa UI when input arrives; since Lion, "starting a
> simple UI" gets as far a having its icon appear in the dock, and the user has
> to notice that and click on the icon in order to see the altconsole window in
> all its ... um ... glory.)
> 
> If the "AltConsole.app" sub-bundle isn't present, none of this I/O
> redirection happens.  (The intent was that the AltConsole window could
> be useful when debugging but would be removed from a shipping application;
> AFAIK, some people with shipping applications prefer to leave it in.)
> 
> If the I/O redirection happens, it happens:
> - in the initial thread, before any other threads are created and before the
>   initial thread starts running the event loop
> - after the standard streams (the values of *TERMINAL-IO* and friends) have
>   been initialized to streams associated with fds 0 and 1
> - in a way that affects how errors that occur in the event thread are handled.
>   (If the AltConsole is available, the event thread will enter a break loop
>   that effectively interacts with it, however crudely; if not, IIRC some
>   error information (possibly including a backtrace) is written and the thread
>   crosses its fingers and tries to reset itself to the point where the next
>   event would be processed.)
> 
> It's a little awkward, but it's generally possible to do some debugging in
> a break loop in the AltConsole window.  You don't have much in the way of
> lisp-aware editing support and you don't have a GUI (the GUI is sitting in
> a break loop ...), but you can poke around a bit and may be able to understand
> the problem more easily than if all you could do is look at printed backtraces
> in a logfile somewhere.  It's not an ideal debugging environment (but neither
> is staring at logfiles), and I think the answer to your basic question (why
> is AltConsole used ?) is that it's better than nothing, and many people find
> staring at logfiles to be not much better than nothing.
> 
>> Now that I think of it, I can probably fix my current annoyance by simply rebinding Hunchentoot's *terminal-io*.
>> 
>> That reminds me of another thing that's been puzzling me for a long time: occasionally I'll get a message in the AltConsole that looks something like this:
>> 
>> "Thread something-or-other needs to tell you something terribly important, but it can't for some obscure reason.  Type (:y 23) to yield control to this thread."
>> 
>> (Obviously I'm paraphrasing -- I haven't actually seen this in quite a while.)
> 
> If two threads try to write to the same stream, that's generally possible because
> a lock guards the internal state of the stream.  Even if that internal state is
> kept consistent, the output is generally going to be jumbled and possibly unreadable,
> and you'd need to use some higher-level locking protocol to decide which thread
> writes to the stream when.
> 
> If two threads try to read from the same stream at the same time, it's generally
> necessary to use a higher-level protocol in order to have any idea of which thread
> reads what (parts of the) input, and that's more often more than a cosmetic issue.
> The higher-level protocol that CCL uses affect some ways of requesting input from
> a shared input stream (it affects things like break loops and Y-OR-N-P; it -doesn't-
> affect things like READ-LINE or READ-CHAR) and involves the concept of some thread
> being designated as the (current) "owner" of that shared resource and a means of
> (at least temporarily) transferring or yielding ownership to some other thread.
> If you run CCL in the shell, the initial listener thread "owns" the input side
> of *TERMINAL-IO*
> 
> If you run CCL in the shell and do:
> 
> ? (process-run-function "example" (lambda () (sleep 1) (break)))
> 
> you'll get the same sort of message and the same sort of advice to type a
> command which will transfer/yield ownership of the stream to the specified
> thread.  That advice will make sense if the current owner (the listener
> thread) is back at a REPL prompt and the :Y command will have the intended
> effect there.
> 
> If you did:
> 
> (progn
>  (process-run-function "example" (lambda () (sleep 1) (break)))
>  (sleep 60))
> 
> then the message and advice would come at a time when the advice is harder to act
> on; you'd have to interrupt the SLEEP call in the listener or wait for it to
> finish before you could act on the advice.
> 
> In the GUI environment, the same "ownership" protocol is used to control access
> to the input side of the (global, static) *TERMINAL-IO* and the event thread
> is noted as the owner, but (as you've noted) the advice makes less sense: the
> owner of the shared resource is usually off processing events instead of reading
> REPL commands from that stream.  There are likely a few solutions to this
> problem. but everything that I've considered can be as confusing as the problem
> itself.
> 
> A workaround is to use (in the Cocoa environment) BACKGROUND-PROCESS-RUN-FUNCTION
> instead of PROCESS-RUN-FUNCTION.  (I'm fairly sure that the former symbol is
> exported and FIND-SYMBOL or APROPOS or ... would tell you what package it's
> exported from.)  A thread created with BACKGROUND-PROCESS-RUN-FUNCTION will
> behave much like a listener thread in the Cocoa GUI: its standard stream variables
> will be bound to a stream/streams that use a Listener window and its underlying
> Hemlock buffer for I/O, but in the case of a "background" thread the window
> will only be created and made visible if the thread does I/O to that stream.
> 
> 
>> 
>> Invariably in such situations, typing (:y 23) has no discernible effect.  What am I doing wrong?  I've tried lots of variations on the theme, typing it with and without parens, typing it into a listener, typing it in to the AltConsole.  It's never been a serious problem, which is why I've never bothered to ask about it before, but since I've got the AC on the brain and it's late I figured I'd ask.
>> 
>> rg
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130424/d51aa506/attachment.htm>