Hello
Here is the latest OCaml Weekly News, for the week of January 28 to February 04, 2014.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00249.html
Louis Gesbert announced:
We are proud to announce that OPAM 1.1.1 has just been released.
This minor release features mostly stability and UI/doc improvements over OPAM
1.1.0, but also focuses on improving the API and tools to be a better base for
the platform (functions for opam-doc, interface with tools like opamfu and
opam-installer). Lots of bigger changes are in the works, and will be merged
progressively after this release.
== Installing ==
Installation instruction are available here:
http://opam.ocaml.org/doc/Quick_Install.html
Note that some packages may take a few days until they get out of the pipeline.
If you're eager to get 1.1.1, either use our binary installer:
https://raw.github.com/ocaml/opam/master/shell/opam_installer.sh
or compile from source:
https://github.com/ocaml/opam/releases/tag/1.1.1
== About OPAM ==
OPAM is a source-based package manager for OCaml. It supports multiple
simultaneous compiler installations, flexible package constraints, and a
Git-friendly development workflow. OPAM is edited and maintained by OCamlPro,
with continuous support from OCaml Labs and the community at large (including
its main industrial users such as Jane-Street and Citrix).
The "official" package repository is now hosted at https://opam.ocaml.org,
synchronised with the Git repository at http://github.com/ocaml/opam-repository,
where you can contribute new packages descriptions. Those are under a CC0
license, a.k.a. public domain, to ensure they will always belong to the
community.
Thanks to all of you who have helped build this repository and made OPAM such a
success.
== Changes ==
From the changelog:
* Fix `opam-admin make <packages> -r` (#990)
* Explicitly prettyprint list of lists, to fix `opam-admin depexts` (#997)
* Tell the user which fields is invalid in a configuration file (#1016)
* Add `OpamSolver.empty_universe` for flexible universe instantiation (#1033)
* Add `OpamFormula.eval_relop` and `OpamFormula.check_relop` (#1042)
* Change `OpamCompiler.compare` to match `Pervasives.compare` (#1042)
* Add `OpamCompiler.eval_relop` (#1042)
* Add `OpamPackage.Name.compare` (#1046)
* Add types `version_constraint` and `version_formula` to `OpamFormula` (#1046)
* Clearer command aliases. Made `info` an alias for `show` and added the alias
`uninstall` (#944)
* Fixed `opam init --root=<relative path>` (#1047)
* Display OS constraints in `opam info` (#1052)
* Add a new 'opam-installer' script to make `.install` files usable outside of
opam (#1026)
* Add a `--resolve` option to `opam-admin make` that builds just the archives
you need for a specific installation (#1031)
* Fixed handling of spaces in filenames in internal files (#1014)
* Replace calls to `which` by a more portable call (#1061)
* Fixed generation of the init scripts in some cases (#1011)
* Better reports on package patch errors (#987, #988)
* More accurate warnings for unknown package dependencies (#1079)
* Added `opam config report` to help with bug reports (#1034)
* Do not reinstall dev packages with `opam upgrade <pkg>` (#1001)
* Be more careful with `opam init` to a non-empty root directory (#974)
* Cleanup build-dir after successful compiler installation to save on space
(#1006)
* Improved OSX compatibility in the external solver tools (#1074)
* Fixed messages printed on update that were plain wrong (#1030)
* Improved detection of meaningful changes from upstream packages to trigger
recompilation
Ian Zimmerman asked and Anil Madhavapeddy replied:
> If I upgrade, can I keep my existing ~/.opam or do I have to rebuild
> everything?
OPAM 1.1.1 shouldn't change the ~/.opam format at all, so you can
interchange OPAM 1.1.0 and 1.1.1 without any problems.
If you do spot some incompatibility, please let us know.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00254.html
Gabriel Scherer announced:
TL;DR: During the six next months, we will follow pull requests (PR)
posted on the github mirror of the OCaml distribution, as an
alternative to the mantis bugtracker. This experiment hopes to attract
more people to participate in the extremely helpful and surprisingly
rewarding activity of patch reviews.
Dear OCaml community,
I think we need more people ready to review patches proposed for
inclusion in the OCaml compiler/distribution; lack of reviews is
currently one of the bottleneck in the development process -- among
others, such as the sheer difficulty to reach consensus on any change
to the language itself. Doing patch reviews is helpful, extremely
interesting, and an excellent way to get to know more about small
parts of the compiler.
There was a resurgence of discussions on caml-list (Yotam Barnoy's
[moving to github] and Adrien Nader's thoughtful proposal of
a [mailing-list for patch review]). Amir Chaudhry launched a poll to
record decreasing order of preference, and the [results] are
clear-cut: people hate Mantis' guts, and would rather use anything
else.
[moving to github]: http://alan.petitepomme.net/cwn/2013.12.24.html#5
[mailing-list for patch review]:
https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00055.html
[results]: https://docs.google.com/forms/d/1QWhqJRv1yPvdi6E3AiqbvUwlqGorV_Wbk7h_JYuDUiQ/viewanalytics
I declare open the following experiment: for six months, starting
today upto late July, patches proposed for the OCaml distribution may
be submitted as a pull request (PR) on the [main github mirror], and
we warmly encourage anyone to review the proposed patches, and make
any comments they feel can help. Anything that can help improve the
contribution, or discuss potential issues (backward compatibility,
future-proofiness of the change, alternative designs...) will speed up
the time between a patch proposal and a clear decision to integrate it
or not.
[main github mirror]: https://github.com/ocaml/ocaml/
In six months, we will reconsider, the default choice being to stop
using github and revert to a mantis-only workflow. In the meantime,
I will mirror the github PRs on the mantis side, so that contributors
that do not wish to use the github interface can continue working as
before. Patches and reviews are of course still welcome on mantis.
Note that github will *not* be used for issue tracking, only for patch
reviews. If you want to submit a patch against a bug discussed in
Mantis, or want to re-submit a patch already in Mantis (in the wild
hope of more eyeballs), feel free to send a github PR and link to it
from the bugtracker. Finally, the github mirror remains *read-only*:
if patches are accepted, the PR will be closed but will be committed
to the SVN first, and synced in git as usual.
We're just trying things to see if it works better. I hope it does. In
any case, thanks in advance for your participation -- whichever tool
you use. Happy hacking!
.
PS: If you want to get notified for all Pull Requests sent, you
(need a github account and) can click on the "Watch" button in the top
right of http://github.com/ocaml/ocaml to register for
notifications. In the [notification settings] page of your account,
you can set up notifications to get send by email and/or to the
(mostly useless) github notification web interface.
[notification settings](https://github.com/settings/notifications)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00253.html
Ömer Sinan Ağacan asked and Gerd Stolpmann replied:
> I want to be able to use some very big C libraries from OCaml and I
> want to automate process of writing bindings as much as possible. What
> are my options for this? Do we have any tools to generate bindings?
I ran into this question a couple of months ago. The options we have are
not really good (e.g. I tried camlidl before). Because of this I wrote
my own utility that is special-cased for my application (bindings of
gnutls):
https://godirepo.camlcity.org/wwwsvn/branches/onet4/code/tools/stubgen.ml?rev=1935&root=lib-ocamlnet2&view=auto
See here for an example how to use it:
https://godirepo.camlcity.org/wwwsvn/branches/onet4/code/src/nettls-gnutls/?root=lib-ocamlnet2
especially gnutls.descr. Basically, this a little OCaml program, and by
calling a function (called "standard") you generate a binding, e.g.
standard "gnutls_alert_description_t gnutls_alert_get (gnutls_session_t
session)"
The syntax in the string mimicks C header declarations, and can use
special data types like ztstr (for zero-terminated string).
I haven't found time to make something more systematic out of this idea.
Currently, the strong point of this method is that it is quite easy to
adapt it to your own needs.
Francois Berenger also replied:
I am not sure this is what you are looking for, but there is this in OPAM:
ctypes -- Combinators for binding to C libraries without writing any C
https://github.com/ocamllabs/ocaml-ctypes
There is also this:
cstruct -- access C structures via a camlp4 extension
Adrien Nader also replied:
Some time ago I've started a project named "cowboy" (because it makes
bindings...) which could match what you're looking for. I've been using
it to generate lablgtk-compatible bindings to webkit-gtk and more
generally glib-based libraries since they all share the same
conventions.
In a few words, it's yacfe-light, an AST-simplification layer and a
custom output.
Now, for the full explanation.
1- Yacfe-light
Yacfe-light is a parser for unpreprocessed C (and C++ and Java). This
means it can extract more programmer-level information than other
parsers. Consider these code excerpts from my
/usr/include/webkit/webkitwebview.h:
#include <webkit/webkitwebbackforwardlist.h>
#include <webkit/webkitwebframe.h>
#include <webkit/webkitwebhistoryitem.h>
This module depends on "webkitwebbackforwardlist", "webkitwebframe",
"webkitwebhistoryitem" (and a few others).
#define WEBKIT_TYPE_WEB_VIEW (webkit_web_view_get_type())
We can also see that the short name of the module is "WEB_VIEW".
struct _WebKitWebViewClass {
GtkContainerClass parent_class;
/*< public >*/
[...]
/* internal */
void (* set_scroll_adjustments) (WebKitWebView *web_view,
[...]
/* Padding for future expansion */
void (*_webkit_reserved0) (void);
[...]
}
struct _WebKitWebViewClass is the central object to this library. It has
a "parent_class" which is used for inheritance in glib-based libraries.
Some of the elements in that class are for internal use and some of
them are merely padding for future extension of the object without
changing its ABI.
#if !defined(WEBKIT_DISABLE_DEPRECATED)
WEBKIT_API GdkPixbuf *
webkit_web_view_get_icon_pixbuf (WebKitWebView *web_view);
#endif
And one last bit is there is an API (as seen by the "WEBKIT_API"
attribute) which is available but deprecated.
Most of these bits would go away with a regular C parser which requires
the code to be preprocessed through 'cpp' first: there would be many
more lines of code, names and comments wouldn't be preserved, macros
which mean something to the programmer would be expanded to an
unreadable form and some lines would be dropped.
2- AST simplication layer
Yacfe-light is great. But it's a parser for a quite large language and
it tries to extract as much information as possible. It also cares about
the implementation of functions while this doesn't matter for binding
generation.
That's why cowboy has a layer to strip most of it and offer something
simpler.
3- Output
The last step is to output the actual bindings. I believe that large and
mature libraries require a specific backend. They have their own
API-style and it shouldn't be handled in a generic way since it would
make the bindings much lower-level and less pleasant to use.
In practice, for my glib backend which outputs code to be used with
lablgtk, this means (output of 'wc -l *.ml'):
128 glib.ml -> main module which call others
29 glibAnnots.ml -> don't remember
71 glibC.ml -> .c file with the low-level code
98 glibFixes.ml -> work-arounds for inconsistencies in the C libs
158 glibG.ml -> g${Library}.ml file (lablgtk convention)
68 glibGtk.ml -> gtk${Library}.ml file (lablgtk convention)
23 glibGtkTypes.ml -> outputs type declarations
27 glibH.ml -> .h file with type conversion macros (Val_foo())
190 glibLasso.ml -> parsing of names following the glib conventions
14 glibMETA.ml -> outputs a META file for use with ocamlfind
32 glibOCaml.ml -> translate between C and ocaml type names
45 glibOasis.ml -> outputs a _oasis file
27 glibObjects.ml -> don't remember
240 glibProps.ml -> outputs a ".props" file which is parsed by a
lablgtk tool which then outputs several files
83 glibVar.ml -> outputs a ".var" file which is parsed by a
lablgtk tool which then outputs several files
Glib and lablgtk compat are probably more than what most large libraries
would require though and you can get something useful in way fewer lines
than that. The most annoying bit was definitely the names in glib-based
libraries: alternating between "WEBKIT_WEB_VIEW", "WebKitWebView",
"webkit_web_view_*", ... telling the code to understand that as "web"
and "kit" or as "webkit".
I also haven't had much trouble with updating and newer versions of the
C libraries and have been fairly happy to have spent some time working
on the automation.
Caveats:
I haven't been able to work on it recently and the code could most
probably be improved but it the codebase isn't huge either and it
doesn't have dead corpses in it.
Yacfe-light doesn't enjoy C++ that much. This means that a .cpp file
will make it choke even though the only functions you're interested in
are C ones.
Automation is useful for large and/or evolving libraries which have
conventions. For instance, for glib, the headers all have the same
shapes, they use the same macros and the "object" always goes in the
first argument of the function. PHP's API on the other hand is
everything but consistent.
I think that should cover most of it. As I've said, I haven't updated
cowboy recently. I haven't had much time and I will be horribly until
the end of FOSDEM since I'm presenting there (which is sunday :) ).
Adrien Nader soon added:
Woops, forgot to link to the website:
https://forge.ocamlcore.org/projects/cowboy/
http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=cowboy/cowboy.git;a=summary
I also forgot to mention that yacfe-light wasn't neatly
packaged/packageable as far as I know; that's something I have worked on
but not published and I can do so next week.
Adrien Nader finally said:
I've been told over IRC that I made it sound like cowboy is a pet
project that is very young, experimental and/or incomplete.
That is definitely not the case and for the glib-based libraries
support, it binds dozens and dozens of data structures, thousands of
functions and, in the case of webkit-gtk, it generates 12k lines of code
(C, OCaml and lablgtk-specific domain-specific languages).
Xavier Leroy also replied to the original message:
> I want to be able to use some very big C libraries from OCaml and I
> want to automate process of writing bindings as much as possible. What
> are my options for this? Do we have any tools to generate bindings?
Yes, several:
- Ctypes https://github.com/ocamllabs/ocaml-ctypes
- CamlIDL http://forge.ocamlcore.org/projects/camlidl/
- SWIG http://www.swig.org/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00255.html
Markus Weißmann asked and Jeremie Dimino replied:
> on Linux there is support for a socket family "PF_CAN" for the CAN bus
> (controller area network bus) [1].
> I was wondering if anyone is/was working on
> 1) support for PF_CAN for the standard Unix socket in OCaml (see example
> code on [2])
> 2) some kind of OCaml CAN library/separate bindings for aforementioned
> socket domain
> 3) an OCaml library/tool on top of CAN, e.g. some CAN controller, a
> DeviceNET or CANOpen library
> and of course if 1) would be an acceptable patch for the standard
> library or if it would be considered "too exotic", given that there
> aren't many domains supported by the OCaml/Unix socket right now ('only'
> PF_UNIX, PF_INET and PF_INET6).
>
> Best regards
> Markus
>
> [1] https://gitorious.org/linux-can/
> [2] http://en.wikipedia.org/wiki/SocketCAN
I wrote stubs for using CAN sockets a long time ago. We used it for the
control system of a robot. The code is here:
http://sourceforge.net/p/krobot/krobot/ci/master/tree/info/control2011/src/can/
and the definition of CAN frames is in this file:
http://sourceforge.net/p/krobot/krobot/ci/master/tree/info/control2011/src/lib/krobot_can.mli
It should be easy to extract the code from the project if you want to
reuse it.
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/.
Extending OCaml in C++ - Boost.Date Time example:
http://shayne-fletcher.blogspot.com/2014/02/extending-ocaml-in-c-boostdate-time.html
Build native Win32 x86_64 OCaml 4.01.0 on Windows 8.1:
http://shayne-fletcher.blogspot.com/2014/02/build-native-win32-x8664-ocaml-4010-on.html
Papers, papers, papers:
http://gallium.inria.fr/blog/papers-please
Experiment: OCaml patch review on github.com/ocaml/ocaml:
http://gallium.inria.fr/blog/patch-review-on-github
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.