Here is the latest Caml Weekly News, for the week of September 10 to 17, 2013.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00094.htmlLouis 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
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00170.htmlDeep 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.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00173.htmlDamien 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.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00196.htmlJonathan 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.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00184.htmlRomain 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.)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00197.htmlMark 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 . 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.  https://github.com/mshinwell/ocaml/blob/4.01-allocation-profiling/stdlib/allocation_profiling.mliGerd 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 ?
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00219.htmlYoriyuki 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
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-09/msg00223.htmlYoriyuki 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.
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
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.