From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr 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 0FA13BC69 for ; Mon, 30 Jul 2007 15:22:09 +0200 (CEST) Received: from XSMTP0.ethz.ch (xsmtp0.ethz.ch [82.130.70.14]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6UDM6Di004190 for ; Mon, 30 Jul 2007 15:22:08 +0200 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jul 2007 15:22:06 +0200 Received: from [10.0.1.3] ([80.219.210.76]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jul 2007 15:22:06 +0200 In-Reply-To: <20070730115725.GB28423@jiyu.gnu> References: <950BC328-B571-4736-A779-8E3EE9CF6F3E@student.ethz.ch> <20070730054047.GA11678@jiyu.gnu> <93DE46B0-285F-4066-A1CA-0A3969C728B3@student.ethz.ch> <20070730115725.GB28423@jiyu.gnu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <498E26F4-E414-48A1-ADDE-8A6E03486E82@student.ethz.ch> Cc: caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Kaspar Rohrer Subject: Re: [Caml-list] Native multithreaded LablGTK2? Date: Mon, 30 Jul 2007 15:22:04 +0200 To: Julien Moutinho X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jul 2007 13:22:06.0188 (UTC) FILETIME=[9FE102C0:01C7D2AC] X-Miltered: at concorde with ID 46ADE5FE.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lablgtk:01 pervasives:01 gtk:01 stdout:01 stdout:01 gtk:01 giochannel:01 gmain:01 buffer:01 ocaml:01 buffer:01 gmain:01 iirc:01 threads:01 wrote:01 On 30.07.2007, at 13:57, Julien Moutinho wrote: > Oki douki, it's just that I did not undertand why you use std(in|out) > to communicate between threads... But you use them because you want > a buffering machinery and you have only looked at Pervasives, right? No, the problem is of a different nature: I want to capture standard output and display it in a (log) window in my Gtk application. I'm aware that I could just use custom output functions, but the main problem here is that I've embedded a Scheme interpreter (Ocs, actually: http://will.iki.fi/software/ocs/) which writes to stdout by default. Now, of course I could adapt Ocs to suit my needs. But I have no intention to do so at the moment (although it would be relatively straight forward by extending Ocs_port). >> I'm piping stdout, because that's the only way I was able to redirect >> stdout to a gtk text widget (using a GIOchannel: GMain.Io.*). If >> anybody >> has a better idea, I'd be glad to hear it. I was originally >> thinking of an >> out_channel that writes to a buffer instead of a file, but the Ocaml >> standard library seems to be missing this functionality. Or is it? > You have [Stream.t], [Buffer.t] and [GText.buffer] at your service. > > HTH. I actually already use a GText.buffer. In conjunction with piping and GMain.Io.add_watch, I am able to redirect standard output to the buffer and thus display it in a text widget. But this only works reliably if the application is multithreaded, because pipes have a fixed size buffer (something around 5000 bytes IIRC). Now, if the buffer was able to capture all output, this would work for a single thread also. Because writes to the buffer would never block, unlike writes to a pipe. I might be wrong on all of the above though, as I am far from an expert on either Gtk or multithreading. Anyway, thanks again. I really apreciate any help I can get.