Hello
Here is the latest OCaml Weekly News, for the week of April 21 to 28, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-04/msg00105.html
Continuing the thread from last week, Richard Jones said:
> What is the current suggested way to determine what, roughly, autoconf
> would do for you? I have some platform specific functionality to be
> included (or excluded) depending on the OS.
Is there a reason not to use autoconf? I use it all the time with
OCaml projects, eg:
https://github.com/libguestfs/libguestfs
https://github.com/libguestfs/supermin
and a random more recent example:
http://git.annexia.org/?p=mclu.git;a=tree
There are ocaml.m4 macros on ocamlforge.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-04/msg00112.html
Jürgen Hötzel announced:
I implemented some basics systemd bindings (just journal functions at the
moment):
https://github.com/juergenhoetzel/ocaml-systemd
Any feedback is appreciated.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-04/msg00125.html
Leo Wzukw announced:
I developed since about a year a tools named OcLaunch. It allow to spread
launch of program across session, each time a terminal (or anything else) is
called.
For example, you may want to launch a client chat and several TODO list, and
then verify update. If add all to your .bashrc, the output will be displayed
every time it is sourced, i. e. each time you open a terminal. What a mess!
With OcLaunch, these commands are launched one at time. So
* You open your first terminal: the client chat is launched
* You open the second one: a TODO list is displayed
* ... and so on
An other advantage is that your reminder are spread across your session, which
remind you important task several times and may limit procrastination!
Official website is http://oclaunch.tuxfamily.org/home.html. You can find a
demo video if the purpose of OcLaunch is not clear and several resources.
Email me if you need some help or to give feedback.
Leo
PS: People reading French may be interested by this page :
http://linuxfr.org/news/oclaunch-launch-automagically
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-04/msg00131.html
Alain Frisch announced:
LexiFi is currently experimenting with the js_of_ocaml compiler in order to
create some browser-side applications in OCaml. In this context, we have
started a new project called gen_js_api which aims at simplifying the creation
of bindings to Javascript libraries.
The approach is quite different from js_of_ocaml's native FFI (which relies on
language extensions). In gen_js_api, authors of bindings define the expected
OCaml interface, annotated with light attributes to define the actual mapping
to Javascript; and client of generated bindings work with native OCaml types,
without requiring any language extension, nor any knowledge of how js_of_ocaml
represents OCaml values in Javascript.
gen_js_api has reached a state where actual bindings can be written, and it is
reasonably well documented. It is now a good time to look at the project if
you're interested in this topic. Of course, feel free to comment on the
project or contribute to it.
Project page:
https://github.com/alainfrisch/gen_js_api
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-04/msg00132.html
Helmut Brandl asked:
I am currently writing a software package in ocaml and I want to be able to
compile it from ocaml to javascript to be able to run it under nodejs. I have
found js_of_ocaml which seems to do a rather good job in compiling from
bytecode to javascript.
I achieved the compilation to javascript which can run under nodejs as long as
I don't use anything from the unix library. Unfortunately I need two functions
from the unix library: 1. Get the last modification time of a file. 2. Create
a directory. I cannot find anything equivalent in the standard library.
I tried to find some hints in the js_of_ocaml documentation but I haven't
succeeded because to documentation is hard to read.
Can anybody give me some hints on how to get these two functions in a way that
js_of_ocaml does the correct compilation?
Daniel Bünzli suggested:
If you are getting unknown primitive errors at link time then you can simply
try to implement them yourself using node's filesystem APIs see:
http://ocsigen.org/js_of_ocaml/2.5/manual/linker
If you are not concerned about using Unix directly (because node.js is your
only target) and simply need these functions you can bind the corresponding
node API functions directly:
http://ocsigen.org/js_of_ocaml/2.5/manual/bindings
Alain Frisch also suggested:
You need to define bindings to node.js' "fs" API:
https://nodejs.org/api/fs.html
It should be possible to implement a subset of the Unix module through this
API, or just to expose the few functions you would need.
For instance, with the gen_js_api I announced earlier today, binding the
synchronous mkdir function would look like:
val mkdir: string -> int -> unit
[@@js.global "fs.mkdirAsync"]
Daniel Bünzli then said and Alain Frisch replied:
> That should be "fs.mkdirSync".
Indeed!
> Just curious, how would the binding to the async fs.mkdir look like ?
Something like:
val mkdir_async: string -> int -> (js_exn option -> unit) -> unit
[@@js.global "fs.mkdir"]
assuming some predefined bindings for js_exn. (One could also decide to bind
JS exception to OCaml's exn type, but the gain is not clear.)
There are other possible variations, such as making the mode optional:
val mkdir_async:
string ->
?mode:(int[@js.default 0o777]) ->
(js_exn option -> unit) ->
unit
[@@js.global "fs.mkdir"]
Here js.default forces the default value for the optional mode argument.
Without it, a missing value will send an `undefined` as the second argument (I
don't know if fs.mkdir would be happy with it). This is currently not
supported, but one could also extend the tool to allow:
val mkdir_async:
string ->
?mode:(int[@js.drop_if_missing]) ->
(js_exn option -> unit) -> unit
[@@js.global "fs.mkdir"]
so that the second argument is dropped in the JS call if not provided (but
I don't see how to support that for OCaml callbacks in full generality, since
the function needs to check the type of arguments to decide how to interpret
them).
Alain Frisch later added:
> Here js.default forces the default value for the optional mode argument.
> Without it, a missing value will send an `undefined` as the second
> argument (I don't know if fs.mkdir would be happy with it).
Just to clarify: the issue here is that node.js documents the function as:
fs.mkdir(path[, mode], callback)
and its implementation is more liberal:
=================
function modeNum(m, def) {
if (util.isNumber(m))
return m;
if (util.isString(m))
return parseInt(m, 8);
if (def)
return modeNum(def);
return undefined;
}
fs.mkdir = function(path, mode, callback) {
if (util.isFunction(mode)) callback = mode;
...
modeNum(mode, 511 /*=0777*/)
...
};
=================
(welcome to Javascript wonderful calling conventions!)
So both conventions are supported to omit the mode argument:
fs.mkdir(path, undefined, callback)
fs.mkdir(path, callback)
(one could actually pass anything as the second argument as long as it is not
a number, not a string and not a function).
So it is ok to bind it simply as:
val mkdir_async: string -> ?mode:int -> (js_exn option -> unit) -> unit
[@@js.global "fs.mkdir"]
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocaml.org/.
CueKeeper: Gitting Things Done in the browser:
http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/
Generating Javascript bindings from OCaml interfaces:
http://www.lexifi.com/blog/generating-javascript-bindings-ocaml-interfaces
Coq 8.5 beta 2 is out!:
https://coq.inria.fr/news/125.html
Recover the good old C-x C-b (list-buffers) behaviour around Emacs 24.4 and later:
http://camlspotter.blogspot.com/2015/04/recover-good-old-c-x-c-b-list-buffers.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.