Here is the latest OCaml Weekly News, for the week of January 23 to 30, 2018.
Archive: https://discuss.ocaml.org/t/to-be-solved-hopefully-cross-compiling-project-using-jbuilder/572/3Jared Forsyth announced:
This has now landed! (for future reference) https://github.com/ocaml/dune/pull/380 and here's the docs update https://github.com/ocaml/dune/pull/434
Archive: https://discuss.ocaml.org/t/mirageos-audio-profiles-podcast-series/1482/1Hannes Mehnert announced:
[Tim](https://tim.pritlove.org/) recorded audio profiles of some MirageOS developers at our hack retreat in December 2017, they are online now: https://mirage.metaebene.me -- enjoy listening Keep in mind, the next hack retreat is scheduled for March (7th-18th), sign up at http://retreat.mirage.io :)
Archive: https://discuss.ocaml.org/t/atdgen-for-xml/1498/1Brendan Long asked:
I'm currently working on [a project for read XLSX documents](https://github.com/brendanlong/ocaml-ooxml) and I'm finding that the majority of the code is for parsing XML into records (for example, [everything in this folder](https://github.com/brendanlong/ocaml-ooxml/tree/master/spreadsheetml/src)). If this was JSON, I'd use atdgen, but it doesn't seem to support XML. Is there some sort of code-generation tool for XML?Martin Jambon replied:
Atdgen doesn't handle XML. It could be extended to do so, but that would require a bit of work, especially since XML is richer than json. In the old days there was [IoXML](http://pauillac.inria.fr/~ddr/IoXML/), which was based on camlp4 and would generate serialization functions from type definitions. As far as I remember, it lacked a mechanism to specify how to customize your mapping from OCaml to XML, so it was good for dumping your own data but not so much for reading data from external sources. Edit: IoXML's last release is from 2016 and works with camlp5, so it might just work for you. Or you could tweak it to accommodate XLSX idioms.Marek Kubica then suggested:
You could try [ppx_protocol_conv](https://github.com/andersfugmann/ppx_protocol_conv) which comes with a `deriving` plugin similar to `yojson` but using `xml-light`.
Archive: https://discuss.ocaml.org/t/what-are-the-best-practices-for-setting-up-continuous-integration-for-ocaml-projects/1499/1Leonid asked:
I'd like to gather feedback and perhaps help curate documentation on what are the best practices for setting up CI for OCaml projects. Pardon my naivety in this area, but I figured that asking the experts and following a good path would save me (and hopefully others) a lot of work. I don't have as many OCaml projects as many of the other developers on this forum, but even with one project I find my current setup and constraints stifling. I'm currently using [ocaml-ci-scripts](https://github.com/ocaml/ocaml-ci-scripts)'s [travis-opam.sh](https://github.com/ocaml/ocaml-ci-scripts/blob/master/.travis-ocaml.sh), but with a long delay and 10 minute+ wait times on several tests it is cumbersome. On top of that, recently, the failures are entirely unrelated to my code; failures like `opam` not being available. I know that travis supports containerized builds, but I don't understand how to use [travis-docker.sh](https://github.com/ocaml/ocaml-ci-scripts/blob/master/.travis-docker.sh). My specific questions are: 1. Is there a way to test on a container with a fixed opam environment (hopefully, with the relevant packages installed) such that when I push, Travis only tests based on the newest code? It is wasteful to repeatedly test the installation of opam and my projects dependencies during development. I'd like to fix my projects dependencies and upgrade them as I individually review newer versions as opposed to riding the wave of latest packages. 2. Barring this (my personal) *ideal* setup, what is the next best way? 3. Is Travis a good CI platform and are there better ones ? I'm unfortunately a bit wedded to Github for this project as I've heard good things about Gitlab. I do find Travis's matrix functionality useful for dividing the testing.Bobby Priambodo then suggested:
I utilize Docker to run tests for my (unpublished) [ezpostgresql](https://github.com/bobbypriambodo/ezpostgresql) lib. I don't use `travis-docker.sh` (must have missed that by then). My CI runs in 2,5 minutes on average with few tests, but all those time are used to build the image and install dependencies. The actual test run is subsecond, so I imagine it would scale to number of tests nicely. Certainly better than the 10+ minutes I also encountered when trying to use `travis-opam.sh`. If you want to try it, here are the interesting files that enabled it: 1. [Dockerfile.test](https://github.com/bobbypriambodo/ezpostgresql/blob/master/Dockerfile.test) 2. [docker-compose.yml](https://github.com/bobbypriambodo/ezpostgresql/blob/master/docker-compose.yml) (my tests use postgres so I use a container for the sake of simplicity) 3. [.travis.yml](https://github.com/bobbypriambodo/ezpostgresql/blob/master/.travis.yml) This works great for me. I only tested on one base alpine image so far but I think you would be able to utilize Travis' matrix to achieve it (perhaps multiple Dockerfiles?). Feel free to ask anything or suggest improvements!Christian Lindig also suggested:
For the XenServer project, we maintain a set of upstream libraries and our own components in one Opam repository [xs-opam](https://github.com/xapi-project/xs-opam). This repository we build with [Travis](https://travis-ci.org/xapi-project/xs-opam). The setup could use some polish but it achieves the following: * We control exactly the versions of the upstream libraries we are using. These packages live in [`packages/upstream`](https://github.com/xapi-project/xs-opam/tree/master/packages/upstream). * We control exactly the versions of our own libraries that we are using by referring to tags in their repositories: [`packages/xs`](https://github.com/xapi-project/xs-opam/tree/master/packages/xs). * We build our own component packages by referring to the master branch of their repositories: [`packages/xs-extra`](https://github.com/xapi-project/xs-opam/tree/master/packages/xs-extra). The repository also contains a Dockerfile to build everything locally. All in all this is an example for the continuous integration of a project that is composed of executable components and libraries and might be bigger than what you were looking for. Internally we have another CI system that also builds the rest of the XenServer distribution which is not implemented in OCaml. We use Travis mostly to run it on pull requests and not as the ultimate test.
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. Full Time: OCaml Engineer for PL/distributed-systems cryptocurrency project at O(1) Labs in San Francisco http://jobs.github.com/positions/767159c8-0098-11e8-83c1-fe33ae7cb599 OCaml Engineer for PL/distributed-systems cryptocurrency project at O(1) Labs (Full-time) https://functionaljobs.com/jobs/9063-ocaml-engineer-for-pl-distributed-systems-cryptocurrency-project-at-o1-labs
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.