Hello
Here is the latest Caml Weekly News, for the week of June 12 to 19, 2007.
> I wonder if anyone has thought about or developed a domain-specific > language in OCaml for handling the processing of binary structures? > I was thinking of writing something to make system calls into the Xen > hypervisor. The main problem is that the hypervisor takes & returns > binary structures which have very precise size / alignment > requirements, bitfields, etc. (and the requirements change with > versions of the hypervisor). It sounds like the ideal use for a DSL > to describe the binary structure of each version of each call and > automatically build accessors. I had a play with some code to do this. A write-up of my experiment is here: http://et.redhat.com/~rjones/hvcalls/
We are currently offering a software developper position for a young engineer with good programming skills wanting to work in our research team AOSTE at INRIA-Rocquencourt. SynDEx is written in OCaml and is quite a big software (around 50,000 lines). You can get details about this position on our website: http://www.syndex.org/. Click on the jobs link in the menu on the left. Please send your curriculum and motivation letter to Yves.Sorel@inria.fr
I've added to the Camlp4 wiki a documentation about Camlp4MapGenerator and Camlp4FoldGenerator http://brion.inria.fr/gallium/index.php/Camlp4MapGenerator http://brion.inria.fr/gallium/index.php/Camlp4FoldGenerator
I'm just passing this one along. If interested, contact me and I'll put you in touch. I gather that it requires relocation to Newport in Wales. http://annexia.org/tmp/job%20description%20static%20analysis.pdf
GLCaml (http://glcaml.sourceforge.net), a dynamic cross-platform Ocaml binding for OpenGL and extensions, has been updated to version 20070616. It contains the following changes: * Almost all current OpenGL extensions are now supported, doubling the previous number of supported extensions. * GLCaml should now compile on generic unix, and now works on Solaris. as well as Windows, Linux, and Mac OSX. * It has been re-released under the BSD license. It was previously released under the LGPL. * SDLCaml has a few minor bugfixes incorporated. It remains under the LGPL.
I'm pleased to announce the existence of an experimental branch in OCaml's CVS. Main changes: * Dynamic loading of OCaml code in native code programs, through the Dynlink module. * Simplified dynamic linking of C code under Windows. More info: http://alain.frisch.fr/natdynlink.html Enjoy and send some feedback!Brian Hurt asked and Alain Frisch answered:
> B) How extensive were the changes to the Ocaml source code? For Linux x86, the change is rather small and straightforward. For Windows ports, it is more tricky, because a Windows DLL cannot reference symbols from the main program. I wrote the FlexDLL tool to simulate a POSIX-ish dlopen API, so that the patch to OCaml itself mostly reduces to removing code or sharing Makefiles with Unix. All the trouble is encapsulated into FlexDLL (which is itself a quite small piece of code, but a tricky one). >From Linux AMD64, the ABI/dynamic linker does not allow to dynamically load position dependant code, so I had to modify the last stage of ocamlopt's backend in order to produce PIC code (when the option -dlcode is given; note that this is independant from the existing -fpic option, details on demand). Again, this is a rather small and unintrusive change. You can use CVS to get a diff between the ocaml3100 tag and the natdynlink branch (but it won't show you new files; you can always "cvs checkout" both and do a local diff). > How likely > is it that this will get included in some future version of the main trunk? It is likely to be included in OCaml 3.11, not before. (Except for the native toplevel which will probably not be included.) Of course, feedback can only help for the integration.Jon Harrop asked and Alain Frisch answered:
> Is that "native" as in we're going to get an OCaml top-level with native-code
> performance? If so, this is hugely important for me...
What kind of application do you have in mind?
It's "native" as in "we have an OCaml top-level with native-code
performance and a large latency". Each phrase is compiled with
ocamlopt's backend to an assembler file, which is then assembled, linked
into a shared library, dl-opened and then run. (Shared libraries will
never be closed so your OS must be strong enough to support that.)
Performances will likely be equal to ocamlopt's generated code (in
particular, we have cross-phrase optimizations).
Feel free to play with it ("make ocamlnat") and tell us whether this is
adequate for what you want to do.
Jon Harrop later said:The native top-level is the bit that interests me the most, as this combines interactivity with OCaml's superb native-code performance. I just benchmarked the new top-level and it runs my ray tracer 17x faster: $ time ocaml unix.cma ray.ml >image.pgm real 1m11.656s user 2m21.106s sys 0m0.331s $ time ocamlnat unix.cmxa ray.ml >image.pgm real 0m4.294s user 0m6.265s sys 0m0.521s Interactive compilation to native code was one of the main benefits of F# over OCaml. So I, for one, would dearly love to see this in the mainstream OCaml!Quôc Peyrot asked and Alain Frisch answered:
> Is it working (or going to work) on PPC (Mac OS X)? It is not currently working. The code generator must be adapted to produce PIC code. I've started to do that but it doesn't work and I won't be able to finish it. If someone is interested to help, please tell me.
> I need to reboot my translator as a Windows app. I would like to know > how well is LablGTK supported on Windows (specially with Glade) and > whether this is advisable if Windows is my only target platform. Have a look at: http://merjis.com/developers/xphelloworld
It is my pleasure to announce the availability of Ocamlodbc version 2.14. http://home.gna.org/ocamlodbc/ Ocamlodbc is an wrapper for various ODBC drivers (mysql, postgresql, unixodbc, oracle, SQLserver,...). This release features a better compilation and installation script under windows (incorporating suggestions from Dmitry Bely) and a slightly improved documentation. It has been tested to work under windows server 2003 and SQLserver.
> Is there a copy of ledit floating around that compiles under 3.10? The > latest version I found was 1.13, at http://pauillac.inria.fr/~ddr/ledit/. I > may just not know where to look. Ledit compiles perfectly with Camlp4s that you can download on my site. I am sorry, I am not going to port my softwares (GeneWeb, ledit, mlrogue, olibrt) into the new Camlp4, because I don't agree with the fundamental choices of that camlp4 (in particular, changes in the syntax tree, and I disagree the use of some libraries, programs, programming and compilation technics, interfaces, tools, source tree). These choices are too different to be compatible with my point of view. I would like to cooperate with the OCaml team to improve their Camlp4, they are nice people but they are taking to what I call wrong directions. (They know my point of view, I told them.) I need Camlp4 for GeneWeb, but I did not manage to port it to the new Camlp4, and it is the main reason why I resurected the version of Camlp4 I had. These days, I have been preparing a new version with a new pretty printing system used and documentation pages. If it is a question of naming, I can rename my Camlp4 into Camlp5 or whatever, but ledit will not be translated into the Camlp4 distributed with OCaml.Jon Harrop also suggested:
You just need to translate the sources into vanilla OCaml using OCaml 3.09 and camlp4 and then it is forwards compatible: $ mkdir trans $ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo cursor.ml >trans/cursor.ml $ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo ledit.ml >trans/ledit.ml $ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo go.ml >trans/go.ml Then you can compile the new sources (in ./trans) with OCaml 3.10: $ cd trans $ ocamlopt unix.cmxa cursor.ml ledit.ml go.ml -o ledit Hey presto, new ledit binary. Ah, the beauty of camlp4. :-)
We just released a new version of Smoke, including a free byte-code edition: http://www.ffconsultancy.com/products/smoke_vector_graphics/ Smoke is a high-performance cross-platform 2D vector graphics library written entirely in OCaml that renders using OpenGL to exploit hardware acceleration. Version 2.01 adds: * Compilation for OCaml 3.10.0 * Vector text using the Computer Modern fonts (see demo3.ml) We are working towards typesetting, GUIs and a vector graphics replacement for the OCaml top-level...
I'd like to announe the New York Functional Programmers Meetup, which is Wednesday, June 27th, 7PM, at the offices of Jane Street Capital. The NYFP meetup is for people using or interested in strongly typed functional languages, such as Ocaml, Haskell, SML, etc. Meeting details are here: http://lisp.meetup.com/59/ (sorry about the Lisp category- it's the closest thing Meetup has to "Functional Programmers").
Hi, I thought I'd briefly report progress on a subsystem of Felix
which may prove a useful technology for Ocaml.
I am using Dypgen
http://dypgen.free.fr/
and Ocs scheme
http://will.iki.fi/software/ocs/
together for building Felix AST terms in a flexible way.
Dypgen is an *extensible* GLR parser generator which is now working
reasonably well. Syntactic forms in the input language can be parsed
so that the user actions extend the grammar being parsed, including
adding new non-terminals and handling conflicts. GLR parsers can
parse any context free language, and work with many grammars for
such languages, and although some care is required obtaining reasonable
performance, an Ocamlyacc-like (LALR1) grammar seems to parse about
the same speed as Ocamlyacc.
The big problem with extensions is not the grammar, but the user
actions. To solve this problem, I have chosen to use Scheme programs
as user actions. Ocs_scheme is written in Ocaml and is very easy
to work with, and appears quite fast.
With this combination, user action codes are written as 'text'
which is then compiled and executed to produce an Ocs_types.sval
or scheme value. These values are basically s-expressions.
Felix converts them to a simple s-expression format, then
converts them to Felix AST_format with a laboriously coded
mapping. Of course the typing is dynamic, up to the building
of the AST. The AST built is the same one the same Ocamlyacc
grammar would have yielded.
At this point I am moving 95% of the Felix grammar into
a user library, so that the 'initial' hard coded grammar
is 'more or less' reduced to:
(a) the top level compilation unit (start symbol)
(b) some code for parsing syntax extension syntax
(c) an effective top level dummy non-terminal
(d) a set of bottom non-terminals which wrap tokens with attributes,
such as literals and names
The bits 'in between' are all programmed in the input source,
that is, user written library code.
The same idea could be used for Ocaml. Instead of using ocamlp4
to separately build extensions, the extensions are defined
directly in the source code that needs them, and ocaml
parses it. Note: dypgen syntax extensions are properly scoped.
Felix uses the format:
syntax schemer {
s_term := sprefixed =># "_1";
s_term := s_term / spower =># "`(ast_apply (div (,_1 ,_3)))";
s_term := s_term % spower =># "`(ast_apply (mod (,_1 ,_3)))";
}
open syntax schemer;
so that the grammar definitions are defined separately from
use. At the moment Felix #includes this input into the program
that needs it, however the layout is design to support separate
compilation of the grammar definitions, so that only the
'open syntax' is required. That statement provides the linkage
to the language sorely missing from the current ocamlp4 engineering.
However the above system is much more flexible because it is
properly scoped -- the opened syntax is only accessible in
the scope an Ocaml 'open' would normally make names available.
Thus, you could easily define 'macros' to help implement
modules without impacting other modules, even in the same
translation unit.
Whilst Scheme isn't the best language for processing Ocaml AST terms
or extensions to them, it has the advantage of being a complete,
well known, high power symbol processing languages. To use the system
you only need to learn a bit of Scheme plus your base AST mapping.
The technology appears different from MetaOcaml because the
staging is localised, that is, the phasing is recursed bottom up
not top down (but I may be wrong on that!) as well as using
a distinct meta-language which is of course unpleasant, particularly
the dynamic typing.
When Ocaml 3.11 is released I hope to extend the technology to
also support dynamic loading of semantic extensions. It's probable
these extensions will be plugged directly into Ocs_scheme as
primitives, so that the Ocaml based AST is discarded permanently.
[The whole compiler will become a Scheme program, albiet with
very specialised primitives written in Ocaml]
Most term rewriting systems are 'effectively' dynamically typed,
even if they use some lower level static typing as support.
Rewrite rules have both pre- and post- conditions which can't
be represented with static typing, and excess static typing
appears to seriously impeded modification of the term rewriting
systems. These systems are 'interpreting' terms no matter
what -- that is, they're intrinsically dynamically typed.
Using s-expressions is a rather extreme encoding, and is
basically TOO dynamic IMHO, but it does seem to represent
a good compromise when there is an emphasis on extension
and experiment. The point is that whilst a more static
encoding is safer for simpler extensions .. it really
gets in the way badly when the extension is a complex
function of an already complex term encoding.
It would be interesting if someone wanted to use this idea
to make a new camlp5 front end to Ocaml.
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.