From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D84C1BC48 for ; Thu, 7 Apr 2005 05:40:51 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j373epMT006380 for ; Thu, 7 Apr 2005 05:40:51 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA25437 for ; Thu, 7 Apr 2005 05:40:50 +0200 (MET DST) Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id j373enjS006375 for ; Thu, 7 Apr 2005 05:40:50 +0200 Received: from unknown (HELO ?192.168.1.100?) (rftp@pacbell.net@63.194.18.166 with plain) by smtp816.mail.sc5.yahoo.com with SMTP; 7 Apr 2005 03:40:48 -0000 Message-ID: <4254ABC7.2080003@rftp.com> Date: Wed, 06 Apr 2005 20:40:55 -0700 From: Robert Roessler Organization: Robert's High-performance Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Garrigue Cc: Caml-list Subject: Re: [Caml-list] Toplevel usage of stdout and stderr References: <4253A8E0.8090802@rftp.com> <20050406.194634.00976783.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20050406.194634.00976783.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4254ABC3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4254ABC1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 toplevel:01 stdout:01 stderr:01 toplevel:01 ocaml:01 stdout:01 stderr:01 ocaml:01 surprising:01 prerr:01 ugliness:01 buffering:01 iirc:01 low-level:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Jacques Garrigue wrote: > From: 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". > > > 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