Previous week Up Next week

Hello

Here is the latest Caml Weekly News, for the week of November 02 to 09, 2010.

  1. rpc: type conversion
  2. "OCAPIC" : OCaml for PIC18 microcontrollers
  3. ocaml-extunix 0.0.1 released
  4. MLbrot: Mandelbrot Set in OCaml
  5. Other Caml News

rpc: type conversion

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/1cf46226f066ffc9#

Philippe Strauss asked and Jake Donham replied:
> I need to use RPC in a current project of mine, but I don't get how do you
> write the type conversion and what is provided, taking a very basic example:

If you are using OCaml on both ends, you might prefer to use orpc:

  http://jaked.github.com/orpc/

which generates stubs from OCaml signatures rather than ONC RPC interface
files.
      

"OCAPIC" : OCaml for PIC18 microcontrollers

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

Philippe Wang announced:
this is an announcement for "OCAPIC", a project which brings OCaml to
programming PIC micro-controllers.

Some PIC18 series characteristics:
- 8 bit architecture
- low cost (a few US dollars), fairly spread in electronics world
- very low volatile memory (a few bytes only, up to ~5000 bytes, depending on
  the model)
- very low non-volatile memory (less than a KB up to 128 KB)
- EEPROM : 0 to 1024 bytes

How to program those little chips with OCaml:
- write an OCaml program, compile it, transfer it to the PIC.

Well, actually it demands a little more than just that:
- write an OCaml program, like usually, while keeping in mind that the stack
  is more limited than usual, same for the heap
- compile it (with ocamlc)
- reduce the binary (with ocamlclean : a bytecode reducer which removes
  dead-code)
- transform the (reduced or not) binary (with bc2asm : take back not useful
  zeros, thence reducing the binary size)
- transfer it to the PIC along with its OCaml VM.

Indeed, an OCaml VM has been implemented in PIC18 ASM in order to run OCaml
programs on a PIC ! :-)

An example of real program is in the distribution (open source, downloadable
from the website):
ocapic-1.3/src/tests/goblet/ (722 lines of ML code).

We also provide a simulator in order to run on a PC (needs X11 (Linux/MacOSX)
and GCC) your programs written for PIC18.

The whole implementation has been fairly well tested, however the
documentation is still quite young.

Here is the website : 
http://www.algo-prog.info/ocaml_for_pic/ 

Cheers.

Benoît Vaugon (developer and initiator of OCAPIC project)
Philippe Wang (supervisor)
Emmanuel Chailloux (supervisor)

P.S. si vous êtes francophone et nous contactez directement, merci de le faire
en français
      
Daniel Bünzli asked and Philippe Wang replied:
> Interesting project. Was the choice of PIC based on technical reasons 
> or just familiarity of the authors with these chips ? 
>
> I would have liked to give it a try but unfortunately I work AVRs and 
> avr-gcc. 

PIC ASM is the first "programming language" Benoît learnt, a few years ago. He
has practiced it ever since.
But meanwhile he learnt OCaml (among other languages). A few months ago, he
suggested me to implement an OCaml virtual machine running on PICs, with
maximum performance efficiency in mind. This is why OCAPIC's VM is implemented
in ASM.

The purpose is of course to program PICs with a high level language while
remaining (relatively) *very* efficient.

Vincent St-Amour and Marc Feeley have a similar project (Scheme on PICs) which
a much higher priority on portability: their VM is implemented in C code.
http://www.ccs.neu.edu/home/stamourv/picobit-ifl.pdf 

The "side effect" of our project — which can interest many OCaml users — is
that OCAPIC provides "ocamlclean", which is a tool that takes an OCaml
bytecode binary (produced by ocamlc) and reduces it by (statically)
eliminating most of its deadcode (and of course dynlink is thence broken; note
that dynlink is not relevant on PICs). This tool is independent from the rest
of OCAPIC.
Actually, this tool was mandatory for programs using OO-layer : without it,
bytecode binaries embedding OO-layer were to big to fit on our PICs.
      
Goswin von Brederlow asked and Philippe Wang replied:
> Doesn't the overhead of boxed structures as well as loosing a bit on 
> ints make that impractical given the extremly limited memory? 

Thanks for the question. Let me try to give an (indirect) answer.

OCAPIC has 16-1=15bit integers and 16bit blocks. And the overhead is quite
acceptable to us.

A gobblet game [1] I.A. was implemented and tested. (The OCaml code is
included in the distribution so anyone can check it out.) The first version of
this game was very hard to beat (for a human). Then a strategy was found (to
beat the I.A.). So some randomization was supplied to the I.A. to make it more
interesting. Now the I.A. has become really very hard to beat.
(We used a PIC18F4620: flash memory = 64kiB; volatile memory = 3968B ; EEPROM
= 1KiB ; speed = 10 MIPS)

Between two moves, the I.A. may trigger the GC about ten times or more.
However, the time between two moves is less than 2 seconds, and generally
quite less than half a second (and in the beginning of the game it's hard to
realize the time it takes).

Providing a GC to programming PIC microcontrollers is a tremendous gain
comparing to manually manage everything (memory and computing).
Providing a high-level language allows to implement algorithms that would be
very hard or impossible to implement in ASM (or most low-level languages such
as C or Basic).

We haven't yet experimented real-time constrained programming (e.g.,
ReactiveML might bring OCAPIC to a step further).

Now, maybe the direct answer to the question can be :
 programming PICs has been impractical to most people, now all readers of this
list can potentially program them without much difficulties (and without
paying a too high cost on performance efficiency).

:-)

[1] http://www.educationallearninggames.com/how-to-play-gobblet-game-rules.asp
      

ocaml-extunix 0.0.1 released

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

ygrek announced:
I am glad to announce the first release of ExtUnix - extended Unix
module. This is a preliminary alpha release, some API may change (based
on your feedback). Implemented bindings :
* fsync fdatasync
* eventfd signalfd
* statvfs fstatvfs
* dirfd openat unlinkat fstatat
* uname
* fadvise fallocate
* ttyname setpgid getpgid setreuid setregid
* realpath
* some ioctls

This release would have been much less interesting without the major
contributions by Sylvain Le Gall, Stéphane Glondu and Kaustuv Chaudhuri.

Get it at https://forge.ocamlcore.org/frs/?group_id=175

Homepage:
http://extunix.forge.ocamlcore.org/

Get source code:
git clone http://git.ocamlcore.org/extunix/extunix.git/

Browse source code:
http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=extunix/extunix.git;a=summary

ExtUnix aims to collect thin bindings to various low-level system API
in one library with consistent interface. Project guidelines (verbatim from
README):
http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=extunix/extunix.git;a=blob_plain;f=README.txt;hb=HEAD

For OCaml programming style, we follow Unix module:
 * Values and types should be named by the name of the underlying C function
 * Raise Unix_error on runtime errors
 * Uniformly raise Not_available exception for functions not available on the
   current platform
 * Be MT friendly by default - i.e. release runtime lock for blocking
   operations, (FIXME) optionally provide ST variants

Portability: 
 * No shell scripting for build and install (think windows :) )
 * Write portable C code (use compiler options to catch compatibility issues),
   NB: msvc doesn't support C99.
 * Provide module (ExtUnix.Specific) exposing only functions available on the
   platform where library is built - i.e. guaranteed to not throw
   Not_available exception (experimental).
      

MLbrot: Mandelbrot Set in OCaml

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/85623ba9e467dfda#

Daniel de Rauglaudre announced:
New release of MLbrot: 1.00

MLbrot is a program allowing to explore the Mandelbrot Set and produce
nice fractal images. With some extra work, can produce videos. Can be
helped by other computers, via internet, to speed up images calculations.

Interfaced with 3 graphic toolkits: Lablgtk2, OpenGL and Olibrt. You
can choose the one(s) you want at configure time, or let the 'configure'
shell to select the ones it finds.

Best interface is with Lablgtk2 (it has menus and progress bars).

Web site and download at:
  http://pauillac.inria.fr/~ddr/mlbrot/

You need OCaml and Camlp5 to compile.
You need at least one library installed: Lablgtk2, OpenGL or Olibrt.
Very useful library too: GMP/MPZ to display deep images (zoom > 2^46).

Documentation not yet done. Just launch it, try out option -help
and/or ask me.
      

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/.

Commercial, Supported, Faster PDFtk - Beta Testers Wanted:
  http://coherentpdf.com/blog/?p=51

Why Map/Reduce matters:
  http://blog.camlcity.org/blog/plasma3.html

ocaml-extunix 0.0.1 released:
  http://forge.ocamlcore.org/forum/forum.php?forum_id=726

ocaml-sphinx 0.0.1 released:
  http://forge.ocamlcore.org/forum/forum.php?forum_id=725

Stalin Scheme vs OCaml:
  http://www.wisdomandwonder.com/link/5360/stalin-scheme-vs-ocaml

F#:
  http://gaiustech.wordpress.com/2010/11/05/f/

Plasma 0.2:
  http://caml.inria.fr/cgi-bin/hump.cgi?contrib=733

Camlp5 6.00:
  http://caml.inria.fr/cgi-bin/hump.cgi?contrib=592
      

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