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 .NetArchive: <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 makethe 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 browsingArchive: <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 exporterArchive: <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 detectionArchive: <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([EMAIL PROTECTED]) 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly