Here is the latest OCaml Weekly News, for the week of March 14 to 21, 2017.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-03/msg00051.htmlContinuing the thread from last week, François Pottier announced:
> I will probably prepare a blog post with a cleaned up solution... Done: http://gallium.inria.fr/blog/from-visitors-to-iterators/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-03/msg00054.htmlPaul Lachat asked:
I need to setup communication between two Ocaml processes on Windows. I think that using the named pipe of Windows is the good method to do this task. But I can't find any module for Ocaml who allow using the system call of Windows. I have already find this module https://opam.ocaml.org/packages/named-pipe/, but it use C, and I would like to avoid depending on another langage than Ocaml or software like Cygwin. Does anybody know a way to use named pipe of Windows in Ocaml ? Thank you in advance for your answer ! Ps : Sorry if it's the wrong mailing list to ask, it's the first time I use one.Johannes Kanig replied:
For the client side, you can simply use Unix.openfile on the pipe name: let name = "\\\\.\\pipe\\" ^ socket_name in Unix.openfile name [Unix.O_RDWR] 0 For the server side, you need to call the Win32 API functions CreateNamedPipe and ConnectNamedPipe, and for that you need to have bindings in C, exactly like the above library does it. I don't think there is another way.David Allsopp also replied:
> I need to setup communication between two Ocaml processes on Windows. > I think that using the named pipe of Windows is the good method to do this task. Depending on your exact needs, you can also accomplish this with anonymous pipes - use Unix.pipe (twice, if you need to communicate two ways) and pass the appropriate side of each pipe as stdin and stdout to Unix.create_process. That of course assumes that you can afford to use stdin/stdout for this. I don't think that the Unix module allows you to create inheritable handles, so I think that's the only way of passing the pipe descriptor without resorting to bindings. > But I can't find any module for Ocaml who allow using the system call of Windows. The traditional way is to create bindings in C for the system calls (see https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html). The library you have found is certainly an example of doing this. > I have already find this module https://opam.ocaml.org/packages/named-pipe/, > but it use C, > and I would like to avoid depending on another langage than Ocaml or software > like Cygwin. The OCaml runtime is implemented in C, so in some senses you can't avoid it! Note that Cygwin is in this context an operating system - you can bind to Windows system calls using stubs written in C and still not depend on Cygwin (if you use the Microsoft Visual C ports of OCaml, you don't even need Cygwin to compile your code). If you are using the actual Cygwin ports of OCaml, then although you can bind to Windows system calls, you shouldn't - you should use a normal Unix "file-based" pipe (see Unix.mkfifo). > Does anybody know a way to use named pipe of Windows in Ocaml ? The library you have found is the usual way - you may also like to investigate https://github.com/ocamllabs/ocaml-ctypes which, I believe has good Windows support these days (it's on my list of things to investigate and replace my own Windows C bindings...).David Scott also replied:
Although I'm one of the authors of that particular library I now prefer to use this other library instead: https://github.com/fdopen/uwt https://opam.ocaml.org/packages/uwt/ where "Uwt.Pipe" is a Unix domain socket on Unix and a named pipe on Windows. I'm very happy with "uwt" -- it seems to be very stable and reliable, despite the relatively low version number. Personally I don't want my final executables to depend on the cygwin.dll but I don't mind if my development environment uses cygwin for the Unix utilities like "make", "vi" etc. I usually install OCaml one Windows using this installer: http://fdopen.github.io/opam-repository-mingw/installation/ -- this installs everything you need (including Cygwin). I then `opam install` my dependencies and `make`, like I can on Unix. My resulting .exe files are independent of cygwin.dll and I ship them as-is.David Scott then said and David Allsopp replied:
> With regards to ocaml on windows, has anyone tried using bash on windows and > ocaml built using msvc/mingw? > > Bash on windows now supports calling native windows binaries from within the > bash shell itself. > > https://msdn.microsoft.com/en-us/commandline/wsl/interop#invoking-windows-binaries-from-wsl > > I am guessing this probably makes Cygwin redundant as a ocaml build environment. Yes – I had patched it for MSVC. The results are very good and at some point I’ll package it up properly for merging. Note that the interop is trickier for the mingw ports because the resulting executables need to be able to call into LXSS. There’s also some pain with setting environment variables when calling Win32 processes, which is why I hadn’t got around to finishing it off. Cygwin will only truly redundant if/when LXSS is available on all platforms – it’s only Windows 10 and not Server 2016 (to say nothing of older versions of Windows).
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-03/msg00061.htmlTom Ridge announced:
This may be of interest for people thinking about on-disk storage etc. https://github.com/tomjridge/tjr_btree/ It is not really in state to release, hence the "preview". It is the core library in the upcoming "ImpFS" filesystem which (with SibylFS) comes from the "Future filesystems" project.Frédéric Bour asked and Tom Ridge replied:
> Thanks for sharing this project, this looks promising. It seems this is a > proven library? > > Do you have links to this "Future filesystems" project? (and maybe the other > names you mentioned). At the moment, there is only the SibylFS website: https://sibylfs.github.io/ And the EPSRC grant description: http://gow.epsrc.ac.uk/NGBOViewGrant.aspx?GrantRef=EP/K022741/1 But when things are further down the line, I will put together a website for ImpFS.Hendrik Boom asked and Tom Ridge replied:
> The interesting point about this system is in the README: > > tjr_btree is a B-tree library. The core is written in Isabelle/HOL and exported > to OCaml > > Does this mean something like that the code has been generated from a formal > proof of its correctness? Not at this point. But yes, previous versions have had (often partial) formal proofs developed. So I would say that the code is likely to be pretty good from a correctness point of view. Obviously the full formal proof for the core would be desirable. But other projects can probably start using the code now, hence why I released it relatively early.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-03/msg00074.htmlJeremie Dimino announced:
If you were previously using the opam repository for Jane Street development packages on github , you can now switch to a new url : opam repo add janestreet-dev https://ocaml.janestreet.com/opam-repository This repository is a mirror of the github one but with static archives rather than git urls. This means that `opam update` will be much faster as it won't have to check the individual git repositories one by one.  https://github.com/janestreet/opam-repository  https://ocaml.janestreet.com/opam-repository
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-03/msg00076.htmlRomain Beauxis announced:
Apologies if I'm beating a dead horse but I think I've never wondered about this: What are the assumptions related to the garbage collector when an exception is raised? I sort-of always assumed it would be run but it doesn't seem that this is the case. This code: let () = let g () = let f _ = Printf.printf "Collecting x\n%!" in let x = Bytes.create 1024 in Gc.finalise f x; () in g (); Gc.full_major(); raise Not_found Shows that the finalization function is never call if I remove the call to full_major. Any reason for that? The reason I'm asking if that I know I've been writing C bindings where some cleanup operations are wrapped up in the finalization code with the expectation that, except for a hard crash, it would always be executed at some point in the future..Dmitry Bely replied:
It has nothing to do with exceptions. The problem is that OCaml runtime does not execute the garbage collector on program exit. But you can write let _ = at_exit Gc.full_major if you need to force GC.Max Mouratov then added:
It won't guarantee running all finalisers, as some of the objects may still be reachable. As part of a yet unmerged patch  that will land in 4.06, I have added an option that makes the runtime shut down properly on process exit (by an implicit call to the new caml_shutdown function), but unfortunately it doesn't handle Gc.finalise yet, as the relevant logic is not so trivial (and is probably a subject for a different PR). However, custom blocks  are guaranteed to be finalised properly with caml_shutdown, so you might look into this. Links:  https://github.com/ocaml/ocaml/pull/71  https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#sec442
Here is a sneak peek at some potential future features of the Ocaml compiler, discussed by their implementers in these Github Pull Requests. - Remove statically allocated compare stack https://github.com/ocaml/ocaml/pull/1073 - Allow creation of empty .cmxa files on macOS https://github.com/ocaml/ocaml/pull/1094 - Rudimentary documentation of ocamlnat https://github.com/ocaml/ocaml/pull/1096
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. Trivial meta-programming with cinaps https://blogs.janestreet.com/trivial-meta-programming-with-cinaps/ New OPAM Features: “opam build” http://www.ocamlpro.com/2017/03/16/new-opam-features-opam-build/ new opam features: "opam build" https://opam.ocaml.org/blog/opam-build/ One more talk, two more videos https://blogs.janestreet.com/one-more-talk-two-more-videos/ Full Time: Fullstack System Engineer at issuu in Copenhagen, Denmark http://jobs.github.com/positions/46f4e1c0-08e0-11e7-8bae-613c73194cc5
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.