Here is the latest OCaml Weekly News, for the week of April 26 to May 03, 2016.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00087.htmlJacques Garrigue announced:
This is a combined announce for new versions of LablTk and LablGTK, ready to serve you with OCaml 4.03. LablTk is an interface for the Tcl/Tk GUI toolkit, which allows you to build user interfaces very fast. It comes with the OCamlBrowser library explorer, which is not only a good demonstration of the power of LablTk, but also a useful companion in your everyday program development. https://forge.ocamlcore.org/projects/labltk/ Until ocaml-4.01, LablTk and OCamlBrowser were part of the standard distribution, but they were spun off to simplify maintenance. This new release contains a few bug fixes, and an upgrade of OCamlBrowser for OCaml 4.03 (as a result, ocamlbrowser will not compile on older versions). LablGTK is an interface for the Gtk+ toolkit, version 2. It also wraps many extensions, such as libglade, for rapid prototyping, or gtksourceview2, for programming editors. https://forge.ocamlcore.org/projects/lablgtk/ This is a bug fix release, which in particular fixes some incompatibilities with 4.03. Both libraries should also soon be available on opam. Jacques Garrigue LablTk 8.06.0 changelog: * Adapt to ocaml 4.03 * Fix const qualifiers in C code LablGTK 2.18.4 changelog: * update applications * Fix ml_gnome_canvas_c2w (Didier Le Botlan) * remove build dependency on camlp4 (still needed for tree version) * allow to change the GC speed (i.e. the impact of custom blocks) see GMain.Gc_custom.set_speed. * use own definition of alloc_custom, to be sure to allocate in the heap * fix GtkTree.TreeModel.cast * add get_image and get_pixbuf to GDraw.drawable.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00098.htmlContinuing the thread from last week, Fabrice Le Fessant announced:
OPAM-builder has been updated to display build results for all OPAM packages for this new version 4.03.0: http://opam.ocamlpro.com/builder/html/report-last.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00104.htmlSylvain Le Gall announced:
Hotfix version to compile with OCaml 4.03.0 + OPAM release. http://le-gall.net/sylvain+violaine/blog/index.php?post/2016/04/29/Release-of-OASIS-0.4.6
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00003.htmlDeep in this thread, Gabriel Scherer said:
Markus Weißmann: >>> The value comes from C bindings, but from a string-value via Char.code. >>> It is then passed through a constructor-function to create the record; >>> I added a check there to see if the C bindings are to blame: Gerd Stolpmann: >> Well, there are other types of errors in C bindings that could also >> cause this. Imagine what happens when the C bindings do not properly >> handle pointers (e.g. do not declare them as local roots), and an >> outdated pointer to an int is followed by the GC because of this. >> Because the minor GC moves values to the major heap, this could cause >> that the int is overwritten then. >> >> In my experience, it's always the C binding! >> >> Unfortunately, there's no code for investigations. Sébastien Hinderer: > Do you think there is room for improvement at this level? > > Do you already have a bit more precise ideas about the kind of tools that > coould be helpful? In 2006 there was work on a static analysis tool to check OCaml C stubs called "Saffire", which you can read about in detail here: http://www.cs.umd.edu/~jfoster/papers/cs-tr-4845.html Adrien Nader extracted the implementation and loaded it on the OCaml Forge in 2012, anyone interested in fixing/updating the project should probably get in touch with him: https://forge.ocamlcore.org/projects/saffire/ I have always been curious about how it would fare on the C bindings in the wild -- my guess is that it may have bitrotten a bit but that it would find a few issues, and also be very helpful during the development phase (where you iteratively hunt for segfaults), if it was an "opam install" away and easy to run. I have been trying to motivate the Frama-C people to find an excellent intern to write a specification of the OCaml memory model in ACSL (their specification language for C, http://frama-c.com/acsl.html ); the dream is that one may then be able to use Frama-C to check for safety of the C stubs, and even possibly verify some parts of the C codebase in the compiler distribution (probably not the runtime implementation itself, which precisely breaks the abstraction of the memory model, but at least large parts of C implementation of primitives, otherlibs/, etc.). I think they are interested as well, but I'm not sure they have found the time and people to work on this. Finally, note that Jeremy Yallop's Ctypes ( https://github.com/ocamllabs/ocaml-ctypes ) may be the better solution to write correct C bindings. I think that it is complementary with the above-mentioned efforts: - Saffire could be used to check legacy C stubs, of which there are many - A more precise model of the OCaml value representation and exposed runtime interface could help verify Ctypes itself and other future projects interacting with the runtime at a lower level. Ctypes is slightly more restricted than general C stubs, but substantially more safe (and more convenient). In my experience the unsafety of C bindings is a huge time sink, so starting with a Ctypes binding is almost certainly the most productive choice.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00006.htmlwhitequark announced:
I'm glad to announce the 1.1 release of ppx_import, which should be already available on OPAM. It adds support for OCaml 4.03 and nothing else
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00008.htmlwhitequark announced:
I'm glad to announce the 2.4 release of ppx_deriving_protobuf, which should be already available on OPAM. It adds support for OCaml 4.03 and nothing else.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00009.htmlwhitequark announced:
I'm glad to announce opam-cross-ios, an OPAM-based cross-toolchain in the spirit and using the conventions of opam-cross-android and opam-cross-windows. It is based on Gerd Stolpmann's work but expands it so that 1) multi-target deployments are trivial and 2) C libraries can be cross-compiled from within OPAM. : https://github.com/whitequark/opam-cross-ios : https://github.com/whitequark/opam-cross-android : https://github.com/whitequark/opam-cross-windows : http://psellos.com/ocaml/compile-to-iphone.html
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.