Hello
Here is the latest OCaml Weekly News, for the week of April 11 to 25, 2017.
Sorry for the hiatus last week, I was away for vacations.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00042.html
Continuing this thread, Richard Jones said:It looks like people have already mentioned getttext. I want to add that OCaml already has an excellent gettext implementation. No need to reinvent any wheels. https://forge.ocamlcore.org/projects/ocaml-gettext/ We use it every day in libguestfs, an example picked at random (there are thousands more): https://github.com/libguestfs/libguestfs/blob/master/v2v/input_libvirt.ml#L39 Therefore you might think I'd be very exciting about having the OCaml compiler messages being localized. That not so much. I find that it makes it considerably easier to search for error messages, and also to help people, if they are in a single language. It's for this reason that we don't translate debugging and other internal messages in our tools. (But being an English native speaker it's a lot easier for me, so take this with a pinch of salt.)Gabriel Scherer then replied:
> I find that it makes it considerably easier to search for error messages On this specific topic, I would be interested in having OCaml compiler error messages numbered, just as warnings already are, precisely because it makes it much easier to reference them (is robust to change of wording), and for example look up a specific error in the manual for further explanations -- we recently started doing this for warnings, see http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec270 .
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00044.html
Fabrice Le Fessant announced:As the Sparc native backend was just removed today from OCaml, it might be interesting for some of you to know that OCamlPro recently resurrected the ia64 native backend and ported it to HP-UX for one of its customers. The whole story is here: http://www.ocamlpro.com/porting-ocaml/ So, if you are interested in using OCaml on new architectures, or new versions of OCaml on architectures that are no longer officially supported, just contact us.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00052.html
Ashish Agarwal announced:Solvuu is a startup developing software for the life sciences industry. Our core technology is based on ideas from type theory and functional programming, and our software is implemented almost entirely in OCaml. We develop software across the full stack: cloud infrastructure management, job scheduling, data management and security, clients and servers for many APIs, rich websites, and much more. We are currently hiring 2 full-time OCaml programmers in New York City. We are open to a spectrum of qualifications, but basically the more OCaml you know the better. Ideal candidates will have at least 5 years of experience developing production OCaml software, whether in industry or as an academic active in the open source community. We are offering great compensation packages that include salary, equity, and the usual things like health care and a ping pong table. Most importantly, you will build great technology to advance society in areas as important as cancer treatment, drug discovery, and agriculture. And you get to do all of that in Manhattan, one of the most vibrant and beautiful cities in the world. To apply, please contact me directly (ashish@solvuu.com) with your resume/CV. International applicants are welcome, but the reality is getting a visa will be challenging. We are willing to try and may explore options for exceptional candidates. About Genomics: Our primary focus is on genomics, an industry driven by a dramatic decrease in the cost of DNA sequencing. Fifteen years ago it cost $100,000,000 to sequence a single human genome, today it costs $1000, and in a couple of years it is expected to cost $100. This has spawned multiple new industries that face serious computational challenges due to the size and complexity of the data and associated algorithms. Solvuu addresses the full spectrum of computational needs of this important market. We have great investors and partnerships, and are now building a great engineering team. Please join us. Solvuu is headquartered in New York City and also has an office in Silicon Valley.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00054.html
Damien Doligez announced:We have the pleasure of announcing the release of OCaml version 4.04.1, dedicated to the memory of Emmy Noether on the anniversary of her death. This is a bug-fix release, see the list of changes below. It is available as a bunch of OPAM switch and as a source download in the following locations: https://github.com/ocaml/ocaml/archive/4.04.1.tar.gz https://caml.inria.fr/pub/distrib/ocaml-4.04/ Happy hacking, -- Damien Doligez for the OCaml team. OCaml 4.04.1 (14 Apr 2017): --------------------------- ### Code generation and optimizations: - PR#7501, GPR#1089: Consider arrays of length zero as constants when using Flambda. (Pierre Chambart, review by Mark Shinwell and Leo White) ### Standard library: - PR#7403, GPR#894: fix a bug in Set.map as introduced in 4.04.0 (Gabriel Scherer, report by Thomas Leonard) ### Tools: - PR#7411: ocamldoc, avoid nested <pre> tags in module description. (Florian Angeletti, report by user 'kosik') - PR#7488: ocamldoc, wrong Latex output for variant types with constructors without arguments. (Florian Angeletti, report by Xavier Leroy) ### Build system: - PR#7373, GPR#1023: New flexlink target in Makefile.nt to bootstrap the flexlink binary only, rather than the flexlink binary and the FlexDLL C objects. (David Allsopp) ### Bug fixes - PR#7369: Str.regexp raises "Invalid_argument: index out of bounds" (Damien Doligez, report by John Whitington) - PR#7373, GPR#1023: Fix ocamlmklib with bootstrapped FlexDLL. Bootstrapped FlexDLL objects are now installed to a subdirectory flexdll of the Standard Library which allows the compilers to pick them up explicitly and also ocamlmklib to include them without unnecessarily adding the entire Standard Library. (David Allsopp) - PR#7385, GPR#1057: fix incorrect timestamps returned by Unix.stat on Windows when either TZ is set or system date is in DST. (David Allsopp, report and initial fix by Nicolás Ojeda Bär, review and superior implementation suggestion by Xavier Leroy) - PR#7405, GPR#903: s390x: Fix address of caml_raise_exn in native dynlink modules (Richard Jones, review by Xavier Leroy) - PR#7417, GPR#930: ensure 16 byte stack alignment inside caml_allocN on x86-64 for ocaml build with WITH_FRAME_POINTERS defined (Christoph Cullmann) - PR#7456, GPR#1092: fix slow compilation on source files containing a lot of similar debugging information location entries (Mark Shinwell) - PR#7457: a case of double free in the systhreads library (POSIX implementation) (Xavier Leroy, report by Chet Murthy) - PR#7460, GPR#1011: catch uncaught exception when unknown files are passed as argument (regression in 4.04.0) (Bernhard Schommer, review by Florian Angeletti and Gabriel Scherer, report by Stephen Dolan) - PR#7505: Memory cannot be released after calling Bigarray.Genarray.change_layout. (Damien Doligez and Xavier Leroy, report by Liang Wang) - GPR#912: Fix segfault in Unix.create_process on Windows caused by wrong header configuration. (David Allsopp) - GPR#980: add dynlink options to ocamlbytecomp.cmxa to allow ocamlopt.opt to load plugins. See http://github.com/OCamlPro/ocamlc-plugins for examples. (Fabrice Le Fessant, review by David Allsopp) - GPR#992: caml-types.el: Fix missing format argument, so that it can show kind of call at point correctly. (Chunhui He) - GPR#1043: Allow Windows CRLF line-endings in ocamlyacc on Unix and Cygwin. (David Allsopp, review by Damien Doligez and Xavier Leroy) - GPR#1072: Fix segfault in Sys.runtime_parameters when exception backtraces are enabled. (Olivier Andrieu)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00071.html
Francois Berenger announced:We are pleased to announce the 2.6.0 release of OCaml batteries-included. Batteries Included is a community-maintained standard library extension, with a focus on performance, stability and compatibility. Bug reports, pull requests and user feedback are warmly welcome, see the project page at https://github.com/ocaml-batteries-team/batteries-included/ The library's API documentation can be found at: http://ocaml-batteries-team.github.io/batteries-included/hdoc2/ Batteries 2.6.0 is a minor release, compatible with OCaml 4.04.0. As usual, Batteries 2.6.0 is compatible with older OCaml releases as well (until OCaml-3.12.1), and provides back-ported versions of most standard library functions made available recently. After an 'opam update' your will be able to do an 'opam upgrade batteries' an enjoy this new release. Many thanks to the contributors for this release: Florian Angeletti Francois Berenger Michael Färber Oscar Gauthier Ifaz Kabir Johannes Kloos Gabriel Scherer Thibault Suzanne Detailed Changelog v2.6.0 (minor release) added BatList.favg and faster BatList.fsum #746 (Gabriel Scherer, Francois Berenger) install .cmt and .cmti files #740 (Francois Berenger, Gabriel Scherer) BatMap: added find_default #730 (Francois Berenger) added scripts/test_install.sh #743 (Francois Berenger) BatHashtbl: added {to|of}_list, bindings #728 (Francois Berenger, Thibault Suzanne) added {BatList|BatArray}.shuffle #702, #707 (Francois Berenger, Gabriel Scherer) Clarification and improvements to the documentation #682, #685, #693 (Florian Angeletti, Johannes Kloos, Michael Färber) make LazyList.split_at lazy: split_at : int -> 'a t -> 'a t * 'a t would previously eagerly force the prefix of the list and only be lazy in its second returned value. #694 (Michael Färber, Gabriel Scherer, Thibault Suzanne) Add List.{map2i,iter2i} #696 (Thibault Suzanne) Added Result.{map,map_both} #705 (Ifaz Kabir) Add {BatSet,BatMap}.{Int,Int32,Int64,Nativeint,Float,Char,String} as common instantions of the respective Make functor. #709, #712 (Thibault Suzanne, Francois Berenger) BatString: add chop : ?l:int -> ?r:int -> string -> string #714, #716 (Gabriel Scherer, request by Francois Berenger) BatSet: make to_array allocate the resulting array at first instead of using Dynarray (faster, uses less memory). #724 (Thibault Suzanne) BatList: add fold_left_map: ('a -> 'b -> 'a * 'c) -> 'a -> 'b list -> 'a * 'c list #734 (Thibault Suzanne, review by Gabriel Scherer, request by Oscar Gauthier) add BatList.frange : float -> [< `To | `Downto ] -> float -> int -> float list frange 0. `To 1. 3 is [0.; 0.5; 1.]. #745 (Francois Berenger)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00075.html
François Pottier announced:It is my pleasure to announce a new release of Menhir, which is available as of now via opam. opam update && opam install menhir The main changes are as follows: - Changed Menhir's license from QPL to GPLv2. MenhirLib remains under LGPLv2, with a linking exception. - Moved the repository to gitlab.inria.fr, where it is public. - Many additions to the incremental API, suggested by Frédéric Bour. - A new library, MenhirSdk, allows external tools to get access to a description of the grammar and automaton. This was also proposed by Frédéric Bour. This change and the previous one, together, allow error recovery strategies to be precomputed and implemented. For more details, see the change log: https://gitlab.inria.fr/fpottier/menhir/blob/master/CHANGES.md
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00078.html
Anton Bachin announced:We are pleased to announce release 3.0.0 of Lwt, the concurrent programming/promise library. https://github.com/ocsigen/lwt This release makes some minor breaking improvements to the Lwt API, which were previously announced in release 2.7.0. You can see the changelog here: https://github.com/ocsigen/lwt/releases/tag/3.0.0 The non-breaking changes made to date are separated out into a preceding Lwt 2.7.1, also released recently. Most notable are compatibility with OCaml 4.05 and the official announcement of Lwt_result: https://github.com/ocsigen/lwt/releases/tag/2.7.1 Release 3.0.0 completes the first test of Lwt's "soft" breakage cycle [1]: Lwt warns users about upcoming breakage, provides simple upgrade paths, and gives time to (optionally) adapt before the breakage actually occurs. Simultaneously, users are invited to visit the Lwt repository and object to any planned breaking change, or otherwise contribute their opinions and expertise. We hope that, going forward, this will give us the flexibility to fix crufty parts of Lwt in a consensual fashion, without causing unjustified headaches and surprises. Of course, we prefer to avoid breakage as much as possible – but, here and there, some things just need to be broken. 3.0.0 factors some of Lwt's optional dependencies fully out into their own packages [2]. This process will likely continue with factoring out the Camlp4 extension and the PPX [3]. We are also eyeing the Lwt Unix bindings, though this requires more consideration. On the subject of Unix, we are also considering some kind of "merger," literal or not, [4] between Lwt and uwt [5], the Lwt-aware binding to libuv [6]. A combination of a libuv binding and prospective bindings to Node.js [7] might be the best way to create portable, maintainable I/O bindings at once for Unix-like operating systems, Windows, and Node. This work, however, is in an absolutely embryonic stage, and we are not sure how or where it might go. Though not immediately relevant to users, work continues on reducing the internal technical debt of Lwt. We hope this makes contributing to Lwt easier in the future – that Lwt will not be a forbidding code base. This should help everyone in the longer term, and it goes hand-in-hand with the slow writing of the new manual. It seems writing tests, and refactoring Lwt in places, are necessary to gain the kind of understanding needed to write a good, thorough manual in the first place. The Lwt project welcomes new co-maintainers: Mauricio Fernandez (@mfp) and Simon Cruanes (@c-cube). Their fresh perspectives and expertise, both general and specialized, already help the quality of Lwt greatly. Happy concurrent programming, Anton Bachin [1]: https://github.com/ocsigen/lwt/issues/293 [2]: https://github.com/ocsigen/lwt/issues/41 [3]: https://github.com/ocsigen/lwt/issues/338 [4]: https://github.com/ocsigen/lwt/issues/328 [5]: https://github.com/fdopen/uwt [6]: http://libuv.org/ [7]: https://github.com/ocsigen/lwt/issues/270
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00085.html
Hongbo Zhang said:Given that bitten by PPX from time to time, finally, I think it is a time to spend two hours sharing my experience with PPX and why you(the OCaml library developer) should avoid PPX as much as you can. Here is a story I just experienced this morning, I tried to install a package from opam, and it complained my compiler is too old - 4.02.3, to be honest, 4.02.3 is still a pretty modern OCaml compiler, even debian stable still stays on 4.01. Anyway, I switched to 4.04.1, after half an hour, it failed to compile again, complaning about some ppx error message. This is not my first time experience, and finally it made me to write an essay about why PPX is harmful. PPX is a compiler plugin, it imposes a very large compiler surface API to your library, and we don't have any backward compatibility guarantee from the compiler, which means your library will only work against a specific compiler. Even worse, OCaml is an elegant but small community, we don't have too many maintainers for a library, if you have a library which relies on PPX (the dependency chain could be really really huge, for example, ppx_metaquot depends on typing environment, you can find lots of stories about node_modules in Node community), it will probably not work against next version of OCaml compiler, and it will be a huge maintenance overhead for other people to pick it up. OCaml is already a very expressive language, probably more expressive than any other mainstream language, (Go, Java, C/C++, etc), it is fine to write some boilerplate code, or we can cut PPX as a dev dependency, after your PPXed your code, check in the generated source code(via -dsource), so it will not bring dependency to end users. There are some valid use cases of PPX, for example, in BuckleScript or JS_of_OCaml, we want to customize OCaml language a bit for external FFI, or if you have a very large team, and committed effort to maintain your PPX. Happy hacking in OCaml without PPX, Thanks -- HongboYotam Barnoy then said:
My 2 cents: I personally think we did PPX wrong. PPX should have used the syntax as its starting point for full backwards compatibility. Currently, the PPX cycle is OCaml: { syntax -> AST -> serialized AST } -> PPX: {serialized AST -> AST -> PPX modification -> serialized AST} -> OCaml: {serialized AST -> AST -> ... } Exposing the AST is the cause of the problem you mention. If instead, every PPX extension had a particular OCaml compiler's syntax parser and syntax printer integrated into it, and the PPX cycle was: PPX: { syntax -> AST -> PPX modification -> syntax } -> compiler: { syntax -> AST -> ...} We would have far fewer issues with PPX plugins, since they would be as backwards-compatible as the syntax. I think this mistake happened because everyone was trying to move away from camlp4's complexity, and we didn't notice that the problem with camlp4 wasn't the approach, but rather the fact that it wasn't making use of the same code as the compiler and therefore required its own heavy learning-curve and parallel maintenance to keep up with the compiler. To be fair though, camlp4 came before the age of OCaml on github, opam, and the associated easy code/library sharing. The only issue I can see with this idea of improving PPX is that the PPX-generated syntax wouldn't have the original source locations. We'd need an annotation that indicated the original source locations (perhaps row and column offsets) when a PPX translated to modified syntax and printed it out, so that the compiler's errors would have proper locations relative to the original source.Gerd Stolpmann then replied:
So far I understand, with "syntax" you really mean syntax-as-string. I think most often the AST changes by adding more fields or more AST nodes. Wouldn't the situation already improve a lot if we switched to record variants for the AST types? (Besides that the compiler would get way more readable.) New fields wouldn't be a big problem anymore because they are looked up by name and not by position.Alain Frisch also replied:
I think https://github.com/let-def/ocaml-migrate-parsetree is a much stronger approach. If I understand correctly, Jane Street moved from using a migration system based on concrete syntax to using this new project. In your suggested approach, imagine you have a PPX processor written for OCaml 4.04. It assumes that the Parsetree it works on is the one of 4.04. Sure, you can compile this PPX processor (+ embedded parser/printer) into a stand-alone executable, using OCaml 4.04, and then apply it as a preprocessor called from OCaml 4.05. But this is very impractical: users would need to install OCaml 4.04 just to produce the PPX executable. Moreover, you loose the ability to combine multiple rewritings in a single process, and you have to pay the price of multiple parsing/printing/processes. On top of that: (i) you put in the critical loop "pprintast.ml", which has always been more or less buggy; (ii) there is no hope that an "old PPX" applies to source code using newest syntactic features; (iii) as you mention, locations would need to be added for each node in the AST, which makes the parsing/printing even slower; moreover, it is not technically straightforward to do so, since many places in the AST contains locations but do not support attaching attributes; (iv) we loose the ability to change the concrete syntax of OCaml, either to use alternative syntaxes such as Reason, or to remove, at some point, weird corner cases in the current syntax. With ocaml-migrate-parsetree, you can still compile your PPX written for 4.04 with newer versions of OCaml. And it would even be possible (I don't know if this is already the case) to apply it to source code using newer syntactic features, as long as the rewriting done by the PPX doesn't interact with those features. (This could be achieved by turning new syntactic features into attributes/extension nodes when mapping to the older AST; and then recognizing these forms and reconstitute the correct new AST forms when mapping back to the new version.)Jeremie Dimino then added:
Yes, we are now using ocaml-migrate-parsetree at Jane Street. I think that with this library the versioning story is much better. We are heavy user of ppx rewriters and all of the code we release now builds with OCaml 4.03 to 4.06 without problems. Initially we considered using the concrete syntax to solve the versioning problem and we have a solution that should work in theory. Although it's not great when there is no source file, such as in the toplevel. The method we considered is described in [1]. Switching to ocaml-migrate-parsetree was easier since we didn't have to change anything to the way things worked, just port the code. Regarding the idea of cutting down the dependency for release tarballs by including the generated code, while this is an interesting idea, there are a lot of small annoying problems that makes this technique hard in practice. The two main problems are: 1. it doesn't work for .ml files that are generated. Basically all the code you generate with custom code generators as to be ppx free. It is fine however for pure generators, since you can just embed the generated code 2. it doesn't work if you use conditional compilation. Conditional compilation is not great in general, but it is a lot of work to completely get rid of it However, one thing that we kept from these experiments is the idea to use ppx in the same way that expectation tests work. This idea is described in [1] and we use it for the Base library [2]. Additionally it is a good testing/debugging tool. It is a viable solution if all you need is [@@deriving] plugins and don't want to depend on ppx. The idea is to let the ppx rewriter insert the code generated by [@@deriving] plugins in the source code: type t = A | B [@@deriving_inline sexp_of] let sexp_of_t = function | A -> Sexp.Atom "A" | B -> Sexp.Atom "B" [@@@end_of_derived_code] The code builds without ppx and you still don't have to write the boilerplate yourself, you let the ppx tool do it for you. [1] https://blogs.janestreet.com/an-solution-to-the-ppx-versioning-problem/ [2] https://github.com/janestreet/baseYaron Minsky replied to the initial post:
I understand the frustration, but I think your conclusion is misplaced. PPXs are massively helpful when building serious software. Having automatic generation of pretty-printers, comparison functions, hash functions, binary protocols, and the like is a huge win for both programmer efficiency and correctness. The Haskell folk aren't wrong to care about deriving, and the schemers aren't crazy to want their macro systems. In short, I think abandoning syntactic abstractions is madness. I agree that the portability problems are serious and should be addressed, but ocaml-migrate-parsetree seems like a solid step in the right direction.Hongbo Zhang then said:
Yes, when you never depend on other people's PPX, it is perfectly fine to provide a customized suite of PPX. Think about the software which only works against 4.03, 4.04, this is equivalent to say that you release a c++ library only works with gcc 7 while most enterprises are still using 4.8, nobody even think it is a serious piece of software. It is a different story in Haskell deriving or Scheme macro system, there is no issue that you software in use today will be not compilable in the future.Fabrice Le Fessant then replied:
A lot of people use `autoconf` to generate `./configure` scripts, and the standard practice is to keep the `./configure` script so that people don't need to run `autoconf` to just compile and install the software. Maybe projects could do the same with ppx, i.e. store pre-processed files in the project sources so that the ppx would only be needed when the developer modifies the sources. For example, there could be a `_ppx` directory, where pre-processed files would be stored under the hash of a combination of their original source code and the `-ppx` arguments. The compiler (or the build system) would use these files when available instead of calling the ppx. That might reduce the problem at least for `opam`, since users are not supposed to edit the packages when installing them.Emilio Jesús Gallego Arias also replied to the initial post:
indeed I think this problem is real as I have been trying to design a plan for Coq 8.8 (expected Q1 2018) to depend on PPX, and indeed it has not been easy to come up with something that wouldn't be turned down by the developers due to compatibility concerns. It is great to hear that ocaml-migrate-parsetree helps and that the situation is improving, but maybe the biggest concern would Coq adopt that solution, is how fast would it become "obsolete", to be replaced by a new one. From my attendance to the Coq WG I got the personal feeling that there was some amount of uncertainty about what the OCaml roadmap regarding certain features is. This in turn difficults the elaboration of Coq's own roadmap.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00096.html
Hongbo Zhang announced:BuckleScript is an optimizing compiler for OCaml to generate readable JavaScript, it is open sourced by Bloomberg [1]. Major changes are listed here: https://github.com/bloomberg/bucklescript/blob/master/site/docsource/Release.1.7.0.adoc Documentation is available here: http://bloomberg.github.io/bucklescript/Manual.html To install: npm install -g bs-platform Happy hacking in OCaml! -- Hongbo [1]: https://github.com/bloomberg/bucklescript/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00108.html
Runhang Li announced:Call for tutorials Commercial Users of Functional Programming (CUFP) 2017 September 7th-9th, 2017, Oxford, United Kingdom Co-located with International Conference on Functional Programming (ICFP) Dear fellow camels, Commercial Users of Functional Programming (CUFP) 2017 is now seeking tutorials proposals. Co-located with International Conference on Functional Programming (ICFP), Commercial Users of Functional Programming (CUFP) will take place in Oxford, U.K. from 7th to 9th of September, 2017. CUFP is devoted to showcase the state of the art of functional programming in industrial settings. We are looking for tutors who would like to host half-day tutorial sessions of the following topics: * Introductions to functional programming languages, e.g., Haskell, OCaml, Scala, F#, Scheme, Erlang, Clojure. * Advanced programming languages, concepts, or applications, e.g., Agda, Idris, F*, Coq, Eff. * Applications of functional languages in particular areas, including web, high-performance computing, and finance. * Tools and techniques supporting state of the art functional programming, e.g., ReasonML, TypeScript, Elm, QuickCheck, FlowType. * Theory. Type theory, category theory, abstract algebra, ongoing or new research, or anything useful or interesting to functional programmers. **Proposal submission deadline is May 25th** Details can be found at: http://cufp.org/2017/call-for-tutorials.html
Here is a sneak peek at some potential future features of the Ocaml compiler, discussed by their implementers in these Github Pull Requests. - generalize -dtimings to show allocation, top heap size https://github.com/ocaml/ocaml/pull/1152 - Spellchecker hints and type-directed disambiguation for extensible variants https://github.com/ocaml/ocaml/pull/1154
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. Full Time: Front-end Developer at issuu in Copenhagen http://jobs.github.com/positions/9c9c5cac-28e3-11e7-8515-f5b67b252bbb Seventeenth OCaml compiler hacking evening at Pembroke http://ocamllabs.github.com/compiler-hacking/2017/04/18/seventeenth-compiler-hacking-may News about Tyre | Drup's thingies https://drup.github.io/2017/04/17/tyre-news/ EzSudoku http://www.ocamlpro.com/2017/04/11/ezsudoku/
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.