<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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?</div><div><br></div><div>Alex</div><div><br></div><div><br></div><br><div><div>On Apr 24, 2013, at 5:02 AM, Gary Byers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>On Wed, 24 Apr 2013, Ron Garret wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Apr 24, 2013, at 12:21 AM, peter wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">At 10:40 PM -0700 13/4/23, Ron Garret wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Why does CCL use the AltConsole instead of the OSX system logging facilities?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But presumably we've the altconsole so some human interaction is possible with the CCL state which would not be possible in the console.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><br>[I think that the following is generally correct, but it's from memory. If<br>there are any nits to be picked, I'd be surprised if they're significant in<br>any way.)<br><br>When running a Cocoa application, file descriptor 0 is associated with /dev/null<br>(a pseudodevice that always returns EOF on input) and one or both of fds 1 and<br>2 are associated with the system logging service. (I don't remember the exact<br>details, and those details have changed from OSX release to release.)<br><br>When running the Cocoa IDE (or something derived from it), some code that runs<br>at startup looks in the application bundle's resources for an "AltConsole.app"<br>sub-bundle; if that sub-bundle and its executable are found, a bidirectional<br>pipe is created and the executable is run with its fds 0 and 1 attached to<br>one side of the pipe and the main applications fds 1 and 0 are redirected to<br>the other the other end of that pipe. (The altconsole executable is supposed<br>to just listen for input on its fd 0 - output from the main application's fd 1 -<br>and only start a simple Cocoa UI when input arrives; since Lion, "starting a<br>simple UI" gets as far a having its icon appear in the dock, and the user has<br>to notice that and click on the icon in order to see the altconsole window in<br>all its ... um ... glory.)<br><br>If the "AltConsole.app" sub-bundle isn't present, none of this I/O<br>redirection happens. (The intent was that the AltConsole window could<br>be useful when debugging but would be removed from a shipping application;<br>AFAIK, some people with shipping applications prefer to leave it in.)<br><br>If the I/O redirection happens, it happens:<br> - in the initial thread, before any other threads are created and before the<br> initial thread starts running the event loop<br> - after the standard streams (the values of *TERMINAL-IO* and friends) have<br> been initialized to streams associated with fds 0 and 1<br> - in a way that affects how errors that occur in the event thread are handled.<br> (If the AltConsole is available, the event thread will enter a break loop<br> that effectively interacts with it, however crudely; if not, IIRC some<br> error information (possibly including a backtrace) is written and the thread<br> crosses its fingers and tries to reset itself to the point where the next<br> event would be processed.)<br><br>It's a little awkward, but it's generally possible to do some debugging in<br>a break loop in the AltConsole window. You don't have much in the way of<br>lisp-aware editing support and you don't have a GUI (the GUI is sitting in<br>a break loop ...), but you can poke around a bit and may be able to understand<br>the problem more easily than if all you could do is look at printed backtraces<br>in a logfile somewhere. It's not an ideal debugging environment (but neither<br>is staring at logfiles), and I think the answer to your basic question (why<br>is AltConsole used ?) is that it's better than nothing, and many people find<br>staring at logfiles to be not much better than nothing.<br><br><blockquote type="cite">Now that I think of it, I can probably fix my current annoyance by simply rebinding Hunchentoot's *terminal-io*.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">"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."<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(Obviously I'm paraphrasing -- I haven't actually seen this in quite a while.)<br></blockquote><br>If two threads try to write to the same stream, that's generally possible because<br>a lock guards the internal state of the stream. Even if that internal state is<br>kept consistent, the output is generally going to be jumbled and possibly unreadable,<br>and you'd need to use some higher-level locking protocol to decide which thread<br>writes to the stream when.<br><br>If two threads try to read from the same stream at the same time, it's generally<br>necessary to use a higher-level protocol in order to have any idea of which thread<br>reads what (parts of the) input, and that's more often more than a cosmetic issue.<br>The higher-level protocol that CCL uses affect some ways of requesting input from<br>a shared input stream (it affects things like break loops and Y-OR-N-P; it -doesn't-<br>affect things like READ-LINE or READ-CHAR) and involves the concept of some thread<br>being designated as the (current) "owner" of that shared resource and a means of<br>(at least temporarily) transferring or yielding ownership to some other thread.<br>If you run CCL in the shell, the initial listener thread "owns" the input side<br>of *TERMINAL-IO*<br><br>If you run CCL in the shell and do:<br><br>? (process-run-function "example" (lambda () (sleep 1) (break)))<br><br>you'll get the same sort of message and the same sort of advice to type a<br>command which will transfer/yield ownership of the stream to the specified<br>thread. That advice will make sense if the current owner (the listener<br>thread) is back at a REPL prompt and the :Y command will have the intended<br>effect there.<br><br>If you did:<br><br>(progn<br> (process-run-function "example" (lambda () (sleep 1) (break)))<br> (sleep 60))<br><br>then the message and advice would come at a time when the advice is harder to act<br>on; you'd have to interrupt the SLEEP call in the listener or wait for it to<br>finish before you could act on the advice.<br><br>In the GUI environment, the same "ownership" protocol is used to control access<br>to the input side of the (global, static) *TERMINAL-IO* and the event thread<br>is noted as the owner, but (as you've noted) the advice makes less sense: the<br>owner of the shared resource is usually off processing events instead of reading<br>REPL commands from that stream. There are likely a few solutions to this<br>problem. but everything that I've considered can be as confusing as the problem<br>itself.<br><br>A workaround is to use (in the Cocoa environment) BACKGROUND-PROCESS-RUN-FUNCTION<br>instead of PROCESS-RUN-FUNCTION. (I'm fairly sure that the former symbol is<br>exported and FIND-SYMBOL or APROPOS or ... would tell you what package it's<br>exported from.) A thread created with BACKGROUND-PROCESS-RUN-FUNCTION will<br>behave much like a listener thread in the Cocoa GUI: its standard stream variables<br>will be bound to a stream/streams that use a Listener window and its underlying<br>Hemlock buffer for I/O, but in the case of a "background" thread the window<br>will only be created and made visible if the thread does I/O to that stream.<br><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">rg<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Openmcl-devel mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br></blockquote><blockquote type="cite"><a href="http://clozure.com/mailman/listinfo/openmcl-devel">http://clozure.com/mailman/listinfo/openmcl-devel</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Prof. Alexander Repenning</font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px">University of Colorado</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Computer Science Department</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Boulder, CO 80309-430</p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a></font></p><br class="Apple-interchange-newline"></span></span></span></span>
</div>
<br></body></html>