Hello
Here is the latest Caml Weekly News, for the week of November 27 to December 04, 2007.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/ff60b99b32dd2326#4d342ba3bfa6a5da
Daniel de Rauglaudre announced:Yet another release of Camlp5: 5.04 A new feature is added: full backtracking 1/ new syntax to create backtracking parsers introduced by "bparser". 2/ ability to change the parsing algorithm of extensible grammars. Also, some bug fixes in installation, improvements of documentation pages, other small bug fixes. See the Camlp5 documentation and the file CHANGES. Download the sources and the documentation at: http://pauillac.inria.fr/~ddr/camlp5/
Acknowledging that there is a number of people interested in interfacing python and caml, I just put up a website from which our bugfixed and extended variant of Art Yerkes' "pycaml" module can be downloaded: http://nmag.soton.ac.uk/tf/pycaml.html (Note ad Debian developers: this fixes some major memory management bugs that can cause crashes in the original pycaml module which is in Debian, so, ideally, our variant should eventually supersede the code that is at present in that Debian package. Interface-wise, our module provides more than the original one, but I think I also had to remove two or three very obscure functions.)
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/b364c5890ed1fbc2#a4098c82b0570bc0
Gerd Stolpmann announced:
Wink Technologies, Inc., the makers of the soon-to-be-famous people
search engine (http://wink.com), have just released another OCaml
library, this time for using the ICE protocol.
This is really an exciting contribution, as it directly addresses the
problem of language interoperability. Hydro opens the door to use O'Caml
besides other languages in the same company! We at Wink use Hydro
already for communication between O'Caml, C++, and Java.
Note that we don't have any relationship with ZeroC, the inventors of
ICE.
--------------------------------------------------------
From the README:
--------------------------------------------------------
Hydro is an independent implementation of ICE, the object-oriented RPC
protocol by ZeroC, for the O'Caml programming language. This is an
early, not yet complete release, but the code is already stable and
usable. For the restrictions of this release, see below.
Hydro (like ICE) allows you to bridge language barriers by letting
components written in different programming languages communicate with
each other. ZeroC's ICE product currently includes implementations for C
++, Java, C#, Python, Ruby, VB, and PHP. Hydro adds support for O'Caml.
The ICE protocol is rich enough to make the representation of the data
to communicate easy and convenient to use, and adopts an object-oriented
type system. ZeroC sees ICE as a superior successor to CORBA.
Hydro includes a runtime, and a generator called hydrogen. The runtime
is fully asynchronous, based on Ocamlnet's event queues. The generator
is used to create a thin layer on top of the runtime that maps abstract
Hydro types to specific O'Caml types. The Hydro engine therefore
appears to the programmer as if it was typed using the input IDL file.
Unlike the generators shipped by ZeroC, hydrogen does not create
marshalling code -- we see this as the task of the runtime and not of
the language mapping layer. Because of this design decision we have high
confidence in the correctness of the generator.
Although we want Hydro to be an implementation whose protocol is fully
compatible with ICE and that can process all its IDL files, we take some
freedom to deviate from what is described in ZeroC's "ICE manual". ICE
was designed with mainstream object-oriented languages in mind, and
therefore lacks many of the advanced constructs available in O'Caml
(variants, for example). Conversely, ICE includes constructs such as
hierarchical exceptions and downcasts which do not exist in O'Caml (and
for good reason!). To deal with the "impedance mismatch," we
implemented emulations for these concepts. On the other hand, O'Caml
offers advanced features which ought to be exploited by a good
implementation. For example, in O'Caml, asynchronous networking code is
quite natural, so we have chosen to make this the default style. So
while Hydro is quite straightforward, the O'Caml programmer should not
expect a design which is a perfect one-to-one translation of what ZeroC
describes.
*** Features ***
* Support for clients and proxies
* The whole ICE type system is implemented, and can be marshalled.
This includes graphs of objects.
* The whole ICE type system can be mapped to O'Caml types. The
mapping is quite flexible and configurable, e.g. you can choose
whether you prefer arrays or lists as representations of ICE
sequences. Where necessary, the properties of the ICE type
system are emulated. For example, hydrogen generates special
code for downcasts of objects.
* IDL files are dynamically represented at runtime
* The runtime supports both asynchronous and synchronous method
invocation
* The runtime can be integrated with other libraries that also
base on Ocamlnet's event queues, e.g. with Ocamlnet's HTTP
clients, or SunRPC.
* Fully automatic connection management
* The generated code is properly indented
* Liberal license conditions
*** Restrictions ***
* Hydro does not support servers for now (this will follow soon,
and is now priority #1). The support for clients is quite
adequate.
* Hydro only supports twoway calls over TCP for now
* Hydro does not support separate compilation (i.e. you cannot
split an .ice file into several parts, hydrogen every part
alone, and then merge them later). This is a fundamental
restriction we'll never be able to improve.
* There is no support for Slice checksums
* There is no support for checked proxy casts (to will follow
soon)
* There is no support for configuration files
* There is no support for stringified proxies and endpoints
* The runtime and the generated language mapping layer are both
reentrant. However, there is no specific support for
multi-threaded programming beyond this
* There is no support for compression
* Except of calling the locator service of IceGrid, there is no
support for add-on technologies like IceGrid, Freeze, etc. We
have some interest in IceGrid, so this may also follow at some
time.
[... rest of README omitted...]
--------------------------------------------------------
Download, and documentation
--------------------------------------------------------
Download link: http://oss.wink.com/hydro/
Manual: http://oss.wink.com/hydro/hydro-0.5/doc/html/index.html
A GODI package godi-hydro exists.
For general information about ICE, see ZeroC's homepage:
http://zeroc.com
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/8e9f7c3618c06913#f0856d2923ce223b
Raj Bandyopadhyay said and Xavier Leroy answered:> The issue for me is that I need to be able to modify mutable objects in > OCaml (eg. array-modification in-place) from both OCaml and C/Python. > However, the OCaml GC moves things around while the execution is in > C/Python and this crashes my program. > The Python GC is very simple, based on reference counts, hence (I think) > it suffices just to make sure that any object has a refcount > 0 to keep > the Python GC off. > Well, I decided to go ahead and hack some C code to build a custom OCaml > compiler. These are the steps I followed: That's a classic bootstrapping issue, and "make bootstrap; make all" might solve it. But you are on the wrong tracks anyway. What your C code does is disable the compactor, which runs from time to time to eliminate fragmentation in the major heap by moving objects around. You can disable it by using Gc.set with the "max_overhead" field set to a suitably high value, as documented in the Gc module. There is no need to hack the run-time system. However, what you will never be able to disable is the minor collector, which moves blocks from the minor heap to the major heap. The reason it cannot be disabled is that the minor heap is of fixed size, so if it gets full and the minor GC isn't executed to empty it, your program cannot proceed. You see, the Caml garbage collector is like a god from ancient mythology: mighty, but very irritable. If you mess with it, it'll make you suffer in surprising ways. The solution to your problem is to play nice with the Caml GC: on the C/Python side, handle Caml "values" through an indirection via a malloc-ed block, and register the Caml value contained within this block with the Caml GC using register_global_roots(), as Thomas Fischbacher outlined. Members of this list can probably point you to some existing C/Caml bindings that does just this and that you could use as inspiration.Raj Bandyopadhyay then said and Thomas Fischbacher answered:
> I would highly appreciate any pointers to existing code that does the > 'register_global_roots()' thing. Examples would definitely help me code > it correctly. I would suggest you download the nsim sources from: http://nmag.soton.ac.uk/nmag/current/download/nmag-0.1-core.tar.gz and study the nsim/mpi_petsc/petsc.ml and petsc_stubs.c files. (Actually, the code quality of these functions varies a bit. Most of the module is reasonably good style, but not everything.) Basically, this is an OCaml interface to the PETSc "parallel sparse linear algebra" library. (It also assimilated Xavier's old MPI interface for OCaml. Had to do that, sorry.) Of particular interest should be the function with_petsc_vector_as_bigarray, which will take an opaque petsc vector and a function that takes a double-float bigarray and calls that function from C in such a way that it can address the Petsc vector as if it were a bigarray. Also, you might be interested in the "sundials" module, which interfaces the CVODE time integrator from libsundials to OCaml.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/4889bce2f6aacee2#7ffda7cb9f8d1a1d
Eric Merritt asked and Sylvain Le Gall answered:
> I have spent quite a bit of time digging around for this on the net
> with now luck. We have a pretty simple ocaml app for which we would
> like to distribute an executable binary. For the most part this works.
> However, we would like to minimize the number of binaries that we are
> forced to distribute. We would also like to avoid any confusion on the
> part of our users around figuring out which version of glibc they are
> using. For example, we would like to avoid distributing a binary for
> each version of glibc available. Its more work for us and has a chance
> of confusing some of the folks using our work. Considering the
> simplicity of our binary it seems like a good solution would be to be
> to just statically link against glibc (our only non-ocaml dependency).
> So it would be great if someone could give me pointers to docs that
> describe how to do this. Extra points if I can easily do this with
> OCamlMakefile. If there is another way to accomplish our goals I am
> more then willing to entertain them, as there are a lot of potential
> problems involved with static linking against glibc.
Other people had already give you some advices on how to achieve a static
link against glibc.
I would like to WARN you against this. I have some pretty bad
experiences with using static glibc in my binaries. It seems to have
something to do with the fact that:
* top bugs of glibc (in BUGS in the orginal tarball
[ **] Closing shared objects in statically linked binaries most of the
times leads to crashes during the dlopen(). Hard to fix.
** is medium severity.
* whatever you will statically linked, you will always have to load
ld-linux.so -- which makes you fall into the top bug of glibc
* you will have to include NSS into your code (so it won't be
possible to use system NSS).
All in all, you could get really strange behavior by using a statically
linked glibc into your code. Of course, this also should not happen...
Garrett Jones also suggested:This setting works for me with OCamlMakefile: LDFLAGS = -Wl,-Bstatic
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/025abd745cc22ff0#2934380d38140f9a
Walid Taha announced:
The Resource-Aware Programming (RAP) research group at Rice University
is seeking qualified doctoral and post-doctoral students. The openings will
support work on a wide range of topics, including the Concoqtion programming
language, physically safe computing, and device drivers. The full descriptions
of these positions can be found at:
http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsGraduate
and http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsPostdoctoral
Funding for these positions is provided by the National Science Foundation
(NSF) and by industrial partners including Intel, LogicBlox, and Schlumberger.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/8ba2204855fc5e46#5aee553df34548e2
Continuing the thread from last week, Xavier Leroy said:
Yes, LLVM is an impressive project and your example demonstrates that
LLVM is very well suited to run-time code generation.
However, I have a point of terminology to make: the language you
implemented is not what is normally called Mini-ML in the literature.
Your language has first-order, second-class functions, while Mini-ML
has higher-order, first-class functions. A runtime code generator for
Mini-ML would be significantly more complex, since it has to deal with
first-class functions either through closure conversion or
defunctionalization, meaning in both cases dynamic allocation and
garbage collection.
Which brings us back to Basile's original question about LLVM and the
Caml garbage collector. The following page suggests that they can
already work together:
http://llvm.org/docs/GarbageCollection.html
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM
If you know of a better way, please let me know.
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.