English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Usability problems with ocamlmktop / toplevels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-08-15 (13:35)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Usability problems with ocamlmktop / toplevels
Am Freitag, den 12.08.2005, 16:28 +0100 schrieb Richard Jones:
> I'm experimenting with building a custom toplevel, but have run across
> some problems.
> (1) I want to have some modules 'open' already in the toplevel - we
> have lots and lots of modules, some with long names, and most of these
> should be opened by default.  The partial solution is to add lots of
> 'open' statements to a .ocamlinit file in the current directory, but
> this assumes that you know what the current directory is, and that you
> only need to use one type of toplevel in that directory.

It is not possible to compile such "open"s into the toplevels. This has
to to with the initialisation order.

Nevertheless, a partial solution is implemented in findlib:

ocamlfind ocamlmktop -o top -custom -package findlib,... -linkpkg

Note that I mention "findlib" explicitly. Now you can at least #require
the packages in scripts which generates the necessary #directory
directives, so your script becomes independent of where the packages are
actually installed. (#require does not load code that is already part of
the toplevel.)

My advice is to have a project-wide initialisation file one can #use
from the scripts, e.g.

#use "./init.ml"

And in init.ml there are all the #require and open directives.

> (2) Toplevels don't work the same way as 'ocaml'.  The difference is
> that our custom toplevel ignores any command line arguments passed to
> it, whereas 'ocaml foo.ml' runs 'foo.ml'.  This means that we can't
> use our toplevel to write scripts:
>   #!./adwords
> (or variations we've tried) doesn't work.

For me this works.

Maybe the OS does not resolve the relative path. You can also try

#! /usr/bin/env ./adwords

but note that #! only allows one argument.

> (3) Some libraries are linked into the toplevel, but apparently can't
> be accessed.  For instance, Calendar ExtLib must be linked into the
> toplevel because our main code relies on them; however no symbols from
> either are visible:
> $ ./adwords
>         Objective Caml version 3.08.2
> # Date.today ();;
> Unbound value Date.today
> # open Date;;
> Unbound module Date
> # ExtString.String.split;;
> Unbound value ExtString.String.split

The directories are not in the search path. This is solved by the
#require trick shown above.

> Rich.
> PS. This is how we build the toplevel:
> ocamlfind ocamlmktop -custom -package pxp-lex-iso88591,pxp-engine,netclient,netstring,extlib,pcre,calendar -I ../ocsoap -I ../csv -linkpkg ../ocsoap/oCSoap.cmo ../csv/csv.cma adwords.cma -o adwords
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714