Hello
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/3
Jared 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/1
Hannes 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/1
Brendan 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`.
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.