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 BB92E7F109 for ; Tue, 24 Nov 2015 18:52:54 +0100 (CET) IronPort-PHdr: 9a23:53P3RhNTJ12TdZ2pyJkl6mtUPXoX/o7sNwtQ0KIMzox0Kfz8rarrMEGX3/hxlliBBdydsKIZzbWI+Pq/EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35nxiL75ocKbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t/vQqALbQACTynwZW2QQ2loUUkmWpC39C7X8qCb/t+c19CifPMvxBeQ2VTWn7qFsYB3hjiocKyQ0/X2Rgct12vF1uhWk8jVlxodXZLa6KXt4c6rANYcTX29IU8IXWDFMBI61cqMCCfFEOfdfqc/zvQ1d/lOFGQCwCba3mXdzjXjs0Ph/jr0s 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: A0B9AACNo1RWnN6nTYxehA5vrl2RUhcBC4VsAoFDPBABAQEBAQEBARABAQEBAQgLCQkhLoItgggBAQQjSwoBEAkCDgoJBBILAgIJAwIBAgEzEgYNBgIBAQ6IBwMSDZBnnTWLOgOEdAEBAQEBBQEBAQEBAR2LUoc7DC4TgTEFhg4MjFGDZYUkgnKGdkmHHJMJAjiCPBYHgVZyhSsBAQE X-IPAS-Result: A0B9AACNo1RWnN6nTYxehA5vrl2RUhcBC4VsAoFDPBABAQEBAQEBARABAQEBAQgLCQkhLoItgggBAQQjSwoBEAkCDgoJBBILAgIJAwIBAgEzEgYNBgIBAQ6IBwMSDZBnnTWLOgOEdAEBAQEBBQEBAQEBAR2LUoc7DC4TgTEFhg4MjFGDZYUkgnKGdkmHHJMJAjiCPBYHgVZyhSsBAQE X-IronPort-AV: E=Sophos;i="5.20,339,1444687200"; d="scan'208,217";a="188936934" Received: from labbe.ens-lyon.fr ([140.77.167.222]) by mail2-smtp-roc.national.inria.fr with ESMTP; 24 Nov 2015 18:52:28 +0100 Received: from localhost (localhost [127.0.0.1]) by labbe.ens-lyon.fr (Postfix) with ESMTP id 07AB2320D21; Tue, 24 Nov 2015 18:52:28 +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 CQvjG5ZZ9Zma; Tue, 24 Nov 2015 18:52:26 +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 6FD8F320D09; Tue, 24 Nov 2015 18:52:26 +0100 (CET) To: Jeremie Dimino References: <5654971F.2070006@ens-lyon.fr> <5654A199.3010700@ens-lyon.fr> Cc: caml-list From: =?UTF-8?Q?Arma=c3=abl_Gu=c3=a9neau?= Message-ID: <5654A3DA.7000503@ens-lyon.fr> Date: Tue, 24 Nov 2015 17:52:26 +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="------------040005070107010001000902" Subject: Re: [Caml-list] Custom toplevel and ocamlbuild This is a multi-part message in MIME format. --------------040005070107010001000902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I see. That was it, indeed. Thanks a lot for the answers! On 24/11/15 17:48, Jeremie Dimino wrote: > It might be to do with where foo.cmi ends up. When using ocamlbuild it > will be in _build while when running the command manually it will be > in the current directory. Toplevels are not standalone, they need to > read the .cmi files at runtime. The cmi files are located by the OCaml > compiler using a search path. > > Try running myutop.top as follow after building it with ocamlbuild: > > ./myutop.top -I _build > > Alternatively you can also use `#directory "_build";;` from inside the toplevel. > > On Tue, Nov 24, 2015 at 5:42 PM, Armaël Guéneau > wrote: >> 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 > > > >> >> > > > --------------040005070107010001000902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I see. That was it, indeed.

Thanks a lot for the answers!

On 24/11/15 17:48, Jeremie Dimino wrote:
> It might be to do with where foo.cmi ends up. When using ocamlbuild it > will be in _build while when running the command manually it will be > in the current directory. Toplevels are not standalone, they need to > read the .cmi files at runtime. The cmi files are located by the OCaml > compiler using a search path. > > Try running myutop.top as follow after building it with ocamlbuild: > >     ./myutop.top -I _build > > Alternatively you can also use `#directory "_build";;` from inside the toplevel. > > On Tue, Nov 24, 2015 at 5:42 PM, Armaël Guéneau > <armael.gueneau@ens-lyon.fr> wrote: >> 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 > > > >> >> > > >


--------------040005070107010001000902--