Hello
Here is the latest Caml Weekly News, for the week of July 16 to 23, 2013.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-07/msg00121.html
Anil Madhavapeddy announced:I've put together two Ubuntu PPAs to make it more convenient to use modern OCaml/OPAM versions on Ubuntu via binary packages. OPAM stable: https://launchpad.net/~avsm/+archive/ppa This includes the latest stable OCaml (4.00.1) and OPAM (1.0.0). OPAM unstable: https://launchpad.net/~avsm/+archive/ppa-opam-unstable This includes the latest snapshot of OCaml (4.01.0dev) and OPAM (1.0.1dev). This should get you reasonably stable snapshot of both, and will include the release candidates of OCaml when it's released. For now, these are experimental PPAs as I muddle my way through learning how Debian packaging works. Reports of breakage or success to me directly would be appreciated. Most of this PPA was based on the excellent Debian package sources, and thanks to Mehdid Dogguy in particular for the OPAM packaging.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-07/msg00128.html
Edgar Friendly announced:It's been a while since 2.0, and batteries has had a bunch of improvements that should be shared with a wider audience. More features, more bugfixes, more batteries. Thanks to the *many* contributors in this release; batteries exists because of you. E. Changelog: Added: Array.{avg,favg,singleton}, Bigarray.of_enum, Hashtbl.{modify,modify_def,modify_opt,map_inplace,filter_inplace,filter_opt_inplace}, IMap.{modify,modify_def,modify_opt}, LazyList.lazy_fold_right, List.{singleton,unfold,min_max,modify,modify_dep,modify_opt, span, nsplit, group_consecutive}, Map.modify_opt (*3), MultiMap.modify_opt (*3), MultiPMap.modify_opt (*3), Option.{default_delayed , map_default_delayed}, Set.find, Set.Incubator.op_map, String.rev, Substring.{equal,contains,iteri,enum} Fixed: Compilation with Ocaml 4.01 Speedup in LazyList.append More organized magic for fast list snoc Speedup in String.{replace,nreplace} Cleanup int32.[un]pack exceptions Fix last bit access in BatBitSet Float.round corner case on predecessor of 0.5 fixed Fix Enum.concat's clone implementation Fix List.n_cartesian_product to allow empty input Fix BatText.rfind's index calculation Improve Pervasives.undefined to be curry-able Array.backwards doesn't clone array anymore Remove useless allocation in Splay.cfind More unit tests, benchmarks
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-07/msg00135.html
Romain Bardou asked:I plan on writing yet another library to help with concurrency in OCaml. The motivations for this library, and the interface I have in mind, are available here: http://romain.bardou.fr/procord/api/Procord.html Before actually implementing the library, I would be very happy to receive feedback. I am interested to know, among others: - whether I miss important information which would make the very existence of this library stupid (such as, it already exists); - whether I forgot some important use case; - whether the names I chose have better ubiquitous equivalents; - whether you believe I should choose another interface entirely, for instance, if you don't like functors.Török Edwin then said and Romain Bardou replied:
> Processing streams of data in parallel without having to read all the data > in memory first. Good point. I'm not sure how to deal with this and I actually think it calls for a slightly different paradigm. Although maybe one could eventually add send/receive functions to send/receive to/from an 'a process, and the same for the worker. It would allow to transmit more than one input and more than one output. > You could sort of do this with your current interface but only on Unix > (i.e. mkfifo and pass filename). > Don't know what'd work on Windows, perhaps creating a (named) pipe, and > sending the file descriptor to a newly spawned child? I don't think there are named pipes on Windows but I may be wrong. Maybe it can be emulated using files anyway. I don't think sending a file descriptor is a good idea but sending a file name is of course possible. > Also it'd be nice to have something similar to the reduce in map-reduce. That's definitely something I want to be able to add easily. It won't be in the initial version, as I have no need for it right now, but it is important for me that it can easily be added, maybe as a new layer on top of Procord itself. >> - whether the names I chose have better ubiquitous equivalents; >> - whether you believe I should choose another interface entirely, for >> instance, if you don't like functors. > > I'd prefer if there was also a Lwt-like monadic interface, but it is not > absolutely required (it could probably be done on top of your already > existing interface). That is also something I want to be able to add easily, but I don't want Procord to depend on anything and to force one library. The user should be able to choose Async or Lwt or whatever. This is why I propose get_file_descriptors and process_status. It should be easy to write a Lwt using that. It would be possible to provide separate modules Procord_lwt and Procord_async as interfaces though.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-07/msg00152.html
Gerd Stolpmann announced:I'm happy to announce ocamlnet-3.6.6. This is a pure bug fixing release. Details about this release can be found on the project page: http://projects.camlcity.org/projects/ocamlnet.html See ChageLog for a detailed list of changes: http://projects.camlcity.org/projects/dl/ocamlnet-3.6.6/ChangeLog
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-07/msg00199.html
Gerd Stolpmann announced, starting a huge thread. Here is an excerpt of his message:Unfortunately, it is no longer possible for me to run the GODI distribution. GODI will not upgrade to OCaml 4.01 once it is out, and it will shut down the public service in the course of September 2013. The website, camlcity.org, will remain up, but with reduced content. Existing GODI installations can be continued to be used, but upgrades or bugfixes will not be available when GODI is off. Although there are still a lot of GODI users, it is unavoidable to shut GODI down due to lack of supporters, especially package developers. I was more or less alone in the past months, and my time contingent will not allow it to do the upgrade to OCaml 4.01 alone (when it is released). Also, there was a lot of noise about a competing packaging system for OCaml in the past weeks: OPAM. Apparently, it got a lot of attention both from individuals and from organizations. As I see it, the OCaml community is too small to support two systems, and so in some sense GODI is displaced by OPAM. The sad part is that OPAM is only clearly better in one point, namely in interacting with the community (via Github). In times where social networks are worth billions this is probably the striking point. It doesn't matter that OPAM lacks core functions like deleting all files when a package is removed, and that it lacks many other features GODI has. So there is some loss of functionality for the community (partly difficult to replace, like GODI's support for Windows). If somebody wants to take over GODI, please do so. The source code is still available as well as the package directories. Maybe it is sufficient to move the repository to a public place and to redesign the package release process to give GODI a restart.
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/. Batteries 2.1 released: https://forge.ocamlcore.org/forum/forum.php?forum_id=880 GODI is shutting down: http://blog.camlcity.org/blog/godi_shutdown.html Creating Xen block devices with Mirage: http://www.openmirage.org/blog/xen-block-devices-with-mirage
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.