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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D30847F0F9 for ; Tue, 24 Nov 2015 18:42:51 +0100 (CET) IronPort-PHdr: 9a23:o4keDBBvYloAVgfAKeVKUyQJP3N1i/DPJgcQr6AfoPdwSP/7oMbcNUDSrc9gkEXOFd2CrakU1qyJ7eu6BSQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTqkb/ssMePKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ7djgTYVQaE+lcbV2wXlFIIX1mEv1nGWcLTvzH3s+twkAWbOMzwSvhgWzij6qZtTzfqgSEKLCIj/WzLzMd3ifQIjgimoklW2Yvd44WiG+f/eK7UYJtOTHBEV8tVESNcD4WxZpYnAuwaeOJJqI+7qUFY/kj2PhWlGO66kmwAvXTxx6Bvlrl4HA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=armael.gueneau@ens-lyon.fr; spf=Pass smtp.mailfrom=armael.gueneau@ens-lyon.fr; spf=None smtp.helo=postmaster@labbe.ens-lyon.fr Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of armael.gueneau@ens-lyon.fr) identity=pra; client-ip=140.77.167.222; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="armael.gueneau@ens-lyon.fr"; x-sender="armael.gueneau@ens-lyon.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of armael.gueneau@ens-lyon.fr designates 140.77.167.222 as permitted sender) identity=mailfrom; client-ip=140.77.167.222; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="armael.gueneau@ens-lyon.fr"; x-sender="armael.gueneau@ens-lyon.fr"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@labbe.ens-lyon.fr) identity=helo; client-ip=140.77.167.222; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="armael.gueneau@ens-lyon.fr"; x-sender="postmaster@labbe.ens-lyon.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9AAD6oFRWnN6nTYxehA5vrl2RUhcBC4VsAoFDPBABAQEBAQEBARABAQEBAQgLCQkhLoItgggBAQQjSwoBEAsOCgkEEgsCAgkDAgECATMSBg0GAgEBDogHAxINrhSLPAOEZAEBAQEBBQEBAQEBAR2LUoc7DC4TgTEFhg4MkDaFJIJyhz+aJQI4gjwWB4FWcoUrAQEB X-IPAS-Result: A0B9AAD6oFRWnN6nTYxehA5vrl2RUhcBC4VsAoFDPBABAQEBAQEBARABAQEBAQgLCQkhLoItgggBAQQjSwoBEAsOCgkEEgsCAgkDAgECATMSBg0GAgEBDogHAxINrhSLPAOEZAEBAQEBBQEBAQEBAR2LUoc7DC4TgTEFhg4MkDaFJIJyhz+aJQI4gjwWB4FWcoUrAQEB X-IronPort-AV: E=Sophos;i="5.20,339,1444687200"; d="scan'208,217";a="188935613" Received: from labbe.ens-lyon.fr ([140.77.167.222]) by mail2-smtp-roc.national.inria.fr with ESMTP; 24 Nov 2015 18:42:51 +0100 Received: from localhost (localhost [127.0.0.1]) by labbe.ens-lyon.fr (Postfix) with ESMTP id DA6D3320C51; Tue, 24 Nov 2015 18:42:50 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.10.1 (20141025) (Debian) at ens-lyon.fr Received: from labbe.ens-lyon.fr ([127.0.0.1]) by localhost (labbe.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxdF9qUzdMI2; Tue, 24 Nov 2015 18:42:49 +0100 (CET) Received: from kingston.cl.cam.ac.uk (kingston.cl.cam.ac.uk [128.232.64.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by labbe.ens-lyon.fr (Postfix) with ESMTPSA id A278C320D0F; Tue, 24 Nov 2015 18:42:49 +0100 (CET) To: Jeremie Dimino References: <5654971F.2070006@ens-lyon.fr> From: =?UTF-8?Q?Arma=c3=abl_Gu=c3=a9neau?= Cc: caml-list Message-ID: <5654A199.3010700@ens-lyon.fr> Date: Tue, 24 Nov 2015 17:42:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030907040701080207090905" Subject: Re: [Caml-list] Custom toplevel and ocamlbuild This is a multi-part message in MIME format. --------------030907040701080207090905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit It sounds better to put "Foo" at the beginning of myutop.mltop indeed! However, it still doesn't work here (same thing, the toplevel cannot access Foo). What is super super weird is that if I manually run the build commands _that ocamlbuild lists in the terminal_, which are: ocamlfind ocamlc -c -thread -package threads,utop -o foo.cmo foo.ml ocamlfind ocamlc -c -thread -package threads,utop -o myutop_main.cmo myutop_main.ml ocamlfind ocamlmktop -linkpkg -thread -package threads,utop -package threads,utop foo.cmo myutop_main.cmo -o myutop.top this time, it works... This smells like $PATH issues or something related to my setup, but I triple-checked and I don't see where this could come from... On 24/11/15 17:14, Jeremie Dimino wrote: > Did you try adding "Foo" at the beginning of myutop.mltop? foo.cmo > needs to come before myutop_main.cmo and I suppose that ocamlbuild > puts the cmo in the same order as the one specified in the .mltop > unless the dependencies force reordering. > > The reason foo.cmo needs to come before is that OCaml run the > initialization code of linked compilation units in the same order they > are specified on the command line and the toplevel can only see > modules that have been initialized. > Myutop_main contains the entry point of the toplevel - i.e. the call > to the interactive loop - so the toplevel doesn't have access to units > that are linked after myutop_main.cmo. That's also the reason why you > can't access Myutop_main from the custom toplevel. > > On Tue, Nov 24, 2015 at 4:58 PM, Armaël Guéneau > wrote: >> Hi list, >> >> I was trying to build a custom toplevel, bundled with my custom >> modules, and encountered a few issues. >> >> Following the last advice given by gasche on this reddit post >> https://www.reddit.com/r/ocaml/comments/3qjs1q/utop_is_a_much_better_toplevel_than_ocaml_if_you/cwisrrj >> I copy-pasted the files from examples/custom-utop, added a foo.ml file >> containing "let x = 3", and added "Foo" at the end of myutop.mltop. >> >> Then, if I compile the custom toplevel using the provided Makefile >> (which simply uses ocamlbuild and the builtin rule for .mltop files, I >> guess), the toplevel produced does not have access to the Foo module. >> >> However, if I manually build using ocamlfind ocamlmktop: >> >> ocamlfind ocamlmktop -o myutop -thread -linkpkg -package utop foo.cmo >> myutop_main.cmo >> >> this time, it works, and `myutop` has access to Foo. >> >> Is the default ocamlbuild rule for building .mltop files missing some >> option? Am I doing something wrong? >> >> — Armaël >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > > --------------030907040701080207090905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It sounds better to put "Foo" at the beginning of myutop.mltop
indeed! However, it still doesn't work here (same thing, the
toplevel cannot access Foo).

What is super super weird is that if I manually run the build commands
_that ocamlbuild lists in the terminal_, which are:

   ocamlfind ocamlc -c -thread -package threads,utop -o foo.cmo foo.ml
   ocamlfind ocamlc -c -thread -package threads,utop -o myutop_main.cmo myutop_main.ml
   ocamlfind ocamlmktop -linkpkg -thread -package threads,utop -package threads,utop foo.cmo myutop_main.cmo -o myutop.top

this time, it works...

This smells like $PATH issues or something related to my setup, but I
triple-checked and I don't see where this could come from...

On 24/11/15 17:14, Jeremie Dimino wrote:
> Did you try adding "Foo" at the beginning of myutop.mltop? foo.cmo > needs to come before myutop_main.cmo and I suppose that ocamlbuild > puts the cmo in the same order as the one specified in the .mltop > unless the dependencies force reordering. > > The reason foo.cmo needs to come before is that OCaml run the > initialization code of linked compilation units in the same order they > are specified on the command line and the toplevel can only see > modules that have been initialized. > Myutop_main contains the entry point of the toplevel - i.e. the call > to the interactive loop - so the toplevel doesn't have access to units > that are linked after myutop_main.cmo. That's also the reason why you > can't access Myutop_main from the custom toplevel. > > On Tue, Nov 24, 2015 at 4:58 PM, Armaël Guéneau > <armael.gueneau@ens-lyon.fr> wrote: >> Hi list, >> >> I was trying to build a custom toplevel, bundled with my custom >> modules, and encountered a few issues. >> >> Following the last advice given by gasche on this reddit post >> https://www.reddit.com/r/ocaml/comments/3qjs1q/utop_is_a_much_better_toplevel_than_ocaml_if_you/cwisrrj >> I copy-pasted the files from examples/custom-utop, added a foo.ml file >> containing "let x = 3", and added "Foo" at the end of myutop.mltop. >> >> Then, if I compile the custom toplevel using the provided Makefile >> (which simply uses ocamlbuild and the builtin rule for .mltop files, I >> guess), the toplevel produced does not have access to the Foo module. >> >> However, if I manually build using ocamlfind ocamlmktop: >> >>   ocamlfind ocamlmktop -o myutop -thread -linkpkg -package utop foo.cmo >> myutop_main.cmo >> >> this time, it works, and `myutop` has access to Foo. >> >> Is the default ocamlbuild rule for building .mltop files missing some >> option?  Am I doing something wrong? >> >> — Armaël >> >> -- >> Caml-list mailing list.  Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > >


--------------030907040701080207090905--