Hello

Here is the latest Caml Weekly News, for the week of September 16 to 23, 2008.

1. csml: high-level bindings between OCaml and .Net
2. OCamlSpotter: OCaml compiler extension for source browsing
3. Portable PNG exporter
4. Dum: dumper module with cycle detection

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/18b9b5b886dcad72#

LexiFi is proud to announce the first public release of CSML, a system to
interface OCaml and .Net/C#. CSML makes it possible to leverage existing .Net
components from OCaml, to expose OCaml libraries into the ..Net world and more
generally to write mixed OCaml/.Net applications.

With CSML, developers write scripts that describe interactions between the two
worlds (OCaml and .Net). It is possible to bind functions, static or instance
methods, properties, to pass opaque pointers from one heap to the other, or to
copy values structurally. CSML preserves type safety properties from the two
worlds, it propagates exceptions and first-class functions in a sound way and
it deals automatically with memory management.

CSML is used internally by LexiFi to develop complex OCaml/C# applications and
to expose its core technologies as .Net components.


More information, download, screenshots and documentation:

            http://www.lexifi.com/csml/


CSML is made of a compiler and a small runtime system. The runtime system is
licensed under the LPGL with the classical linking exception. The compiler
comes free of charge in binary form only. It is entirely possible to use CSML
in the context of an open-source project or in a commercial application.

Note: CSML works with the forthcoming OCaml 3.11. To use it now, you can check
out a recent version from OCaml'S CVS. CSML has been tested with the two
"native" ports of OCaml for Win32 (MSVC and MinGW).
			

> Out of curiosity: is CSML specific to Windows or not?

Currently CSML only works under Windows.

I've briefly tried to make it work under Linux with Mono some months ago but I
stopped very quickly; I could not even call a simple C function in a shared
library from C# with Mono (see
http://lists.ximian.com/pipermail/mono-list/2008-March/037946.html). If anyone
is interested in helping porting CSML to Mono, please let me know!
			

> Is it easier to use CSML compare to porting ocaml code to F#? 

It depends on how much of .Net you plan to use (and other factors). If 
you talk about porting OCaml code to F#, it probably means you have an 
existing code base that does not require .Net at all now and you want to 
use some features from .Net; in that case, to answer your question, 
using CSML is probably easier than rewriting your whole code base. 

F# and OCaml+CSML are really two different things. 

With F#, you live in the .Net world entirely: a single GC, no issues 
with threads, and the binding between F# and C# is automatic. CSML make 
the two worlds live happily together but they are still two separate worlds. 

For situations were both would be appropriate, there are several 
arguments to consider. 

- As far as I know, F# is significantly slower than OCaml in native code 
for symbolic computation (which is precisely the kind of code you would 
like to use ML for). 

- F# and OCaml are really two different languages, with their own 
features (e.g. the object and module systems are very different) and 
tools. 

- For people who want to support cross-platform applications, OCaml is 
probably a better option. CSML lets you write the parts of your 
applications that are specific to .Net but the rest of your project 
remains platform-independent. 

- For members of the OCaml consortium at least, being able to modify, 
embed and redistribute the OCaml compiler is a big plus. (E.g. at 
LexiFi, we rely heavily on substantial extensions to the OCaml system.) 

- With CSML, it is possible to have mutually recursive OCaml and C# data 
structures and to have a single application that calls back and forth 
between the two languages. As far as I know, it is not possible to link 
F# and C# code in the same .Net assembly, so some kind of recursions are 
more difficult. This is not a problem if you only want to import 
existing .Net libraries or to expose your ML code as .Net components, 
but for a mixed application, this might be an issue.
			

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/85cf1bba8731894a#

From what I've heard, there's also an OCaml summer of code project
that enriched the info found in .annot files.  So, it's certainly time
to discuss extensions to .annot files, but let's do that globally, not
one at a time.  It is probably too late for inclusion in 3.11, but as
long as these extensions are backward compatible, inclusion in bugfix
releases can be considered.
			

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/8b83d718b0b02fc0#

While working on a graphics related problem, I needed to save the
contents of a Graphics framebuffer to a .png file.  Quick googling for
"ocaml png" didn't bring up any results for libraries that would be
easy to install via GODI.  I am aware of CamlImages but unfortunately
I have never been successful at installing it due its heavy dependence
on external libraries.  I also often work on Windows and installing
external OCaml libraries on Windows is usually a major PITA (if
possible at all).

I decided to write a simple self-contained .png exporter that wouldn't
depend on any external libraries (not even libpng or zlib).  I thought
someone else might benefit from this piece of code and I thus made it
freely available here:

http://code.google.com/p/aihiot/source/browse/trunk/gfx/save_bitmap/ocaml/png.ml
			

Your code is surprisingly elegant .. I didn't think it was possible to
write out a PNG file in such few lines.  I wonder if it would be more
concise using bitstring.

For reference, I've found the easiest way to export PNGs (in any
language, not just OCaml) is to use netpbm.  Simply fork pnmtopng
using Unix.open_process_out and write a PPM file.  A PPM file has such
a simple format that you can write it directly from just about any
language, even a shell script.

 P3 <width> <height> 255
 followed by <width>x<height>x3 RGB triplets (in decimal, separated
 by writespace)

As a concrete example in OCaml:

 open Printf

 let () =
   let chan = Unix.open_process_out "pnmtopng > /tmp/image.png" in
   fprintf chan "P3 128 128 255\n";
   for i = 0 to 127 do
     for j = 0 to 127 do
       let r = float (i+j) /. 256. in
       let g = float (i*2) /. 256. in
       let b = float j /. 128. in
       fprintf chan "%d %d %d\n"
	  (int_of_float (r*.255.))
	  (int_of_float (g*.255.))
	  (int_of_float (b*.255.))
     done
   done;
   ignore (Unix.close_process_out chan)
			

As my tiny PNG exporter got more attention than I anticipated, let me
clarify a couple of things:

- My OCaml code is based on a C function written by Tero Karras.  I
 merely rewrote his masterpiece in OCaml.  The C version is available
 here:

 http://code.google.com/p/aihiot/source/browse/trunk/gfx/save_bitmap/c/save_bitmap.c

- The trick is to save out uncompressed PNGs.  This gets rid of the
 zlib dependency.  Although the files get bigger, uncompressed .png
 is still very useful.

> Your code is surprisingly elegant .. I didn't think it was possible to
> write out a PNG file in such few lines.  I wonder if it would be more
> concise using bitstring.

Doing 32-bit (<> 31-bit) integer on OCaml was a bit of a pain and it
shows.  If Bitstring helps you write more concise 32-bit ALU ops, then
I'd imagine the code would be more concise.  Manipulating bit fields
was not a big issue with .png though.

Updating Adler and CRC in functional style was probably not a good
idea, an imperative version would be easier to read and maintain.  Not
to mention feeling a bit naughty when doing I/O inside a fold_left. :)

> For reference, I've found the easiest way to export PNGs (in any
> language, not just OCaml) is to use netpbm.  Simply fork pnmtopng
> using Unix.open_process_out and write a PPM file.

I usually write out .tga which is also very easy to write and most
programs open it.  I wanted to have .png to be able to view them in
generated HTML reports.

Saving a .tga is quite easy, copy&pasting from
http://code.google.com/p/aihiot/source/browse/trunk/gfx/save_bitmap/ocaml/tga.ml:

(** Save a .tga file to chnl. *)
let write_tga_chnl chnl pixels w h =
 let header =
   [0; 0; 2; 0; 0; 0; 0; 0; 0; 0; 0; 0;
    w land 255; w lsr 8;
    h land 255; h lsr 8; 32; 8] in
 List.iter (fun e -> output_byte chnl e) header;
 for y = 0 to h-1 do
   for x = 0 to w-1 do
     let c = pixels.(x+(h-1-y)*w) in (* h-1-y = Flip image *)
     output_byte chnl (c land 255);
     output_byte chnl ((c lsr 8) land 255);
     output_byte chnl ((c lsr 16) land 255);
     output_byte chnl 255;
   done
 done
			

> - The trick is to save out uncompressed PNGs.  This gets rid of the 
>  zlib dependency.  Although the files get bigger, uncompressed .png 
>  is still very useful. 

and you can compress them later with pngcrush [1]. 

[1] http://en.wikipedia.org/wiki/Pngcrush 
			

You can reduce the amount of exchanged datas using binary ppm instead of ascii 
ppm. In such case the format is:

 P6\n<width in ascii> <height in ascii>\n255\n
 followed by <width>x<height>x3 RGB triplets of octect (in binary)

Here is the OCaml code I use, as well for jpeg:

let output_ppm ~oc ~img:(_, r_channel, g_channel, b_channel) =
 let width = Bigarray.Array2.dim1 r_channel
 and height = Bigarray.Array2.dim2 r_channel in
 Printf.fprintf oc "P6\n%d %d\n255\n" width height;
 for y = 0 to pred height do
   for x = 0 to pred width do
     (* output_byte doesn't raise any exception about the range *)
     output_char oc (char_of_int r_channel.{x,y});
     output_char oc (char_of_int g_channel.{x,y});
     output_char oc (char_of_int b_channel.{x,y});
   done;
 done;
 output_char oc '\n';
 flush oc
;;

(* you can use different conversion commands (convert is from ImageMagick) *)
let print_jpeg ~img ?(quality=96) () =
 let cmd = Printf.sprintf "cjpeg -quality %d" quality in
 (*
 let cmd = Printf.sprintf "ppmtojpeg -quality %d" quality in
 let cmd = Printf.sprintf "convert ppm:- -quality %d jpg:-" quality in
 *)
 let ic, oc = Unix.open_process cmd in
 output_ppm ~img ~oc;
 try
   while true do
     let c = input_char ic in
     print_char c
   done
 with End_of_file -> ()
;;

(* output any of the hundred formats ImageMagick knows *)
let print_file ~img ~format =
 let cmd = Printf.sprintf "convert ppm:- %s:-" format in
 let ic, oc = Unix.open_process cmd in
 output_ppm ~img ~oc;
 try
   while true do
     let c = input_char ic in
     print_char c
   done
 with End_of_file -> ()
;;

let new_img ~width ~height =
 let all_channels =
   let kind = Bigarray.int8_unsigned
   and layout = Bigarray.c_layout
   in
   Bigarray.Array3.create kind layout 3 width height
 in
 let r_channel = Bigarray.Array3.slice_left_2 all_channels 0
 and g_channel = Bigarray.Array3.slice_left_2 all_channels 1
 and b_channel = Bigarray.Array3.slice_left_2 all_channels 2
 in
 (all_channels,
  r_channel,
  g_channel,
  b_channel)
;;
_________________________________________

Anyway I'm very pleased to see this png exporter, while it's allways usefull 
to remove an external dependency !
Thanks for this piece of code !
			

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/713869732cd97cf0#

Wink.com is releasing a module called Dum for dumping data.
It derives from Dumper by Richard W Jones (now Std.dump in Extlib) and
from Size by Jean-Christophe Filliatre.

  http://oss.wink.com/dum/

The main improvement over the original Dumper is that shared values and
therefore cycles are detected and labelled:

# let rec loopy = 1 :: 2 :: loopy in Dum.p loopy;;
- : string = "#0: (1 (2 #0))"

Dum was originally developed to print the maximum out of uncaught exceptions,
since the standard Printexc.to_string does not go arbitrarily deep and this
was occasionally a source of frustration.

Now data such as closure fields and object fields are dumped like regular data
without causing particular problems or worries.

The output is pretty-printed and its size limit is configurable.
			

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

Alan Schmitt