[Openmcl-devel] stdout from called C funcs while using IDE

[Gary Byers]

In an OSX GUI application, fd 0 is connected to /dev/null and fd's 1 and 2
are redirected to a logging mechanism.  The C runtime library initializes
the standard FILE*s (stdin, stdout, stderr) to use these file descriptors
(regardless of whether the application is a GUI or command-line application.)

The lisp also initializes lisp streams that use these file descriptors.
One of them - an output stream associated with fd 1 - happens to be
the value of CCL::*STDOUT* - but it's a very different kind of object than
(but with a similar function to) C's "stdout".

The initial lisp thread - the thread that basically runs the Cocoa
event loop - uses input and output streams that are ordinarily associated
with fd's 0 and 1.  That thead shouldn't do much conventional I/O under
normal circumstances, but it's very useful for it to be able to do
at least simple I/O for debugging (rather than just having backtraces
and error messages go to the logging device/console.)  For the last
few months, we've basically been using a little Cocoa program (AltConsole)
and arranging that that kind of output goes (via a socket or pipe or
whatever) to that program.  (We also use #_dup2 to make fd 0 equivalent
to that socket/pipe, so it's possible to do simple kinds of interactive
things - like a simple break loop - in that AltConsole window.)

The lisp kernel also needs to do at least some simple kinds of interactive
I/O (in order to run the kernel debugger, which is at least slightly
better than nothing.)  All of the text output that the kernel does
uses a C stream ("dbgout") that's initially assocated with fd 2; when
the IDE startup code creates a socket to communicate with AltConsole,
we tell the lisp kernel to associate our end of the socket with the
C "dbgout" stream.

Lots of random library functions write diagnostic messages to fd 2
(and it's possible that some of this stuff uses fd 1 as well.) We
intentionally don't try to redirect that to AltConsole, because we
don't want the AltConsole window to pop up and announce things like:

SystemFlippers: didn't consume all output from ...

There's no good way of telling whether those "third party" messages
will be interesting or not, but when we tried to use other mechanisms
to capture process-wide diagnostic output, people complained about
seeing windows popping up to describe things that most people don't
care about or even understand.

It's certainly possible that some third-party diagnostic messages
could be intersting enough to warrant having the AltConsole window
pop up to describe them (and it's also possible that some messages
coming from lisp/the lisp kernel aren't), but we're intentionally
not redirecting fds 1 and 2 (on the assumption that anyone who
knows what SystemFlippers are can probably look in the logfiles
if they want to know whether all input was consumed.)

On Mon, 6 Apr 2009, Paul Krueger wrote:

> I'm running the Cocoa IDE for CCL under Leopard. While working through
> some of the foreign function examples shown on http://ccl.clozure.com/manual/chapter12.10.html
>  I discovered that even though everything works as advertised from a
> CCL command line, when using the IDE the output from the C functions
> is sent to the system console rather than to either the listener
> window or the AltConsole window. I think maybe this is because the
> function try-connecting-to-altconsole in start.lisp uses a dup2 call
> to change stdin (fd 0), but doesn't actually change stdout (fd 1). It
> only changes the lisp symbol ccl::*stdout*. I tried to make what I
> thought was a simple change to fix this by adding a second #_dup2 call
> for fd 1, but when I tried to rebuild the IDE from the CCL command
> line it aborted while trying to save the new application, so I suspect
> there is something more subtle happening during the build.
>
> This isn't really a problem for me given what I need to do, so I'm not
> going to spend any more time chasing it down. But I thought I'd
> mention it in case printf to stdout from a called C function is needed
> by someone.
>
> Incidentally, there is a small typo on http://ccl.clozure.com/manual/chapter12.10.html
> . The include statement in the example code should be "#include
> <stdio.h>" rather than "#include <stdio.>". Most any C programmer
> would figure that out pretty quickly I'm sure.
>
> Paul
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>