Hello
Here is the latest OCaml Weekly News, for the week of December 17 to 24, 2013.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00116.html
Continuing the thread from last week, Malcolm Matalka announced:
I have updated and submitted the OPAM 1.1.0 Nix package to NixPkgs, the
pull request can be followed here:
https://github.com/NixOS/nixpkgs/pull/1393
It should be merged in a day or two.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00135.html
Sylvain Le Gall announced:
I have just released OASIS v0.4.1 to fix a bug with threads compilation.
You can get the release here:
https://forge.ocamlcore.org/frs/?group_id=54
Here is the changelog:
* Major changes:
* Fix broken compilation with threads and OCaml >= 4.01 (Closes: #1358)
* Minor changes:
* Refactor plugins for command line interface.
* Get rid of message 'field is set but no matching plugin' (Closes: #795, #1043).
* Features:
* dynrun_for_release (alpha):
* The goal of this plugin is to allow creating release with a minimal
setup.ml that uses '-setup-update dynamic'.
* Refactor setup.ml to perform early checks. like looking for findlib
and oasis.dynrun library and warns the user in case they cannot be
found (early configure script).
* Along setup.ml, Makefile and configure, also keep INSTALL.txt if
StdFiles plugins is used to provide a readable list of package to
install.
* Addendum to 0.4.0 release:
* Since 0.4.0 OASIS has a limited support to syntax extension. If in the
list of BuildDepends, one of the library ends with ".syntax", OASIS will
add the tag "syntax_camlp4o" to all files of this library. This new
feature already covers some common case of using syntax extensions.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00143.html
Jeremie Dimino announced:
As you may have noticed, a few weeks ago the camlp4 folder disappeared
from the subversion repository of OCaml. Since there was no technical
reason to keep Camlp4 in the official distribution
and it was making work on the compiler harder than necessary, It was
decided to make it an external project.
Camlp4 then started his second life on github. The official repository
is at this address:
https://github.com/ocaml/camlp4
New bug reports should go there. We can keep using the mantis bug
tracker for existing tickets, though it would be better if people could
move their tickets to github.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00156.html
Christoph Bauer:
there is an update for the ports of OCaml 4.00.1 to AIX and HP-UX. This
is the last update of both ports.
http://ocaml-ports.geschenker.net/ocaml-hpux.html
http://ocaml-ports.geschenker.net/ocaml-aix.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00159.html
Yotam Barnoy asked, triggering some discussions:
Following on the news that camlp4 has been moved to github, I would like
to see ocaml moved to github as well (the main repository, that is --
not a mirror):
a. The ocaml code seems under-documented, with some files still having
French documentation. I have a feeling folks on this list could do a
great job adding thorough documentation to the code if a push was made
to do that. If people could add some documentation and then make a pull
request for their documented files, we'd soon have much better
documentation.
b. Better documentation would lead to more people hacking the code,
which could help accelerate ocaml development. For example, it appears
that one sorely needed feature is proper backend multiplexing. The llvm
backend that was developed a couple of years back was forked by some
people to develop heavy features, and now all of those repositories are
experiencing bit-rot. The llvm backend could instead be an optional part
of the official distribution.
Thoughts on this, anyone?
Gabriel Scherer replied:
I think "which control version software to use" should be strictly the
choice of the developers. I've talked repeatedly with some of the major
OCaml developers about that, and my impression is that, so far, they are
happy to use SVN and see no major reason to change. I respect this
choice and don't believe we should put any pressure on their choice of
everyday tools.
I hear the argument that putting a project on github automagically
increases the amount of external contributions. This might be true, but
has yet to be demonstrated. The major entry-point for OCaml development
discussion (besides this list) is the bugtracker:
http://caml.inria.fr/mantis/
I believe it is rather clear and easy-to-use (not as powerful as
bugzilla, but not as scary either). If you think more visible
documentation of where to go and how to contribute is needed, I'm ready
to help make that happen (for example a page on ocaml.org). On mantis we
accept bugreport, which sometimes turn into development discussion,
frown upon feature requests, and welcome patches, either uploaded as a
diff, or as a link to whatever-web-mirror-for-wichever-dcvs-you-like (
for example feel free to fork the de-facto-official github mirror,
https://github.com/ocaml/ocaml/ , and send a link to a commit there ).
My understanding of the "if we did X (which requires some
not-fascinating work), we would have more contributions" kind of
suggestions is that there are often cheap to propose and of doubtful
effectfulness (some have been tried in the past, with
not-always-convincing results). Some things have been done which are
really nice, such as the "compiler hacking sessions" organized in the
Cambridge area by Jeremy Yallop and Leo White at OCamllabs, and I hope
we have even more of that in the future.
> The ocaml code seems under-documented, with some files still having
> French documentation.
> I have a feeling folks on this list could do a great job adding
> thorough documentation to the code
> if a push was made to do that.
Push ! Push ! This is a push !
I agree that the compiler code could be better commented, and have asked
and obtained agreement to encourage and review patches commenting the
code. Please send anything you've got in that direction, and tell the
folks on this list to do the same.
> For example, it appears that one sorely needed feature is proper
> backend multiplexing.
Well, I would be happy to help discuss and review patches in that
direction. OCaml developers tend to be conservative in things they
accept upstream (anyone would be after 20 years of continuous
development of the same thing, with mistakes of the past bugging you
endlessly), but there are a few notable "external" contributions at each
release, do not hesitate to provide one of them.
I made a talk at an early OCaml User Paris Meeting about (my perception
of) the distribution development, which may be of interest:
http://gallium.inria.fr/~scherer/drafts/ocaml_paris_meetup_may_2013/draft.html
Richard Jones suggested:
git is so superior to svn in every respect that I wish the OCaml
developers would use it. But as you say it is their choice, and we
have git mirrors.
> I hear the argument that putting a project on github automagically
> increases the amount of external contributions. This might be true, but has
> yet to be demonstrated.
I can add some (negative) anec-data:
(1) Putting a project on github increases the number of people
submitting bug reports and pull requests using github's proprietary
interface. This is annoying because you need some way to tell them
not to do this, and to deal with people who do it anyway. (libguestfs
-- hosted on github -- has an all-caps notice on the front page:
http://github.com/libguestfs/libguestfs)
(2) It's easy to run your own git repository with a web interface.
There is nothing magical that github provides here except free
bandwidth and someone who looks after security errata.
(3) To all intents and purposes, OCaml is already on github, ie:
https://github.com/ocaml/ocaml . So the massive influx of developers
should have already happened.
Markus Mottl said and Gabriel Scherer replied:
> The reason why the "massive influx of developers" hasn't happened may
> be that making small contributions is perceived as more costly when
> the authoritative repository is not on Github. Most contributors only
> make small contributions. If you make large and/or frequent
> contributions, the cost may seem negligible as you adjust to the
> "indirect" workflow. At least what concerns me, I might have
> submitted a tiny patch here or there, but felt that the development
> model is not open enough for small or less important contributions so
> I didn't bother. That's why I'd also love to see the OCaml team go
> "distributed", preferably either Git (github) or Mercurial
> (Bitbucket).
I understand that this is a matter of "perception" that relies on
subjective aspects, but I would like to point out that, objectively,
there is not much difference between a github-style workflow and what
currently happens for "small contribution" (one-shot patches).
Probably the most common workflow on github is approximately as follows:
(1) clone the github repository
(2) get it to compile by following whatever instruction (OCaml has an
INSTALL file)
(3) do your change, compile again and test
(4) fork the github repository (some peopele do that at point (1)), push
your changes, submit a pull request
By comparison, my current OCaml workflow is as follows:
(1) clone the github repository
(2) identical
(3) identical
(4) use "git format-patch HEAD~1" to get a patch, submit it on mantis
(New Issue, upload a file)
(recently some people just provide a link to the commit on their github
or wherever and it works just as well)
I understand that github provides an homogeneous experience so that
users don't have to wonder about what the workflow is, and that OCaml
users may need more explicit information about how to contribute (we can
work on that). I'm a bit surprised that an expert user that is a
long-time contributor on the bugtracker, such as Markus, would perceive
a difference in difficulty/welcome-ness here.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00163.html
Lukasz Stafiniak announced:
I am pleased to release the version 1.1 of InvarGenT, a system that
infers invariants and postconditions, and exports the corresponding
GADTs-based OCaml code.
https://github.com/lukstafi/invargent/releases
InvarGenT is based on _Vincent Simonet and François Pottier "A
constraint-based approach to guarded algebraic data types"_ only without
subtyping and without type/invariant annotations.
Version 1.1 brings better OCaml exporting, better documentation and
several bug fixes.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00187.html
Adrien Nader announced:
I've released version 1.3 RC1 of my Win-builds project, formerly known
as "yypkg mingw-builds".
Win-builds is a software distribution which targets Windows with both
native and cross toolchains from Linux and provides around 60 packages
of libraries and applications. It is supported by the yypkg package
manager both on Windows and Linux.
Why you shouldn't use this project:
- it works and is therefore going to be fairly boring
- it makes things too easy when dealing with Windows
- it has up-to-date components and is even going to feature security
update
- but it's not going to be bleeding-edge, which makes it even more
boring
- binary packages mean you don't get to pass -fomg-optimize and
-funroll-loops to GCC
- there is too litle Javascript and CSS on its website
- you might find bugs in your own software and build guilt about not
fixing them
- 1.3 is a bit cumbersome to setup on Linux (although it will work on every
distribution) and that will only be fixed during January or February
- you might have built your own system or want to do so in the future
- it's not on github
- I still haven't finished pushing my new 10-minutes introduction to
lablgtk and you resent me from not doing so
Website: http://win-builds.org/
Bug Tracker: http://win-builds.org/bugs
Documentation: http://win-builds.org/stable/
Downloads: the links are hidden inside the documentation
PS: the cross-compilation aspect is in my first reply to this message to
make things a bit clearer/cleaner.
He later added:
As mentionned, this version includes an OCaml cross-compiler from Linux to
Windows. It is findlib-enabled and actually ocamlfind is the only way to
properly invoke it. It probably also features a number of new and still
unknown bugs (in case you were thinking you could build your project and
assert that it won't crash).
The good news is that I've been able to build without modification
ocaml-fileutils, type_conv and sexplib (from before they landed in the
tarballs of Core) and yypkg itself (which features a small C stub).
Their common point is the use of ocamlfind either through OASIS or
through ocamlbuild directly and without ad-hoc code added to the build
systems.
Cross-compilation should be available out-of-the-box in the OCaml
compiler fairly soon and, even though this builds on an SVN snapshot
from January 2013, win-builds will let you check the behaviour of your
build systems and provide feedback on how you would like things to be
done.
Some notes:
- binary names need to lose the '.exe' and get a prefix with the target:
x86_64-w64-mingw32-ocamlopt.opt
- camlp4, ocamldoc, ocamldebug and labltk are not provided and it's not
yet clear how they will integrate with cross-compilation
- the host needs an native OCaml of the exact same version (imagine if
camlp4 wrote or read an AST for another version)
- I haven't tried building for both native and cross in the same pass
using ocamlfind's -toolchain option (see "man findlib.conf") and this
will be an issue for build systems which create an executable with
findlib (this excludes ocamlbuild right now) and then use it
- more, discussion is open
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/.
Gen_server in Ocaml:
http://functional-orbitz.blogspot.com/2013/12/genserver-in-ocaml.html
Reconstructing the Knuth-Morris-Pratt algorithm:
http://gallium.inria.fr/blog/kmp
10 tips for writing comments (plus one more):
https://ocaml.janestreet.com/?q=node/121
Polymorphism for beginners:
http://roscidus.com/blog/blog/2013/12/20/polymorphism-for-beginners/
Mirage 1.0.3 released; tutorial on building this website available:
http://openmirage.org/blog/mirage-1.0.3-released
Full Time: Software Developer (Functional Programming) at Jane Street in New York, NY; London, UK; Hong Kong:
http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45
OASIS v0.4.1 release:
https://forge.ocamlcore.org/forum/forum.php?forum_id=892
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.