Re: [Caml-list] Toplevel usage of stdout and stderr

[Robert Roessler <roessler@rftp.com>]

Jacques Garrigue wrote:

> From: Robert Roessler <roessler@rftp.com>
> 
>>I am close to finishing my LablGTK-based syntax-colored GUI for the 
>>toplevel... and I have noticed [the Windows version of] the ocaml 
>>toplevel seems to use both stdout and stderr for warnings and errors.
>>
>>Chapter 9 of the Objective Caml manual clearly states "results are 
>>printed on standard output, errors on standard error" and further that 
>>the Windows ocaml.exe "works exactly as under Unix".
> 
> 
> Sometimes even developers don't read the manual.
> I was convinced that in interactive mode errors go to stdout.
> I even remember some discussions about this.
> In practice it seems that errors go to stdout, but warnings go to
> stderr. Not surprising as prerr_warning takes no parameter and prints
> (almost) directly to stderr.

Actually, it is even weirder than this. :)  My favorite is

STDERR:
Characters 53-60:
Warning: this match case is unused.

STDOUT:
   match [] with
   | a :: [] -> []
   | _ :: a :: [] -> []
   | b :: [] -> []..
   | b :: [] -> [];;
     ^^^^^^^

This splitting of the same message across the two channels causes an 
ugliness - I end up having to process the stderr info (if any) before 
the stdout.  Not horrible, but I have to wait to see if there is going 
to be any stderr output.

> Sorry for this confusing situation. On Unix this is not too bad, but
> on windows the buffering can be a pain IIRC.

Good old select and low-level I/O.  Sigh.

> If you are calling ocaml as a subprocess, ocamlbrowser provides a way
> to do it, and even to kill the subprocess. Look in shell.ml. This is
> rather mixed with Tk parts. The point is that on windows Fileinput did
> not work on pipes, so an alternative system is coded using threads.

Yes, I am using a create_process - I implemented the socketpair (in 
Caml, of course) and use three of those to communicate with the 
toplevel.  I did this instead of pipes so I could use select without 
worrying about how the pipes were implemented.

The CAMLSIGPIPE thing looks like it will... work.  I would much rather 
that the kill call was supported in the Windows version of the Unix 
library - since it *could* do SIGINT.  I have already written this for 
myself, but the CAMLSIGPIPE hack has the advantage of not requiring 
the additional DLL with the kill in it.  Thanks for the tip. :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com