[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Sep 23 00:45:16 PDT 2008
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
========================================================================
1) csml: high-level bindings between OCaml and .Net
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/18b9b5b886dcad72#
>
------------------------------------------------------------------------
** Alain Frisch announced:
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).
** Stefano Zacchiroli asked and Alain Frisch answered:
> 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!
** Ludovic Coquelle asked and Alain Frisch answered:
> 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.
========================================================================
2) OCamlSpotter: OCaml compiler extension for source browsing
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/85cf1bba8731894a#
>
------------------------------------------------------------------------
** Continuing a thread from last week, Xavier Leroy said:
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.
========================================================================
3) Portable PNG exporter
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/8b83d718b0b02fc0#
>
------------------------------------------------------------------------
** Janne Hellsten announced:
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
>
** Richard Jones then said:
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)
** Janne Hellsten then replied:
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
** Daniel Bünzli added:
> - 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>
** Florent Monnier also said:
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 !
========================================================================
4) Dum: dumper module with cycle detection
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/713869732cd97cf0#
>
------------------------------------------------------------------------
** Martin Jambon announced:
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
(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 --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20080923/a340b500/attachment-0001.htm
-------------- 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/20080923/a340b500/attachment-0001.pgp
More information about the caml-news-weekly
mailing list