From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D8FA87FA30 for ; Sun, 13 Jul 2014 12:23:33 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of michipili@gmail.com) identity=pra; client-ip=74.125.82.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="michipili@gmail.com"; x-sender="michipili@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of michipili@gmail.com designates 74.125.82.172 as permitted sender) identity=mailfrom; client-ip=74.125.82.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="michipili@gmail.com"; x-sender="michipili@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f172.google.com) identity=helo; client-ip=74.125.82.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="michipili@gmail.com"; x-sender="postmaster@mail-we0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQBAJhdwlNKfVKslGdsb2JhbABZg2CDS6kVCgEGlSKIWBYPAQEBAQcLCwkSKoQcEQ8BDQEbHAIDEhAPAgUTAwsCCwMCAQIBEREBBQEvCAIeiAsBAxEEAZ9fgxJqiyeBcoMQilgKGScNZIZVAQUOgR6ET4QDhWqCYYFMBZsOgUqFQ4sfQYR2 X-IPAS-Result: AkQBAJhdwlNKfVKslGdsb2JhbABZg2CDS6kVCgEGlSKIWBYPAQEBAQcLCwkSKoQcEQ8BDQEbHAIDEhAPAgUTAwsCCwMCAQIBEREBBQEvCAIeiAsBAxEEAZ9fgxJqiyeBcoMQilgKGScNZIZVAQUOgR6ET4QDhWqCYYFMBZsOgUqFQ4sfQYR2 X-IronPort-AV: E=Sophos;i="5.01,652,1400018400"; d="scan'208";a="71241098" Received: from mail-we0-f172.google.com ([74.125.82.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Jul 2014 12:23:30 +0200 Received: by mail-we0-f172.google.com with SMTP id x48so1132962wes.31 for ; Sun, 13 Jul 2014 03:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7uU21UDEojjc1WwoIzIytRQ+/LWeswsbcILwxyFkEgA=; b=Kie4W0zl5ut91OjuIAbs9e2izM43RwRD5aA2Y120f4O6Zk+F4s73bz9xDqgobjjeCh 1n/B5WI1/73fZYAXhWt7arbW8ATp68jdN7fDPPuyaYlgThTgGJt6X5/vJJDibPrLeVhf K7PJtMLbdWWKwNgQA9D+/iESCWuNT4dmElJVAni0m9xkAslQxDTypfvcnivCmTy+1WAg H7Tg+WCMBkODe0AP6YaQ4NiEZoIy4jdavYX0d8EPDO4lnUj9DzIPvsjxTJySSNMQ/qyj wAQdcbzXPd65yVJBO5hUQqzaGxTd2NWJ+kKEquOLcpkwpnBRJW67/2lo1dDNGGuET+Wb AAuA== X-Received: by 10.194.62.140 with SMTP id y12mr11668679wjr.27.1405247009445; Sun, 13 Jul 2014 03:23:29 -0700 (PDT) Received: from llea.celt.neu (xdsl-89-0-102-51.netcologne.de. [89.0.102.51]) by mx.google.com with ESMTPSA id ub11sm17303529wib.1.2014.07.13.03.23.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jul 2014 03:23:28 -0700 (PDT) Message-ID: <53C25E20.6070704@gmail.com> Date: Sun, 13 Jul 2014 12:23:28 +0200 From: =?UTF-8?B?TWljaGFlbCBHcsO8bmV3YWxk?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Caml-list] Toplevel startup hook When preparing a custom toplevel, one can use Toploop.toplevel_startup_hook to prepare the environment of the toplevel. I use this to open some modules and add some custom printers. It works great but I noticed a surprising behaviour. When running, the startup hook is executed before the input is read $ ./customtoplevel < script.ml however with $ ./customtoplevel script.ml or $ ./customtoplevel -stdin < script.ml the startup hook is still executed, but apparently, it is executed *after* script.ml, which makes the startup hook useless in this case, since script.ml obviously wants to use the modules compiled in the toplevel, which is only possible if the path of the interface is added with a `#directory` directive. What is the rationale behind this behaviour? What is the best way to go around this? I am looking forward writing a toplevel which can open modules and install printers. Is there a way to do this without relying on initialisation files, i.e. purely “within” the executable produced by ocamlmktop? Also, is there any reason why CMI files not packed in the toplevel together with the implementation? It seems to me, one cannot use the toplevel without these implementation files *and* there is no easy way to let the toplevel find these files when you are working as a toplevel developer (CMIs are in your project directories) and when you are working as a toplevel user (CMIs are installed in the standard library directory). -- Michael