[cwn] Attn: Development Editor, Latest OCaml Weekly News

Tue May 3 06:47:09 PDT 2016

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.schmitt at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20160503/2d37ef35/attachment.pgp>