[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Mar 7 01:47:29 PST 2006
Hello,
Here is the latest Caml Weekly News, for the week of February 28 to
March 07, 2006.
1) Native delimited continuations for bytecode OCaml
2) Toy implementation of Zope's TAL for OCaml
3) ocamlopt on Mac/Intel
4) release of Zenon
5) Looking for pointers regarding integration of OCaml plugins into
OCaml native code
6) Line number for index out of bounds
========================================================================
1) Native delimited continuations for bytecode OCaml
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
3f1bfc0d4bee6607/c6936fd51ad033ba?lnk=raot#c6936fd51ad033ba>
------------------------------------------------------------------------
** Jacques Carette announced:
[Posted for oleg at pobox.com]
This message announces the native implementation of delimited
continuation framework for byte-code OCaml. The framework supports
`static' (shift/reset) and `dynamic' (prompt/control, shift0,
control0) delimited continuation operators with multiple, arbitrarily
typed prompts. The test file testd0.ml is a good example of using
shift/reset in OCaml programs.
The implementation is native: it copies a relevant fragment of the
OCaml interpreter stack (The stack or its fragments are never
inspected however). The implementation is efficient: only the
necessary prefix of the stack is copied. The implementation is
fully integrated with OCaml exceptions: exception handlers may be
captured in delimited continuation (and re-instated when the captured
continuation is installed); exceptions remove the prompts along the
way. The implementation has no typing problems, no bizarre 'a cont
types, and no use for magic. The implementation does no patching to
the OCaml system and is a regular library. If you compile the
top-level (see `make top'), you can use delimited continuation
operators in interactive OCaml sessions.
The library has been tested for OCaml 3.08, 3.09.0, and 3.09.1, on
ia32 Linux and FreeBSD platforms. The current version is 1.6, Feb 7,
2006.
The library is distributed under the MIT license.
<http://pobox.com/~oleg/ftp/packages/caml-shift.tar.gz>
========================================================================
2) Toy implementation of Zope's TAL for OCaml
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
5d154f783267a2c2/94adde2a0780da6d?lnk=raot#94adde2a0780da6d>
------------------------------------------------------------------------
** Bruno De Fraine announced:
I made a toy implementation of Zope's TAL (Template Attribute
Language) for
OCaml, conveniently named 'Octal'. It is built on top of Camlp4 and
Xml-Light.
The purpose of TAL is to have a template that is a valid XML or HTML
document
that already renders like the resulting document.
The approach employed by Octal is to preprocess the TAL template and
produce an
OCaml function that takes the template parameters and that returns the
generated XML document. As such, the template is precompiled into an
evaluated
form and template parameters can be type-checked by OCaml. Octal is
realized as
a Camlp4 quotation.
Source code and a README with more information is available from:
<http://ssel.vub.ac.be/svn-gen/bdefrain/octal/>
========================================================================
3) ocamlopt on Mac/Intel
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
0dc0545a76842394/caa62f340ea258ce?lnk=raot#caa62f340ea258ce>
------------------------------------------------------------------------
** Xavier Leroy announced:
A first port of OCaml to the new Intel Macs, including the native-code
compiler, is now available in the 3.09 bugfix branch of the CVS
repository. Thanks to David Powers for lending an account.
Impatient users can obtain the sources using
cvs -d ':pserver:anoncvs at camlcvs.inria.fr:/caml' co -r release309
ocaml
Technically, this should not go into the bug fix branch, but Mac fans
will never wait until 3.10 is out...
The port required undoing a dubious change in ocamlopt (all platforms)
that I did 3 years ago to support the -ffast-math option. The change
and its reversal affect the compilation of trigonometric and
exponential functions, and are so minor that the reversal should not
break anything, but one never knows. If you're tracking the 3.09
bugfix branch and observe weird behaviours in numerical applications,
please file a bug report asap.
========================================================================
4) release of Zenon
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
412e0f37f9a8b101/60b281082579378e?lnk=raot#60b281082579378e>
------------------------------------------------------------------------
** Damien Doligez announced:
It is my pleasure to announce the release of Zenon, an automatic theorem
prover written in OCaml.
Zenon handles first-order logic with equality. Its most important
feature is
that it outputs the proofs of the theorems, in Coq-checkable form.
This is version 0.4.1, available at <http://focal.inria.fr/zenon/>.
Unfortunately, there is no documentation yet, so this is for the
adventurous spirit.
It is released under the New BSD license.
========================================================================
5) Looking for pointers regarding integration of OCaml plugins into
OCaml native code
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
8a8872782ad82a99/faa91d8abd418d96#faa91d8abd418d96>
------------------------------------------------------------------------
** David MENTRE asked and Basile STARYNKEVITCH answered:
> I would like to extend an OCaml native code application with plugins
> written in OCaml (preferably native code). So, much like the C/OCaml
> interface, I would like to have some dynamically loaded OCaml code
> calling my application core code and vice versa.
>
> From my readings of the caml-list archives, I understand that:
>
> 1/ It is possible to load bytecode code into a bytecode application,
> using the Dynlink module;
>
> 2/ It could be possible to load native code into a native code
> application[1] but Xavier thinks this is no longer possible or
too
> difficult[2]. I haven't be able to find the explanation Xavier is
> refering to. Has anybody a pointer to it? I would like to
understand
> the issue(s).
I'm not an expert on Ocaml's GC, but I believe the issue is the local
roots on the call stack. With bytecode, it is only on the VM stack,
whose organisation is well understood. With native code, the pointers
are on the machine's stack (the one usually used by C), and the Ocaml
generated code contains extra information to describe it (IIRC some
kind of hash tables mapping machine return addresses to stack frame
descriptions).
> 3/ With original OCaml, it is not possible to load a bytecode into a
> native code application but that might be possible with the
> Asmdynlink module of Fabrice Le Fessant[2]. If I remember
correctly
> (can't remember where I read that), the main issue is that native
> and bytecode have not exactly the same memory representation
(thus,
> for example, the GC is different). Is that correct?
I believe it is related to the previous point.
There might be also another possibility. You might consider using
Metaocaml see <http://www.metaocaml.org/> with the following caveats
First and above all, Metaocaml is much less mature than Ocaml is,
and the team of people working on Metaocaml is much smaller. This
means that Metaocaml is really a research prototype, not a full
software product (there is no offense intended in stating this fact).
MetaOcaml is native only on x86 (32 bits). IIRC, it is not native on
x86_64 (aka AMD64) nor on all the other native targets of Ocaml.
IIRC, there is not robust machinery to drop useless code, which is
needed for long-time running programs in MetaOcaml. Basically, what is
missing (both in MetaOcaml & in Ocaml) is the ability to garbage
collect useless code. But this requirement has a major impact on the
compiler, the runtime library and the performance of the GC,
etc... Maybe Ocaml's successor would have the meta-programming
abilities of MetaOcaml and a way to drop useless code, ie a GC
handling machine code (old versions of SML/NJ did have it, and some
CommonLisp implementations have it also). There are also some
theoretical barriers (see all the work on safe module signatures,
mixins, mobility, ....).
I'm not sure that MetaOcaml has the ability to do exactly a module
run-time linking; however, it is able to generate code at runtime
which might be somehow equivalent. It could recieve some description
of the code to generate...
Maybe the easiest way is to stay within the bytecode... Do you really
need the performance of native code? You might also try with
ocamljitrun (but I admit that I don't have much time maintaining it).
** Alessandro Baretta also answered:
> 2/ It could be possible to load native code into a native code
> application[1] but Xavier thinks this is no longer possible or
too
> difficult[2]. I haven't be able to find the explanation Xavier is
> refering to. Has anybody a pointer to it? I would like to
understand
> the issue(s).
Actually, MetaOcaml has most of the machinery needed to do this. I
have recently
released to the MetaOcaml hackers list a patch which actually enables
native
linking of ocamlopt generated code on Linux/x86. I have no clue as to
the level
of support for any other operating system/architecture. I must add that,
although Natdynlink exists in MetaOcaml, it is definitely not a mature
implementation. I had to solve several issues myself before I could
get my
AS/Xcaml to run any bit of a web application in native dynamic mode.
Yet, after
all the bugfixing, I only have a proof-of-concept implementation,
which is not
stable enough for production use. A lot more testing and feedback is
needed the
by the MetaOcamlers to get this feature to work right.
And, by the way, MetaOcaml is really much more stable than its
official "alpha"
status implies. As far as I seen while experimenting with building
the AS/Xcaml,
is that Natdynlink needs more work. The rest seems fairly robust.
========================================================================
6) Line number for index out of bounds
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
190ec2f3c3dbac80/a32ea5687ea4a9c0#a32ea5687ea4a9c0>
------------------------------------------------------------------------
** Andries Hekstra asked and Richard Jones answered:
> Invalid_argument("index out of bounds")
[...]
> Of course, I am very curious in which line number of the program this
> exception occurs.
> Is there any way to get hold of this line number?
This is a real problem with OCaml - it's impossible to get stack
traces of where an exception happens with native code. I'm assuming
you're using native code. I commonly have cases where a program dies
with "exception: Not_found" because I forgot to enclose some List.find
with an appropriate try ... with clause, or made some wrong
assumption. Tracking these down is time-consuming.
Possible workarounds:
* Use bytecode, and before running the program set the environment
variable OCAMLRUNPARAM=b which will print a stack trace.
* Surround every possible array index with a try ... with expression
like this:
try
(* code which accesses the array *)
with
Invalid_argument "index out of bounds" -> assert false
The "assert false" will print the line and character number of the
assertion.
* Hack ocamlopt to be able to print exceptions properly :-)
** Markus Mottl then said:
> * Hack ocamlopt to be able to print exceptions properly :-)
We have already developed a patch for the OCaml-compiler to generate
function
call backtraces for native code programs and submitted it to the
OCaml-bugtracker in the hope to get it included in a future release.
Function
call backtraces are different from stack backtraces, sometimes more,
sometimes
less useful. They are usually sufficient for tracking down the
source of
exceptions.
In case you feel like running a patched runtime, look up issue
0003885 on the
bugtracker, which contains an attachment with the patch for OCaml 3.09:
<http://caml.inria.fr/mantis/view.php?id=3885>
========================================================================
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/>
--
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/20060307/86e80f84/PGP.bin
More information about the caml-news-weekly
mailing list