Hello
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.html
David 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.html
Simon 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.html
Yaron 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.html
Malcolm 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.html
Malcolm 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.html
Anton 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.