[opam-devel] having an iocamljs for every pull request

Andy Ray andy.ray at ujamjar.com
Tue May 6 11:43:47 BST 2014


On Tue, May 6, 2014 at 11:16 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
> Jeremy enquired about what is required to have an iocamljs toplevel available for every new package pull request into OPAM repository.  I believe we actually have many of the mechanics already:
>
> - Set up an `i.ocaml.org` virtual machine to serve the Cohttp static site for IOCamlJS.  This never runs native code, but does all the URL remapping for the JavaScript frontend to work.  We would need to add virtual hosting support for it, which should be fairly easy.


As discussed previously there are one or two things to 'harden' in the
server to make this safe but nothing difficult or time consuming.


> - Detect if there's a new ocamlfind package in the pull request, which could be done using Thomas' ocamlfind-detection patch.
>
> - Alter the OPAM-repository Travis scripts to POST to i.ocaml.org with the OPAM repository merge point and the name of the new package(s), and have the VM build the new libraries and make the cmo available.


Yeah, the only trick is keeping the opam/ocamlfind installation
working correctly as new packages are installed/updated to the
universe.


> - Have the Travis script comment on the original pull request with the URL of the toplevel.


Using the dynamic loading approach there would only be one generic
iocamljs kernel (/url) and the packages would be loaded by the user.
You could I suppose auto generate a notebook with the appropriate
#require directives though.


> - Sit back and listen to the awed gasps.
>
> Does this sound about right?


The alternative approach is to build a custom toplevel (think
ocamlmktop) with the library built in.

You need much the same machinery as above, then use the iocamljs
makefile to build a new iocaml kernel.

pros;

* much less likely to blow the js stack than dynamic loading (although
its possible, if inconvenient, to run the browser with a bigger stack)
* much quicker for the user to get the page running than dynamic loading
* its possible the opam/ocamlfind configuration would be easier - you
would just need *this* package to be compiled then it could be wiped.

cons;

* you need some way of controlling the expunge stage - specifically,
you want to know the name of all toplevel exported modules from a
package
* undoubtedly the makefile would need to be revised to support the
multitude of libraries out there.

If there could be a special opam package file (or target) to help
configuring a package for iocamljs compilation (exported modules,
extra js primitives, syntax extensions required etc) I would say there
are big advantages to this approach.

-Andy


More information about the opam-devel mailing list