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.htmlContinuing 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.htmlSylvain 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.htmlJeremie 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.htmlChristoph 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.htmlYotam 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.htmlRichard 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.htmlLukasz 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.htmlAdrien Nader announced:
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.