Hello

Here is the latest OCaml Weekly News, for the week of January 27 to February 03, 2015.

1. Win-builds 1.5.0 - fully-bootstrapped free software distribution for Windows
2. record update-apply
3. Merlin 2.1 released
4. Simple compression library
5. Other OCaml News

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-01/msg00149.html

I am happy to announce the availability of Win-builds 1.5.0 which is the
result of many months of work in order to add new packages, update
available ones and make all operations simpler and more intuitive.

Homepage: http://win-builds.org
Downloads: http://win-builds.org/download.html
Documentation: http://win-builds.org/documentation.html
Support information (IRC, MLs): http://win-builds.org/support.html
Package list (informative): http://win-builds.org/packages.html
Source: http://cgit.notk.org/gitolite/win-builds/

=== Project Description ===

Win-build is best described as a free software distribution for Windows:
the goal isn't to provide dumps of binaries but to build something new,
well-integrated, easy to install and upgrade, focused on stability (but
without being out-of-date either), with a good package coverage and
identical binaries on Windows and Linux.

=== New in 1.5.0 ===

Complaints for the previous version centered around simplicity and
package coverage.
As such, this new version has focused on making it simpler to edit
packages (modifying existing packages or adding new ones) and install
thanks to more automated build steps on Linux and to the re-introduction
of a GUI on Windows.

==== New Packages ====

The package count has risen to 90. This may seem low compared to Linux
distributions but this is enough to build GUI applications using either
the EFLs, Qt and GTK+ (and many more). This makes a lot of sense if you
consider how many packages on Linux make little sense on Windows:
smartd, pciutils, all the X-related ones, KDE and Gnome, motif, mt, ...

==== GUI Package Manager and Installer on Windows ====

The GUI is written using ocaml-efl and is used as the installer on
Windows. The actual executable relies on several dozens of files
(libraries and resources) and is packed into a self-extracting (and
cleaning) executable to make it appear as a single file that can be
readily run[1].
Its build is not documented for this release as a sign that the ocaml
cross-compiler has some quirks[2]. Getting full and upstream support for
cross-compilation is however something I'll be working on
from now on.

==== More Scripted Installation on Linux ====

On the developer side, the component that runs all the build scripts has
been rewritten from shell script to OCaml. This provides a simple
validity check of the build list description and proper ordering of the
build steps, making it safer for people to do their own edits.

To honor the great tradition of OCaml programs taking advantage of
high-level optimizations, doesn't attempt to build several packages in
parallel for a given architecture. It however builds for two
architectures in parallel, thereby providing a reasonable efficiency.

==== Documentation ====

Documentation has been updated and expanded. It finally properly covers
the topic of creating new packages and is therefore now fairly
exhaustive when it comes to the win-builds project.

Over the next few days, the documentation will be expanded again to
cover more topics related to usage on Windows, in particular with IDEs.

=== Post-mortem and Future ===

This release took much longer than planned. Roughly twice as long. This
is due to two factor: adding the GUI for the package manager and
installer which was planned for the subsequent version, and Qt.

The GUI seems to have been worth it with much better download stats
and close to a hundred installations per day (more than +40%), without
additional publicity. [these numbers are guaranteed and not inflated by
anything]

Qt will be dealt with in a dedicated section below.

==== -next repository ====

The work leading to this version, as is most often the case, has made
apparent a number of issues with the development process. The main issue
is probably the time it takes between the addition of a feature request
and the availability of the corresponding package.

This has little to do with the actual packaging or updating work and
almost everything to do with the lack of a repository for the next
version. As such, starting with the first changes after 1.5.0, there
will be a "-next" version that will be regularly updated with packages
built from the latest code and publicly reachable.

==== New contributions: what has been done and what's coming up ====

A number of new contributors and contributions have appeared. Most
changes were fairly late in the development cycle and have therefore not
been merged in the main tree for 1.5.0.  

The code hosting has been moved to a gitolite in order to allow hosting
of branches from others. This is for added convenience and any
publicly-reachable git hosting is fine for merging back to the main
branches.

===== Qt =====

Some packages unfortunately require a lot of work with each new
version. Actually the set of such packages has only one inhabitant: Qt.

I'll be frank: maintaining a Qt that is cross-compiled from Linux for
Windows is probably close to a full-time part-time job, i.e. something
that will take all the time for someone doing part-time on it. My
perception is probably flawed since I've made the initial packaging and
it includes things that have probably never been done before and
definitely deviate from what upstream had in mind (i.e. cross-compile
qmake itself).

It is also unfortunately to be expected that each new version of Qt
breaks something for this packaging (cross-compile to Windows).

As such, additional maintainers are looked for. There is no reason to be
afraid and this is not about abandoning the package unless someone steps
up. This is entirely in order to be able to better track upstream
releases.

==== Security Updates ====

This part has mostly been a failure. The work involved was larger than
expected and was let slip by without bound.

Basically, the work (reading, updating the source, rebuilding, testing,
uploading, announcing) is sometimes too much to do immediately after the
availability of a security fix. With no strict bound and with the need
to spend time on large changes in the build architecture, the updates
have slipped by one day at a time. As usual, Frederick P. Brooks got it
right:
  Q: How does a large software project get to be one year late?
  A: One day at a time.

The larger architecture have been done. There will be others but they
should be less pervasive and shouldn't block working on other tasks for
as much time.

More importantly, at least for this release, the official goal is to
handle most security updates in 3 days at most and let none slip by more
than 8 days. This should be at least as good as most large Linux
distributions. Any security update lagging behind for more than that
should be considered "unnoticed" and a poke warranted.


PS

[1] It obviously takes some time to extract the 25MB or so (8MB
compressed) but it is fast enough and can most probably be made faster.
The main advantage however is that this solves the issue of replacing
files which are in-use: the package manager depends on .dll files and
therefore would have been unable to ever replace these without resorting
to complex tricks.

[2] Perhaps the best proof is the following top-level code:
  let init_count = ref 0
  let init () =
    if !init_count = 0 then (
      do_the_actual_init ();
      incr init_count;
    )
    else
      ()
  let () = init ()

On Windows I had to add an explicit call to the "init" function from
somewhere else in the code.
      

> Maybe this is a stupid question but given that you use OCaml for
> implementing and there is still no way to distribute opam packages for
> windows, could you not package ocaml/opam for your distribution and
> this way import all ocaml packages at once?

I want to make an ocaml cross-compiler actually available in win-builds
for people to use. There is already one in win-builds but it's not built
by default as it has too many (potential) quirks.

In the near future I'll work again on making cross-compilation upstream
for the ocaml compiler. Working on win-builds has also convinced me that
being able to cross-compile a compiler would be useful too. That would
make it possible to have a package that provides an ocaml compiler that
runs on Windows and targets Windows.

As far as opam is concerned, I currently don't intend to do anything
specific for it. The reason is that there's already a lot to do on
things that are not specific to opam and it's not sensible to expand my
TODO list. :) 
Another thing to note is that win-builds provides binary packages and
that doesn't match the usual opam usage. In any case, packages for ocaml
libraries and tools is planned and wished but a realistic schedule would
be in 6 months or more (time to get better ocaml cross-compiler, to test
it and to make more packages).

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-01/msg00152.html

I often find myself writing code like this

{foo with bar = f foo.bar}

and would like to avoid the redundancy of typing 'bar'. So it would be
very convenient to have an applied-to operator:

{foo with bar <- f}

This would only need one additional syntactic sort at the very first
stage, since the operator can immediately be de-sugared into the
already-existing with-form.

What do you think?
      

This is really the update function of a lens. Anil has taken a part of
a project that had contained a lens package into its own library,
https://github.com/avsm/ocaml-lens . Although a ppx library with
lenses would be most appropriate (since this is all still manual).
      

Fieldslib uses camlp4, but basically gets the job done.  A Field.t is
more or less a lens (you can write a simple function that constructs a
lens from a Field.t), so that gives you the basic bits you need.
We're going to do a ppx rewrite soon.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-01/msg00158.html

Merlin is an editor-independent tool to ease the developement of
programs in OCaml. It aims at providing features available in modern
IDEs such as: "as you type" error reporting, auto completion, source
browsing ("jump to definition"), extraction of type, ...

Merlin is available on opam and can be installed with `opam install
merlin`. It can also be built from sources, which are available at
http://github.com/the-lambda-church/merlin .

As always you can find a full changelog at
https://github.com/the-lambda-church/merlin/blob/master/CHANGELOG ,
but the highlights are :

- The introduction of support for PPX syntax extensions.

- The introduction of a "destruct" command for automatic match pattern
generation, as demonstrated on :
http://the-lambda-church.github.io/merlin/destruct.ogv

- Major changes to the vim plugin, introducing (among other things) a
type history buffer allowing one to navigate the history of printed
types and copy/paste them.

We want to thank: Geoff Gole, Rudi Grinberg, Markus Mottl, Roman
Vorobets and Arthur Wendling, who all contributed to this release.
We also thank JaneStreet for their continued support.

The Merlin team
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00006.html

I'm looking for a compression library such as camlzip to read/write
compressed files (any lossless compression algorithm is fine), but
having a function similar to Pervasives.output_value, which does not
seem to be available in camlzip (and I do not see how I could easily
implement it).

Would it be simple to modify camlzip to add this function? I believe
that if this were the case, then it would already have been done, but
I might be wrong.

Otherwise, is there another OCaml library with an API very similar to
Pervasives'? I'd prefer a lightweight solution (avoiding Core and
Batteries) if possible.
      

> Can't you do Marshal.to_string, and then use Camlzip on the
> generated string ?

Indeed, I can. I believe the hard part is actually the input_value
operation.
But I haven't looked enough into Marshal, maybe my solution can be
found there.
      

Marshal has everything you need:

let input_value ch =
  let header = String.create Marshal.header_size
  in
    Gzip.really_input ch header 0 Marshal.header_size;
    let buffer = String.create (Marshal.total_size header 0)
    in
      Gzip.really_input ch buffer Marshal.header_size (Marshal.data_size header 0);
      String.unsafe_blit header 0 buffer 0 Marshal.header_size;
      Marshal.from_string buffer 0
      

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/.

Pearl No.1 - The Min Missing Natural Number:
  http://typeocaml.com/2015/02/02/functional-pearl-no-1-the-min-free-nature/

Making making better:
  https://blogs.janestreet.com/making-making-better/?utm_source=rss&utm_medium=rss&utm_campaign=making-making-better

Private Release of Alt-Ergo 1.00:
  http://www.ocamlpro.com/blog/2015/01/29/major-private-release-alt-ergo-1.00.html
      

Old cwn

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.

Alan Schmitt