[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Sep 17 08:04:27 PDT 2013
Hello,
Here is the latest Caml Weekly News, for the week of September 10 to 17, 2013.
1) ReactiveML 1.09.01
2) OCaml vs Ada and/or GUI options
3) OCaml release 4.01.0
4) OCaml installer for Windows 4.01.0
5) ocamlbuild documentation
6) Allocation profiling for x86-64 native code
7) Camomile 0.8.5
8) ucorelib 0.0.2
9) Other Caml News
========================================================================
1) ReactiveML 1.09.01
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00094.html>
------------------------------------------------------------------------
** Louis Mandel announced:
We are happy to announce the new release of ReactiveML: <http://reactiveml.org>.
ReactiveML is a language similar to OCaml extended with a built-in notion of
parallel composition. It is based on the reactive synchronous model, a kind of
cooperative multithreading with a global notion of time.
The language is well suited to program applications with a lot of parallel
processes which communicate and synchronize a lot such as video games or
simulation problems.
ReactiveML is compiled into plain OCaml code and thus can link or be linked to any OCaml code.
This new version includes among others the following features:
- a new application to the programming of mixed music: <http://reactiveml.org/reactive_asco>
- the possibility to execute non-instantaneous code at top-level
- a new standard library which includes in particular:
Module Rml_list: process iterators on lists
Module Rml_process_manager: combinators for suspension, reconfiguration, ...
Module async: launching asychronous computations
- a new preemption construct with multiple handler to easily define automata.
The full list of changes is available at <http://reactiveml.org/distrib/changes>.
ReactiveML can be installed from the sources:
<http://reactiveml.org/distrib/rml-1.09.01-2013-09-10.tar.gz>
or using OPAM:
opam install rml
========================================================================
2) OCaml vs Ada and/or GUI options
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00170.html>
------------------------------------------------------------------------
** Deep in this huge thread, Jacques Garrigue asked and Alain Frisch replied:
> BTW, lexifi has also some internal system to build GUIs automatically.
> I don't know if there is a blog post on that.
Indeed, we build GUIs automatically, mapping type definitions to entry
screens (e.g. a sum type will produce a combobox, a list of record of
simple types will produce a data grid, etc). This is based on our
runtime type extension, and we use attributes on type definitions to
tweak the GUI layout/behavior (e.g. displaying some float field as a
percentage, or adding a groupbox around several fields). Some
customizations (such as adding buttons) can be added through "patches"
on the GUI. To specify these patches, we rely on a notion of "type path"
(strongly typed values describing a path in a data type seen as a tree).
All in all, this is very useful to generate large numbers of entry
screens without writing any GUI code while ensuring a great level of
uniformity across the application. This also makes it possible to
switch from one underlying GUI technology to another one quite easily
(our Windows desktop applications currently relies on .NET Windows
Forms, but we have other GUI backends in place -- including a web based
one).
Of course, the entire application is not only made of those "uniform"
entry screens, there are menus, toolbars, interactive charts, pages
using ad hoc widgets, etc, which are written in a more standard manual
style. For these parts, we found it quite convenient to use a
programming style allowing recursive definitions of controls and
associated callbacks. This is described in the "lazy let binding"
section of this blog post:
<https://www.lexifi.com/blog/ocaml-extensions-lexifi-semi-implicit-laziness>
This allows for a more functional style of building GUIs, while keeping
the standard underlying paradigm (as opposed to FRP GUI frameworks).
Here is the example from the blog post:
=============================================================
lazy let rec button1 =
button ~click:(fun () -> button2 # disable) "Button1"
and button2 =
button ~click:(fun () -> button1 # disable) "Button2"
and my_form =
form ~title:"Dialog example"
(hbox
[
button1;
button2;
button ~click:(fun () -> my_form # close) "Close";
]
)
in
my_form # run_modal
=============================================================
The typical equivalent of this code would require creating the form
object, the hbox panel, adding widgets to the hbox, adding the hbox to
the form, setting some text properties, and then registering a callback
on the buttons.
I guess it would be feasible to write some thin layer on top of LabGTK
supporting this style (assuming the "lazy let" binding goes upstream!),
and it would already make the client code look nicer.
========================================================================
3) OCaml release 4.01.0
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00173.html>
------------------------------------------------------------------------
** Damien Doligez announced:
Dear OCaml users,
We have the pleasure of celebrating the birthday of Irène
Joliot-Curie by announcing the release of OCaml version 4.01.0. This
is a major release that introduces type-based disambiguation of
constructors and record field labels, a whole lot of new warnings, and
many other features described in detail at the end of this mail.
It is available here: <http://caml.inria.fr/download.en.html>
This is released as source for the time being, binary versions will
probably be available in the near future.
We would like to take the opportunity to thank all the contributors,
bug reporters, and packagers who are helping us make OCaml better.
Thanks also to the people who tested the beta and RC versions and
reported on the results: Byron D. Allen, David Allsop, Mathieu Barbin,
John Carr, Anil Madhavapeddy, Christophe Raffalli, David Sheets, and
if I've forgotten someone, please forgive me.
Happy hacking,
-- Damien Doligez for the OCaml team.
High-level description of the changes:
======================================
Language features:
- It is now possible to have several variant constructors or record
fields of the same name in scope, and type information will be used
to disambiguate which one is used -- instead of always using the
last one.
ocaml -w +41 # warning 41, disabled by default,
# warns when the last-in-scope is used without type information
# type t = A | B;;
# type u = A;;
# let x : t = A;;
val x : t = A
# let y = A;;
Warning 41: A belongs to several types: u t
The first one was selected. Please disambiguate if this is wrong.
val y : u = A
This slightly controversial feature can be tweaked in various ways
through an extensive set of warning (40, 41, 42): by converting some
of them as errors, you can disable it completely or control its
applicability. See
<http://www.lexifi.com/blog/type-based-selection-label-and-constructors>
for a more detailed description of the feature.
(Jacques Garrigue, Alain Frisch and Leo P. White)
- The new warnings 44 and 45 (disabled by default) can be activated to
warn about identifiers that are used after having been shadowed by
an `open` construct. The `open` keyword can be written `open!` to
silence this warning (as method! silences the method warning). No
warning-silencing variant is available for the syntax `M.(e)`.
ocaml -w +44
# module M = struct let x = 1 end;;
module M : sig val x : int end
# let x = 2 in let open M in x;;
^^^^^^^^^^^^^^^
Warning 44: this open statement shadows
the value identifier x (which is later used)
- : int = 1
# let x = 2 in let open! M in x;;
- : int = 1
Warning 44 concerns all kinds of shadowing, except record labels and
variant constructors (warning 45). Those were separated out as users
of type-based disambiguation may want to shadow them freely, and yet
warn on usual shadowing of value variables.
(Alain Frisch, thanks to a request of Daniel Bünzli)
User experience:
- The -short-path option changes the way the type-checker prints types
to pick a short representation (eg. `string` instead of
`StringSet.elt`). Longer types are sometimes more helpful to
understand where the type comes from, but -short-path was found to
help readability in functor-heavy code, such as when using Jane
Street's Core library.
(Jacques Garrigue, with helpful feedback from Jane Street)
- The compiler now suggests possible typos on "unbound identifier" errors
(Gabriel Scherer)
# Unix.read_link;;
Error: Unbound value Unix.read_link
Did you mean readlink?
- After ten years being deprecated, infix operators (&) and (or) now
raise an activated-by-default warning (the existing warning 3,
Deprecated feature). Use (&&) and (||) instead. ISO-latin1
characters in variable names are also deprecated in this way.
(Damien Doligez)
- Infix application operators (|>) and (@@) are added to Pervasives
(Fabrice Le Fessant)
let even x = x mod 2 = 0
let () = [1;2;3] |> List.tl |> List.filter even |> List.iter print_int
let () = List.iter print_int @@ List.filter even @@ List.tl [1;2;3]
Runtime:
- Runtime support for printing general stack traces, and efficient
generation of stack traces or exception backtraces that won't be
printed immediately
(Jacques-Henri Jourdan and Gabriel Scherer, Alain Frisch)
- New -with-frame-pointers configure switch to add a frame pointer to
each stack frame. This improves the effectiveness of
debugging/profiling tools (in particular in-kernel 'perf' tool that
doesn't support the less invasive DWARF information approach
developed by Mark Shinwell), at the cost of a modest performance hit.
(Fabrice Le Fessant)
Background work:
- A lot of debugging for GADTs in the type system, in particular GADT
exhaustiveness checking; uncovered an old soundness bug due to
parametrized types implicitly considered injective in constraints
(Jacques Garrigue, Leo P. White and Jeremy Yallop)
- Jacques Garrigue also did subtle work to allow the propagation of
types inside all patterns, including those containing polymorphic
variants. This propagation is needed for GADT typing and type-based
disambiguation.
- A lot of work to speedup compilation with -annot and -bin-annot by
(Alain Frisch, with some help from Guillaume Melquiond)
- Adrien Nader integrated (thanks to careful review by Wojciech Meyer)
a big chunk of his cross-compilation patches; full cross-compilation
is not yet available but keeps getting closer.
- OCamlbuild benefited from lot of bugfixes and granted feature
wishes, as well as a shiny new testsuite
(Wojciech Meyer, Gabriel Scherer, with some help from Gabriel Kerneis)
- Damien Doligez did tedious work reorganizing the testsuite,
reproducing bugs in exotic settings, and setting
a continuous-integration instance to spot build failures earlier.
- Benedikt Meurer kept improving the ARM-backend (eg. CFI
directives support) and made general cleanups of register allocation
- Pierre Chambart integrated various performance-optimization
patches in various spots that were easy to optimize and led to
observable improvements; he's now working on a much more ambitious
analysis and optimization pass that is still in the prototype phase.
- A changelog message with attributions and too much detail.
(Gabriel Scherer)
Experimental features -- will probably change in the next versions:
- The new -ppx option allows to pass ast-to-ast rewriters as external
programs (Alain Frisch). It is still experimental, and not yet
featureful enough for wide usage. The forthcoming integration of the
extension_points work of Alain will make it suitable to more
use-cases.
- Experimental OCAMLPARAM environment variable to set compilation
option (just as from the command-line, but easier to tweak for users
that need to set some parameters globally for whole build)
(Fabrice Le Fessant)
- ocamlbuild has a new -plugin-tags option that allows to pass
arbitrary tags to the compilation of the myocamlbuild.ml
(Gabriel Scherer). This feature is still experimental, but the aim
is to let experts distribute reusable ocamlbuild plugin as
libraries, instead of having users copy-paste the recipe.
Some of the external contributions:
- Valentin Gatien-Baron fixed a quadratic blowup of linktime due to
a recent optimization of partial application primitives. He also
spotted a missing specialization of integer comparison that degraded
compilation times.
- Anil Madhavapeddy added ocamlbuild targets foo.byte.o, foo.byte.c
and foo.native.o for object file production (the -output-obj
compiler option)
- Christophe Troestler significantly improved the ocamlbuild API
documentation, found in the "signatures.mli" file exporting
user-visible interfaces for the OCamlbuild components accessible
from a plugin
- Benoît Vaugon and Chet Murthy contributed a non-invasive fix to
manipulation of bytecode files of size > Sys.max_string_length
(which could happen on 32bit machines)
-------------------------------------------------------------------------------
Change log:
===========
(Changes that can break existing programs are marked with a "*")
Other libraries:
- Labltk: updated to Tcl/Tk 8.6.
Type system:
- PR#5759: use well-disciplined type information propagation to
disambiguate label and constructor names
(Jacques Garrigue, Alain Frisch and Leo P. White)
* Propagate type information towards pattern-matching, even in the presence of
polymorphic variants (discarding only information about possibly-present
constructors). As a result, matching against absent constructors is no longer
allowed for exact and fixed polymorphic variant types.
(Jacques Garrigue)
* PR#6035: Reject multiple declarations of the same method or instance variable
in an object
(Alain Frisch)
Compilers:
- PR#5861: raise an error when multiple private keywords are used in type
declarations
(Hongbo Zhang)
- PR#5634: parsetree rewriter (-ppx flag)
(Alain Frisch)
- ocamldep now supports -absname
(Alain Frisch)
- PR#5768: On "unbound identifier" errors, use spell-checking to suggest names
present in the environment
(Gabriel Scherer)
- ocamlc has a new option -dsource to visualize the parsetree
(Alain Frisch, Hongbo Zhang)
- tools/eqparsetree compares two parsetree ignoring location
(Hongbo Zhang)
- ocamlopt now uses clang as assembler on OS X if available, which enables
CFI support for OS X.
(Benedikt Meurer)
- Added a new -short-paths option, which attempts to use the shortest
representation for type constructors inside types, taking open modules
into account. This can make types much more readable if your code
uses lots of functors.
(Jacques Garrigue)
- PR#5986: added flag -compat-32 to ocamlc, ensuring that the generated
bytecode executable can be loaded on 32-bit hosts.
(Xavier Leroy)
- PR#5980: warning on open statements which shadow an existing
identifier (if it is actually used in the scope of the open); new
open! syntax to silence it locally
(Alain Frisch, thanks to a report of Daniel Bünzli)
* warning 3 is extended to warn about other deprecated features:
- ISO-latin1 characters in identifiers
- uses of the (&) and (or) operators instead of (&&) and (||)
(Damien Doligez)
- Experimental OCAMLPARAM for ocamlc and ocamlopt
(Fabrice Le Fessant)
- PR#5571: incorrect ordinal number in error message
(Alain Frisch, report by John Carr)
- PR#6073: add signature to Tstr_include
(patch by Leo P. White)
Standard library:
- PR#5899: expose a way to inspect the current call stack,
Printexc.get_callstack
(Gabriel Scherer, Jacques-Henri Jourdan, Alain Frisch)
- PR#5986: new flag Marshal.Compat_32 for the serialization functions
(Marshal.to_*), forcing the output to be readable on 32-bit hosts.
(Xavier Leroy)
- infix application operators |> and @@ in Pervasives
(Fabrice Le Fessant)
Other libraries:
- PR#5568: add O_CLOEXEC flag to Unix.openfile, so that the returned
file descriptor is created in close-on-exec mode
(Xavier Leroy)
Runtime system:
* PR#6019: more efficient implementation of caml_modify() and caml_initialize().
The new implementations are less lenient than the old ones: now,
the destination pointer of caml_modify() must point within the minor or
major heaps, and the destination pointer of caml_initialize() must
point within the major heap.
(Xavier Leroy, from an experiment by Brian Nigito, with feedback
from Yaron Minsky and Gerd Stolpmann)
Internals:
- Moved debugger/envaux.ml to typing/envaux.ml to publish env_of_only_summary
as part of compilerlibs, to be used on bin-annot files.
(Fabrice Le Fessant)
- The test suite can now be run without installing OCaml first.
(Damien Doligez)
Bug fixes:
- PR#3236: Document the fact that queues are not thread-safe
(Damien Doligez)
- PR#3468: (part 1) Sys_error documentation
(Damien Doligez)
- PR#3679: Warning display problems
(Fabrice Le Fessant)
- PR#3963: Graphics.wait_next_event in Win32 hangs if window closed
(Damien Doligez)
- PR#4079: Queue.copy is now tail-recursive
(patch by Christophe Papazian)
- PR#4138: Documentation for Unix.mkdir
(Damien Doligez)
- PR#4469: emacs mode: caml-set-compile-command is annoying with ocamlbuild
(Daniel Bünzli)
- PR#4485: Graphics: Keyboard events incorrectly delivered in native code
(Damien Doligez, report by Sharvil Nanavati)
- PR#4502: ocamlbuild now reliably excludes the build-dir from hygiene check
(Gabriel Scherer, report by Romain Bardou)
- PR#4762: ?? is not used at all, but registered as a lexer token
(Alain Frisch)
- PR#4788: wrong error message when executable file is not found for backtrace
(Damien Doligez, report by Claudio Sacerdoti Coen)
- PR#4812: otherlibs/unix: add extern int code_of_unix_error (value error);
(Goswin von Berdelow)
- PR#4887: input_char after close_in crashes ocaml (msvc runtime)
(Alain Frisch and Christoph Bauer, report by ygrek)
- PR#4994: ocaml-mode doesn't work with xemacs21
(Damien Doligez, report by Stéphane Glondu)
- PR#5098: creating module values may lead to memory leaks
(Alain Frisch, report by Milan Stanojevi?)
- PR#5102: ocamlbuild fails when using an unbound variable in rule dependency
(Xavier Clerc, report by Daniel Bünzli)
* PR#5119: camlp4 now raises a specific exception when 'DELETE_RULE' fails,
rather than raising 'Not_found'
(ygrek)
- PR#5121: %( %) in Format module seems to be broken
(Pierre Weis, first patch by Valentin Gatien-Baron, report by Khoo Yit Phang)
- PR#5178: document in INSTALL how to build a 32-bit version under Linux x86-64
(Benjamin Monate)
- PR#5212: Improve ocamlbuild error messages of _tags parser
(ygrek)
- PR#5240: register exception printers for Unix.Unix_error and Dynlink.Error
(Jérémie Dimino)
- PR#5300: ocamlbuild: verbose parameter should implicitly set classic display
(Xavier Clerc, report by Robert Jakob)
- PR#5327: (Windows) Unix.select blocks if same socket listed in first and
third arguments
(David Allsopp, displaying impressive MSDN skills)
- PR#5343: ocaml -rectypes is unsound wrt module subtyping (was still unsound)
(Jacques Garrigue)
- PR#5350: missing return code checks in the runtime system
(Xavier Leroy)
- PR#5468: ocamlbuild should preserve order of parametric tags
(Wojciech Meyer, report by Dario Texeira)
- PR#5551: Avoid repeated lookups for missing cmi files
(Alain Frisch)
- PR#5552: unrecognized gcc option -no-cpp-precomp
(Damien Doligez, report by Markus Mottl)
- PR#5580: missed opportunities for constant propagation
(Xavier Leroy and John Carr)
- PR#5611: avoid clashes betwen .cmo files and output files during linking
(Wojciech Meyer)
- PR#5662: typo in md5.c
(Olivier Andrieu)
- PR#5673: type equality in a polymorphic field
(Jacques Garrigue, report by Jean-Louis Giavitto)
- PR#5674: Methods call are 2 times slower with 4.00 than with 3.12
(Jacques Garrigue, Gabriel Scherer, report by Jean-Louis Giavitto)
- PR#5694: Exception raised by type checker
(Jacques Garrigue, report by Markus Mottl)
- PR#5695: remove warnings on sparc code emitter
(Fabrice Le Fessant)
- PR#5697: better location for warnings on statement expressions
(Dan Bensen)
- PR#5698: remove harcoded limit of 200000 labels in emitaux.ml
(Fabrice Le Fessant, report by Marcin Sawicki)
- PR#5702: bytecomp/bytelibrarian lib_sharedobjs was defined but never used
(Hongbo Zhang, Fabrice Le Fessant)
- PR#5708: catch Failure"int_of_string" in ocamldebug
(Fabrice Le Fessant, report by user 'schommer')
- PR#5712: (9) new option -bin-annot is not documented
(Damien Doligez, report by Hendrik Tews)
- PR#5731: instruction scheduling forgot to account for destroyed registers
(Xavier Leroy, Benedikt Meurer, reported by Jeffrey Scofield)
- PR#5734: improved Win32 implementation of Unix.gettimeofday
(David Allsopp)
- PR#5735: %apply and %revapply not first class citizens
(Fabrice Le Fessant, reported by Jun Furuse)
- PR#5738: first class module patterns not handled by ocamldep
(Fabrice Le Fessant, Jacques Garrigue, reported by Hongbo Zhang)
- PR#5739: Printf.printf "%F" (-.nan) returns -nan
(Xavier Leroy, David Allsopp, reported by Samuel Mimram)
- PR#5741: make pprintast.ml in compiler_libs
(Alain Frisch, Hongbo Zhang)
- PR#5747: 'unused open' warning not given when compiling with -annot
(Alain Frisch, reported by Valentin Gatien-Baron)
- PR#5752: missing dependencies at byte-code link with mlpack
(Wojciech Meyer, Nicholas Lucaroni)
- PR#5763: ocamlbuild does not give correct flags when running menhir
(Gabriel Scherer, reported by Philippe Veber)
- PR#5765: ocamllex doesn't preserve line directives
(Damien Doligez, reported by Martin Jambon)
- PR#5770: Syntax error messages involving unclosed parens are sometimes
incorrect
(Michel Mauny)
- PR#5772: problem with marshaling of mutually-recursive functions
(Jacques-Henri Jourdan, reported by Cédric Pasteur)
- PR#5775: several bug fixes for tools/pprintast.ml
(Hongbo Zhang)
- PR#5784: -dclambda option is ignored
(Pierre Chambart)
- PR#5785: misbehaviour with abstracted structural type used as GADT index
(Jacques Garrigue, report by Jeremy Yallop)
- PR#5787: Bad behavior of 'Unused ...' warnings in the toplevel
(Alain Frisch)
- PR#5793: integer marshalling is inconsistent between architectures
(Xavier Clerc, report by Pierre-Marie Pédrot)
- PR#5798: add ARM VFPv2 support for Raspbian (ocamlopt)
(Jeffrey Scofield and Anil Madhavapeddy, patch review by Benedikt Meurer)
- PR#5802: Avoiding "let" as a value name
(Jacques Garrigue, report by Tiphaine Turpin)
- PR#5805: Assert failure with warning 34 on pre-processed file
(Alain Frisch, report by Tiphaine Turpin)
- PR#5806: ensure that backtrace tests are always run (testsuite)
(Xavier Clerc, report by user 'michi')
- PR#5809: Generating .cmt files takes a long time, in case of type error
(Alain Frisch)
- PR#5810: error in switch printing when using -dclambda
(Pierre Chambart)
- PR#5811: Untypeast produces singleton tuples for constructor patterns
with only one argument
(Tiphaine Turpin)
- PR#5813: GC not called when unmarshaling repeatedly in a tight loop (ocamlopt)
(Xavier Leroy, report by David Waern)
- PR#5814: read_cmt -annot does not report internal references
(Alain Frisch)
- PR#5815: Multiple exceptions in signatures gives an error
(Leo P. White)
- PR#5816: read_cmt -annot does not work for partial .cmt files
(Alain Frisch)
- PR#5819: segfault when using [with] on large recursive record (ocamlopt)
(Xavier Leroy, Damien Doligez)
- PR#5821: Wrong record field is reported as duplicate
(Alain Frisch, report by Martin Jambon)
- PR#5824: Generate more efficient code for immediate right shifts.
(Pierre Chambart, review by Xavier Leroy)
- PR#5825: Add a toplevel primitive to use source file wrapped with the
coresponding module
(Grégoire Henry, Wojciech Meyer, caml-list discussion)
- PR#5833: README.win32 can leave the wrong flexlink in the path
(Damien Doligez, report by William Smith)
- PR#5835: nonoptional labeled arguments can be passed with '?'
(Jacques Garrigue, report by Elnatan Reisner)
- PR#5840: improved documentation for 'Unix.lseek'
(Xavier Clerc, report by Matej Ko?ík)
- PR#5848: Assertion failure in type checker
(Jacques Garrigue, Alain Frisch, report by David Waern)
- PR#5858: Assert failure during typing of class
(Jacques Garrigue, report by Julien Signoles)
- PR#5865: assert failure when reporting undefined field label
(Jacques Garrigue, report by Anil Madhavapeddy)
- PR#5872: Performance: Buffer.add_char is not inlined
(Gerd Stolpmann, Damien Doligez)
- PR#5876: Uncaught exception with a typing error
(Alain Frisch, Gabriel Scherer, report by Julien Moutinho)
- PR#5877: multiple "open" can become expensive in memory
(Fabrice Le Fessant and Alain Frisch)
- PR#5880: 'Genlex.make_lexer' documention mentions the wrong exception
(Xavier Clerc, report by Virgile Prevosto)
- PR#5885: Incorrect rule for compiling C stubs when shared libraries are not
supported.
(Jérôme Vouillon)
- PR#5891: ocamlbuild: support rectypes tag for mlpack
(Khoo Yit Phang)
- PR#5892: GADT exhaustiveness check is broken
(Jacques Garrigue and Leo P. White)
- PR#5906: GADT exhaustiveness check is still broken
(Jacques Garrigue, report by Sébastien Briais)
- PR#5907: Undetected cycle during typecheck causes exceptions
(Jacques Garrigue, report by Pascal Zimmer)
- PR#5910: Fix code generation bug for "mod 1" on ARM.
(Benedikt Meurer, report by user 'jteg68')
- PR#5911: Signature substitutions fail in submodules
(Jacques Garrigue, report by Markus Mottl)
- PR#5912: add configure option -no-cfi (for OSX 10.6.x with XCode 4.0.2)
(Damien Doligez against XCode versions, report by Thomas Gazagnaire)
- PR#5914: Functor breaks with an equivalent argument signature
(Jacques Garrigue, report by Markus Mottl and Grégoire Henry)
- PR#5920, PR#5957: linking failure for big bytecodes on 32bit architectures
(Benoît Vaugon and Chet Murthy, report by Jun Furuse and Sebastien Mondet)
- PR#5928: Missing space between words in manual page for ocamlmktop
(Damien Doligez, report by Matej Ko?ík)
- PR#5930: ocamldep leaks temporary preprocessing files
(Gabriel Scherer, report by Valentin Gatien-Baron)
- PR#5933: Linking is slow when there are functions with large arities
(Valentin Gatien-Baron, review by Gabriel Scherer)
- PR#5934: integer shift by negative amount (in otherlibs/num)
(Xavier Leroy, report by John Regehr)
- PR#5944: Bad typing performances of big variant type declaration
(Benoît Vaugon)
- PR#5945: Mix-up of Minor_heap_min and Minor_heap_max units
(Benoît Vaugon)
- PR#5948: GADT with polymorphic variants bug
(Jacques Garrigue, report by Leo P. White)
- PR#5953: Unix.system does not handle EINTR
(Jérémie Dimino)
- PR#5965: disallow auto-reference to a recursive module in its definition
(Alain Frisch, report by Arthur Windler via Gabriel Scherer)
- PR#5973: Format module incorrectly parses format string
(Pierre Weis, report by Frédéric Bour)
- PR#5974: better documentation for Str.regexp
(Damien Doligez, report by william)
- PR#5976: crash after recovering from two stack overflows (ocamlopt on MacOS X)
(Xavier Leroy, report by Pierre Boutillier)
- PR#5977: Build failure on raspberry pi: "input_value: integer too large"
(Alain Frisch, report by Sylvain Le Gall)
- PR#5981: Incompatibility check assumes abstracted types are injective
(Jacques Garrigue, report by Jeremy Yallop)
- PR#5982: caml_leave_blocking section and errno corruption
(Jérémie Dimino)
- PR#5985: Unexpected interaction between variance and GADTs
(Jacques Garrigue, Jeremy Yallop and Leo P. White and Gabriel Scherer)
- PR#5988: missing from the documentation: -impl is a valid flag for ocamlopt
(Damien Doligez, report by Vincent Bernardoff)
- PR#5989: Assumed inequalities involving private rows
(Jacques Garrigue, report by Jeremy Yallop)
- PR#5992: Crash when pattern-matching lazy values modifies the scrutinee
(Luc Maranget, Leo P. White)
- PR#5993: Variance of private type abbreviations not checked for modules
(Jacques Garrigue)
- PR#5997: Non-compatibility assumed for concrete types with same constructor
(Jacques Garrigue, report by Gabriel Scherer)
- PR#6004: Type information does not flow to "inherit" parameters
(Jacques Garrigue, report by Alain Frisch)
- PR#6005: Type unsoundness with recursive modules
(Jacques Garrigue, report by Jérémie Dimino and Josh Berdine)
- PR#6010: Big_int.extract_big_int gives wrong results on negative arguments
(Xavier Leroy, report by Drake Wilson via Stéphane Glondu)
- PR#6024: Format syntax for printing @ is incompatible with 3.12.1
(Damien Doligez, report by Boris Yakobowski)
- PR#6001: Reduce the memory used by compiling Camlp4
(Hongbo Zhang and Gabriel Scherer, report by Henri Gouraud)
- PR#6031: Camomile problem with -with-frame-pointers
(Fabrice Le Fessant, report by Anil Madhavapeddy)
- PR#6032: better Random.self_init under Windows
(Alain Frisch, Xavier Leroy)
- PR#6033: Matching.inline_lazy_force needs eta-expansion (command-line flags)
(Pierre Chambart, Xavier Leroy and Luc Maranget,
regression report by Gabriel Scherer)
- PR#6046: testsuite picks up the wrong ocamlrun dlls
(Anil Madhavapeddy)
- PR#6056: Using 'match' prevents generalization of values
(Jacques Garrigue, report by Elnatan Reisner)
- PR#6058: 'ocamlbuild -use-ocamlfind -tag thread -package threads t.cma' fails
(Gabriel Scherer, report by Hezekiah M. Carty)
- PR#6060: ocamlbuild rules for -principal, -strict-sequence and -short-paths
(Anil Madhavapeddy)
- PR#6069: ocamldoc: lexing: empty token
(Maxence Guesdon, Grégoire Henry, report by ygrek)
- PR#6072: configure does not handle FreeBSD current (i.e. 10) correctly
(Damien Doligez, report by Prashanth Mundkur)
- PR#6074: Wrong error message for failing Condition.broadcast
(Markus Mottl)
- PR#6084: Define caml_modify and caml_initialize as weak symbols to help
with Netmulticore
(Xavier Leroy, Gerd Stolpmann)
- PR#6090: Module constraint + private type seems broken in ocaml 4.01.0
(Jacques Garrigue, report by Jacques-Pascal Deplaix)
- PR#6109: Typos in ocamlbuild error messages
(Gabriel Kerneis)
- PR#6123: Assert failure when self escapes its class
(Jacques Garrigue, report by whitequark)
- PR#6158: Fatal error using GADTs
(Jacques Garrigue, report by Jeremy Yallop)
- PR#6163: Assert_failure using polymorphic variants in GADTs
(Jacques Garrigue, report by Leo P. White)
- PR#6164: segmentation fault on Num.power_num of 0/1
(Fabrice Le Fessant, report by Johannes Kanig)
Feature wishes:
- PR#5181: Merge common floating point constants in ocamlopt
(Benedikt Meurer)
- PR#5243: improve the ocamlbuild API documentation in signatures.mli
(Christophe Troestler)
- PR#5546: moving a function into an internal module slows down its use
(Alain Frisch, report by Fabrice Le Fessant)
- PR#5597: add instruction trace option 't' to OCAMLRUNPARAM
(Anil Madhavapeddy, Wojciech Meyer)
- PR#5676: IPv6 support under Windows
(Jérôme Vouillon, review by Jonathan Protzenko)
- PR#5721: configure -with-frame-pointers for Linux perf profiling
(Fabrice Le Fessant, test by Jérémie Dimino)
- PR#5722: toplevel: print full module path only for first record field
(Jacques Garrigue, report by ygrek)
- PR#5762: Add primitives for fast access to bigarray dimensions
(Pierre Chambart)
- PR#5769: Allow propagation of Sys.big_endian in native code
(Pierre Chambart, stealth commit by Fabrice Le Fessant)
- PR#5771: Add primitives for reading 2, 4, 8 bytes in strings and bigarrays
(Pierre Chambart)
- PR#5774: Add bswap primitives for amd64 and arm
(Pierre Chambart, test by Alain Frisch)
- PR#5795: Generate sqrtsd opcode instead of external call to sqrt on amd64
(Pierre Chambart)
- PR#5827: provide a dynamic command line parsing mechanism
(Hongbo Zhang)
- PR#5832: patch to improve "wrong file naming" error messages
(William Smith)
- PR#5864: Add a find operation to Set
(François Berenger)
- PR#5886: Small changes to compile for Android
(Jérôme Vouillon, review by Benedikt Meurer)
- PR#5902: -ppx based pre-processor executables accept arguments
(Alain Frisch, report by Wojciech Meyer)
- PR#5986: Protect against marshaling 64-bit integers in bytecode
(Xavier Leroy, report by Alain Frisch)
- PR#6049: support for OpenBSD/macppc platform
(Anil Madhavapeddy, review by Benedikt Meurer)
- PR#6059: add -output-obj rules for ocamlbuild
(Anil Madhavapeddy)
Tools:
- OCamlbuild now features a bin_annot tag to generate .cmt files.
(Jonathan Protzenko)
- OCamlbuild now features a strict_sequence tag to trigger the
strict-sequence option.
(Jonathan Protzenko)
- OCamlbuild now picks the non-core tools like ocamlfind and menhir from PATH
(Wojciech Meyer)
- PR#5884: Misc minor fixes and cleanup for emacs mode
(Stefan Monnier)
- PR#6030: Improve performance of -annot
(Guillaume Melquiond, Alain Frisch)
** Romain Bardou asked and Richard Jones replied:
> Is this available anywhere else than from the source code?
Fedora 21, from this weekend.
** Pierre-Malo Deniélou also replied:
Mageia Cauldron, from yesterday.
========================================================================
4) OCaml installer for Windows 4.01.0
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00196.html>
------------------------------------------------------------------------
** Jonathan Protzenko announced:
The OCaml installer for Windows platforms has been updated
<http://protz.github.io/ocaml-installer/> and now also features the
latest version of OCaml.
========================================================================
5) ocamlbuild documentation
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00184.html>
------------------------------------------------------------------------
** Romain Bardou asked and Gabriel Scherer replied:
> Is this available anywhere else than from the source code?
> <http://brion.inria.fr/gallium/index.php/Ocamlbuild> has a link to
> <http://gallium.inria.fr/~pouillar/ocamlbuild/html/Signatures.PLUGIN.html>,
> should
> this be updated? The manual has an Ocamlbuild section, should there be a
> link from there to the API?
No, this is currently not available anywhere else. For curious users, the
source code can be browsed in various places, such as:
<http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/ocamlbuild/signatures.mli?view=markup>
<https://github.com/ocaml/ocaml/blob/trunk/ocamlbuild/signatures.mli>
Note that the "ocamlbuild API" is mostly meant for rather advanced users
(which should be comfortable reading a .mli file in their favorite text
editor). Assuming the availability of satisfying documentation (more on
that later), the long-term picture is that most users should only use a
tiny subset of the API -- currently mostly the `flag` command.
Given that the wiki is not a great success in terms of crowd-writing
documentation or visibility, I have decided to start another approach: I
started writing a new ocamlbuild manual during August (trying to fix some
of the complaints people had on the existing one), and a preview of the
result can be seen here:
<https://github.com/gasche/manual-ocamlbuild>
I will gladly accept contributions, including porting content present on
the Wiki, or just adding content. I am still investigating options to
mechanically generate some parts of this documentation from the source
code; I think the "reference section" could basically include the output of
a beefed up `-documentation` output, but am not sure how to integrate the
API signature. The best solution could be to simply run ocamldoc, and then
include the .html in the result -- this is how the OCaml manual itself does
it, and it seems to work ok.
(I had planned to give myself more time to improve this documentation
draft, before making a call to contributions on the list, but your message
prompted an earlier response. Thanks for your interest.)
========================================================================
6) Allocation profiling for x86-64 native code
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00197.html>
------------------------------------------------------------------------
** Mark Shinwell said:
Large OCaml programs can experience performance degradation due to high
garbage collection loads (or possibly due to it being Friday 13th).
Understanding the memory usage of such programs can also be difficult.
To this end, I am pleased to release a version of OCaml 4.01 that
contains functionality for the memory profiling of native code programs,
for the x86-64 architecture. Currently it is only fully working on Linux
platforms, but there should be a version for Mac OS X in the near future,
and the BSDs.
opam remote add mshinwell git://github.com/mshinwell/opam-repo-dev
opam update
opam switch 4.01-allocation-profiling
The source is on GitHub:
<https://github.com/mshinwell/ocaml/tree/4.01-allocation-profiling>
Using ocamlopt with -allocation-tracing and running in an environment
with the OCAMLRUNPARAM environment variable including the letter "T"
enables the use of the functionality in the new [Allocation_profiling]
standard library module [1]. You should also ensure that you have
the new ocamlmklocs script (installed to the same place as the
compiler binaries) on your PATH at compile time.
The runtime system for this compiler contains instrumentation that can
produce a global analysis showing the total number of words allocated
on the OCaml heaps by source location. This works not only for blocks
allocated in OCaml code but also in C stubs. Further, values are
instrumented---without space overhead---in order to be able to determine
from a snapshot of the heap which value was allocated where; and also
to provide a runtime API that can be queried from the instrumented
program itself. Following Unix tradition, there is no shiny user
interface. Scripts are provided to decode the data from the former
two analyses. There is also a script that can draw a graph of the
heap quotiented by the equivalence relation that identifies two
blocks iff they were allocated at the same source location.
Programs compiled with allocation profiling will run slower than under
normal compilation, but this degradation should not be that
significant. They will use a little more memory than normal, but not
much, and the amount of increase roughly speaking is about twice the
size of the machine code in your program. (In particular there is
no overhead per value allocated.)
Source locations reported are very slightly approximated, but this
should not normally cause a problem.
Sometimes the source location that appears in the profile may not be
quite the function you're looking for (e.g. some allocation function
that's called from multiple places; the allocation function rather
than the callers might show up). The system goes to some rudimentary
efforts to avoid this by looking back up the stack one level under
certain conditions, but if you get stuck, you can set a breakpoint in
gdb on the function identified in the profile and collect a backtrace
every time you pass it. These can then be uniquified by a shell script
left as an exercise to the reader. (This technique has been discussed
previously on this list.)
This is not yet a fully-polished system, but it has been used at Jane
Street on rather large OCaml programs with success. The part that still
requires most work is the runtime API. If you experience long compile
times then you can disable the runtime API support by editing the
ocamlmklocs script to write an empty file; fixing this is on the list.
(See the comment in stdlib/allocation_profiling.mli.) This is on the
list to be fixed.
I would be interested to hear of reports of success or failure; or
feature requests. One feature on the near-term list is being able to
measure how long a particular value has been in existence.
Have fun.
Mark
P.S. There is some related work going on at OCamlPro using similar
techniques. These projects were developed independently, but we expect
to collaborate on getting some of this technology into the main
distribution.
[1] <https://github.com/mshinwell/ocaml/blob/4.01-allocation-profiling/stdlib/allocation_profiling.mli>
** Gerd Stolpmann asked and Mark Shinwell replied:
> A dumb question: how do you do the value instrumentation? Without space
> overhead? There is not much information in the value itself...
The maximum size of blocks is reduced and then an
approximation to the instruction pointer at the point of
allocation is stored in the spare space in the header
word. (More detail to follow in a reply to Jacques-Henri.)
** Jacques-Henri Jourdan asked and Mark Shinwell replied:
> This is a really interesting work !
>
> Actually, I have had this project of making a memory profiler for Ocaml
> for a few months. My idea was to do some statistical profiling by
> annotating only a fraction of the allocated blocks.
I think it's certainly worth experimenting with different approaches.
I've tried to address your points below.
> Here was the advantages I thought about :
>
> 1- Lower execution time overhead. BTW, what is yours ?
I don't have any exact figures to hand, and in fact, it will
potentially vary quite a lot depending on the amount of allocation.
I think the time overhead is maybe 20% at the moment for a large
allocation-heavy application.
This could be decreased somewhat---firstly by optimizing, and
secondly by maybe allowing the "global"
(cf. [Allocation_profiling.Global] in the stdlib) analysis to be
disabled. (This analysis was actually the predecessor of the
value-annotating analysis.) The remaining overhead of annotating
the values is small.
> 2- When annotating a block, we could decide to store more information.
> Typically, it could be very profitable to know (at least a part of) the
> current backtrace while allocating.
Agreed. I'm hoping to do some work on capturing a partial
backtrace in that scenario.
> 3- We could also analyze more precisely the life of annotated objects
> without much performance constrains, because they are fewer. We could
> for example put watchpoints on them to know when they accessed, or do
> statistics about there life time...
I think if using watchpoints you'd have to pick and choose what
you instrument fairly carefully, in any case, otherwise everything
will grind to a halt. Lifetime statistics are likely to be supported
soon (this should be easy).
> 4- Your method for annotating blocks uses the 22 highest bits of the
> blocks headers to store the bits 4..25 of the allocation point address.
> I can see several (minor) problems of doing that
> - The maximum size of a block is then limited to 32GB.
I think such blocks are unlikely to occur in practice. I'd argue
that it's most likely a mistake to have such large allocations inside
the OCaml heap, too.
> - That does mean that those 22 bits identify the allocation point,
> and I am not convinced that the probability of collision is negligible
> in the case of large code base (like code) non-contiguously loaded in
> memory because of dynlink, for example.
I neglected to say that this is not expected to work with natdynlink
at the moment. I think for x86-64 Linux the current assumption about
contiguous code is correct, at least using the normal linker scripts,
and the range is probably sufficient.
The main place where the approximation could be problematic, I think,
is where there are allocation points close together that can't quite
be distinguished. In practice I'm not sure this is a problem, though.
> - This is not usable for x86-32 bits.
I'm not sure x86-32 is worthy of much attention any more (dare
I say it!) but 32-bit platforms more generally I think still are
of concern. My plan for upstreaming this work includes a patch
to enable compiler hackers to adjust the layout of the block header
more easily (roughly speaking, removing hard-coded constants in
the code) and that may end up including an option to allocate more
than one header word per block. This could then be used to solve
the 32-bit problem, as well as likely being a useful platform for
other experiments.
> With statistical profiling, we can afford having a separate table of
> traced blocks, that we would maintain at the end of each GC phase. This
> way, we don't actually "annotate" blocks, but we rather annotate the
> corresponding table entry.
This seems like it might cause quite a lot of extra work, and
disturb cache behaviour, no? (The current "global" analysis
mentioned above in my system will disturb the cache too, but I
think if that's turned off, just the value annotation should not.)
> 5- It is not necessary to walk the whole heap to understand some of its
> properties, but rather only the traced blocks.
>
> There is an easy and cheap way to do statistical profiling of memory
> allocation: we could decide that each allocation exceeding
> caml_young_limit should receive a special treatment in order to be traced.
>
> So, do you think this would be a good idea to implement ? Any other
> comments ?
========================================================================
7) Camomile 0.8.5
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00219.html>
------------------------------------------------------------------------
** Yoriyuki Yamagata announced:
I am pleased to announce the new release of Camomile, a Unicode
library for OCaml. This release is a bug fix release. You can download the new version from
<https://github.com/yoriyuki/Camomile/releases/tag/rel-0.8.5>
You can find the general information at the Wiki
<https://github.com/yoriyuki/Camomile/wiki>
========================================================================
8) ucorelib 0.0.2
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00223.html>
------------------------------------------------------------------------
** Yoriyuki Yamagata announced:
I am pleased to announce the new release of ucorelib, a simple Unicode
library for OCaml. This release adds the supports of all UTF encodings
(UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE).
<https://github.com/yoriyuki/ucorelib/releases/tag/v0.0.2>
ucorelib will be the core of the series of libraries which will provides
various operation over Unicode.
** Adrien Nader asked and Yoriyuki Yamagata replied:
> Can you explain how this relates to Camomile? Is this meant to be a
> replacement at some point in the future?
Yes, it is meant to replace Camomile in the future. I think there are
several problems in Camomile.
1. Monolithic. Camomile is a large library. it forces you to install many
encodings even if you want to just, say, use UTF-8. I will brake Camomile
into the pieces. ucorelib will be a core part of such libraries.
2. Not type safe. UTF-8 string exposes internal byte strings. ucorelib
will provide abstract Text data type whose internal data structure is
hidden.
3. Imperative. Camomile mimics OCaml standard strings which are
imperative. Instead, ucorelib and related libraries will be purely
functional.
4. Functor. Camomile uses functor a lot. Unfortunately this seems to
repel the beginners. ucorelib uses the module language essential ways
(code converters are implemented by using first class modules) but for
casual users it does not requires any knowledge of OCaml's module system.
5. Data files. Camomile needs to external data files to start. This
causes a lot of problems. ucorelib does not need external data files.
6. Unicode version. I want to upgrade everything to Unicode 0.6.X, not
0,3,X.
========================================================================
9) Other Caml News
------------------------------------------------------------------------
** From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at <http://planet.ocaml.org/>.
Code layout of Fan (a metaprogramming tool for OCaml):
<http://hongboz.wordpress.com/2013/09/16/code-layout-of-fan-a-metaprogramming-tool-for-ocaml/>
Full Time: Software Developer (Functional Programming) at Jane Street in New York, NY; London, UK; Hong Kong:
<http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45>
Camlpdf, the first good command-line PDF tool I've found:
<http://anil.recoil.org/2013/09/16/camlpdf-the-end-of-sucky-pdf-tools.html>
OCaml 4.01.0 entering Rawhide:
<http://rwmj.wordpress.com/2013/09/14/ocaml-4-01-0-entering-rawhide/>
Expiration of SSL certificate and upcoming forge.ocaml.org:
<https://forge.ocamlcore.org/forum/forum.php?forum_id=885>
OCaml 4.01.0 released:
<http://caml.inria.fr/pub/distrib/ocaml-4.01/>
Monomophic let in OCaml?:
<http://gallium.inria.fr/blog/monomorphic_let>
========================================================================
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/> .
========================================================================
More information about the caml-news-weekly
mailing list