[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Dec 4 02:50:21 PST 2007
Hello,
Here is the latest Caml Weekly News, for the week of November 27 to
December 04, 2007.
1) Camlp5 release 5.04 - yet another release of camlp5...
2) Python and Caml
3) Wink releases Hydro - an ICE implementation
4) Disabling the OCaml garbage collector
5) Is there a way to statically link an ocaml app compiled to native
code against glibc?
6) Doctoral and Post-doctoral openings at Rice
7) LLVM: A native-code compiler for MiniML in ~100LOC
========================================================================
1) Camlp5 release 5.04 - yet another release of camlp5...
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/>
========================================================================
2) Python and Caml
Archive: <http://groups.google.com/group/fa.caml/tree/browse_frm/
thread/8e9f7c3618c06913/ec95a14d05add01e?rnum=11&_done=%2Fgroup%
2Ffa.caml%2Fbrowse_frm%2Fthread%2F8e9f7c3618c06913%
3F#doc_96437ac1bbd4db89>
------------------------------------------------------------------------
** Deep in this thread, Thomas Fischbacher announced:
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.)
========================================================================
3) Wink releases Hydro - an ICE implementation
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>
========================================================================
4) Disabling the OCaml garbage collector
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.
========================================================================
5) Is there a way to statically link an ocaml app compiled to native
code against glibc?
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
========================================================================
6) Doctoral and Post-doctoral openings at Rice
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.
========================================================================
7) LLVM: A native-code compiler for MiniML in ~100LOC
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>
========================================================================
Using folding to read the cwn in vim 6+
------------------------------------------------------------------------
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.
========================================================================
Old cwn
------------------------------------------------------------------------
If you happen to miss a CWN, you can send me a message
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take
a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
========================================================================
--
Alan Schmitt <http://alan.petitepomme.net/>
The hacker: someone who figured things out and made something cool
happen.
.O.
..O
OOO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20071204/5f89f025/attachment.pgp
More information about the caml-news-weekly
mailing list