Hello
Here is the latest Caml Weekly News, for the week of September 17 to 24, 2013.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00257.html
Jon Harrop asked and Anil Madhavapeddy replied:> 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.Thomas Sibut-Pinote also replied:
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.ocamlKristopher Micinski said and Ivan Gotovchits suggested:
> 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/Kristopher Micinski then said and Xavier Clerc added:
> 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?Kristopher Micinski said and Xavier Clerc replied:
> 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.Alexandre Pilkiewicz said:
http://gallium.inria.fr/blog/ocaml-on-a-nexus-7/Richard Mortier suggested and Xavier Clerc replied:
> 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
Continuing the thread on this release, Nicolas Braud-Santoni announced: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
Deep in this thread, Alain Frisch said: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! )))Daniel Bünzli replied:
> - 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.htmlAndreas Rossberg then added:
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
Thomas Gazagnaire announced: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 switchAnil Madhavapeddy then added:
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
Dwight Schauer asked: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?).Gerd Stolpmann asked and Dwight Schauer replied:
> 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.Gerd Stolpmann then said:
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).Jonathan Kimmitt also replied:
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.Goswin von Brederlow asked and Anil Madhavapeddy replied:
> 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
Lucas DiCioccio announced: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
Rob Moss announced: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
Chet Murthy asked and Francois Berenger replied:> 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
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.