Hello

Here is the latest Caml Weekly News, for the week of September 17 to 24, 2013.

1. OCaml on Android
2. OCaml release 4.01.0
3. OCaml vs Ada and/or GUI options
4. Beta release of OPAM 1.1.0
5. Ocaml on an embedded arm system (no linux)
6. Call for Talks - Open World Forum / OSDC
7. SIunits 0.1
8. ocaml interface to berkeley db?
9. Other Caml News

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00257.html

> What is the status of OCaml on Android? Have any Android apps been written
> in OCaml?

There's a GitHub OPAM repository here:
https://github.com/vouillon/opam-android-repository

and I've just ordered myself my first Android device, as Mirage has just been
ported over to it a few days ago in UNIX mode:
https://lists.cam.ac.uk/pipermail/cl-mirage/2013-September/msg00062.html

I haven't tried it myself yet, but intend to once my physical device shows
up. Googling reveals a few applications built using it already, but I have
no idea how substantial they are.
      

I'm not sure if this anwers your question, but someone wrote an Ocaml
toplevel for Android:
http://vernoux.fr/2011/11/11/ocaml-toplevel-for-android/
https://play.google.com/store/apps/details?id=fr.vernoux.ocaml
      

> The basic problem with running OCaml on Android is that pretty much
> everything (minus a few system services / daemons, for example) runs
> inside a Dalvik VM.  Everything that is a "real app" thus uses the
> facilities of the SDK to interact with the underlying
> system.  (Various services such as internet can be opened via a raw
> socket, and are protected via lower level system modifications.)

And what about OCaml-Java [1]. Will it be possible to use it with
dalvik?

[1] http://ocamljava.x9c.fr/preview/
      

> With a little bit of hacking it'd probably work, but I'm not sure of the
> status of ocaml-java and haven't looked into the implementation details.
> Since ocaml-java outputs class files (afaik) you'd have to sort of hack the
> android build pipeline yourself, but that wouldn't be the hard part: all
> the tools are there. The harder part is that the Android SDK is very Java
> oriented, and it just feels awkward as hell to use in OCaml even if you
> were to write a thin wrapper around the SDK.

In theory, you are right that it wouldn't be hard.
In practice, the problem is that OCaml-Java emits classes
for Java 1.7 while (to the best of my knowledge) Android
only accepts Java 1.6 classes. As far as I know, there is no
other pending problem.

From this point, the question would be: is it better to wait
for Android to update to Java 1.7 (or even 1.8...), or to
modify OCaml-Java? Honestly, I would need quite a bit
of encouragement to modify OCaml-Java in this direction...

Regarding interaction with the classes of the Android SDK,
one may be interested in the typer extension allowing to
manipulate Java instances from pure OCaml code:
http://ocamljava.x9c.fr/preview/javaext.html
The main potential problem with this approach is that the
extension currently allows only to implement interfaces, but
not to extend classes. It may be a problem if for example the
event system of Android is based on abstract classes.
Another problem may be the "linking", i. e. the way Android
expects to execute an application: is it a bare main method,
or is there a need to implement/extend a given interface/class?
      

> Yes, it does rely on extending an abstract class. This does, in fact,
> permeate the framework.

This problem is indeed to be fixed in a future version of OCaml-Java.
Currently, you can extend an abstract class only in well delimited
circumstances, for example to build an applet.
      

http://gallium.inria.fr/blog/ocaml-on-a-nexus-7/
      

> a colleague here ported cadmium to android a while back. don't know
> how relevant/working it still is though.
>
> https://github.com/dominicjprice/joecaml

Beware, Cadmium is only providing an OCaml bytecode interpreter
written in Java. You hence only get a Java equivalent of the "ocamlrun"
program.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00264.html

Exherbo [1] since tonight [2].

[1] http://exherbo.org/
[2] https://github.com/nbraud/nicoo_exherbo/commit/24037f640154b8352a5dac7359d7b94dd3451f64
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00270.html

We have done some experiments running LexiFi's core libraries (symbolic 
manipulations of terms representing financial contracts) in the browser, 
using js_of_ocaml.  We also played with dynamic GUI generation directly 
in the browser, based on our runtime type extension (which works fine 
with js_of_ocaml).

Overall, we were impressed by the easiness to integrate js_of_ocaml (no 
need to patch the compiler or do big changes to the build system) and 
its faithfulness to the semantics of OCaml.  Really no big bad 
surprises, and it was amazing to see a complex piece of software running 
in the browser.  js_of_ocaml opens many interesting doors for using 
OCaml in web development!


(((Some points which required some special care:

   - Support for C primitives.  Each primitive called by the bytecode 
needs to have a Javascript implementation.  Since LexiFi's version of 
OCaml is most often synchronized with OCaml's trunk than with a stable 
release, we had to implement the new primitives.  This raises the 
general point that js_of_ocaml will need some active maintenance, even 
if the OCaml bytecode itself is very stable across versions.

  - A tiny semantic difference: in OCaml, the expression 
"String.unsafe_get s (String.length s)" returns '\000', which gives an 
efficient way to iterate over a string without checking for the 
end-of-string condition explicitly.  This hack (which is also used in 
the stdlib module, btw) does not work with the way strings are 
represented in js_of_ocaml.  That said, we were quite happy to see that 
other low-level hacks we do with the runtime representation of values 
worked well (setting a block tag to Object_tag to force generic 
comparison and hashing to use the second field; or playing with the 
representation of method tables to memoize method calls).

  - The lack of weak hash tables, which we use quite a lot.  I wonder if 
Firefox's experimental WeakMap could be used to simulate them (and if 
other browsers will get similar features).

  - Reliance on Camlp4 for interacting with Javascript.  Getting rid of 
this dependency was our first internal use of -ppx!
)))
      

> - The lack of weak hash tables, which we use quite a lot. I wonder if
> Firefox's experimental WeakMap could be used to simulate them (and if  
> other browsers will get similar features).

AFAIK, the answer is no. I explain why in this message [1].

Best,

Daniel

[1] https://lists.cam.ac.uk/pipermail/cl-mirage/2013-April/msg00032.html
      

As you say, WeakMap is a feature of the upcoming EcmaScript 6 standard, and
hence will be supported by all browsers sometime soon. (FWIW, Chrome also
has supported WeakMap for a while, albeit you still need to turn on the
'Experimental JavaScript' flag on the chrome://flags page. And IIRC, other
vendors are working on it already.)

But yes, WeakMap is carefully designed to not make GC observable, so it
cannot implement weak references. Weak references are on the agenda for ES7,
but that will take another two years at least.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00300.html

We are very happy to announce the beta release of OPAM version 1.1.0!
 
OPAM is a source-based package manager for OCaml. It supports multiple
simultaneous compiler installations, flexible package constraints, and
a Git-friendly development workflow which. OPAM is edited and
maintained by OCamlPro, with continuous support from OCamlLabs and the
community at large (including its main industrial users such as
Jane-Street and Citrix).
 
Since its first official release last March[1], we have fixed many
bugs and added lots of new features and stability improvements[2]. New
features go from more metadata to the package and compiler
descriptions, to improved package pin workflow, through a much faster
update algorithm. The full changeset is included below.
 
We are also delighted to see the growing number of contributions from
the community to both OPAM itself (35 contributors) and to its
metadata repository (100+ contributors, 500+ unique packages, 1500+
packages). It is really great to also see alternative metadata
repositories appearing in the wild (see for instance the repositories
for Android[3], Windows[4] and so on[5]). To be sure that the
community efforts will continue to benefit to everyone and to
underline our committment to OPAM, we are rehousing it at
`http://opam.ocaml.org` and switching the license to CC0 (see [6],
where 85 people are commenting on the thread).
 
The binary installer has been updated for OSX and x86_64:
- http://www.ocamlpro.com/pub/opam_installer.sh
 
You can also get the new version either from Anil's unstable PPA:
    add-apt-repository ppa:avsm/ppa-testing
    apt-get update
    sudo apt-get install opam
 
or build it from sources at :
- http://www.ocamlpro.com/pub/opam-full-1.1.0-beta.tar.gz
- https://github.com/OCamlPro/opam/releases/tag/1.1.0-beta
 
NOTE: If you upgrade from OPAM 1.0, the first time you will run the
new `opam` binary it will ugrade its internal state in an incompatible
way: THIS PROCESS CANNOT BE REVERTED. We have tried hard to make this
process fault-resistant, but failures might happen. In case you have
precious data in your ~/.opam folder, it is advised to backup that
folder before you upgrade to 1.1.
 
Happy hacking,
Thomas, on behalf on all the OPAM team
 
[1] http://www.ocamlpro.com/blog/2013/03/14/opam-1.0.0.html
[2] https://github.com/OCamlPro/opam/issues?milestone=17&page=1&state=closed
[3] https://github.com/vouillon/opam-android-repository
[4] https://github.com/vouillon/opam-windows-repository
[5] https://github.com/search?q=opam-repo&type=Repositories&ref=searchresults
[6] https://github.com/OCamlPro/opam-repository/issues/955
 
== CHANGES ==
* Automatic backup before any operation which might alter the list of installed packages
* Support for arbitrary sub-directories for metadata repositories
* Lots of colors
* New option `opam update -u` equivalent to `opam update && opam upgrade --yes`
* New `opam-admin` tool, bundling the features of `opam-mk-repo` and
  `opam-repo-check` + new 'opam-admin stats' tool
* New `available`: field in opam files, superseding `ocaml-version` and `os` fields
* Package names specified on the command-line are now understood
  case-insensitively (#705)
* Fixed parsing of malformed opam files (#696)
* Fixed recompilation of a package when uninstalling its optional dependencies (#692)
* Added conditional post-messages support, to help users when a package fails to
   install for a known reason (#662)
* Rewrite the code which updates pin et dev packages to be quicker and more reliable
* Add {opam,url,desc,files/} overlay for all packages
* `opam config env` now detects the current shell and outputs a sensible default if
  no override is provided.
* Improve `opam pin` stability and start display information about dev revisions
* Add a new `man` field in `.install` files
* Support hierarchical installation in `.install` files
* Add a new `stublibs` field in `.install` files
* OPAM works even when the current directory has been deleted
* speed-up invocation of `opam config var VARIABLE` when variable is simple
  (eg. `prefix`, `lib`, ...)
* `opam list` now display only the installed packages. Use `opam list -a` to get
  the previous behavior.
* Inverse the depext tag selection (useful for `ocamlot`)
* Add a `--sexp` option to `opam config env` to load the configuration under emacs
* Purge `~/.opam/log` on each invocation of OPAM
* System compiler with versions such as `version+patches` are now handled as if this
  was simply `version`
* New `OpamVCS` functor to generate OPAM backends
* More efficient `opam update`
* Switch license to LGPL with linking exception
* `opam search` now also searches through the tags
* minor API changes for `API.list` and `API.SWITCH.list`
* Improve the syntax of filters
* Add a `messages` field
* Add a `--jobs` command line option and add `%{jobs}%` to be used in OPAM files
* Various improvements in the solver heuristics
* By default, turn-on checking of certificates for downloaded dependency archives
* Check the md5sum of downloaded archives when compiling OPAM
* Improved `opam info` command (more information, non-zero error code when no patterns match)
* Display OS and OPAM version on internal errors to ease error reporting
* Fix `opam reinstall` when reinstalling a package wich is a dependency of installed packages
* Export and read `OPAMSWITCH` to be able to call OPAM in different switches
* `opam-client` can now be used in a toplevel
* `-n` now means `--no-setup` and not `--no-checksums` anymore
* Fix support of FreeBSD
* Fix installation of local compilers with local paths endings with `../ocaml/`
* Fix the contents of `~/.opam/opam-init/variable.sh` after a switch
      

For those curious about the package growth, I've plotted the results of
"opam-admin stats" here:

http://anil.recoil.org/2013/09/20/opam-1-1-beta.html

Also, I'd love to get any feedback about whether the beta PPAs in my
ppa-testing repository work well for you. I'm still learning my way
around the (very powerful) system Canonical have, and I think this new
repository should work with Ubuntu Precise, Quantal and Raring on both
x86_64 and i386. I'm still working my way through building ARM packages
for the rPi and Dreamplugs, since that's a more manual process.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00307.html

I'm looking at the feasibility of targetting a couple ARM processeors in a
similar manner to ocapic at its core.

What I'm looking to end up with is a bytecode interpreter running
coopertatively multi-tasked ocaml apps, that I can feed in more bytecode at
runtime (start a new task, replace an existing task, or interpret a
bytecode sequence in an existing task.) The framework for this on the
embedded target would be in C (not assembly).

Ideally I'd also have a shell on the host development that I could used to
interactively compile and interpret ocaml code running on the target.

I would also like to crosscomple (including metacompilation) for the target
on the host machine, where I could have a sources file that switch between
host and target code to produce applications for the target.

Ideally the shell on the host would have access to the same environment
used for cross compilation.

I have not used OCaml all that much, so I don't know yet how how difficult
(or feasible) that this task would be.

Since the bare metal framework of the embedded target would be in C, I
would develop and test it first on the host system. (Linux on x86_64).


The ARM processors I'm looking to target are:
STM32F407ZGT6 ARM Cortex-M4, 1MB Flash, 196KB RAM (Has floating point)
STM32F103RB ARM Cortex-M3, 128 KB Flash, 20K RAM (No floating point)

On both I'd like to be able to run bytecode both out of Flash and RAM.
(Primarily flash, but RAM for debugging).

Speed is on overly important as long as I can control when the garbage
collection is run (could be done in C in the multitasker?).
      

> I hope this isn't a typo. 196 KB RAM is way too low to even run a hello
> world program. The predecessor of ocaml, caml-light, needed 640K at
> minimum for running it on DOS, and that was 16 bit code. Ocaml is a lot
> larger, and generates less dense 32 bit code.
>
> For a very small app on bare metal, I think you need at least 4-8 MB of
> memory. For making you happy, calculate 64 MB. I cannot say much about
> the split flash mem vs. RAM - but you should take into account that the
> representation of values isn't optimized for compactness, and you also
> need extra RAM to give the garbage collector room.
>
> Maybe it is possible to lower the memory requirements by modifying the
> ocaml runtime (e.g. make the bytecode more compact at the cost of extra
> decoding steps, remove unneeded parts like the compactor, ...), but I
> doubt you'll be able to hit the mentioned limits.

No, the Flash/RAM sizes I mentioned are not a typo.

OCaPIC is a similar OCaml project for PIC microntrollers.
http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC:OCAPIC

The microcontrollers targetted by OCaPIC have the following characteristics:
  RAM memory: a few kB.
  Flash memory: a few tens of kB.
  Clock: a few MHz

The ARM microcontrollers I'm looking to target are much bigger than PIC
microcontrollers on all 3 of those counts are significantly larger.
      

Just looked at the slides. They implemented a lot of things to increase
the compactness (bytecode compression, 16 bit integers and pointers, a
simple stop-and-copy GC, a utility to remove dead code, ...). This is
essentially a complete port of ocaml to a new architecture, with heavy
modification of the runtime. At the end, it is possible to run programs
with a few hundred lines of code (which is really impressive). You
cannot run the toploop shell.

What you could do, of course, it to port OcaPIC to ARM (well, there is
some assembly code, but not that much). But this doesn't give you a
toploop, probably not even dynamic loading of bytecode.

I really wonder what makes these very small devices so interesting as
platform for OCaml (other than, of course, having fun to run some code
in the favorite language there).
      

It is perfectly possible to run OCAML on an ARM with 196K of memory. For this
purpose the code density will only be a bit worse than a C compiler for the
same complexity of algorithm. The ocapic distribution achieves some of its
savings by using primitives that access the hardware directly. So this saves
quite a bit in library code. However what you propose to do is to implement
the bytecode toplevel on the ARM. This can not be done with less than about 2
megs of RAM, and some features would have to be left out. The primary
functions that need the space are to do with parsing and compiling your input
to bytecode and linking it incrementally with the provided libraries, all of
which takes significant space. If you want something non-trivial to run you
need to allow decent amounts of space for heap objects and garbage collection
efficiency.

If you only want a fixed program to run this is more realistic for 192K and in
theory the Ocaml code could be flashed. You still need to tweak things I would
guess if the garbage collector has to work in 196K or potentially 20K. If you
use native code generation the interpreter can be omitted which will save
quite a bit. Be prepared to write the vast of libraries yourself such as
anything to do with I/O. Standard libraries for list manipulation would not
need to be changed. A certain style of OCaml when written will save you quite
a bit of memory, especially if you use it to write device drivers and such
like where it is important not to continually allocate objects.
      

> I'm looking at the same, but for seriously different specs.
>
> My interest would be to run ocaml apps on a Raspberry PI baremetal.
> Basically what openmirage does for the cloud (x86 VMs) but for
> Raspberry PI and similar dimensioned arm boards.
> 
> So targets would be ARMv6 / ARMv7 cpus with 128MB - 2GB ram, USB,
> HDMI, ethernet (often via USB), serial and an SD card.

Mirage is just a collection of libraries that implement useful
kernel functionality (e.g. a TCP/IP stack), so you can quite easily
retarget it to bare metal rPis with a suitable mini operating system.

There are several such available (or just start from uBoot), and
then get a basic console working to get some output. Dave Scott
has written a VNC library in OCaml that's available from his Github,
so you could work on some framebuffer rasterization after that.

The essential approach is to start in small steps: get serial console
working, then basic timer integration, and then hook in higher level
libraries from those.

(We're working on a Xen/ARM Mirage backend at the moment, but only
because we can't be bothered to write all the physical device drivers
that an rPi would need -- I'd be happy to merge in a "bare-metal"
ARM backend for the rPi as well).

> I'm familiar with the hardware side, how to boot, how to initialize
> the devices, how to get a picture to show on the HDMI and so on. What
> I lack is knowledge in creating a new runtime library for ocaml that
> runs directly on the hardware, or with just a verry thin hardware
> abstraction layer.

You don't really need a new runtime library; just a barebones C library.
Gabor Pali has a variant of Mirage that compiles into a FreeBSD kernel
module, for example, which operates in a similar "baremetal" environment.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00316.html

I'm Lucas DiCioccio, founder of the Haskell-Paris user group.

I'll organize a "functional programming" conference track at the next
OWF/OSDC[1,2] conference, Sat. October, 5th (in Paris, France).

I'm looking for speakers willing to present something in close relation with
functional programming (e.g., a programming langage, a library or framework,
return on experience). Controversial topics are also welcome as long as the
talk is not a lenghty troll. The audience at OSDC is often heterogeneous,
hence your presentation should be, accessible to non experts.

Talks should be circa 25min, in English or French. You can submit a talk
by sending me a title and a short description of the content.
I'll take the responsibility to do the editor and mix topics.

There will also be a lightning talk sessions (5 min. sharp), randomized
selection. You can register now via email or during the presentation break.
Lightning talks will be beamed from my computer and I accept only PDF/HTML.

Regards,

--Lucas DiCioccio

[1] http://openworldforum.org/
[2] http://osdc.fr/
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00319.html

I am pleased to announce the initial version of SIunits, a simple library that
provides run-time checking of, and conversion between, units associated with
numerical values. Despite the name, non-SI units can easily be defined and
used.

The code is available at http://hub.darcs.net/rgm/SIunits and the
documentation can be found at http://robmoss.github.io/SIunits/SIunits.html
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00318.html

> Is there a moderately official place to find this package?  I find
> mention of in various places, but the links to source archives seem to
> all have gone stale.  I found one place where somebody had imported
> the source into another project:
>
>    https://github.com/aryx/lfs.git
>
> But that was it.  Anybody else know where an unmodified source might
> be found?  (I found a sourceforge project, but again, 'way too old).

How about this package in GODI?

http://docs.camlcity.org/docs/godipkg/4.00/godi-ocamlbdb
      

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.ocaml.org/.

Goaljobs, part 4:
  http://rwmj.wordpress.com/2013/09/20/goaljobs-part-4/

Goaljobs, part 3:
  http://rwmj.wordpress.com/2013/09/20/goaljobs-part-3/

OPAM 1.1 beta available, with pretty colours:
  http://anil.recoil.org/2013/09/20/opam-1-1-beta.html
      

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