OCaml Weekly News
Hello
Here is the latest OCaml Weekly News, for the week of October 20 to 27, 2020.
Table of Contents
- Bisect_ppx, the coverage tool, now has excellent integration with Dune
- Js_of_ocaml in the VSCode OCaml Platform
- Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
- Set up OCaml 1.1.2
- Set up OCaml 1.1.3
- First release of FSML
- Qrc 0.1.0, a QR code encoder
- cumulus 0.0.1
- Brr 0.0.1, a toolkit for programming browsers
- Old CWN
Bisect_ppx, the coverage tool, now has excellent integration with Dune
Anton Bachin announced
Bisect_ppx, the coverage tool, has just had its 2.5.0 release, in which the main addition is a very neat integration with Dune:
dune runtest --instrument-with bisect_ppx --force
This uses the new instrumentation support added in Dune 2.7.0, and is a considerable improvement over the dubious methods Bisect and its users were previously forced to rely on :)
It is no longer necessary to edit dune
files for a release, as Bisect only becomes a dependency of
your project when --instrument-with bisect_ppx
is supplied on the Dune command line, which is only
during development and in CI. This makes projects ready for release from any commit. Dune also now
knows to rebuild affected files when instrumentation is turned on or off, so you don't have to manually
run dune clean
in between. Everything just works the way it should.
See the updated instructions for all the details on how to use this integration.
I've also adapted Lambda Soup as a simple full-project example. See its
opam
,
dune-project
,
dune
,
and
Makefile
.
Bisect_ppx still supports all the older integrations, so if you have an existing setup, you don't have to edit it. Support may eventually be removed in the future, however, so I encourage users to gradually update.
See the full changelog for information on bugs fixed by the release.
Thanks to the Dune team for adding --instrument-with
, to @undu for supporting it on the Bisect side,
and to all the Bisect_ppx users and contributors!
Happy testing!
Js_of_ocaml in the VSCode OCaml Platform
Max LANTAS announced
I just finished a write-up about vscode-ocaml-platform's recent transition to Js_of_ocaml: https://mnxn.github.io/blog/ocaml/vscode-jsoo/
I can answer any questions here.
This is also my first technical blog post, so any constructive criticism or comments about my writing would be very helpful.
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
Laurène Gibaud announced
At OCamlPro, we will be organizing 2 cross-company training sessions in French. Both sessions interleave theory and practice. You'll have time to ask your specific questions and get personalized feedback on your programs.
- Our Beginner session will allow developers to build upon their experience of other programming languages (such as C, C++, Python, C# or Java) to program confidently in OCaml. Feel free to share the info with your coworkers or your network!
- Our “Expert OCaml” training will allow you to master OCaml’s advanced features such as its type-system, OCaml’s open source tools and libraries, and how to write compact and efficient code.
More info on the program and prerequisites on http://www.ocamlpro.com/training-ocamlpro/ or ask away (answer this email or write at contact@ocamlpro.com).
When? The Beginner session is scheduled for November 23-24, 2020. The Expert session will be on November 25-26, 2020.
Where? Paris 14, in OCamlPro's office.
How? Register on: https://www.ocamlpro.com/pre-inscription-a-une-session-de-formation-inter-entreprises/
We can also organize custom and on-site sessions upon request.
Set up OCaml 1.1.2
Sora Morimoto announced
This release contains these changes:
- Add the Cygwin setup to a known location for later steps
- Check if the switch exists before creating the switch
Set up OCaml 1.1.3
Sora Morimoto announced
This release contains these changes:
- Update the
@actions/core
package to address CVE-2020-15228
First release of FSML
jserot announced
This is to announce the first public release of FSML, an OCaml library for describing and describing synchronous finite state machines.
FSML is a simplified version of the library provided in the Rfsm package for which
- the system is composed of a single FSM
- this FSM has a single, implicit, triggering event (typically called the clock , hence the term synchronous used in the description)
The FSML library provides
- a type
Fsm.t
for describing FSMs- possibly having local variables
- for which transitions , implicitely triggered by a clock, are defined by a set of boolean guards and a set of actions
- a set of PPX extensions for building values of type
Fsm.t
- functions for producing and viewing graphical representations of FSMs in the
.dot
format - functions for saving and reading FSM representations in files using the JSON format
- functions for performing single or multi-step simulations of FSMs and generating trace files in the
.vcd
format to be viewed by VCD viewers such as gtkwave - functions for generating C or VHDL code from a FSM representation (for integration into existing
code and/or simulation)
FSML is available from Github or as an OPAM package.
Qrc 0.1.0, a QR code encoder
Daniel Bünzli announced
QR codes are unsightly – a mirror of their specification. But they enable all sorts of neat tricks now that scanners for them are in many pockets.
Qrc generate them:
Qrc encodes your data into QR codes. It has built-in QR matrix renderers for SVG, ANSI terminal and text.
Qrc is distributed under the ISC license. It has no dependencies.
Homepage: https://erratique.ch/software/qrc
API docs: https://erratique.ch/software/qrc/doc/ or odig doc qrc
Install: opam install qrc
cumulus 0.0.1
Petter A. Urkedal announced
I would like to announce a new FRP library built on the React library. The purpose of cumulus is to help organize code which work on differential updates. The main type is the cumulus signal, which is analogous to a react signal, except that information about the difference from the previous value is provided to consumers along with the new value, when the cumulus signal changes.
So, why does a cumulus signal provide both the state and the difference to downstream signals? That is, what is the difference between the following:?
type t1 = state * change React.E (* initial value and even of changes *) type t2 = (state, change) Cumulus.t (* the cumulus signal *)
The former type presumes that after the consumer has received the initial state, it will only need to know what changes on successive updates. This seems quite natural. It works well if, for instance, we want to reconstruct a signal holding a set of strings, given an initial set and a series of additions and removals:
module String_set = Set.Make (String) type 'a set_patch = [`Add of string | `Remove of string] type 'a update = 'a -> 'a let patch_string_set : string set_patch -> String_set.t update = function | `Add x -> String_set.add x | `Remove x -> String_set.remove x let integrate_strings (init, changes) = React.E.fold (fun l p -> patch_string_set p l) init changes
But what if we want to maintain a signal holding the intersection of two sets of strings? If we try to lift the intersection operation to work on patches, we discover that learning about the addition of an element to left-hand set is not sufficient to determine whether the element shall the added to the resulting set; we also need to know whether the element is a member of the right-hand set. So, in this case we would instead use cumulus signals:
let cu : (String_set.t, string set_patch) Cumulus.t = ... let cv : (String_set.t, string set_patch) Cumulus.t = ... let cuv = let init u v = String_set.inter u v in let patch (u, du) (v, dv) r' = (match du, dv with | None, Some x when String_set.mem x u -> Cumulus.Patch (String_set.add x r', `Add1 x) ...) in Cumulus.l2 ~init ~patch cu cv
For the complete example, using integers instead of strings, see test_isecn.ml
from the
testsuite.
(Footnote: If consumers know how to integrate the states they depend on, they could in principle keep their own record of the full states of the arguments. But this would be inefficient if there are many consumers, and there is also a simplification of code and possibly improved abstraction in letting the producer maintain its own state.)
Formally, we can understand the difference between t1
and t2
in terms of calculus. For instance,
the differential of a product d(x·y) = dx·y + x·dy
contains a mix of both the differentials and
values of the two variables. But if the expression is linear, only differentials will will occur:
d(a·x + b·y + c) = a·dx + b·dy
. So, when t1
is sufficient, we are dealing with the analogue of a
linear function. The above example could be turned into a linear one by making Labels.t
a multiset
type and considering the multiset union operation.
Thus far we only considered purely functional code, but a cumulus signal may chose to modify and return
the same physical state during an update. Also note when designing the differential component of the
cumulus signal, that we may exploit the fact the consumers also may inspect the corresponding new
state. Combining these two points, a cumulus signal holding an array might have the type ('a array,
[`Set of int | `Resize of int])
. Here the state may be reused for `Set
and replaced for
`Resize
.
On a related not, there is also the reactiveData library which deals with (linear) patching of containers.
I must also mention that there there is an OCaml project with the same name (except casing). Sorry for not checking thoroughly in advance. I hope it is not an issue in practise, otherwise there is still time to rename while the library is fresh.
Brr 0.0.1, a toolkit for programming browsers
Continuing this thread, Yoann Padioleau asked Daniel Bünzli replied
What are the differences with the default bindings provided in js_of_ocaml to the browser APIs (e.g., js.mli, dom.mli, etc.)?
I'm not sure exactly what you are asking but:
- If you are asking about the way API are exposed:
brr
does not type JavaScript's objects as phantom types. It simply relies on OCaml's abstract data types and plain functions. More about this can be found in brr's FFI manual and FFI cookbook. - If you are asking about binding coverage, you should be able to get a sense of what is bound in
brr
here.
Regarding 2. brr
's coverage of more recent browser APIs is broader and more consistent than in
js_of_ocaml
– Promise support, Fetch, Service workers, Media capture APIs, WebGL2, Webcrypto,
WebAudio, etc. Conversly older APIs supported in js_of_ocaml
may not supported in brr
(e.g.
XMLHTTPRequest). Besides brr
's coverage of some of the DOM element-specific interfaces may be
shallower than in js_of_ocaml
. There is however good coverage for the
HTMLMediaElement
,
HTMLCanvasElement
,
HTMLFormElement
and
HTMLInputElement
interfaces. For
the rest the attribute and property
API and the occasional trivial
FFI method binding should be able to get you a long way.
Old CWN
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.