caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: "Christoph Höger" <christoph.hoeger@celeraone.com>,
	"OCaml Mailing List" <caml-list@inria.fr>
Subject: Re: [Caml-list] In-memory assembly
Date: Wed, 10 Jan 2018 17:46:22 +0100	[thread overview]
Message-ID: <24887eea-d5d3-21f8-bc1e-2e23af47cccd@starynkevitch.net> (raw)
In-Reply-To: <CAOazmvuH+DPaoEsEcXX2W0zv8J6po5h=2tmmiCg6d1U6Ad1t-w@mail.gmail.com>



On 01/10/2018 11:20 AM, Christoph Höger wrote:
> Dear all,
>
> I want to trigger OCaml compilation programmatically from a C++ 
> application and avoid the usage of subprocesses. It is fairly 
> straightforward to generate an OCaml AST, but I cannot compile it.


You should explain what kind and size is the generated code, and why do 
you want to avoid the usage of subprocesses.
My impression is that you should not be afraid of using subprocesses and 
temporary files.

Some hints and feelings (which I did not got from generating Ocaml code, 
but C code, in my past http://starynkevitch.net/Basile/gcc-melt/ project)


Generating Ocaml code is a good idea (I am very fond of metaprogramming 
in general). Perhaps you should into MetaOcaml (see 
http://okmij.org/ftp/ML/MetaOCaml.html for more)

I'm guessing you might generate a non-tiny amount of Ocaml code, and 
since you want to use the native Ocaml compiler, that code will run for 
a non-short period of time. Notice that if both assumptions are false 
(tiny amount of generated code, running for a short period of time) 
you'll be happy by embedding the Ocaml bytecompiler in your C++ 
application (and there is no real point in using the native Ocaml 
compiler), which I believe is a solved problem.

So, I am assuming you generate a non-small Ocaml file (e.g. a thousand 
lines), and it runs for a non-tiny amount of time (e.g. at least half a 
second, or perhaps 0.1 second).

Then you probably want to ask your ocamlopt compiler to optimize, e.g. 
with its -O2 flag. This probably takes a few tenths of seconds (on a 
file of a few thousand lines of Ocaml), or more. That delay (even 0.1 
seconds of compilation time by ocaml) is long enough to make the usage 
of subprocesses insignificant: a modern system can run hundreds of 
processes every second.

If you care about filesystem delays (which are not that important), 
consider putting the generated Ocaml source code on some fast 
filesystem, e.g. some tmpfs on Linux.

Cleaning up temporary files and running short processes from C++ code is 
a solved problem (and a very common practice).

Cheers.


Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France


      parent reply	other threads:[~2018-01-10 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 10:20 Christoph Höger
2018-01-10 10:41 ` Gabriel Scherer
2018-01-10 15:42   ` Evgeny Roubinchtein
2018-01-10 16:46 ` Basile Starynkevitch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24887eea-d5d3-21f8-bc1e-2e23af47cccd@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=caml-list@inria.fr \
    --cc=christoph.hoeger@celeraone.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).