Hello, Here is the latest OCaml Weekly News, for the week of April 26 to May 03, 2016.
1) LablTk 8.06.1 and LablGTK 2.18.4 2) OCaml release 4.03.0 3) OASIS 0.4.6 4) Obj.out_of_heap_tag, out of minor heap or memory corruption? 5) ppx_import 1.1 6) ppx_deriving_protobuf 2.4 7) opam-cross-ios ======================================================================== 1) LablTk 8.06.1 and LablGTK 2.18.4 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00087.html> ------------------------------------------------------------------------ ** Jacques 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. ======================================================================== 2) OCaml release 4.03.0 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00098.html> ------------------------------------------------------------------------ ** Continuing 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> ======================================================================== 3) OASIS 0.4.6 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-04/msg00104.html> ------------------------------------------------------------------------ ** Sylvain 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> ======================================================================== 4) Obj.out_of_heap_tag, out of minor heap or memory corruption? Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00003.html> ------------------------------------------------------------------------ ** Deep 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. ======================================================================== 5) ppx_import 1.1 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00006.html> ------------------------------------------------------------------------ ** whitequark 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 ======================================================================== 6) ppx_deriving_protobuf 2.4 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00008.html> ------------------------------------------------------------------------ ** whitequark 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. ======================================================================== 7) opam-cross-ios Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-05/msg00009.html> ------------------------------------------------------------------------ ** whitequark announced: I'm glad to announce opam-cross-ios[1], an OPAM-based cross-toolchain in the spirit and using the conventions of opam-cross-android[2] and opam-cross-windows[3]. It is based on Gerd Stolpmann's work[4] but expands it so that 1) multi-target deployments are trivial and 2) C libraries can be cross-compiled from within OPAM. [1]: <https://github.com/whitequark/opam-cross-ios> [2]: <https://github.com/whitequark/opam-cross-android> [3]: <https://github.com/whitequark/opam-cross-windows> [4]: <http://psellos.com/ocaml/compile-to-iphone.html> ======================================================================== Old cwn ------------------------------------------------------------------------ If you happen to miss a CWN, you can send me a message (alan.schm...@polytechnique.org) and I'll mail it to you, or go take a look at the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish to receive it every week by mail, you may subscribe online at <http://lists.idyll.org/listinfo/caml-news-weekly/> . ======================================================================== -- OpenPGP Key ID : 040D0A3B4ED2E5C7 Monthly Athmospheric CO₂, Mauna Loa Obs. 2015-03: 401.52, 2016-03: 404.83
signature.asc
Description: PGP signature
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly
