[Caml-list] embedding Ocaml in an existing application

[Caml-list] embedding Ocaml in an existing application

[Basile STARYNKEVITCH]

Hello,

Some remarks (and wishes) about embedding Ocaml (bytecoded) in an
existing application.

I just embedded (a single day hack) Ocaml inside the Larbin web
crawler (coded in C++ by Sebastien Ailleret) on
http://pauillac.inria.fr/~ailleret/prog/larbin/ You should be able to
get the patch from my personal web page or else email me either at
work <basile.starynkevitch@cea.fr> or at home
<basile@starynkevitch.net>. This because I need (for the POESIA
project) to scan some part of the Web and get some crude measures of
features like: percentage of Web pages using Javascript (about 50%)
and mean length of such scripts (about 2Kbytes). So I hacked larbin to
add Ocaml inside it.

I used ocaml v3.02 or v3.01 (bytecode interpreter).

First remark: the ocaml linking mechanism use the undocumented -p
flag to dump all the Ocaml symbol table. So I had to hack Larbin's
main routine to test for the special -p single argument and then call
only ocaml_main_init(argv); and exit(0) in that case. I believe that
it would be quite trickly to embed Ocaml inside a significant
application which uses the -p flag (see the code in
ocaml/byterun/startup.c routine parse_command_line). At least I
suggest that the linking mechanism use a less natural convention (such
as "-print-ocaml-symbols" as argv[1] of main) and that it could be
documented. (and I did not found quickly where Ocaml invokes this
magic -p flag).

Second remark: for embedding Ocaml inside Larbin I need the
-use-runtime flag to the ocamlc compiler. But it seems that the next
version (v3.03) does not have it anymore. I hope that it will still be
possible to embed OCaml inside an application without having to
compile the whole application as a shared library.

3rd remark: 
why don't caml_main take and changes the main argc,argv arguments
(like e.g. gtk_init routine in the Gtk toolkit) so that the
application can use the other arguments. Otherwise, I suggest to
publicize the parse_command_line routine so an embedding application
could parse its own main arguments and pass some others to ocaml
before starting the Ocaml interpreter. (imagine you want to embed
Ocaml inside an existing Gtk application?).

My previous post http://caml.inria.fr/archives/200112/msg00015.html
regarding a tiny syntactic extension was related to this [Larbin]
patch. I think that novice Ocaml users might be interested in a
syntactic sugar to register bound values.

Regards to all
-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] embedding Ocaml in an existing application

[Xavier Leroy]

> Some remarks (and wishes) about embedding Ocaml (bytecoded) in an
> existing application.
> [...]
> First remark: the ocaml linking mechanism use the undocumented -p
> flag to dump all the Ocaml symbol table.

Only for the -use-runtime linking mode, which I think is not required
at all for what you're doing (embedding an OCaml program and the
OCaml runtime inside a larger program).  The "-use-runtime" and
"-make-runtime" linking modes are just a variation on "-custom"
linking where the custom runtime system can be shared between several
bytecode executables.  For embedding OCaml, I'd suggest either

1) link in -custom mode with your own main() function and the rest of
   the application as C libraries or object files;

or:

2) link the Caml code in -output-obj mode and perform the final linking
   (with the rest of the application) using the C linker.

Both approaches are documented in the chapter "C interface" of the
manual.  I advise (2) over (1) because it's often more flexible,
e.g. you can provide the Caml parts to your Caml-phobic colleagues as
an innocuous-looking C object file, and they don't even need to have
ocamlc installed to perform the final link of the application.

> So I had to hack Larbin's
> main routine to test for the special -p single argument and then call
> only ocaml_main_init(argv); and exit(0) in that case. I believe that
> it would be quite trickly to embed Ocaml inside a significant
> application which uses the -p flag (see the code in
> ocaml/byterun/startup.c routine parse_command_line). At least I
> suggest that the linking mechanism use a less natural convention (such
> as "-print-ocaml-symbols" as argv[1] of main) and that it could be
> documented. (and I did not found quickly where Ocaml invokes this
> magic -p flag).

The ocamlc linker, when invoked with -use-runtime /my/runtime,
will invoke /my/runtime -p to learn about the primitives that
/my/runtime provides.

> Second remark: for embedding Ocaml inside Larbin I need the
> -use-runtime flag to the ocamlc compiler. But it seems that the next
> version (v3.03) does not have it anymore. I hope that it will still be
> possible to embed OCaml inside an application without having to
> compile the whole application as a shared library.

Yes, it will still be possible, for two reasons:
1) you don't need -use-runtime here (see above)
2) -use-runtime was gone in 3.03 alpha, but is back by popular demand
in the next release.

(The new facilities for dynamic loading makes -use-runtime
essentially useless, but these dynamic loading facilities are not yet
running on all systems, so let's keep -use-runtime for a while.)

> 3rd remark: 
> why don't caml_main take and changes the main argc,argv arguments
> (like e.g. gtk_init routine in the Gtk toolkit) so that the
> application can use the other arguments. Otherwise, I suggest to
> publicize the parse_command_line routine so an embedding application
> could parse its own main arguments and pass some others to ocaml
> before starting the Ocaml interpreter. (imagine you want to embed
> Ocaml inside an existing Gtk application?).

I agree that only your main() routine knows how to deal with the
command-line arguments and options.  So, the "argv" arguments that it
passes to caml_main are not, in general, the same "argv" that main()
received.  Often, none of the arguments and options are intended for
Caml, they are all to be processed by your main program.  Then,
it suffices to pass caml_main the arguments
                { argv[0], NULL }
i.e. an empty command-line.  In more complicated situations, you may
have to parse the command-line, construct a "caml_argv" array of
arguments intended for Caml, and call caml_main(caml_argv), but I've
never encountered a need for doing this.

Best wishes,

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr