No subject
Tue Sep 24 01:15:06 PDT 2013
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.
========================================================================
2) OCaml release 4.01.0
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>
========================================================================
3) OCaml vs Ada and/or GUI options
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.html>
** Andreas 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.
========================================================================
4) Beta release of OPAM 1.1.0
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 switch
** Anil 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.
========================================================================
5) Ocaml on an embedded arm system (no linux)
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.
========================================================================
6) Call for Talks - Open World Forum / OSDC
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/>
========================================================================
7) SIunits 0.1
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>
========================================================================
8) ocaml interface to berkeley db?
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>
========================================================================
9) 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.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
(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/> .
========================================================================
More information about the caml-news-weekly
mailing list