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 p1R2knP8028356 for ; Sun, 27 Feb 2011 03:46:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcBAC9KaU1V2gB4mWdsb2JhbACmWwEBAQEBCAsKBxElunwNhVQEj3U X-IronPort-AV: E=Sophos;i="4.62,233,1297033200"; d="scan'208";a="92154679" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail2-smtp-roc.national.inria.fr with SMTP; 27 Feb 2011 03:46:44 +0100 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.93.111]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id C43E712C0A7; Sun, 27 Feb 2011 03:46:42 +0100 (CET) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1PtWdM-00086H-Ih; Sun, 27 Feb 2011 03:45:20 +0100 Date: Sun, 27 Feb 2011 03:45:20 +0100 From: Guillaume Yziquel To: rixed@happyleptic.org Cc: caml-list@inria.fr Message-ID: <20110227024520.GL18196@localhost> References: <20110226214403.GA20532@yeeloong.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110226214403.GA20532@yeeloong.happyleptic.org> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p1R2knP8028356 Subject: Re: [Caml-list] Calling the toplevel from the toplevel Le Saturday 26 Feb 2011 à 22:44:04 (+0100), rixed@happyleptic.org a écrit : > I'm trying to build an application that's run from the toplevel, using > the toplevel to customize the application from itself (for instance, > setting some global parameters using the toplevel to configure the > application behavior while it's running). > > But I cannot allow the toplevel to read directly from stdin nor to > write anything into stdout (since my application uses ncurses). > > I've looked for various ways to do this, and the simpler I found to > prevent the toplevel to use stdout is to call myself > Toploop.execute_phrase with a custom formatter (so that I can display > the output where and how I want). > > Up to now all seams to work except for minor annoyances : > > - I cannot start the application directly by linking the custom toplevel > with something like "let _ = start_application ()" but I have to call > "start_application();;" from the toplevel manually (or from the > .ocamlinit file), otherwise the application bindings are not > available. For this, you can change the Toploop.read_interactive_input reference to what you want to control what you input to the toplevel. You therefore do not need to consider workarounds such as calling evaluation functions from code evaluated from the toplevel itself. 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. You've also got a Toplevel.toplevel_startup_hook ref that may be useful. > - I cannot let the user uses the toplevel directives "use" and "load" > because both writes into stdout whatever the formatter passed to > Toploop.execute_phrase (for "use" this is easily solvable by shadowing > the toplevel implementation by another one that call Toploop.use_file > with my own formatter, but for "load" I would have to copy a lot of > code from topdirs.ml > > I'd like to know if it is safe to call the Toploop evaluation functions > from code evaluated from the toplevel itself ? Or if someone can suggest > a better way to prevent the toplevel from using stdout ? Well, the Toploop module provides some interesting values to control output: val parse_toplevel_phrase : (Lexing.lexbuf -> Parsetree.toplevel_phrase) ref val parse_use_file : (Lexing.lexbuf -> Parsetree.toplevel_phrase list) ref val print_location : formatter -> Location.t -> unit val print_error : formatter -> Location.t -> unit val print_warning : Location.t -> formatter -> Warnings.t -> unit val input_name : string ref val print_out_value : (formatter -> Outcometree.out_value -> unit) ref val print_out_type : (formatter -> Outcometree.out_type -> unit) ref val print_out_class_type : (formatter -> Outcometree.out_class_type -> unit) ref val print_out_module_type : (formatter -> Outcometree.out_module_type -> unit) ref val print_out_sig_item : (formatter -> Outcometree.out_sig_item -> unit) ref val print_out_signature : (formatter -> Outcometree.out_sig_item list -> unit) ref val print_out_phrase : (formatter -> Outcometree.out_phrase -> unit) ref I'd also look in the toplevel code of lwt, specifically in the source code of lwt.top package. Contains quite a lot of interesting toplevel tricks that would likely be of use to you. I'm not so sure, but it seems to have some amount of control over toplevel output. -- Guillaume Yziquel