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

[Paul Krueger]

Thanks, that was a good explanation. I can understand why you might  
not redirect fd 2 (normally stderr for C functions) for the reasons  
you mentioned (you would get all sorts of random messages). I suppose  
you can't guarantee that fd 1 doesn't also get that sort of output and  
I can't speak for the various library functions that are out there,  
but I would normally expect the use of fd 1 by OS functions (other  
than those like printf which are explicitly intended to use it) to be  
pretty minimal. So I would mildly lobby for a redirection of fd 1  
(only) to AltConsole in order to accommodate the simple use of printf  
in called C functions. If not, it might be useful for someone to add a  
comment on the web page I referenced to explain where the output from  
the example functions will go when executed under the IDE. Or I  
suppose the examples could be made more complex by passing in the  
AltConsole fd to the C functions. I suspect you may have higher  
priorities, so consider all this just a mild suggestion if it's  
convenient.

On Apr 6, 2009, at 6:01 PM, Gary Byers wrote:

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