Toplevel usage of stdout and stderr

Toplevel usage of stdout and stderr

[Robert Roessler]

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

I would like to know if the apparent mixing of the two channels is 
intended, or if it is a bug (possibly just with the Windows version), 
and if there is some rationale for when stdout is used versus stderr.

This last would be of help to me, as I am trying to do "smart" 
filtering (and interpreting) of the toplevel output - and not having 
any model for what is going to show up where (other than knowing that 
the "inferred type and result value, if any" will go to stdout, as 
will the "# " prompt) makes this a little more difficult. :)

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

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

[Jacques Garrigue]

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.

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

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.

Jacques Garrigue

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

[Robert Roessler]

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