ocaml dll in an Erlang runtime

[Ulf Wiger (TN/EAB)]

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

_______________________________________________
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

[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





_______________________________________________
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

[Matthieu Dubuget]

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

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

_______________________________________________
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

[Joel Reymont]

http://tinyurl.com/yrjryv

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

> 2007/6/21, Joel Reymont <joelr1@...>: 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

[Ulf Wiger (TN/EAB)]

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@... [mailto:caml-list-bounces@...] On Behalf Of Matthieu Dubuget
Sent: den 21 juni 2007 12:16
To: Joel Reymont
Cc: caml-list@...
Subject: Re: [Caml-list] ocaml dll in an Erlang runtime

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

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

_______________________________________________
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

[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@...
> [mailto:caml-list-bounces@...] On Behalf Of Joel Reymont
> Sent: den 21 juni 2007 12:29
> To: Matthieu Dubuget
> Cc: caml-list@...
> 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@...>: 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
>

_______________________________________________
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

[Jon Harrop]

On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> 2007/6/21, Joel Reymont <joelr1@...>:
> > 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

_______________________________________________
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

[Matthieu Dubuget]

2007/6/21, Jon Harrop <jon@...>:

On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> 2007/6/21, Joel Reymont <joelr1@...>:
> > 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

_______________________________________________
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]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...>:

2007/6/21, Jon Harrop <jon@...>:

On Thursday 21 June 2007 11:15:39 Matthieu Dubuget wrote:
> 2007/6/21, Joel Reymont <joelr1@...>:
> > 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

_______________________________________________
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
_______________________________________________
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]

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

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

http://tinyurl.com/yrjryv

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

> 2007/6/21, Joel Reymont <joelr1@... >: 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
_______________________________________________
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

[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

_______________________________________________
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

[Dmitry Bely-2]

On 6/21/07, Jon Harrop <jon@...> 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

_______________________________________________
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

[Serge Aleynikov-2]

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
>

_______________________________________________
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

[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

_______________________________________________
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

[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

_______________________________________________
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

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

_______________________________________________
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

[Gabriel Kerneis]

Le Wed, 27 Jun 2007 23:07:59 +0200, "Ulf Wiger (TN/EAB)"
<ulf.wiger@...> 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


_______________________________________________
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

[Gabriel Kerneis]

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

--
Gabriel


_______________________________________________
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