Usability problems with ocamlmktop / toplevels

Usability problems with ocamlmktop / toplevels

[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.

(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.

(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

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

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Usability problems with ocamlmktop / toplevels

[Olivier Andrieu]

Hi Richard,

 Richard Jones [Friday 12 August 2005] :
 > (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

That's because the toplevel needs access to the .cmi of the modules
_at runtime_. Use the -I argument of the toplevel, or the #directory
directive. 

-- 
   Olivier

Re: [Caml-list] Usability problems with ocamlmktop / toplevels

[Gerd Stolpmann]

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.

#!./top
#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
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------