[Openmcl-devel] The AltConsole

Ron Garret ron at flownet.com
Wed Apr 24 01:11:32 PDT 2013


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.

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

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




More information about the Openmcl-devel mailing list