Here is the latest OCaml Weekly News, for the week of February 23 to March 01, 2016.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00090.htmlDavid Allsopp announced:
Of potential interest to Windows OCaml users, I'm pleased to announce a preliminary release of "msvs-tools", a collection of scripts (at the moment only 2) for aiding the use of the Microsoft C Compiler with OCaml. GitHub repo at https://github.com/metastack/msvs-tools. msvs-detect searches for Visual Studio and Windows SDKs for compilers matching a set of criteria. Its intended use is for configure scripts, where it can be used to remove the requirement for the user to set-up PATH, LIB and INCLUDE prior to launching Cygwin, or to find pairs of x86 and x64 C compilers. msvs-promote-path provides one solution to the conflict between Microsoft's Linker (link.exe) and coreutils link (/usr/bin/link) in Cygwin by performing a little PATH munging so you don't have to. msvs-detect will hopefully be heading into FlexDLL (to replace an earlier more limited version called findwinsdk) and also into OPAM-on-Windows (which always needs pairs of compilers for x64 and x86). msvs-promote-path will hopefully head into OCaml itself, but it'd be helpful even at this stage to know if it works correctly on your system so, if you're using a Windows system that has at least one Microsoft C Compiler installed and Cygwin, then you should be able to launch a Visual Studio Command Prompt (or Windows SDK Command Prompt) and from that run: C:\cygwin\bin\mintty - (adjusted as necessary, if you installed Cygwin elsewhere) and then from bash: $ link | head -1 link: missing operand Try `link --help' for more information. $ eval $(./msvs-promote-path) /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC/Bin/amd64 moved to the front of $PATH $ link | head -1 Microsoft (R) Incremental Linker Version 9.00.21022.08 $ ./msvs-detect --all Identified Environment C compiler as SDK6.1-x64 Installed and usable packages: SDK5.2-x64 SDK6.1-x64 SDK6.1-x86 SDK7.0-x64 SDK7.0-x86 SDK7.1-x64 SDK7.1-x86 VS10.0-x64 VS10.0-x86 VS11.0-x64 VS11.0-x86 VS12.0-x64 VS12.0-x86 VS14.0-x64 VS14.0-x86 VS7.0-x86 VS7.1-x86 VS8.0-x64 VS8.0-x86 VS9.0-x64 VS9.0-x86 Obviously the output will depend on exactly what you have installed and, yes, the test system I'm working on actually has every version of Visual Studio and the Windows SDK simultaneously installed; thank you Microsoft for keeping all those demo ISOs on your website and for the MSDN Academic Alliance/e-Academy which provided me with free copies of VS .NET 2002 and 2003 a veeery long time ago. Any feedback - especially if it doesn't work - much appreciated.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00094.htmlSimon Cruanes announced:
I have the pleasure of announcing the release of containers 0.16 (now on opam). Containers is a lightweight, pay-for-what-you-use, extension of the standard library that provides additional printers, functions, conversions from/to iterators, and new modules to ease the manipulation of options, errors, etc. A lot of new functions have been implemented, some modules have been deprecated (in particular, the `bigstring` interface was moved into its own opam library). The full changelog can be found at https://github.com/c-cube/ocaml-containers/blob/a2179d4355d7f3f66c029c3f412cfbdcd93f783e/CHANGELOG.adoc I wrote a small tutorial that demonstrates a few features of containers; it can be found at https://github.com/c-cube/ocaml-containers/blob/0e5334b673f86494d80f11210fc87a2527fa5be7/TUTORIAL.adoc
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00102.htmlYaron Minsky announced:
Just an FYI: we have a better version of the generated documentation for Core and Jane Street's other open source libraries, here: https://ocaml.janestreet.com/ocaml-core/latest/doc/ These aren't perfect, but they're in a much cleaner state due to improvements in the doc generation toolchain. There are still real improvements to make, but going forward, we expect to have up to date docs for every release.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00103.htmlMalcolm Matalka asked and Jeremy Yallop replied:
> I have a large/complex struct I am trying to create bindings for > operations on it in Ocaml. I have an API that tells me how many bytes > the struct is so I can allocate it just fine and pass it around to C > functions I've bound with ctypes. But some data in it is accessed via > members. I started implementing a structure in ctypes for it, but it's > getting large and awkward. Are there any best practices around doing > this? The best approach is to use the Cstubs_structs module, which allows you to declare just the parts of the structs that you need to access in your program, and which generates code that uses the C struct declarations to work out sizes, alignments, field offsets, etc. The basic API is the familiar set of functions "structure", "field" and "seal" from the Ctypes module, but the build process is a little more involved. However, in return for the more complex build, all the issues that you're concerned about are addressed. The Cstubs_structs API is not yet very well documented, but there's a brief guide with examples in the pull request that introduced it: https://github.com/ocamllabs/ocaml-ctypes/pull/62 > Some concerns I have: > > - It seems fragile - a different version of the library might have > different members in the struct so keeping my ocaml code in-synch > seems error prone. The Cstubs_structs module addresses this by using generated C code to determine the offsets of fields each time you build your library. > - It's annoying because the struct has a lot of members I don't care > about in my case. I only want access to a few members that have > important details. Since Cstubs_structs retrieves layout rather than computing it you only need to declare the members that you care about. > - The struct is large with lots of types that I don't necessarily want > to create so creating the struct becomes somewhat awkward. If I know > the size of the types I might be able to pretend it's an array of N > chars or something instead of trying to implement the type just to > fill out this struct, but I don't know if that is valid. Again, since Cstubs_structs retrieves struct layout and alignment information from C, you can use Ctypes.make to create struct values, even if you haven't declared all the fields.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00107.htmlMalcolm Matalka asked and Jeremy Yallop replied:
> I'm writing bindings for a library that is just doing I/O and wondering > what the suggested best practice is around using string or bigarray. It > seems like using Bigarray is probably the most versatile interface. > People can decide to do the copying themselves or just use Bigarray > everywhere. Yes, Bigarray is the more versatile choice, and probably the better default. > Are there any other things to consider? Suggestions? Since ctypes bindings are just OCaml programs, one possibility is to abstract over the choice of storage. David Sheets's libsodium bindings are a good example of this approach; for example, here's a functor which builds bindings for half a dozen functions based on an abstract "Sodium_storage.S" signature: https://github.com/dsheets/ocaml-sodium/blob/95d26a85/lib_gen/sodium_bindings.ml#L64-L76 Elsewhere in the library are implementations of Sodium_storage.S for Bigarray and for Bytes: https://github.com/dsheets/ocaml-sodium/blob/95d26a85/lib/sodium_storage.ml One pleasant aspect of this approach is that the abstraction over storage type doesn't cause any loss of type safety. You can use all the typed abstraction facilities of OCaml to construct your binding descriptions, and the generated C code is checked against the headers for the bound library by the C compiler.Gerd Stolpmann also replied:
Use bigarrays. There is one striking advantage: you need not to make a copy when calling blocking I/O functions. With strings/bytes you need to, because another thread could otherwise move the buffer while you are reading/writing.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-02/msg00110.htmlAnton Bachin announced:
I would like to announce the release of Namespaces, an Ocamlbuild plugin that gives your project logical nested modules based on its directory layout, as is common in the build systems of many other languages. So, src/server/foo.ml becomes Server.Foo, and src/client/foo.ml becomes Client.Foo. There is no conflict between the two foo.ml files, and thus no need to call them server_foo.ml and client_foo.ml. The project page and documentation can be found here: https://github.com/aantron/namespaces Namespaces works, but it abuses Ocamlbuild heavily, so there may be many corner cases that are not yet addressed well. Bug reports are very much welcome. If something can’t be fixed by changing Namespaces, perhaps Namespaces will be a good point of discussion for updating Ocamlbuild itself, or other OCaml tooling. Regards and enjoy, Anton P.S. How is Ocamlbuild spelled? I have seen it as Ocamlbuild, OCamlbuild (which stands to reason), and ocamlbuild in monospace font, in the original manual.
Here is a sneak peek at some potential future features of the Ocaml compiler, discussed by their implementers in these Github Pull Requests. docstrings https://github.com/ocaml/ocaml/pull/477
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.