From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p1RAqFjo005758 for ; Sun, 27 Feb 2011 11:52:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcDAJ+7aU3UGyoElGdsb2JhbACYNI4SFQEBAQEJCwgJEQMiuXmFYQSPZg8 X-IronPort-AV: E=Sophos;i="4.62,234,1297033200"; d="scan'208";a="92165698" Received: from smtp4-g21.free.fr ([212.27.42.4]) by mail2-smtp-roc.national.inria.fr with ESMTP; 27 Feb 2011 11:52:11 +0100 Received: from acer.happyleptic.org (unknown [82.229.213.209]) by smtp4-g21.free.fr (Postfix) with SMTP id 0E4384C835B for ; Sun, 27 Feb 2011 11:52:03 +0100 (CET) Received: by acer.happyleptic.org (sSMTP sendmail emulation); Sun, 27 Feb 2011 11:52:03 +0100 Date: Sun, 27 Feb 2011 11:52:03 +0100 From: rixed@happyleptic.org To: caml-list@inria.fr Message-ID: <20110227105201.GA2765@happyleptic.org> References: <20110226214403.GA20532@yeeloong.happyleptic.org> <20110227024520.GL18196@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110227024520.GL18196@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Calling the toplevel from the toplevel > For this, you can change the Toploop.read_interactive_input reference to > what you want to control what you input to the toplevel. Yes, I tried this initially, having found this into the lwt top level. Actually, there is many way to replace stdin by something else. My main concern is for stdout, which appears explicitly in the code for the toplevel directives. > You therefore > do not need to consider workarounds such as calling evaluation functions > from code evaluated from the toplevel itself. Calling the evaluator is the only way I've found to prevent the toplevel from writing into stdout (apart from manipulations of the file descriptors themself, which are error prone since ncurses also insist on writing on file descriptor 1). > But it's a bit surprising that application bindings are not available > when calling start_application from some code that is being loaded. If > you insist on loading a .cmo instead of a .cma, the .cmo code is > executed when loaded, while code in the .cma often seems to be executed > only when required. That may solve your issue. Dunno. The application is not loaded as a cmo nor as a cma, but linked into a custom toplevel with mktoplevel, so I'm unsure if this remark applies. > You've also got a Toplevel.toplevel_startup_hook ref that may be useful. I will have a look to this one, thank you!