Hello
Here is the latest Caml Weekly News, for the week of October 16 to 23, 2012.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00087.html
Mike Lin asked and William Le Ferrand replied:
> I'm curious what kind of critical mass there might be for an OCaml
> meetup/UG in Silicon Valley. Who's around? Has this been tried/failed
> before?
There used to be "OCaml dinners" in bay area, 3 or 4 were organized
about 1 year ago. At some point we even held a little hackathon
resulting in a small website for posting ocaml challenges (code should
be at https://github.com/baoug), now deceased.
Ashish Agarwal then added:
Mike, I suggest you just start a group on http://meetup.com. We've
had good success with the NYC OCaml Meetup (and it's not just because
of Jane Street, indeed most of our members are not from Jane Street).
The hard work is in recruiting speakers to give talks, organize
hack-a-thons, etc., but it only takes a couple committed people to
make it work.
And once you start it, be sure to let the http://ocaml.org dev team
know so we can add it to the new website under the Meetings section.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00090.html
malc announced:
New version of llpp (tagged v13) is now available at
http://repo.or.cz/w/llpp.git
Blurb:
llpp a graphical PDF viewer which aims to superficially resemble
less(1)
Changes:
* Bugfixes
* Presentation mode in multi column case
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00098.html
Yaron Minsky announced:
A thing that should be of interest to many on this list. We discussed
this already at the OCaml Users and Developers conference, but we're
now talking about it more widely: a new lab is being formed at
Cambridge University that is focused on improving the OCaml ecosystem.
Jane Street is the primary funder, and Anil Madhavapeddy is the
technical lead.
If you're interested in reading a bit more about it, both Anil and I
have posts about it:
- https://ocaml.janestreet.com/?q=node/109
- http://anil.recoil.org/2012/10/19/announcing-ocaml-labs.html
We hope and expect this effort to add to the energy and excitement of
the OCaml community, and to contribute materially to the software
infrastructure we all depend on.
Paolo Donadeo asked and Anil Madhavapeddy replied:
> While I'm very grateful for your effort and while anxiously waiting for
> your book, I notice that in your post you mention a brand new package
> manager, OPAM.
>
> Do we really need of yet another package manager? How can't OPAM scatter
> the community further?
>
> Now, if I write a small library and I want to make it available to OCaml
> developers, I have to care about: making the source code Debian and Red Hat
> friendly, godi friendly, oasis-db friendly and, now, OPAM. And there are
> probably other systems I don't even know.
>
This is certainly a valid criticism given the current state of affairs,
but I would encourage you to listen to Thomas' talk to OUD to get an
overview of why OPAM came about, and where it's going:
http://www.youtube.com/watch?v=ivLqeRZJTGs
OPAM has picked up lessons from all the other previous package managers,
and is, as Markus noted, a generally pleasant experience for beginners to
use. It supports a nice workflow for developing libraries, has
first-class support for multiple repositories (either DVCS or local
archives), and simultaneous installations of multiple standard libraries.
Just this by itself probably wouldnt justify a brand new package manager,
and the longer term plan is tighter integration with OASIS, ocamlbuild and
the many other build systems available. Ultimately, we want to make it
really easy for a beginner to jump in, write their own code, reuse other
peoples code, and publish it online. There have been a number of (very
brave and good) pieces of this puzzle over the years (notably OASIS), but
OPAM aims to pull them all together into an integrated whole.
You'll see much more of this in the next few months as OCaml Labs spins up
and begins supporting OCamlPro more in their efforts. The first thing
we're doing is to get the ocaml.org infrastructure in place (and moving
over the excellent ocaml-lang.org over to the new domain), and part of
that work will be to figure out the unification of OASIS-DB, OPAM and
other package managers into one site. I'm personally aiming for a demo at
the OCaml Consortium meeting in late November, and then it'll be announced
on the list. Much of the work on OPAM has been guided by the requirements
of the bigger industrial members of the Consortium, such as Jane Street
and Citrix (e.g. support for private repositories).
I'll send out more details about this work shortly. Meanwhile, if you're
interested in working on it full-time, please do apply for the jobs at
OCaml Labs, and get in touch with questions. It's going to be fun!
Later on, Paolo Donadeo asked and Fabrice Le Fessant replied:
I should stress that there has been no official announce of OPAM,
because it is still considered as unstable, but it should be
officially released soon... One of the major differences with other
package managers for OCaml for me is its ability to maintain different
trees, for different versions of the compiler, allowing to test easily
a new version or a patch.
> A question: can OPAM live in peace with odb.ml or GODI? In this moment
> my environment is built with GODI (for compiler and major libraries)
> and what is not present in GODI is installed with odb.ml, which
> installs everything in ~/.odb, no conflict with /opt/godi/...
OPAM installs its packages in ~/.opam/, so there will be no conflict
in the installation.
> Can I
> say to OPAM to ignore a dependency, for example can I install an OPAM
> package which depends on Batteries, while Batteries installed with
> GODI?
The purpose of OPAM is to manage the versions of installed packages,
so that if some package needs a new version of another package, it
would be able to upgrade that package. If some packages are managed
outside of OPAM, it will not be able to upgrade them, and upgrading
them with another package manager will break the consistency between
the packages. So, you probably don't want to do that.
Packaging a library for OPAM is quite simple (you just need to explain
how to build it, i.e. usually ./configure; make; make install), and
the repository is available on Github, so uploading a package is just
sending a pull-request there...
Addrien Nader also replied to the initial post:
Since the topic of package managers has been started, I'd like to
stress a few things about yypkg which I write.
Yypkg is a dumb binary package manager which works everywhere OCaml,
bsdtar and xz work. It doesn't care about what is inside packages, it
works in any directory (not only /), and it's meant for developers
more than for admins (it doesn't try [yet] to provide safe upgrade
paths for the whole universe).
As for other features of yypkg, it's very fast with very small
packages and the core code is only 500 lines of OCaml, comments
included.
That said, for other package managers, you also need to compare what
they're aiming at. Godi is a full-fledge system, odb.ml has a way
smaller scope. I don't know enough about OPAM to comment on it.
As for the library you'd be writing, please, please, forget about
specific package managers when writing it! You only need a few things:
don't make your own build system but use a well-known one and use
pkg-config if it's C/C++ or ocamlfind if it's OCaml. Nothing more.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00116.html
Gerd Stolpmann announced:
There are some news about GODI, the still alive OCaml distribution:
(1) A new version of the GODI software (godi-tools) has been
released, with a bunch of new features, code name Skylift
(2) Accompanying godi-tools, there is also a new bootstrap,
now defaulting to OCaml-4.00
(3) There are two new GODI derivates easing the installation
on Windows.
*
1. Skylift
It has been possible for a long time to mix packages from various
sources, e.g. from the official GODI site, and from alternate sites.
However, this feature was well hidden, and a bit complicated to use.
Skylift eases this dramatically:
- It includes scripts for populating directories with packages to
export to the public (i.e. share your packages with others)
- The profile feature was added to exactly control from where to
take packages. The idea is that the user just installs a single
file ("profile") and then automatically gets the packages from the
sources described in this file. This makes it easy to import the
package sources shared by others.
For some environments, it is very meaningful to deviate from GODI's
source-only policy, and to create and distribute binary packages (i.e.
already compiled). To support this better, the binary packages (which
are also present almost since the beginning but were never noticed)
have been enhanced. They encode now the "binary compatibility status"
in a checksum that is appended to the filename, e.g.
foo-3.4@BUILD_65fd12.tar.gz, and also record extended information
about this issue within the package file. This means that you can have
several foo-3.4 packages that were built with distinct dependencies,
and GODI is clever enough to pick the right one. In addition to this,
GODI supports now also to download binary packages from remote
directories, and there is also a new UI dialog for this.
For developers, adding a patch to a GODI package has become easier:
just edit the file, and then run a command to record the change.
That's it now.
GODI is now also simpler to install, because you don't need wget nor
PCRE anymore for running the bootstrap: wget is gone because GODI has
now an included file downloader, and PCRE could be dropped by
rearranging some Ocamlnet packaging.
Read more about Skylift:
http://godi.camlcity.org/godi/project-doc/skylift-intro.txt
Skylift is now also described in the User's Manual:
http://godi.camlcity.org/godi/user-doc/umanual.html
You can get Skylift only by installing GODI freshly - there is no
upgrade path for existing installations.
2. The new bootstrap
The new bootstrap is
http://download.camlcity.org/download/godi-skylift-20121022.tar.gz
It works as before, but default now to install OCaml 4.00.1. Of
course, you can still select an older version of OCaml.
Note that the support for packages is still not perfect for OCaml
4.00, but many packages are already ported (by version bump or patch).
3. Windows (mingw)
Skylift also includes all changes to run together with Cygwin-1.7 (a
lot of the original GODI Windows support was bound to Cygwin-1.5).
This inspired two guys to further enhance the Windows experience:
- CygwinGODI (by Sébastien Fricker) is an installer that covers both Cygwin
and GODI: http://cygwingodi.forge.ocamlcore.org/
- WODI (by Andreas Hauptmann) goes even further, and creates a GODI
derivate with specially-adapted packages, and a new GUI. WODI
uses the new Skylift features for mixing packages sources, and for
providing binary packages: http://wodi.forge.ocamlcore.org/
Read more about GODI in general: http://godi.camlcity.org
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00120.html
Jon Ludlam asked:
Firstly I'd like to add another voice in support of opam - it's been a
very pleasant experience using it despite it's beta status, and so
many of the developers here have become dependent on it that we're
changing our XenServer/XCP build system to build everything using it.
Before opam is officially announced (!) I'd like to raise an issue
with versioning which people may like to consider. Currently opam has
several ways of specifying the location of the source tarball for a
package. By custom, the packages are broadly categorised into rapidly
developing packages and stable packages. For rapidly developing
packages, the source is often set to be a pointer to github to the
master branch, often because no 'stable' version exists. For stable
packages, the url is often a pointer to a tarball on the developers
website, or sometimes a tagged release from github.
For our purposes, we need to be able to ensure that our builds are
reproducible, and hence need to know exactly which versions are
installed. We had hoped to achieve this by removing or disabling
packages whose sources were got directly from a master branch in
github. However, it turns out that some packages that are 'stable' are
dependent upon these packages, which seems brittle. The question is
how to fix it? Should the opam repository maintainers require that
'stable' packages aren't dependent on 'unstable' ones? Should opam
itself be aware of the difference and enforce this policy? If someone
really wants to release a stable version of their thing and it's
dependent upon an upstream project with only a github repo, should the
developer engage the upstream devs and request at least a tag, or
should they make their own tarball/github fork?
Many of these questions are social rather than technical, hence I'm
posting to the general ocaml list.
Anil Madhavapeddy replied:
I ran into exactly this problem with Mirage, and have solved it for now by
having two separate OPAM remotes for the stable and development systems. A
continuous build system (Jenkins) installs all packages with and without the
development remote, and highlights any dependencies that have crept in on
every push.
I would like the ability to specify remote refs/tags/branches too, as Gabriel
suggests. This is worth a feature request at http://github.com/OCamlPro/opam,
preferably with an intended workflow of what you'd like.
For the purposes of reproducible builds, you may find that 'opam-mk-repo'
comes in useful on a checkout out package repository. It populates the
archives/ directory of a repository with a tarball containing the exact
archive snapshot. If an archive tarball is missing, OPAM attempts to create
it (via rsync/git), but if present, is treated as the most current tarball.
You could modify the XCP build system to run `opam-mk-repo` regularly and
preserve the contents of archives/.
(the latter may well be an undocumented feature of OPAM. Thomas Gazagnaire is
on vacation sailing the high seas at the moment. Unless we can get a friendly
seagull to deliver this query, it will probably have to wait for his return
next week).
Finally, for development purposes, you can also use 'opam pin' to force a
particular package to a development version:
$ opam pin mirage-net git://github.com/mirage/mirage-net
$ opam update
# this will refresh all the pinned remotes, either via rsync or git fetch
$ opam upgrade
# this will recompile all dependent libraries with the newest interface
$ opam pin mirage-net none
# this will unpin the package and go back to normal versioning.
With sufficiently cunning pinning, you may not need to use the development
remotes for day-to-day use at all.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00123.html
Peter Groves announced:
OCuality is an integrated logging, assertion, and unit testing
library.
This is the first open source release after several years of
development as part of the designByRobots project.
The goal of Ocuality is to create a straightforward, yet minimal, way
of defining certain property's of an application's types so that
assertions don't require vast amounts of type-specific boilerplate to
pack and unpack data structures to run a compare() function against.
Ocuality also tries to remove problems that occur when unit testing
libraries, built-in asserts methods, and logging libraries do not work
nicely together (such as java's assert() method, junit library, and
logging working against each other).
The key feature of Ocuality is the way assertions (via a module called
Verify) can be called from either application code or as part of a
unit test (via the TestCase module). When a Verify method fails or
(optionally) succeeds, an informative log message is generated. When a
suite of unit tests are run, the number of Verifications that succeed
or fail are summarized, as well as a detailed list of failing tests.
This approach to assertions requires a comparer ('a Comparer.t), which
is simply a toString() and compare() method for an abstract type ('a).
The Comparer module provides methods for composing higher order
Comparer.t's (e.g. create a ('a list Comparer.t) given a ('a
Comparer.t))) which are extremely powerful in creating simple yet
complete assertions in unit tests.
Project Home and Readme:
https://github.com/pgroves/ocuality
Example Code (executable version of examples in the Readme):
https://github.com/pgroves/ocuality/blob/master/src/ReadmeExample.ml
Feedback and feature suggestions are welcome on the project's github
issue tracker:
https://github.com/pgroves/ocuality/issues
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-10/msg00124.html
Philippe Veber asked and Jeremy Yallop replied:
> A couple of libraries, like pgocaml for instance, define a functor over a
> (monadic) thread implementation, like in the following:
>
> module type Thread = sig
> type 'a t
> val return : 'a -> 'a t
> val bind : 'a t -> ('a -> 'b t) -> 'b t
> end
>
> module F(T : Thread) : sig
> val v : string -> string T.t
> end
>
> Is it possible to define F as a function (ie at the value level)?
Yes! Matías Giovannini has a blog post showing how to do just that:
http://alaska-kamtchatka.blogspot.co.uk/2011/09/higher-order-fun.html
Gabriel Scherer also replied:
If you want to parametrize over arbitrary monads, the modularized
appraoch (using functors or first-class modules) is adapted. But note
that for more specialized needs different interfaces are possible. For
example, Daniel Bünzli experimented with explicit inversion of control
instead of parametrization by monadic library, to solve the problem of
being Lwt/Async/"event loop" agnostic:
[Caml-list] Non-blocking IO interface design
https://sympa.inria.fr/sympa/arc/caml-list/2012-04/msg00055.html
I'm not sure how this worked out in the end, but this may be worth
looking at if you're still at the general design step.
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.ocamlcore.org/.
Bootstrapping OCaml/async on the Raspberry Pi:
https://ocaml.janestreet.com/?q=node/110
Announcing OCaml Labs:
https://ocaml.janestreet.com/?q=node/109
Ocsigen HOWTO: call JS functions from OCaml:
http://ocsigen.org/
Announcing the OCaml Labs project:
http://anil.recoil.org/2012/10/19/announcing-ocaml-labs.html
Ocsigen HOWTO: call JS functions from OCaml:
http://ocsigen.org/
Breaking up is easy to do (with OPAM):
http://www.openmirage.org/blog/breaking-up-is-easy-with-opam
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.