Hello
Here is the latest OCaml Weekly News, for the week of November 21 to 28, 2017.
Archive: https://discuss.ocaml.org/t/obuild-v0-1-9-is-4-06-0-compilant/1165/1
UnixJunkie announced:
Thanks to the obuild maintainer Jerome Maloberti and contributions from
Jacques Pascal Deplaix and Andy Li.
This is already in the opam repository.
Archive: https://discuss.ocaml.org/t/ann-minivpt-2-0-0-in-opam/1166/1
UnixJunkie announced:
The vantage point tree implementation in OCaml has a new functorial interface.
Thanks to Ilias Garnier for contributing.
Toplevel usage example:
#require "minivpt";;
module Point_2D =
struct
type t = float * float
let dist (x0, y0) (x1, y1) =
let square x =
x *. x
in
sqrt (square (x0 -. x1) +. square (y0 -. y1))
end
module Vpt = Vp_tree.Make(Point_2D)
-->
module Vpt :
sig
type t = Vp_tree.Make(Point_2D).t
val create : Point_2D.t list -> t
val nearest_neighbor : Point_2D.t -> t -> float * Point_2D.t
val to_list : t -> Point_2D.t list
val is_empty : t -> bool
end
Archive: https://discuss.ocaml.org/t/ann-ocaml-mariadb-0-9-0/1170/1
Andre Nathan announced:
I've released a new version of OCaml-MariaDB. The main change is that now
library users are expected to call `Mariadb.library_end` explicitly when they
are done using the library. Previously this function was called automatically
after `Mariadb.close`. While this is fine when linking to libmysqlclient, it
breaks the Connector/C (libmariadbclient) when multiple database connections are
instantiated. This problem was reported by Donovan Mueller.
This release also includes contributions by Petter Urkedal and Jan Pöschko.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-11/msg00059.html
Bob announced:
BuckleScript is an optimizing compiler for OCaml to generate readable
JavaScript, it was open sourced by Bloomberg [1] and also supported by Facebook
Reason team.
Most highlighted features:
1. Automatic JS converter between OCaml and JS values
2. Compiler made relocatable (we prebuilt it for MacOS and Windows, the
installation time is reduced from 2min to 14s, we will also prebuild it for
Linux in next release)
3. Generalize type specialized comparisons, also emit a warning for polymorphic
comparison(warning number 102)
A non-complete list of changes is available here:
https://github.com/BuckleScript/bucklescript/blob/master/Changes.md#210
Happy Thanksgiving && Happy hacking OCaml! -- Hongbo
[1]: https://github.com/bucklescript/bucklescript/
Archive: https://discuss.ocaml.org/t/ocaml-hack-event-4-06-opam-fixes-compiler-projects/1181/1
gemmag announced:
The recent OCaml 4.06 release has made the long-awaited switch to immutable
strings by default. However, this has resulted in a significant number of opam
packages requiring modifications to build - we are hosting an OCaml Hack Evening
on **Thursday 7th December from 19:00-22:30 at Pembroke College, Cambridge** to
fix as many as possible.
Please indicate your interest via the
[Doodle](https://doodle.com/poll/khqk6i49r4828apu) by Thursday 30th November.
If you cannot physically attend, but would like to help fix up packages in the
meantime / during the event in your local timezone, check [Obi for the
failures](http://obi.ocamllabs.io/triage.html). Fix all the red things :P
----
**When**: Thursday 7 December 2017, 19:00 - 22:30
**Where**: The Thomas Gray Room, Pembroke College, Cambridge CB2 1RF
**Who**: anyone interested in improving OCaml. Knowledge of OCaml programming
will obviously be helpful, but prior experience of working on OCaml internals
isn't necessary
**Refreshments**: Finger buffet in hack room
**What**: Fixing opam packages, fixing bugs, implementing new features, learning
about OCaml internals
**Wiki**: https://github.com/ocamllabs/compiler-hacking/wiki
The OCaml 4.06 release featured safe-string as the default rather than optional
as per previous releases. The focus of this event will be to work on the opam
repository to [fix up as many packages as
possible](http://obi.ocamllabs.io/triage.html), and also to publish a guide on
ocamllabs.io detailing how to migrate your packages for wider use.
As well as fixing up opam packages, you can find information on [mini projects
and other compiler
projects](https://github.com/ocamllabs/compiler-hacking/wiki/Things-to-work-on)
on the wiki.
The evening will also feature a short (5-10 min) presentation about the recent
MirageOS Marrakech Hack Retreat.
Anil Madhavapeddy then added:
Anyone who can't make it to Cambridge -- we could congregate in #ocaml as well :-)
Archive: https://discuss.ocaml.org/t/ann-secp256k1-ml-0-3-2/1190/1
Davide Gessa announced:
Hi, this is my first post here, and I would like to announce the new release of
the ocaml library secp256k1-ml.
This library wrap the secp256k1 EC(DSA) library into an OCaml library. At the
moment only a subset of functionalities are available:
* Context: create, clone, destroy, randomize
* Elliptic curve: public key creation
* ECDSA: verify, sign, recover
This library was first released by me, but Vincent Bernardoff and Yoichi Hirai
helped to improve the library.
Repository: https://github.com/dakk/secp256k1-ml
Opam page: https://opam.ocaml.org/packages/secp256k1/
cfcs asked and Davide Gessa replied:
> Do you have plans to include an OCaml implementation as well?
Not in the short term and not in this packages (which is a wrapper of libsecp).
Atm there is a pure ocaml ECC implementation here:
https://github.com/nickgian/ECC-OCaml
Archive: https://discuss.ocaml.org/t/ann-bitcoinml-0-3-1/1191/1
Davide Gessa announced:
Bitcoinml is a Bitcoin data-structures library for OCaml.
This project is directly related to **letchain**
(https://github.com/dakk/letchain), an OCaml Bitcoin full-node implementation
still work-in-progress.
Bitcoinml provides support for the following data-structures:
* Address (with also bech32 addresses)
* Block
* Block_lazy (lazy block evaluation)
* Hash
* Merkleroot
* Script (script execution, common pattern recognizer)
* Tx (In, Out, Witness)
* Varint (CompactSize)
* Params (network parameters for BTC, XTN and BCH)
Repository + odoc: https://github.com/dakk/bitcoinml
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-11/msg00071.html
Richard W. M. Jones announced:
Forwarding because it may be of interest to the OCaml developers.
Rich.
- - -
Date: Tue, 28 Nov 2017 09:23:55 +0000
From: David Chisnall <David.Chisnall@cl.cam.ac.uk>
To: RISC-V HW Dev <hw-dev@groups.riscv.org>, RISC-V SW Dev
<sw-dev@groups.riscv.org>, isa-dev@groups.riscv.org
Subject: [sw-dev] [ANN] RISC-V J Extension Working Group
Hello RISC-V Developers,
We are pleased to announce the formation of the J Extension Working
Group (charter attached), chaired by David Chisnall and with Martin
Maas as vice chair. This group will be responsible for proposing
RISC-V extensions for managed, interpreted and JIT-ed languages that
have extend beyond those of ahead-of-time compiled Algol-family
languages (such as C/C++).
The J working group solicits contributions from hardware implementors,
language designers, as well as experts on language-runtime systems,
interpreters, compilers, memory management and garbage
collection. Contributions in related areas such as dynamic binary
translation, memory consistency models and transactional memory are
strongly encouraged as well. If you wish to participate, please reply
to this email.
David Chisnall and Martin Maas
RISC-V J Extension Working Group Charter
----------------------------------------
The RISC-V J extension aims to make RISC-V an attractive target for
languages that are traditionally interpreted or JIT compiled, or which
require large runtime libraries or language-level virtual
machines. Examples include (but are not limited to) C#, Go, Haskell,
Java, JavaScript, OCaml, PHP, Python, R, Ruby, Scala or WebAssembly.
Typical features of these languages include garbage collection,
dynamic typing and dynamic dispatch, transparent boxing of primitive
values, and reflection. This provides a very wide scope for possible
approaches and, as such, the working group will follow a two-pronged
strategy investigating both immediate gains and longer-term more
experimental ideas concurrently. Existing attempts to implement
JIT-compiled languages on RISC-V have highlighted some places where
better instruction density is possible, and these should fall into an
early version of the specification.
Instructions intended to accelerate common JIT’d instruction sequences
may be optional within the J extension, with the expectation that
software will test for their presence before determining which code
sequence to generate. This also provides scope for additions that are
only appropriate for a subset of microarchitectures. For example,
there is increasing interest in running JavaScript on IoT devices, but
acceleration for simple low-power in-order pipelines with constrained
memory may be wholly inappropriate for large application cores.
Among other topics, the group expects to work within the following
areas and collaborate with several existing RISC-V extension working
groups:
- Dynamic languages often require efficient overflow-checked addition
for promotion between integer representations. The M standard
describes overflow-checking multiplication, and the J and M extension
work groups will work together to unify these.
- A significant amount of research has explored hardware support for
garbage collection (GC), including hardware read/write barriers and
using transactional memory for GC. The J extension group will consider
these options and work with a potential future T extension working
group to use transactional memory support for this purpose. It is
important that the J extension does not propose specialised
garbage-collection acceleration support when similar performance can
be achieved in software simply by using the T extension.
- The memory model working group is refining the core specification’s
atomicity and ordering guarantees. Environments containing JIT
compilers have stronger requirements with regard to ordering of data
writes to instruction reads than traditional ahead-of-time
environments (particularly on multicore systems). The J extension may
propose a stronger memory model in this regard, but must not propose
anything that contradicts the memory model working group’s design.
- User-level interrupts have significant potential for side-exits from
JIT-compiled code for deoptimisation, certain garbage collection
algorithms, and potentially other VM features. User-level interrupts
are currently defined in the privileged specification and may be
supported by a future N extension. The J working group must coordinate
designs with a potential future N working group to ensure that such
mechanisms are reusable.
The J working group solicits contributions from hardware implementors,
language designers, as well as experts on language-runtime systems,
interpreters, compilers, memory management and garbage
collection. Contributions in related areas such as dynamic binary
translation, memory consistency models and transactional memory are
strongly encouraged as well.
Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.
- Add Filename.quote_command function
https://github.com/ocaml/ocaml/pull/1492
Here are links from many OCaml blogs aggregated at OCaml Planet,
http://ocaml.org/community/planet/.
Software Engineer (Haskell, Full Stack) at Capital Match (Full-time)
https://functionaljobs.com/jobs/9053-software-engineer-haskell-full-stack-at-capital-match
Eighteenth OCaml compiler hacking evening at Pembroke, Cambridge
http://ocamllabs.github.com/compiler-hacking/2017/11/21/eighteenth-compiler-hacking-december
Migration to GitHub is complete
https://coq.inria.fr/news/140.html
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.