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.htmlMike 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.htmlmalc 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.htmlYaron 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.htmlGerd 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.htmlJon 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.htmlPeter 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.htmlPhilippe 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.htmlGabriel 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.