ocaml dll in an Erlang runtime

ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

[-- Attachment #1: Type: text/plain, Size: 3500 bytes --]


Would any of you be interested in prototyping a semi-tight coupling
between Erlang and OCaml?

A small group of Erlang programmers have started tossing the idea
around, and with sufficient lack of detailed knowledge, it seems pretty
reasonable. (:


Motivation:

We've been using Erlang in commercial products for over 10 years now,
and it's taken about that long to get into a position where we're
considered a viable player for mission-critical product development. In
order to get there, we've also been extolling the virtues of functional
programming in general, and often cited Ocaml as an example of how you
don't have to sacrifice low-level performance.

We feel that the ongoing paradigm shift towards multicore architectures
is really helping our cause. There is much discussion about how to get
all those legacy apps to work and scale on new hardware, and the
advantages of functional/declarative programming are becoming more
obvious.

Erlang is very strong in the area of concurrency, distribution and
fault-tolerance, but fairly weak when sequential performance is of the
essence (especially number crunching). When Erlang performance isn't
enough, we usually jump into C-routines linked into the Erlang runtime,
with all the problems associated with that. Often, instead of risking
system integrity, we live with the performance we can get out of Erlang.
It would be nice if we could present Ocaml as a safe (and productive!)
driver environment for things like parsing text-based protocols,
numerically intensive tasks, and complex sequential algorithms.

I've noticed that there have been some discussions about concurrency in
Ocaml. From an Ocaml perspective, this binding could be a way to use
Ocaml in distributed systems, where Erlang is used as a "systems glue"
for supervision, load balancing, replication, etc.

Idea:

I'd like to explore the idea of running an Ocaml runtime in Erlang's
memory space. Both languages are garbage-collected, and Erlang's
linked-in driver interface allows for "drivers" that use their own
threads. We could target only the multi-processor variant of Erlang,
where this sort of cooperation becomes slightly easier.

For a looser connection, Erlang's distribution protocol is documented,
and allows for "C-nodes" (non-Erlang nodes) to connect to an Erlang
cluster over TCP. One could actually start with talking via regular
pipes, using a common serialization format, and then gradually making a
tighter and tigher connection.


I will make no false promises, like "if we do this, Ericsson will use
it". I have no money to offer anyone, and we who have started looking at
this on the erlang side have fairly little time to spend on it. Business
as usual, in other words: no time, no money - just an idea that might be
fun to explore.

What say ye? Do you think it's doable? Would any of you be willing to
assist, or offer advice?


The Erlang docs have an Interoperability Tutorial:
http://www.erlang.org/doc/tutorial/part_frame.html

The Erlang Term serialization format, the Erlang Port Mapper Daemon
protocol, and the Distributed Erlang protocol are documented in a
slightly more obscure location. Download the source from
http://www.erlang.org/download.html and read the text file
otp_src_R11B-5/erts/emulator/internal_doc/erl_ext_dist.txt 

If you feel that this is OT for the caml list, you can backmail me.

Regards,
Ulf Wiger
Senior software architect
Ericsson

[-- Attachment #2: Type: text/html, Size: 4891 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Joel Reymont]

My biggest issue with OCaml is building shared libraries.

I tried to build a shared library for use with Ruby once and failed  
miserably.

On Jun 21, 2007, at 10:39 AM, Ulf Wiger (TN/EAB) wrote:

> I'd like to explore the idea of running an Ocaml runtime in Erlang's
> memory space. Both languages are garbage-collected, and Erlang's
> linked-in driver interface allows for "drivers" that use their own
> threads. We could target only the multi-processor variant of Erlang,
> where this sort of cooperation becomes slightly easier.
>
--
http://topdog.cc      - EasyLanguage to C# translator
http://wagerlabs.com  - Blog

Re: [Caml-list] ocaml dll in an Erlang runtime

[Matthieu Dubuget]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

2007/6/21, Joel Reymont <joelr1@gmail.com>:
>
> My biggest issue with OCaml is building shared libraries.
>
> I tried to build a shared library for use with Ruby once and failed
> miserably.


Could you please elaborate about this? Maybe not on this thread.

I ask this, because almost all my OCaml code is use as shared libraries.
Most of the time, this is on Windows (but compilation is a lot simpler on
unix).
They are called from LabVIEW, Java, C...

The only problem I faced is that I have to avoid Thread module.

Salutations


Matt

[-- Attachment #2: Type: text/html, Size: 828 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Joel Reymont]

http://tinyurl.com/yrjryv

On Jun 21, 2007, at 11:15 AM, Matthieu Dubuget wrote:

> 2007/6/21, Joel Reymont <joelr1@gmail.com>: My biggest issue with  
> OCaml is building shared libraries.
>
> I tried to build a shared library for use with Ruby once and failed
> miserably.
>
> Could you please elaborate about this? Maybe not on this thread.

--
http://topdog.cc      - EasyLanguage to C# translator
http://wagerlabs.com  - Blog

RE: [Caml-list] ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

If you can run multiple instances of ocaml dlls in the same memory
space, this doesn't have to be such a big deal.
 
To clarify, a "driver" in Erlang is instantiated using the
open_port(Cmd) function. This initiates a driver context, and the number
of available file descriptors limits how many instances you can open. It
becomes problematic if the code is makes use of global variables.
 
But even if one can only have one instance of an OCaml driver, this
could be useful. You can open a named port, which can be accessed by any
erlang process.
 
BR,
Ulf W


________________________________

	From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Matthieu Dubuget
	Sent: den 21 juni 2007 12:16
	To: Joel Reymont
	Cc: caml-list@yquem.inria.fr
	Subject: Re: [Caml-list] ocaml dll in an Erlang runtime
	
	


	2007/6/21, Joel Reymont <joelr1@gmail.com>: 

		My biggest issue with OCaml is building shared
libraries.
		
		I tried to build a shared library for use with Ruby once
and failed
		miserably.


	Could you please elaborate about this? Maybe not on this thread.

	
	I ask this, because almost all my OCaml code is use as shared
libraries.
	Most of the time, this is on Windows (but compilation is a lot
simpler on unix).
	They are called from LabVIEW, Java, C...
	
	The only problem I faced is that I have to avoid Thread module. 
	
	Salutations
	
	
	Matt
	


[-- Attachment #2: Type: text/html, Size: 3077 bytes --]

RE: [Caml-list] ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

Ok, the problem was building a dynamically linked 
library? The patch seems to work, but offer some 
slowdown.

You _can_ link drivers statically into the erlang VM,
which is how it had to be done in the olden days. 
For prototyping, this should be perfectly adequate.

Today, one normally uses erl_ddll module to dynamically 
load/unload libs, since it's much more convenient.

BR,
Ulf W

> -----Original Message-----
> From: caml-list-bounces@yquem.inria.fr 
> [mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Joel Reymont
> Sent: den 21 juni 2007 12:29
> To: Matthieu Dubuget
> Cc: caml-list@yquem.inria.fr
> Subject: Re: [Caml-list] ocaml dll in an Erlang runtime
> 
> http://tinyurl.com/yrjryv
> 
> On Jun 21, 2007, at 11:15 AM, Matthieu Dubuget wrote:
> 
> > 2007/6/21, Joel Reymont <joelr1@gmail.com>: My biggest issue with 
> > OCaml is building shared libraries.
> >
> > I tried to build a shared library for use with Ruby once and failed 
> > miserably.
> >
> > Could you please elaborate about this? Maybe not on this thread.
> 
> --
> http://topdog.cc      - EasyLanguage to C# translator
> http://wagerlabs.com  - Blog
> 
> 
> 
> 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 

Re: [Caml-list] ocaml dll in an Erlang runtime

[Jon Harrop]

On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> 2007/6/21, Joel Reymont <joelr1@gmail.com>:
> > I tried to build a shared library for use with Ruby once and failed
> > miserably.
>
> Could you please elaborate about this? Maybe not on this thread.
>
> I ask this, because almost all my OCaml code is use as shared libraries...

I think a lot of people (myself included) would benefit enormously if you 
could explain in words of one syllable exactly how you can compile an OCaml 
program into a DLL (.so on Linux) and call it from C.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e

Re: [Caml-list] ocaml dll in an Erlang runtime

[Matthieu Dubuget]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

2007/6/21, Jon Harrop <jon@ffconsultancy.com>:
>
> On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> > 2007/6/21, Joel Reymont <joelr1@gmail.com>:
> > > I tried to build a shared library for use with Ruby once and failed
> > > miserably.
> >
> > Could you please elaborate about this? Maybe not on this thread.
> >
> > I ask this, because almost all my OCaml code is use as shared
> libraries...
>
> I think a lot of people (myself included) would benefit enormously if you
> could explain in words of one syllable exactly how you can compile an
> OCaml
> program into a DLL (.so on Linux) and call it from C.



Not an  OCaml "program". I simply write C DLLs embedding my Caml code as
described in
18.7.5  Embedding the Caml code in the C code
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#htoc238

Nothing automatic. I manually write all C functions, have them call OCaml
callbacks, etc.
If this is actually what you have in mind, I can write and post one
minimalistic example.

It is possible to have a tool to turn one OCaml library (CMA/CMXA) into one
shared library.
See ODLL, from N. Canasse in the hump.

Salutations

Matt

[-- Attachment #2: Type: text/html, Size: 1697 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Pablo Polvorin]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

just my 2c,
a couple of weeks ago, i posted a little about the path that i followed  to
make a shared library with ocaml code, with links to readings that i had
found useful to do so

http://caml.inria.fr/pub/ml-archives/caml-list/2007/03/72f8409732a3aeb7a9d449c438bbff0e.fr.html
As Matthieu, nothing automatic.

2007/6/21, Matthieu Dubuget <matthieu.dubuget@gmail.com>:
>
>
>
> 2007/6/21, Jon Harrop <jon@ffconsultancy.com>:
> >
> > On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> > > 2007/6/21, Joel Reymont <joelr1@gmail.com>:
> > > > I tried to build a shared library for use with Ruby once and failed
> > > > miserably.
> > >
> > > Could you please elaborate about this? Maybe not on this thread.
> > >
> > > I ask this, because almost all my OCaml code is use as shared
> > libraries...
> >
> > I think a lot of people (myself included) would benefit enormously if
> > you
> > could explain in words of one syllable exactly how you can compile an
> > OCaml
> > program into a DLL (.so on Linux) and call it from C.
>
>
>
> Not an  OCaml "program". I simply write C DLLs embedding my Caml code as
> described in
> 18.7.5  Embedding the Caml code in the C codehttp://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#htoc238
>
>
> Nothing automatic. I manually write all C functions, have them call OCaml
> callbacks, etc.
> If this is actually what you have in mind, I can write and post one
> minimalistic example.
>
> It is possible to have a tool to turn one OCaml library (CMA/CMXA) into
> one shared library.
> See ODLL, from N. Canasse in the hump.
>
> Salutations
>
> Matt
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


-- 
Pablo Polvorin

[-- Attachment #2: Type: text/html, Size: 3639 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Pablo Polvorin]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

ups, i missed the Joel's link, sorry for the duplicate


2007/6/21, Joel Reymont <joelr1@gmail.com>:
>
> http://tinyurl.com/yrjryv
>
> On Jun 21, 2007, at 11:15 AM, Matthieu Dubuget wrote:
>
> > 2007/6/21, Joel Reymont <joelr1@gmail.com>: My biggest issue with
> > OCaml is building shared libraries.
> >
> > I tried to build a shared library for use with Ruby once and failed
> > miserably.
> >
> > Could you please elaborate about this? Maybe not on this thread.
>
> --
> http://topdog.cc      - EasyLanguage to C# translator
> http://wagerlabs.com  - Blog
>
>
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
Pablo Polvorin

[-- Attachment #2: Type: text/html, Size: 1633 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Xavier Leroy]

> Would any of you be interested in prototyping a semi-tight coupling
> between Erlang and OCaml? [...] Do you think it's doable?

I haven't looked closely at the Erlang interop facilities, but I think
it is doable.  Here are some remarks based on previous
interoperability experiences with Caml.

The first step is to find a good mapping between data structures of
the two languages.  When both are statically typed, this can be
difficult as both type systems try to impose their views.
When at least one of the languages is dynamically typed, it's easier.

One approach is to define a Caml datatype that reflects the
"universal" type of the dynamically-typed language, e.g. S-exprs in
the case of Lisp, and provide low-level interface functions to
exchange values of this type.

Conversions between this Caml representation of the universal type and
regular Caml data structures can be written manually in Caml, or maybe
automatically generated in the style of Markus Mottl's Sexplib tool
or Jeremy Yallop's Deriving mechanism.

Function values can be difficult to exchange in both directions.  It
might be possible to encapsulate Erlang functions as an abstract Caml
type, with an appropriate "apply" primitive.  I don't know if this can
be made to work in the other direction, e.g. encapsulate Caml
functions as some opaque thing on the Erlang side.  At any rate, for
many applications, exchange of first-order data structures can be
enough.

If the Caml code and the Erlang code live in the same address space,
the actual exchange of data can be done through the C interfaces of
both languages.  This is what we did for the Caml/Java interface,
going through the Java Native Interface and OCaml's C interface.
The two GC can be made to cooperate.  However, data cycles that spawn
the two heaps will never be garbage-collected.

As others mentioned, it is possible to encapsulate Caml code and the
Caml runtime system as a DLL, at least for x86 under Linux and Windows.
For the Caml/Java interface, we used the reverse embedding: the Caml
code would link with the Java runtime system (as a library), which
would then load the Java code.

Apparently, Erlang makes it possible to communicate between separate
processes using byte streams.  This is an original feature that could
significantly simplify the interface: the Caml side could be written
entirely in Caml, bypassing low-level C interface code.

I guess that's all I can say at this point, but feel free to ask
questions.

- Xavier Leroy

Re: [Caml-list] ocaml dll in an Erlang runtime

[Dmitry Bely]

On 6/21/07, Jon Harrop <jon@ffconsultancy.com> wrote:

> I think a lot of people (myself included) would benefit enormously if you
> could explain in words of one syllable exactly how you can compile an OCaml
> program into a DLL (.so on Linux) and call it from C.

If COM interface is OK for you and your target platform is Windows,
the answer is simple: Camlidl. BTW, .Net framework supports COM
components almost natively, so you'll get F# <-> Ocaml interaction for
free :)

- Dmitry Bely

Re: [Caml-list] ocaml dll in an Erlang runtime

[Serge Aleynikov]

While using serialized streams of data between processes is the easiest 
interoperability approach it is also the slowest of the two supported by 
Erlang run-time.  In the second approach that uses the same address 
space Erlang maintains a pool of OS threads separate from the ones 
executing Erlang byte-code that can be used to make asynchronous 
blocking calls of C functions.  If this model is used as far as I 
understand separate Caml run-times would have to be initialized per 
pooled thread managed by Erlang.  Otherwise garbage collection on the 
Caml side (that uses a single mutex) would block all pooled OS threads 
currently executing Caml closures while being garbage collected that 
would penalize performance.  Is this a feasible approach?  Would it lead 
to too much of memory overhead?  (Erlang doesn't have the same issue 
because user-level light-weight processes don't share heaps and garbage 
collection happens on a light-weight process level without stalling 
other processes).

Serge


Xavier Leroy wrote:
>> Would any of you be interested in prototyping a semi-tight coupling
>> between Erlang and OCaml? [...] Do you think it's doable?
> 
> I haven't looked closely at the Erlang interop facilities, but I think
> it is doable.  Here are some remarks based on previous
> interoperability experiences with Caml.
> 
> The first step is to find a good mapping between data structures of
> the two languages.  When both are statically typed, this can be
> difficult as both type systems try to impose their views.
> When at least one of the languages is dynamically typed, it's easier.
> 
> One approach is to define a Caml datatype that reflects the
> "universal" type of the dynamically-typed language, e.g. S-exprs in
> the case of Lisp, and provide low-level interface functions to
> exchange values of this type.
> 
> Conversions between this Caml representation of the universal type and
> regular Caml data structures can be written manually in Caml, or maybe
> automatically generated in the style of Markus Mottl's Sexplib tool
> or Jeremy Yallop's Deriving mechanism.
> 
> Function values can be difficult to exchange in both directions.  It
> might be possible to encapsulate Erlang functions as an abstract Caml
> type, with an appropriate "apply" primitive.  I don't know if this can
> be made to work in the other direction, e.g. encapsulate Caml
> functions as some opaque thing on the Erlang side.  At any rate, for
> many applications, exchange of first-order data structures can be
> enough.
> 
> If the Caml code and the Erlang code live in the same address space,
> the actual exchange of data can be done through the C interfaces of
> both languages.  This is what we did for the Caml/Java interface,
> going through the Java Native Interface and OCaml's C interface.
> The two GC can be made to cooperate.  However, data cycles that spawn
> the two heaps will never be garbage-collected.
> 
> As others mentioned, it is possible to encapsulate Caml code and the
> Caml runtime system as a DLL, at least for x86 under Linux and Windows.
> For the Caml/Java interface, we used the reverse embedding: the Caml
> code would link with the Java runtime system (as a library), which
> would then load the Java code.
> 
> Apparently, Erlang makes it possible to communicate between separate
> processes using byte streams.  This is an original feature that could
> significantly simplify the interface: the Caml side could be written
> entirely in Caml, bypassing low-level C interface code.
> 
> I guess that's all I can say at this point, but feel free to ask
> questions.
> 
> - Xavier Leroy
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 

Re: [Caml-list] ocaml dll in an Erlang runtime

[Jon Harrop]

On Thursday 21 June 2007 10:39:54 Ulf Wiger (TN/EAB) wrote:
> Would any of you be interested in prototyping a semi-tight coupling
> between Erlang and OCaml?

Perhaps a tighter coupling between OCaml and Haskell would also be of 
interest?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e

RE: [Caml-list] ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

Thank you for your comments, Xavier.

(It does seem as if some prototyping will take
place in the near future.)

Xavier Leroy wrote:

> One approach is to define a Caml datatype that reflects the 
> "universal" type of the dynamically-typed language, e.g. 
> S-exprs in the case of Lisp, and provide low-level interface 
> functions to exchange values of this type.

One might also have a look at the Erlang binary type. (:

Actually, this is not as corny as it sounds.
You could pass a parsing declaration in the form
of Erlang bit syntax expressions, and compile an
encode/decode module on the fly on the Erlang side.

Examples of the bit syntax can be found here:
http://www.erlang.org//doc/programming_examples/bit_syntax.html#4

And there's a (currently experimental) new version
of binary handling called "binary comprehensions"
(c.f. list comprehensions, but on bits or bytes)

http://user.it.uu.se/~pergu/papers/erlang05.pdf

Here's a very small example of decoding with the
help of binary comprehensions, from above paper:

uudecode(UUencodedBin) ->
<<(X-32):6 || X <<- UUencodedBin, 32=<X, X=<95>>.

The native code compiler in Erlang understands 
the bit syntax and optimizes the matching, so working
directly on binary objects in Erlang is both reasonably
expressive and quite efficient.

Large binaries are reference-counted in Erlang,
and passed by pointer reference between processes
(under the covers - conceptually, they're copied).


> Function values can be difficult to exchange in both 
> directions.  It might be possible to encapsulate Erlang 
> functions as an abstract Caml type, with an appropriate 
> "apply" primitive.  I don't know if this can be made to work 
> in the other direction, e.g. encapsulate Caml functions as 
> some opaque thing on the Erlang side.  At any rate, for many 
> applications, exchange of first-order data structures can
> be enough.

Function values are only passed by reference between 
erlang nodes, so evaluating them only works if the 
right module is loaded on the remote end (a hash value
is passed along to ensure that the wrong function isn't
evaluated.) Even if it can't be evaluated, it can of 
course be passed along as an opaque value.

If this representation were used when communicating,
it might be possible (but perhaps quite strange) to 
represent OCaml functions in the same way, such that 
they cannot be confused with Erlang functions.

This would make it possible to pass function values
by reference between the two environments, but each
reference would only actually be callable in its native
environment.

In order to send an OCaml function value through the 
Erlang environment to an OCaml recipient, I guess an
appropriate encapsulation is needed, which would look
like a binary object to the Erlang side.

BR,
Ulf W

RE: [Caml-list] ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

I hadn't made up my mind, but now I've created 
a google code project:

http://code.google.com/p/erlocaml/

and a google discussion group

http://groups.google.com/group/erlocaml-discuss


Let me know if you want to be added as member in
the group or project.

I have no particular structure in mind, but figure
that anyone competent enough to slap together 
useful code for this project can be trusted to 
submit it in a reasonable way. (:

Every google code project has a wiki. We could make
use of that as well. Again, I have no particular 
structure in mind.

BR,
Ulf W

 

> -----Original Message-----
> From: Jeff Henrikson [mailto:jehenrik@yahoo.com] 
> Sent: den 27 juni 2007 21:40
> To: Ulf Wiger (TN/EAB)
> Subject: Re: [Caml-list] ocaml dll in an Erlang runtime
> 
> I have been thinking about such a bridge and what it would be 
> good for. 
> I thought of something.  So I'd be interested in following 
> this conversation once it leaves caml-list.  Not sure if you 
> had in mind a mailing list or sourceforge page or whatever.
> 
> Regards,
> 
> 
> Jeff Henrikson
> 
> 
> On Thu, 21 Jun 2007 11:39:54 +0200, "Ulf Wiger (TN/EAB)"
> <ulf.wiger@ericsson.com> said:
> > 
> > Would any of you be interested in prototyping a semi-tight coupling 
> > between Erlang and OCaml?
> > 
> > A small group of Erlang programmers have started tossing the idea 
> > around, and with sufficient lack of detailed knowledge, it seems 
> > pretty reasonable. (:
> > 
> > 
> > Motivation:
> > 
> > We've been using Erlang in commercial products for over 10 
> years now, 
> > and it's taken about that long to get into a position where we're 
> > considered a viable player for mission-critical product 
> development. 
> > In order to get there, we've also been extolling the virtues of 
> > functional programming in general, and often cited Ocaml as 
> an example 
> > of how you don't have to sacrifice low-level performance.
> > 
> > We feel that the ongoing paradigm shift towards multicore 
> > architectures is really helping our cause. There is much discussion 
> > about how to get all those legacy apps to work and scale on new 
> > hardware, and the advantages of functional/declarative 
> programming are 
> > becoming more obvious.
> > 
> > Erlang is very strong in the area of concurrency, distribution and 
> > fault-tolerance, but fairly weak when sequential 
> performance is of the 
> > essence (especially number crunching). When Erlang 
> performance isn't 
> > enough, we usually jump into C-routines linked into the Erlang 
> > runtime, with all the problems associated with that. Often, 
> instead of 
> > risking system integrity, we live with the performance we 
> can get out of Erlang.
> > It would be nice if we could present Ocaml as a safe (and 
> productive!) 
> > driver environment for things like parsing text-based protocols, 
> > numerically intensive tasks, and complex sequential algorithms.
> > 
> > I've noticed that there have been some discussions about 
> concurrency 
> > in Ocaml. From an Ocaml perspective, this binding could be a way to 
> > use Ocaml in distributed systems, where Erlang is used as a 
> "systems glue"
> > for supervision, load balancing, replication, etc.
> > 
> > Idea:
> > 
> > I'd like to explore the idea of running an Ocaml runtime in 
> Erlang's 
> > memory space. Both languages are garbage-collected, and Erlang's 
> > linked-in driver interface allows for "drivers" that use their own 
> > threads. We could target only the multi-processor variant 
> of Erlang, 
> > where this sort of cooperation becomes slightly easier.
> > 
> > For a looser connection, Erlang's distribution protocol is 
> documented, 
> > and allows for "C-nodes" (non-Erlang nodes) to connect to an Erlang 
> > cluster over TCP. One could actually start with talking via regular 
> > pipes, using a common serialization format, and then 
> gradually making 
> > a tighter and tigher connection.
> > 
> > 
> > I will make no false promises, like "if we do this, 
> Ericsson will use 
> > it". I have no money to offer anyone, and we who have 
> started looking 
> > at this on the erlang side have fairly little time to spend on it. 
> > Business as usual, in other words: no time, no money - just an idea 
> > that might be fun to explore.
> > 
> > What say ye? Do you think it's doable? Would any of you be 
> willing to 
> > assist, or offer advice?
> > 
> > 
> > The Erlang docs have an Interoperability Tutorial:
> > http://www.erlang.org/doc/tutorial/part_frame.html
> > 
> > The Erlang Term serialization format, the Erlang Port Mapper Daemon 
> > protocol, and the Distributed Erlang protocol are documented in a 
> > slightly more obscure location. Download the source from 
> > http://www.erlang.org/download.html and read the text file 
> > otp_src_R11B-5/erts/emulator/internal_doc/erl_ext_dist.txt
> > 
> > If you feel that this is OT for the caml list, you can backmail me.
> > 
> > Regards,
> > Ulf Wiger
> > Senior software architect
> > Ericsson
> --
>   Jeff Henrikson
>   jehenrik@jhenrikson.org
> 
> 

Re: [Caml-list] ocaml dll in an Erlang runtime

[Gabriel Kerneis]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Le Wed, 27 Jun 2007 23:07:59 +0200, "Ulf Wiger (TN/EAB)"
<ulf.wiger@ericsson.com> a écrit :
> 
> 
> I hadn't made up my mind, but now I've created 
> a google code project:
> 
> http://code.google.com/p/erlocaml/
> 
> and a google discussion group
> 
> http://groups.google.com/group/erlocaml-discuss
> 
> 
> Let me know if you want to be added as member in
> the group or project.

Although I've got lots of things to do those days, this project sounds
amazing to me and I'd like to contribute - maybe in a month or two. I
learnt Erlang a month ago and have practiced Ocaml for a few years,
now.

Regards,
-- 
Gabriel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] ocaml dll in an Erlang runtime

[Gabriel Kerneis]

[-- Attachment #1: Type: text/plain, Size: 79 bytes --]

Sorry for the noise, this was supposed to be a private reply.

-- 
Gabriel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]