Hello
Here is the latest OCaml Weekly News, for the week of March 01 to 08, 2016.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00010.html
Damien Doligez announced:
The release of OCaml version 4.03.0 is drawing near. We have
created a beta version for your testing pleasure. Please
use `opam switch 4.03.0+beta1` to install it, then test
your favourite software with it. Then let me know whether
it works for you.
We want to know about all bugs. Please report them at
http://caml.inria.fr/mantis/bug_report_page.php .
This beta version is available as source code at these addresses:
https://github.com/ocaml/ocaml/releases/tag/4.03.0%2Bbeta1
http://caml.inria.fr/pub/distrib/ocaml-4.03/
and will (very soon) be available as an OPAM switch.
Happy hacking,
-- Damien Doligez for the OCaml team.
OCaml 4.03.0:
-------------
(Changes that can break existing programs are marked with a "*")
Language features:
- PR#5528: inline records for constructor arguments (Alain Frisch)
- PR#6220, PR#6403, PR#6437, PR#6801:
Improved redundancy and exhaustiveness checks for GADTs.
Namely, the redundancy checker now checks whether the uncovered pattern
of the pattern is actually inhabited, exploding at most one wild card.
This is also done for exhaustiveness when there is only one case.
Additionally, one can now write unreachable cases, of the form,
"pat -> .", which are treated by the redundancy check. (Jacques Garrigue)
- PR#6374: allow "_ t" as a short-hand for "(_, _, ..) t" for n-ary type
constructors (Alain Frisch)
- PR#6714: allow [@@ocaml.warning] on most structure and signature items:
values, modules, module types
(whitequark)
- GPR#26: support for "(type a b)" as syntactic sugar for "(type a) (type b)"
(Gabriel Scherer)
- GPR#42: short functor type syntax: "S -> T" for "functor (_ : S) -> T"
(Leo White)
- GPR#88: allow field punning in object copying expressions:
{< x; y; >} is sugar for {< x = x; y = y; >}
(Jeremy Yallop)
- GPR#112: octal escape sequences for char and string literals
(Rafaël Bocquet)
- GPR#167: allow to annotate externals' arguments and result types so
they can be unboxed or untagged. Supports untagging int and unboxing
int32, int64, nativeint and float.
(Jérémie Dimino, Mark Shinwell)
- GPR240: replace special annotations on externals by attributes:
* "float" is generalized to [@@unboxed]
* "noalloc" becomes [@@noalloc]
Deprecate "float" and "noalloc".
(Jérémie Dimino)
- GPR#254: @ocaml.warn_on_literal_pattern attribute on constructors to
warn when the argument is matches against a constant pattern. This
attribute is applied on predefined exception constructors which
take an purely informational (with no stability guarantee) message.
(Alain Frisch)
- GPR#268: hexadecimal notation for floating-point literals
In OCaml source code, FP literals can be written using the hexadecimal
notation 0x<mantissa in hex>p<exponent> from ISO C99.
(Xavier Leroy)
- GPR#173: [@inline] and [@inlined] attributes (for function declarations
and call sites respectively) to control inlining
(Pierre Chambart, Mark Shinwell)
- PR#6806: Syntax shortcut for putting a type annotation on a record field
(Valentin Gatien-Baron, review by Jérémie Dimino)
- PR#6806: Allow type annotations before the "->" in "fun <args> -> <expr>"
(Valentin Gatien-Baron, review by Jérémie Dimino)
- GPR#282: change short-paths penalty heuristic to assign the same cost to
idents containing double underscores as to idents starting with an underscore
(Thomas Refis, Leo White)
- GPR#273: allow to get the extension slot of an extension constructor
by writing [%extension_constructor <path>]
(Jérémie Dimino)
- PR#6681 GPR#326: signature items are now accepted as payloads for
extension and attributes, using the syntax [%foo: SIG ] or [@foo: SIG ].
(Alain Frisch and Gabriel Radanne)
* GPR#342: Allow shortcuts for extension and attributes on all keywords.
The attribute in "let[@foo] .. in .." is now attached to the value binding,
not to the expression.
(Gabriel Radanne)
* GPR#234: allow "[]" as a user-defined constructor. Demand parenthesis
around "::" when using "::" as user-defined constructor.
(Runhang Li, review by Damien Doligez)
- GPR#188: accept [@@immediate] attribute on type declarations to mark types
that are represented at runtime by an integer
(Will Crichton, reviewed by Leo White)
Compilers:
- PR#4080, PR#6537, PR#5333: fix stack overflow in the compiler when -pack'ing
a module
that includes a module of the same name (Alain Frisch)
- PR#4231, PR#5461: (interim solution) warning 31 is now fatal by default
- PR#4800: better compilation of tuple assignment (Gabriel Scherer and
Alain Frisch)
- PR#5995: keep -for-pack into account to name exceptions; document -for-pack
as mandatory for bytecode as well (Alain Frisch, report by Christophe
Troestler)
- PR#6400: better error message for '_' used as an expression
(Alain Frisch, report by whitequark)
- PR#6501: harden the native-code generator against certain uses of "%identity"
(Xavier Leroy, report by Antoine Miné).
- PR#6636: add --version option
(whitequark)
- improve type-specialization of unapplied primitives
(Frédéric Bour, review by Gabriel Scherer)
- PR#6737: fix Typedtree attributes on (fun x -> body) expressions
- PR#6679: fix pprintast printing of constraints in type declarations
- PR#6845: -no-check-prims to tell ocamlc not to check primitives in runtime
* PR#6865: remove special case for parsing "let _ = expr" in structures
(Jérémie Dimino, Alain Frisch)
* PR#6438: Pattern guard disables exhaustiveness check
(Alain Frisch)
- PR#6920: fix debug informations around uses of %apply or %revapply
(Jérémie Dimino)
- PR#6939: Segfault with improper use of let-rec (Alain Frisch)
- PR#6943: native-code generator for POWER/PowerPC 64 bits, both in
big-endian (ppc64) and little-endian (ppc64le) configuration.
(Xavier Leroy, with inspiration from RedHat's unofficial ppc64 and ppc64le
ports)
- PR#6979: better code generation in x86-32 backend for copying floats to
the stack (Marc Lasson, review by Xavier Leroy)
- PR#7018: fix missing identifier renaming during inlining (Alain Frisch,
review by Xavier Leroy)
- PR#7026, GPR#288: remove write barrier for polymorphic variants without
arguments
(Simon Cruanes)
- PR#7031: new warning, ambiguous guarded or-patterns (Luc Maranget,
Gabriel Scherer, report by Martin Clochard and Claude Marché).
- PR#7067: Performance regression in the native compiler for long
nested structures (Alain Frisch, report by Daniel Bünzli, review
by Jacques Garrigue)
- PR#7097: Strange syntax error message around illegal packaged module
signature constraints (Alain Frisch, report by Jun Furuse)
- PR#7118, PR#7120: Bug fixed in stack unwinding metadata generation.
Was a cause of crashes in GUI programs on OS X.
(Bart Jacobs)
- GPR#17: some cmm optimizations of integer operations with constants
(Stephen Dolan, review by Pierre Chambart)
- GPR#109: new unboxing strategy for float and int references (Vladimir Brankov,
review by Alain Frisch)
- GPR#107: Prevent more unnecessary float boxing, especially in `if` and `match`
(Vladimir Brankov, review by Alain Frisch)
- GPR#115: More precise typing of values at the C-- and Mach level,.
(Xavier Leroy, review by Pierre Chambart)
- GPR#132: Flambda: new intermediate language and "middle-end" optimizers
(Pierre Chambart, Mark Shinwell, Leo White)
- GPR#207: Colors in compiler messages (warnings, errors)
(Simon Cruanes, review by Gabriel Scherer)
- GPR#258: more precise information on PowerPC instruction sizes
(Pierre Chambart, Xavier Leroy)
- PR#7022, GPR#259: unbox float and boxed ints earlier, avoid second pass
(Alain Frisch)
- PR#7064, GPR#316: allowing to mark compilation units and sub-modules as
deprecated (Alain Frisch)
- GPR#263: improve code generation for if-equivalents of (&&) and (||)
(Pierre Chambart)
- GPR#271: Fix incorrect mutability flag when records are built using "with"
(Mark Shinwell)
- GPR#270: Make [transl_exception_constructor] generate [Immutable] blocks
(Mark Shinwell)
- GPR#275: native-code generator for IBM z System running Linux.
In memoriam Gene Amdahl, 1922-2015.
(Bill O'Farrell, Tristan Amini, Xavier Leroy)
- GPR#282: relax short-paths safety check in presence of module aliases, take
penalty into account while building the printing map.
(Thomas Refis, Leo White)
- GPR#306: Instrument the compiler to debug performance regressions
(Pierre Chambart)
- GPR#319: add warning for missing cmx files, and extend -opaque option to mli
files.
(Leo White)
- GPR#388: OCAML_FLEXLINK environment variable allows overriding flexlink
command (David Allsopp)
- GPR#407: don't display the name of compiled .c files when calling the
Microsoft C Compiler (same as the assembler).
(David Allsopp)
- GPR#431: permit constant float arrays to be eligible for pattern match
branch merging (Pierre Chambart)
- GPR#392: put all parsetree invariants in a new module Ast_invariants
(Jérémie Dimino)
- GPR#455: provide more debugging information to Js_of_ocaml
(Jérôme Vouillon)
Runtime system:
- PR#3612: allow allocating custom block with finalizers in the minor heap
(Pierre Chambart)
- PR#6517: use ISO C99 types {,u}int{32,64}_t in preference to our homegrown
types {,u}int{32,64}.
(Xavier Leroy)
- PR#6760: closures evaluated in the toplevel can now be marshalled
(whitequark, review by Jacques-Henri Jourdan)
- PR#6902, GPR#210: runtime emits a warning when finalizing an I/O channel
which is still open (Alain Frisch, review by Damien Doligez);
this is controlled by OCAMLRUNPARAM=W=1 or with Sys.enable_runtime_warnings.
- Signal handling: for read-and-clear, use GCC/Clang atomic builtins
if available. (Xavier Leroy)
- PR#6910, GPR#224: marshaling (output_value, input_value, et al)
now support marshaled data bigger than 4 Gb. (Xavier Leroy)
- GPR#226: select higher levels of optimization for GCC and Clang when
compiling the run-time system and C stub code. (Xavier Leroy)
- GPR#262: Multiple GC roots per compilation unit (Pierre Chambart, Mark
Shinwell, review by Damien Doligez)
- GPR#325: Add v=0x400 flag to OCAMLRUNPARAM to display GC stats on exit (Louis
Gesbert, review by Alain Frisch)
- GPR#297: Several changes to improve the worst-case GC pause time.
(Damien Doligez, with help from Leo White and Francois Bobot)
Standard library:
- PR#1460, GPR#230: Array.map2, Array.iter2
(John Christopher McAlpine)
- PR#5197, GPR#63: Arg: allow flags such as --flag=arg as well as --flag arg
(Richard Jones)
- PR#6017, PR#7034, GPR#267: More efficient ifprintf implementation
(Jeremy Yallop, review by Gabriel Scherer)
- PR#6296: Some documentation on the floating-point representations
recognized by Pervasives.float_of_string
(Xavier Leroy)
- PR#6316: Scanf.scanf failure on %u formats when reading big integers
(Xavier Leroy, Benoît Vaugon)
- PR#6321: guarantee that "hypot infinity nan = infinity"
(for conformance with ISO C99) (Xavier Leroy)
- PR#6390, GPR#36: expose Sys.{int_size,max_wosize} for improved js_of_ocaml
portability (Hugo Heuzard)
- PR#6449: Add Map.union (Alain Frisch)
* PR#6494: Add equal function in modules
Bytes, Char, Digest, Int32, Int64, Nativeint, and String
(Romain Calascibetta)
* PR#6524, GPR#79: Filename: Optional ?perms argument to open_temp_file
(Daniel Bünzli, review by Jacques-Pascal Deplaix)
* PR#6525, GPR#80: Add Uchar module to the standard library
(Daniel Bünzli, review by Yoriyuki Yamagata and Damien Doligez)
- PR#6577: improve performance of %L, %l, %n, %S, %C format specifiers
(Alain Frisch)
- PR#6585: fix memory leak in win32unix/createprocess.c
- PR#6649, GPR#222: accept (int_of_string "+3")
(Christopher McAlpine)
- PR#6645, GPR#174: Guarantee that Set.add, Set.remove, Set.filter
return the original set if no change is required (Alain Frisch,
Mohamed Iguernlala)
- GPR#175: Guarantee that Map.add, Map.remove, Map.filter
return the original map if no change is required.
(Mohamed Iguernlala)
- PR#6694, PR#6695: deprecate functions using ISO-8859-1 character set
in Char, Bytes, String and provide alternatives using US-ASCII.
(whitequark)
- GPR#164: more efficient (branchless) implementation of Pervasives.compare
specialized at type 'float'.
(Vladimir Brankov)
- GPR#201: generalize types of Printf.{ifprintf,ikfprintf}
(Maxence Guesdon)
- GPR#216: add the missing POSIX.1-2001 signals in Sys
(Guillaume Bury)
- GPR#239: remove type-unsafe code from Stream
(Pierre Chambart, review by Gabriel Scherer and Jeremy Yallop)
- GPR#250: Check for negative start element in Array.sub
(report and fix by Jeremy Yallop)
- GPR#265: new implementation of Queue avoiding Obj.magic
(Jérémie Dimino)
- GPR#268, GPR#303: '%h' and '%H' modifiers for printf and scanf to
support floating-point numbers in hexadecimal notation
(Xavier Leroy, Benoît Vaugon)
- GPR#272: Switch classify_float to [@@unboxed] (Alain Frisch)
- Improve speed of classify_float by not going through fpclassify()
(Alain Frisch, Xavier Leroy)
- GPR#277: Switch the following externals to [@@unboxed]:
* {Nativeint,Int32,Int64}.{of,to}_float
* Int{32,64}.float_of_bits
* Int{32,64}.bits_of_float
(Jérémie Dimino)
- GPR#281: Switch the following externals to [@@unboxed]:
* Sys.time (and [@@noalloc])
* Pervasives.ldexp (and [@@noalloc])
* Pervasives.compare for float, nativeint, int32, int64.
(François Bobot)
- PR#3622, GPR#195: add function Stack.fold
(Simon Cruanes)
- GPR#329: Add exists, for_all, mem and memq functions in Array
(Bernhard Schommer)
- GPR#337: Add [Hashtbl.filter_map_inplace] (Alain Frisch)
- GPR#356: Add [Format.kasprintf] (Jérémie Dimino, Mark Shinwell)
- GPR#22: Add the Ephemeron module that implements ephemerons and weak
hash table (François Bobot, review by Damien Doligez, Daniel Bünzli,
Alain Frisch, Pierre Chambart)
Type system:
- PR#5545: Type annotations on methods cannot control the choice of abbreviation
* PR#6465: allow incremental weakening of module aliases (Jacques Garrigue).
This is done by adding equations to submodules when expanding aliases.
In theory this may be incompatible is some corner cases defining a module
type through inference, but no breakage known on published code.
- PR#6593: Functor application in tests/basic-modules fails after commit 15405
Toplevel and debugger:
- PR#6113: Add descriptions to directives, and display them via #help
(Nick Giannarakis, Berke Durak, Francis Southern and Gabriel Scherer)
- PR#6396: Warnings-as-errors not properly flushed in the toplevel
(Alain Frisch)
- PR#6468: toplevel now supports backtraces if invoked with OCAMLRUNPARAM=b
(whitequark and Jake Donham,
review by Gabriel Scherer and Jacques-Henri Jourdan)
- PR#6935, GPR#298: crash in debugger when load_printer is given a directory
(Junsong Li, review by Gabriel Scherer)
- PR#6401: use proper error reporting for toplevel's environment
initialization (Gabriel Scherer)
- PR#7081: report preprocessor warnings in the toplevel
(Valentin Gatien-Baron, review by Jérémie Dimino)
- PR#7098: Loss of ppx context in toplevel after an exception
(Alain Frisch, report by whitequark)
- PR#7101: The toplevel does not close in_channel for libraries specified on
its command line (Alain Frisch)
- PR#7119: ocaml doesn't respect [@@@warning] (Alain Frisch, report by
Gabriel Radanne)
Other libraries:
* Unix library: channels created by Unix.in_channel_of_descr or
Unix.out_channel_of_descr no longer support text mode under Windows.
Calling [set_binary_mode_{in,out} chan false] on these channels
now causes an error.
- PR#4023 and GPR#68: add Unix.sleepf (sleep with sub-second resolution)
(Evgenii Lepikhin and Xavier Leroy)
* Protect Unix.sleep against interruptions by handled signals.
Before, a handled signal could cause Unix.sleep to return early.
Now, the sleep is restarted until the given time is elapsed.
(Xavier Leroy)
* PR#6120: implement Unix.symlink and Unix.readlink on Windows. Unix.symlink has
a new optional argument to_dir (ignored on non-native Windows platforms). stat
functions reimplemented to avoid buggy Microsoft CRT implementations (native
Windows only)
- PR#6263: add kind_size_in_bytes and size_in_bytes functions
to Bigarray module.
(Runhang Li, review by Mark Shinwell)
- PR#6289: Unix.utimes uses the current time only if both arguments
are exactly 0.0. Also, use sub-second resolution if available.
(Xavier Leroy, report by Christophe Troestler)
- PR#6896: serious reimplementation of Big_int.float_of_big_int and
Ratio.float_of_ratio, ensuring that the result is correctly rounded.
(Xavier Leroy)
- PR#6989: in Str library, make sure that all \(...\) groups are binding
and can be consulted with Str.matched_group. There used to be
a limitation to 32 binding groups.
(Xavier Leroy)
- PR#7013: spurious wake-up in the Event module
(Xavier Leroy)
- PR#7024: in documentation of Str regular expressions, clarify what
"end of line" means for "^" and "$" regexps.
OCamldep:
- GPR#286: add support for module aliases
(jacques Garrigue)
Manual:
- GPR#302: The OCaml reference manual is now included in the manual/
subdirectory of the main OCaml source repository. Contributions to
the manual are warmly welcome.
(François Bobot, review by Florian Angeletti)
- MPR#6676: ongoing simplification of the "Language Extensions" section
(Alain Frisch, John Whitington)
- MPR#7092, GPR#379: Add missing documentation for new 4.03 features
(Florian Angeletti)
- MPR#7109, GPR#380: Fix bigarray documentation layout
(Florian Angeletti, Leo White)
Bug fixes:
- PR#3612: memory leak in bigarray read from file
(Pierre Chambart, report by Gary Huber)
* PR#4166, PR#6956: force linking when calling external C primitives
(Jacques Garrigue, reports by Markus Mottl and Christophe Troestler)
* PR#4466, PR#5325: under Windows, concurrent read and write operations
on the same socket could block unexpectedly. Fixed by keeping sockets
in asynchronous mode rather than creating them in synchronous mode.
(Xavier Leroy)
* PR#4539: change exception string raised when comparing functional values
(Nicolas Braud-Santoni, report by Eric Cooper)
- PR#4832: Filling bigarrays may block out runtime
(Markus Mottl)
- PR#5663: program rejected due to nongeneralizable type variable that
appears nowhere
(Jacques Garrigue, report by Stephen Weeks)
- PR#5780: Strange type variable names in error messages (GADTs)
(only made the names more informative)
(Jacques Garrigue, report by Sebastien Furic)
- PR#5887: move the byterun/*.h headers to byterun/caml/*.h to avoid header
name clashes
(Jérôme Vouillon and Adrien Nader and whitequark)
* PR#6081: ocaml should add script's directory to search path, not current
directory
(Thomas Leonard and Damien Doligez)
- PR#6108, PR#6802: fail cleanly if dynlink.cma or ocamltoplevel.cma
are loaded inside the toplevel loop.
(Xavier Leroy)
- PR#6171: Error message confusing when a type escapes its scope.
- PR#6340: Incorrect handling of \r when processing "Windows" source files
(Damien Doligez, report by David Allsopp)
- PR#6342: Incorrect error message when type constraints differ
(Alain Frisch, report by Philippe Wang)
* PR#6521: {Bytes,Char,String}.escaped are locale-dependent
(Damien Doligez, report by Jun Furuse)
- PR#6526: ocamllex warning: unescaped newline in comment string
(Damien Doligez, report by user 'dhekir')
- PR#6341: ocamldoc -colorize-code adds spurious <br> tags to <pre> blocks
- PR#6560: Wrong failure message for {Int32,Int64,NativeInt}.of_string
(Maxime Dénès and Gabriel Scherer)
- PR#6648: show_module should indicate its elision
- PR#6650: Cty_constr not handled correctly by Subst
- PR#6651: Failing component lookup
* PR#6664: Crash when finalising lazy values of the wrong type.
(Damien Doligez)
- PR#6672: Unused variance specification allowed in with constraint
- PR#6744: Univars can escape through polymorphic variants (partial fix)
- PR#6752: Extensible variant types and scope escaping
- PR#6762: improve warning 45 in presence of re-exported type definitions
(Alain Frisch, report by Olivier Andrieu)
- PR#6776: Failure to kill the "tick" thread, segfault when exiting the runtime
- PR#6780: Poor error message for wrong -farch and -ffpu options (ocamlopt, ARM)
- PR#6805: Duplicated expression in case of hole in a non-failing switch.
(Luc Maranget)
- PR#6808: the parsing of OCAMLRUNPARAM is too lax
(Damien Doligez)
- PR#6874: Inefficient code generated for module function arguments
- PR#6888: The list command of ocamldebug uses the wrong file
(Damien Doligez, report by Pierre-Marie Pédrot)
- PR#6897: Bad error message for some pattern matching on extensible variants
- PR#6899: Optional parameters and non generalizable type variables
(Thomas Refis and Leo White)
- PR#6907: Stack overflow printing error in class declaration
- PR#6931: Incorrect error message
- PR#6938: fix regression on "%047.27{l,L,n}{d,i,x,X,o,u}"
(Benoît Vaugon, report by Arduino Cascella)
- PR#6944: let module X = Path in … is not typed as a module alias
(Jacques Garrigue, report by def)
- PR#6945 and GPR#227: protect Sys and Unix functions against string
arguments containing the null character '\000'
(c-cube and Xavier Leroy, report by Daniel Bünzli)
- PR#6946: Uncaught exception with wrong type for "%ignore"
- PR#6954: Infinite loop in type checker with module aliases
- PR#6972, GPR#276: 4.02.3 regression on documentation comments in .cmt files
(Leo White, report by Olivier Andrieu)
- PR#6977: String literals in comments interpret escape sequences
(Damien Doligez, report by Daniel Bünzli and David Sheets)
- PR#6980: Assert failure from polymorphic variants and existentials
- PR#6981: Ctype.Unify(_) with associated functor arg refering to previous one
- PR#6982: unexpected type error when packing a module alias
- PR#6985: `module type of struct include Bar end exposes
%s#row when Bar contains private row types
- PR#6992: Segfault from bug in GADT/module typing
- PR#6993: Segfault from recursive modules violating exhaustiveness assumptions
- PR#6998: Typer fails reading unnecessary cmis with -no-alias-deps and -w -49
(Leo White, report by Valentin Gatien-Baron)
- PR#7003: String.sub causes segmentation fault
(Damien Doligez, report by Radek Micek)
- PR#7008: Fatal error in ocamlc with empty compilation unit name
(Damien Doligez, report by Cesar Kunz)
- PR#7012: Variable name forgotten when it starts with a capital letter
(Jacques Garrigue, Gabriel Scherer,
report by Thomas Leonard and Florian Angeletti)
- PR#7016: Stack overflow in GADT typing
- PR#7030: libasmrun_shared.so fails to build on SPARC Solaris
(report and fix by Patrick Star)
- PR#7036: Module alias is not taken into account when checking module
type compatibility (in a class type) (Jacques Garrigue)
- PR#7037: more reproducible builds, don't put temp file names into objects
(Xavier Leroy)
- PR#7038: out of memory condition in caml_io_mutex_lock
(Xavier Leroy, report by Marc Lasson)
- PR#7039: Unix.getsockname returns garbage for unnamed PF_UNIX sockets
(Xavier Leroy)
- PR#7042 and GPR#295: CSE optimization confuses the FP literals +0.0 and -0.0
(Xavier Leroy)
- PR#7075: Fix repetitions in ocamldoc generated documentation
(Florian Angeletti)
- PR#7082: Object type in recursive module's `with` annotation
- PR#7108: ocamldoc, have -html preserve custom/extended html generators
(Armaël Guéneau)
- PR#7096: ocamldoc uses an incorrect subscript/superscript style
- PR#7115: shadowing in a branch of a GADT match breaks unused variable
warning (Alain Frisch, report by Valentin Gatien-Baron)
- PR#7133: Jump labels in assembly end up as symbols in the executable on OS X
(Bart Jacobs)
- PR#7135: only warn about ground coercions in -principal mode
(Jacques Garrigue, report by Jeremy Yallop)
- GPR#205: Clear caml_backtrace_last_exn before registering as root
(report and fix by Frederic Bour)
- GPR#220: minor -dsource error on recursive modules
(Hongbo Zhang)
- GPR#228: fix a dangling internal pointer in (bytecode )debug_info
(Gabriel Scherer and Mark Shinwell and Xavier Leroy)
- GPR#233: Make CamlinternalMod.init_mod robust to optimization
(Pierre Chambart, Mark Shinwell)
- GPR#249: fix a few hardcoded ar commands
(Daniel Bünzli)
- GPR#251: fix cross-compilation with ocamldoc enabled
(whitequark)
- GPR#280: Fix stdlib dependencies for .p.cmx (Pierre Chambart,
Mark Shinwell)
- GPR#283: Fix memory leaks in intern.c when OOM is raised
(Marc Lasson, review by Alain Frisch)
- GPR#22: Fix the cleaning of weak pointers. In very rare cases
accessing a value during the cleaning of the weak pointers could
result in the value being removed from one weak arrays and kept in
another one. That breaks the property that a value is removed from a
weak pointer only when it is dead and garbage collected. (François
Bobot, review by Damien Doligez)
- GPR#313: Prevent quadratic cases in CSE
(Pierre Chambart, review by Xavier Leroy)
- PR#6795, PR#6996: Make ocamldep report errors passed in
[%ocaml.error] extension points
(Jérémie Dimino)
- GPR#355: make ocamlnat build again
(Jérémie Dimino, Thomas Refis)
- GPR#405: fix compilation under Visual Studio 2015
(David Allsopp)
- GPR#441: better type error location in presence of type constraints
(Thomas Refis, report by Arseniy Alekseyev)
- PR#7111: reject empty let bindings instead of printing incorrect syntax
(Jérémie Dimino)
Features wishes:
- PR#4518, GPR#29: change location format for reporting errors in ocamldoc
(Sergei Lebedev)
- PR#4714: List.cons
- PR#5418 (comments) : generate dependencies with $(CC) instead of gcc
- PR#6167: OCAMLPARAM support for disabling PIC generation ("pic=0")
(Gabor Pali)
- PR#6367: introduce Asttypes.arg_label to encode labelled arguments
- PR#6452, GPR#140: add internal suport for custom printing formats
(Jérémie Dimino)
- PR#6611: remove the option wrapper on optional arguments in the syntax tree
- PR#6635: support M.[], M.(), M.{< >} and M.[| |]
(Jeremy Yallop, review by Gabriel Radanne)
- PR#6691: install .cmt[i] files for stdlib and compiler-libs
(David Sheets, request by Gabriel Radanne)
- PR#6722: compatibility with x32 architecture (x86-64 in ILP32 mode).
ocamlopt is not supported, but bytecode compiles cleanly.
- PR#6742: remove duplicate virtual_flag information from Tstr_class
- PR#6719: improve Buffer.add_channel when not enough input is available
(Simon Cruanes)
* PR#6816: reject integer and float literals directly followed by an identifier.
This was prevously read as two separate tokens.
[let abc = 1 in (+) 123abc] was accepted and is now rejected.
(Hugo Heuzard)
- PR#6876: improve warning 6 by listing the omitted labels.
(Eyyüb Sari)
- PR#6924: tiny optim to avoid some spilling of floats in x87
(Alain Frisch)
- GPR#111: `(f [@taillcall]) x y` warns if `f x y` is not a tail-call
(Simon Cruanes)
- GPR#118: ocamldep -allow-approx: fallback to a lexer-based approximation
(Frédéric Bour)
- GPR#137: add untypeast.ml (in open recursion style) to compiler-libs
(Gabriel Radanne)
- GPR#142: add a CAMLdrop macro for undoing CAMLparam*/CAMLlocal*
- GPR#145: speeedup bigarray access by optimizing Cmmgen.bigarray_indexing
(Vladimir Brankov, review by Gabriel Scherer)
- GPR#147: [type 'a result = Ok of 'a | Error of 'b] in Pervasives
(Yaron Minsky)
- GPR#156, GPR#279: optimize caml_frame_descriptors realloc (dynlink speedup)
(Pierre Chambart, Alain Frisch,
review by François Bobot, Xavier Leroy and Damien Doligez)
- GPR#191: Making gc.h and some part of memory.h public
(Thomas Refis)
- GPR#196: Make [Thread.id] and [Thread.self] [noalloc]
(Clark Gaebel)
- GPR#165, GPR#221: fix windows compilation warnings
(Bernhard Schommer, Gabriel Scherer, report by Alain Frisch)
- GPR#189: Added .dylib and .so as extensions for ocamlmklib
(Edgar Aroutiounian, whitequark)
- GPR#237: a CONTRIBUTING document
(François Bobot, Gabriel Scherer, review by Xavier Leroy)
- GPR#245: remove a few remaining French comments
(Florian Angeletti)
- GPR#252: improve build instructions in MSVC Windows README
(Philip Daian)
* GPR#170: Parse arbitrary precision integers.
Accept a single [A-Za-z] as modifier for integers (generalizing 'l','L','n')
and floats.
May cause breakage (ie. ppx preprocessor) because of changes in the parsetree.
This changes PR#6816 a little bit by reading the literal [123a] as a single
token that can later be rewritten by a ppx preprocessor.
(Hugo Heuzard)
- GPR#308: add experimental support for NetBSD/arm (verified on RaspberryPi)
(Rich Neswold)
- GPR#335: Type error messages specify if a type is abstract
because no corresponding cmi could be found. (Hugo Heuzard)
- GPR#365: prevent printing just a single type variable on one side
of a type error clash. (Hugo Heuzard)
- GPR#383: configure: define _ALL_SOURCE for build on AIX7.1
(tkob)
- GPR#401: automatically retry failed test directories in the testsuite
(David Allsopp)
- GPR#451: an optional 'parallel' target in testsuite/Makefile using the
GNU parallel tool to run tests in parallel.
(Gabriel Scherer)
Build system:
- GPR#388: FlexDLL added as a Git submodule and bootstrappable with the compiler
(David Allsopp)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00031.html
whitequark announced:
I'm pleased to announce the release of ppx_deriving_protobuf 2.3.
It will be available in OPAM shortly.
Changes since 2.2:
* A serious bug with integer overflow checking was fixed.
* Hygiene (provided by ppx_deriving >=3.0) was added.
* .protoc files can now be written using [@@deriving protobuf { protoc }].
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00043.html
Gerd Stolpmann announced:
a new release of OCamlnet is available for download: 4.1.1. The major
changes:
- Supports bytes, and builds with -safe-string so far possible.
OCaml-4.01 is still supported with the "bytes" add-on package
distributed with ocamlfind.
- Speeding up the exchange of RPC messages between threads of
the same process. This bypasses now some serialization steps.
(This will make most sense with multicore OCaml, of course,
and is provided in preparation of that.)
- Added an LDAP client
- Support some public-key cryptography
See the project page for download, documentation, a detailed changelog,
and the mailing list:
http://projects.camlcity.org/projects/ocamlnet.html
The repository has been moved to
https://gitlab.camlcity.org/gerd/lib-ocamlnet3
Gerd
PS. This overlaps with the OCaml-4.03 release window. I haven't found time to look into that.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00044.html
Gerd Stolpmann announced:
As a followup of the new OCamlnet-4.1.1 a number of other libraries have
also been updated. The new versions need OCamlnet-4.1.1 and require at
least OCaml-4.01.
For details, see the project pages:
http://projects.camlcity.org/projects/pxp.html
http://projects.camlcity.org/projects/webdav.html
http://projects.camlcity.org/projects/cache.html
http://projects.camlcity.org/projects/netamqp.html
http://projects.camlcity.org/projects/wdialog.html
http://projects.camlcity.org/projects/wtimer.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00045.html
Gerd Stolpmann announced:
The xstrp4 library has also been ported to use -safe-string. Yet, it is
still a camlp4 preprocessor.
http://projects.camlcity.org/projects/xstrp4.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00048.html
Christophe Raffalli announced:
I am please to annouce a first alpha release of gles3 for OCaml.
These are lightweight bindings for gles3, a join work with Alexandre
Miquel.
The package should be in the opam repository soon.
URLs: http://lama.univ-savoie.fr/~raffalli/gles3/
http://lama.univ-savoie.fr/~raffalli/gles3/gles3-050316.tar.gz
This is also a call for contributions, mainly:
- to test and debug
- port the egl.ml file to other platforms than linux/EGL/X11
(windows, OSX, linux/wayland, ios, android, ...)
Cheers,
Christophe Raffalli
--------------------------------------------------------------------
[1]OCaml [2]GLES 3.0 bindings
examples with shadows
Introduction
This project aims at providing a portable way to do OpenGL (precisely
GLES) application using OCaml. It comes in three parts:
* Low level bindings which allow to call directly GLES functions.
This binding tries to be reasonably type-safe using polymorphic
variants to encode Glenum type. The low level bindings also provide
some sanity checks for the size of bigarrays which allow to capture
quite a lot of errors with clear messages.
* High level bindings: to provide some auxiliary functions like
matrix inversion and ease the development. For instance, to use
shaders, with the high level bindings, you use compile_shader with
the sources code, get a value of type unit program. Then, you can
set the variables of the shaders (uniform or attributes), either as
constant or function and get a function to finally run the shaders.
* A way to open a window, start the main loop and interact. Currently
only EGL under X11 is supported but it would be nice to have
support for other platforms (windows, OSX, android, ios, wayland,
...) with exactly the same interface.
Authors
* [3]Alexandre Miquel (initial low level bindings for GLES 2)
* [4]Christophe Raffalli (partial port to GLES 3.0, high-level
bindings and examples)
Documentation
* [5]Generated html from the MLI files
* the examples:
[6]examples/testa_gles.ml: a rotating cube
[7]examples/testb_gles.ml: a rotating cube with a texture
[8]examples/testc_gles.ml: 7 rotating cubes with simple shadow
mapping
[9]examples/testd_gles.ml: 7 rotating cubes and 8 implicit surfaces
with simple shadow mapping
TODO (please contribute !)
* test and fix bugs !
* documentation
* complete the low-level bindings
* develop the high-level bindings guided by more examples
* provide support for more platforms (see introduction)
* find a way to support multiple version of GLES (at least 2.0, 3.0,
3.1) with only one OCaml library, and possibly in a transparent way
when using the high-level bindings (i.e., the high lebel bindings
should test the version and make the best choice)
* collect regexp for error message in GLSL for most GLES vendors to
give good error messages in all cases (only one vendor,
nouveau/mesa supported currently). This is a pity that GLES does no
define a standard at least for position in error messages.
* ...
Known bugs
* Mixing vertex arrays and buffer seems not to work (but no error
flag are positionned), for instance, vertex in a buffer and normal
in an array result in wrong normals. One shoud check this on a C
program...
* Textures are not yet garbage collected ... should be fixed soon
Références
1. http://caml.inria.fr/
2. https://www.khronos.org/registry/gles
3. https://www.fing.edu.uy/~amiquel/
4. file:///~raffalli
5. file:///home/raffalli/Caml/gles3/main.html
6. file:///home/raffalli/Caml/gles3/repos/examples/testa_gles.ml
7. file:///home/raffalli/Caml/gles3/repos/examples/testa_gles.ml
8. file:///home/raffalli/Caml/gles3/repos/examples/testa_gles.ml
9. file:///home/raffalli/Caml/gles3/repos/examples/testa_gles.ml
Hendrik Boom asked and Christophe Raffalli replied:
> Aren't there already bindings of OpenGL for OCaml?
Yes, but not for recent version of Open LG (i.e. version 3 and 4) or
GLES (any version).
gles3 are bindings for GLES which is available on every platforms
including cell phones and tablets.
The bindings also try to be different. Let me recall some context to
explain... There are also some discussions about teaching below ...
In OpenGL 1 series, you could send the vertices of your object using
one function call per vertex. There was a fixed pipeline processing
your data using a lot of state variables. There was also a stack of
matrices transformations.
With the apparition of GLSL (the Open GL Shading Language). All this
was not really used anymore, as the user is now free to do the
computation
- on CPU
- on GPU, for each vertex
- on GPU, for each fragment
This is very flexible indeed. And the way to share data also improved
with VBO.
In GLES and Open 3 or 4, the fixed pipeline, the possibility to send
vertices one by one, matrices stack, ... have all been
removed. Shaders are mandatory if you want to render anything.
To my knowledge there are no bindings for Open GL >= 3 or GLES from
OCaml. So this is the first.
One problem with recent Open GL is teaching ... From C this is very
technical and almost unasable with students. The idea of my bindings
is to have
- lowlevel bindings that are already a bit easier than using C
directly (more errors detected at typing and runtime).
- highlevel bindings usable by students, but also more confortable for
the general programmer. I actually used thess bindings with my
students this year ... Not perfect yet, but better than C or old
OpenGL OCaml bindings.
I hope this clarify things ...
> Might there be a reason to convert my rather feeble
> video game to gles3? (I'm currently using glMlite)
glMlite (from the web page) is OpenGL 1/2 with a sentence I do no get fully:
"glMLite is ready to develop forward compatible OpenGL 3.X programs!"
To know if should switch to gles3 .... you have to give it a try ...
If you have improvment to gles3 that would make you switch, please contribute !
Hezekiah M. Carty then said and Christophe Raffalli replied:
> > Aren't there already bindings of OpenGL for OCaml?
>
> Yes, but not for recent version of Open LG (i.e. version 3 and 4) or
> GLES (any version).
>
>
> There are thin bindings to OpenGL 3+4 and GLES 2+3:
> http://erratique.ch/software/tgls
>
> They have been around for a while, with the first release back in 2014 and the
> most recent last year.
Hello,
I did not know these bindings, but there are too lowlevel for what I
want when I teach (only one type for GLenum).
The lowlevel bindings of gles use polymorphic variant, so reading the
mli, you know what is allowed for a given GL function.
Moreover, the highlevel bindings provide the necessary functions to
really program. For instance, the Matrix module provide a function to
compute the NormalMatrix from the ModelView matrix. I know it is not
hard to inverse/transpose and extract a sub 3x3 matrice from a given
matrice, idem for an equivalent to the lookat GLU matrix ... But it is
better if this is already done.
The idea would be to have (we are not there yet) Highlevel binding
that can not trigger GLerror ... with little impact on performance.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00059.html
Vincent Jacques asked:
Does somebody have experience measuring test coverage of generated
lexers/parsers?
I'm using ocamllex/ocamlyacc [1] (but I can switch to Menhir [2]) to generate a
lexer/parser. In my tests, I simply check that some input strings give the ASTs
I expect.
I usually use Bisect [3] to make sure that my tests cover the code I intended to
cover, but in that configuration, Bisect is lost between the .mll/.mly files and
the generated .ml files and produces useless reports.
How would you measure test coverage in that case?
Thanks,
[1] http://caml.inria.fr/pub/docs/manual-ocaml/lexyacc.html
[2] http://gallium.inria.fr/~fpottier/menhir/
[3] http://bisect.x9c.fr/
Gabriel Scherer replied:
This is an interesting question and, as far as I know, there is no good solution
using existing versions of the interacting tools.
Below very simple patch that will add (*BISECT-IGNORE*) in front of every line
of code generated by Menhir, except those written by the programmer (the
"strecthes" in Menhir-speak). It applies cleanly on top of the latest released
Menhir archive,
http://gallium.inria.fr/~fpottier/menhir/menhir-20160303.tar.gz
The patch as-is is obviously a hack: it would need to be a configuration option
when running menhir, and hard-coding Bisect (or bisect_ppx)'s syntax into Menhir
is not elegant. One could try to have a configuration option to let users write
a fixed string (or comment) at the beginning of each generated code line, but
I'm not sure whether François Pottier (in cc:) would consider this is elegant
enough. François, would you comment on whether this is a direction that seems
acceptable to you?
(Bisect support ignoring entire regions at once by using (*BISECT-IGNORE-BEGIN*)
and (*BISECT-IGNORE-END*); we could try to implement that instead of a per-line
change, but I suspect that it would be slightly harder to implement (you have to
hook the beginning of input, end of input, and around each user-code insertion)
for no real gain.)
Toggling code-coverage semantics by inserting comments is not a very nice
interface (although rather logical when you think of the level of generality
required), so it's a bit frustrating that parser generators would have to play
at this level. It would be better to have a more structured, unified interface
supported by all the code-coverage tools, but to my knowledge no such thing
exists.
From d595ba5149a314c56623e1735af7678f5f62d525 Mon Sep 17 00:00:00 2001
From: Gabriel Scherer <gabriel.scherer@gmail.com>
Date: Sun, 6 Mar 2016 17:43:14 -0500
Subject: [PATCH] output (*BISECT-IGNORE*) in front of each
non-programmer-written line
EXPERIMENTAL PATCH: this should of course be turned into an explicit option
---
src/printer.ml | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/printer.ml b/src/printer.ml
index ea978bc..714bb08 100644
--- a/src/printer.ml
+++ b/src/printer.ml
@@ -46,6 +46,7 @@ let rawnl f =
let nl f =
rawnl f;
+ output_string f "(*BISECT-IGNORE*)";
output_substring f whitespace 0 !indentation
let indent ofs producer f x =
--
2.5.0
François Pottier then said:
This seems to be such a simple change in Menhir that it would be acceptable.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00063.html
Yotam Barnoy asked:
I'm thinking about my next project in OCaml, and I'm wondering how many users of
OCaml currently use Lwt or Async regularly.
One of the advantages of OCaml over Haskell (which I'm not crazy about) is the
fact that you don't have to constantly be stuck inside a monad. However, once
you want to use these user-level threading libraries, you're essentially tied to
a monad. It also means that the usage of any other monad from Lwt/Async code is
out -- OCaml doesn't have the monad transformer infrastructure to layer monads
easily as far as I can tell (am I wrong?). I mean, even in Haskell using Monad
Transformers is a pain (IMO).
Also, what happens to general utility functions that aren't rewritten for
Async/Lwt -- as far as I can tell, being in non-monadic code, they will always
starve other threads, since they cannot yield to another Async/Lwt thread. Is
this perception correct? If so, this seems to imply that you either write your
code to cooperate within these frameworks and suffer the monad, or don't, and
make it near-impossible for Lwt/Async users to make use of your code.
I would like to get an idea of the usage level of these libraries, as well as
the burden of writing compatible code, any difficulties etc. Also, I'd like to
get a sense of the domains that benefit from these libraries. Some domains (such
as gaming) traditionally involve a continuous main loop, and would thus only
suffer from the additional overhead of queuing in these libraries.
Malcolm Matalka replied:
I mostly use Async. However, I think most usage of Lwt or Async
requires doing as little as possible in these frameworks and using them
to orchestrate other functions. For example, I usually try to separate
parsing of a network protocol from the reading and writing of the bytes.
Simon Cruanes also replied:
It seems that Lwt is more popular in the community
outside JaneStreet than Async (if only by looking at its reverse
dependencies on opam.ocaml.org). There has been posts about this, for
instance http://rgrinberg.com/blog/2014/12/11/abandoning-async/ .
However, if you're writing a library, it is good taste (if possible) to
parametrize you code over an "IO" monad that will be easy to instantiate
with either Async or Lwt (or the trivial blocking monad where 'a t = 'a
and (>>=) x f = f x) along with the required IO primitives.
Regarding general utility functions, if they do not perform IO or depend
on (blocking) IO they can be used directly with Async/Lwt (unless they
really take a very long time to complete).
Ashish Agarwal replied to several persons:
Yotam Barnoy:
> Also, what happens to general utility functions that aren't rewritten for
> Async/Lwt -- as far as I can tell, being in non-monadic code, they will always
> starve other threads, since they cannot yield to another Async/Lwt thread.
There is Lwt_preemptive.detach and Async's In_thread.run to get around this.
Simon Cruanes:
> It seems that Lwt is more popular in the community outside JaneStreet than
> Async (if only by looking at its reverse dependencies on opam.ocaml.org). There
> has been posts about this, for instance
> http://rgrinberg.com/blog/2014/12/11/abandoning-async/ .
I'd be wary of drawing conclusions from one blog post and even from opam. I
think the answer is: both are used a lot. Also depends on what you mean by "a
user". It's not too useful to count Jane Street's packages and one barely used
package on opam both as 1. A lot of code is not on opam.
Yotam Barnoy:
> Is there an existing compatibility library functorized over the intersection
> of Async and Lwt? That would make being compatible with both much easier.
Most people provide this internally for each of their projects, e.g. Cohttp's IO
signature (https://github.com/mirage/ocaml-cohttp/blob/master/lib/s.mli).
However, we have quite a few projects that needed this abstraction, so
duplicating this code in each repo seemed wrong. Thus we developed future
(https://github.com/solvuu/future), which was recently released in opam.
Rudi Grinberg said:
Since my post was mentioned, I thought I’d chime in.
I’ve used both libraries and I’ve found little practical difference between the
two. I think porting a codebase from Lwt to Async (and vice versa) is mostly
mechanical work.
While I still prefer Async’s interface a little more but I think the two main
points in my blog post still stand. If portability and maximum interoperability
with the community are important to you then the decision is already made in my
eyes.
Ivan Gotovchits then said:
> While I still prefer Async’s interface
Me too, that's why we created an [overlay][1] over Lwt, that provides an
interface in the style of Core library.
I'm currently working on releasing this library to opam.
[1]: https://github.com/BinaryAnalysisPlatform/core-lwt
Ivan Gotovchits added:
We actually have another work, that heavily intersects with `Lwt` and `Async`.
It is code named `bap-future`[1], and in short this
is a library to work with asynchronous values. This can be seen, as `Lwt.t` or
`Ivar.t` cleaned up of everything unnecessary.
In the ideal future, the `Future.t` can be used as a common denominator between
`Lwt` and `Async`.
[1]:
https://github.com/BinaryAnalysisPlatform/bap/blob/master/lib/bap_future/bap_future.mli
P.S. It will be also released very soon.
Yaron Minsky said:
This is definitely a fraught topic, and it's unfortunate that there's
no clear solution.
To add a bit more information:
- Async is more portable than it once was. There's now Core_kernel,
Async_kernel and Async_rpc_kernel, which allows us to do things like
run Async applications in the browser. I would think Windows
support would be pretty doable by someone who understands that world
well.
That said, the chain of dependencies brought in by Async is still
quite big. This is something that could perhaps be improved, either
with better dead code analysis in OCaml, or some tweaks to
Async_kernel and Core_kernel themselves.
- There are things we could contemplate to make it easier to bridge
the divide. Jeremie Dimino did a proof of concept rewrite of lwt to
use async as its implementation, where an Lwt.t and a Deferred.t are
equal at the type level.
https://github.com/janestreet/lwt-async
Another possibility, and one that might be easier to write, would be
to allow Lwt code to run using the Async scheduler as another
possible back-end. This would allow one to have programs that used
both Async and Lwt together in one program, without running on
different threads.
It's worth mentioning if that there is interest in making Async more
suitable for a wider variety of goals, we're happy to work with
outside contributors on it. For example, if someone wanted to work on
Windows support for Async, we'd be happy to help out on integrating
that work.
Probably the biggest issue is executable size. That will get better
when we release an unpacked version of our external libraries. But
even then, the module-level granularity captures more things than
would be ideal.
Malcolm Matalka asked and Yaron Minsky replied:
> When I last looked at the scheduler it was limited to [select] or
> [epoll], is this still the case? How difficult would it be to expand on
> those?
Right now, only select and epoll are supported, but adding support for
something else isn't hard. The Async_unix library has an interface
called File_descr_watcher_intf.S, which both select and epoll go
through. Adding support for another shouldn't be difficult if someone
with the right OS expertise wants to do it.
Is there a particular kernel API you want support for?
Malcolm Matalka replied:
kqueue, I run most things on FreeBSD and select is sadly mostly useless
for anything serious. I've played with the idea of adding kqueue
support myself but haven't had the time.
Yotam Barnoy asked and Malcolm Matalka replied:
> Out of curiosity, what polling mechanism is available on the lwt side?
I believe Lwt supports multiple event loops underneath, including libuv
to get whatever polling the OS supports.
Adrien Nader then said:
Unless that has changed recently, it's using libev, not libuv. But the
crux remains the same: it relies on a C library that provides a
compatibility layer across event loops. I see little reason to not do
the same for Core rather than trying to handle properly each and every
mechanism around. The reason to also (still) support select() is that
it's everywhere (except that on Windows it's not really usable but there
you know you have libev or libuv).
Jeremie Dimino also said:
Yes, by default Lwt has a backend using Unix.select, and a libev one if
available at compile time (`opam install conf-libev`)
. At runtime Lwt will use the Unix.select backend by default, except if it was
configured to choose the libev one (the default on Linux) [1].
There is also a backend using the glib main loop, for GTK applications
[1] https://github.com/ocsigen/lwt/blob/master/_oasis#L88
Yaron Minsky asked and Jeremie Dimino replied:
> Jeremie, other than having some different back-ends available (e.g., glib
> main loop), how different are the approaches to backend management between
> Async and Lwt?
The backend interfaces are slightly different, but we just need a bit of glue in
the middle. Essentially the difference is that with Lwt you provide one callback
per fd and watch (read or write), while with Async you have a global callback.
Right now what we need to change in Async to make this work is:
- allow to provide a backend programmatically; right now you can only choose
between the predefined epoll and select ones
- make the scheduler ignore fds returned by the backend that are not handled by
async
François Berenger said:
> - Async is more portable than it once was. There's now Core_kernel,
> Async_kernel and Async_rpc_kernel, which allows us to do things like
> run Async applications in the browser. I would think Windows
> support would be pretty doable by someone who understands that world
> well.
Just for information: with the ZeroMQ bindings that are in opam
(package zmq), it is possible to do synchronous and/or asynchronous distributed
programming in OCaml.
That's not exactly RPC, but with some translation layer you can do some kind of
RPC.
However, unlike async, zmq is not a pure OCaml library so
that's not as portable. You need the right version of the ZeroMQ
C++ library to be installed.
But, the good news, some asynchronous programming can be done
in OCaml without pulling in neither async nor lwt. :)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00076.html
Gerd Stolpmann announced:
there is a new version of findlib. It's only a bug fix version:
- Uninstalling findlib no longer uninstalls the ocamlbuild library by
accident (Gabriel Scherer, Edwin Török)
- Adding an "ocamldoc" library, providing the cmi's for ocamldoc
plugins (suggested by Armaël Guéneau)
- Support for OCaml-4.03: recognize that the new -color option has an
argument (reported by Guillaume Bury)
The new version is available on the project page:
http://projects.camlcity.org/projects/findlib.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-03/msg00096.html
Daniel Bünzli announced:
I'd like to announce the first release of Hmap:
```
Hmap provides heterogeneous value maps for OCaml. These maps bind keys
to values with arbitrary types. Keys witness the type of the value
they are bound to which allows to add and lookup bindings in a type
safe manner.
```
Hmap has no dependency and is distributed under the ISC license.
Home page: http://erratique.ch/software/hmap/
API docs: http://erratique.ch/software/hmap/doc/Hmap
Yaron Minsky asked and Daniel Bünzli replied:
> Neat!
>
> I'm curious if you've looked at Core_kernel's Univ_map? I believe it's very
> similar in spirit, and I'm curious if there are any interesting differences
> there:
>
> https://github.com/janestreet/core_kernel/blob/master/src/univ_map.mli
No, I just abstracted code I've been c&p around in a lot of projects.
> Our type witnesses are a little interesting in that you can derive new
> witnesses from old ones (e.g., if a equals a', and b equals b', then a * b
> equals a' * b'). That said, I'm not sure that this is relevant for the
> heterogenous map use case.
The type identifiers are an implementation detail. I used to implement this
using a universal type, see e.g. [1], but the type identifier implementation
allocates less and should be more efficient (but the latter I didn't measure).
Best,
Daniel
[1] http://alan.petitepomme.net/cwn/2010.02.09.html#1
Here are links from many OCaml blogs aggregated at OCaml Planet,
http://ocaml.org/community/planet/. Since it is the first time this feed
is included, there are news older than a week.
OCaml Diary, Part 4b
http://rudenoise.uk/ocaml-diary-04b.html
OCaml 4.03: Everything else
https://blogs.janestreet.com/ocaml-4-03-everything-else/?utm_source=rss&utm_medium=rss&utm_campaign=ocaml-4-03-everything-else
Introducing Functoria
https://mirage.io/blog/introducing-functoria
Publishing an OPAM Package - a Checklist
http://rgrinberg.com/blog/2016/02/26/opam-package-checklist/
OCaml/MirageOS Diary, Part 4a
http://rudenoise.uk/ocaml-mirageos-diary-04a.html
A better inliner for OCaml, and why it matters
https://blogs.janestreet.com/flambda/?utm_source=rss&utm_medium=rss&utm_campaign=flambda
OCaml EFL 1.17.0 released
http://forge.ocamlcore.org/forum/forum.php?forum_id=929
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
Ocsigen: client-server widgets
https://ocsigen.github.io/blog/2016/02/22/tutorial-widgets/
OCaml/MirageOS Diary, Week 3
http://rudenoise.uk/ocaml-mirage-diary-03.html
Twenty-Four Puzzle OCaml iOS App
http://psellos.com/2016/02/2016.02.i-met-up-with-the-king.html
Scrap Your Camlp4
http://rgrinberg.com/blog/2016/02/15/scrap-your-camlp4/
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.