* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-09-03 7:35 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-09-03 7:35 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1966 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 27 to
September 03, 2019.
Table of Contents
─────────────────
Ocaml-multicore: report on a June 2018 development meeting in
Paris
Interesting OCaml Articles
Old CWN
Ocaml-multicore: report on a June 2018 development meeting in
Paris
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202/10>
Deep in this thread, sid announced
──────────────────────────────────
As a small step towards multicore, its interesting to note that
<https://github.com/ocaml/ocaml/pull/8713> just got merged to
master!
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/46>
Yotam Barnoy announced
──────────────────────
<https://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 12394 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-10-15 7:28 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-10-15 7:28 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 5627 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 08
to 15,
2019.
Table of Contents
─────────────────
capnp-rpc 0.4.0
Ocaml-protoc.plugin.1.0.0
Old CWN
capnp-rpc 0.4.0
═══════════════
Archive:
<https://discuss.ocaml.org/t/ann-capnp-rpc-0-4-0/4524/1>
Thomas Leonard announced
────────────────────────
I'm pleased to announce the release of [capnp-rpc 0.4.0], an
OCaml
implementation of the Cap'n Proto RPC specification.
If you haven't used the library before, please see the
[documentation
and tutorial]. Cap'n Proto RPC aims to provide secure,
efficient,
typed communications between multiple parties.
This library is now being used to build [ocaml-ci], where it is
used
for all communication between the web frontend and backend
services,
and to provide a command-line client.
[capnp-rpc 0.4.0]
<https://github.com/mirage/capnp-rpc/releases/tag/v0.4.0>
[documentation and tutorial]
<https://github.com/mirage/capnp-rpc/blob/master/README.md>
[ocaml-ci] <https://github.com/ocaml-ci/ocaml-ci>
Main changes since v0.3
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Breaking changes:
• Wrap errors with the ``Capnp' tag to make it easier to compose
with
other types of error.
• Prefix all command-line options with `capnp-'.
e.g. `--listen-address' is now `--capnp-listen-address'. The
old
names were confusing for applications that supported other
protocols
too (e.g. a web server).
New features:
• Add `Capability.with_ref' convenience function. This
automatically
calls `dec_ref' when done.
• Add Unix `Cap_file' module to load and save `Sturdy_refs'. In
particular, this ensures that saved cap files get a mode of
`0o600',
since they contain secrets.
• Export cmdliner network address parsing. This is useful if
you
don't want to use the default option parsing. For example, if
you
want to make Cap'n Proto an optional feature of your program.
• Upgrade from `uint' (which is deprecated) to the newer
`stdint'.
The latest version of `uint' is just a wrapper around
`stdint', so
this shouldn't break anything if you are using the latest
version.
• Put cmdliner options in their own man-page section. Use
`Capnp_rpc_unix.manpage_capnp_options' to control where in
your
man-page they appear.
• Enable `SO_KEEPALIVE' for TCP connections. For use with
Docker's
libnetwork, try something like this in your `stack.yml':
┌────
│ sysctls:
│ - 'net.ipv4.tcp_keepalive_time=60'
└────
Ocaml-protoc.plugin.1.0.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-1-0-0/4535/1>
Anders Fugmann announced
────────────────────────
I'm happy to announce the second release of
[ocaml-protoc-plugin].
Ocaml-protoc-plugin is a plugin to googles `protoc' compiler
which
generates type idiomatic to ocaml from `.proto' files including
full
compliant serialization and deserialization functions.
[ocaml-protoc-plugin]
<https://github.com/issuu/ocaml-protoc-plugin>
Most noteworthy changes in this release:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Full proto2 support.
• The list of dependencies has been slimmed way down, and now
only
depends on `conf-protoc' (the `protoc' compiler and googles
*well
known types*).
• Buckescript support.
• Added options to change the ocaml (type for scalar types (int,
int64
or int32).
Many thanks to Wojtek Czekalski for helping trimming
dependencies and
for Buclescript support.
Full changelog:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Support enum aliasing
• Avoid name clash with on 'name'
• Fix code generation when argument contains a path
• Refactor internal types to make serialization and
deserialization
type spec symmetrical.
• Optimize deserialization for messages with max_id < 1024
• Don't depend on Base in runtime
• Slim runtime dependencies: Remove need for base, ocplib-endian
and
ppx_let
• Honor [packed=…] flag.
• Make fixed scalar types default to int32 and int64
• Support proto2 specification
• Add options to switch between int64|int32 and int
• Fix name clash problem with special enum names
• Refactor serialization and deserialization to simplify emitted
code
• Eagerly evaluate serialization (for speed).
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 16446 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-05 6:55 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-11-05 6:55 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1700 bytes --]
Here is the latest OCaml Weekly News, for the week of October 29
to
November 05, 2019.
Table of Contents
─────────────────
vim-ocaml - new home
Old CWN
vim-ocaml - new home
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-vim-ocaml-new-home/4615/1>
Rudi Grinberg announced
───────────────────────
Dear Vim & Neovim users,
I would like to announce that I've officially moved the
[vim-ocaml]
repository under the control of the OCaml organization on
github. Please direct your bug reports and pull requests to this
repository. This move is done not because vim-ocaml is being
neglected, on the contrary, there's an active team of
maintainers that
recently expanded. I simply want to take this opportunity to
draw more
Vim & Noevim users to this project, as I suspect many users
aren't
aware of recent efforts.
[vim-ocaml] <https://github.com/ocaml/vim-ocaml>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 11877 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-12 13:21 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-11-12 13:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 2875 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 05
to 12,
2019.
Table of Contents
─────────────────
Mirage 3.7.1 released
Old CWN
Mirage 3.7.1 released
═════════════════════
Archive:
<https://discuss.ocaml.org/t/mirage-3-7-1-released/4634/1>
Hannes Mehnert announced
────────────────────────
MirageOS 3.7.1 is released to opam repository now.
Breaking change:
• The hooks previously defined in
OS.Main.at_enter/at_enter_iter/at_exit/at_exit_iter are now
part of
Mirage_runtime (only used by mirage-entropy)
<https://github.com/mirage/mirage/pull/1010>
Behaviour changes of MirageOS unikernels:
• A unikernel now always calls the Mirage_runtime.at_exit
registered
hooks – once a unikernel succesfully executed its `start' in
`Lwt_main.run', `exit 0' is called to ensure this behaviour
<https://github.com/mirage/mirage/pull/1011>
• Top-level exceptions are no longer caught (there used to be in
mirage-unix/mirage-xen/mirage-solo5 custom handlers). The
OCaml
runtime prints the exception and backtrace on stdout and calls
exit
2 (from 4.10.0, abort() will be called).
Deprecations (being removed from Mirage 4.0)
• All Mirage_YYY_lwt are deprecated, Mirage_YYY interfaces are
no
longer astracted over 'a io and buffer. This reduces the
amount of
opam packages - mirage-yyy-lwt are no longer part of the
release
(each mirage-yyy package provides a Mirage_yyy_lwt module for
backwards compatibility). Motivation was discussed in
<https://github.com/mirage/mirage/issues/1004>
• mirage-types and mirage-types-lwt are deprecated, please use
the
Mirage_YYY signatures directly instead.
Other observable changes
• `mirage configure' now deletes all exising opam files
Most reverse dependencies are already released to opam, have a
look at
<https://github.com/mirage/mirage/issues/1012> for progress (and
the
temporary <https://github.com/mirage/mirage-dev.git#easy> opam
overlay).
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 13405 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-26 8:33 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-11-26 8:33 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 28861 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 19
to 26,
2019.
Table of Contents
─────────────────
tiny_httpd 0.1
printbox.0.3
v0.13 release of Jane Street packages
opam2nix (v1)
GitHub Actions for OCaml / opam now available
OCurrent 0.1 (CI/CD pipeline eDSL)
New pages for OCaml API
Irmin 2.0.0 release
Tail cascade: a new indentation style for some OCaml constructs
Old CWN
tiny_httpd 0.1
══════════════
Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727/1>
Simon Cruanes announced
───────────────────────
Hello and good morning, I'm pleased to announce that
[tiny_httpd] 0.1
has been released and is on opam.
The goal is to emulate python's standard `http.server' by
providing a
0-dependencies, minimalist, simple HTTP server for embedding in
applications that are not primarily a website, with very basic
routing
(thanks to `Scanf'). A binary `http_of_dir' is also distributed
and
can be used to serve a directory, with optional upload of files.
[tiny_httpd] <https://github.com/c-cube/tiny_httpd>
printbox.0.3
════════════
Archive: <https://discuss.ocaml.org/t/ann-printbox-0-3/4731/1>
Simon Cruanes announced
───────────────────────
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/8/8e7c55c5ab69c12f53a7862d2f84dd6e0cfc0dc0.png>
┌────
│ let b =
│ let open PrintBox in
│ PrintBox_unicode.setup();
│ frame @@ grid_l [
│ [text "subject"; text_with_style Style.bold "announce:
printbox 0.3"];
│ [text "explanation";
│ frame @@ text {|PrintBox is a library for rendering nested
tables,
│ trees, and similar structures in monospace text or
HTML.|}];
│ [text "github";
│ text_with_style Style.(bg_color Blue)
"https://github.com/c-cube/printbox/releases/tag/0.3"];
│ [text "contributors";
│ vlist_map (text_with_style Style.(fg_color Green))
["Simon"; "Guillaume"; "Matt"]];
│ [text "dependencies";
│ tree empty
│ [tree (text "mandatory")
│ [text "dune"; text "bytes"];
│ tree (text "optional")
│ [text "uutf"; text "uucp"; text "tyxml"]]];
│ [text "expected reaction"; text "🎉"];
│ ]
│
│ let () = print_endline @@ PrintBox_text.to_string b
└────
([actual link to the release])
[actual link to the release]
<https://github.com/c-cube/printbox/releases/tag/0.3>
v0.13 release of Jane Street packages
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735/1>
Xavier Clerc announced
──────────────────────
We are pleased to announce the v0.13 release of Jane Street
packages!
This release comes with 14 new packages, and a number of fixes
and
enhancements. The documentation for this release is available on
our
website:
<https://ocaml.janestreet.com/ocaml-core/v0.13/doc/>
The remainder of this mail highlights the main changes since the
v0.12
release; we hope it will be useful to developers in the process
of
migrating to the new version. A comprehensive changelog is
available
at the end.
Notable changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Changed `Base', `Core_kernel', and `Core' functions to raise
`Not_found_s' instead of `Not_found'. `Hashtbl.find_exn' and
`Map.find_exn' now include the key in their error message.
• Changed `Core' and `Core_kernel' to export `int' comparison
rather
than polymorphic comparison.
• Removed the "robust" float comparison operators (`>.', `=.',
…)
from the default namespace.
• Replaced `sexp_*' types (`sexp_list', `sexp_option',
`sexp_opaque',
…) with preprocessor attributes (`[@sexp.list]',
`[@sexp.option]',
`[@sexp.opaque]', …).
• Changed `let%map' syntax from `let%map.Foo.Let_syntax' to
`let%map.Foo'.
• Added to `match%optional' support for specifying a path, so
you can
write `match%optional.Foo foo_option' rather than `let open
Foo.Optional_syntax in match%optional foo_option'.
• Improved `Base.Backtrace' so that it enables recording of
backtraces
in more situations, specifically when `OCAMLRUNPARAM' is
defined but
doesn't mention the backtrace flag, `b'.
• Added javascript support for `Zarith', `Bigint', `Bignum', and
`Bigdecimal'.
• Changed `Hashtbl.create''s default `size' from 128 to 0.
• Changed `Core_kernel.Command' so that all commands accept
double
dash flags: `--help', `--version', and `--build-info'.
New packages
╌╌╌╌╌╌╌╌╌╌╌╌
• async_udp (<https://github.com/janestreet/async_udp>): UDP
support
for Async.
• async_websocket
(<https://github.com/janestreet/async_websocket>): A
library that implements the websocket protocol on top of
Async.
• bonsai (<https://github.com/janestreet/bonsai>): A library for
building dynamic webapps, using Js_of_ocaml.
• postgres_async
(<https://github.com/janestreet/postgres_async>):
OCaml/async implementation of the postgres protocol (i.e.,
does not
use C-bindings to libpq).
• ppx_cold (<https://github.com/janestreet/ppx_cold>): Expands
`[@cold]' into `[@inline never][@specialise never][@local
never]'.
• ppx_pattern_bind
(<https://github.com/janestreet/ppx_pattern_bind>):
A ppx for writing fast incremental bind nodes in a pattern
match.
• ppx_python (<https://github.com/janestreet/ppx_python>):
`[@@deriving]' plugin to generate Python conversion functions.
• ppx_yojson_conv
(<https://github.com/janestreet/ppx_yojson_conv>):
`[@@deriving]' plugin to generate Yojson conversion functions.
• ppx_yojson_conv_lib
(<https://github.com/janestreet/ppx_yojson_conv_lib>): Runtime
lib
for `ppx_yojson_conv'.
• pythonlib (<https://github.com/janestreet/pythonlib>): A
library to
help writing wrappers around OCaml code for python.
• sexp_select (<https://github.com/janestreet/sexp_select>): A
library
to use CSS-style selectors to traverse sexp trees.
• timezone (<https://github.com/janestreet/timezone>): Time-zone
handling.
• toplevel_backend
(<https://github.com/janestreet/toplevel_backend>):
Shared backend for setting up toplevels.
• zarith_stubs_js
(<https://github.com/janestreet/zarith_stubs_js>):
Javascript stubs for the Zarith library.
Deprecations / Removals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`Async_kernel':
• Deprecated monadic `ignore' functions in favor of `ignore_m'.
`Base':
• Deleted `Array.replace' and `replace_all' functions, which
have been
deprecated since before the last public release.
• Deprecated `Result.ok_unit'; use `Ok ()'.
• Removed the `Monad' and `Applicative' interfaces' `all_ignore'
function; it was previously deprecated and replaced by
`all_unit'.
• Removed `List.dedup', which has been deprecated since 2017-04.
• Removed `String' mutation functions, which have been
deprecated in
favor of `Bytes' since 2017-10.
• Deprecated `Array.truncate', `Obj_array.unsafe_truncate', and
`Uniform_array.unsafe_truncate'.
• Deprecated `Sys.argv', which has been superseded by
`get_argv',
which is a function, reflecting the fact that `argv' can
change (as
of OCaml 4.09).
`Core_kernel':
• Removed `Core_kernel.Std', which had been deprecated for a
year.
• Deprecated type `Command.Spec.param' in favor of
`Command.Param.t'.
• Removed `Hashtbl' functions that had been deprecated for
years.
• Removed `Float.to_string_round_trippable', which has been
deprecated
in favor of `to_string' since 2017-04.
• Deprecated `Fqueue' functions where one should use `Fdeque'
instead:
`bot', `bot_exn', and `enqueue_top'.
• Deleted `Bus.unsubscribes', which will be obviated by a
performance
improvement to `Bus.unsubscribe'.
`Timing_wheel':
• Removed the `alarm_upper_bound' function, which has been
deprecated
for 6 months, and superseded by `max_allowed_alarm_time'.
Moves
╌╌╌╌╌
`Core_kernel':
• Moved `Bounded_int_table' to a standalone library.
• Moved the `Pool' and `Tuple_type' modules to a standalone
library,
`Tuple_pool'.
`Async_unix':
• Moved `Unix.Fd.replace' into a `Private' submodule.
Changelog
╌╌╌╌╌╌╌╌╌
Please visit
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>
opam2nix (v1)
═════════════
Archive: <https://discuss.ocaml.org/t/ann-opam2nix-v1/4741/1>
Tim Cuthbertson announced
─────────────────────────
Anouncing opam2nix (v1)
[opam2nix] generates [nix] expressions from the [opam] OCaml
package
repository. It works similarly to [bundix], [node2nix], etc:
You run an (impure) command to resolve all transitive dependency
versions using the current opam repository, generating a .nix
file
that locks down the exact package sources and versions. Then
this file
can be imported to provide `buildInputs' for building your ocaml
project in nix.
*What is nix and why would I care?* Well, that's a long story
but the
headline benefits of nix are:
• reproducible builds (if it builds for me, it builds for you)
• stateless (you don't set up switches and then install
packages, each
expression specifies everything it needs, and anything you
don't
have is fetched/built on demand)
• language agnostic (takes care of non-ocaml dependencies)
It's sadly not a shallow learning curve, but those benefits are
hard
to find elsewhere, so I obviously think it's worthwhile. So if
you use
nix (or would like to), please give it a try and provide
feedback. I'll (slowly) start working on upstreaming it into
nixpkgs.
[opam2nix] <https://github.com/timbertson/opam2nix>
[nix] <https://nixos.org/>
[opam] <https://opam.ocaml.org/>
[bundix] <https://github.com/nix-community/bundix>
[node2nix] <https://github.com/svanderburg/node2nix>
GitHub Actions for OCaml / opam now available
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745/1>
Anil Madhavapeddy announced
───────────────────────────
I was in the [GitHub Actions] beta program and forward ported my
code
to the latest version that just went public. It's a pretty
simple way
to get your OCaml code tested on Linux, macOS and Windows,
without
requiring an external CI service. The action attempts to
provide a
homogenous interface across all three operating systems, so
invoking
'opam' from subsequent actions should "just work".
You can find it here:
• In the GitHub Marketplace at
<https://github.com/marketplace/actions/setup-ocaml>
• Source code on <https://github.com/avsm/setup-ocaml/>
• Hello World usage on
<https://github.com/avsm/hello-world-action-ocaml>
• Usage in ocaml-yaml:
•
<https://github.com/avsm/ocaml-yaml/blob/master/.github/workflows/test.yml>
• An [example ocaml-yaml run]
This should be considered fairly experimental as GH Actions is
so new.
If you do use it, then consider [updating this issue with your
usage].
It does not current supporting caching yet, but is pretty fast
to
bootstrap (~4minutes).
It also doesn't have any higher level purpose other than to set
up an
opam environment, since most of the additional functionality
such as
revdeps testing is planned for addition to the [ocurrent DSL].
Nevertheless, this GH feature will hopefully be useful for
smaller
projects without a lot of computational requirements. Let me
know how
it goes!
Windows is currently supported through @fdopen's excellent fork
that
uses Cygwin. As Windows support is being mainlined into opam
itself
at the moment, I'm hoping that we will gradually move over to
that.
That should eventually remove the need for two separate
opam-repositories, so I won't be adding any features that are
Linux or
macOS-specific and do not work on the Cygwin version.
[GitHub Actions] <https://github.com/actions>
[example ocaml-yaml run]
<https://github.com/avsm/ocaml-yaml/runs/314055554>
[updating this issue with your usage]
<https://github.com/avsm/setup-ocaml/issues/4>
[ocurrent DSL]
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/2>
OCurrent 0.1 (CI/CD pipeline eDSL)
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/1>
Thomas Leonard announced
────────────────────────
[OCurrent] 0.1 has just been released to opam-repository.
OCurrent is an OCaml eDSL intended for writing build/test/deploy
pipelines. It is being used as the engine for [ocaml-ci] and the
[docker-base-images] builder (used to build the OCaml Docker
images,
such as `ocurrent/opam:alpine-3.10-ocaml-4.08'). Other good uses
might
be building and redeploying a Docker service or a unikernel
whenever
its source repository changes. It can be run locally as a single
Unix
process.
An OCurrent pipeline is written as an OCaml program, but the
OCurrent
engine ensures that it is kept up-to-date by re-running stages
when
their inputs change. A web UI is available so you can view your
pipeline and see its current state.
OCurrent can statically analyse the pipelines before they have
run,
allowing it to run steps in parallel automatically and to
display the
whole pipeline. It does this using a light-weight alternative to
arrows, which doesn't require programming in an awkward
point-free
style. See [CI/CD Pipelines: Monad, Arrow or Dart?] for more
about
that.
The basic functionality can be extended using "plugins" (just
normal
OCaml libraries). Plugins are available for interacting with
Docker,
Git, GitHub and Slack. These are in separate packages
(e.g. `current_github') to avoid having the base package pull in
too
many dependencies).
There is also an optional Cap'n Proto RPC interface, in the
`current_rpc' opam package. This is used, for example, by
[citty] to
provide a TTY interface to ocaml-ci.
[The OCurrent wiki] contains examples, and documentation on the
various plugins.
Here's an example pipeline (from the base image builder):
<https://roscidus.com/blog/images/cicd/docker-base-images-thumb.png>
[OCurrent] <https://github.com/ocurrent/ocurrent>
[ocaml-ci] <https://github.com/ocurrent/ocaml-ci/>
[docker-base-images]
<https://github.com/ocurrent/docker-base-images>
[CI/CD Pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
[citty] <https://github.com/ocurrent/citty>
[The OCurrent wiki] <https://github.com/ocurrent/ocurrent/wiki>
Anil Madhavapeddy then added
────────────────────────────
For those curious about the relation to the existing CI used in
opam-repository, then it is no coincidence that @talex5 is the
author
of both :-)
This DSL is the next iteration of the [datakit-ci], but
specialised to
be faster and simpler for extending with OCaml and more complex
workflows that our OCaml Platform tools need these days (like
ocamlformat linting, or dune expect promotion, or odoc
cross-referenced doc generation). We are planning a smooth
migration
next year over to the new system, but wanted to release this
early to
show you some of the pieces going into this new iteration. I am
particularly excited about the new tty-based interface that
saves an
awful lot of clicking around on web UIs for CI results…
[datakit-ci] <https://github.com/moby/datakit>
New pages for OCaml API
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/new-pages-for-ocaml-api/4720/13>
Continuing this thread, sanette announced
─────────────────────────────────────────
I have uploaded a new version (same link
<https://sanette.github.io/ocaml-api/>)
• background color for links in the TOC @Maelan
• more indentation for value descriptions @Maelan, @grayswandyr
• word wrapping long `<pre>' codes @grayswandyr
• type table: remove `(*' and `*)', give more space to code wrt
comments, diminish comment's color @grayswandyr
searching is not ready yet… please wait suggestions for dark
theme
welcome
sanette later added
───────────────────
I have just uploaded a new version with a basic search engine.
• for each page, you can search values/modules
• in the general index page, the search includes also the
descriptions
• search results are ranked by relevance
the downside is that each page now comes with an index of about
570Kb
in the form of an index.js file. I'm kind of hoping that the
browser
will cache this, but I'm not sure. It would be maybe better to
only
load the index file on demand.
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/1>
Thomas Gazagnaire announced
───────────────────────────
On behalf of the Irmin development team, I am very happy to
announce
the release of Irmin 2.0.0, a major release of the Git-like
distributed branching and storage substrate that underpins
[MirageOS]. We began the release process for all the components
that
make up Irmin [back in May 2019], and there have been close to
1000
commits since Irmin 1.4.0 released back in June 2018. To
celebrate
this milestone, we have a new logo and opened a dedicated
website:
[irmin.org].
More details here:
<https://tarides.com/blog/2019-11-21-irmin-v2>
[MirageOS] <https://mirage.io/>
[back in May 2019]
<https://tarides.com/blog/2019-05-13-on-the-road-to-irmin-v2>
[irmin.org] <https://irmin.org/>
Tail cascade: a new indentation style for some OCaml constructs
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tail-cascade-a-new-indentation-style-for-some-ocaml-constructs/4736/1>
gasche announced
────────────────
I recently decided to change my indentation style for certain
OCaml
constructs in a way that I'm going to describe below. I just
coined a
name for this approach, "tail cascade". I'm creating this topic
to
convince everyone that this is a cool idea you should adopt as
well. Or at least tolerate it when you review other people's
code.
Problem
╌╌╌╌╌╌╌
Programs that heavily use `match' often see a shift to the right
due
to nested indentation.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | Some z ->
│ ...
└────
Another problem with this style is that it suffers from the
"dangling
bar" issue: if you try to add a new case for one of the exterior
`match', it is parsed as belonging to the innermost `match'.
People
have been recommending (rightly) to use `begin match .. end' for
all
nested match constructs to avoid this issue.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ begin match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ begin match f y with
│ | None -> ...
│ | Some z ->
│ ...
│ end
│ (* now this is safe *)
│ | FooBlah -> ...
│ end
└────
But still the unpleasant shift to the right remains.
Proposal: cascading tail case
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We should in general use `begin match .. end' for nested
matches. But
the "cascading tail case" proposal is to *not* do it for the
*last*
case of the pattern-matching, and instead *de-indent* (dedent)
this
last case – tail case.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | None -> ...
│ | Some z ->
│ ...
└────
Note that with this indentation style, the "dangling match"
problem is
also avoided: unlike with the original, non `end'-protected
program,
the indentation makes it immediately obvious that any further
case
will be attached to the innermost match, and not any of the
exterior
ones.
A program using this "cascading tail" approach should always use
`begin match .. end' for nested matches, except for a nested
match
returned within the last branch of an outer match, which can
(optionally) be dedented instead.
The choice to dedent the last case corresponds to encouraging a
sequential reading of the program, where the other cases are
"auxiliary cases" checked first and dispatched quickly, and the
last
case is the "main part" where the "rest" of the logic of the
program
lies. This pattern is typical of nested pattern-matching on the
`option' or `result' type for example:
┌────
│ match foo x with
│ | Error err ->
│ fail_foo_error err
│ | Ok y ->
│ match bar y with
│ | Error err ->
│ fail_bar_error err
│ | Ok () ->
│ ...
└────
Remark: it is *not* always the case that the `Error' constructor
is
the auxiliary case, and the `Ok' constructor is the main case;
sometimes we implement fallback logic like "if `foo' work then
we are
good, but otherwise we have to do this and that", and the error
case
is the most salient (and longer) part of the program logic. I
would
recommend being mindful, when you write code, of whether there
is a
most convincing way to "sequentialize" it (distinguish auxiliary
and
main/tail case), and avoid using cascading tails when there is
no
clear sequentialization choice.
Remark: some cases of tail cascades can be linearized by using a
good
definition of "bind" and a monadic style. This tends to be very
limited however: it fixes one of the constructors to always be
the
"tail" constructor (always `Some', always `Ok'), and it only
works
when the handling of the other constructors is very homogeneous
(typically: return directly). In real code, many situations
occur
where the monadic style doesn't fit the problem, but tail
cascade does
help writing a readable program.
Generalization: tail cascade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While I have never seen cascading tail cases in real-world OCaml
code
before (I'm happy to be given pointers; I think that the idea is
not
new, but I'm not aware of previous attempts to give it a catchy
name
and spread the cascade love), this is in fact a new (to me)
instance
of a common technique that is used for other OCaml constructs:
┌────
│ if foo x then ...
│ else if bar x then ...
│ else ... (* this `tail else` was dedented *)
│
│ let x = foo in
│ let y = bar in (* this `tail let` was dedented *)
│ ... (* and the rest as well *)
│
│ bind foo @@ fun x ->
│ bind bar @@ fun y -> (* this "tail function body" was dedented
*)
│ ... (* and the rest as well *)
└────
I would call "tail cascade" (or maybe: "cascading tail") the
idea of
dedenting the "rest" of an OCaml expression (compared to a
strict
tree-nesting-based approach) when it morally describes the
"rest" of
the expression. I use the name "tail" because those expressions
are
almost always in tail-position in the sense of tail-calls.
This general approach legitimizes some styles that I have seen,
and
sometimes used, in the wild, while at the same time considering
that I
may have been doing something improper, for example:
┌────
│ if foo then blah else
│ ... (* dedented *)
│
│
│ Fun.protect
│ ~finally:(...)
│ @@ fun () ->
│ ... (* dedented *)
│
│
│ try simple_approach with exn ->
│ ... (* dedented *)
│
│
│ 1 +
│ 2 + (* dedented *)
│ ... (* dedented *)
└────
Remark: after a `then' or `else', many people share the
reasonable
view that any expression containing imperative constructs (`foo;
bar')
should be enclosed in a `begin .. end' block to avoid
surprising-precedence issue. Just as for nested `match', this
recommendation should be lifted for "tail else" constructs.
Remark: The last example is a case where the dedented
expressions are
*not* in tail-position from a runtime-evaluation point of view.
I am
not sure as whether the two notions should be made to coincide
more
strongly, but in any case I'm not fond of the style in this
particular
example, I prefer to move the infix operator to the beginning of
the
next line instead, following a different style and
justification.
The possibility this "cascading tail" style today crucially
relies on
the nesting properties of open-ended syntactic constructs,
notably
`let' (commonly cascaded), and now `match' and `if
... else'. Proposals to transition to a syntax where `match' and
`else' are forced to take a closing marker are incompatible with
the
cascading style. I have not made my mind on whether this should
be
considered a blocker for those proposals, but at least it shows
that
having the open-ended form available has value for certain
programs.
Louis Gesbert then said
───────────────────────
@gasche I prototyped a dedicated option in `ocp-indent', if
you're
interested in trying it out :)
┌────
│ opam pin
git+https://github.com/OCamlPro/ocp-indent#match-tail-cascade
│ echo "match_tail_cascade=true" >> ~/.ocp-indent
└────
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 50844 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-03 15:43 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-12-03 15:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 22620 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 26
to
December 03, 2019.
Table of Contents
─────────────────
Irmin 2.0.0 release
How viable is delivering binaries linked to Cygwin to Windows
customers?
Dune 2.0.0
Advanced C binding using ocaml-ctypes and dune
Upcoming breaking change in Base/Core v0.14
CI/CD Pipelines: Monad, Arrow or Dart?
Use of functors to approximate F# statically resolved type
parameters
Old CWN
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/5>
Continuing this thread, samoht announced
────────────────────────────────────────
And there is now a follow-up blog post, explaining how to use
the new
GraphQL API available in Irmin2:
<https://tarides.com/blog/2019-11-27-introducing-irmin-graphql>.
How viable is delivering binaries linked to Cygwin to Windows
customers?
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-viable-is-delivering-binaries-linked-to-cygwin-to-windows-customers/4775>
mbacarella asked
────────────────
I’m in the early stages of planning a deliverable binary product
that
will run on Linux, Mac and Windows.
My brief sniff of the air around the OCaml ecosystem says I
should
expect to target Cygwin to get Windows going (although there’s
impressive work to get native Windows stuff done that can become
the
preferred approach in a few years).
My experience using Cygwin as an operating environment is that
it’s
pretty darn sluggish compared to Linux on the same computer.
Why is this? There’s an anecdote that says Cygwin can only fork
at
about 30-50x a second on Windows, due to how it has to adapt it
to
work within Windows’ task spawning model. (For contrast, Linux
can
achieve thousands of forks per second if you play around with
it).
I understand from another product developer that when they build
binaries to deliver to Windows/Cygwin, they actually
cross-compile on
Linux because of how slowly the toolchain runs on Cygwin.
That sounds like bad news if you want to do UNIXy things, but
for a
single standalone application this might not be so bad? I assume
if I
ship a deliverable to Windows/Cygwin, the end user may enjoy
good
performance, so long as I’m not spawning tons of processes or
relying
on fork for multi-programming. Is this a safe assumptions?
Any other gotchas when it comes to OCaml on Cygwin w.r.t.
performance?
The app pretty much has real-time gaming requirements (though
it’s not
a game so can side-step worrying about access to GPUs and
what-not). Stated another way, although my application will
depend on
the POSIX layer offered by Cygwin, I expect it not to crunch
POSIX
related stuff in the main loop.
How has your experience gone?
John Whitington replied
───────────────────────
I have been shipping commercial binaries for Linux (32 and 64
bit),
Windows (32 and 64bit) and OS X for years. For example:
<https://github.com/coherentgraphics/cpdf-binaries>
And even static or shared libraries in binary form:
<https://github.com/coherentgraphics/cpdflib-binary>
On OS X, you need to use MACOSX_DEPLOYMENT_TARGET or similar to
make
sure your builds will run on older systems. And, in fact, you
need to
use MACOSX_DEPLOYMENT_TARGET when asking OPAM to compile the
OCaml
compiler itself. And, you will need to deal with codesigning and
notarization. But it’s all doable.
For linux, you may need to build under older linux versions, to
make
sure that the glibc in use is old enough. This is not an
ocaml-specific problem. I have a 64 bit and 32 bit VM with
old-ish
glibc versions for this purpose.
Under Windows, there are no such backward-compatibility
problems. I
use the new OCaml for windows system, which comes with OPAM, and
is
mingw-based. No cygwin remains in the final binary.
For more obscure systems (AIX, HPUX, Sparc etc) customers
compile from
source (with help from me). Not once in more than ten years has
anyone
cared that it was written in OCaml.
dbuenzli also replied
─────────────────────
remember that on the Windows native port, the Unix module
distributed
with OCaml is your POSIX compatibility layer. There are a few
entry
points to avoid though, the list is at the bottom of [this
page].
[this page]
<https://caml.inria.fr/pub/docs/manual-ocaml/libunix.html>
nojb also replied
─────────────────
At LexiFi our main application is developed and shipped on
Windows. We
use the msvc port of OCaml. This means that you need Cygwin to
develop, but the resulting application is fully native and does
not
depend on the Cygwin DLL. As @dbuenzli mentioned, the Unix
module *is*
the POSIX compatibility layer.
Compilation speed is slower on Windows because process creation
is
slower on Windows as a general rule, but it is manageable (our
application has around 2000 modules + Js_of_ocaml + C bindings +
C#
component).
We don’t have any issues with runtime performance. The `Unix'
library
mentioned above implements Windows support directly without
going
through any compatibility layer and is quite efficient.
BikalGurung also replied
────────────────────────
There is an editor being built in ocaml/reasonml which currently
targets windows, linux and macos -
<https://github.com/onivim/oni2>. However, the binary is native
windows rather than cygwin derivative. So if you don’t have to
use
cygwin dependencies then native windows binary could be the way
to go.
Also esy - <https://github.com/esy/esy> makes developing
ocaml/reasonml on windows viable.
keleshev also replied
─────────────────────
*TLDR*: Install the [Mingw port of OCaml 4], freely use most
opam
libraries, and compile to native Windows binaries, without
licensing
issues.
I recommend you read the “Release notes for Windows”:
<https://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc>
To summarise, there are three Windows ports:
• Native Microsoft port,
• Native Mingw port,
• Cygwin port.
All three require Cygwin for development purposes. I recommend
using
the Native Mingw, as:
• it *doesn’t* require Visual Studio (it uses a mingw fork of
GCC that
“cross-compiles” native Windows executables),
• it *doesn’t* rely on the dreaded cygwin.dll
• it has good opam support with opam-repository-mingw:
<https://github.com/fdopen/opam-repository-mingw>
• it has a convenient installer:
<https://fdopen.github.io/opam-repository-mingw/> 5.
To contrast, Native Microsoft requires Visual Studio, and
doesn’t have
opam. You can still vendor pure OCaml packages, but as soon as
you
want to use some C bindings you’re in trouble, because of the
“minor”
differences between Visual C and GCC. And everything assumes GCC
nowadays.
Cygwin port is the one I don’t have experience with, but
re-reading
the “Release notes for Windows” above it strikes me that it
mentions
that Cygwin was re-licensed from GPL to LGPL with static linking
exception. So it looks like the Cygwin port could be viable for
commercial use, but I never tried to statically linked
`cygwin.dll',
and I’m not sure what are the benefits of Cygwin port over the
Mingw
port.
[Mingw port of OCaml 4]
<https://fdopen.github.io/opam-repository-mingw/>
dmbaturin also replied
──────────────────────
With [soupault 4], I decided to ship prebuilt binaries for all
platforms including Windows. Mostly to see if I can, all its
users I
know of are on UNIX-like systems and know how to build from
source,
but that’s beside the point. :wink:
I can confirm everything @keleshev says: fdopen’s package just
works,
opam works exactly like it does on UNIX, pure OCaml libraries
are
trivial to install, and the binaries don’t depend on cygwin.
Note
that “opam switch create” also just works, you can install
either
MinGW or MSVC compiler versions as opam switches. I only ever
start
the Windows VM to make release builds, and the workflow is
exactly the
same as on Linux where I’m actually writing code.
My only obstacle on that path was that FileUtils lost its
Windows
compatibility, but I wanted to use it, so I worked with
@gildor478 to
make it cross-platform again. Uncovered a bug in the
implementation of
Unix.utimes in the process, but it’s hardly a commonly used
function.
You can also setup AppVeyor builds. It’s not as simple as I wish
it
would be, but there are projects doing it that you can steal the
setup
from.
There’s also opam-cross-windows, but it’s very incomplete and
needs
work to be practical. There are no big obstacles, it just needs
work. While files in opam-repository-mingw are normally
identical to
the default opam repository, the cross one needs small
adjustments in
every package to specify the toolchain to use, so the required
work is
mostly a lot of trivial but manual actions. I hope eventually it
reaches parity with fdopen’s one and we’ll be able to easily
build for
Windows without ever touching Windows.
As of static Linux builds, @JohnWhitington’s approach can work,
but
there’s a better option if you don’t need anything from glibc
specifically and don’t link against any C libs: build statically
with
musl. There’s a `+musl+static+flambda' compiler flavour. You
need musl
and gcc-musl to install it, but after that, just build with
`-ccopt
-static' flag and you get a binary that doesn’t depend on
anything.
[soupault 4] <https://soupault.neocities.org/>
Dune 2.0.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
rgrinberg announced
───────────────────
On behalf of the dune team, I’m delighted to announce the
release of
dune 2.0. This release is the culmination of 4 months of hard
work by
the dune team and contains new features, bug fixes, and
performance
improvements . Here’s a selection of new features that I
personally
find interesting:
• New boostrap procedure that works in low memory environments
• (`deprecated_library_name' ..) stanza to properly deprecate
old
library names
• (`foreign_library' ..) stanza to define C/C++ libraries.
• C stubs directly in OCaml executables
Refer to the change log for an exhaustive list.
We strive for a good out of the box experience that requires no
configuration, so we’ve also tweaked a few defaults. In
particular, `$
dune build' will now build `@all' instead of `@install', and
ocamlformat rules are setup by default.
Lastly, dune 2.0 sheds all the legacy related to jbuilder and
will no
longer build jbuilder projects. This change is necessary to ease
maintenance and make it easier to add new features down the
line. There are a few other minor breaking changes. Refer to the
change log for the full list. We apologize in advance for any
convenience this might cause.
[Changelog]
[Changelog] <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
Advanced C binding using ocaml-ctypes and dune
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/advanced-c-binding-using-ocaml-ctypes-and-dune/4805>
toots announced
───────────────
I worked on a socket.h binding last summer and had a great
experience
integrating ocaml-ctypes with dune, I thought that might be of
interest to other developers so I wrote about it:
<https://medium.com/@romain.beauxis/advanced-c-binding-using-ocaml-ctypes-and-dune-cc3f4cbab302>
rgrinberg replied
─────────────────
This is a good article. I encourage anyone who writes C bindings
with
ctypes to study it carefully.
A little bit of advice to shorten your dune files:
┌────
│ (deps (:gen ./gen_constants_c.exe))
└────
This line isn’t necessary. Dune is smart enough to know that
running a
binary in a rule incurs a dependency on it.
dune has a truly amazing [support for cross-compiling],
which we do not cover here, but, unfortunately, its
primitives for building and executing binaries do not yet
cover this use case.
Indeed, we don’t have any primitives for running binaries on the
target platform. Perhaps we should add some. However, we do in
fact
have some features in dune to solve this concrete cross
compilation
problem. As far as I understand, the goal is to obtain some
compile
time values such as #define constants and field offsets for the
target
platform. This does not in fact require to run anything on the
cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end result is
that
these configurator scripts are completely compatible with cross
compilation.
Perhaps this could be generalized to work with ctypes generators
as
well?
Funny bit of trivia: The hack in configurator required to do
this is
in fact something I extracted from ctypes itself. The original
author
is [whitequark], who in turn wrote it to make ctypes itself
amendable
to cross compilation.
[support for cross-compiling]
<https://dune.readthedocs.io/en/latest/cross-compilation.html>
[whitequark] <https://github.com/whitequark>
emillon then added
──────────────────
This does not in fact require to run anything on the cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end
result is that these configurator scripts are completely
compatible with cross compilation.
If anybody wants to know more about this bit, I wrote an article
about
this last year:
<https://dune.build/blog/configurator-constants/>
Upcoming breaking change in Base/Core v0.14
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upcoming-breaking-change-in-base-core-v0-14/4806>
bcc32 announced
───────────────
We’re changing functions in Base that used to use the
polymorphic
variant type `[ `Fst of 'a | `Snd of 'b ]' to use `('a, 'b)
Either.t'
instead. As well as enabling the use of all of the functions in
the
Either module, this makes the functions consistent with other
functions that already use `Either.t', (currently just
`Set.symmetric_diff')
The following functions’ types will change:
• `Result.ok_fst'
• `List.partition_map'
• `Map.partition_map', `Map.partition_mapi'
• `Hashtbl.partition_map', `Hashtbl.partition_mapi'
The type of List.partition3_map will not change:
┌────
│ val partition3_map
│ : 'a t
│ -> f:('a -> [ `Fst of 'b | `Snd of 'c | `Trd of 'd ])
│ -> 'b t * 'c t * 'd t
└────
We don’t have a generic ternary variant, and it doesn’t seem
worth it
to mint one just for this purpose.
Since this change is pretty straightforward, we expect that a
simple
find/replace will be sufficient to update any affected call
sites.
CI/CD Pipelines: Monad, Arrow or Dart?
══════════════════════════════════════
Archive:
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Thomas Leonard announced
────────────────────────
In this post I describe three approaches to building a language
for
writing CI/CD pipelines. My first attempt used a monad, but this
prevented static analysis of the pipelines. I then tried using
an
arrow, but found the syntax very difficult to use. Finally, I
ended up
using a light-weight alternative to arrows that I will refer to
here
as a dart (I don’t know if this has a name already). This allows
for
static analysis like an arrow, but has a syntax even simpler
than a
monad.
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Use of functors to approximate F# statically resolved type
parameters
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/use-of-functors-to-approximate-f-statically-resolved-type-parameters/4782>
cmxa asked
──────────
I am learning OCaml coming from F#. In F#, to calculate the
average of
an array whose element type supports addition and division, one
can
write
┌────
│ let inline average (arr: 'a[]) : 'a
│ when ^a : (static member DivideByInt : ^a * int -> ^a)
│ and ^a : (static member (+) : ^a * ^a -> ^a)
│ and ^a : (static member Zero : ^a)
│ =
│ if Array.length arr = 0 then
(LanguagePrimitives.GenericZero) else
│ LanguagePrimitives.DivideByInt (Array.fold (+)
(LanguagePrimitives.GenericZero) arr) (Array.length arr)
└────
My understanding is that in OCaml, one would have a module type
like
so:
┌────
│ module type Averagable = sig
│ type 'a t
│
│ val divide_by_int : 'a -> int -> 'a
│ val plus : 'a -> 'a -> 'a
│ val zero : 'a
│ end
└────
My question is how the corresponding function would be written:
┌────
│ let average arr =
│ ???
└────
smolkaj replied
───────────────
First, `Averagable' should look like this:
┌────
│ module type Averagable = sig
│ type t
│ val divide_by_int : t -> int -> t
│ val plus : t -> t -> t
│ val zero : t
│ end
└────
Then average will look something like this:
┌────
│ let average (type t) (module A : Averagable with type t = t)
(arr : t array) : t =
│ Array.fold ~init:A.zero ~f:A.plus arr
└────
(The code above uses Jane Street’s Base/Core library.)
ivg then added
──────────────
While @smolkaj’s answer is a correct and direct implementation
of your
F# code, it might be nicer if your code can interplay with
existing
abstractions in the OCaml infrastructure. For example,
┌────
│ open Base
│
│ let average (type a) (module T : Floatable.S with type t = a)
xs =
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
and now it could be used with any existing numeric data in
Base/Core
┌────
│ average (module Int) [|1;2;3;4|];;
│ - : Base.Float.t = 2.5
└────
and even adapted to non-numbers,
┌────
│ let average_length = average (module struct
│ include String
│ let to_float x = Float.of_int (String.length x)
│ let of_float _ = assert false
│ end)
└────
The latter example shows that we requested more interface than
need, a
cost that we have to pay for using an existing definition. In
cases
when it matters, you can specify the specific interface, e.g.,
┌────
│ module type Floatable = sig
│ type t
│ val to_float : t -> float
│ end
│
│ let average (type a) (module T : Floatable with type t = a) xs
=
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
But we reached the point where using first class modules is
totally
unnecessary. Our interface has only one function, so the
following
definition of average, is much more natural
┌────
│ let average xs ~f =
│ Array.fold ~init:0. ~f:(fun s x -> s +. f x) xs /.
│ Float.of_int (Array.length xs)
└────
it has type `'a array -> f:('a -> float) -> float' and computes
an
average of `f x_i' for all elements in the array.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 41191 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-10 8:21 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-12-10 8:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 4145 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 03
to 10,
2019.
Table of Contents
─────────────────
Internships at Nomadic-labs
Interesting OCaml Articles
Next OUPS meetup December 18th 2019
Old CWN
Internships at Nomadic-labs
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/internship-at-nomadic-labs/4819>
Julien Tesson announced
───────────────────────
Nomadic Labs is currently looking for students with an interest
in
functional programming for internships that would take place in
our
offices in Paris or Grenoble.
We have a catalog of internships topics available at [1] The
internships topics are mainly addressed to master student but
other
well motivated application will be considered.
A first selection phase on received résumé will occur on
december
15th. Please contact us at contact@nomadic-labs.com by
specifying
which topics in the catalog you're interested in.
[1]: <https://nomadic-labs.com/download/internship_catalog.pdf>
Please, feel free to redistribute widely.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/57>
james woodyatt announced
────────────────────────
Found on *Lobste.rs*: Mark Karpov writes yet another [Haskell
vs. OCaml] for old time's sake. I found it worth a read and a
mention
here.
p.s. He spends a bit of time in the intro lamenting the lack of
a
conventional Unicode string library for OCaml, and I feel that
pain
acutely, especially since I'm the author of an *unconventional*
one,
i.e. the [Ucs_text] module in my [Orsetto] project.
[Haskell vs. OCaml]
<https://markkarpov.com/post/haskell-vs-ocaml.html>
[Ucs_text]
<https://bitbucket.org/jhw/orsetto/src/default/src/ucs/ucs_text.mli>
[Orsetto] <https://bitbucket.org/jhw/orsetto>
Next OUPS meetup December 18th 2019
═══════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00009.html>
Bruno Bernardo announced
────────────────────────
The OUPS meetup is back. The next one will take place on
Wednesday,
December 18, 7pm at IRILL on the Jussieu campus. As usual, we
will
have a few talks, followed by pizzas and drinks.
The talks will be the following:
• Nathan Rebours, The future of OCaml-PPX
• Guillaume Claret, coq-of-ocaml
(<https://clarus.github.io/coq-of-ocaml/>)
And possibly a third talk. Contact us if you want to present
something, especially if you have a small project you want to
show in
10-15min.
To register, or for more information, go here:
<https://www.meetup.com/ocaml-paris/events/267019458>
*Registration is required! Access is not guaranteed after 7pm if
you're not registered.* (It also helps us to order the right
amount of
food.)
Access map:
IRILL - Université Pierre et Marie Curie (Paris VI)
Barre 15-16 1er étage
4 Place Jussieu
75005 Paris
<https://www.irill.org/pages/access.html>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 15372 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-17 8:52 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-12-17 8:52 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 6972 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 10 to 17,
2019.
Table of Contents
─────────────────
Is there a good way to encode linear types in OCaml?
Arch Linux installer written in OCaml
batteries batteries.2.11.0
Old CWN
Is there a good way to encode linear types in OCaml?
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/is-there-a-good-way-to-encode-linear-types-in-ocaml/1292/7>
Continuing this old thread, Konstantin Olkhovskiy said
──────────────────────────────────────────────────────
I've stumbled upon a library that implements linear types for OCaml,
using monads, lens and some ppx to make it more lightweight. Might be
of interest: <https://github.com/keigoi/linocaml>
Anton Kochkov added
───────────────────
It is the part of even more interesting system - [OCaml MPST]
(Multiparty Session Types) See the [slides].
[OCaml MPST] <https://github.com/keigoi/ocaml-mpst>
[slides]
<https://www.slideshare.net/keigoi/ocamlmpst-global-protocol-combinators-175519214>
Guillaume Munch-Maccagnoni then said
────────────────────────────────────
(The paper linked on that page is dated 2011/2014. In case anyone
wonders whether the authors have found a time machine in a barn to be
able to cite papers from 2018, there just seems to be an error in the
preparation. It is freshly published, and a PDF with correct dates is
available [here].)
[here]
<https://www.jstage.jst.go.jp/article/ipsjjip/27/0/27_431/_article>
Arch Linux installer written in OCaml
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/arch-linux-installer-written-in-ocaml/4388/12>
Darren announced
────────────────
I'm doing a short update here as Oali has seen some significant
changes. This update is also the last one here to avoid being too
annoying, and also since I won't be add too much new stuff to Oali in
foreseeable future.
Major changes since last time
• SaltStack files and script files (or profiles) now live in a
separate [repo]
• Oali accepts custom profile repo URL to facilitate using your own
SaltStack files without forking Oali itself
• Semi self-documentation
• Added mechanism to facilitate inline documentation inside
`oali.ml' itself
• The generated markdown doc is stored as [OALI_DOC] in repo, it
lists all the steps (or tasks) Oali does, along with descriptions
• Added LVM support
• Works with all 3 disk layouts, and encryption
• See [here] for details on added logical volumes
• Answer remembering of dialogues when appropriate
• Relatively static answers (e.g. hostname, whether to use
encryption, LVM) are stored in `oali_answers' directory, with a
JSON file for each task
• The "answer store" can be used in new session of Oali. The old
answer store is wiped accordingly if user changes their answer.
• Added SSH server setup and public key transfer code (ported from old
server bash script)
• See [here] for details
• Mainly useful for when you have (virtual) console access to live
CD/Oali install screen, and want to add needed public key to the
user's `.ssh/authorized_keys' via network instead of loading from
physical medium
I've used Oali to install in various configurations in past couple of
days, and have yet to notice major defects. That being said, exercise
caution as you would for installing an OS.
[repo] <https://github.com/darrenldl/oali-profiles>
[OALI_DOC] <https://github.com/darrenldl/oali/blob/master/OALI_DOC.md>
[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#20-set-up-disk>
[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#54-transfer-ssh-public-keys>
batteries batteries.2.11.0
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-batteries-batteries-2-11-0/4871/1>
UnixJunkie announced
────────────────────
The latest 2.x release of batteries is available in opam. OCaml
batteries included is a community maintained extended standard
library.
<https://github.com/ocaml-batteries-team/batteries-included>
The API documentation is hosted here:
<https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>
Here is the changelog:
┌────
│ v2.11.0 (minor release)
│
│ This minor release fixes a few bugs or interface mismatch with OCaml stdlib,
│ and is compatible with BER MetaOCaml.
│
│ This is the last planned release of the v2 series.
│ Next planned release (v3.0.0) will introduce some API changes.
│
│ Notable changes:
│
│ Add Unix.with_locked_file
│ #904
│ (Simon Cruanes, Cedric Cellier, review by Francois Berenger)
│
│ Build with -strict-sequence
│ #927
│ (Armaël Guéneau, review by Francois Berenger)
│
│ Add Legacy.Result for OCaml >= 4.8.0
│ #913
│ (Cedric Cellier, review by Francois Berenger)
│
│ Remove BatOo
│ #915
│ (Cedric Cellier, review by Francois Berenger)
│
│ Add BatFilename
│ #910
│ (Cedric Cellier, review by Francois Berenger)
│
│ Make batteries usable with BER MetaOCaml
│ #909
│ (Cedric Cellier, review by Francois Berenger and Gabriel Scherer)
│
│ Unix.sleepf is provided across all OCaml versions;
│ previously it was only for OCaml >= 4.03.0
│ #930
│ (Francois Berenger, review by Cedric Cellier)
└────
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 18093 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-31 9:18 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2019-12-31 9:18 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 14554 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 17 to 31,
2019.
Sorry for the hiatus last week, I was away with no internet
access. Happy new year!
Table of Contents
─────────────────
Internships at Be Sport (OCaml, Ocsigen)
ocaml-lsp preview
Reproducible builds with OCaml / opam and MirageOS
the OCaml Software Foundation
soupault: a static website generator based on HTML rewriting
Release of owl-symbolic 0.1.0
Old CWN
Internships at Be Sport (OCaml, Ocsigen)
════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00023.html>
Be Sport announced
──────────────────
Be Sport currently has several open internship positions for OCaml
developers.
Keywords: OCaml, Ocsigen, Mobile app development, Web, Database,
Sport, Social networks
Be Sport develops the first global platform dedicated to sport, in
collaboration with prominent actors of sport in France and in the
world. All our development is done in OCaml. Our Web and mobile apps
(iOS, Android) are developed as a multi-tier app using the Ocsigen
framework. Our premises are located in the center of Paris.
Please contact me for more information.
ocaml-lsp preview
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/1>
Rudi Grinberg announced
───────────────────────
I'm excited to announce [ocaml-lsp]. This project contains an
implementation of an LSP server for the OCaml language. The current
implementation piggy backs on the widely successful [merlin] tool to
provide completion & type inference. In the future, we'd like to use
all other essential tools such as ocamlformat, odoc, dune to provide
more functionality in your editors.
For now, the project isn't yet available on opam as we're still
polishing some rough edges in the release process. Nevertheless, I
invite all brave souls who are ready to experiment to give this lsp
server a try. Your feedback & contributions are most welcome
:slight_smile:
[ocaml-lsp] <https://github.com/ocaml/ocaml-lsp>
[merlin] <https://github.com/ocaml/merlin>
UnixJunkie asked and Anton Kochkov replied
──────────────────────────────────────────
This project looks nice.
If I am an Emacs or Vi user, can I take advantage of an
LSP server?
Or, is this only for some new editors like Atom or VScode?
@UnixJunkie of course! That's the whole point of this tooling.
For Vim you can choose between:
• [Coc.nvim] - most powerful of all, but written in TypeScript and
heaviest of all
• [Ale] - pure VimL
• [vim-lsp] - pure VimL
• [LanguageClient-neovim] - written in Rust
• Some other implementations
I am not an Emacs expert, but there is amazing LSP integration too:
• [lsp-mode]
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/b/b8acd745527e801fef1eb3d4e8722d49c5c2ed1a.png>
[Coc.nvim] <https://github.com/neoclide/coc.nvim>
[Ale] <https://github.com/dense-analysis/ale>
[vim-lsp] <https://github.com/prabirshrestha/vim-lsp>
[LanguageClient-neovim]
<https://github.com/autozimu/LanguageClient-neovim>
[lsp-mode] <https://github.com/emacs-lsp/lsp-mode>
Pau Ruiz Safont said
────────────────────
Neovim 0.5.0 (now pre-released) has native LSP support as well:
<https://github.com/neovim/neovim/pull/11336>
Not sure how well integrated is it going to be with various plugins
([example])
[example] <https://github.com/Shougo/deoplete-lsp>
Anton Kochkov added
───────────────────
NeoVim 0.5.0 will also include the [tree-sitter] parser for syntax
highlighting, which will allow way better coloring. And tree-sitter
already has [OCaml grammar], so implementing semantics-aware syntax
highlighter will be easier. But I expect the support more or less
ready for external contributions only in 0.6.0, sadly. Integrating the
tool with something like [GitHub Semantic] (*Haskell alert*) will
greatly improve OCaml experience on GitHub too, see the [corresponding
issue].
[tree-sitter] <https://tree-sitter.github.io/tree-sitter/>
[OCaml grammar] <https://github.com/tree-sitter/tree-sitter-ocaml>
[GitHub Semantic] <https://github.com/github/semantic>
[corresponding issue] <https://github.com/github/semantic/issues/138>
Pieter Goetschalckx said
────────────────────────
The next step for Semantic support is documented [here], but I'm
working on some [improvements] of the tree-sitter parser first.
[here]
<https://github.com/tree-sitter/haskell-tree-sitter/blob/master/docs/codegen.md>
[improvements]
<https://github.com/tree-sitter/tree-sitter-ocaml/pull/36>
Carlos D'Agostino said
──────────────────────
For Emacs there is also `eglot': <https://github.com/joaotavora/eglot>
– As the README says, it's quite minimalist compared to `lsp-mode'.
Reproducible builds with OCaml / opam and MirageOS
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/reproducible-builds-with-ocaml-opam-and-mirageos/4877/1>
Hannes Mehnert announced
────────────────────────
I wrote up recent developments about reproducible builds with opam –
including some tooling <https://hannes.nqsb.io/Posts/ReproducibleOPAM>
Thanks to everyone involved in the effort to get OCaml and opam
deterministic
• Nov 2015 [I collected downstream patches and asked kindly to get
them upstream] (temporary flle names in binaries, timestamps)
• Dec 2017 [BUILD_PATH_PREFIX_MAP support] (and further patches for
that)
• Dec 2018 Paris summit [opam reproducibility] [MirageOS]
• [`orb'] tool for reproducibility testing (so much better than the
shell scripts I used in the meantime)
• Dec 2019 [Marrakesh summit]
The journey is not yet finished, we're in a pretty good shape, but
further testing and tooling is needed to expose the information "is my
library reproducible?" to OCaml developers.
I'm interested in feedback, please let us discuss this further here in
case you're interested. :D
[I collected downstream patches and asked kindly to get them upstream]
<https://github.com/ocaml/ocaml/issues/7037>
[BUILD_PATH_PREFIX_MAP support]
<https://github.com/ocaml/ocaml/pull/1515>
[opam reproducibility]
<https://reproducible-builds.org/events/paris2018/report/#Toc11410_331763073>
[MirageOS]
<https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>
[`orb'] <https://github.com/rjbou/orb>
[Marrakesh summit]
<https://reproducible-builds.org/events/Marrakesh2019/>
Anil Madhavapeddy added
───────────────────────
An absolutely amazing cross-layer effort; well done on pushing all
this through @hannes! I really enjoyed reading the minutes of the
Paris summit last year:
<https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>
the OCaml Software Foundation
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>
Continuing this thread, gasche announced
────────────────────────────────────────
A small report on the actions that we launched since my initial
posting.
(There was also some progress on the "enabling individual donations"
front, maybe something will be possible in the next few months. Don't
start holding your breath yet.)
• We are funding the "Leafs" research project in Lisbon to develop
teaching material for theoretical-computer-science courses (automata
and stuff) in OCaml, with interactive visualization components, some
of which will hopefully be integrated in the [Learn-OCaml] platform
over the course of 2020/2021.
• We provide funding for the [Gallium/Cambium] research team at INRIA
Paris (France), an active place for OCaml-related fundamental
research (some of the team members are also very active on the
implementation front, for example Xavier Leroy, Damien Doligez,
Florian @octachron Angeletti, and Sébastien Hinderer).
• We sponsor the [SWERC] programming contest for 2019-2020, and in
return the contest added OCaml to the list of available
languages. Most participants to these competitive-programming events
use C++, but we talked to past and active participants who said they
would be interested in using OCaml on some problems with more
symbolic computation.
• Over the course of the 4.10 release process, we are funding work by
@kit-ty-kate to have a wide look at the ecosystem and improve
compatibility with the upcoming release. (I believe that the
upstream PR [#9176] is a first result of this effort.)
• In reaction to the Discourse thread [Suggestions for OCaml
documentation], we are planning to fund further work by @sanette to
experiment with the HTML rendering of the OCaml manual, in
coordination with @octachron to try to upstream improvements when
reasonably possible.
• We got in touch with the [Owl] project to sponsor a development
sprint in 2020.
[Learn-OCaml] <http://ocaml-sf.org/learn-ocaml.html>
[Gallium/Cambium] <http://cambium.inria.fr/>
[SWERC] <https://swerc.eu/2019/about/>
[#9176] <https://github.com/ocaml/ocaml/pull/9176>
[Suggestions for OCaml documentation]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
[Owl]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/10>
Daniil Baturin announced
────────────────────────
Made a [1.7.0 release].
First improvement is that you now can pipe the content of any element
through any external program with `preprocess_element' widget (PR by
Martin Karlsson). For example, insert inline SVG versions of all
graphviz graphs from `<pre class="language-graphviz">' and also
highlight the Dot source itself with [highlight] (or any other tool of
your choice):
┌────
│ [widgets.graphviz-svg]
│ widget = 'preprocess_element'
│ selector = 'pre.language-graphviz'
│ command = 'dot -Tsvg'
│ action = 'insert_after'
│
│ [widgets.highlight]
│ after = "graphviz-svg"
│ widget = "preprocess_element"
│ selector = '*[class^="language-"]'
│ command = 'highlight -O html -f --syntax=$(echo $ATTR_CLASS | sed -e "s/language-//")'
│ action = "replace_content" # default
└────
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a4d8cc05d65634de0faf3c05b16e0de8d27a78a3.png>
Two other improvements are multiple index "views" and default value
option for custom index fields, like
┌────
│ [index.custom_fields]
│ category = { selector = "span#category", default = "Misc" }
└────
[1.7.0 release]
<https://soupault.neocities.org/blog/soupault-1.7.0-release>
[highlight] <http://andre-simon.de>
Release of owl-symbolic 0.1.0
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/1>
jrzhao42 announced
──────────────────
We are please to release [owl-symbolic 0.1.0]. It fully supports
defining a computation graph and running on accelerators (TPU/GPU) via
[ONNX] specification. It also aims to support converting an Owl
computation graph into symbolic representation and then to ONNX
model. The module also has some cool features like converting a
computation graph into LaTeX string, and then showing the result in a
web UI, etc.
We implements a full neural network module atop of it (the interface
of which is basically identical to that in Owl's core). It turns out
that the design of `owl-symbolic' is so nice that the DNN module only
has 179 LOC! You can easily define popular DNN architectures such as
Inception, ResNet, VGG, etc. just like in Owl.
This is still an on-going project and a lot remains to be
done. Despite its name, `owl-symbolic' does not do any useful computer
algebra (CAS) stuff at the moment, but CAS is indeed on our TODO.
For more information, please check out the related section in [Owl
tutorial book].
[owl-symbolic 0.1.0] <https://opam.ocaml.org/packages/owl-symbolic/>
[ONNX] <https://onnx.ai/>
[Owl tutorial book] <https://ocaml.xyz/owl_tutorials/symbolic.html>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26832 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-07 13:43 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-01-07 13:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 23631 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 31, 2019
to January 07, 2020.
Table of Contents
─────────────────
ocaml-lsp preview
Mkocaml Release - Project generator
Garbage Collection, Side-effects and Purity
A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
Release of owl-symbolic 0.1.0
Static lifetime
Old CWN
ocaml-lsp preview
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/15>
Continuing this thread, Edwin Török said
────────────────────────────────────────
Here is an example with ALE and Neovim (tested with v0.3.8):
• Install the [Ale] plugin. If your Vim has support for packages (Vim
8+ or Neovim) you can simply clone it in the correct subdir, no need
for a plugin manager: `git clone https://github.com/w0rp/ale.git
.vim/pack/my-plugins/start/ale'
• Add this to your .vimrc:
┌────
│ " only invoke merlin to check for errors when
│ " exiting insert mode, not on each keystroke.
│ let g:ale_lint_on_text_changed="never"
│ let g:ale_lint_on_insert_leave=1
│
│ " enable ALE's internal completion if deoplete is not used
│ let g:ale_completion_enabled=1
│
│ " only pop up completion when stopped typing for ~0.5s,
│ " to avoid distracting when completion is not needed
│ let g:ale_completion_delay=500
│
│ " see ale-completion-completeopt-bug
│ set completeopt=menu,menuone,preview,noselect,noinsert
│
│ if has('packages')
│ packloadall
│
│ " This should be part of ALE itself, like ols.vim
│ call ale#linter#Define('ocaml',{
│ \ 'name':'ocaml-lsp',
│ \ 'lsp': 'stdio',
│ \ 'executable': 'ocamllsp',
│ \ 'command': '%e',
│ \ 'project_root': function('ale#handlers#ols#GetProjectRoot')
│ \})
│
│ " remap 'gd' like Merlin would
│ nmap <silent><buffer> gd <Plug>(ale_go_to_definition_in_split)<CR>
│
│ " go back
│ nnoremap <silent> <LocalLeader>gb <C-O>
│
│ " show list of file:line:col of references for symbol under cursor
│ nmap <silent><buffer> <LocalLeader>go :ALEFindReferences -relative<CR>
│
│ " Show documentation if available, and type
│ nmap <silent><buffer> <LocalLeader>hh <Plug>(ale_hover)<CR>
│
│ " So I can type ,hh. More convenient than \hh.
│ nmap , <LocalLeader>
│ vmap , <LocalLeader>
│ endif
└────
[Ale] <https://github.com/dense-analysis/ale>
Mkocaml Release - Project generator
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/mkocaml-release-project-generator/4949/1>
Chris Nevers announced
──────────────────────
I recently created a tool to generate OCaml projects. I constantly
have difficulties with dune commands and setting up opam files,
etc. Mkocaml generates a dune project with inline tests, opam file,
git repository, git ignore, and a Makefile with easy commands. This
tool can be of great help to newcomers, allowing them to get up and
running faster!
<https://github.com/chrisnevers/mkocaml>
Garbage Collection, Side-effects and Purity
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/garbage-collection-side-effects-and-purity/4737/1>
Gerard asked
────────────
GC = Garbage Collection
GC, in a pure program, is a point that's always confused me. I always
understood that freeing memory from a program was impure and would
create side-effects but it seems it doesn't matter if the program is
remove from all consequences of those impure acts and side-effects.
Basically, if any memory block has no remaining references in the
program, then freeing that block will have no consequences on the
running program so its allowed to happen behind the scenes..
Is this correct reasoning?
Guillaume Munch-Maccagnoni replied
──────────────────────────────────
To answer your question “does de-allocation creates a side-effect?”:
To state the obvious: if you care about the memory consumption of your
program, then you care about the side-effect of de-allocation, and
this indeed voids purity.
A language like OCaml lets you reason about de-allocation. Memory is
collected when values are no longer reachable. Like in other
languages, 1) a value that does not escape and goes out of scope will
get collected, and 2) you can reason about when a value escapes and
goes out of scope thanks to OCaml respecting the strict evaluation
order of value types. OCaml (like other compiled languages) is in fact
more precise: it ties the dynamic notion of reachability to the
lexical notion of variable occurrence. For instance, in the following:
┌────
│ let x = get_huge_data () in
│ let z = long_running_function x in
│ f z
└────
OCaml will be able to collect the value in `x' before `x' goes out of
scope, and thus if possible before `long_running_function'
returns. Indeed, OCaml performs liveness analysis during compilation,
and records the information about variable occurrences in frame
descriptors, for consumption by the GC when it scans for roots. In
fact, you can rely on call-by-value operational semantics to (loosely)
reason that a value no longer appears in a program, and therefore that
the corresponding memory will be collected by the GC¹ ([Morrisett,
Felleisen and Harper, "Abstract Models of Memory Management"]). Of
course, using lazy or higher-order interfaces (when closures escape;
with many idioms they do not) will make it harder to reason about the
lifetime of values.
(¹: For OCaml, this is a conjecture I make, for subsets which could be
given such operational semantics, and only for native
compilation. Morrisett, Felleisen and Harper's semantics obviously
assumes that the results of liveness analysis are made available to
the GC, but this is not written, nor is there any mention of the link
between liveness analysis and accuracy of garbage collection in
Appel's "Modern Compiler Implementation in C". I assume that it was
part of folklore at the time, though recently I mentioned it to some
functional PL researcher and they seemed surprised. I only found it
explicitly mentioned in later papers from the OOP community. I checked
that everything seems in place for OCaml to allow such reasoning, but
only the authors of the original code, @xavierleroy and
@damiendoligez, can tell us if this is intended to be part of the
language semantics.)
Furthermore, memory is not collected immediately when a value becomes
unreachable. Instead:
• Short-lived values are allocated contiguously and deallocated in a
batch, so that allocating and deallocating short-lived values is
very cheap, with additional benefits in terms of cache
locality. This replaces stack allocation from languages with
explicit memory management.
• Longer-lived values are moved to a heap that is scanned
incrementally, to ensure a bounded latency. In contrast, naive
reference-counting and unique pointers from C++/Rust make you pay
the cost of deallocation up-front.
While this is essential for understanding the performance of OCaml
programs, from the point of view of deallocation-as-an-effect, the
delaying of the collection of unreachable memory can be seen as a
runtime optimisation, that does not change the effectful status of
deallocation (the memory still gets freed). [The intuition is that an
effect can support some degree of reordering without requiring purity,
as illustrated by strong monads which can be commutative without being
idempotent, one possible definition of purity for semanticists.]
But is de-allocation an effect _in practice_? Faced with the
scepticism and misunderstandings from this thread, I emit two
hypotheses:
1) Memory consumption is not an issue in functional programming, for
application areas that interest functional programmers.
2) Memory management in OCaml is efficient in such a way that
programmers do not need to think about it in their day-to-day
programming activities in those terms.
Hypothesis 2) could be explained for instance if OCaml programmers are
already dealing with effects and thinking about the order in which
their code executes (my experience), and are only used to deal with
deallocation as an afterthought, e.g. when chasing leaks with a
profiler.
Let us turn towards two programming language experiments from the
1990's that allow me to reject hypothesis 1). Both show what happens
when one denies the status of deallocation as an effect controlled by
the programmer.
• Region-based memory management consisted in allocating in a stack of
memory _regions_ deallocated at once, and determined by a
whole-program static analysis. Now regarded as a failed idea but
successful experiment (i.e. good science!), it taught us a lot about
the structure of functional programs in relationship to memory
management ([see this retrospective]). There were some good
performance results, but also pathological cases _“where lifetimes
were not nested or where higher-order functions were used
extensively”_, sometimes requiring them to be altered to be _“region
friendly”_, which was _“time-consuming”_ and required knowledge of
the inference algorithm. In addition, the regions changed
unpredictably when the programs evolved, and memory leaks appeared
when the compiler inferred too wide regions.
• Haskell was (at the time) an experiment with lazy functional
programming. Pervasive laziness prevents reasoning about the
lifetime of values, and purity is a central assumption used by the
compiler for program transformations, which is antithetical with
reasoning about deallocation as an effect. It is well-known that
naive Haskell code has issues with memory leaks, and that realistic
Haskell programs have to follow "best practices" to avoid leaks, by
making extensive use of strictness annotations (e.g. bang
patterns). Unfortunately, I found it hard to find reliable academic
sources about lessons drawn from the experiment like the RBMM
retrospective. The best I could find on the topic of memory leaks is
the following blog post:
<https://queue.acm.org/detail.cfm?id=2538488>, from a Haskell
programmer who wrote in another post (linked from that one) _“My
suspicion is that many (most?) large Haskell programs have space
leaks, but they often go unnoticed”_. This is consistent with
comments I received from people with Haskell experience (first-hand,
one academic and one industrial) and about an industrial Haskell
consultant (second-hand) who reportedly commented that their main
job was to fix memory leaks (but maybe in jest). Of course, take
this with a grain of salt. At least, I believe that the Haskell
academic community has accumulated empirical evidence of the extent
and manner in which deallocation voids purity assumptions. Having an
authoritative source about it would be pretty important to me, given
the initial promises of functional programs being more tractable
mathematically specifically via “referential transparency” and
independence of execution order, whose theoretical justification
already looks shaky to me from a semantic point of view. Some parts
of the literature continues to promise far-reaching consequences of
equational reasoning, without clear statements of limitation of the
application domain. I have the impression that the Haskell which is
practiced in the real world is very different from what you can read
in some academic papers.
The hypothesis that deallocation matters as an effect, and that ML
makes it easy to program and reason about effects, seems to me a
strong argument explaining OCaml's predictable and competitive
performance.
So, thank you for your healthy scepticism.
[Morrisett, Felleisen and Harper, "Abstract Models of Memory
Management"] <https://dash.harvard.edu/handle/1/3293156>
[see this retrospective]
<https://link.springer.com/article/10.1023/B:LISP.0000029446.78563.a4>
Xavier Leroy replied
────────────────────
Concerning the "don't scan local variables that are dead" trick:
• Technically it is not "intended to be part of the language
semantics" because the bytecode compiler (ocamlc) doesn't implement
it, only the native-code compiler (ocamlopt).
• As far as I remember, I reinvented this trick circa 1993, but it
seems it was used earlier in the Lazy ML compiler by Augustsson and
Johnsson. See Appel and Shao's paper "An Empirical and Analytic
Study of Stack vs. Heap Cost for Languages with Closures", JFP,
1996, end of section 5.
Guillaume Munch-Maccagnoni the asked
────────────────────────────────────
TL;DR: the paper mentioned by @xavierleroy provides additional
references regarding the importance of liveness analysis for GC,
including a demonstration by Appel that this actually matters for
space complexity (thanks!). I find that a link is still missing with
an abstract semantics à la Morrisett, Felleisen & Harper. This seems
important to me because more theoretical works about time & space
complexity in the lambda-calculus seem to take for granted that
garbage collection implements something like the latter (i.e., how
does one specify and certify that a compiler is sound for space
complexity?).
Xavier Leroy replied
────────────────────
See for example [Closure Conversion is Safe for Space], by Zoe
Paraskevopoulou and Andrew W. Appel, ICFP 2019.
[Closure Conversion is Safe for Space]
<https://www.cs.princeton.edu/~appel/papers/safe-closure.pdf>
A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-lightweight-ocaml-webapp-tutorial-using-opium-caqti-and-tyxml/4967/1>
Shon announced
──────────────
The tutorial is [hosted on gitlab pages], out of [this repository].
I put this together in response to some requests for introductory
material on the topic (here and on [/r/ocaml]. I don't have much
expertise to offer in this area, but I had hacked together some simple
servers based on Opium in the past few months, so it seemed like I
should be able to memorialize some of what I learned for the benefit
of others. I received some critical guidance by the Opium maintainers,
rgrinberg and anuragsoni, and from other resources online (mentioned
at the end of the tutorial).
Any feedback or improvements are welcome: this is my first time
writing such lengthy instructional material, and I'm sure there's lots
of room to make it better.
[hosted on gitlab pages] <https://shonfeder.gitlab.io/ocaml_webapp/>
[this repository] <https://gitlab.com/anuragsoni/ocaml_webapp>
[/r/ocaml] <https://www.reddit.com/r/ocaml/>
Release of owl-symbolic 0.1.0
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/2>
jrzhao42 announced
──────────────────
The Owl tutorial book URL address is now changed to:
<https://ocaml.xyz/book/symbolic.html>.
Static lifetime
═══════════════
Archive: <https://discuss.ocaml.org/t/static-lifetime/4908/19>
André asked and Guillaume Munch-Maccagnoni replied
──────────────────────────────────────────────────
> Is it possible to “statically” allocate a value? By this I mean mark
a value such that it gets ignored by the GC and lives until the
program exits?
This is indeed the purpose of Ancient, which comes with limitations
and does not allow you to reclaim the memory until you exit the
program. (I am curious to know how well it works with recent OCaml
versions.)
> it would be really interesting to learn whether Ocaml forbids blocks
outside the heap.
The OCaml runtime has two modes (chosen at compilation) for dealing
with so-called "out-of-heap" pointers. In the legacy one that Chet
remembers, the GC uses a page table when scanning to be able to tell
which pointers it possesses. In the "no-naked-pointers" mode devised
more recently for efficiency reasons, the page table is replaced by
looking at the colour in the header of the dereferenced
value. Out-of-heap values must be preceded by a header with colour
black. The no-naked-pointer mode is more restricted, because once a
static value is referenced, it can no longer be deallocated, as you
never know whether it is still reachable by the GC. This should be
enough to support Ancient.
> One should verify such intuitions experimentally, before trying to
fix them, but I’m not familiar with what OCaml profilers can do…
Excluding large long-lived data from the GC is an old idea. Among
recent developments, Nguyen et al. [1] distinguish a "control path"
(where the generational hypothesis is assumed to hold) from a "data
path" (where values are assumed to follow an "epochal" behaviour
(long-lived, similar lifetimes, benefit from locality), and are
excluded from GC). They give as motivation so-called "big data" and as
figures of pathological GC usage up to 50% of total runtime. I
remember reading similar figures from blog posts about large data sets
in OCaml. In reality this indeed depends on knobs you can turn on your
GC that can result in increased peak memory usage among
others. (Assuming infinite available memory, it is even possible to
let the GC share drop to 0%.)
@ppedrot reported to me that in a recent experiment with Coq, using an
Ancient-like trick to exclude some large, long-lived and
rarely-accessed values from being scanned (namely serialising them
into bigarrays), they saw an 8% performance improvement across the
board in benchmarks.
Multicore, if I understood correctly, aims to support only the
no-naked-pointer mode, and I am not sure what the page table will
become. Coq currently does some out-of-heap allocation in the VM, and
has been adapted to be compatible with the no-naked-pointer mode by
wrapping out-of-heap pointers into custom blocks. For scanning its
custom stack (which mixes in-heap and out-of-heap values), Coq sets up
a custom root-scanning function (`caml_scan_roots_hook`), which still
relies on the page table.
Note that having to wrap out-of-heap pointers in custom blocks is
(much!) less expressive: for instance with Ancient you can call
`List.filter` on a statically-allocated list (and correctly get a
GC-allocated list of statically-allocated values). With custom blocks
you cannot mix in-heap and out-of-heap values in this way.
For a type system to deal with "statically" allocated values, have a
look at Rust, which: 1) prevents cycles of reference-counting schemes
thanks to uniqueness, 2) can treat GC roots as resources to deal with
backpointers at the leaves of the value (cf. the interoperability with
SpiderMonkey's GC in Servo). A point of view that I like is that
tracing GCs and static allocation differ fundamentally by how they
traverse values for collection: traversing live values for the first
one, and traversing values at the moment of their death for the
other. This gives them distinct advantages and drawbacks so one can
see them as complementary. (See notably [2,3].) Static allocation is
interesting for performance in some aspects (no tracing, no read-write
barrier, reusability of memory cells, avoids calling the GC at
inappropriate times), but I find it even more interesting for
interoperability (e.g. exchanging values freely with C or Rust, or
[applications from that other thread]). It is natural to want to mix
them in a language.
As far as I understand, developing the runtime capabilities for OCaml
to deal with out-of-heap pointers without resorting to an expensive
page table is an engineering problem, not a fundamental one. If anyone
is interested in this, please contact me.
[1] Nguyen et al., [Yak : A High-Performance Big-Data-Friendly Garbage
Collector], 2016
[2] Bacon, Cheng and Rajan, [A Unified Theory of Garbage Collection],
2004
[3] Shahriyar, Blackburn and Frampton, [Down for the Count? Getting
Reference Counting Back in the Ring], 2012
[applications from that other thread]
<https://discuss.ocaml.org/t/using-a-bigarray-as-a-shared-memory-for-parallel-programming/4841/19>
[Yak : A High-Performance Big-Data-Friendly Garbage Collector]
<https://www.usenix.org/system/files/conference/osdi16/osdi16-nguyen.pdf>
[A Unified Theory of Garbage Collection]
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.439.1202&rep=rep1&type=pdf>
[Down for the Count? Getting Reference Counting Back in the Ring]
<https://dl.acm.org/citation.cfm?doid=2258996.2259008>
UnixJunkie also replied
───────────────────────
If you can store your long-leaved data into a bigarray, I think you
would reach the effect that you were looking for (no more GC scanning
of this data).
This was once advised to me by Oleg, for some performance-critical
section of some code.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35507 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-14 14:17 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-01-14 14:17 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 24944 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 07 to 14,
2020.
Table of Contents
─────────────────
Calling a single function on every member of a GADT?
OCamlPro's opam cheat sheet, with a new theme!
OCaml 4.10.0, first beta
Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
Release of naboris 0.1.0 a simple http server
esy@0.6.0 release
Old CWN
Calling a single function on every member of a GADT?
════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00007.html>
Ivan Gotovchits asked
─────────────────────
I'm basically trying to do the equivalent of this simple `fold'
function:
┌────
│ module Simple =
│ struct
│ type term =
│ | Int of int
│ | Add
│ | App of term * term
│
│ let rec fold i f = function
│ | Int _ as t -> f i t
│ | Add -> f i Add
│ | App (x, y) as t -> f (fold (fold i f x) f y) t
│ end
└────
… but using a GADT:
┌────
│ module Gadt =
│ struct
│ type _ term =
│ | Int : int -> int term
│ | Add : (int -> int -> int) term
│ | App : ('b -> 'a) term * 'b term -> 'a term
│
│ let rec fold : type a. 'r -> ('r -> _ term -> 'r) -> 'r = fun i f -> function
│ | Int _ as t -> f i t
│ | Add -> f i Add
│ (*
│ ^ Error: This pattern matches values of type (int -> int -> int) term
│ but a pattern was expected which matches values of type int term
│ Type int -> int -> int is not compatible with type int
│ *)
│ | App (x, y) as t -> f (fold (fold i f x) f y) t
│ end
└────
I've tried other variants of the syntax and got many encouragements
but no green flag from the type-checker. Why is the compiler
expecting an int term in there? I though the whole point of the `type
a. ...' syntax was to allow the matched type to vary from one pattern
to the next? Is there a way to do this?
Ivan Gotovchits replied
───────────────────────
It is the limitation of the let-bound polymorphism. A parameter of a
function is monomorphic in its body. The classical example doesn't
even reference any GADT,
┌────
│ let example f = f "hello", f 42
└────
It won't compile even though we can provide a polymorphic function
that can applied both to integers and to strings, e.g., `exampe (fun x
-> x)' should be possible, but not, because of the let-bounded
polymorphism. There are a few solutions available in OCaml, the
simplest is to use records, e.g.,
┌────
│ type app = {apply : 'a. 'a -> 'a}
│
│ let example {apply} = apply "hello", apply 42;;
│
│ val example : app -> string * int = <fun>
└────
Now we have `app' that is polymorphic. In your case, I would define a
visitor type, e.g.,
┌────
│ type 'r visitor = {visit : 'a. 'a term -> 'r -> 'r}
│
│ let rec fold : type a. 'r -> 'r visitor -> a term -> 'r =
│ fun i f t -> match t with
│ | Int _ as t -> f.visit i t
│ | Add as t -> f.visit i t
│ | App (x,y) as t ->
│ let i = fold i f x in
│ let i = fold i f y in
│ f.visit i t
└────
Jacques Garrigue also replied
─────────────────────────────
Actually, this is a rare case where using a polymorphic method may be
handy too:
┌────
│ let rec fold : type a r. r -> <v : 'b. r -> 'b term -> r> -> a term -> r =
│ fun i f -> function
│ | Int _ as t -> f#v i t
│ | Add -> f#v i Add
│ | App (x, y) as t -> f#v (fold (fold i f x) f y) t
│
│ let v =
│ object method v : type a. _ -> a Gadt.term -> _ =
│ fun x -> function
│ | Int n -> x+n
│ | Add -> x+1
│ | App _ -> x+2
│ end
│
│ let r = Gadt.fold 0 v (App (App (Add, Int 3), Int 5))
└────
The point being that to match on a Gadt you will anyway need to use
the (type a) construct to allow refinement.
rixed asked and Ivan Gotovchits replied
───────────────────────────────────────
So there is no lighter syntax to specify that `f' should
accept any member of a GADT than the syntax to specify
that `f' should accept any type at all?
Only three methods of introducing rank-2 polymorphism are known to me:
1. records
2. objects
3. first-class modules
Jacques has demonstrated the solution with objects, which might be a
little bit more lightweight, at least as you don't need to define a
new data type beforehand. But the invocation is more verbose and
requires an annotation from the caller side, which could be
confusing. The third solution relies on first-class modules and is
even more verbose, at least on the definition side. Just for the sake
of completeness,
┌────
│ module type Visitor = sig
│ type t
│ val term : t -> 'a term -> t
│ end
│
│ let rec fold : type a r. r -> (module Visitor with type t = r) -> a term
│ -> r =
│ fun i ((module Visit) as f) t -> match t with
│ | Int _ as t -> Visit.term i t
│ | Add as t -> Visit.term i t
│ | App (x,y) as t ->
│ let i = fold i f x in
│ let i = fold i f y in
│ Visit.term i t
│
│ let s = fold 0 (module struct
│ type t = int
│ let term x _ = x + 1
│ end)
└────
And again, it is not about GADT. GADT act as a red herring here. As
I've demonstrated earlier, using a simple pair will suffice to display
the limitation of the prenex polymorphism. Even no ADT is required,
just apply one term to another two and you will get them unified,
e.g.,
┌────
│ let f g x y : unit = g x; g y
└────
will have type
┌────
│ val f : ('a -> unit) -> 'a -> 'a -> unit
└────
because 'a is quantified on the scope of `f' not `g', in other words,
it has type (not an OCaml syntax)
┌────
│ val f : forall 'a. ('a -> unit) -> 'a -> 'a -> unit
└────
while we would like to have a type
┌────
│ val f : forall 'b, 'c. (forall 'a. 'a -> unit) -> 'b -> 'c -> unit
└────
OCaml doesn't allow us to define types like `('a. 'a -> 'a)' and the
reason is not that it is hard to extend the parser it is…
I wonder, is this just a limitation of the OCaml parser or
is there some deep reason for these work-around (like is
the case, from my understanding, for the value
restriction)?
Yep, good catch! It is because of the impurity. Indeed, Haskell has
the Rank2Types extension that lets us write types like `(forall a. a
-> ()) -> b -> c -> ()', with no extra syntactic burden (modulo having
to provide the type annotation). But functions in Haskell are pure,
therefore it is possible. To make the story short and obvious, let me
do a simple demonstration of how things can go wrong in a language
with side-effects. Let's go back to the simple example of pairs and
the identity function. Consider the following nasty identity
function,
┌────
│ let bad_id () =
│ let cache = ref None in
│ fun x -> match cache.contents with
│ | None -> cache := Some x; x
│ | Some cache -> cache
└────
It has type `unit -> 'a -> 'a' therefore, if we would have the rank-1
polymorphism enabled for functions, we could apply it to the function
┌────
│ let map2 : fun ('a. 'a -> 'a) -> 'b -> 'c -> 'b * 'c = fun f (x,y) -> f x, f y
└────
as
┌────
│ let x,y : string * int = map2 (bad_id ()) "hello", 42
└────
and will get a segmentation fault, as `y' will now have type int but
hold a string.
And here comes the syntax as a savior as it lets us specify functions
that are guaranteed to be syntactic values. Indeed, all three
solutions syntactically guarantee that the provided argument is a
function, not a closure. Indeed, let's introduce the universal
identity via a record,
┌────
│ type id = { f : 'a. 'a -> 'a}
└────
and we can see that our `bad_id' is not accepted due to the value
restriction, while good_id, defined as,
┌────
│ let good_id x = x
└────
is perfectly fine, e.g.,
┌────
│ let id1 = {f = good_id} (*accepted *)
│ let id2 = {f = bad_id} (* rejected *)
└────
moreover, even a fine, but not syntactic, identity is also rejected
┌────
│ let fine_id () x = x
│ let id3 = {f = fine_id ()} (* rejected *)
└────
with the message
┌────
│ This field value has type 'b -> 'b which is less general than 'a. 'a -> 'a
└────
The same is true with modules,
┌────
│ module type Id = sig
│ val f : 'a -> 'a
│ end
│ module Id1 : Id = struct let f = good_id end (* accepted *)
│ module Id2 : Id = struct let f = bad_id () end (* rejected *)
│ module Id3 : Id = struct let f = fine_id () end (* rejected *)
└────
and with objects (left as an exercise).
To summarize, in order to enable rank2 polymorphism we need a special
kind of values to bear universal functions, as we can't rely on
ordinary functions, which could be constructed using partial
application. OCaml already had objects and records, which serve as a
fine media for universally quantified functions. Later first class
modules were introduced, which could also be used for the same
purpose. Probably, one could devise a special syntax (or rely on the
new attributes and extensions syntax, e.g., `map2 [%rank2 : fun x ->
x] ("hello",42)' but probably this will lead to an unnecessary
bloating of the language and the implementation, especially since we
already have three solutions with a more or less tolerable syntax (and
are in the base language, not an extension). Besides, if we will use
the `[@@unboxed]' annotation, or visitor will have the same
representation as a function, e.g.,
┌────
│ type 'r visitor = {visit : 'a. 'r -> 'a term -> 'r} [@@unboxed]
│ let count x _ = x + 1
│ let counter = {visit=count}
└────
and
┌────
│ # Core_kernel.phys_same count counter;;
│ - : bool = true
└────
Concerning rank-n polymorphism, in OCaml is is achieved using
functors. Yes, they are a little bit syntactically heavy and force us
to write signatures, but this is necessary anyway as rank-n is
undecidable (non-inferrable). Finally, as a real-world example [1] of
rank-2 polymorphism consider the universal WAVL tree that is a binary
tree with each element having a different type (aka heterogeneous
map). We use it in BAP as a backing store. You might find a few tricks
there, especially using continuation-passing in the recursive cases.
Cheers, Ivan
[1]:
<https://github.com/BinaryAnalysisPlatform/bap/blob/b40689e636607b977758af048b79d65684ce48c3/lib/knowledge/bap_knowledge.ml#L847-L1693>
Malcolm Matalka asked and Ivan Gotovchits replied
─────────────────────────────────────────────────
Why is type checking creating a record different than type
checking a function argument?
If we had the syntax (or something like it):
let map2 : ('a. 'a -> 'a) -> ('b * 'c) -> ('b * 'c)
Why would the type checker not be able to see that
map2 good_id ("hi", 42)
is valid but
map2 (fine_id ()) ("hi", 32)
is not, using the same logic that is verifying creating
the "id" record is not valid?
I believe it is possible, as it is possible in Haskell (with
RankNTypes and ScopedTypeVariables). The main (theoretical) difference
is that in OCaml we need to check whether an expression is expansive
and use a specialized generalization in case if it is (for the relaxed
value restriction). It will, however, complicate the type inference
engine a lot, but most importantly, changing the typing rule of
functions will have a tremendous impact on the language. So this would
be a very impractical solution. Especially, since we don't have the
mechanism of language extensions, enabling RankNTypes will make a lot
of programs untypeable, as they will now require type annotations
(recall that RankN is undecidable in general). It could probably be
implemented as a compiler command line parameter, like `-rectypes' but
this will be still quite impractical since more often code like `fun f
-> f 1, f true' is a programmer error, rather than a true request for
universal polymorphism (the same as with rectypes, recursive types a
more often an error rather than a deliberate attempt). Therefore,
enabling RankN(^1) polymorphism will type too many programs (not that
it is unsound, just many programs won't have sense) at the cost of
even more obscure type errors. On the other hand, we have three
syntactic constructs that let us express non-prenex polymorphism of
the necessary rank(^2) without breaking anything else. So it looks
like a good deal - we can have rankN polymorphism and decidable type
checker at the same time. Just think of polymorphic records/methods as
an embedded DSL for rankN polymorphism.
`==========' Footnotes:
1) An important point, that I forgot to notice, is that enabling
scoped
type variables, will inevitably enable rankN polymorphism, e.g., since
now any type could be a polytype, then suppose we have type
`'a. ('b.'b -> 'a) -> 'a' could be instantiated to 'a = 'd. ('c. ->
'd) -> 'd, so that our type is now `'d. ('b. 'b -> ('c. 'c -> 'd) ->
'd) -> ('c. 'c -> 'd) -> 'd' which is now rank3. Therefore, enabling
arbitrary quantification in the arrow type will lead to rankN and
immediately make undecidable most of the type checker.
1) We can craft arbitrary rank using records with universally
quantified
type variables, e.g., here is an example of rank3 polymorphism:
┌────
│ type 'a rank1 = {f1 : 's. 's -> 'a}
│ type 'a rank2 = {f2 : 'r. 'r -> 'a rank1}
└────
Indeed, `f2' has type `'a.('r. 'r -> ('s. 's -> 'a)'
OCamlPro's opam cheat sheet, with a new theme!
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rfc-ocamlpros-opam-cheat-sheet-with-a-new-theme/4689/3>
Thomas Blanc announced
──────────────────────
The opam cheat-sheet is now published in its final form.
You can get the [colored] and [black-and-white] versions from our
website.
Happy hacking!
[colored]
<http://www.ocamlpro.com/wp-content/uploads/2019/11/ocaml-opam.pdf>
[black-and-white]
<http://www.ocamlpro.com/wp-content/uploads/2020/01/ocaml-opam-bw.pdf>
OCaml 4.10.0, first beta
════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-first-beta/4989/1>
octachron announced
───────────────────
The release of OCaml 4.10.0 is approaching. We have published a first
beta version to help you adapt your software to the new features ahead
of the release.
During our preliminary tests for this new beta, we discovered that the
recent work towards a multicore-ready OCaml runtime introduced
compatibility issues within some opam packages, that were tweaking the
runtime internals. Most of those opam packages have been fixed, or
will be soon. Nevertheless, if you are affected by such compatibility
issue, please speak up.
The source code is available at these addresses:
<https://github.com/ocaml/ocaml/archive/4.10.0+beta1.tar.gz>
<https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta1.tar.gz>
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these:
• afl
• flambda
• fp
• fp+flambda
We want to know about all bugs. Please report them here:
<https://github.com/ocaml/ocaml/issues>
Happy hacking.
Kate added
──────────
For the people wanting to give OCaml 4.10.0beta1 a shot, here is an
opam overlay which adds fixes to major packages for them to work with
this beta: <https://github.com/kit-ty-kate/opam-alpha-repository>
To use it, simple call:
┌────
│ $ opam switch 4.10
│ $ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
└────
Obviously, this repository should not be used in production and
probably contains a few bugs, but at least it allows everyone to have
almost as many packages available as with OCaml 4.09. Only 60ish
packages are still not available, but apart from the notable exception
of `merlin' all the essential packages and dependencies are there.
This work has been part of the release-readyness effort founded by the
OCaml Software Foundation as announced here:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>
The rest of the effort is going to be put towards having `merlin'
available for OCaml 4.10 and upstreaming all the fixes from
opam-alpha-repository (most of them have PRs associated already). I'm
hopeful for them be all upstreamed and available before the stable
release of OCaml 4.10.
Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-data-engineer-positions-at-elastic-us-canada-western-europe-proximate-to-na-timezones/4991/1>
Hezekiah Carty announced
────────────────────────
Our team here at [Elastic] has positions open for a few security data
engineers (aka wranglers of data and all the systems involved). We
are a distributed company so you don't have to be close to an office
to be considered. Infosec industry experience is _not_ required,
though of course welcome. We're surrounded by experts in the field so
you'll have lots of opportunities to learn as you go!
The official postings are available here (both have the same text and
only differ in title/seniority):
• Security data engineer -
<https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-data-engineer/2005140#/>
• Senior security data engineer -
<https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-senior-data-engineer/2005152#/>
Language-wise, OCaml/Reason makes up most of the code you’ll be
working on. Python makes up most of the rest, in particular taking
advantage of the machine learning and natural language processing
goodies that ecosystem provides. Most of the tools and service we
develop are internally focused, supporting security research and
improvements to security protections for our users. For those
so-inclined, there are lots of opportunities to present at and attend
conferences, present work in blog posts, contribute to open source
software projects and otherwise engage the community.
The positions are very similar to our [last hiring announcement],
though we had a different name at that point!
Please reach out to me if you have any questions. I’m available on the
OCaml or Reason Discord servers or by email at
hezekiah.carty@elastic.co.
[Elastic] <https://www.elastic.co/>
[last hiring announcement]
<https://discuss.ocaml.org/t/filled-posting-is-no-longer-open-threat-research-engineer-job-endgame-us/1937>
Release of naboris 0.1.0 a simple http server
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/release-of-naboris-0-1-0-a-simple-http-server/4994/1>
Shawn McGinty announced
───────────────────────
<https://github.com/shawn-mcginty/naboris>
I could use input on the API and the documentation. Working on trying
to improve both at the moment.
The goal was to create a very simple library for building RESTful type
of web servers. Make it _very_ easy to manage handle request/response
lifecycle and sessions.
In my opinion this type of web server is a great entry point for new
developers looking to explore the OCaml/Reason world.
Recently I have fallen in love with OCaml and Reason, and as a mostly
web centered developer I've found this area quite lacking. I'm still
new to the language and eco system so any guidance would be highly
appreciated!
Yawar Amin replied
──────────────────
Wow! It seems we had much the same idea–OCaml/Reason more accessible
to web developers new to the ecosystem :-D I've been working on
something very similar: <https://github.com/yawaramin/re-web/>
Ulrik Strid said
────────────────
There is also opium <https://github.com/rgrinberg/opium>
And morph <https://github.com/reason-native-web/morph> that has
similar goals.
It would be nice if we could either create a shared core that all
could build from or collaborate on one.
esy@0.6.0 release
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-esy-0-6-0-release/5010/1>
Andrey Popp announced
─────────────────────
We've just released a new version of esy. You can install it with npm:
┌────
│ $ npm install -g esy@0.6.0
└────
[esy] is a package.json driven workflow for native development with
Reason/OCaml (and even C/C++). It provides per-project build
environments which are isolated from each other but share underlying
build caches so creating new environments is cheap.
While 0.6.0 is mainly about "quality-of-life" improvements it also got
few new features including a basic support for garbage collection of
unused build artifacts.
For more info see a [blog post] by @prometheansacrifice which
highlights important updates in 0.6.0.
[esy] <https://esy.sh>
[blog post] <https://esy.sh/blog/2020/01/12/0.6.0.html>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 53238 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-21 14:09 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-01-21 14:09 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 14 to 21,
2020.
Table of Contents
─────────────────
How does the compiler check for exhaustive pattern matching?
resto 0.2 released
opam 2.0.6 release
soupault: a static website generator based on HTML rewriting
Spin: Project scaffolding tool and set of templates for Reason and OCaml
Old CWN
How does the compiler check for exhaustive pattern matching?
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-does-the-compiler-check-for-exhaustive-pattern-matching/5013/1>
Dylan Irlbeck asked
───────────────────
Hi all. I'm relatively new to OCaml, and I was curious on how the
compiler is able to give a warning when a case list is non-exhaustive
- both from a high-level and, if possible, the implementation of this
check. I have some ideas about how one could do this, but none of my
ideas seem like they'd be nearly as efficient as the OCaml compiler
is.
gasche replied
──────────────
The canonical reference for exhaustivity-checking in OCaml is the
scientific publication
[Warnings for pattern matching] Luc Maranget 2007
The general idea is to consider all the patterns of a given
pattern-matching at once, generalize this structure to a "matrix" of
patterns (matching on several values in parallel), and devise an
algorithm to "explore" these pattern matrices in such a way that you
eventually tell if a given pattern-matrix is exhaustive, or can
propose a counter-example.
(I guess we should write a high-level/accessible blog post about
this.)
[Warnings for pattern matching]
<http://moscova.inria.fr/~maranget/papers/warn/index.html>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/1>
Raphaël Proust announced
────────────────────────
On behalf on Nomadic Labs, I'm happy to announce the release of
version 0.2 of `resto', a library to create type-safe HTTP/JSON
services.
The library is available through opam (`opam install resto'),
distributed under LGPL, and hosted on
<https://gitlab.com/nomadic-labs/resto>.
`resto' was previously released as `ocplib-resto' maintained by
OCamlPro. The project is now maintained by Nomadic Labs.
Along with many bugfixes and a few added features, the main change of
this release is that the library is split into multiple packages with
fine-grained dependencies.
opam 2.0.6 release
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-0-6-release/5038/1>
R. Boujbel announced
────────────────────
We are pleased to announce the minor release of [opam 2.0.6].
This new version contains mainly build update & fixes. You can find
more information in this [blog post].
_opam is a source-based package manager for OCaml. It supports
multiple simultaneous compiler installations, flexible package
constraints, and a Git-friendly development workflow._
[opam 2.0.6] <https://github.com/ocaml/opam/releases/tag/2.0.6>
[blog post] <https://opam.ocaml.org/blog/opam-2-0-6>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/11>
Daniil Baturin announced
────────────────────────
soupault 1.8.0 is [released] along with Lua-ML 0.9.1.
Lua-ML now raises `Failure' when Lua code execution fails. There's
much room for improvement in that area, for now I've just done
something that is better than just displaying errors on stderr but
otherwise allowing syntax and runtime errors pass silently.
If you have any ideas how perfect interpreter error reporting _should_
work, please share!
As of improvements in soupault itself, there's now:
• A way for plugins to specify their minimum supported soupault
version like `Plugin.require_version("1.8.0")'
• `TARGET_DIR' environment variable and `target_dir' Lua global that
contains the directory where the rendered page will be written, to
make it easier for plugins/scripts to place processed assets
together with pages.
• "Build profiles": if you add `profile = "production"' or similar to
widget config, that widget will be ignored unless you run `soupault
--profile production'.
• A bunch of new utility functions for plugins.
[released] <https://soupault.neocities.org/blog/soupault-1.8.0-release/>
Spin: Project scaffolding tool and set of templates for Reason and OCaml
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/spin-project-scaffolding-tool-and-set-of-templates-for-reason-and-ocaml/5047/1>
Mohamed Elsharnouby announced
─────────────────────────────
<https://github.com/tmattio/spin>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18137 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-28 10:54 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-01-28 10:54 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 8910 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 21 to 28,
2020.
Table of Contents
─────────────────
New release of Menhir (20200123)
Ocaml cross compiler?
Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
Proper way to allocate an OCaml string from C code in OCaml 4.10?
OCaml 4.10.0, second beta
Old CWN
New release of Menhir (20200123)
════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00040.html>
François Pottier announced
──────────────────────────
It is my pleasure to announce a new release of Menhir, the LR(1)
parser generator.
┌────
│ opam update
│ opam install menhir
│ opam install coq-menhirlib # if you wish to use menhir --coq
└────
There are no new features, only a significant change in the manner in
which Menhir is built:
• Menhir is now built and installed by dune. This should make life
easier for Menhir's developers: in particular, `make test' and `make
speed' can be run straight away and do not requiring installing
Menhir first. This should also make compilation much faster on
multi-core machines. (Contributed by Nicolás Ojeda Bär, to whom many
thanks are due.)
• There used to be a distinction between two slightly different ways
of installing Menhir, namely with and without `ocamlfind'. This
distinction disappears. The command line switch
`--suggest-ocamlfind' is deprecated and causes Menhir to print
`false'.
We hope that these changes do not break any of the code that relies on
Menhir today. Please report any problems that you might
encounter. Happy hacking!
Ocaml cross compiler?
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-cross-compiler/1494/7>
Deep in this thread, Dmitry Ponyatov asked
──────────────────────────────────────────
What about embedded targets like Cortex-M (STM32F3/F4)? How much
memory should it have to have to run OCaml-compiled programs?
Ivan Gotovchits replied
───────────────────────
You may find this [page] interesting. To summarize, with _a lot of
work_ you can make a subset of OCaml programs runnable on a
microcontroller. You will also need to rewrite OCaml's runtime and
develop a new GC for it.
In real life, no, you can't run OCaml on a microcontroller. You need
at least a couple of megabytes of normal RAM with MMU.
[page] <http://www.algo-prog.info/ocapic/web/index.php?id=ocapic>
Ivan Gotovchits then added
──────────────────────────
Hmm, found this [project], that is also quite relevant to you, it is
quite alive, so maybe you have chances :)
[project] <https://github.com/stevenvar/OMicroB>
Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/two-master-internship-proposals-to-explore-social-and-technical-aspects-of-the-creation-of-the-ocaml-and-coq-platforms/5073/1>
Théo Zimmermann announced
─────────────────────────
We are looking for candidates for the following two internships
intended to prefigure the creation of the OCaml and Coq platforms:
• a first internship is focused on exploring technical aspects:
<https://www.irif.fr/_media/users/theo/internship_proposal_platform_tech.pdf>
• a second internship is focused on exploring social and policy
aspects:
<https://www.irif.fr/_media/users/theo/internship_proposal_platform_social.pdf>
Please feel free to forward this announcement. Interested students
should send their resume and cover letter at
[yrg@irif.fr](<mailto:yrg@irif.fr>) and
[theo@irif.fr](<mailto:theo@irif.fr>).
Yann Régis-Gianas (Inria, IRIF, OCaml Foundation) and Théo Zimmermann
(Inria, IRIF, Coq development team)
Proper way to allocate an OCaml string from C code in OCaml 4.10?
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/proper-way-to-allocate-an-ocaml-string-from-c-code-in-ocaml-4-10/5075/1>
Rwmjones asked
──────────────
Previously to allocate a string with explicit length (ie. one which
may contain \0 characters) in C code we have used:
┌────
│ strv = caml_alloc_string (count);
│ memcpy (String_val (strv), str, count);
└────
In OCaml 4.10 this doesn't compile because String_val returns a `const
char *'.
I could change String_val to Bytes_val, but that feels wrong. The
runtime seems to use `&Byte_u (strv, 0)'.
It's a shame there's not a caml_copy_string_len function, but what is
the proper way to do this for OCaml 4.10+, especially a way that won't
break in future and will be compatible with multicore?
yallop suggested
────────────────
You can use [`caml_alloc_initialized_string']:
┌────
│ CAMLextern value caml_alloc_initialized_string (mlsize_t len, const char *);
└────
[`caml_alloc_initialized_string']
<https://github.com/ocaml/ocaml/blob/d408e58ea15ec890a2c6d98441d261db51a6735d/runtime/caml/alloc.h#L38~>
OCaml 4.10.0, second beta
═════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-second-beta/5083/1>
octachron announced
───────────────────
The release of OCaml 4.10.0 is near. We have released a second beta
version to help you adapt your softwares and libraries to the new
features ahead of the release.
This new beta contains an update to the internal runtime API that
should make it easier to maintain compatibility across version for
expert users; and a small fix for the analysis of recursive values.
The source code is available at these addresses:
<https://github.com/ocaml/ocaml/archive/4.10.0+beta2.tar.gz>
<https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta2.tar.gz>
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these:
• afl
• flambda
• fp
• fp+flambda
For a better experience, you can use the opam alpha repository
provided by:
┌────
│ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
└────
This repository contains a handful of temporary patched packages, that
you can use while waiting for the packages to be properly patched.
This repository should not be used in production and you probably want
to install it only for the beta switch.
We want to know about all bugs. Please report them here:
<https://github.com/ocaml/ocaml/issues>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 21596 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-04 8:47 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-02-04 8:47 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 16468 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 28 to
February 04, 2020.
Table of Contents
─────────────────
Multicore OCaml: January 2020 update
Use Case for Ephemerons?
`json-data-encoding' version 0.8 (was `ocplib-json-typed')
Developer position at Abacus Medicine, Copenhagen
Camlp5 version 7.11 release (4.10 compatibility)
Old CWN
Multicore OCaml: January 2020 update
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the January 2020 news update from the Multicore OCaml team!
We're going to summarise our activites monthly to highlight what we're
working on throughout this year. This update has kindly been assembled
by @shakthimaan and @kayceesrk.
The most common question we get is how to contribute to the overall
multicore effort. As I [noted last year], we are now in the process of
steadily upstreaming our efforts to mainline OCaml. Therefore, the
best way by far to contribute is to test for regressions or
opportunities for improvements in the patches that are outstanding in
the main OCaml repository.
A secondary benefit would be to review the PRs in the [multicore
repository], but those tend to be more difficult to evaluate
externally as they are being spotted as a result of stress testing at
the moment. A negative contribution would be to raise discussion of
orthogonal features or new project management mechanisms – this takes
time and effort to reply to, and the team has a very full plate
already now that the upstreaming has begun. We don't want to prevent
those discussions from happening of course, but would appreciate if
they were directed to the general OCaml bugtracker or another thread
on this forum.
We'll first go over the OCaml PRs and issues, then cover the multicore
repository and our Sandmark benchmarking infrastructure. A new
initiative to implement and test new parallel algorithms for Multicore
OCaml is also underway.
[noted last year]
<https://discuss.ocaml.org/t/multicore-prerequisite-patches-appearing-in-released-ocaml-compilers-now/4408>
[multicore repository]
<https://github.com/ocaml-multicore/ocaml-multicore/pulls>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
Eventlog is a proposal for a new tracing facility for OCaml runtime
that provides metrics and counters, and uses the Binary Trace Format
(CTF). The next step to get this merged is to incubate the tracing
features in separate runtime variant, so it can be selected at
application link time.
• [ocaml/ocaml#8984] Towards a new closure representation
A new layout for closures has been proposed for traversal by the
garbage collector without the use of a page table. This is very much
useful for Multicore OCaml and for performance improvements. The PR
is awaiting review from other developers, and can then be rebased
against trunk for testing and merge.
• [ocaml-multicore/ocaml-multicore#187] Better Safe Points
A patch to regularly poll for inter-domain interrupts to provide
better safe points is actively being reviewed. This is to ensure
that any pending interrupts are notified by the runtime system.
• Work is underway on improving the marshaling (runtime/extern.c) in
upstream OCaml to avoid using GC mark bits to represent visitedness,
and to use a hash table (addrmap) implementation.
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
[ocaml/ocaml#8984] <https://github.com/ocaml/ocaml/pull/8984>
[ocaml-multicore/ocaml-multicore#187]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/187>
◊ Completed
The following PRs have been merged to upstream OCaml trunk:
• [ocaml/ocaml#8713] Move C global variables to a dedicated structure
This PR moves the C global variables to a "domain state"
table. Every domain requires its own table of domain local
variables, and hence this is required for Multicore runtime.
This uncovered a number of [compatability issues] with the C header
files, which were all included in the recent OCaml 4.10.0+beta2
release via the next item.
• [ocaml/ocaml#9253] Move back `caml_*' to thematic headers
The `caml_*' definitions from runtime/caml/compatibility.h have been
moved to provide a compatible API for OCaml versions 4.04 to
4.10. This change is also useful for Multicore domains that have
their own state.
[ocaml/ocaml#8713] <https://github.com/ocaml/ocaml/pull/8713>
[compatability issues] <https://github.com/ocaml/ocaml/issues/9205>
[ocaml/ocaml#9253] <https://github.com/ocaml/ocaml/pull/9253>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The following PRs have been merged into the Multicore OCaml trees:
• [ocaml-multicore/ocaml-multicore#275] Fix lazy behaviour for
Multicore
A `caml_obj_forward_lazy()' function is implemented to handle lazy
values in Multicore Ocaml.
• [ocaml-multicore/ocaml-multicore#269] Move from a global
`pools_to_rescan' to a domain-local one
During stress testing, a segmentation fault occurred when a pool was
being rescanned while a domain was allocating in to it. The rescan
has now been moved to the domain local, and hence this situation
will not occur again.
• [ocaml-multicore/ocaml-multicore#268] Fix for a few space leaks
The space leaks that occurred during domain spawning and termination
when performing the stress tests have been fixed in this PR.
• [ocaml-multicore/ocaml-multicore#272] Fix for DWARF CFI for
non-allocating external calls
The entry to `caml_classify_float_unboxed' caused a corrupted
backtrace, and a fix that clearly specifies the boundary between
OCaml and C has been provided.
• An effort to implement a synchronized minor garbage collector for
Multicore OCaml is actively being researched and worked
upon. Benchmarking for a work-sharing parallel stop-the-world branch
against multicore trunk has been performed along with clearing
technical debt, handling race conditions, and fixing segmentation
faults. The C-API reversion changes have been tested and merged into
the stop-the-world minor GC branch for Multicore OCaml.
[ocaml-multicore/ocaml-multicore#275]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/275>
[ocaml-multicore/ocaml-multicore#269]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/269>
[ocaml-multicore/ocaml-multicore#268]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/268>
[ocaml-multicore/ocaml-multicore#272]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/272>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
• The [Sandmark] performance benchmarking infrastructure has been
improved for backfilling data, tracking branches and naming
benchmarks.
• Numerical parallel benchmarks have been added to the Multicore
compiler.
• An [Irmin] macro benchmark has been included in Sandmark. A test for
measuring Irmin's merge capabilities with Git as its filesystem is
being tested with different read and write rates.
• Work is also underway to implement parallel algorithms for N-body,
reverse-complement, k-nucleotide, binary-trees, fasta,
fannkuch-redux, regex-redux, Game of Life, RayTracing, Barnes Hut,
Count Graphs, SSSP and from the MultiMLton benchmarks to test on
Multicore OCaml.
[Sandmark] <http://bench2.ocamllabs.io/>
[Irmin] <https://irmin.org>
Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌
• A chapter on Parallel Programming in Multicore OCaml is being
written and an early draft will be made available to the community
for their feedback. It is based on Domains, with examples to
implement array sums, Pi approximation, and trapezoidal rules for
definite integrals.
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• CTF: Common Trace Format
• CFI: Call Frame Information
• DWARF: Debugging With Attributed Record Formats
• GC: Garbage Collector
• PR: Pull Request
• SSSP: Single Source Shortest Path
Nicolas Tollenaere asked
────────────────────────
If I may ask a question, I am curious about the status of integration
of effects into the type system. According to this page
<https://ocamlverse.github.io/content/future_ocaml.html#typed-algebraic-effects>,
original plan was to merge an untyped version of effect, before it was
decided to integrate them into the system. I have seen this
presentation of leo white on this matter
<https://www.janestreet.com/tech-talks/effective-programming/> along
with this one <https://www.youtube.com/watch?v=ibpUJmlEWi4> (from
2016). My understanding was that, at the time of the last
presentation, there was still some theoretical issues to be solved
(although the speaker did not seem too worried about finding some way
around eventually). I have no idea about the current status of the
project. Reading your post it seems that you are now in an integration
phase (PR reviews and all) that would imply that you're done with
(most) theoretical questions. But that could either mean that you are
integrating an untyped version of effects (and the type system is let
for future development) or that you have indeed settled on a
design. Which one is it ? Anyway, thanks for the post and the work in
general, this project seems awesome (even if I did not dive into it
too much until now)
Anil Madhavapeddy replied
─────────────────────────
Good question; our current focus in getting the runtime components
upstreamed (the "Domains" API) and some of the mechanisms that could
be used by an effect system. We haven't yet settled on a final design
for an effect extension to OCaml, but the general preference is to
skip integrating an untyped effect system if a typed version lands in
the right timescales. This will happen after all the runtime pieces
are upstreamed, which will allow everyone to use multicore parallelism
via the lower-level Domains API.
Use Case for Ephemerons?
════════════════════════
Archive: <https://discuss.ocaml.org/t/use-case-for-ephemerons/2838/3>
Continuing this old thread, Yawar Amin said
───────────────────────────────────────────
[Here's another use] (disclaimer: this is my project).
What's happening here is that I'm using an 'ephemeral cache' (i.e. a
cache backed by an ephemeron hash table, [here]) to store subscribers
to a 'topic', i.e. a pub-sub bus. You get a subscription token when
you subscribe to a topic, and part of that token is the cache key. The
cache is 'ephemeral' so as soon as the subscription token goes out of
scope, it and its corresponding subscription (concretely, the stream
and its push function) are automatically deleted from the cache.
Hence, there's no 'unsubscribe' or 'close topic' functionality–it's
assumed that you want to unsubscribe if you let the subscription token
go out of scope.
[Here's another use]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Topic.ml>
[here]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Cache.ml#L41>
`json-data-encoding' version 0.8 (was `ocplib-json-typed')
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-json-data-encoding-version-0-8-was-ocplib-json-typed/5095/1>
Raphaël Proust announced
────────────────────────
I'm happy to announce that Nomadic Labs is now in charge of the
development, maintenance and release of `json-data-encoding' – the
library previously known as `ocplib-json-typed'. Even though we are
changing to a more descriptive name, we are maintaining continuity of
version numbers. As a result, this is an announce for the version
`0.8'.
The library `json-data-encoding' lets you define encodings for a given
OCaml type, and use that encoding to encode values of that type into
JSON or decode JSON into values of that type. The library supports
multiple JSON backends: `Ezjsonm', `Yojson', native browser
representation (for `js_of_ocaml', via the package
`json-data-encoding-browser') and `BSON' (via the package
`json-data-encoding-bson').
It is available via `opam' (`opam install json-data-encoding') and
hosted on <https://gitlab.com/nomadic-labs/json-data-encoding/>
Changes from the version v0.7 include:
• extensive tests using `Crowbar' (adapted from similar tests on
`data-encoding' originally by @gasche)
• minor documentation improvements
• improved self documentation capabilities for unions' cases (work by
@smondet)
• improved schema equality (work by @rbardou)
Developer position at Abacus Medicine, Copenhagen
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/developer-position-at-abacus-medicine-copenhagen/5119/1>
mokn announced
──────────────
Abacus Medicine has an open developer position. We do parallel
distribution of medicine in EU and for that we have developed a system
to handle the trading. A part of this system is developed in OCaml.
Unfortunately the job description is only in danish, but we do accept
applications in english: [Job description]
[Job description]
<https://www.jobindex.dk/jobannonce/351439/software-developer>
Camlp5 version 7.11 release (4.10 compatibility)
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-camlp5-version-7-11-release-4-10-compatibility/5121/1>
Chet Murthy announced
─────────────────────
New release 7.11 of Camlp5. Compatible with all OCaml versions >=
4.00.0, latest OCaml version 4.10+beta2 included.
Main improvement: compatible with 4.10's blank module names and
generative functors.
Home page, including downloading and documentation at:
<https://camlp5.github.io/>
Enjoy!
N.B. I'm new to helping out with camlp5, so might have made some
mistakes; any users who find problems should contact me either
directly, or (better) thru issues on
<https://github.com/camlp5/camlp5/releases> and I'll be sure to get
right on it.
N.B.#2: There are still lots of gaps between current Ocaml, and
Camlp5's support; I'm working on fixing that, and there'll soon be a
release that brings camlp5 as up-to-date as possible with Ocaml.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 29138 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-18 8:18 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-02-18 8:18 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 14952 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 11 to 18,
2020.
Table of Contents
─────────────────
Logical 0.3.0
OCaml 4.10.0, first release candidate
New release of Menhir, including bug fixes
First release of data-encoding, JSON and binary serialisation
Opam package popularity?
What's the OCaml equivalent for HLint?
New release of naboris 0.1.1
Category theory for Programmers book - OCaml flavor
Call for Speakers: Build Meetup New York April 2020
Old CWN
Logical 0.3.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-logical-0-3-0/5150/1>
Tóth Róbert announced
─────────────────────
I proud to announce that I published Logical 0.3.0 and it's available
in opam. I'm also not to proud to announce that I did a bunch of
breaking changes in this release. :D
During development of this release, I realized that I made the biggest
mistake I could do as a library maintainer, which is that I didn't use
my own library, so I made a bunch of stupid design mistakes, which I
hopefully fixed in this release.
Changelog:
• Added both_multi goal
• Removed set from the type system
• Moved type system to separate module
• Re-factored state to be a map instead of an association list
• Added bunch of examples to the bin folder
One of my main goal with Logical was to solve the puzzles that I found
in this entertaining article:
<https://xmonader.github.io/prolog/2018/12/21/solving-murder-prolog.html>
and it became a reality so hurray. Another important thing to mention
is that I can proudly say that Logical is capable of solving a mystery
murder, so it's at least a mystery murder complete
language/framework. :D
Future plans(0.4.0 release):
• I want to introduce conditions or validations (I need to find a good
name for it) on the variables, which would basically be a function,
which is run when the variable gets it's value, so it's possible to
assess if the value is a good one or not. I think this feature is
extremely general, flexible and powerful, so I have to be careful
how I implement it(if I will). :D It also means that implementing
negation in Logical will become a breeze, so that's it for being
negation free.
• I'm thinking of creating a Variable module, which will by more like
a syntactic sugar for creating variables. I'm not sure about this,
because this would make Goal.equal "obsolete".
• I will hide Base's datatypes behind ours, so the user don't have to
depend on base to use the library.
Let me know if you have any suggestion or comment about Logical.
Github: <https://github.com/StrykerKKD/Logical>
Docs: <https://strykerkkd.github.io/Logical>
OCaml 4.10.0, first release candidate
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-4-10-0-first-release-candidate/5137/2>
octachron announced
───────────────────
We have released a second release candidate to integrate a bug fix for
32-bit users of the new best-fit allocator:
<https://github.com/ocaml/ocaml/pull/9292>
The fix should be transparent for other users, the release is mostly
here to try to minimize the difference between the candidate and final
binaries.
New release of Menhir, including bug fixes
══════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-02/msg00023.html>
François Pottier announced
──────────────────────────
Dear users of OCaml & Menhir,
It is my pleasure to announce a new release of Menhir.
┌────
│ opam update
│ opam upgrade menhir
└────
This release fixes two bugs in our implementation of Pager's
algorithm. Menhir relies on this algorithm to build an LR automaton
and to decide which states can safely be merged, where "safely" means
"without creating unexplainable conflicts". One bug (which had been
known for a long time, but not fixed) would cause Menhir to sometimes
make an unsafe merge decision, thereby creating an unexplainable
conflict. The other bug (which had never been discovered until now)
would cause Menhir to sometimes miss a safe merge decision, thereby
creating an automaton with needlessly many states.
In summary, after upgrading to this version, you may find (in some
cases) that the parser produced by Menhir for your grammar has
changed. It may have slightly more or slightly fewer states than the
parser produced by previous versions of Menhir. Even in cases where
the parser hasn't changed, the numbering of the states can be
different.
Feedback is welcome.
Happy parsing,
François Pottier
francois.pottier@inria.fr
<http://cambium.inria.fr/~fpottier/>
2020/02/11
╌╌╌╌╌╌╌╌╌╌
• Re-implement Menhir's default algorithm for constructing LR(1)
automata, namely Pager's algorithm. This closes issue #21 (reported
by Andrej Bauer), a bug that would sometimes cause unexplainable
conflicts to appear, because states were merged too
aggressively. This also removes an unreported bug that would cause
the automaton to have too many states, because states were *not*
merged aggressively enough. In summary, the old and new construction
algorithms differ: in many cases, the resulting automaton is
unchanged, but in some cases, the automaton produced by the new
algorithm may have slightly more or slightly fewer states.
• Re-implement Menhir's algorithm for constructing automata in
`--no-pager' mode. In this (undocumented) mode, Menhir does not
merge any states, but allows itself to redirect a transition from a
state `s' to a *larger* state `s''. This method yields an automaton
whose states form a subset of the states of the canonical LR(1)
automaton. It usually has significantly fewer states than the
canonical automaton, and significantly more states than the
automaton produced by Pager's algorithm. The new construction method
removes an unreported bug that would cause the automaton to have too
many states. The automaton produced by the new algorithm will
usually have significantly fewer states than the automaton produced
by the previous algorithm.
• Re-implement Menhir's algorithms for constructing automata in
`--lalr' and `--canonical' modes. The previous algorithms were
correct, as far as we know, so the output of the new algorithms is
the same, up to a possible renumbering of the states. The new
algorithms are slightly faster.
• Increase the maximum length of a production, which used to be 127,
up to 1023. Display a polite error message if this length is
exceeded. (Problem reported by Andreas Abel.)
• The new switch `--timings-to <filename>' causes internal timing
information to be written to the file `<filename>'.
• A version of the library `fix' is now vendored (included) inside
Menhir. This should have no impact for end users, but implies that
`dune' 2.2.0 or later is required.
First release of data-encoding, JSON and binary serialisation
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-data-encoding-json-and-binary-serialisation/4444/8>
Raphaël Proust announced
────────────────────────
The newly released version (0.2) addresses this. All the binary
reading/writing primitives use `result' by default and have `_opt' and
`_exn' variants.
The JSON primitives are not yet changed because they rely on an
external library that has more idiosyncratic error management. (This
will eventually be fixed in a future version.)
Opam package popularity?
════════════════════════
Archive: <https://discuss.ocaml.org/t/opam-package-popularity/5159/1>
Chet Murthy asked
─────────────────
Is there someplace a database of opam packages and their popularity?
Obviously it'd be inaccurate, but it'd still be interesting to see
which packages are most-often downloaded via opam …..
Levi Roth replied
─────────────────
The listing at <https://opam.ocaml.org/packages/index-popularity.html>
has the download counts (I think for the latest month, not sure if
that means past 30 days or since the start of the current calendar
month) as title attributes on the table rows.
What's the OCaml equivalent for HLint?
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/whats-the-ocaml-equivalent-for-hlint/5167/1>
Fangyi Zhou asked
─────────────────
I've been using OCaml for quite a while and one thing I've been
looking for is a good linter, ideally something like the Haskell
[HLint].
I found [this] which seems quite old - latest release in 2012.
Sorry if this has been raised previously.
[HLint] <https://github.com/ndmitchell/hlint>
[this] <http://mascot.x9c.fr/index.html>
"Aaron L. Zeng
──────────────
Something similar, but not as featureful, is [ppx_js_style]. It's
somewhat opinionated, but the checks aren't Jane Street-specific.
[ppx_js_style] <https://github.com/janestreet/ppx_js_style>
New release of naboris 0.1.1
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-new-release-of-naboris-0-1-1/5173/1>
Shawn McGinty announced
───────────────────────
<https://github.com/shawn-mcginty/naboris>
• *(much)* Better performance
• API improvements
Category theory for Programmers book - OCaml flavor
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/category-theory-for-programmers-book-ocaml-flavor/3905/4>
Anton Kochkov announced
───────────────────────
Thanks to @Arul the book was finished, and now is available for
download here -
<https://github.com/hmemcpy/milewski-ctfp-pdf/releases/tag/v1.4.0-rc1>
Please, enjoy and report a feedback.
Call for Speakers: Build Meetup New York April 2020
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/call-for-speakers-build-meetup-new-york-april-2020/5174/1>
Jérémie Dimino announced
────────────────────────
On April 7th and 8th, [Jane Street], [Bloomberg] and [Google] will be
hosting a Build Meetup at the [Jane Street offices] in New York City.
As we begin shaping our schedule, we are reaching out to a number of
communities to find people who would like to participate in the
event. Speaker sign-ups are now live [here].
We are excited to announce that the keynote will be presented by the
authors of the research paper “[From Laptop to Lambda: Outsourcing
Everyday Jobs to Thousands of Transient Functional Containers]” which
examines the exciting possibilities for build through the use of cloud
functions.
The entire event will be themed around all things build and test:
Bazel, Buck, BuildStream, CMake, Dune, Goma, Pants, Recc and Remote
Execution. In addition to this, we are interested in the growing
surrounding ecosystems, such as editor integration and developer build
experience as a whole.
The meetup will run as follows: on day one, a series of talks will be
presented along with breakfast, lunch and refreshments. This will be
followed by an evening social at a nearby venue to continue the
discussions from throughout the day.
On the second day there will be an opportunity for broader community
collaboration and discussion during our all day code sprint.
We are looking for insightful and engaging talks and presentations on
topics focused around build systems. Have you worked tirelessly for
the past 6 months on a new feature for project foo you would like to
showcase? Have you and your team spent the last year integrating the
tool bar at your workplace? Do you have some comparisons to make
between qux and quux that the community could benefit from?
If so, we would love to [hear from you]!
We welcome proposals for talks across the entire ecosystem. Each talk
should ideally last 30 minutes, followed by time for questions.
Keep your eyes out for meetup registration information, which will be
sent separately over the next few weeks!
[Jane Street] <https://www.janestreet.com/>
[Bloomberg] <https://www.techatbloomberg.com/>
[Google] <http://www.google.com/>
[Jane Street offices] <https://www.janestreet.com/contact-us/nyc/>
[here]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>
[From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of
Transient Functional Containers]
<http://stanford.edu/~sadjad/gg-paper.pdf>
[hear from you]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 28180 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-25 8:51 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-02-25 8:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 6517 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 18 to 25,
2020.
Table of Contents
─────────────────
Dune 2.3.0
What's the OCaml equivalent for HLint?
Training Sessions for "Expert OCaml" in Paris
OCaml 4.10 released
Old CWN
Dune 2.3.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-3-0/5184/1>
Rudi Grinberg announced
───────────────────────
On behalf of the dune team, I'm proud to announce the 2.3.0 release of
dune. This release is particularly relevant for users of coq that use
dune to build their theories, developers of coq that use dune to build
their favorite theorem prover. I'd like to thank @ejgallego for all
the hard work to improve dune in this regard.
I'd also like to point out the `(strict_package_deps)' option that is
now available in project files. This option will now ask dune to
validate the package dependencies specified in the `package' stanzas
in your dune-project files.
Here's the full change list, and as always, happy hacking!
2.3.0 (15/02/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Improve validation and error handling of arguments to `dune init'
(#3103, fixes #3046, @shonfeder)
• `dune init exec NAME' now uses the `NAME' argument for private
modules (#3103, fixes #3088, @shonfeder)
• Avoid linear walk to detect children, this should greatly improve
performance when a target has a large number of dependencies (#2959,
@ejgallego, @aalekseyev, @Armael)
• [coq] Add `(boot)' option to `(coq.theories)' to enable bootstrap of
Coq's stdlib (#3096, @ejgallego)
• [coq] Deprecate `public_name' field in favour of `package' (#2087,
@ejgallego)
• Better error reporting for "data only" and "vendored" dirs. Using
these with anything else than a strict subdirectory or `*' will
raise an error. The previous behavior was to just do nothing (#3056,
fixes #3019, @voodoos)
• Fix bootstrap on bytecode only switches on windows or where `-j1' is
set. (#3112, @xclerc, @rgrinberg)
• Allow `enabled_if' fields in `executable(s)' stanzas (#3137, fixes
#1690 @voodoos)
• Do not fail if `ocamldep', `ocamlmklib', or `ocaml' are absent. Wait
for them to be used to fail (#3138, @rgrinberg)
• Introduce a `strict_package_deps' mode that verifies that
dependencies between packages in the workspace are specified
correctly. (@rgrinberg, #3117)
• Make sure the `@all' alias is defined when no `dune' file is present
in a directory (#2946, fix #2927, @diml)
What's the OCaml equivalent for HLint?
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/whats-the-ocaml-equivalent-for-hlint/5167/3>
Continuing this thread, Stéphane Lavergne said
──────────────────────────────────────────────
Aside from Mascot and `ppx_js_style', it seems that [ocp-lint] is
actively maintained by the folks at OcamlPro. I personally only use
`ocamlformat' so I can't vouch for it, but it seems promising.
[ocp-lint] <https://github.com/OCamlPro/typerex-lint>
Training Sessions for "Expert OCaml" in Paris
═════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-02/msg00032.html>
Laurène Gibaud announced
────────────────────────
OCamlPro organizes a cross-company training in French for developers
who already use OCaml. The "Expert OCaml" training mixes theory and
practice and 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.
When? The next session is scheduled for March 3-4, 2020, the second
will be on April 7-8, 2020.
Where? Paris 14, at our office
If interested, contact us at contact@ocamlpro.com or register on:
<http://www.ocamlpro.com/forms/preinscriptions-formation-ocaml/>. We
can also organize custom and on-site sessions upon request.
More info on: <http://www.ocamlpro.com/training-ocamlpro/>
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/1>
octachron announced
───────────────────
We have the pleasure of celebrating the birthday of Francis Ronalds by
announcing the release of OCaml version 4.10.0.
Some of the highlights in this release are:
• A new best-fit allocator for the major heap which reduces both GC
cost an memory usage.
• Some preliminary runtime work for OCaml multicore
• Immutable strings are now enforced at configuration time
• User-defined indexing operators for multidimensional arrays
• Coming soon: statmemprof, a new statistical memory profiler. The
external API will be release next version.
• Various improvements to the manual
• More precise exhaustiveness check for GADTs
• Many bug fixes
Merlin, the OCaml editor service, is not yet available for this
release. We will publish a follow-up announcement when Merlin is
ready.
This release is (or soon will be) available as a set of OPAM switches,
and as a source download here:
<https://caml.inria.fr/pub/distrib/ocaml-4.10/>
Editor note: please follow the archive link for the full changelog
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18280 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-03 8:00 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-03-03 8:00 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12736 bytes --]
Here is the latest OCaml Weekly News, for the week of February 25 to
March 03, 2020.
Table of Contents
─────────────────
OCaml 4.10 released
Summary of the Dune retreat 2020
Multicore OCaml: Feb 2020 update
Oplot 0.50
soupault: a static website generator based on HTML rewriting
Old CWN
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/4>
Contnuing this thread, Anil Madhavapeddy said
─────────────────────────────────────────────
Indeed, many thanks to everyone who leapt in to make 4.10 ready in
opam in such record time! Just a note that the CI Docker images are
now also rebuilt for x86_64, arm32/64 and ppc64le to reflect the 4.10
release, so feel free to start using
them. <https://hub.docker.com/r/ocaml/opam2/tags>
Summary of the Dune retreat 2020
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/summary-of-the-dune-retreat-2020/5224/1>
Jérémie Dimino announced
────────────────────────
We recently organised the second Dune retreat. If you'd like to see
what is happening in the Dune world at the moment, please find a
summary of what we discussed and work on in this blog post!
<https://dune.build/blog/dune-retreat-2020/>
Multicore OCaml: Feb 2020 update
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the February 2020 news update from the Multicore OCaml
team, spread across the UK, India, France and Switzerland! This
follows on from [last month's] update, and has been put together by
@shakthimaan and @kayceesrk.
The [release of OCaml 4.10.0] has successfully pushed out some
prerequisite features into the upstream compiler. Our work in
February has focussed on getting the multicore OCaml branch "feature
complete" with respect to the complete OCaml language, and doing
extensive benchmarking and stress testing to test our two minor heap
implementations.
To this end, a number of significant patches have been merged into the
[Multicore OCaml trees] that essentially provide complete coverage of
the language features. We encourage you to test the same for
regressions and provide any improvements or report shortcomings to
us. There are ongoing OCaml PRs and issues that are also under review,
and we hope to complete those for the 4.11 release cycle. A new set of
parallel benchmarks have been added to our [Sandmark benchmarking
suite] (live instance [here]), including enhancements to the build
setup.
[last month's]
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090>
[release of OCaml 4.10.0]
<https://discuss.ocaml.org/t/ocaml-4-10-released/5194>
[Multicore OCaml trees]
<https://github.com/ocaml-multicore/ocaml-multicore>
[Sandmark benchmarking suite] <https://github.com/ocaml-bench/sandmark>
[here] <http://bench2.ocamllabs.io>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Completed
The following PRs have been merged into Multicore OCaml:
• [ocaml-multicore/ocaml-multicore#281] Introduce `Forcing_tag' to fix
concurrency bug with lazy values
A `Forcing_tag' is used to implement lazy values to handle a
concurrency bug. It behaves like a locked bit, and any concurrent
access by a mutator will raise an exception on that domain.
• [ocaml-multicore/ocaml-multicore#282] Safepoints
A preliminary version of safe points has been merged into the
Multicore OCaml trees. [ocaml-multicore/ocaml-multicore#187] also
contains more discussion and background about how coverage can be
improved in future PRs.
• [ocaml-multicore/ocaml-multicore#285] Introduce an 'opportunistic'
major collection slice
An "opportunistic work credit" is implemented in this PR which forms
a basis for doing mark and sweep work while waiting to synchronise
with other domains.
• [ocaml-multicore/ocaml-multicore#286] Do fflush and variable args in
caml_gc_log
The caml_gc_log() function has been updated to ensure that `fflush'
is invoked only when GC logging is enabled.
• [ocaml-multicore/ocaml-multicore#287] Increase EVENT_BUF_SIZE
During debugging with event trace data it is useful to reduce the
buffer flush times, and hence the `EVENT_BUF_SIZE' has now been
increased.
• [ocaml-multicore/ocaml-multicore#288] Write barrier optimization
This PR closes the regression for the `chameneos_redux_lwt'
benchmarking in Sandmark by using `intnat' to avoid sign extensions
and cleans up `write_barrier' to improve overall performance.
• [ocaml-multicore/ocaml-multicore#290] Unify sweep budget to be in
word size
The PR updates the sweep work units to all be in word size. This is
to handle the differences between the budget for setup, sweep and
for large allocations in blocks.
[ocaml-multicore/ocaml-multicore#281]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/281>
[ocaml-multicore/ocaml-multicore#282]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/282>
[ocaml-multicore/ocaml-multicore#187]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/187>
[ocaml-multicore/ocaml-multicore#285]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/285>
[ocaml-multicore/ocaml-multicore#286]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/286>
[ocaml-multicore/ocaml-multicore#287]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/287>
[ocaml-multicore/ocaml-multicore#288]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/288>
[ocaml-multicore/ocaml-multicore#290]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/290>
◊ Ongoing
• A lot of work is ongoing for the implementation of a synchronised
minor garbage collector for Multicore OCaml, including benchmarking
for the stop-the-world (stw) branch. We will publish the results of
this in a future update, as we are assembling a currently
comprehensive evaluation of the runtime against the mainstream
runtime.
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
[Sandmark] now has support to run parallel benchmarks. We can also now
about GC latency measurements for both stock OCaml and Multicore OCaml
compiler.
• [ocaml-bench/sandmark#73] More parallel benchmarks
A number of parallel benchmarks such as N-body, Quick Sort and
matrix multiplication have now been added to Sandmark!
• [ocaml-bench/sandmark#76] Promote packages. Unbreak CI.
The Continuous Integration build can now execute after updating and
promoting packages in Sandmark.
• [ocaml-bench/sandmark#78] Add support for collecting information
about GC pausetimes on trunk
The PR now helps process the runtime log and produces a `.bench'
file that captures the GC pause times. This works on both stock
OCaml and in Multicore OCaml.
• [ocaml-bench/sandmark#86] Read and write Irmin benchmark
A test for measuring Irmin's merge capabilities with Git as its
filesystem is being tested with different read and write rates.
• A number of other parallel benchmarks like Merge sort,
Floyd-Warshall matrix, prime number generation, parallel map, filter
et. al. have been added to Sandmark.
[Sandmark] <http://bench2.ocamllabs.io/>
[ocaml-bench/sandmark#73]
<https://github.com/ocaml-bench/sandmark/pull/73>
[ocaml-bench/sandmark#76]
<https://github.com/ocaml-bench/sandmark/pull/76>
[ocaml-bench/sandmark#78]
<https://github.com/ocaml-bench/sandmark/pull/78>
[ocaml-bench/sandmark#86]
<https://github.com/ocaml-bench/sandmark/pull/86>
Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌
• Examples using domainslib and modifying Domains are currently being
worked upon for a chapter on Parallel Programming for Multicore
OCaml. We will release an early draft to the community for your
feedback.
OCaml
╌╌╌╌╌
One PR opened to OCaml this month, which fixes up the marshalling
scheme to be multicore compatible. The complete set of [upstream
multicore prerequisites] are labelled in the compiler issue tracker.
• [ocaml/ocaml#9293] Use addrmap hash table for marshaling
The hash table (addrmap) implementation from Multicore OCaml has
been ported to upstream OCaml to avoid using GC mark bits to
represent visitedness.
[upstream multicore prerequisites]
<https://github.com/ocaml/ocaml/labels/multicore-prerequisite>
[ocaml/ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
Acronyms
╌╌╌╌╌╌╌╌
• CTF: Common Trace Format
• CI: Continuous Integration
• GC: Garbage Collector
• PR: Pull Request
As always, many thanks to our fellow OCaml developers and users who
have reviewed our code, reported bugs or otherwise assisted this
month.
Oplot 0.50
══════════
Archive: <https://discuss.ocaml.org/t/ann-oplot-0-50/5235/1>
sanette announced
─────────────────
I'm happy to annouce the revival of the `oplot' library.
If you ever wanted to quickly draw the graph of an intriguing
mathematical function, animate it by varying a parameter, or explore a
3D surface, without leaving your favorite programming language, then
`oplot' is for you.
If you're familiar with LaTeX and want to produce nice mathematical
graphics decorated with LaTeX formulas, that you can view onscreen,
export to images or vector graphics (pdf, eps) then `oplot' is even
more for you!
• Installation: `opam install oplot'
• documentation:
<https://sanette.github.io/oplot/oplot/Oplot/index.html>
• source code, issues, etc: <https://github.com/sanette/oplot>
Drawing is hardware accelerated (opengl) thanks to the venerable
`ocamlsdl' and `lablgl' libraries. I'm glad they still work perfectly.
Happy plotting.
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/12>
Daniil Baturin announced
────────────────────────
[1.9.0] release is now available.
• `--index-only' option that makes soupault dump the site metadata to
JSON and stop at that
• Metadata extraction and index generation can now be limited to
specific pages/section/path regexes, just like widgets
• The `preprocess_element' widget now supports a list of selectors,
e.g. `selector = ["code", "pre code"]'.
• Plugin API now has functions for running external programs, and some
more element tree access functions.
• CSS selector parse errors are now handled gracefully ([lambdasoup
PR#31]).
• The `title' widget now correctly removes HTML tags from the supposed
title string and doesn't add extra whitespace (fixes by [Thomas
Letan]).
[1.9.0] <https://soupault.neocities.org/blog/soupault-1.9.0-release/>
[lambdasoup PR#31] <https://github.com/aantron/lambdasoup/pull/31>
[Thomas Letan] <https://soap.coffee/~lthms/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 25154 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-10 14:29 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-03-10 14:29 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 23566 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 03 to 10,
2020.
Table of Contents
─────────────────
Non opam workflows
First release of metapp
OCaml 4.10 released
Transept 0.1.0: Generalised Parser Combinators
Multicore OCaml: Feb 2020 update
owl 0.8.0 and 0.9.0 released
Parser combinators vs. parser preprocessors?
Dune 2.4.0
Tyxml 4.4.0
first release of oplsr: an OCaml wrapper to the pls R package - Partial Least Squares (PLS) regression
Old CWN
Non opam workflows
══════════════════
Archive: <https://discuss.ocaml.org/t/non-opam-workflows/5232/1>
Manas asked
───────────
Very recently, I learnt that there is a significant chunk of users in
the OCaml community that does not use opam to install packages. As a
small initiative to contribute to tooling, I want to ensure what I
build is compatible with these workflows - workflows I'm not familiar
with myself.
I'd love to learn more - what does it look like? How do you setup your
compiler, dune and merlin (and/or soon ocamllsp)? How do you configure
your editor to find them and what would make it easier to do so?
I'm told of Duniverse as one tool that being used in these non-opam
workflows. Are there any more popular ones out there?
Théo Zimmermann replied
───────────────────────
I am one of these people. I mostly rely on Nix, whose package
repository nixpkgs provides package sets for all (relatively recent)
versions of OCaml. These package sets are not generally as complete as
what you can find on opam, so it sometimes happens that I open a PR on
the nixpkgs repository to add a new package (and in the meantime I use
my local updated copy of the nixpkgs repo).
You can see the list of available OCaml packages at:
<https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=ocamlPackages>
(This is for the default OCaml version, currently 4.07 in
nixpkgs-unstable. Other package sets are called
`ocaml-ng.ocamlPackages_4_0X' but are not shown in this web search.)
Most OCaml packages are available at a single version in nixpkgs (even
though you can choose your version of OCaml). To gain more flexibility
on the exact version I use in one of my project, I am planning to test
Duniverse. At that point, I would rely on Duniverse for library
dependencies, but I would still rely on Nix to install OCaml, findlib,
Dune, Duniverse (I'll have to take care of packaging it), utop,
merlin, or ocamlformat.
Nix is pretty straightforward to use. You generally provide a
`default.nix' at the root of your repository, and it will list the
dependencies that you use. When you want to go develop your project,
you just enter a special shell (with the `nix-shell' command) and you
are in an environment where the tools you need are in `PATH' and the
libraries you need are in `OCAMLPATH'.
There's just one tool that I needed special configuration for:
`ocamlformat' (especially because some projects use it and some do
not). When I use it, my `default.nix' contains:
┌────
│ shellHook = ''
│ export OCAMLFORMAT_LOCATION=${ocamlformat}
│ '';
└────
which will export an environment variable when I enter the shell.
And my `.emacs' contains:
┌────
│ (setq ocamlformat-location (getenv "OCAMLFORMAT_LOCATION"))
│ (when (> (length ocamlformat-location) 0)
│ (add-to-list 'load-path (concat ocamlformat-location "/share/emacs/site-lisp"))
│ (require 'ocamlformat)
│ (add-hook 'tuareg-mode-hook
│ (lambda () (add-hook 'before-save-hook 'ocamlformat-before-save))))
└────
I want to ensure what I build is compatible with these
workflows
If you mean as a library author, then all you have to ensure is that
you use Dune as the build system (makes the Duniverse workflow better,
and makes it easier to package your library in nixpkgs,
cf. `buildDunePackage' documented at
<https://nixos.org/nixpkgs/manual/#sec-language-ocaml>).
Rwmjones also replied
─────────────────────
You might want to check out the Fedora OCaml packages.
Unfortunately I don't have a convenient way to link to the whole list,
but if you look at all the OCaml packages here:
<https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=ocaml>*
and then if you substitute the `ocaml-<packagename>' in two places in
this URL:
<https://src.fedoraproject.org/rpms/ocaml-re/blob/master/f/ocaml-re.spec>
(example showing `ocaml-re' package), you can see how we build and
package them in the `%prep', `%build' and `%install' sections.
And yes, please make sure your software doesn't depend on opam.
Building everything in your home directory is not suitable for
enterprise software distribution.
First release of metapp
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-metapp/5250/1>
Thierry Martinez announced
──────────────────────────
I am happy to announce the first release of `metapp', yet another
preprocessor for OCaml. Similarly to [`ppx_optcomp'], `metapp' is a
PPX rewriter. But instead of introducing a specific DSL for
preprocessor directives, `metapp' provides a `[%meta ...]' extension,
where the dots `...' are arbitrary OCaml expressions that are
substituted at compile-time by the AST nodes they evaluate into. These
expressions build AST nodes either by (anti-)quoting some code
directly, or by using `compiler-libs' ([`Parsetree'], [`Ast_helper'],
…).
In particular, this preprocessor is easy to use for conditional
compilation, and is an alternative to [`cppo'] and [`ppx_optcomp'].
┌────
│ let option_get o =
│ [%meta if Sys.ocaml_version >= "4.08.0" then
│ [%e Option.get o]
│ else
│ [%e match o with
│ | None -> invalid_arg "option_get"
│ | Some x -> x]]
└────
In this example, the code between `[%e ... ]' is "anti-quoted": it is
the code that is inserted (conditionally) in the rewritten module. Of
course, the anti-quoted code can contain itself some `[%meta ...]'
code. `[%meta ...]' can even itself contain other levels of `[%meta
...]' code for multi-stage programming.
An example of usage of `metapp' is the [`metaquot'] package, which
implements the same quoters as `ppx_tools.metaquot': `[%expr ...]',
`[%type: ...]', etc. These quoters are implemented by
meta-programming: the meta-code introspects `Parsetree.cmi' from
`compiler-libs' to generate the code matching the current OCaml
version.
[`ppx_optcomp'] <https://github.com/janestreet/ppx_optcomp>
[`Parsetree']
<https://caml.inria.fr/pub/docs/manual-ocaml/compilerlibref/Parsetree.html>
[`Ast_helper']
<https://caml.inria.fr/pub/docs/manual-ocaml/compilerlibref/Ast_helper.html>
[`cppo'] <https://github.com/ocaml-community/cppo>
[`metaquot'] <https://github.com/thierry-martinez/metaquot>
Raphaël Proust added
────────────────────
To potentially save a few second to the next readers:
<https://github.com/thierry-martinez/metapp> seems to be the repo
where it is hosted.
Thierry Martinez then said
──────────────────────────
Thanks, @raphael-proust! The package is also available via opam: `opam
install metapp' (and `metaquot' is available via opam as well).
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/5>
octachron continued this thread
───────────────────────────────
The Merlin team has just released a preview version of Merlin which is
compatible with 4.10.0 (Merlin is an editor service that provides
modern IDE features for OCaml) .
This is a preview version:
• the support for short-path is disabled
• only OCaml 4.10.0 is supported in this preview
It can be installed via opam with the usual
┌────
│ opam install merlin
└────
Transept 0.1.0: Generalised Parser Combinators
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-transept-0-1-0-generalised-parser-combinators/5262/1>
Didier Plaindoux announced
──────────────────────────
I’m happy to announce the first release of Transept an OCaml
implementation of generalized parsers combinators.
This implementation has been inspired by a 19 years old paper -
written by Daan Leijen and Erik Meijer - titled “Parsec: Direct Style
Monadic Parser Combinators For The Real World” [1]. The current
implementation provides basic combinators dedicated to char, chars
recognition but also conjunction, sequence, repetition and more. Since
the current design relies on the abstract definition of manipulated
element most of the parsers are generic and can be used with streams
of chars or something else.
Finally, with this library, I wanted to share my love of OCaml modules
🤗
Opam: <https://opam.ocaml.org/packages/transept/transept.0.1.0/>
[1]
<https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/parsec-paper-letter.pdf>
Didier Wenzek then said
───────────────────────
It good to see yet another parser combinator for OCaml, even if this
makes more difficult the choice of one of them. I believe this
highlights how well OCaml shines for this kind of applications where
both high-level expressiveness and performance matter.
[`angstrom'] is one the alternatives and provides a comparison with
others. It would be good to position `transept' here.
There is also a more recent article with a radically new approach: [A
Typed, Algebraic Approach to Parsing] by Neelakantan R. Krishnaswami
and Jeremy Yallop - PLDI 2019. This paper proposes a [library of
parser combinators] for context-free expressions, an algebraic
presentation of the context-free languages. The key points are
• the use of types to statically reject any language which cannot be
parsed unambiguously and linearly;
• the use of staging, with OcamlBER, to produce parsers which
performance are close to those of hand-written code.
[`angstrom'] <https://github.com/inhabitedtype/angstrom>
[A Typed, Algebraic Approach to Parsing]
<https://www.cl.cam.ac.uk/~nk480/parsing.pdf>
[library of parser combinators] <https://github.com/yallop/ocaml-asp/>
Multicore OCaml: Feb 2020 update
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227/3>
Continuing this thread, Rwmjones asked
──────────────────────────────────────
Hi Anil (or anyone!). Is there a place I can find more about breaking
changes that might be made to C extensions? As you may know we have a
lot of C code which interfaces with OCaml, both as ordinary extensions
written in C, but also embedding OCaml in C programs (although that's
much more rare), and I'd like a heads up about what's likely to
change.
Anil Madhavapeddy replied
─────────────────────────
Hi @rwmjones! In a nutshell: no breaking C changes. The longer version
is that we implemented two different minor collectors in order to
evaluate various tradeoffs systematically:
• a concurrent minor collector that requires a read barrier and some C
API changes in order to create more safe points
• a stop-the-world minor collector that doesn't require a read barrier
and no extra C API changes, but would probably cause longer pauses
The good news is that our STW collector scales up much better than we
expected (tested to 24 cores), and so our first domains patchset will
almost certainly use that version now. We expect to shift to a
concurrent (and possibly pauseless) collection algorithm at some
future point, but in terms of upstreaming it looks like we should be
able to delay any C API changes until after the first version of
multicore has landed.
Do you have any nice standalone candidate programs using the C FFI we
could add to Sandmark?
owl 0.8.0 and 0.9.0 released
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-owl-0-8-0-and-0-9-0-released/5281/1>
Marcello Seri announced
───────────────────────
We are happy to announce *two* new releases of `owl': a dedicated
system for scientific and engineering computing in OCaml.
Since our previous announcement in July last year, there has been an
[enormous amount of work] going on to cleanup and extend owl's
internals and its interfaces.
In this period we have been trying to release often and keep
disruption to a minimum. Owl 0.8.0 and 0.9.0 are exceptional in this
respect:
• `owl.0.8.0':
• the discrepancy between `owl-base' (pure ocaml) and `owl' (links
cblas/lapacke) interfaces started becoming a problem in few
places. In this release many interfaces have been unified and
reused. The algodiff module has undergone a similar
refactoring. Although most users should be shielded from these
changes, they may break existing code, requiring an upper bound on
owl and some localized updates. This should mostly boil down to
changes like
┌────
│ -module CGraph_D = Owl_computation_engine.Make_Graph (Owl_computation_cpu_device.Make (Dense.Ndarray.D))
│ +module CGraph_D = Owl_computation_engine.Make_Graph (Owl_computation_cpu_device.Make (Owl_algodiff_primal_ops.D))
└────
• this is the last edition supporting OCaml compiler versions <
4.10.0 (more on this later).
• `owl.0.9.0': the main difference between `0.8.0' and `0.9.0' is that
owl now requires OCaml 4.10.0. This release of OCaml introduces
*extended indexing operators*. With them we can now write things
like `x.%{0;3}' (for indexing) and `x.${[0:2];[2;4]}' (for slicing)
instead of the more cumbersome `x.%{[|0;3|]}' and
`x.${[[0:2];[2;4]]}'.
The project is thoroughly documented at [ocaml.xyz ] where you can
find multiple examples of use.
A lot of work has (and is) been going into improving the
documentation, you can find the results in the new [owl book]:
<https://ocaml.xyz/book/toc.html>. This is currently targeting the
development version of owl, so using `master' or `0.9.0' is the best
bet if you want to try the examples out.
One of the issue of the old documentation was that it was getting
stale very fast: the book is reusing some of the infrastructure of
RWO, so all examples get recompiled and retested continuously to
ensure their correctness.
As a final note, we would like to send a huge thank to the [OCaml
Software Foundation], see also the [announcement made on this forum],
which has given us some funding that will support a retreat of the
maintainers and a development sprint that will take place at the end
of March.
We meant to announce the retreat and sprint for some time now, but the
size and publicity of the event may depend on updates to the various
governmental and institutional recommendation in regards to COVID-19
spreading. If a public event will be possible, we will make a
separate announce on this forum.
We want to also thank all the contributors for the increasing number
of comments, fixes and discussions that are helping us shape the next
releases of owl.
The Owl Dev Team
[enormous amount of work]
<https://github.com/owlbarn/owl/blob/master/CHANGES.md>
[ocaml.xyz ] <http://ocaml.xyz>
[owl book] <https://ocaml.xyz/book/toc.html>
[OCaml Software Foundation] <http://ocaml-sf.org/>
[announcement made on this forum]
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476>
Parser combinators vs. parser preprocessors?
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/parser-combinators-vs-parser-preprocessors/5263/4>
Continuing this thread, yallop said
───────────────────────────────────
Gasche said:
Combinators also describe a grammar; they can build a
representation that is then processed. I think it would be
perfectly reasonable to provide combinators to describe a
L(AL)R grammar, and then a function from such a grammar to
a parsing automaton, along with the result of various
analyses. This would solve the “additional tooling”
problem of typical parser generators, and also the “lack
of conflict analysis” problem of typical parser combinator
libraries. But it may require support for staging for
performance reasons.
Readers of this thread may be interested in the [asp] (*algebraic
staged parsing*) library (also described in the [Transept post] linked
above), which is built on an approach along the lines @gasche
describes:
• combinators that describe a grammar (using context-free expressions)
• an analysis (formulated as a type system) that ensures deterministic
parsing
• staging to eliminate performance overhead
The interface is pretty standard, with combinators for alternation,
sequencing, etc., and performance is quite good (better than
`ocamlyacc' on our benchmarks).
There's a paper, [A typed algebraic approach to parsing], that
describes the design in more detail.
Chet_Murthy said:
Also, I’m personally a massive LL(1) (over LALR) bigot
Grammars built using `asp' are essentially LL(1). (The weasel word
"essentially" isn't hiding much here, but the paper has the details.)
[asp] <https://github.com/yallop/ocaml-asp/>
[Transept post]
<https://discuss.ocaml.org/t/ann-transept-0-1-0-generalised-parser-combinators/5262>
[A typed algebraic approach to parsing]
<https://www.cl.cam.ac.uk/~jdy22/papers/a-typed-algebraic-approach-to-parsing.pdf>
Dune 2.4.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-4-0/5288/1>
Rudi Grinberg announced
───────────────────────
On behalf of the dune team, I'm pleased to announce the release of
dune 2.4.0. This releases features support for [mdx], an interesting
take on the notebook paradigm by the RWO team. This release also
includes a crucial fix to polling mode which makes it usable in
environments with finite memory :slight_smile:.
Happy hacking!
[mdx] <https://github.com/realworldocaml/mdx>
2.4.0 (06/03/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Add `mdx' extension and stanza version 0.1 (#3094, @NathanReb)
• Allow to make Odoc warnings fatal. This is configured from the `(env
...)' stanza. (#3029, @Julow)
• Fix separate compilation of JS when findlib is not
installed. (#3177, @nojb)
• Add a `dune describe' command to obtain the topology of a dune
workspace, for projects such as ROTOR. (#3128, @diml)
• Add `plugin' linking mode for executables and the
`(embed_in_plugin_libraries ...)' field. (#3141, @nojb)
• Add an `%{ext_plugin}' variable (#3141, @nojb)
• Dune will no longer build shared objects for stubs if
`supports_shared_libraries' is false (#3225, fixes #3222,
@rgrinberg)
• Fix a memory leak in the file-watching mode (`dune build -w')
(#3220, @snowleopard and @aalekseyev)
Tyxml 4.4.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-tyxml-4-4-0/5290/1>
Gabriel Radanne announced
─────────────────────────
I have the pleasure to announce the release of [TyXML 4.4.0], with
special Reason support!
[TyXML] is a library for building statically correct HTML and SVG
documents. TyXML provides a set of combinators which use the OCaml
type system to ensure the validity of the HTML. TyXML is now a stable
library and this release comes with a few newly supported elements and
attributes (such as ARIA elements) and associated bug fixes. However,
the main novelty of this release is a long awaited feature: the
support for [Reason’s JSX syntax] in the brand new `tyxml-jsx'
package.
See the complete announcement for code examples and details:
<https://drup.github.io/2020/03/06/tyxml440/>
[TyXML 4.4.0] <https://github.com/ocsigen/tyxml/releases/tag/4.4.0>
[TyXML] <https://github.com/ocsigen/tyxml>
[Reason’s JSX syntax] <https://reasonml.github.io/docs/en/jsx.html>
first release of oplsr: an OCaml wrapper to the pls R package - Partial Least Squares (PLS) regression
══════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-oplsr-an-ocaml-wrapper-to-the-pls-r-package-partial-least-squares-pls-regression/5293/1>
UnixJunkie announced
────────────────────
It is my great pleasure to release one more hackish wrapper to use
some R package from within OCaml:
<https://github.com/UnixJunkie/oplsr>
For some background:
<https://en.wikipedia.org/wiki/Partial_least_squares_regression>
Cf. test.ml in the sources for a usage example.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 39431 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-17 11:04 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-03-17 11:04 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12110 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 10 to 17,
2020.
Table of Contents
─────────────────
Unicode 13.0.0 update for Uucd, Uucp, Uunf and Uuseg
Introducing dune describe
Introducing Model_quickcheck. Quickcheck for stateful, imperative code
Odig 0.0.5
Suggestions for ocaml documentation
Introducing Gopcaml mode - structural OCaml editing
Try OCaml 2.0 (beta)
jose 0.2.0
Old CWN
Unicode 13.0.0 update for Uucd, Uucp, Uunf and Uuseg
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/unicode-13-0-0-update-for-uucd-uucp-uunf-and-uuseg/5298/1>
Daniel Bünzli announced
───────────────────────
Unicode 13.0.0 was released on the 10th of march.
It adds 5390 characters to the standard including graphic symbols for
legacy computing. If you were looking for characters representing
seven-segment decimal digits, now you [have them]. For the curious,
the [encoding proposal] has the motivation and source of these new
symbols. For more information about all the other additions, see [this
page].
Accordingly the libraries mentioned at the end of this message had to
be updated, consult the individual release notes for details. Both
Uucd and Uucp are incompatible releases sinces new script and block
enumerants had to be added.
Uucp has a new Emoji module with the new emoji properties introduced
in 13.0.0 which are now used by Uuseg to improve emoji
segmentation. The overall compiled size of Uucp shrinked a bit; here
uucp.cmxs went from 7.8Mo to 4.6Mo. Further reduction can likely be
achieved with more work. Thanks to David Kaloper Meršinjak for helping
on this.
A periodic reminder, if Unicode still puzzles you, read an absolute
minimal Unicode introduction and OCaml Unicode tips on [this page]
(also available via `odig doc uucp').
Happy retro computing,
Daniel
P.S. The OCaml compiler [detected] an obsolete rule in the 13.0.0
update of the Unicode line breaking algorithm.
—
Uucd 13.0.0 Unicode character database decoder for OCaml.
<http://erratique.ch/software/uucd>
Uucp 13.0.0 Unicode character properties for OCaml.
<http://erratique.ch/software/uucp>
Uunf 13.0.0 Unicode text normalization for OCaml.
<http://erratique.ch/software/uunf>
Uuseg 13.0.0 Unicode text segmentation for OCaml.
<http://erratique.ch/software/uuseg>
[have them] <https://www.unicode.org/charts/PDF/U1FB00.pdf>
[encoding proposal]
<https://www.unicode.org/L2/L2019/19025-terminals-prop.pdf>
[this page]
<http://blog.unicode.org/2020/03/announcing-unicode-standard-version-130.html>
[this page] <https://erratique.ch/software/uucp/doc/unicode.html>
[detected]
<https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.html>
Introducing dune describe
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-dune-describe/5300/1>
Jérémie Dimino announced
────────────────────────
Just a quick post to introduce the new `dune describe' command in Dune
2.4.0. If you'd like to write a tool that needs to understand the
structure of a dune project, figure out where the cmt files are
located, etc…, this is the command to look at.
The command is not production ready yet, but the infrastructure is in
place. If you are interested in releasing tools that rely on it,
please let us know so that we can discuss what information you need
out of dune and also so that we can stabilise it.
<https://dune.build/blog/dune-describe/>
Introducing Model_quickcheck. Quickcheck for stateful, imperative code
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-model-quickcheck-quickcheck-for-stateful-imperative-code/5301/1>
suttonshire announced
─────────────────────
I'm sharing a small project I've been working on that I hope will be
interesting or useful to the community. [Model_quickcheck] is a
model-based testing system that allows you to validate the
"properties" of stateful, imperative OCaml programs. It's built on
Jane Street's Base_quickcheck.
I just started learning OCaml and one of the first projects I've been
working on is a user-space reliable transport protocol. Writing tests
for this system became unwieldy because I was trying to validate
certain properties of the protocol by thinking up very specific
sequences of actions that would invoke behaviors that relied on that
property. I got tired of it and got curious if there was a way to
generate these interesting sequences. My research turned up frameworks
like [QCSTM] and [PropEr] for state machine property-based
testing. This seemed to be exactly what I needed so I started building
something similar.
To use Model_quickcheck you specify a set of actions to apply to your
program, a model that describes the state of you program and a set of
predicates that define the properties of you system. The model is
hopefully a simpler representation of your system e.g. a map instead
of a key-value database, or a queue instead of a reliable network
protocol. Model_quickcheck then generates a random sequences of
actions applies them to your system and verifies the properties.
This has been an exciting and useful project. I've learned a bunch
about the Base library, Quickcheck, first class modules, and inline
tests. I'm just getting started, but I just wanted to share the
project with the community since I've learned a lot by lurking here.
[Model_quickcheck] <https://github.com/suttonshire/model_quickcheck>
[QCSTM] <https://github.com/jmid/qcstm>
[PropEr] <https://propertesting.com/book_state_machine_properties.html>
Odig 0.0.5
══════════
Archive: <https://discuss.ocaml.org/t/ann-odig-0-0-5/5304/1>
Daniel Bünzli announced
───────────────────────
`odig' has a new release. See the [release notes] for details.
Installation: `opam install ocaml-manual odig'
Tutorial: <https://erratique.ch/software/odig/doc/manual.html>
odig is a command line tool to lookup documentation of installed OCaml
packages. It shows package metadata, readmes, change logs, licenses,
cross-referenced `odoc' API documentation and manuals.
[release notes]
<https://github.com/b0-system/odig/blob/v0.0.5/CHANGES.md#v005-2019-03-11-la-forclaz-vs>
Suggestions for ocaml documentation
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504/50>
sanette announced
─────────────────
The "OCaml API", which is the documentation for the standard library,
is now complete for all versions 4.00–4.10, with a quick search field,
on the demo site:
<https://sanette.github.io/ocaml-api/>
Introducing Gopcaml mode - structural OCaml editing
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310/1>
Kiran Gopinathan announced
──────────────────────────
Hi all, I am pleased to announce the first release of Gopcaml-mode, a
new emacs library that aims to extend the existing OCaml editing
experience with structural editing capabilities.
A picture is worth a thousand words, so I'll cut to the chase, and
start with a few demonstrations:
Examples
╌╌╌╌╌╌╌╌
• AST-based code navigation - `C-M-n, C-M-p, C-M-u, C-M-d, C-M-f,
C-M-b'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_move_expression_example.gif>
• AST-based code transformation -`C-M-N, C-M-P, C-M-F, C-M-B'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_move_function_example.gif>
• Mark exp - `C-M-SPC'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_mark_sexp.gif>
• Extract expression into letdef - `C-c C-e'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_extraction_expressions.gif>
This is just a small sample of the features - a full listing is
provided at the project readme, which can be found at the [project
page].
[project page] <https://gitlab.com/gopiandcode/gopcaml-mode>
Notes
╌╌╌╌╌
This plugin is quite faithful to the OCaml specification and doesn't
reimplement a separate OCaml parser as some other plugins do - instead
I use the Ecaml package (which allows interfacing with Emacs from
OCaml code) to allow delegating to the OCaml parser (from
Ocaml-compiler-libs) directly.
It's in the process of being published to opam, and should be
available to download soon.
Try OCaml 2.0 (beta)
════════════════════
Archive: <https://discuss.ocaml.org/t/ann-try-ocaml-2-0-beta/5325/1>
Louis Gesbert announced
───────────────────────
OCamlPro is happy to announce the release of a new version of the
venerable [Try OCaml tool].
This tool allows you to quickly test OCaml snippets from anywhere,
directly from your browser. It's still in beta, so any issues or
comments are welcome below.
The new version is a complete refactor and redesign, based on the
backend of Learn-OCaml.
Original announcement:
<http://www.ocamlpro.com/2020/03/16/new-version-of-try-ocaml-in-beta/>
[Try OCaml tool] <https://try.ocamlpro.com>
jose 0.2.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-jose-0-2-0/5328/1>
Ulrik Strid announced
─────────────────────
I recently released a JavaScript Object Signing and Encryption library
to opam.
The main usecase for JOSE is JWT and JWK and is a comprehensive
library for both unlike some other libraries that currently exist in
the ecosystem. It uses mirage-crypto and supports RSA and OCT keys
currently and will support EC when mirage-crypto does.
I have not really implemented the encryption part yet but if anyone
needs JWE I'll gladly do the work or accept PRs.
The project was initially developed in Reason but I changed over to
OCaml at some point because of limitations in Reason at the time but
the repo still has the old name.
The docs can be found here:
<https://ulrikstrid.github.io/reason-jose/>
The repo can be found here:
<https://github.com/ulrikstrid/reason-jose/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 25657 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-24 9:31 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-03-24 9:31 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 13108 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 17 to 24,
2020.
Table of Contents
─────────────────
Luv 0.5.1 — a libuv binding — Windows support
resto 0.2 released
Bisect_ppx 2.0.0 — code coverage for OCaml with nice HTML reports
OCaml 4.09.1 released
Cookie 0.1.6
First release of lwt-pipeline
Using Ocaml as scripting language - piping sh commands
Old CWN
Luv 0.5.1 — a libuv binding — Windows support
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/luv-0-5-1-a-libuv-binding-windows-support/5334/1>
Anton Bachin announced
──────────────────────
I am pleased to announce release [0.5.1] of [**Luv**]. The main change
is the addition of Windows support, which makes Luv fully
cross-platform.
Accordingly, Luv 0.5.1 is now installable from both the main opam
repo, and from opam-repository-mingw.
<https://github.com/aantron/luv>
Also, as a side effect of the build system refactoring that was needed
to support Windows, Luv's build system no longer requires Python, and
supports cross-compilation.
The other noteworthy change in release 0.5.1 is a routine upgrade of
the vendored libuv to its latest version, [1.35.0].
[0.5.1] <https://github.com/aantron/luv/releases/tag/0.5.1>
[**Luv**] <https://github.com/aantron/luv>
[1.35.0] <https://github.com/libuv/libuv/releases/tag/v1.35.0>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/2>
Raphaël Proust announced
────────────────────────
Releases of `resto' 0.3 and 0.4
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
On behalf of Nomadic Labs, I'm happy to announce the release of
versions 0.3 and 0.4 of `resto'. Both versions are available through
`opam' and available on <https://gitlab.com/nomadic-labs/resto>.
The main change in 0.3 is to depend on `json-data-encoding', the fork
of the unmaintained `ocplib-json-typed'.
The changes of 0.4 are more invasive and require users changes:
• handle the new ``Gone' response code, and
• pass `gettimeofday' manually.
This last feature removes a dependency from `resto-cohttp' to `Unix',
and thus helps with use within a `js_of_ocaml' environment.
Bisect_ppx 2.0.0 — code coverage for OCaml with nice HTML reports
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bisect-ppx-2-0-0-code-coverage-for-ocaml-with-nice-html-reports/5338/1>
Anton Bachin announced
──────────────────────
I am pleased to announce [release 2.0.0] of [**Bisect_ppx**], the
OCaml coverage tool, which helps you see which parts of your code are
not being tested.
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>
This release is a major upgrade. The highlights are:
• Support for BuckleScript, js_of_ocaml, and esy. In other words,
Bisect_ppx now compiles to both native code and JS, and is published
in both opam and npm.
• The ability to [send reports automatically] from Travis and CircleCI
to Coveralls and Codecov. More integrations can be added over time.
• The awkward `(*BISECT-IGNORE*)' comments for excluding code from
instrumentation have been replaced by AST attributes like
`[@coverage off]'
(<https://github.com/aantron/bisect_ppx#Exclusion>).
• A new, more principled instrumentation algorithm.
• A new reporter command line based on [Cmdliner]. Run
`bisect-ppx-report --help' to get started with it.
• Syntax highlighting.
You are invited to peruse the all-new [README] for details :)
Several features have been deprecated; mostly command-line flags. You
can see the list in the *Deprecations* section of the
[changelog]. However, it may be easier to simply try using Bisect_ppx
as before – it will warn you if you use a deprecated flag. The
deprecated flags will be removed in Bisect_ppx 2.1.0, expected around
July 2020.
Happy testing!
<https://github.com/aantron/bisect_ppx>
[release 2.0.0]
<https://github.com/aantron/bisect_ppx/releases/tag/2.0.0>
[**Bisect_ppx**] <https://github.com/aantron/bisect_ppx>
[send reports automatically]
<https://github.com/aantron/bisect_ppx#Coveralls>
[Cmdliner] <https://erratique.ch/software/cmdliner/doc/Cmdliner>
[README] <https://github.com/aantron/bisect_ppx#readme>
[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.0.0>
OCaml 4.09.1 released
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-09-1-released/5341/1>
octachron announced
───────────────────
We have the pleasure of celebrating the anniversary of the first
spacewalk, conducted by Alexei Leonov, by announcing the release of
OCaml version 4.09.1. This is mainly a bug-fix release, with a
handful of configuration fixes and a GC fix backported from 4.10.0
. See the list of changes below for more details.
It is (or soon will be) available as a set of OPAM switches, and as a
source download here:
<https://github.com/ocaml/ocaml/archive/4.09.1.tar.gz>
Changes in 4.09.1:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9073], [#9120]: fix incorrect GC ratio multiplier when allocating
custom blocks with caml_alloc_custom_mem in runtime/custom.c (Markus
Mottl, review by Gabriel Scherer and Damien Doligez)
• [#8855], [#8858]: Links for tools not created when installing with
–disable-installing-byecode-programs (e.g. ocamldep.opt installed,
but ocamldep link not created) (David Allsopp, report by Thomas
Leonard)
• [#8947], [#9134], [#9302]: fix/improve support for the BFD library
(Sébastien Hinderer, review by Damien Doligez and David Allsopp)
• [#8953], [#8954]: Fix error submessages in the toplevel: do not
display dummy locations (Armaël Guéneau, review by Gabriel Scherer)
• [#8965], [#8979]: Alpine build failure caused by
check-parser-uptodate-or-warn.sh (Gabriel Scherer and David Allsopp,
report by Anton Kochkov)
• [#8985], [#8986]: fix generation of the primitives when the locale
collation is incompatible with C. (David Allsopp, review by Nicolás
Ojeda Bär, report by Sebastian Rasmussen)
• [#9050], [#9076]: install missing compilerlibs/ocamlmiddleend
archives (Gabriel Scherer, review by Florian Angeletti, report by
Olaf Hering)
• [#9144], [#9180]: multiple definitions of global variables in the C
runtime, causing problems with GCC 10.0 and possibly with other C
compilers (Xavier Leroy, report by Jürgen Reuter, review by Mark
Shinwell)
• [#9180]: pass -fno-common option to C compiler when available, so as
to detect problematic multiple definitions of global variables in
the C runtime (Xavier Leroy, review by Mark Shinwell)
• [#9128]: Fix a bug in bytecode mode which could lead to a
segmentation fault. The bug was caused by the fact that the atom
table shared a page with some bytecode. The fix makes sure both the
atom table and the minor heap have their own pages. (Jacques-Henri
Jourdan, review by Stephen Dolan, Xavier Leroy and Gabriel Scherer)
[#9073] <https://github.com/ocaml/ocaml/issues/9073>
[#9120] <https://github.com/ocaml/ocaml/issues/9120>
[#8855] <https://github.com/ocaml/ocaml/issues/8855>
[#8858] <https://github.com/ocaml/ocaml/issues/8858>
[#8947] <https://github.com/ocaml/ocaml/issues/8947>
[#9134] <https://github.com/ocaml/ocaml/issues/9134>
[#9302] <https://github.com/ocaml/ocaml/issues/9302>
[#8953] <https://github.com/ocaml/ocaml/issues/8953>
[#8954] <https://github.com/ocaml/ocaml/issues/8954>
[#8965] <https://github.com/ocaml/ocaml/issues/8965>
[#8979] <https://github.com/ocaml/ocaml/issues/8979>
[#8985] <https://github.com/ocaml/ocaml/issues/8985>
[#8986] <https://github.com/ocaml/ocaml/issues/8986>
[#9050] <https://github.com/ocaml/ocaml/issues/9050>
[#9076] <https://github.com/ocaml/ocaml/issues/9076>
[#9144] <https://github.com/ocaml/ocaml/issues/9144>
[#9180] <https://github.com/ocaml/ocaml/issues/9180>
[#9128] <https://github.com/ocaml/ocaml/issues/9128>
Cookie 0.1.6
════════════
Archive: <https://discuss.ocaml.org/t/ann-cookie-0-1-6/5346/1>
Ulrik Strid announced
─────────────────────
I recently released a cookie library. It can parse and create cookie
headers (`list((string, string)' which both Cohttp and Httpaf uses),
both `Set-Cookie' and `Cookie' so it works on both client and
server. It should be compliant with
<https://tools.ietf.org/html/rfc6265> and I have a pretty good test
suite for the parsing of cookies at least.
I couldn’t find a standalone library before this so I decided to
create one since I need it for my web framework, `Morph'.
The next step is to create and publish integrations with
[`ocaml-session'] which I have started.
• Repo: <https://github.com/ulrikstrid/ocaml-cookie>
• Docs: <https://ulrikstrid.github.io/ocaml-cookie>
[`ocaml-session'] <https://github.com/inhabitedtype/ocaml-session>
First release of lwt-pipeline
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-lwt-pipeline/4220/2>
Raphaël Proust announced
────────────────────────
A second release of `lwt-pipeline' (v0.2) is available through
`opam'. This new release makes no change to the code and only affects
the following:
• looser constraints on versions of `dune' dependency,
• tests,
• tests are executed in CI,
• minor documentation improvements.
Using Ocaml as scripting language - piping sh commands
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/using-ocaml-as-scripting-language-piping-sh-commands/5366/1>
Nicolas Tollenaere announced
────────────────────────────
I am trying to use ocaml to pipe the result of a command to another (I
would also be interested in feeding a string or a io stream into a sh
command). For example, I would like to do the equivalent of cat
foo.txt | grep thing, or pipe the result of one of my ocaml function
into grep.
Quite surprinsingly, neither the Stdlib or Batteries Sys modules
expose any way to handle the output of Sys.command directly (I would
have thought there would be optional input and output arguments
defaulting to stdin and stdout, or something along that). Batteries IO
module does expose a pipe function but it's not clear for me how it
would interact with the Sys module. Any ideas or other modules/package
I could use ?
Nicolás Ojeda Bär suggested
───────────────────────────
I think you may be interested by
<https://github.com/janestreet/shexp>.
Nicolas Tollenaere then said
────────────────────────────
@grayswandyr @nojb Thanks for the suggestion. I just found shcaml
<http://tov.github.io/shcaml/doc/> and I was going to give it a try,
do you know how it compares to shexp ?
David Chemouil replied
──────────────────────
AFAIK shcaml is unmaintained, but the approach is very nice indeed.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26314 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-31 9:55 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-03-31 9:55 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 30045 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 24 to 31,
2020.
Table of Contents
─────────────────
An In-Depth Look at OCaml’s New “Best-Fit” Garbage Collector Strategy
First release of Pp, a pretty-printing library
soupault: a static website generator based on HTML rewriting
routes: path based routing for web applications
Compiler Engineer at Mixtional Code in Darmstadt or anywhere else in Germany
tiny-httpd 0.5
Visual Studio Code plugin for OCaml
Dismas: a tool for automatically making cross-versions of opam packages
Multicore OCaml: March 2020 update
Old CWN
An In-Depth Look at OCaml’s New “Best-Fit” Garbage Collector Strategy
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/an-in-depth-look-at-ocaml-s-new-best-fit-garbage-collector-strategy/5370/1>
OCamlPro announced
──────────────────
The Garbage Collector is probably OCaml’s greatest unsung hero. Its
pragmatic approach allows us to allocate without much fear of
efficiency loss. We looked into its new "Best-fit" strategy and here
is what we learned!
[http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/]
[http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/]
<http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/>
First release of Pp, a pretty-printing library
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-pp-a-pretty-printing-library/5371/1>
Jérémie Dimino announced
────────────────────────
I'm happy to announce the first release of the [pp library]! This
library provides a lean alternative to the [Format module] of the
standard library. It uses the same comcepts of boxes and break hints,
however it defines its own algebra which some might find easier to
work with and reason about. I personally do :) The final rendering is
still done via a formatter which makes it easy to integrate `Pp' in
existing programs using `Format'.
We introduced this module in [Dune] to help improve the formatting of
messages printed in the terminal and it has been a success. The new
API is smaller, simpler and makes it easy for developers to do the
right thing. Once the `Pp' module of Dune was mature enough, we
decided to extract it into a separate library so that it could benefit
others.
The library itself is composed of a single `Pp' module and has no
dependencies. Its documentation is self-contained and no previous
knowledge is required to start using it, however the various guides
for the `Format' module such as [this one] should be applicable to
`Pp' as well.
If you have used `Format' before and like me found its API complicated
and difficult to use, I hope that you will find `Pp' nicer to work
with!
[pp library] <https://github.com/diml/pp>
[Format module]
<https://caml.inria.fr/pub/docs/manual-ocaml/libref/Format.html>
[Dune] <https://dune.build>
[this one] <http://caml.inria.fr/resources/doc/guides/format.en.html>
Josh Berdine then said
──────────────────────
Another great resource for understanding the core mental model of
Format is [Format Unraveled], although if I understand pp correctly
the discussion about Format not being document-based won't apply to
pp.
[Format Unraveled]
<https://hal.archives-ouvertes.fr/hal-01503081/file/format-unraveled.pdf>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/13>
Daniil Baturin announced
────────────────────────
[1.10.0] release is available.
Bug fixes:
• Files without extensions are handled correctly.
New features:
• Plugin discovery: if you save a plugin to `plugins/my-plugin.lua',
it's automatically loaded as a widget named
`my-plugin'. List of plugin directories is configurable.
• New plugin API functions: `HTMLget_tag_name', `HTML.select_any_of',
`HTML.select_all_of'.
• The `HTML' module is now "monadic": giving a nil to a function that
expects an element gives you a nil back, rather than cause a runtime
error.
[1.10.0] <https://soupault.neocities.org/blog/soupault-1.10-release>
routes: path based routing for web applications
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-routes-path-based-routing-for-web-applications/3624/6>
Anurag Soni announced
─────────────────────
[0.7.2] release is now available on opam. There have been quite a few
changes since the previous versions.
• Routes doesn't deal with HTTP methods anymore
• The internal implementation is now based around a trie like data
structure
• Routes have pretty printers
• sprintf style route printing is supported again
• Minimum supported OCaml version is now 4.05 (it used to be 4.06)
• There is a release available for bucklescript as well and it is
available to install via [npm].
[0.7.2] <http://opam.ocaml.org/packages/routes/>
[npm] <https://www.npmjs.com/package/@anuragsoni/routes>
Compiler Engineer at Mixtional Code in Darmstadt or anywhere else in Germany
════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/compiler-engineer-at-mixtional-code-in-darmstadt-or-anywhere-else-in-germany/5377/1>
Gerd Stolpmann announced
────────────────────────
Type of position:
• regular hire (no freelancers)
• full time
• work from home anywhere in Germany, or in the office in Darmstadt
• work for a small and highly skilled international team, located in
the US and Europe
• the team language is English
We are developing a compiler for a no-code platform that translates
our DSL to bytecode and/or WebAssembly. The language is largely of
functional type but is also able to manage state with a spreadsheet
model, allowing reactive programming without having to resort to
libraries. The language is statically typed using a Hindley-Milner
type checker. The compiler is primarily written in OCaml. Other
languages of our platform are Go, Elm, and Javascript.
We are looking for a compiler engineer with strong skills in all
relevant areas:
• fluent in OCaml or a similar language such as Haskell
• Understanding of the structure of the DSL, including syntax and
semantics
• Translation of FP languages to executable code
• Code optimization
• Graph algorithms
• Type checking
We are open to both juniors and seniors, and payment will be
accordingly. We are not so much interested in formal certifications
but rather in real practice, either from previous jobs, research
projects, or contributions to open source projects.
The no-code platform is being developed by engineers in Europe and the
US at various places, and we usually do not meet physically but in
video conferences. Working from home is very usual. We also get you a
desk in your home town if you prefer this. The compiler development is
lead by Gerd Stolpmann from Darmstadt.
Due to the strong connections to the US, video conferences will often
have to take place in evening hours, until around 7pm or 8pm.
Applications: please follow the "Apply" link at the official web page
describing the position: <https://rmx.mixtional.de/static/54657cda/>
Gerd Stolpmann
CEO of Mixtional Code GmbH (and OCaml hacker of the first hour)
Contact and company details: <https://www.mixtional.de/contact.html>
Sébastien Besnier asked
───────────────────────
I'm living in France, can I apply to the position (we are neighbors!)?
Gerd Stolpmann replied
──────────────────────
Well, I can (at the moment) only make contracts using German law and
for the social security system here. So, if you need a doctor you'd
have to travel… If my company was a bit bigger there would be the
option of opening a second site in France (even a very minimal one),
but the setup costs are so far too high (lawyers and accountants), and
it is too distracting for me to keep up with the fine points of the
system in France. Unfortunately, the EU is not that far that it is
super simple for an employer to hire anywhere in Europe. - Thanks for
asking.
tiny-httpd 0.5
══════════════
Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-5/5381/1>
Simon Cruanes announced
───────────────────────
I just released tiny-httpd 0.5 and the new tiny-httpd-camlzip, which
makes it possible to use `deflate' transparently for queries and
responses. The server has evolved quietly and is getting somewhat more
robust: I'm using it for an internal tool with big html pages (up to
several MB) and it's reasonably fast and doesn't seem to
memleak. There's also an improved `http_of_dir' to quickly and simply
serve a directory on an arbitrary port.
Previous announcement [here]
[here] <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727>
Visual Studio Code plugin for OCaml
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-preview-visual-studio-code-plugin-for-ocaml/5395/1>
Rudi Grinberg announced
───────────────────────
I'm proud to announce a preview release of an [VSC extension for
OCaml]. You can fetch and install this plugin directly from the
extension marketplace if you search for "OCaml Labs". The extension
isn't yet mature, but I believe that it offers a user experience
comparable to other VSC extensions for OCaml already. The plugin
should be used in conjunction with [ocaml-lsp]
The extension is for the OCaml "platform", which means that its scope
includes support for various tools used in OCaml development such as
dune, opam.
Bug reports & contributions are welcome. Happy hacking.
[VSC extension for OCaml]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[ocaml-lsp] <https://github.com/ocaml/ocaml-lsp>
Dismas: a tool for automatically making cross-versions of opam packages
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-prototype-dismas-a-tool-for-automatically-making-cross-versions-of-opam-packages/5404/1>
Daniil Baturin announced
────────────────────────
opam-cross-* are seriously lagging behind the official opam repository
and fdopen's opam-windows, not least because importing packages by
hand is a lot of work. I suppose at least a semi-automated process
could help those repos grow and stay in sync with the upstream much
faster.
I've made a prototype of a tool for "stealing" packages into
cross-repos. For obvious reasons it's called Dismas. You can find it
here: <https://github.com/dmbaturin/scripts/blob/master/dismas.ml>
Limitations:
• the code is a real mess for now
• only dune is supported by automatic build command adjustment
• it cannot handle cases when both native and cross-version of a
dependency are needed
However:
• For simple packages that use dune exclusively, it's completely
automated. I've ported bigstreamaf and angstrom to test it, and
cross-versions built just fine from its output, no editing was
needed.
• It automatically converts dependencies from foo to too-$toolchain
and removes dependencies and build steps only
needed for `with-test' and `with-doc'.
┌────
│ $ ./dismas.ml windows containers ~/devel/opam-repository/packages/containers/containers.2.8.1/opam
│ opam-version: "2.0"
│ maintainer: "simon.cruanes.2007@m4x.org"
│ synopsis:
│ "A modular, clean and powerful extension of the OCaml standard library"
│ build: [
│ ["dune" "build" "-p" "containers" "-j" jobs "-x" "windows"]
│ ]
│ depends: [
│ "ocaml-windows" {>= "4.03.0"}
│ "dune" {>= "1.1"}
│ "dune-configurator"
│ "seq-windows"
│ ]
│ depopts: ["base-unix" "base-threads"]
│ tags: ["stdlib" "containers" "iterators" "list" "heap" "queue"]
│ homepage: "https://github.com/c-cube/ocaml-containers/"
│ doc: "https://c-cube.github.io/ocaml-containers"
│ dev-repo: "git+https://github.com/c-cube/ocaml-containers.git"
│ bug-reports: "https://github.com/c-cube/ocaml-containers/issues/"
│ authors: "Simon Cruanes"
│ url {
│ src: "https://github.com/c-cube/ocaml-containers/archive/v2.8.1.tar.gz"
│ checksum: [
│ "md5=d84e09c5d0abc501aa17cd502e31a038"
│ "sha512=8b832f4ada6035e80d81be0cfb7bdffb695ec67d465ed6097a144019e2b8a8f909095e78019c3da2d8181cc3cd730cd48f7519e87d3162442562103b7f36aabb"
│ ]
│ }
│
│ $ ./dismas.ml windows containers ~/devel/opam-repository/packages/containers/containers.2.8.1/opam | diff
│ ~/devel/opam-repository/packages/containers/containers.2.8.1/opam -
│ 3c3,4
│ < synopsis: "A modular, clean and powerful extension of the OCaml standard library"
│ ---
│ > synopsis:
│ > "A modular, clean and powerful extension of the OCaml standard library"
│ 5,7c6
│ < ["dune" "build" "-p" name "-j" jobs]
│ < ["dune" "build" "@doc" "-p" name ] {with-doc}
│ < ["dune" "runtest" "-p" name "-j" jobs] {with-test}
│ ---
│ > ["dune" "build" "-p" "containers" "-j" jobs "-x" "windows"]
│ 10,11c9,10
│ < "ocaml" { >= "4.03.0" }
│ < "dune" { >= "1.1" }
│ ---
│ > "ocaml-windows" {>= "4.03.0"}
│ > "dune" {>= "1.1"}
│ 13,21c12
│ < "seq"
│ < "qtest" { with-test }
│ < "qcheck" { with-test }
│ < "ounit" { with-test }
│ < "iter" { with-test }
│ < "gen" { with-test }
│ < "uutf" { with-test }
│ < "mdx" { with-test & >= "1.5.0" & < "2.0.0" }
│ < "odoc" { with-doc }
│ ---
│ > "seq-windows"
│ 23,27c14,15
│ < depopts: [
│ < "base-unix"
│ < "base-threads"
│ < ]
│ < tags: [ "stdlib" "containers" "iterators" "list" "heap" "queue" ]
│ ---
│ > depopts: ["base-unix" "base-threads"]
│ > tags: ["stdlib" "containers" "iterators" "list" "heap" "queue"]
└────
Things to do:
• identify all packages that don't need cross-versions. Is cppo one of
them, for example?
• add support for cases when both native and cross versions are
needed. If menhir the only one?
• add support for other build systems. Do all of them work well with
`OCAMLFIND_TOOLCHAIN=windows` if the build setup is written
correctly?
Input from @toots and @pirbo is welcome.
Romain Beauxis then said
────────────────────────
That's a great initiative! Here are a couple of thoughts:
• For dune-based packages, things are indeed pretty
straight-forward. Finding out which dependencies need to be ported
as cross-dependency is indeed the part that's hard to automatize
• For other build systems, it's less clear to me how to
automatize. Maybe others have some thoughts about it.
• The CI system on opam-cross-windows is pretty good at building from
scratch and failing if some deps are missing so trial and error
there can be a great tool.
• Once solved for one cross situation, the problem of
cross-dependencies should be exactly the same for all other cross
environment (android, iOS)
I haven't looked at the tool very closely yet but I'd say a first
improvement would be to be able to track cross-dependencies resolution
and generate new version of the package using them and/or generate
other cross-compiled packages using them.
Anton Kochkov said
──────────────────
For automated pull requests, you might be interested in
<https://discuss.ocaml.org/t/dependabot-and-ocaml/4282>
Daniil Baturin then asked
─────────────────────────
I'm not sure if I understand the premise of dependabot. Why would
anyone hardcode specific dependency versions? Maybe it makes sense in
certain ecosystems that suffer from never-ending ecological disasters…
;)
In any case, most opam packages don't have a constraint on the upper
versions of their dependencies. Can dependabot use custom tracking
rules to check for presense of a newer version in the repo? My
thought was much simpler actually: track the commits in
opam-repository, run recently changed files through Dismas and send
pull requests to opam-cross-*
Yawar Amin replied
──────────────────
It's common practice nowadays to use semantic versioning and have
lockfiles for reproducible builds. Dependabot updates semantic version
ranges and lockfiles. See e.g.
• <https://github.com/thoughtbot/velveteen/pull/31/files>
• <https://github.com/mozilla/adr/pull/77/files>
Multicore OCaml: March 2020 update
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-march-2020-update/5406/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the March 2020 news update from the Multicore OCaml team!
This update has been assembled with @shakthimaan and @kayceesrk, as
with the [February] and [January] ones.
Our work this month was primarily focused on performance improvements
to the Multicore OCaml compiler and runtime, as part of a
comprehensive evaluation exercise. We continue to add additional
benchmarks to the Sandmark test suite. The eventlog tracing system and
the use of hash tables for marshaling in upstream OCaml are in
progress, and more PRs are being queued up for OCaml 4.11.0-dev as
well.
The biggest observable change for users trying the branch is that a
new GC (the "parallel minor gc") has been merged in preference to the
previous one ("the concurrent minor gc"). We will have the details in
longer form at a later stage, but the essential gist is that *the
parallel minor GC no longer requires a read barrier or changes to the
C API*. It may have slightly worse scalability properties at a very
high number of cores, but is roughly equivalent at up to 24 cores in
our evaluations. Given the vast usability improvement from not having
to port existing C FFI uses, we have decided to make the parallel
minor GC the default one for our first upstream runtime patches. The
concurrent minor GC follow at a later stage when we ramp up testing to
64-core+ machines. The [multicore opam remote] has been updated to
reflect these changes, for those who wish to try it out at home.
We are now at a stage where we are porting larger applications to
multicore. Thanks go to:
• @UnixJunkie who helped us integrate the Gram Matrix benchmark in
<https://github.com/ocaml-bench/sandmark/issues/99>
• @jhw has done extensive work towards supporting Systhreads in
<https://github.com/ocaml-multicore/ocaml-multicore/pull/240>. Systhreads
is currently disabled in multicore, leading to some popular packages
not compiling.
• @antron has been advising us on how best to port `Lwt_preemptive`
and the `Lwt_unix` modules to multicore, giving us a widely used IO
stack to test more applications against.
If you do have other suggestions for application that you think might
provide useful benchmarks, then please do get in touch with myself or
@kayceesrk.
Onto the details! The various ongoing and completed tasks for
Multicore OCaml are listed first, which is followed by the changes to
the Sandmark benchmarking infrastructure and ongoing PRs to upstream
OCaml.
[February]
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227>
[January]
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090>
[multicore opam remote]
<https://github.com/ocaml-multicore/multicore-opam>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore#240] Proposed implementation of
threads in terms of Domain and Atomic
A new implementation of the `Threads` library for use with the new
`Domain` and `Atomic` modules in Multicore OCaml has been
proposed. This builds Dune 2.4.0 which in turn makes it useful to
build other packages. This PR is open for review.
• [ocaml-multicore/safepoints-cmm-mach] Better safe points for OCaml
A newer implementation to insert safe points at the Cmm level is
being worked upon in this branch.
[ocaml-multicore/ocaml-multicore#240]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/240>
[ocaml-multicore/safepoints-cmm-mach]
<https://github.com/anmolsahoo25/ocaml-multicore/tree/safepoints-cmm-mach>
◊ Completed
The following PRs have been merged into Multicore OCaml:
• [ocaml-multicore/ocaml-multicore#303] Account correctly for
incremental mark budget
The patch correctly measures the incremental mark budget value, and
improves the maximum latency for the `menhir.ocamly` benchmark.
• [ocaml-multicore/ocaml-multicore#307] Put the phase change event in
the actual phase change code. The PR includes the
`major_gc/phase_change` event in the appropriate context.
• [ocaml-multicore/ocaml-multicore#309] Don't take all the full pools
in one go.
The code change selects one of the `global_full_pools` to try
sweeping it later, instead of adopting all of the full ones.
• [ocaml-multicore/ocaml-multicore#310] Statistics for the current
domain are more recent than other domains
The statistics (`minor_words`, `promoted_words`, `major_words`,
`minor_collections`) for the current domain are more recent, and are
used in the right context.
• [ocaml-multicore/ocaml-multicore#315] Writes in `caml_blit_fields`
should always use `caml_modify_field` to record `young_to_young`
pointers
The PR enforces that `caml_modify_field()` is always used to store
`young_to_young` pointers.
• [ocaml-multicore/ocaml-multicore#316] Fix bug with `Weak.blit`.
The ephemerons are allocated as marked, but, the keys or data can be
unmarked. The blit operations copy weak references from one
ephemeron to another without marking them. The patch marks the keys
that are blitted in order to keep the unreachable keys alive for
another major cycle.
• [ocaml-multicore/ocaml-multicore#317] Return early for 0 length blit
The PR forces a `CAMLreturn()` call if the blit length is zero in
`byterun/weak.c`.
• [ocaml-multicore/ocaml-multicore#320] Move `num_domains_running`
decrement
The `caml_domain_alone()` invocation needs to be used in the shared
heap teardown, and hence the `num_domains_running` decrement is
moved as the last operation for at least the `shared_heap` lockfree
fast paths.
[ocaml-multicore/ocaml-multicore#303]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/303>
[ocaml-multicore/ocaml-multicore#307]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/307>
[ocaml-multicore/ocaml-multicore#309]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/309>
[ocaml-multicore/ocaml-multicore#310]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/310>
[ocaml-multicore/ocaml-multicore#315]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/315>
[ocaml-multicore/ocaml-multicore#316]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/316>
[ocaml-multicore/ocaml-multicore#317]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/317>
[ocaml-multicore/ocaml-multicore#320]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/320>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
The [Sandmark] performance benchmarking test suite has had newer
benchmarks added, and work is underway to enhance its functionality.
• [ocaml-bench/sandmark#88] Add PingPong Multicore benchmark
The PingPong benchmark that uses producer and consumer queues has
now been included into Sandmark.
• [ocaml-bench/sandmark#98] Add the read/write Irmin benchmark
A basic read/write file performance benchmark for Irmin has been
added to Sandmark. You can vary the following input parameters:
number of branches, number of keys, percentage of reads and writes,
number of iterations, and the number of write operations.
• [ocaml-bench/sandmark#100] Add Gram Matrix benchmark
A request [ocaml-bench/sandmark#99] to include the Gram Matrix
initialization numerical benchmark was created. This is useful for
machine learning applications and is now available in the Sandmark
performance benchmark suite. The speedup
(sequential_time/multi_threaded_time) versus number of cores for
Multicore (Concurrent Minor Collector), Parmap and Parany is quite
significant and illustrated in the graph:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/2/20dc869a8dda1c815714a97e6a84f6f81c914cf4.png>
• [ocaml-bench/sandmark#103] Add depend target in Makefile
Sandmark now includes a `depend` target defined in the Makefile to
check that both `libgmp-dev` and `libdw-dev` packages are installed
and available on Ubuntu.
• [ocaml-bench/sandmark#90] More parallel benchmarks
An issue has been created to add more parallel benchmarks. We will
use this to keep track of the requests. Please feel free to add your
wish list of benchmarks!
[Sandmark] <https://github.com/ocaml-bench/sandmark>
[ocaml-bench/sandmark#88]
<https://github.com/ocaml-bench/sandmark/pull/88>
[ocaml-bench/sandmark#98]
<https://github.com/ocaml-bench/sandmark/pull/98>
[ocaml-bench/sandmark#100]
<https://github.com/ocaml-bench/sandmark/issues/100>
[ocaml-bench/sandmark#99]
<https://github.com/ocaml-bench/sandmark/issues/99>
[ocaml-bench/sandmark#103]
<https://github.com/ocaml-bench/sandmark/pull/103>
[ocaml-bench/sandmark#90]
<https://github.com/ocaml-bench/sandmark/issues/90>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
The configure script has now been be updated so that it can build on
Windows. Apart from this major change, a number of minor commits
have been made for the build and sanity checks. This PR is currently
under review.
• [ocaml/ocaml#9353] Reimplement output_value using a hash table to
detect sharing.
The [ocaml/ocaml#9293] "Use addrmap hash table for marshaling" PR
has been re-implemented using a hash table and bit vector, thanks to
@xavierleroy. This is a pre-requisite for Multicore OCaml that uses
a concurrent garbage collector.
As always, we thank the OCaml developers and users in the community
for their code reviews, support, and contribution to the project. From
OCaml Labs, stay safe and healthy out there!
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
[ocaml/ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
[ocaml/ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 43742 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-07 7:51 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-04-07 7:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 26459 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 31 to April
07, 2020.
Table of Contents
─────────────────
Making a music player in OCaml
The end of Camlp4
OCamlformat 0.14.0
ML Family Workshop 2020: Call for presentations
Announcing Sek, an efficient implementation of sequences
Announcing dune-deps: produces a project-centric dependency graph
OCaml Users and Developers Meeting 2020
Old CWN
Making a music player in OCaml
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/making-a-music-player-in-ocaml/5413/1>
Dracose asked
─────────────
I'm interested in making my own music player in OCaml so I wanted to
know whether there were any existing ones and/or examples of how to
make one. Bear in mind, I am interested in the actual logic of how to
read a music file (or a playlist) and listening to it, rather than the
front-end part of a music player. (My knowledge of OCaml is
intermediate)
Thomas Blanc suggested
──────────────────────
You want to check <https://github.com/savonet/liquidsoap>
Yotam Barnoy then said
──────────────────────
Wow @PatJ I didn't know about liquidsoap. I added it to
ocamlverse. This is what we have for the audio page now, in case it's
helpful to the OP: <https://ocamlverse.github.io/content/audio.html>
gndl also replied
─────────────────
I experimented with several solutions in the [playo] project. One of
the possible solutions is to use [ocaml-gstreamer]. If you find that
the gstreamer framework is too annoying (which I can understand :-),
you can use [ocaml-ffmpeg]. note however that, in the latest version
of ocaml-ffmpeg, the audio device output [no longer works]. To
overcome this drawback, you can use [ocaml-portaudio].
[playo] <https://github.com/gndl/playo>
[ocaml-gstreamer] <https://github.com/savonet/ocaml-gstreamer>
[ocaml-ffmpeg] <https://github.com/savonet/ocaml-ffmpeg>
[no longer works] <https://github.com/savonet/ocaml-ffmpeg/issues/32>
[ocaml-portaudio] <https://github.com/savonet/ocaml-portaudio>
The end of Camlp4
═════════════════
Archive: <https://discuss.ocaml.org/t/the-end-of-camlp4/4216/96>
Continuing this old thread, Chet Murthy announced
─────────────────────────────────────────────────
Perhaps worth mentioning briefly that for anybody who -wants- to
continue using camlp4, I'm (a) maintaining camlp5 and bringing it
up-to-date with everything in ocaml 4.10.0 that I can think of, and
(b) I'd be happy to help them port their dependency over to camlp5.
This is not to be construed as an argument for using camlp4/5.
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/1>
Etienne Millon announced
────────────────────────
On behalf of the development team, I'd like to announce the release of
ocamlformat version 0.14.0 :tada:.
Here are the main highlights of this release:
Support for OCaml 4.10
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This means both that it compiles and runs using this version, but also
that it can format 4.10-specific language features (`module _' and
multi-indices operators).
Preliminary support for invalid files
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
As OCamlformat operates on ASTs, it normally requires a valid input
file. This release adds a `--format-invalid-files' option to detect
invalid parts and print them verbatim. This feature is still
experimental.
Preserving more concrete syntax
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Starting with this release, OCamlformat is going to preserve more
concrete syntax. For example, `module M = functor (K : S) -> struct
end' and `module M (K : S) = struct end' are equivalent. In the past,
both variants would be formatted as the latter. Now, the original
syntax is preserved. In some cases, preserving was possible through
the means of an option: for example, to choice between `let%name x = e
in body' and `[%name let x = e in body]', was controlled by the
`extension-sugar' option. This option is now deprecated and
OCamlformat will now always preserve what was in the source file (this
was the default behaviour).
Similarly, it was possible to control how special characters are
escaped in string and character literals through the `escape-strings'
and `escape-chars' options. They are being deprecated and the only
possible behavior will be preserving the concrete syntax (as done by
default).
The reason for this change is that we feel that ocamlformat should be
just about formatting. The fact that this behavior was configurable is
in part due to the fact that it operates on OCaml ASTs, but end users
should not have to be surprised by their code being transformed on
reformatting.
In the future, we plan to extend that to other similar constructs,
such as using `(~/')~ or `begin~/~end', or spacing between module
items.
Placement of doc comments
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Placing doc comments `(** ... *)' is controlled by the `doc-comments'
configuration option. It is always possible to put them before the
item they refer to, and this is what the `doc-comments=before' option
does. The alternative `doc-comments=after' will try to do its best to
put them after, but in some cases it is not possible. For example, in
a variant type declaration, a doc-comment put immediately after will
be attached to the last constructor by documentation
tools. Ocamlformat needs to preserve the meaning of programs, so in
these cases, it will instead put the comment before. In the case of
`module' declarations, putting the comment after might not be very
useful if the corresponding module is very large.
This requires a complex rule to determine which comments will be put
before and which comments will be put after. So in this version, we
are deprecating this mechanism and replacing it with a simpler one
controlled by `doc-comments-val' that applies only to `val' and
`external' items. For these items, it is always possible to attach
documents before or after them. For all other items, like type or
module declarations, the doc comments will consistenly be put before.
Many bugs found by fuzzing
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We hooked ocamlformat to AFL, looking for programs that parse
correctly but trigger errors during formatting. This approach worked
very well and more than 20 logical bugs were found with this
technique.
Upgrading
╌╌╌╌╌╌╌╌╌
To upgrade from ocamlformat 0.13.0, one needs to upgrade the
ocamlformat binary and replace the `version' field in `.ocamlformat'
files by `0.14.0' and then:
• if you used `doc-comments=after', you can replace it by
`doc-comments-val=after'. This will move doc-comments on module
items except `val' and `external' ones.
• if you used `doc-comments=before', you can remove it as it is now
the default.
• if you set `escape-chars=preserve', `escape-strings=preserve', or
`extension-sugar=preserve' explicitly, you can
remove them safely (they were the default)
• if you used another value for one of these options (such as
`escape-strings=hexadecimal'), you will need to remove them as
well. This will not trigger a diff, but ocamlformat will not enforce
a particular concrete syntax for new code.
A note for new users
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We encourage you to try ocamlformat, that can be installed from opam
directly (`opam install ocamlformat'), but please remember that it is
still beta software. We added a [FAQ for new users] that should help
you decide if ocamlformat is the right choice for you.
[FAQ for new users]
<https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users>
Etienne Millon later added
──────────────────────────
This upgrade is likely to generate a huge diff on projects that use
the default profile, so I would like to expand a bit on the reason.
According to [the syntax rules used by the ocaml tools] (the ocaml
compilers, ocamldoc, odoc), it is always possible to put the
doc-comment before an item.
Some teams prefer to put the documentation after. But that is not
always possible. For example, `type t = A | B (** doc *)' will attach
the doc-comment to `B', not to `t'. The only way to attach the comment
to `t' is by putting the comment before.
Enter ocamlformat: doc-comment placement is controlled by an option
with two values, `before' or `after'. `before' will always place the
comment before. `after' determines if it is possible to put the
comment after, and if it is not, will put it before.
Some items cannot have comments after, like variant types (as
described above). But there is another reason not to put comments
after. In some cases, that can put the comment far from the thing it
is documenting. Considering modules, the following is nice:
┌────
│ module M = L.M
│ (** doc *)
└────
But this is not great is the structure is large:
┌────
│ module M = struct
│ ...
│ ...
│ end
│ (** doc *)
└────
To summarize, when ocamlformat is configured to put comments after, it
has to follow a complex heuristic to determine whether it has to
fallback to before. In the case of a module, it depends on its shape,
how many functor arguments are there, this kind of things (for various
reasons, we don't know how large something is going to be in advance,
so we have to look at its shape). The point is that it is complicated
to understand and explain, and that fixing it always makes it more
complex. Another aspect is that in the end, we want ocamlformat to be
pretty stable when it reaches 1.0.0, and complex rules are at odds
with this goal.
So, we have decided to simplify the rule: instead of looking deep in
the AST, we just look at the kind of item this is. For `val' and
`external' items, it is always possible to put the doc-comment after,
so we follow exactly what the configuration option says.
As a user of the default profile, what this means for you: for items
that are not `val' or `external', and considered "simple" by the
0.13.0 heuristic, doc-comments are going to move from after to before.
Based on these reasons, you will understand that `before' is always
simpler. You can opt into this by setting
`doc-comments-val=before'. This will cause an even larger diff as all
items are going to move before (that is: all items described just
above, plus `val' and `external' items), but the rule gets extremely
simple (everything is put before). It is possible that this option
will become the default in the future, but we have not decided this
yet (in this case, if you did not opt into it, you will see comments
on `val' and `external' items move at that time).
[the syntax rules used by the ocaml tools]
<https://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html#ss:ocamldoc-placement>
ML Family Workshop 2020: Call for presentations
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ml-family-workshop-2020-call-for-presentations/5441/1>
Leo White announced
───────────────────
We are happy to invite submissions to the ML Family Workshop 2020, to
be held during the ICFP conference week on Thursday, August 27th.
The ML family workshop warmly welcomes submission touching on the
programming languages traditionally seen as part of the "ML family"
(Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml,
etc.). The scope of the workshop includes all aspects of the design,
semantics, theory, application, implementation, and teaching of the
members of the ML family. We also encourage presentations from related
languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*,
Eff, ATS, etc), to exchange experience of further developing ML ideas.
Currently, the workshop is still scheduled to go ahead as planned in
Jersey City, however it is likely that the ML workshop will end up
being a virtual workshop this year. Either way provisions will be made
to allow speakers to present their work remotely.
See our detailed CFP online on the ICFP website:
<https://icfp20.sigplan.org/home/mlfamilyworkshop-2020>
Important dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Friday 15th May (any time zone): Abstract submission deadline
• Friday 26th June: Author notification
• Thursday 27th August: ML Family Workshop
Program committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Youyou Cong (Tokyo Institute of Technology)
• Gowtham Kaki (Purdue University)
• Neel Krishnaswami (University of Cambridge)
• Daan Leijen (Microsoft Research)
• Koko Muroya (Kyoto University)
• Atsushi Ohori (Tohoku University)
• Jonathan Protzenko (Microsoft Research)
• Gabriel Radanne (INRIA)
• Claudio Russo (Dfinity)
• Leo White (Jane Street) (Chair)
• Jeremy Yallop (University of Cambridge)
Submission details
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
See the online CFP for the details on the expected submission format.
Submissions must be uploaded to the workshop submission website
<https://ml2020.hotcrp.com/>
before the submission deadline.
Announcing Sek, an efficient implementation of sequences
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-sek-an-efficient-implementation-of-sequences/5442/1>
François Pottier announced
──────────────────────────
We are pleased to announce the first release of Sek, an OCaml library
that offers an efficient implementation of sequences.
The library offers both ephemeral (mutable) sequences and persistent
(immutable) sequences, and offers constant-time conversions between
these flavors.
It supports all of the standard operations on stacks, queues, deques
(e.g. push, pop at either end), catenable sequences (concat, split),
and random access sequences (get, set).
Data is stored internally in chunks (fixed-capacity arrays), which is
why this data structure is known as a chunK SEquence.
It is intended to achieve excellent time complexity and memory usage.
This is an initial release. The library has not been tested in
production, but has received extensive unit testing, via afl-fuzz and
ocaml+afl – which are remarkably effective tools, by the way!
This is work in progress; more features, such as iterators, will be
added in the future.
To install Sek, just type
┌────
│ opam update && opam install sek
└────
Documentation is [online].
Feedback is welcome!
Arthur Charguéraud
François Pottier
with contributions by Émilie Guermeur
[online] <http://cambium.inria.fr/~fpottier/sek/doc/sek/Sek/index.html>
Yaron Minsky asked and Fabian replied
─────────────────────────────────────
I’m particularly interested in how it compares to
Base.Sequence and Seq in the OCaml distribution, but
surely there are others as well.
This actually looks like an array/vector structure (supporting, among
other things, fast access to the nth element), so a comparison with
`CCVector', `CCFun_vec', `BatVect', `Clarity.Vector' etc. would be
more appropriate. The name is a bit unfortunate considering the naming
used in the general ecosystem.
Some time ago, I added some crude benchmarks to [containers'
benchsuite]. I'll see if I can add Sek when I find time.
[containers' benchsuite]
<https://github.com/c-cube/ocaml-containers/blob/d34b7588b028f3618cc44d3f4c6417295db586c8/benchs/run_benchs.ml#L112>
gasche said
───────────
I think it really is a sequence library in the sense that in maintains
an in-order sequence of items, and sequences can be joined/split
efficiently. It also provides logarithmic random access, but this is
probably not competitive with fixed-size arrays. It would be
comparable to "persistent vector" libraries, ropes, finger trees,
etc. The fact that the authors expose a Stack/Queue interface suggests
that it has also been tuned to perform reasonably well in this case.
It does not provide any delayed computation of items, so in that
regard it is not comparable to Sequence/Seq.
@charguer has designed similar datastructures in the past to represent
the work-queues of concurrent workers (you want at least a fast "push"
to add a new task and, when doing work-stealing, having a fast "split"
is convenient). See [Theory and Practice of Chunked Sequences], Umut
Acar, Arthur Charguéraud, Mike Rainey, 2014, and [A Work-Efficient
Algorithm for Parallel Unordered Depth-First Search].
As far as I know, the OCaml implementation just released has not been
tested/benchmarked for parallel algorithms. I would be curious to see
an experiment of parallel graph traversal with this structure and
Multicore-OCaml.
[Theory and Practice of Chunked Sequences]
<https://www.chargueraud.org/research/2014/chunkedseq/chunkedseq.pdf>
[A Work-Efficient Algorithm for Parallel Unordered Depth-First Search]
<https://www.chargueraud.org/research/2015/pdfs/pdfs_sc15.pdf>
Announcing dune-deps: produces a project-centric dependency graph
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-dune-deps-produces-a-project-centric-dependency-graph/5451/1>
Martin Jambon announced
───────────────────────
I'm happy to announce the availability of [dune-deps], a command-line
tool that scans a dune project and gathers the dependencies into a
graph. The output is in the dot format, supported by the `dot' command
from [graphviz].
It shows the dependencies between the following:
• libraries defined by the project,
• executables defined by the project,
• direct dependencies on external libraries.
Dependencies are extracted by parsing `dune' files. As an example,
here's what we obtain for the [sources of opam], which has over 50K
lines of code:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/f/f6213fa7fda52521c6782988155ab23b997dafb8.png>
The commands for this are:
┌────
│ # obtain the project's sources
│ $ git clone --depth=1 https://github.com/ocaml/opam.git
│
│ # extract dependencies and eliminate superfluous graph edges
│ $ dune-deps opam | tred > deps.dot
│
│ # render the graph
│ $ dot -Tpng deps.dot -o deps.png
└────
A suggestion is to include such graph in your project's `README.md'.
[dune-deps] <https://github.com/mjambon/dune-deps>
[graphviz] <https://www.graphviz.org/>
[sources of opam] <https://github.com/ocaml/opam>
OCaml Users and Developers Meeting 2020
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-users-and-developers-meeting-2020/5454/1>
Ivan Gotovchits announced
─────────────────────────
It is my pleasure to invite submissions to the OCaml Users and
Developers Workshop 2020, which is again co-located with ICFP and will
be held on Friday 28th August 2020 in Jersey City, NJ, USA.
The OCaml Users and Developers Workshop brings together the OCaml
community, including users of OCaml in industry, academia, hobbyists
and the free software community. Previous editions have been
co-located with ICFP since 2012 in Copenhagen, Boston, Gothenburg,
Nara, Oxford, St Louis and last year in Berlin, following OCaml
Meetings in Paris in 2010 and 2011.
Important Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• <https://ocaml.org/meetings/ocaml/2020/>
• <https://icfp20.sigplan.org/home/ocaml-2020>
• <https://ocaml2020.hotcrp.com/>
Important Dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Talk proposal submission deadline: May 8th, 2020, AoE
• Author Notification: June 26th, 2020
• OCaml Workshop: August 28th, 2020
Scope
╌╌╌╌╌
Presentations and discussions focus on the OCaml programming language
and its community. We aim to solicit talks on all aspects related to
improving the use or development of the language and its programming
environment, including, for example (but not limited to):
• compiler developments, new backends, runtime and architectures
• practical type system improvements, such as GADTs, first-class
modules, generic programming, or dependent types
• new library or application releases, and their design rationales
• tools and infrastructure services, and their enhancements
• prominent industrial or experimental uses of OCaml, or deployments
in unusual situations.
Presentations
╌╌╌╌╌╌╌╌╌╌╌╌╌
The workshop is an informal meeting with no formal proceedings. The
presentation material will be available online from the workshop
homepage. The presentations may be recorded and made available at a
later date.
The main presentation format is a workshop talk, traditionally around
20 minutes in length, plus question time, but we also have a poster
session during the workshop – this allows to present more diverse
work, and gives time for discussion. The program committee will decide
which presentations should be delivered as posters or talks.
Submission
╌╌╌╌╌╌╌╌╌╌
To submit a presentation, please register a description of the talk
(about 2 pages long) at
<https://ocaml2020.hotcrp.com/>
providing a clear statement of what will be provided by the
presentation: the problems that are addressed, the solutions or
methods that are proposed.
LaTeX-produced PDFs are a common and welcome submission format. For
accessibility purposes, we ask PDF submitters to also provide the
sources of their submission in a textual format, such as .tex
sources. Reviewers may read either the submitted PDF or the text
version.
ML family workshop
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The ML family workshop, held on the previous day, deals with general
issues of the ML-style programming and type systems, focuses on more
research-oriented work that is less specific to a language in
particular. There is an overlap between the two workshops, and we have
occasionally transferred presentations from one to the other in the
past. Authors who feel their submission fits both workshops are
encouraged to mention it at submission time and/or contact the Program
Chairs.
Program Committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Ivan Gotovchits, CMU, USA
• Florian Angeletti, INRIA, France
• Chris Casinghino, Draper Laboratory, USA
• Catherine Gasnier, Facebook, USA
• Rudi Grinberg, OCaml Labs, UK
• Oleg Kiselyov, Tohoku University, Japan
• Andreas Rossberg, Dfinity Stiftung, Germany
• Marcello Seri, University of Groningen, Netherlands
• Edwin Torok, Citrix, UK
• Leo White, Jane Street, USA
• Greta Yorsh, Jane Street, USA
• Sarah Zennou, Airbus, France
COVID-19 Notice
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While ICFP-20 [is still scheduled to be held as planned], chances are
high that it will be turned into a virtual conference. Which means a
wider audience and reduced (hopefully) fees. We will keep you posted.
[is still scheduled to be held as planned]
<https://icfp20.sigplan.org/home/icfp-2020>
Questions and contact
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Please send any questions to the chair: Ivan Gotovchits (ivg@ieee.org)
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 42475 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-14 7:28 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-04-14 7:28 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 8637 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 07 to 14,
2020.
Table of Contents
─────────────────
Announcing dune-deps: produces a project-centric dependency graph
OCamlformat 0.14.0
Dune 2.5.0
Old CWN
Announcing dune-deps: produces a project-centric dependency graph
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-dune-deps-produces-a-project-centric-dependency-graph/5451/3>
Martin Jambon announced
───────────────────────
Since the original announcement, I received some good feedback from
users working on large projects. Thank you!
The latest version released today is 1.2.0. It is already available on
opam-repository (thank you @kit-ty-kate). The changes since the
original release, besides bug fixes, include:
• Ability to select or ignore dune files and folders to scan. For
example, `dune-deps foo bar -x bar/test' uses all the dune files
found in folders `foo' and `bar' but will ignore `bar/test'. This is
useful for ignoring uninteresting parts of the project and for
ignoring parse errors (see bug [#4]).
• Executable name disambiguation. For example, private executables of
the same name like `foo/main' and `bar/baz/main' are now rendered as
`main<foo>' and `main<baz>' respectively instead of just `main'.
• Optional exclusion of all executables or all external libraries with
`--no-exe' and `--no-ext'.
• Ability to show only the dependencies and/or the reverse
dependencies of selected libraries. See below.
Whole-project graphs for large projects tend to be unreadable. To deal
with that, I added support for an "hourglass view" (⌛) option for
showing only the dependencies and reverse dependencies of a component
of interest.
The following is obtained with `-h opam-client' on the opam project:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/6/66098faac9fd6681e3c0f4fe357aef8ff34bcaf2.png>
Please [let us know] if this works for your favorite projects! The
source code of dune-deps makes it somewhat easier now to experiment
with new strategies for eliminating nodes. See the `Filter' and
`Filterable' modules.
Check out `dune-deps --help' for detailed documentation on the
options.
[#4] <https://github.com/mjambon/dune-deps/issues/4>
[let us know] <https://github.com/mjambon/dune-deps/issues>
Sean Grove said and Martin Jambon replied
─────────────────────────────────────────
That’s a nice idea - it’d be great to have this available
as a GitHub action so anyone could do this with just a
click or two!
So, I made a [generic yaml workflow] that people can stick into their
git/github project. This will automatically maintain the dependency
graph `.deps/deps.png' which can be included in a readme.
[generic yaml workflow] <https://github.com/mjambon/dune-deps-action>
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/21>
Etienne Millon announced
────────────────────────
As described in this thread, ocamlformat 0.14.0 introduced a new
algorithm to determine how documentation comments are placed. We
underestimated the impact of making this the default, and this means
that many unwanted diffs were present for 0.13.0 -> 0.14.0 upgrades.
We are going to prepare a 0.14.1 release next week reverting this
behavior back to the 0.13.0 defaults. Users still on 0.13.0 are
encouraged to wait for this and upgrade directly to 0.14.1.
Sorry for the inconvenience, and thanks for the feedback!
Dune 2.5.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-5-0/5494/1>
Rudi Grinberg announced
───────────────────────
The dune team is pleased to announce the release of dune 2.5.0. This
release has been brewing for a while and contains a few interesting
features. I'll highlight some of the bigger ones:
• The coq support has been thoroughly extended. There's now support
for both composition of coq libraries in the same workspace and
extraction of coq code to OCaml.
• There's a new `$ dune upgrade' subcommand to help you upgrade dune
files from 1.x to 2.x
• `$ dune utop' will now load ppx preprocessors to the toplevel. Ppx
authors might enjoy this style of interactive development.
• There's a new `(subdir ..)' stanza that can be used to evaluate
stanzas in sub directories. This makes it possible to have a single
dune file for an entire project (generated or not).
I'd like to thank everyone who contributed to dune 2.5.0. Your help is
greatly appreciated.
Here's the full change log:
2.5.0 (09/04/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Add a `--release' option meaning the same as `-p' but without the
package filtering. This is useful for custom `dune' invocation in
opam files where we don't want `-p' (#3260, @diml)
• Fix a bug introduced in 2.4.0 causing `.bc' programs to be built
with `-custom' by default (#3269, fixes #3262, @diml)
• Allow contexts to be defined with local switches in workspace files
(#3265, fix #3264, @rgrinberg)
• Delay expansion errors until the rule is used to build something
(#3261, fix #3252, @rgrinberg, @diml)
• [coq] Support for theory dependencies and compositional builds using
new field `(theories ...)' (#2053, @ejgallego, @rgrinberg)
• From now on, each version of a syntax extension must be explicitely
tied to a minimum version of the dune language. Inconsistent
versions in a `dune-project' will trigger a warning for version
<=2.4 and an error for versions >2.4 of the dune language. (#3270,
fixes #2957, @voodoos)
• [coq] Bump coq lang version to 0.2. New coq features presented this
release require this version of the coq lang. (#3283, @ejgallego)
• Prevent installation of public executables disabled using the
`enabled_if' field. Installation will now simply skip such
executables instead of raising an error. (#3195, @voodoos)
• `dune upgrade' will now try to upgrade projects using versions <2.0
to version 2.0 of the dune language. (#3174, @voodoos)
• Add a `top' command to integrate dune with any toplevel, not just
utop. It is meant to be used with the new `#use_output' directive of
OCaml 4.11 (#2952, @mbernat, @diml)
• Allow per-package `version' in generated `opam' files (#3287,
@toots)
• [coq] Introduce the `coq.extraction' stanza. It can be used to
extract OCaml sources (#3299, fixes #2178, @rgrinberg)
• Load ppx rewriters in dune utop and add pps field to toplevel
stanza. Ppx extensions will now be usable in the toplevel (#3266,
fixes #346, @stephanieyou)
• Add a `(subdir ..)' stanza to allow evaluating stanzas in sub
directories. (#3268, @rgrinberg)
• Fix a bug preventing one from running inline tests in multiple modes
(#3352, @diml)
• Allow the use of the `%{profile}' variable in the `enabled_if' field
of the library stanza. (#3344, @mrmr1993)
• Allow the use of `%{ocaml_version}' variable in `enabled_if' field
of the library stanza. (#3339, @voodoos)
• Fix dune build freezing on MacOS when cache is enabled. (#3249,
fixes ##2973, @artempyanykh)
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 20312 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-21 8:58 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-04-21 8:58 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 27263 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 14 to 21,
2020.
Table of Contents
─────────────────
Current_incr: a small incremental library with no dependencies
Scikit-learn for OCaml
OCaml and opam container images updated: new Fedora/Alpine/Ubuntu images
OCamlformat 0.14.0
Hashconsing an AST via PPX
Genprint v0.4
Other OCaml News
Old CWN
Current_incr: a small incremental library with no dependencies
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-current-incr-a-small-incremental-library-with-no-dependencies/5531/1>
Thomas Leonard announced
────────────────────────
The recent [OCurrent 0.2] release included a little incremental
library which might be interesting to some people. It is useful for
writing programs that need to keep some computation up-to-date
efficiently as the inputs change.
It is similar to the existing [incremental] and [react] libraries
already in opam. Unlike `incremental' (which pulls in the whole of
`core_kernel'), `current_incr' has no runtime dependencies (and build
dependencies only on `ocaml' and `dune'). Unlike `react',
`current_incr' immediately stops computations when they are no longer
needed (rather than relying on weak references and the garbage
collector).
It is a fairly direct implementation of the [Adaptive Functional
Programming] paper, and might be a good starting point for people
wanting to learn about that.
You can get the library using `opam':
┌────
│ opam install current_incr
└────
Here's a simple example (in utop):
┌────
│ #require "current_incr";;
│
│ let total = Current_incr.var 10
│ let complete = Current_incr.var 5
│
│ let status =
│ Current_incr.of_cc begin
│ Current_incr.read (Current_incr.of_var total) @@ function
│ | 0 -> Current_incr.write "No jobs"
│ | total ->
│ Current_incr.read (Current_incr.of_var complete) @@ fun complete ->
│ let frac = float_of_int complete /. float_of_int total in
│ Printf.sprintf "%d/%d jobs complete (%.1f%%)"
│ complete total (100. *. frac)
│ |> Current_incr.write
│ end
└────
This defines two input variables (`total' and `complete') and a
"changeable computation" (`status') whose output depends on them. At
the top-level, we can observe the initial state using `observe':
┌────
│ # print_endline @@ Current_incr.observe status;;
│ 5/10 jobs complete (50.0%)
└────
Unlike a plain `ref' cell, a `Current_incr.var' keeps track of which
computations depend on it. After changing them, you must call
`propagate' to update the results:
┌────
│ # Current_incr.change total 12;;
│ # Current_incr.change complete 4;;
│ # print_endline @@ Current_incr.observe status;;
│ 5/10 jobs complete (50.0%) (* Not yet updated *)
│
│ # Current_incr.propagate ();
│ # print_endline @@ Current_incr.observe status;;
│ 4/12 jobs complete (33.3%)
└────
Computations can have side-effects, and you can use `on_release' to
run some compensating action if the computation needs to be undone
later. Here's a function that publishes a result, and also registers a
compensation for it:
┌────
│ let publish msg =
│ Printf.printf "PUBLISH: %s\n%!" msg;
│ Current_incr.on_release @@ fun () ->
│ Printf.printf "RETRACT: %s\n%!" msg
└────
It can be used like this:
┌────
│ # let display = Current_incr.map publish status;;
│ PUBLISH: 4/12 jobs complete (33.3%)
│
│ # Current_incr.change total 0;
│ # Current_incr.propagate ()
│ RETRACT: 4/12 jobs complete (33.3%)
│ PUBLISH: No jobs
└────
A major difference between this and the react library (which I've used
in previously in [0install's progress reporting] and [CueKeeper]) is
that `Current_incr' does not depend on the garbage collector to decide
when to stop a computation. In react, you'd have to be careful to make
sure that `display' didn't get GC'd (even though you don't need to
refer to it again) because if it did then the output would stop
getting updated. Also, setting `total' to `0' in react might cause the
program to crash with a division-by-zero exception, because the `frac'
computation will continue running until it gets GC'd, even though it
isn't needed for anything now.
[`Current_incr''s API] is pretty small. You might want to wrap it to
provide extra features, e.g.
• Use of a `result' type to propagate errors.
• Integration with `Lwt' to allow asynchronous computations.
• Static analysis to render your computation with graphviz.
• Persistence of state to disk.
If you need that, consider using the main [OCurrent] library, which
extends `current_incr' with these features.
[OCurrent 0.2] <https://github.com/ocurrent/ocurrent/releases/tag/v0.2>
[incremental] <https://github.com/janestreet/incremental>
[react] <https://erratique.ch/software/react>
[Adaptive Functional Programming]
<https://www.cs.cmu.edu/~guyb/papers/popl02.pdf>
[0install's progress reporting]
<https://stackoverflow.com/questions/19975140/how-to-stop-ocaml-garbage-collecting-my-reactive-event-handler>
[CueKeeper]
<https://roscidus.com/blog/blog/2015/06/22/cuekeeper-internals-irmin/>
[`Current_incr''s API]
<https://ocurrent.github.io/ocurrent/current_incr/Current_incr/index.html>
[OCurrent] <https://github.com/ocurrent/ocurrent>
Scikit-learn for OCaml
══════════════════════
Archive: <https://discuss.ocaml.org/t/scikit-learn-for-ocaml/5536/1>
UnixJunkie announced
────────────────────
Ronan Lehy just hacked this:
<https://github.com/lehy/ocaml-sklearn>
This might interest a significant number of people out there. We are
no more condemned to live in a world full of snakes that will bite us
at run-time. :smiley:
Ronan Le Hy then said
─────────────────────
So I came here to announce ocaml-sklearn as it just got published on
Opam, but I see @UnixJunkie did it for me (arigato gozai
masu). Anyway:
• this ambitions to cover the complete scikit-learn API
• this ambition is currently not totally realized, but I wanted to
release something initial that one can play with
• it's all @UnixJunkie's fault with his funny R wrappers.
So:
• opam install sklearn
• go check out [scikit-learn and its awesome documentation] to know
what it does
• look at [ocaml-sklearn's documentation] to see what the current
OCaml API looks like
• have fun with it and tell me what you think of it.
[scikit-learn and its awesome documentation] <https://scikit-learn.org>
[ocaml-sklearn's documentation] <https://lehy.github.io/ocaml-sklearn/>
Anton Kochkov then added
────────────────────────
Probably worth to add here:
• <https://github.com/ocaml-community/awesome-ocaml#machine-learning>
OCaml and opam container images updated: new Fedora/Alpine/Ubuntu images
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-and-opam-container-images-updated-new-fedora-alpine-ubuntu-images/5539/1>
Anil Madhavapeddy announced
───────────────────────────
The Docker [ocaml and opam container images] have been updated:
• Alpine 3.11, Fedora 31 and Ubuntu 20.04 (beta) are now included.
• Ubuntu 19.04 and Fedora 29 and 30 are now deprecated.
• OCaml 4.09.1 and 4.11.0~dev have been refreshed.
You can find the full details of the container images available [on
the OCaml infrastructure wiki].
The containers are generated from a set of scripts using
[ocaml-dockerfile], and will be migrating over the next six months to
use an [ocurrent]-based infrastructure. There will be an announcement
on this forum about any user-facing changes that involves, with plenty
of time to transition your own CIs over. Thanks go to @talex5 and
@XVilka for contributions to this round of updates.
[ocaml and opam container images] <https://hub.docker.com/r/ocaml/opam2>
[on the OCaml infrastructure wiki]
<https://github.com/ocaml/infrastructure/wiki/Containers>
[ocaml-dockerfile] <https://github.com/avsm/ocaml-dockerfile>
[ocurrent] <https://ocurrent.org>
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/24>
Jules announced
───────────────
As Etienne mentioned, we have released OCamlformat 0.14.1, reverting
the change to the defaults and our plans to deprecate the
`doc-comments' option.
For projects that already upgraded to 0.14.0 (eg. Coq), the
`doc-comments' option will change its meaning again. It is necessary
to add `doc-comments=before' to have the documentation comments placed
before. Moreover, the new option `doc-comments-val' added in 0.14.0
has a higher precedence than `doc-comments', even when it's not
set. It is thus necessary to set them both to `before' to have the old
"before" behavior. This will be improved in the next release (see
<https://github.com/ocaml-ppx/ocamlformat/pull/1340>).
Thank you to our early adopters to bear us. We are improving our
release process to reduce confusion for the next updates. As usual, if
you have any feedback, please open an issue on
<https://github.com/ocaml-ppx/ocamlformat> to discuss it with us.
Hashconsing an AST via PPX
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/hashconsing-an-ast-via-ppx/5558/1>
Chet Murthy announced
─────────────────────
[up-front (so nobody gets the wrong idea): I'm not pushing Camlp5.
Rather, I'm just noting that this sort of thing is really easy to do,
and I encourage someone to do something similar using the PPX
infrastructure.]
I didn't want to derail the "Future of PPX" thread, so I thought I'd
post separately to answer ivg@ 's issue about hashconsing of ASTs
using PPX. It's actually [uh, I think] really, really easy to
implement hashconsing of ADTs, using a PPX extension. On a lark, I
decided to do it *today*, and while the code I've got isn't sufficient
to use, I think it's not very far away, and I have the perfect
use-case already in-mind. It took me two hours to implement the
rewriter and the testcase, on top of the other infrastructure, which
has no support for hashconsing of any sort.
Here are some examples of data-types and functions that are
automaticaly hash-consed. The idea is that in the pattern-match the
pattern is annotated with a variable (in this example, "z"); the
expression that is supposed to be hash-consed against that pattern is
annotated with that same variable. [The code that descends to the
expression is a little weak right now, but I think that's easily
fixable.] The algorithm goes as follows:
(1) "decorate" the pattern with "as z_<integer>" variables everywhere
in constructors. This allows us to refer to parts of the original
value.
(2) then find each expression that is marked with that same varable.
Structurally descend the pattern and the expression in parallel and
generate code to compare sub-structure and hashcons where appropriate.
And that's really it. I'm sure this can be implemented using the PPX
tools.
Some comments: (1) what's nice, is that we can just take
already-written code like `List.map' and annotate it; that generates a
hash-consed version. And since the generated code never uses deep
structural equality (only pointer-equality) it should be only
marginally slower than the original implementation.
(2) The variable in the annotation ("z") is used as the base for
generating a whole slew of fresh variables, and I don't bother (yet)
to check for clashes; this (again) is straightforward, but hey, I
started two hours ago.
┌────
│ type t = Leaf of int | Node of t * int * t
│
│ module HCList = struct
│
│ let rec map f = function
│ [][@hashrecons z] -> [][@hashrecons z]
│ | (a::l)[@hashrecons z] -> let r = f a in ((r :: map f l)[@hashrecons z])
│
│ end
│
│ let deep =
│ let rec deep = (function
│ Leaf n[@hashrecons z] -> Leaf n[@hashrecons z]
│ | Node (l, n, r) [@hashrecons z] ->
│ Node (deep l, n, deep r) [@hashrecons z]
│ )
│ [@@ocaml.warning "-26"]
│ in deep
│
│ type sexp =
│ | Atom of string
│ | List of sexp list
│
│ let sexp_deep =
│ let rec deep = function
│ Atom s[@hashrecons z] -> Atom s[@hashrecons z]
│ | List l[@hashrecons z] -> List (HCList.map deep l)[@hashrecons z]
│ in deep
└────
Links: First, at the commit, so they won't change
the testcase file:
<https://github.com/chetmurthy/pa_ppx/commit/5dd6b2ef3ca3677e11a0ad696074200101bd661f#diff-e6dffe78fc6c27bdffa41970c4a7f1ca>
the "ppx rewriter":
<https://github.com/chetmurthy/pa_ppx/commit/5dd6b2ef3ca3677e11a0ad696074200101bd661f#diff-24aeaf51366017948f5735727f001c85>
Second, the files with human-readable names, etc.:
the testcase:
<https://github.com/chetmurthy/pa_ppx/blob/master/tests/test_hashrecons.ml>
the "ppx rewriter":
<https://github.com/chetmurthy/pa_ppx/blob/master/pa_hashrecons/pa_hashrecons.ml>
The projects:
chetmurthy/pa_ppx: A reimplementation of ppx_deriving, all its
plugins, ppx_import, and a few others.
<https://github.com/chetmurthy/pa_ppx>
chetmurthy/camlp5: Camlp5, version pre-8.00 on which the above is
based. This is on the branch 26.attempt-pa-deriving .
Kakadu said
───────────
I experimented with this some time ago for ML workshop. The idea was
to provide function: `t -> htbl -> htbl * t' which rewrites value of
type `t' by removing equal subtrees. Essentially it is just a fold
over data type.
<https://github.com/kakadu/GT/blob/master/regression/test816hash.ml#L74>
Chet Murthy asked and Josh Berdine replied
──────────────────────────────────────────
If you wanna use a hashtable (and, I presume, Obj.magic)
you can write a single function that does the trick for
all immutable data-types, right?
Yes, we have some magic @mbouaziz [code] in Infer that does this to
create as much sharing as possible as values are Marshaled out.
[code]
<https://github.com/facebook/infer/blob/master/infer/src/istd/MaximumSharing.ml>
Genprint v0.4
═════════════
Archive: <https://discuss.ocaml.org/t/ann-genprint-v0-4/5575/1>
progman announced
─────────────────
A re-announcement of Genprint, a general value printing library, that
addresses prior limitations that made it none too useful!
1. It didn't work correctly for 4.08.0, the latest compiler release as
of first announcement (though fine for 4.02 .. 4.07.1)
2. There was an awkward need to specify a search path for .cmt files
when working with the likes of Dune (which uses separate
directories for source, .cmi and (for opt) .cmt files)
3. More often than not values of interest would display simply as
`<abstr>' owing to the presence of signature abstraction of the
module's type of interest.
These issues have been addressed:
1. Works with versions 4.04 .. 4.10.0 (earlier versions became invalid
after a dependency change to ppxlib)
2. The location of .cmt files is captured automatically by the PPX
preprocessor.
3. Signatures at the implementation level (.mli files) and internally
(functor application constraints) are removed to reveal the inner
structure of otherwise abstract values. For instance, the
Ephemeron module:
┌────
│ module EM=Ephemeron.K1.Make(struct type t=int let equal=(=) let hash=Hashtbl.hash end)
│ open EM
│ let _=
│ let v=EM.create 0 in
│ EM.add v 12345678 'X';
│ let emprint ppf (v: Obj.Ephemeron.t) =
│ Format.fprintf ppf "<C wrapper of key/data>" in
│ [%install_printer emprint];
│ [%pr ephem v];
└────
Which prints:
┌────
│ ephem => {size = 1;
│ data =
│ [|Empty; Empty; Empty; Empty; Empty; Empty; Empty; Empty; Empty;
│ Empty; Empty; Cons (922381915, <C wrapper of key/data>, Empty);
│ Empty; Empty; Empty; Empty|];
│ seed = 0; initial_size = 16}
└────
This also demos the [%install_printer] facility which mirrors the
REPL's.
Installation is via the Opam main repository.
Additionally, the project repository [contains] two compiler versions
of _ocamldebug_ integrated with the Genprint library which thereby
becomes its default printer.
All of which makes this library much more useful than previously. See
the [project page] for the details.
[contains]
<https://github.com/progman1/genprintlib/tree/master/debugger>
[project page] <https://github.com/progman1/genprintlib>
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Editor note: Thanks to [ezcurl], I can restore this section. I'm
putting all the links this week, I will prune to only put the new ones
next week.
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [An in-depth Look at OCaml’s new “Best-fit” Garbage Collector
Strategy]
• [Sliding Tile Puzzle, Self-Contained OCaml Webapp]
• [New version of Try OCaml in beta!]
• [Frama-Clang 0.0.8 is out. Download it here.]
• [A reasonable TyXML release | Drup's thingies]
• [Alt-Ergo Users’ Club Annual Meeting]
• [OCaml iOS Apps Ported to Browser]
• [Watch all of Jane Street's tech talks]
• [Mercurial: prettyconfig extension]
• [Mercurial extensions (update)]
• [2019 at OCamlPro]
• [Bitbucket repository migration]
• [Troubleshooting systemd with SystemTap]
• [Ocsigen Start updated]
• [Ocsigen Start updated]
• [opam 2.0.6 release]
• [opam 2.0.6 release]
• [Hackers and climate activists join forces in Leipzig]
• [Deploying authoritative OCaml-DNS servers as MirageOS unikernels]
• [Reproducible MirageOS unikernel builds]
• [Using Python and OCaml in the same Jupyter notebook]
• [Coq 8.11+beta1 is out]
• [Deep-Learning the Hardest Go Problem in the World]
• [Frama-C 20.0 (Calcium) is out. Download it here.]
• [Testing OCaml releases with opamcheck]
• [Coq 8.10.2 is out]
• [Announcing Irmin 2.0.0]
• [BAP 2.0 is released]
• [CI/CD pipelines: Monad, Arrow or Dart?]
• [On fixed-point theorems in synthetic computability]
• [Runners in action]
• [Coq 8.10.1 is out]
• [Announcing MirageOS 3.6.0]
• [Commas in big numbers everywhere: An OpenType adventure]
• [Coq 8.10.0 is out]
• [OCaml expert and beginner training by OCamlPro (in French):
Nov. 5-6 & 7-8]
• [Mr. MIME - Parse and generate emails]
• [A look back on OCaml since 2011]
• [Frama-C 19.1 (Potassium) is out. Download ithere.]
• [Coq 8.10+beta3 is out]
• [Updated Cheat Sheets: OCaml Language and OCaml Standard Library]
• [Frama-Clang 0.0.7 is out. Download ithere.]
• [Decompress: Experiences with OCaml optimization]
• [On complete ordered fields]
• [An introduction to fuzzing OCaml with AFL, Crowbar and Bun]
• [What is algebraic about algebraic effects?]
• [The blog moved from Wordpress to Jekyll]
• [OCamlPro’s compiler team work update]
• [What the interns have wrought, 2019 edition]
• [Decompress: The New Decompress API]
[ezcurl] <https://github.com/c-cube/ezcurl>
[OCaml Planet] <http://ocaml.org/community/planet/>
[An in-depth Look at OCaml’s new “Best-fit” Garbage Collector Strategy]
<http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/>
[Sliding Tile Puzzle, Self-Contained OCaml Webapp]
<http://psellos.com/2020/03/2020.03.how-i-wrote-elastic-man.html>
[New version of Try OCaml in beta!]
<http://www.ocamlpro.com/2020/03/16/new-version-of-try-ocaml-in-beta/>
[Frama-Clang 0.0.8 is out. Download it here.]
<http://frama-c.com/index.html>
[A reasonable TyXML release | Drup's thingies]
<https://drup.github.io/2020/03/06/tyxml440/>
[Alt-Ergo Users’ Club Annual Meeting]
<http://www.ocamlpro.com/2020/03/03/alt-ergo-userss-club-annual-meeting/>
[OCaml iOS Apps Ported to Browser]
<http://psellos.com/2020/02/2020.02.kid-charlemagne.html>
[Watch all of Jane Street's tech talks]
<https://blog.janestreet.com/watch-all-of-jane-streets-tech-talks/>
[Mercurial: prettyconfig extension]
<http://blog.0branch.com/posts/2020-02-15-prettyconfig-extension.html>
[Mercurial extensions (update)]
<http://blog.0branch.com/posts/2020-02-05-hg-extensions.html>
[2019 at OCamlPro]
<http://www.ocamlpro.com/2020/02/04/2019-at-ocamlpro/>
[Bitbucket repository migration]
<http://blog.0branch.com/posts/2020-02-03-bitbucket-migration.html>
[Troubleshooting systemd with SystemTap]
<https://blog.janestreet.com/troubleshooting-systemd-with-systemtap/>
[Ocsigen Start updated]
<https://ocsigen.github.io/blog/2020/01/20/release/>
[opam 2.0.6 release]
<http://www.ocamlpro.com/2020/01/16/opam-2-0-6-release/>
[opam 2.0.6 release] <https://opam.ocaml.org/blog/opam-2-0-6/>
[Hackers and climate activists join forces in Leipzig]
<https://mirage.io/blog/ccc-2019-leipzig>
[Deploying authoritative OCaml-DNS servers as MirageOS unikernels]
<https://hannes.nqsb.io/Posts/DnsServer>
[Reproducible MirageOS unikernel builds]
<https://hannes.nqsb.io/Posts/ReproducibleOPAM>
[Using Python and OCaml in the same Jupyter notebook]
<https://blog.janestreet.com/using-python-and-ocaml-in-the-same-jupyter-notebook/>
[Coq 8.11+beta1 is out]
<https://coq.inria.fr/news/coq-8-11beta1-is-out.html>
[Deep-Learning the Hardest Go Problem in the World]
<https://blog.janestreet.com/deep-learning-the-hardest-go-problem-in-the-world/>
[Frama-C 20.0 (Calcium) is out. Download it here.]
<http://frama-c.com/index.html>
[Testing OCaml releases with opamcheck]
<http://gallium.inria.fr/blog/an-ocaml-release-story-1>
[Coq 8.10.2 is out] <https://coq.inria.fr/news/coq-8-10-2-is-out.html>
[Announcing Irmin 2.0.0] <https://mirage.io/blog/introducing-irmin-v2>
[BAP 2.0 is released]
<http://binaryanalysisplatform.github.io/bap-2-release>
[CI/CD pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
[On fixed-point theorems in synthetic computability]
<http://math.andrej.com/2019/11/07/on-fixed-point-theorems-in-synthetic-computability/>
[Runners in action]
<http://math.andrej.com/2019/10/28/runners-in-action/>
[Coq 8.10.1 is out] <https://coq.inria.fr/news/coq-8-10-1-is-out.html>
[Announcing MirageOS 3.6.0]
<https://mirage.io/blog/announcing-mirage-36-release>
[Commas in big numbers everywhere: An OpenType adventure]
<https://blog.janestreet.com/commas-in-big-numbers-everywhere/>
[Coq 8.10.0 is out] <https://coq.inria.fr/news/coq-8-10-0-is-out.html>
[OCaml expert and beginner training by OCamlPro (in French): Nov. 5-6 &
7-8]
<http://www.ocamlpro.com/2019/09/25/ocaml-expert-and-beginner-training-by-ocamlpro-in-french-nov-5-6-7-8/>
[Mr. MIME - Parse and generate emails]
<https://tarides.com/blog/2019-09-25-mr-mime-parse-and-generate-emails.html>
[A look back on OCaml since 2011]
<http://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/>
[Frama-C 19.1 (Potassium) is out. Download ithere.]
<http://frama-c.com/index.html>
[Coq 8.10+beta3 is out]
<https://coq.inria.fr/news/coq-8-10beta3-is-out.html>
[Updated Cheat Sheets: OCaml Language and OCaml Standard Library]
<http://www.ocamlpro.com/2019/09/13/updated-cheat-sheets-ocaml-language-and-ocaml-standard-library/>
[Frama-Clang 0.0.7 is out. Download ithere.]
<http://frama-c.com/index.html>
[Decompress: Experiences with OCaml optimization]
<https://tarides.com/blog/2019-09-13-decompress-experiences-with-ocaml-optimization.html>
[On complete ordered fields]
<http://math.andrej.com/2019/09/09/on-complete-ordered-fields/>
[An introduction to fuzzing OCaml with AFL, Crowbar and Bun]
<https://tarides.com/blog/2019-09-04-an-introduction-to-fuzzing-ocaml-with-afl-crowbar-and-bun.html>
[What is algebraic about algebraic effects?]
<http://math.andrej.com/2019/09/03/what-is-algebraic-about-algebraic-effects/>
[The blog moved from Wordpress to Jekyll]
<http://math.andrej.com/2019/09/03/the-blog-moved-from-wordpress-to-jekyll/>
[OCamlPro’s compiler team work update]
<http://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>
[What the interns have wrought, 2019 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2019/>
[Decompress: The New Decompress API]
<https://tarides.com/blog/2019-08-26-decompress-the-new-decompress-api.html>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 47059 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-28 12:45 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-04-28 12:45 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 29726 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 21 to 28,
2020.
Table of Contents
─────────────────
opam 2.0.7 and 2.1.0 alpha
OCaml 4.11, release plan
ocamlformat pre-commit hook
New release of naboris 0.1.2
ANN: Releases of ringo
resto 0.2 released
Retrofitting Parallelism onto OCaml (research paper)
Multicore Update: April 2020, with a preprint paper
Why did Core remove polymorphic comparison operators in OCaml 4.10.0?
New release of js_of_ocaml 3.6.0
Other OCaml News
Old CWN
opam 2.0.7 and 2.1.0 alpha
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-opam-2-0-7-and-2-1-0-alpha/5583/1>
R. Boujbel announced
────────────────────
We are pleased to announce the release of [opam 2.0.7] and an [2.1.0
alpha].
This 2.0.7 version contains backported fixes, you can find more
information in this [blog post].
The 2.1.0~alpha contains many new features (cf. [blog post] or
[release note]). If you want to take a look, a few glitches or
regressions are expected, please report them to [the bug-tracker].
*opam is a source-based package manager for OCaml. It supports
multiple simultaneous compiler installations, flexible package
constraints, and a Git-friendly development workflow.*
[opam 2.0.7] <https://github.com/ocaml/opam/releases/tag/2.0.7>
[2.1.0 alpha] <https://github.com/ocaml/opam/releases/tag/2.1.0-alpha>
[blog post] <https://opam.ocaml.org/blog/opam-2-0-7>
[blog post] <https://opam.ocaml.org/blog/opam-2-1-0-alpha/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.1.0-alpha>
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Anil Madhavapeddy then added
────────────────────────────
Thanks for all the hard work that's gone into this release, @rjbou
@AltGr and @dra27!
To set expectations, this alpha release is for our users to smoke test
the new features and let us know if they work for your usecases.
In particular, the opam external dependency management and support for
recursive pins are both commonly requested features. Please do take
this alpha for a spin, and report feedback here on this thread.
After this alpha is cut, there will be a sequence of beta releases
(the number of which depend on the reported bug tail), and then the
final opam 2.1.0 release. Your testing _now_ will greatly help us put
a quality release out of the door.
OCaml 4.11, release plan
════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-11-release-plan/5600/1>
octachron announced
───────────────────
The new version of OCaml, OCaml 4.11.0, has started its bugfix period:
the set of new features is now mostly frozen, and in the three
upcoming months, we will focus mostly on fixing bugs.
For this release cycle, we will experiment releasing an alpha version
of the compiler.
This new alpha version is expected to work as a synchronization point
for people working on updating the opam ecosystem for the new
release. Once the opam ecosystem is in shape for some wider audience
testings, we will publish a beta version as usual. This should be
happen around June.
One of the most notable change in this release is `Statmemprof', a new
statistical memory profiler directly integrated into the GC.
The provisional Changes list is [here].
At this point of time, it is better to take this list with a grain of
salt: there are a handful of new features that are still under
integration, problematic features might be removed, and of course the
list of bug fixes is incomplete.
But one of the most notable feature in this change log, `Statmemprof'
which a new statistical memory profiler API, is most probably here to
stay.
[here] <https://github.com/ocaml/ocaml/blob/4.11/Changes>
Guillaume Munch-Maccagnoni then added
─────────────────────────────────────
It should be mentioned that Memprof is documented as “~EXPERIMENTAL~”,
and at least one breaking change is being considered in 4.12. This
also mean that suggestion for improvement will be welcome (AFAIU).
ocamlformat pre-commit hook
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocamlformat-pre-commit-hook/5602/1>
Brendan Long announced
──────────────────────
This is kind of trivial but I figured it might be useful for other
people. We created a hook config for using [ocamlformat] with
[pre-commit]:
<https://github.com/arenadotio/pre-commit-ocamlformat>
pre-commit is a tool that makes it easier to run checks on changed
files before commiting them, and this makes it so you can auto-run
ocamlformat and ensure no unformatted code gets into your repo.
1. [Install pre-commit] like `pip install pre-commit'
2. In your repo, add a .pre-commit-config.yaml like:
┌────
│ ---
│ repos:
│ - repo: https://github.com/arenadotio/pre-commit-ocamlformat
│ rev: master # or pick a commit sha I guess
│ hooks:
│ - id: ocamlformat
└────
1. Run `pre-commit install'
2. Now every time you run `git commit' (or `pre-commit run'), it will
run every staged OCaml file through ocamlformat and complain if
there are any changes:
┌────
│ $ pre-commit run ocamlformat
│ ocamlformat.....Failed
│ - hook id: ocamlformat
│ - files were modified by this hook
│ $ git add .
│ $ pre-commit run ocamlformat
│ ocamlformat.....Passed
└────
[ocamlformat] <https://github.com/ocaml-ppx/ocamlformat#ocamlformat>
[pre-commit] <https://pre-commit.com/>
[Install pre-commit] <https://pre-commit.com/#install>
New release of naboris 0.1.2
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-naboris-0-1-2/5604/1>
Shawn McGinty announced
───────────────────────
Simple http server for OCaml/ReasonML.
[naboris] has been updated to 0.1.2
This release comes with a few improvements to the API but most notably
it has much better documentation at [naboris.dev]
[naboris] <https://naboris.dev>
[naboris.dev] <https://naboris.dev>
ANN: Releases of ringo
══════════════════════
Archive: <https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/1>
Raphaël Proust announced
────────────────────────
On behalf of Nomadic Labs, I am please to announce the first few
releases of Ringo: a library for caches. Ringo offers two kinds of
caches: Maps for caches of key-value pairs and Sets for caches of
simple elements. In addition, each kind of cache can be tweaked to
handle their bounds differently.
Ringo versions 0.1, 0.2 and 0.3 are available on `opam'. As the
version number and the bundled announce suggests, this library is
still in early phases of release: additional replacement policies will
be added, the interface will probably change somewhat,
etc. Suggestions welcome!
Even though the interface is still in early phases of release, the
implementation is covered by a lot of tests and is already in use in
the Tezos project.
The code is available at <https://gitlab.com/nomadic-labs/ringo>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/3>
Raphaël Proust announced
────────────────────────
Release of `resto 0.5'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
On behalf of Nomadic Labs, I'm happy to announce the release of
version 0.5 of `resto'.
The main change brought in this release are:
• relaxing of dependency bounds,
• documentation!
Retrofitting Parallelism onto OCaml (research paper)
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/retrofitting-parallelism-onto-ocaml-research-paper/5628/1>
Guillaume Munch-Maccagnoni announced
────────────────────────────────────
The following paper on the multicore GC design by @kayceesrk and his
coauthors has been posted on arXiv today and might interest the
community: <https://arxiv.org/abs/2004.11663>
Multicore Update: April 2020, with a preprint paper
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-update-april-2020-with-a-preprint-paper/5630/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the April 2020 update from the Multicore OCaml team, across
the UK, India, France and Switzerland! Although most of us are in
lockdown, we continue to march forward. As with [previous updates],
thanks to @shakthimaan and @kayceesrk for help assembling it all.
[previous updates] <https://discuss.ocaml.org/tag/multicore-monthly>
◊ Preprint: Retrofitting Parallelism onto OCaml
We've put up a preprint of a paper titled ["Retrofitting Parallelism
onto OCaml" ] for which we would be grateful to receive feedback. The
paper lays out the problem space for the multicore extension of OCaml
and presents the design choices, implementation and evaluation of the
concurrent garbage collector (GC).
Note that this is *not a final paper* as it is currently under peer
review, so any feedback given now can still be incorporated. Please
use the e-mail contact details in the [pdf paper] for @kayceesrk and
myself so we can aggregate (and acknowledge!) any such comments.
["Retrofitting Parallelism onto OCaml" ]
<https://arxiv.org/abs/2004.11663>
[pdf paper] <https://arxiv.org/pdf/2004.11663.pdf>
◊ Rebasing Progress
The Multicore OCaml rebase from 4.06.1 has gained momentum. We have
successfully rebased the parallel-minor-GC all the way onto the [4.09
OCaml trees]. We will publish updated opam packages when we get to
the recently branched 4.11 in the next couple of weeks.
Rebasing complex features like this is a "slow and steady" process due
to the number of intermediate conflicts and bootstrapping, so we will
not be publishing opam packages for every intermediate version –
instead, the 4.11 trees will form the new "stable base" for any PRs.
[4.09 OCaml trees]
<https://github.com/ocaml-multicore/ocaml-multicore/tree/parallel_minor_gc_4_09>
◊ Higher-level Domainslib API
A thread from [last month's update] on building a parallel raytracer
led to some useful advancements in the [domainslib] library to provide
async/await-style task support. See the updates below for more
details.
There is also an interesting discussion on
[ocaml-multicore/ocaml-multicore#324] about how to go about profiling
and optimising your own small programs. More experiments with
parallel algorithms with different scheduling properties would be most
useful at this time.
[last month's update]
<https://discuss.ocaml.org/t/multicore-ocaml-march-2020-update/5406/8>
[domainslib] <https://github.com/ocaml-multicore/domainslib>
[ocaml-multicore/ocaml-multicore#324]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324>
◊ Upstreamed features in 4.11
The [4.11 release has recently branched] and has the following
multicore-relevant changes in it:
• A concurrency-safe marshalling implementation (originally in
[ocaml#9293], then implemented again in [ocaml#9353]). This will
have a slight speed hit to marshalling-heavy programs, so feedback
on trying this in your projects with 4.11 will be appreciated to the
upstream OCaml issue tracker.
• A runtime eventlog tracing system using the CTF format is on the
verge of being merged in 4.11 over in [ocaml#9082]. This will also
be of interest to those who need sequential program profiling, and
is a generalisation of the infrastructure that was essential to our
development of the multicore GC. If anyone is interested in helping
with hacking on the OCaml side of CTF support to build clients,
please get in touch with me or @kayceesrk.
In addition to the above highlights, we have also been making
continuous improvements and additions to the Sandmark benchmarking
test infrastructure. The various ongoing and completed tasks are
provided below for your reference.
[4.11 release has recently branched]
<https://discuss.ocaml.org/t/ocaml-4-11-release-plan/5600>
[ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
[ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
[ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore] Promote Multicore OCaml to trunk
The rebasing of Multicore OCaml from 4.06 to 4.10 is being worked,
and we are now at 4.09! In a few weeks, we expect to complete the
rebase to the latest trunk release.
• [ocaml-multicore/eventlog-tools]: OCaml Eventlog Tools
A project that provides a set of tools for runtime tracing for OCaml
4.11.0 and higher has been created. This includes a simple OCaml
decoder for eventlog's trace and a built-in chrome converter tool.
• [ocaml-multicore/domainslib#5] Add parallel_scan to domainslib
A [parallel_scan] implementation that uses the Task API with
prefix_sum and summed_area_table has now been added to the
Domain-level Parallel Programming library for Multicore OCaml
(domainslib) library.
[ocaml-multicore/ocaml-multicore]
<https://github.com/ocaml-multicore/ocaml-multicore/tree/parallel_minor_gc_4_09>
[ocaml-multicore/eventlog-tools]
<https://github.com/ocaml-multicore/eventlog-tools>
[ocaml-multicore/domainslib#5]
<https://github.com/ocaml-multicore/domainslib/pull/5>
[parallel_scan]
<https://en.wikipedia.org/wiki/Prefix_sum#Shared_memory:_Two-level_algorithm>
◊ Completed
The following PRs have been merged into Multicore OCaml and its
ecosystem projects:
• [ocaml-multicore/ocaml-multicore#328] Multicore compiler with
Flambda
Support for Flambda has been merged into the Multicore OCaml project
repository. The translation is now performed at cmmgen instead of
lambda for clambda conversion.
• [ocaml-multicore/ocaml-multicore#324] Optimizing a Multicore program
The following [documentation] provides a detailed example on how to
do performance debugging for a Multicore program to improve the
runtime performance.
• [ocaml-multicore/ocaml-multicore#325] Added eventlog_to_latencies.py
script
A script to generate a latency report from an eventlog has now been
included in the ocaml-multicore repository.
• [ocaml-multicore/domainslib#4] Add support for task_pools
The domainslib library now has support for work-stealing task pools
with async/await parallelism. You are encouraged to try the
[examples].
[ocaml-multicore/ocaml-multicore#328]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/328>
[ocaml-multicore/ocaml-multicore#324]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324>
[documentation]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324#issuecomment-610183856>
[ocaml-multicore/ocaml-multicore#325]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/325>
[ocaml-multicore/domainslib#4]
<https://github.com/ocaml-multicore/domainslib/pull/4>
[examples]
<https://github.com/ocaml-multicore/domainslib/tree/task_pool/test>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
A number of new benchmarks are being ported to the [Sandmark]
performance benchmarking test suite.
• [ocaml-bench/sandmark#104] Added python pip3 dependency
A check_dependency function has now been defined in the Makefile
along with a list of dependencies and pip packages for Ubuntu. You
can now run `make depend' prior to building the benchmark suite to
ensure that you have the required software. The `python3-pip'
package has been added to the list of dependencies.
• [ocaml-bench/sandmark#96] Sandmark Analyze notebooks
The setup, builds and execution scripts for developer branches on
bench2.ocamllabs.io have been migrated to winter.ocamllabs.io.
A UI and automated script driven notebooks for analyzing sequential
bench results is being worked upon.
• [ocaml-bench/sandmark#108] Porting mergesort and matrix
multiplication using Task Pool API library
This is an on-going PR to implement merge sort and
matrix_multiplication using `parallel_for'.
• [cubicle]
`Cubicle' is a model checker and an automatic SMT theorem prover. At
present, it is being ported to Multicore OCaml, and this is a work
in progress.
• [raytracers]
Raytracers is a repository that contains ray tracer implementation
for different parallel functional programming languages. The OCaml
implementation has now been updated to use the new `Domainslib.Task'
API.
Also, a few [experiments] were performed on flambda parameters for
the Multicore raytracer which gives around 25% speedup, but it does
not yet remove the boxing of floats. The experiments are to be
repeated with a merge against the wip flambda2 trees on 4.11, that
removes float boxing.
[Sandmark] <https://github.com/ocaml-bench/sandmark>
[ocaml-bench/sandmark#104]
<https://github.com/ocaml-bench/sandmark/pull/104>
[ocaml-bench/sandmark#96]
<https://github.com/ocaml-bench/sandmark/issues/96>
[ocaml-bench/sandmark#108]
<https://github.com/ocaml-bench/sandmark/pull/108>
[cubicle] <https://github.com/Sudha247/cubicle/tree/add-multicore>
[raytracers] <https://github.com/athas/raytracers/pull/6>
[experiments]
<https://github.com/kayceesrk/raytracers/blob/flambda/ocaml/myocamlbuild.ml>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
A substantial number of commits have gone into this PR based on
reviews and feedback. These include updates to the configure script,
handling warnings and exceptions, adding build support for Windows,
removing unused code and coding style changes. This patch will be
cherry-picked for the 4.11 release.
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
◊ Completed
• [ocaml/ocaml#9353] Reimplement `output_value' using a hash table to
detect sharing
This PR which implements a hash table and bit vector as required for
Multicore OCaml has been merged to 4.11.
Our thanks as always go to all the OCaml developers and users in the
community for their continued support, and contribution to the
project!
[ocaml/ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• GC: Garbage Collector
• PIP: Pip Installs Python
• PR: Pull Request
• SMT: Satisfiability Modulo Theories
• UI: User Interface
Why did Core remove polymorphic comparison operators in OCaml 4.10.0?
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/why-did-core-remove-polymorphic-comparison-operators-in-ocaml-4-10-0/5633/1>
Trung Ta asked
──────────────
I'm using the Core library in a project, and recently when I upgraded
my OCaml from 4.08.1 to 4.10.0, plenty of compilation errors suddenly
appears for comparison expressions like:
`if (xs = []) then ...' or `if (x = true) then ...'
I saw that this change was discussed in this [thread] about
monomorphic comparison operators in Base, but did not expect that Core
would make it a default behavior.
So I'd like to ask since which version that Core removed such
polymorphic comparison operators? (I couldn't find it in release
notes of Core)
Also, if I defined a sum type like `type ternary = True | False |
Unkn', what will be a correct way to write `if (x = True) then ...'
(which is allowed in the new Core)?
I can temporarily fix by writing `if (x == True) then ...', but using
`==' doesn't seem correct, since `==' is about comparing physical
objects…
Thanks for spending your time to check my question.
[thread]
<https://discuss.ocaml.org/t/monomorphic-comparison-operator-of-janestreet-base-library/1585>
Aaron L. Zeng replied
─────────────────────
The change was announced in
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>,
although unfortunately it doesn't look like the CHANGES.md file was
updated in the repo. I would consider the thread to be the canonical
announcement.
Also, if I defined a sum type like `type ternary = True |
False | Unkn' , what will be a correct way to write `if (x
= True) then ...' (which is allowed in the new Core)?
Here's a few suggestions:
1. Define equality/compare functions using [`ppx_compare']
┌────
│ type ternary = True | False | Unkn [@@deriving equal]
│
│ let f x = if (equal_ternary x True) then ...
└────
2. Define equality/compare functions manually
┌────
│ let equal_ternary t1 t2 =
│ match t1, t2 with
│ | True, True | False, False | Unkn, Unkn -> true
│ | _ -> false
└────
3. Explicitly request polymorphic comparison operators using the
`Poly' module:
┌────
│ let f x = if (Poly.(=) x True) then ...
└────
[`ppx_compare'] <https://github.com/janestreet/ppx_compare>
Trung said and Aaron L. Zeng replied
────────────────────────────────────
btw,
┌────
│ type ternary = True | False | Unkn [@@deriving equal]
└────
should be: `[@@deriving eq]'
That depends on which preprocessor you are using. `[@@deriving
equal]' comes from ppx_compare, whereas `[@@deriving eq]' comes from
[ppx_deriving]. Base/Core and the like have better support for the
former, which is a Jane Street project, although you can feel free to
use the latter—the naming conventions are different, so it may not be
as convenient.
[ppx_deriving] <https://github.com/ocaml-ppx/ppx_deriving>
New release of js_of_ocaml 3.6.0
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-js-of-ocaml-3-6-0/5634/1>
Hhugo announced
───────────────
I'm pleased to announce the release [Js_of_ocaml] 3.6.0.
Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes
it possible to run pure OCaml programs in JavaScript environment like
browsers and Node.js.
Try it [online].
Notable changes:
• The `js_of_ocaml' compiler now accepts sub-commands (link,
build-runtime, build-fs, ..). The plan for future versions is to
remove other binary (e.g. jsoo_link) and consolidate everything
inside the `js_of_ocaml' binary itself.
• The standard JavaScript runtime is now embedded in the compiler
(findlib is no longer needed to locate it)
• Add support for the Str library (Regular expressions and high-level
string processing) shipped with the OCaml compiler
• Change memory representation of `Int64.t' (you might need to update
your JavaScript stubs)
• Many bug fixes (thanks to many more tests)
[Js_of_ocaml] <https://github.com/ocsigen/js_of_ocaml>
[online]
<https://ocsigen.org/js_of_ocaml/3.6.0/manual/files/toplevel/index.html>
Kirill Alexander Khalitov asked and Hhugo replied
─────────────────────────────────────────────────
1 Does the project have roadmap?
There is no official roadmap, the project evolves based on issues,
requests and contributions. You can take a look at some of the
[Github issues]
2 Is the project generally exists only for Ocsigen needs?
js_of_ocaml is used by various projects, not only Ocsigen. See
[Bonsai], [sketch-sh] or [jscoq] for instance.
3 Will it be adopted for modern front-end development
(commonjs/esmodules compatibility for working with
existing building tools ex. webpack, etc).
Being more friendly with the JavaScript ecosystem as been discussed
here and there in the past but little has been done, possibly by lack
of interest or use cases.
4 Does the project competing with bucklescript?
I don't think so. The two projects have different goals and different
audience. One of Js_of_ocaml main goal is to stay as close as possible
to the official OCaml semantic, allowing to leverage existing OCaml
libraries without any modification.
5 Why not to do ocaml to js compiler tools (based on
js_of_ocaml and bucklescript experience) that combine
possibility of using native ocaml and js libraries across
back-end and front-end like implemented in Scala.js/Fable
F#?
I don't understand this question. I would expect both js_of_ocaml and
bucklescript to be like Scala.js/Fable F# in their own way.
[Github issues]
<https://github.com/ocsigen/js_of_ocaml/issues?q=is:open+is:issue+label:enhancement>
[Bonsai] <https://github.com/janestreet/bonsai>
[sketch-sh] <https://github.com/Sketch-sh/sketch-sh>
[jscoq] <https://github.com/jscoq/jscoq>
Kirill Alexander Khalitov then said
───────────────────────────────────
I mean what Scala.js/Fable F# allows to use the most native libraries
(not all) and JS ones (from npm registry or from custom JS module) in
one project (ex. front-end). But in case of js_of_ocaml we limited to
native OCaml libs and "HTML scripts" (not JS compatible modules). For
bucklescript case we have whole JS ecosystem but have no access to
useful native libs from opam registry.
Xavier Van de Woestyne replied
──────────────────────────────
In Js_of_OCaml, you can deal with JavaScript's module (and npm/yarn),
using for example:
┌────
│ (* val require : string -> 'a *)
│ let require module_name =
│ let open Js.Unsafe in
│ fun_call
│ (js_expr "require")
│ [|inject (Js.string module_name)|]
└────
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Every proof assistant]
• [opam 2.0.7 release]
• [opam 2.1.0 alpha is here!]
[OCaml Planet] <http://ocaml.org/community/planet/>
[Every proof assistant]
<http://math.andrej.com/2020/04/28/every-theorem-prover/>
[opam 2.0.7 release]
<http://www.ocamlpro.com/2020/04/21/opam-2-0-7-release/>
[opam 2.1.0 alpha is here!]
<http://www.ocamlpro.com/2020/04/21/opam-2-1-0-alpha-is-here/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 47670 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-05 7:45 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-05-05 7:45 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12736 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 28 to May
05, 2020.
Table of Contents
─────────────────
Lwt now has let* syntax
JOSE 0.3.0 - Now with 100% more encryption
Are there learning materials for OCaml for those with no programming experience?
The recent evolution of utop, lambda-term, zed and underneath projects
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
Old CWN
Lwt now has let* syntax
═══════════════════════
Archive: [https://discuss.ocaml.org/t/lwt-now-has-let-syntax/5651/1]
Anton Bachin announced
──────────────────────
[Lwt] now has `let*' and `let+' syntax, which can be used like this:
┌────
│ open Lwt.Syntax
│
│ let () =
│ let request =
│ let* addresses = Lwt_unix.getaddrinfo "google.com" "80" [] in
│ let google = Lwt_unix.((List.hd addresses).ai_addr) in
│
│ Lwt_io.(with_connection google (fun (incoming, outgoing) ->
│ let* () = write outgoing "GET / HTTP/1.1\r\n" in
│ let* () = write outgoing "Connection: close\r\n\r\n" in
│ let* response = read incoming in
│ Lwt.return (Some response)))
│ in
│
│ let timeout =
│ let* () = Lwt_unix.sleep 5. in
│ Lwt.return None
│ in
│
│ match Lwt_main.run (Lwt.pick [request; timeout]) with
│ | Some response -> print_string response
│ | None -> prerr_endline "Request timed out"; exit 1
└────
This is now released in Lwt [5.3.0]. Thanks to Rahul Kumar for adding
`let*', and @CraigFe for adding `let+'!
[Lwt] https://github.com/ocsigen/lwt
[5.3.0] https://github.com/ocsigen/lwt/releases/tag/5.3.0
Thomas Coopman asked
────────────────────
Awesome this looks great.
2 quick questions:
1. I don't see this new version documented on ocsigen yet? Is that a
build that needs to be done manually?
2. Is `ppx_lwt' still recommend for some usecases like `try%'? For
what cases is one preferred over the other?
Anton Bachin replied
────────────────────
Good questions :slight_smile:
1. The docs generation is blocked on an Ocsigen "internal" package
`wikidoc', which has not been updated to support 4.08. So,
effectively, `let*' is exactly what is preventing docs generation
for the time being. I'll post the docs as soon as that is fixed.
2. `ppx_lwt' is probably still the recommended way, because of better
backtraces, and things like `try%lwt'. `let*' is nice for people
that don't want to use the PPX. They can still benefit from a
monadic syntax.
JOSE 0.3.0 - Now with 100% more encryption
══════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-jose-0-3-0-now-with-100-more-encryption/5667/1]
Ulrik Strid announced
─────────────────────
I recently released a version 0.3.0 of JOSE.
[https://github.com/ulrikstrid/reason-jose]
[https://ulrikstrid.github.io/reason-jose]
It now includes some of the JWE (JSON Web Encryption) spec. A huge
thank you goes out to @hannes for helping me implementing one of the
gnarlier combinations of decryption that I could then use as a base
for encryption and more `alg' and `enc'.
I also refactored the JWK (JSON Web Keys) implementation to unify and
simplify the representation. It is now possible to use a private key
for anything a public key can do since it's a superset.
A special thanks to @anmonteiro for helping me with the design and
reviewing my code.
Are there learning materials for OCaml for those with no programming experience?
════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/are-there-learning-materials-for-ocaml-for-those-with-no-programming-experience/5684/1]
Aaron Christianson asked
────────────────────────
OCaml is a language with some advanced features, but a very gentle
learning curve. It seems like it would be well-suited to teaching
beginners to program (a few tricky error messages notwithstanding),
but I haven't seen many resources targeted at teaching programming
from scratch. Does anyone here know any?
Daniel Bünzli replied
─────────────────────
There is [*OCaml from the Very Beginning*] written by @JohnWhitington.
[*OCaml from the Very Beginning*] http://ocaml-book.com/
Nicolás Ojeda Bär also replied
──────────────────────────────
An excellent (free) book is "LE LANGAGE CAML"
[https://caml.inria.fr/pub/distrib/books/llc.pdf].
Pierre also replied
───────────────────
There's also [CS3110] from Cornell University. Here's [the
textbook]. It's pretty great!
[CS3110] https://www.cs.cornell.edu/courses/cs3110/2020sp/
[the textbook]
https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/
The recent evolution of utop, lambda-term, zed and underneath projects
══════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/the-recent-evolution-of-utop-lambda-term-zed-and-underneath-projects/5687/1]
ZAN DoYe announced
──────────────────
Hi, dear OCaml guys! We've been keeping quiet for more than one year
though utop, lambda-term, zed and some related projects were still
evolving during the period of time. This is because of two reasons:
1. The new feature had nothing to do with the fields where most OCaml
developers are working on:
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a30d5fb6fc075a50801b387299cc820965d48ca0.png]
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/9/91b88f0c492702212f00f17af1bf0e18ee1a463b.png]
Recognizing, editing, fuzzy searching for Character
Variation(mainly for ancient CJK characters).
Nevertheless, the new feature brought us a good side effect – the
long-existing [Issue with asian charset] was resolved. UTop users
will notice the refinement naturally, so no announcement was
needed.
2. I didn't deem the first few new editions of zed 2 and lambda-term 2
stable enough.
[Issue with asian charset]
https://github.com/ocaml-community/lambda-term/issues/2
3.0 era
╌╌╌╌╌╌╌
This time, we are entering zed 3, lambda-term 3 era. The features
introduced since zed 2, lambda-term 2 are quite stable now and the new
feature coming to us will have a bit more impact, especially to vim
users. So it's worthwhile to draft an announcement:
◊ VI Editing Mode
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/c/ca11924046977d89d4345ad135977c6960470edc.gif]
OCaml guys, hope you enjoy this.
List of notable changes:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• zed 2:
• wide, combined glyph(Character Variation, IPA, CJK …)
• add wanted_column support for wide width character
• lambda-term 2:
• wide, combined glyph(Character Variation, IPA, CJK …)
• add horizontal scrolling support for wide width character
• zed 3:
• add new actions for convenience
• lambda-term 3:
• `LTerm_read_line': add initial support for vi editing mode:
• motions:
• h l 0 ^ $
• j k gg G
• w W e E b B ge gE
• f F t T
• aw iw aW iW
• include or inner ( ), [ ], { }, < >, ' and "
• generic quote: aq? iq? where ? could be any character
• bracket matching: jump back and forth between matched brackets
• delete, change, yank with motions
• paste: p P
• line joining: J
for a full list of the changes, please visit the homepages of each
project.
Projects underneath:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [charInfo_width]: Determine column width for a character
• [mew] & [mew_vi]: Modal editing witch & Its VI interpreter
complement. In a word, modal editing engine generators.
[charInfo_width] https://bitbucket.org/zandoye/charinfo_width/
[mew] https://github.com/kandu/mew
[mew_vi] https://github.com/kandu/mew_vi
What's next
╌╌╌╌╌╌╌╌╌╌╌
◊ VI Editing Mode
1. Visual mode
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/7/7cc45010710ad28d8d1e859e9b28806469ef8080.gif]
2. register support and more vi compatible
◊ CJKV
We've recorded more then 100 thousand entries about the structure of
CJK characters, what is a character consists of, how are the
sub-assemblies glue together etc. And as a complement to
charInfo_width, we may release a new project called charInfo_structure
;)
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/looking-for-lovely-idiomatic-examples-of-ocaml-used-for-shell-scripting-in-the-manner-of-perl-python-but-esp-perl/5703/1]
Chet Murthy announced
─────────────────────
I wonder if there are people who have written nontrivial Ocaml code
for shell-scripting, that they think exemplifies the right way to do
it. I've been a Perl hacker for 25yr, and so when I reach for Ocaml
to write stuff that should be Perl shell-scripts, I always find it a
bit painful, and there's a significant overhead to getting the job
done. Some of that is applying ocaml to a new domain, but some of it
is that I'm just not using the right idioms and tools (and there are
so many to choose from).
So if anybody has good pointers, I'd appreciate learning about them.
Bikal Lem
─────────
Haven't tried it myself, but this looks promising …
[https://github.com/janestreet/shexp].
At least it has the great Sean Connery in its README so possibly worth
delving a bit. :)
Hezekiah Carty
──────────────
[bos] seems like it can do a lot of what you're looking for. It's at
least worth taking a look, though it may not be at Perl levels of
concise for this kind of task.
[bos] https://erratique.ch/software/bos
Martin Jambon
─────────────
I tried to summarize my take on the subject into this gist:
[https://gist.github.com/mjambon/bb07b24f89fa60c973735307ce9c6cb9]
I'm not aware of the existence of such tool, but this is how I might
design it. This should be reminiscent of camlp4's quotation and
anti-quotation system, which allows alternating between two syntaxes
within a source file.
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 28610 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-12 7:46 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-05-12 7:46 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15797 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 05 to 12,
2020.
Table of Contents
─────────────────
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
Are there learning materials for OCaml for those with no programming experience?
Dune meeting notes
OCaml 4.11.0, first alpha release
OCaml Users and Developers Meeting 2020
VSCode Platform Plugin 0.5.0
Other OCaml News
Old CWN
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/looking-for-lovely-idiomatic-examples-of-ocaml-used-for-shell-scripting-in-the-manner-of-perl-python-but-esp-perl/5703/13]
Continuing this thread, Chet Murthy said and Aaron L. Zeng replied
──────────────────────────────────────────────────────────────────
• needs to be Ocaml code, not an interpreter. I mean, if
I’m not going to write it in Ocaml, I might as well
write in Perl, yes?
I think shexp might deserve another look. It's not an interpreter for
a sexp-based shell language, as its name might unfortunately
deceivingly suggest. It's really a DSL for constructing shell
pipelines using a `'a Process.t' monad. The s-expression part is
advertising that you can debug and trace the actions performed using
s-expressions.
The second-most-important part of Perl/Bash scripting is
string-handling. And it’s certainly the part of Ocaml
that’s most painful when writing scripts. Let’s stipulate
that there are nice libraries to make this easy. I’m an
Ocaml bigot, I have to believe this anyway *grin* . This
library doesn’t seem to use 'em, nor choose/promote a
particular set of such libraries.
I've found [Base] plus [Re] to be sufficient for most of my
string-manipulation needs. It's never going to be as concise as
Perl's built-in "magic" support for regexps, but you gain explicitness
and clarity, which is part of the benefit of OCaml anyway.
[Base] https://github.com/janestreet/base/
[Re] https://github.com/ocaml/ocaml-re
Chet Murthy said and Donn Cave replied
──────────────────────────────────────
It’s not as trivial in Ocaml, for many complicated reasons
that boil down to “gee, string-handling is a PITA”.
Really? hadn't noticed. Ha ha.
I could never really get urge for Perl, but I use its ancestor awk a
lot, and I'm trying out some awk-like simple string functions, like
┌────
│ let strlen = String.length
│ let sub s i n = let b = strlen s
│ in if i < b
│ then let n = min n (b - i)
│ in String.sub s i n
│ else ""
│ (* substring to end of line *)
│ let substr a i = if i < strlen a
│ then String.sub a i ((strlen a) - i)
│ else ""
│ let matchre t s = try
│ Str.search_forward t s 0
│ with | Not_found -> -1
└────
etc.
So "open Awk" gets me a handful of more basic variations on common
string functions, with less elaborate parameters, no normal
exceptions, etc. Including a line by line file processing function.
I have just newly started on this and haven't used it extensively, but
it seems fairly promising. No wacky syntax or hyper intelligent
string processing, no packages, just a few dozen lines of cheater
functions.
"Awk" is a misnomer, in that there's little correspondence between
this and awk, it was just what inspired me to try it.
Raphaël Proust said
───────────────────
I don't think it's lovely and I have no idea if it is idiomatic, but I
made a few scripts of my own in OCaml using the same library that
other mentioned: `bos'
• [typepass] uses `xdotool' to type passwords from the `password'
password manager
• [conn] wraps `wpa_supplicant', `dhcpcd', `ip', and other network
management CLI
• [laptop-status] fetches status information for laptops (e.g.,
battery level) and prints it in a nicely formatted form
• [bakelite] increases or decreases screen brightness
[typepass] https://gitlab.com/raphael-proust/typepass
[conn] https://gitlab.com/raphael-proust/conn
[laptop-status] https://gitlab.com/raphael-proust/laptop-status
[bakelite] https://gitlab.com/raphael-proust/bakelite
Vasile Rotaru also said
───────────────────────
[https://github.com/hammerlab/genspio]
Gabriel Radanne also said
─────────────────────────
I have no particular opinion about the rest, but at least on the regex
side, this might be of interest:
[https://github.com/paurkedal/ppx_regexp]
If that's still not good enough, I would be very interested by
suggestions on how to make it more convenient. :)
OCamlUser proposed
──────────────────
I'm not sure about idiomatic, but I do have a utop config that I use
to do some one-off scripting in OCaml that uses `shexp'
┌────
│ #use "topfind"
│ #warnings "+a"
│ #thread
│ #require "ppx_jane,core"
│ #require "shexp.process"
│ #require "lambdasoup"
│ module List' = List
│ open Shexp_process
│ open Shexp_process.Infix
│ open Core
│
│ module Html = struct
│ include Soup
│
│ let of_string = parse
│ end
│
│ let read_lines cmd =
│ eval (call cmd |- read_all)
│ ;;
│
│ let wget url =
│ read_lines ["wget"; "-O"; "-"; url]
│ ;;
│
│ let chrome_curl url =
│ read_lines ["curl"; "-k"; "-sA"; "Chrome"; "-L"; url; "-o"; "-"]
│ ;;
│
│ let split_lines = String.split ~on:'\n'
│ let filter_lines substring = List.filter ~f:String.(is_substring ~substring)
│ let to_html = Html.of_string
│ let find_html pat html = Html.(html $$ pat)
│
│ let (%) = Fn.compose
└────
Then a simple script called `shexp' in my path:
┌────
│ utop -init ~/bin/ocaml-shexp-config
└────
I add little helper functions as I come upon them. I find it's much
easier to transition to a file, or full program when I need
it. Example program:
┌────
│ utop # read_lines ["sensors"] |> split_lines |> filter_lines "Core 0";;
│ - : string list =
│ ["Core 0: +63.0°C (high = +84.0°C, crit = +100.0°C)"]
└────
Anton Kochkov said
──────────────────
Not exactly OCaml, but can be made with the OCaml syntax as well - see
[BATSH].
[BATSH] https://github.com/batsh-dev-team/Batsh
Bikal Lem also said
───────────────────
I just found this - [https://github.com/ShamoX/cash]. @Chet_Murthy
This may be the closest to ocaml shell scripting experience re perl.
Are there learning materials for OCaml for those with no programming experience?
════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/are-there-learning-materials-for-ocaml-for-those-with-no-programming-experience/5684/9]
Continuing this threaad, Luc_ML said
────────────────────────────────────
Before studying more complex books, it's a good idea to first get an
overview.
[OCaml for the Skeptical / OCaml in a Nutshell] : the title is funny;
its main advantage is that it covers most OCaml concepts in *21 short
sections* where you can experiment by yourself on simple but essential
things.
The books/courses already mentioned are nice. You can also consider
this one that offers many examples/exercises and also a good overview:
[Developing Applications With Objective Caml].
LE LANGAGE CAML mentioned by @nojb is an excellent book. Written in
Caml Light, it's easy to turn it by yourself into OCaml. It offers a
great chance to learn how to do a lot of things in *pure* Caml with
only stdlib and a simple syntax extension system (use camlp5 (i.e. the
"genuine camlp4") that is fine for that. It works out of the box to
deal with streams and it's a chance to understand what is a
LL(1)/recursive descent parser).
[OCaml for the Skeptical / OCaml in a Nutshell]
https://www2.lib.uchicago.edu/keith/ocaml-class/class-01.html
[Developing Applications With Objective Caml]
https://caml.inria.fr/pub/docs/oreilly-book/
Dune meeting notes
══════════════════
Archive: [https://discuss.ocaml.org/t/dune-meeting-notes/5710/1]
Jérémie Dimino announced
────────────────────────
I just wanted to publicise that we are now publishing the notes from
our Dune meetings on the wiki:
[https://github.com/ocaml/dune/wiki]
These meetings happen via video-conference every two weeks. If you are
interested in following the development of Dune more closely, this is
good place to look at.
OCaml 4.11.0, first alpha release
═════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-first-alpha-release/5716/1]
octachron announced
───────────────────
The set of new features for the future version 4.11.0 of OCaml has
been frozen. In the next few months, the OCaml compiler team is
focusing on bug hunting and fixing.
For this release cycle, we have decided to test publishing regularly
alpha versions of OCaml 4.11.0 in order to help fellow hackers join us
early in our bug hunting and opam ecosystem fixing fun. Once the opam
ecosystem is in shape, these alpha releases will morph into the usual
beta and release candidate releases.
If you find any bugs, please report them here:
[https://github.com/ocaml/ocaml/issues]
The compiler can be installed as an OPAM switch with one of the
following commands
┌────
│ opam switch create ocaml-variants.4.11.0+alpha1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+alpha1+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
The source code for the alpha is also available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+alpha1.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+alpha1.tar.gz]
If you are interested by the ongoing list of new features and fixed
bugs, the updated change log for OCaml 4.11.0 is available at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
OCaml Users and Developers Meeting 2020
═══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-users-and-developers-meeting-2020/5454/2]
Ivan Gotovchits announced
─────────────────────────
Due to the multiple requests and since ICFP will be now officially
held online with a significantly reduced fee, we decided to extend the
submission deadline till the end of this month. We are hoping to
attract a larger and more diverse audience this year, given that the
new format is more accessible both travel-wise and financially.
Please, share the news widely!
Important Dates (updated)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Talk proposal submission deadline: May 29th, 2020, AoE
• Author Notification: July 17th, 2020
• OCaml Workshop: August 28th, 2020
VSCode Platform Plugin 0.5.0
════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-vscode-platform-plugin-0-5-0/5752/1]
Rudi Grinberg announced
───────────────────────
This release contains a couple of major improvements:
• Syntax highlighting is vastly improved. There's now highlighting for
many more filetypes, and the core highlighting for OCaml is far more
accurate.
• There's integration with package managers such as opam and esy. One
may now explicitly use them to explicitly select the sandbox that
contains the lsp server and related tools.
Under the hood, the entire plugin was rewritten from typescript to
OCaml (bucklescript). This should hopefully make contribution more
accessible to OCaml hackers.
I'd like to thank @rustykey, @mnxn, @prometheansacrifice, and @imbsky
for their contributions to this release. Their help is the reason for
this vastly improved version of the plugin.
As usual, the plugin is available directly using vscode's extension
market place. I'll leave a link to the plugin [here] to avoid
confusion with the many other OCaml plugins available.
Please report any issues on the [bug tracker]
[here]
https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform
[bug tracker] https://github.com/ocamllabs/vscode-ocaml-platform/issues
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Ocsigen Start 2.18 released]
• [Ocsigen Toolkit 2.7 with new widget Ot_tongue]
[OCaml Planet] http://ocaml.org/community/planet/
[Ocsigen Start 2.18 released]
https://ocsigen.github.io/blog/2020/05/05/os/
[Ocsigen Toolkit 2.7 with new widget Ot_tongue]
https://ocsigen.github.io/blog/2020/05/04/ot/
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 33105 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-19 9:53 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-05-19 9:53 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 26620 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 12 to 19,
2020.
Table of Contents
─────────────────
ocamlformat 0.14.2
ML Family Workshop 2020: Call for presentations
memprof-limits preview (and a guide to handle asynchronous exceptions)
Tezos 7.0 is now available on opam
Official OCaml bindings for verified Everest cryptography
nmea and sail-gadgets
Is there specialized math library for statistics?
New OCaml books?
Other OCaml News
Old CWN
ocamlformat 0.14.2
══════════════════
Archive: [https://discuss.ocaml.org/t/ann-ocamlformat-0-14-2/5754/1]
Guillaume Petiot announced
──────────────────────────
We are pleased to announce the release of `ocamlformat' 0.14.2. This
minor release improves the recent 0.14.0 and 0.14.1 releases regarding
the `doc-comments' option.
How to migrate from 0.13.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Here are the changes of the `doc-comments' options compared to
ocamlformat 0.13.0:
• `after' has been renamed to `after-when-possible' to take into
account the technical limitations of ocamlformat;
• a new value `before-except-val' has been added, placing doc-comments
before the corresponding code, but placing doc-comments of val and
external declarations after the corresponding declaration;
• `before' is unchanged.
Here is the full list of changes made by the 0.14.0 release:
[https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435]
How to migrate from 0.14.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The 0.14.0 release lead to some regression of the `doc-comments'
behavior that (although intended for us) lead to some surprise from a
lot of users. The behavior of `doc-comments' has thus been reverted
to it's 0.13.0 state with the following changes:
The `doc-comments-val' option has been removed and merged with
`doc-comments'. The placement of documentation comments on `val' and
`external' items is now controlled by `doc-comments' .
• `doc-comments=after' becomes `doc-comments=after-when-possible' to
take into account the technical limitations of ocamlformat;
• `doc-comments=before' is unchanged;
• `doc-comments-val' is now replaced with `doc-comments'
To reproduce the former behaviors
• `doc-comments=before' + `doc-comments-val=before' : now use
`doc-comments=before' ;
• `doc-comments=before' + `doc-comments-val=after' : now use
`doc-comments=before-except-val' ;
• `doc-comments=after' + `doc-comments-val=before' : this behavior did
not make much sense and is not available anymore;
• `doc-comments=after' + `doc-comments-val=after' : now use
`doc-comments=after-when-possible'.
How to migrate from 0.14.1
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The 0.14.1 release was preserving the behavior of 0.13.0 regarding
`doc-comments', it added a `unset' value to the `doc-comments-val'
option. This option has been removed with the following changes:
The `doc-comments-val' option has been removed and merged with
`doc-comments'. The placement of documentation comments on `val' and
`external' items is now controlled by `doc-comments' .
• `doc-comments=after' becomes `doc-comments=after-when-possible' to
take into account the technical limitations of ocamlformat;
• `doc-comments=before' is unchanged;
• `doc-comments-val' is now replaced with `doc-comments'
To reproduce the former behaviors
• `doc-comments=before' + `doc-comments-val=before' : now use
`doc-comments=before' ;
• `doc-comments=before' + `doc-comments-val=after' : now use
`doc-comments=before-except-val' ;
• `doc-comments=after' + `doc-comments-val=before' : this behavior did
not make much sense and is not available anymore;
• `doc-comments=after' + `doc-comments-val=after' : now use
`doc-comments=after-when-possible'.
Thank you
╌╌╌╌╌╌╌╌╌
We would like to thank our early users to help us on the road of a
stable 1.0.0 release of ocamlformat.
ML Family Workshop 2020: Call for presentations
═══════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ml-family-workshop-2020-call-for-presentations/5441/4]
Leo White announced
───────────────────
ICFP, and by extension the ML workshop, will be now officially be held
online with a significantly reduced fee. Due to the change in official
status we decided to extend the submission deadline to the end of May.
Important Dates (updated)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Friday 29th May (any time zone): Abstract submission deadline
• Friday 17th July: Author notification
• Thursday 27th August: ML Family Workshop
memprof-limits preview (and a guide to handle asynchronous exceptions)
══════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-memprof-limits-preview-and-a-guide-to-handle-asynchronous-exceptions/5756/1]
Guillaume Munch-Maccagnoni announced
────────────────────────────────────
Dear OCamlers, I am happy to pre-announce [memprof-limits], an
implementation of per-thread global memory limits, and per-thread
allocation limits à la Haskell, compatible with systhreads.
Memprof-limits interrupts the execution by raising an _asynchronous
exception_, an exception that can arise at almost any location in the
code. I also announce [a guide on how to recover from asynchronous
exceptions and other unexpected exceptions] that you find in the
documentation. It summarises knowledge acquired in OCaml by the Coq
proof assistant as well as in other programming languages. To my
knowledge, this has never been told in OCaml textbooks, so I thought
it might be of general interest to you. This research is part of a
wider work aiming to regulate the use of asynchronous exceptions in
OCaml in coordination with multicore language designers.
_Global memory limits_ let you bound the memory consumption inside
specific parts of your program, in terms of memory used by the whole
program. It is inspired by [this other post], but in a form readily
available for use with systhreads.
_Allocation limits_ let you bound the execution of parts of the
program measured in number of allocations, analogous to the same
feature in Haskell advocated in [a nice post by Simon
Marlow]. Allocation limits count allocations but _not_ deallocations,
and is therefore a measure of the work done, which can be more
suitable than execution time.
Memprof-limits, as the name tells, uses the upcoming Memprof engine
from OCaml 4.11, with a low sampling rate that does not affect
performance. A reimplementation of the Memprof interface compatible
with memprof-limits running at the same time is provided for profiling
needs.
Memprof-limits is available on the public opam repository, but depends
on OCaml 4.11 which at the moment is available from the beta opam
repository only. It is _experimental_ for reasons explained in the
manual.
[memprof-limits] https://gitlab.com/gadmm/memprof-limits
[a guide on how to recover from asynchronous exceptions and other
unexpected exceptions] https://gitlab.com/gadmm/memprof-limits#recover
[this other post]
https://discuss.ocaml.org/t/todays-trick-memory-limits-with-gc-alarms/4431
[a nice post by Simon Marlow]
https://simonmar.github.io/posts/2017-01-24-asynchronous-exceptions.html
FAQ
╌╌╌
◊ “Is it wise to rely on the statistical nature of Memprof? If I set an allocation limit of 100 KB, and run a function that allocates exactly 50 KB, then the function might fail, due to the random nature of Memprof.”
Memprof-limits is provided with a [statistical analysis] meant to help
you chose appropriate values for the limit depending on a target safe
allocation value. (Nice pictures omitted because this discuss does not
support svg.)
Long story short, memprof-limits starts being accurate-enough starting
around a safe allocation value of 100 KB with the default sampling
rate (meaning a limit of 1 to 3 MB depending on chosen precision),
with the ratio between the maximal safe allocation and the limit
dropping very quickly for higher values. Correctly, the analysis shows
that limits under 500 KB are unreliable.
I have found that the statistical nature of Memprof makes it very easy
to reason about its application and not have to factor in runtime
implementation details. In addition, Memprof is nevertheless
deterministic, which is (essential and) useful for reproducing runs in
test scenarios.
[statistical analysis]
https://gitlab.com/gadmm/memprof-limits#statistical
◊ “But can we really program with memprof-limits, that is, not only write programs but also reason about them, given the probabilistic nature of the guarantees?”
Yes, if we make two additional hypotheses:
1. Allocation limits (as used in Haskell) are used by determining peak
reasonable allocation usage empirically and picking a limit at a
comfortable margin over it, rather than computing a precise memory
bound to be used as a limit. In very controlled environments where
the latter would be possible, there probably would be better
solutions, and the language this is inspired from makes it very
hard to make predictions on memory use.
2. The programmer is fine with a very unlikely possibility of a false
positive; indeed the program is already designed to let true
positives fail without bringing down mission-critical parts of the
program. For instance they can prefer to see a legitimate client
having a connexion closed once every 10ⁿ year for *n* of their
choosing, if that is the price to pay for avoiding being subject to
DOS on maliciously-crafted requests.
Under these hypotheses, the statistical limit is just as reliable as
the precise limits à la Haskell.
◊ “Is it possible to also implement _local memory limits_, to bound the memory consumption of a particular function?”
Yes but read on.
[Yang & Mazières (2014)] advocates in favour of an _allocator-pays_
model of cost attribution, and note its similarity with memory
profiling. In this model, it is possible for instance to process
untrusted user input under some memory limit, before the result is
distributed to the rest of the program.
Implementing memory limits based on the allocator-pays model, by
adapting allocation limits to take into account deallocations, would
be very easy thanks to the facilities provided by Memprof. Moreover,
the statistical analysis of allocation limits can be transposed, and
guarantees similarly accuracy at a low runtime cost for limits greater
than 100KB.
There is one surprising difficulty, though, which has to do with the
way the GC works. The GC has a space overhead: memory that is wasted
because unreachable values are not collected immediately. This
overhead has to be taken into account when choosing the
limit. However, this overhead is non-local and dependent on the
_total_ major heap size: one cannot just say “take the double of the
desired limit”. Indeed, active threads will pay for memory that has
been allocated in the past and kept alive. More experimentation is
needed to provide guidance on how to take the space overhead into
account.
[Yang & Mazières (2014)]
https://dl.acm.org/doi/10.1145/2594291.2594341
◊ “Can this be used to bound the consumption of lightweight threads in Lwt and Async?”
It is straightforward to make memprof-limits parametric in the notion
of _thread id_ used to track per-thread limits. However, to the best
of my knowledge, Lwt and Async are not meant to play well when the
computation is interrupted by asynchronous exceptions. If you have
more information about this limitation or are interested in
experimenting, please get in touch.
Thanks
╌╌╌╌╌╌
Thank you to Jacques-Henri Jourdan for his explanations about Memprof
and Stephen Dolan for his feedback.
Tezos 7.0 is now available on opam
══════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-tezos-7-0-is-now-available-on-opam/5764/1]
Pierre Boutillier announced
───────────────────────────
Tezos executables and libraries have just been released on `opam'. You
can thus build them from source with a simple `opam install tezos' and
build your own projects upon them.
What is Tezos
╌╌╌╌╌╌╌╌╌╌╌╌╌
Tezos is a distributed consensus platform with meta-consensus
capability. Tezos not only comes to consensus about the state of its
ledger, like Bitcoin or Ethereum. It also comes to consensus about how
the protocol and the nodes should adapt and upgrade. For more
information about the project, see [https://tezos.com].
Our implementation of Tezos is written in OCaml. It is split into
several libraries (command-line interface `tezos-clic', peer-to-peer
library `tezos-p2p', cryptographic primitives `tezos-crypto~…) and
executables (node ~tezos-node', client ~tezos-client~…).
Useful Links
╌╌╌╌╌╌╌╌╌╌╌╌
Source code for this particular implementation can be found at
[https://gitlab.com/tezos/tezos/]. Developer documentation is
available at [https://tezos.gitlab.io/]. In particular, documentation
for this specific release (version 7.0) is available at
[http://tezos.gitlab.io/releases/version-7.html].
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Tezos (internal compiler in order to self amend itself) requires a
specific version of the compiler (OCaml 4.09.1):
┌────
│ opam switch 4.09.1
└────
Tezos also requires some external libraries:
┌────
│ opam depext tezos
└────
Finally, to install all binaries:
┌────
│ opam install tezos
└────
Replying to Nick Betteridge, Raphaël Proust said
────────────────────────────────────────────────
Tezos has a soft-updating mechanism that works (roughly) as follows:
The network starts with a genesis protocol (“protocol” here means
“economic protocol”: the rules according to which smart contracts are
initiated and acted upon, transactions take place, etc.) in which a
single public key is specified.
The genesis protocol has no notion of coin, currency, smart-contract,
etc. Instead, the genesis protocol knows a single operation: a
protocol injection.
The protocol injection for genesis requires the operation to be signed
by the private key that matches the public key of the genesis
block. And the protocol injection changes, irreversibly, the genesis
protocol to a new protocol. This new protocol specifies what
constitutes a valid block to add to the chain.
In the Tezos blockchain, the protocol injected on top of genesis
included a notion of coins and an in-protocol voting system to inject
new protocols based on consensus amongst coin-holders. There is even a
system to obtain the protocol sources over the blockchain network so
they can be compiled by each node and dynlinked directly in: you don't
need to update/restart your node to get the protocol updates. However,
this is arbitrary: you can start a new block-chain with a different
protocol.
For example, you could re-implement Bitcoin (proof-of-work,
coins+transfer, etc.) as a protocol that you inject on top of
genesis. Your block chain would have a tezos genesis block, then a
block that activate your own version of bitcoin, and then the blocks
would be similar to what you would find on the bitcoin block-chain.
Of particular interest to you, the protocol you inject can have
entirely different on-chain notions (e.g., a TCG/CCG with no coins at
all but a notion of ownership over cards) and different soft-updating
mechanism (e.g., the new protocol can accept genesis-style updates (a
“dictatorship” where a single person controls the protocol) or even no
soft-updating mechanism at all (a “stale” protocol where you need to
hard-fork if you want to make significant changes)).
For this use case (of starting your own chain with a different
protocol), you might be better off cloning the git repository, doing
some minimal clean up, etc. This is because the tezos binaries include
the sources for all protocols that have been used on the chain (so you
don't *need* to get them over the network even if you can).
You might be interested in the following blog post about how to write
your own protocol:
[https://blog.nomadic-labs.com/how-to-write-a-tezos-protocol.html]
Official OCaml bindings for verified Everest cryptography
═════════════════════════════════════════════════════════
Archive:
[https://sympa.inria.fr/sympa/arc/caml-list/2020-05/msg00017.html]
Jonathan Protzenko announced
────────────────────────────
The Everest team is pleased to announce the release of official OCaml
bindings for all of our verified cryptographic algorithms, now
available through OPAM as packages hacl-star and hacl-star-raw.
We provide bindings for the following:
• HACL*, a library of pure C algorithms
• Vale, a collection of optimized core assembly routines for maximum
performance
• EverCrypt, an agile, multiplexing API with CPU auto-detection that
brings together HACL* and Vale.
Our code is compiled from the F* programming language to C via the
KReMLin compiler ("K&R meets ML"). We offer two OPAM packages:
• hacl-star-raw consists of low-level ocaml-ctypes bindings generated
by KReMLin
• hacl-star is a hand-written OCaml idiomatic API that uses much more
pleasant signatures, types and abstractions and is also safer, as it
checks all static preconditions at run-time
We support AES{128,256}-GCM, Chacha20-Poly1305, Curve25519 / Ed25519,
P256, MD5, SHA-{1,2,3} (all variants), Blake2 (s&b), HMAC/HKDF, and
the HPKE and SecretBox high-level APIs. Some algorithms are optimized
for Intel chips, notably AES-GCM – see
[https://hacl-star.github.io/Supported.html] for full details.
General documentation about the project is available at
[https://hacl-star.github.io/index.html] – sample code for the OCaml
API is provided as part of the test suite
[https://github.com/project-everest/hacl-star/tree/master/bindings/ocaml/tests]
This work was performed by Victor Dumitrescu from Nomadic Labs, one of
the teams responsible for the core development of the Tezos
blockchain.
nmea and sail-gadgets
═════════════════════
Archive: [https://discuss.ocaml.org/t/ann-nmea-sail-gadgets/5773/1]
Davide Gessa announced
──────────────────────
Ahoy developers, few days ago I published a new ocaml library called
*nmea*, which is essentially a parser for NMEA0183 sentences, a format
for encoding instruments data in boats. There are many sentences,
regarding GPS, compass data, wind, air pressure, water temperature,
waypoints handling, ais, autopilot and more; at the moment the library
is able to decode GPS sentences and compass data, but I'll implement
more sentences in the spare time. I tested it with my boat GPS and
with a gps usb dongle.
After that, I started a new tiny experiment called *sail-gadgets*,
which is a Gtk program that elaborates and displays NMEA data received
from various boat instruments (wind vane, autopilot, gps, radar, ais,
etc). Sail-gadgets can be extended with "gadgets" modules, each one
providing new functionalities and new tabs to the main interface.
Data from sensors are handled using /React/ signals, so in every
gadget we can compose data from various sensor to obtain new reactive
values.
The gadgets I'm planning to write:
• dashboard: shows current position, speed, heading, tripdist, compass
• satview: shows current connected gps satellites (partially done)
• wind: shows wind indicator with true / apparent speed and direction
• radar: shows AIS and Radar targets in range
• mob: allows to drop a marker in the current position, and drive you
to that point
• startline: helper for regatta start
• track: shows current track in a vector map
The hard thing in my opinion is writing new custom widget with cairo
(compass, radar, and things like that).
Finally, the project is intended to run over *gtk-broadway*, so every
html5 enabled device can access the application.
[https://raw.githubusercontent.com/dakk/sail-gadgets/master/media/broadway.jpg]
Hope there are some sailor here that want to join writing some gadgets
:) Repos are:
• [https://github.com/dakk/nmea]
• [https://github.com/dakk/sail-gadgets]
Is there specialized math library for statistics?
═════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/is-there-specialized-math-library-for-statistics/5778/1]
hss asked
─────────
I searched to find math library which is written in OCaml, but there
are only few repositories.
I'd like to use some function like coefficient correlation,
covariance, etc.
I found Lacaml but it seems not to support them.
Could you give some link if you know?
bnguyenvanyen replied
─────────────────────
Hi, you can take a look at Owl : [https://ocaml.xyz/]
There are stat functions and also a lot more
UnixJunkie also replied
───────────────────────
There is also this one:
[https://github.com/superbobry/pareto]
GSL powered OCaml statistics library
[http://superbobry.github.io/pareto/0.2]
And probably even some more:
┌────
│ opam search statistic
│ # Packages matching: match(*statistic*)
│ # Name # Installed # Synopsis
│ [...]
│ gsl -- GSL - Bindings to the GNU Scientific Library
│ oml -- Math Library
│ owl -- OCaml Scientific and Engineering Computing
│ owl-plplot -- OCaml Scientific and Engineering Computing
│ pareto -- GSL powered OCaml statistics library.
│ statsd-client -- StatsD client library
│ [...]
└────
New OCaml books?
════════════════
Archive: [https://discuss.ocaml.org/t/new-ocaml-books/5789/1]
Axel Wintermann asked
─────────────────────
I wonder, why there are no new OCaml books since 2014 year? Many books
are published on Haskell, Scala, F# themes, but no OCaml. I think we
need new books for learning and for rising interest in our beautiful
language.
Takuma Ishikawa replied
───────────────────────
• There is an ongoing work for 2nd edition of Real World OCaml:
[http://dev.realworldocaml.org/].
• OCaml Scientific Computing is also ongoing:
[https://ocaml.xyz/book/].
• A Japanese book "コンピュータを操る", published in Feb. 2020 for
beginners of programming, uses OCaml Blockly:
[https://www.saiensu.co.jp/search/?isbn=978-4-7819-1470-1&y=2020#detail].
Weng Shiwei also replied
────────────────────────
A Chinese book [OCaml语言编程基础教程] ([an introduction to OCaml
language programming]) is published in 2018.
[OCaml语言编程基础教程] https://e.jd.com/30417662.html
[an introduction to OCaml language programming]
https://caml.inria.fr/about/books.en.html#idm277
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Every proof assistant: MMT]
[OCaml Planet] http://ocaml.org/community/planet/
[Every proof assistant: MMT]
http://math.andrej.com/2020/05/15/mmt-a-foundation-independent-logical-system/
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 42565 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-09 8:29 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-06-09 8:29 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 28667 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 02 to 09,
2020.
Table of Contents
─────────────────
Multicore Update: April 2020, with a preprint paper
BAP 2.1.0 Release
Migrating an Async project to Lwt, a short primer
jose 0.4.0
OCaml 4.11.0, second alpha release
OCaml Workshop 2020: Call for Volunteers
Introduction to Lwt
Other OCaml News
Old CWN
Multicore Update: April 2020, with a preprint paper
═══════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/multicore-update-april-2020-with-a-preprint-paper/5630/26]
Continuing this thread, Daniel Bünzli asked and KC Sivaramakrishnan replied
───────────────────────────────────────────────────────────────────────────
One thing that I didn’t get from the paper is how exactly
`ConcurMinor' breaks the current FFI and the impact it
would have on the existing eco-system, on a scale from “it
affect all projects” to “only people doing *that* fancy
thing” :–) ?
All the projects that use the C API. The details are here:
[https://github.com/ocaml-multicore/ocaml-multicore/wiki/C-API-changes]
At the end of the paper it seems you make the point that
`ParMinor' is the solution to go with for the time
being. Does this means you are going to leave behind the
work done on `ConcurMinor' or do you intend to continue to
maintain it ?
We don't intend to maintain it. It is quite a bit of work to maintain
and port the changes across two different GCs. `ParMinor' GC is now
at 4.11 branch point (the default multicore compiler is 4.10 +
ParMinor now). The `ConcMinor' is at 4.06.1.
Given that `ConcMinor' breaks the C API, the ecosystem would have to
be fixed for `ConcMinor' to be useful. The code changes are indeed
intricate; the differences are not just in the minor GC, but the
compilers internal use of the C API. It will be quite a bit of work to
keep both GCs in the same source distribution.
Guillaume Munch-Maccagnoni then said
────────────────────────────────────
Given that `ConcMinor' breaks the C API, the ecosystem
would have to be fixed for `ConcMinor' to be useful.
I do not think this is necessarily true.
Here is why I think so, but be warned that this is preliminary as I do
not have time to explore this idea further on my own at the moment.
State in Rust
╌╌╌╌╌╌╌╌╌╌╌╌╌
Breaking the C API is a consequence of deciding that all
single-threaded shared mutable state must assume they are also shared
between threads. So a new read barrier is used to promote values when
read from another thread. But for data types that were correct up to
now, users must also be careful to avoid races from now on… for
instance by avoiding sharing values of such types between domains.
One lesson of Rust is that there are different kinds of mutable state,
for different usages, with different means to achieve thread-safety.
The closest there is to current OCaml's `mutable' is the notion of
single-threaded multiple-writers mutable state (_`Cell'_). It is made
thread-safe in Rust by statically preventing values containing `Cell'
from crossing thread boundaries (by virtue of not having the _`Send'
trait_). The same restriction is used to make some data structures
more efficient by avoiding the cost of synchronisation (cf. the
reference-counting pointer `Rc' vs. the atomic reference-counting
pointer `Arc').
This is not enough by itself, and Rust offers other kinds of state for
communicating and sharing values between threads.
_`UnsafeCell'_ like Ocaml multicore's `mutable' (though yours is safe
thanks to the work on the memory model): it has almost no restriction
and can be sent across domains, but the user is likewise told to
“avoid data races”. It is rarely used alone, but together with type
abstraction it can be used to program safe concurrent data structures.
Lastly, the default notion of state in Rust is linear state, which can
be sent freely across threads. Thread-safety is ensured by restricting
aliasing using the ownership and borrowing discipline.
A backwards-compatible concurrent collector?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If I had to imagine a backwards-compatible OCaml with static control
of interference à la Rust based on `ConcMinor', it would distinguish
the three kinds of state (concretely with other keywords in addition
to `mutable'). `mutable' would keep its current meaning of
single-domain, multiple-writers state and not require a read barrier,
and in particular preserve the API. (I count systhreads as
single-threaded for this purpose, since here it means "sharing the
same minor heap".)
Programs could progressively transition to other kinds of state when
parallelising the program. Concretely, a data structure like
`Stack.t', instead of becoming racy, would keep its current meaning,
but users could replace it with a linear stack or a concurrent stack,
two data structures distinct from the first one, when parallelizing
their programs.
So how could this fit with the current plans? It is not entirely clear
to me. If people start to rely on parallelism in an unstructured way
(e.g. no clear distinction between different kinds of data types
arising from different ways of ensuring thread-safety) then one will
also lose the ability to retrofit `ConcMinor' in a
backwards-compatible manner (by losing the information that the
current `mutable' API is single-threaded). The API breakage of
`ConcMinor' which might only be virtual right now (if I trust this
preliminary, not fully-explored idea) will become real. (Further
difficulties arise with the emulation of the `Thread' library with
domains, but this could be changed later.)
But if users are provided in advance with a general direction for a
model of control of interference this might happen differently. And
eventually having such a model is desirable in any case, as it helps
parallelizing programs (for instance the Firefox people reported that
they had attempted and failed twice to parallelise the CSS engine in
C++ before succeeding with Rust). Furthermore, in an imaginary
retrofitting of `ConcMinor', one could imagine enforcing something
like the `Send' trait at the level of the read barrier until there is
a better way (there would be two kinds of barriers, one of which would
raise an exception if a state happened to be incorrectly shared across
domains, and not be required in the FFI).
I find `ConcMinor' interesting from a systems programming perspective
compared to the stop-the-world collector because it could (I hope)
offer possibilities such as having a low-latency domain communicating
with a higher-latency domain. Moreover the performance cost of the
read barrier might be lower in this scheme if it could be removed for
all but the concurrent data structures.
BAP 2.1.0 Release
═════════════════
Archive: [https://discuss.ocaml.org/t/ann-bap-2-1-0-release/5906/1]
Ivan Gotovchits announced
─────────────────────────
The Carnegie Mellon University Binary Analysis Platform ([CMU BAP]) is
a suite of utilities and libraries that enables analysis of programs
that are represented as machine code (aka binaries). CMU BAP is
written in OCaml and uses plugin-based architecture to enable
extensibility. We also have a domain-specific language, called Primus
Lisp, that we use to write analysis, specify verification conditions,
interact with the built-in SMT solver, and model the semantics of
machine instructions and functions.
The 2.1.0 Release is very rich in [new features] but the most
prominent addition is the new [symbolic executor] mode for the Primus
framework. We also significantly updated the Primus framework,
integrated it with our new Knowledge Base, which was introduced in the
BAP 2.0 release; we made our interpreter much faster; we added the
systems and components facilities, inspired by Common Lisp; and we
implemented a gradual type checker for Primus Lisp with type
inference. We also added an ability to represent machine instructions
as intrinsic functions so now it is possible to express their
semantics using Primus Lisp since we added IEEE754 primitives to the
Lisp interpreter.
As usual, we upgraded BAP to the newer versions of the Core library
and OCaml (we now support OCaml versions from 4.07 to 4.09). We also
significantly improved our build times and added an optional omake
backend, which we are using in-house.
From the user perspective, one of the key features of BAP as an
analysis platform is that you can run BAP on binaries that you can't
run otherwise, either because they need special hardware or software,
or need to interact with the outside world. In the past couple of
months, we have run BAP on various firmware and found numerous
zero-day vulnerabilities, particular, we were able to find critical
vulnerabilities in the VxWorks operating system that runs on,
potentially, billions of devices including mission-critical and
military appliances.
As always, questions, suggestions, and opinions are very welcome!
[CMU BAP] https://github.com/BinaryAnalysisPlatform/bap
[new features]
https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.1.0
[symbolic executor]
https://github.com/BinaryAnalysisPlatform/bap/pull/1105
Migrating an Async project to Lwt, a short primer
═════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/migrating-an-async-project-to-lwt-a-short-primer/5908/1]
Michael Bacarella announced
───────────────────────────
Consider this a post where I think aloud about my experience migrating
an Async project to Lwt. I've spent about a weekend doing such a
thing, and if, in the process of talking about it here I can save a
few people an hour or two (or perhaps inspire confidence to take such
a project on in the first place) then it will have been worthwhile.
This wouldn't be a complete post if I didn't also mention @dkim's
[translation of Real World OCaml's Async examples to Lwt]
This was born out of a previous effort where I [tried to mix Lwt and
Async in the same project]. This didn't go so well, so I tried
converting the whole thing to Lwt, and it turns out adapting to Lwt if
you're an Async person is actually much easier than I thought it would
be.
[translation of Real World OCaml's Async examples to Lwt]
https://github.com/dkim/rwo-lwt
[tried to mix Lwt and Async in the same project]
https://discuss.ocaml.org/t/best-practices-on-mixing-lwt-and-async/5372
Basics
╌╌╌╌╌╌
Both libraries involve promises/futures. Async calls its promises
`Deferred.t', whereas in Lwt they're called `Lwt.t'.
In Async you start your program by saying `never_returns (Scheduler.go
())' or `Command.async_spec' after you set up your initial
`Deferred.t'.
In Lwt you say `Lwt_main.run' on a top-level `Lwt.t' argument. Note
you can re-run `Lwt_main.run' in a single program as many times as you
want, but perhaps you shouldn't run multiple `Lwt_main.run' in
parallel.
There's an easy correspondence between basic operators.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Async Lwt
────────────────────────────────────────────────────
`Deferred.bind' `Lwt.bind'
`Deferred.return' `Lwt.return'
`>>=' `>>='
`Deferred.map' `Lwt.map'
`>>|' `>|='
`Deferred.don't_wait_for' `Lwt.async'
`In_thread.run' `Lwt_preemptive.detach'
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Starvation worries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The most important difference between Async and Lwt is that *fulfilled
promises are acted on immediately*, whereas Async kinda punts them to
the end of a work queue and runs their thunks later.
A return loop like this starves the rest of Lwt:
┌────
│ open Lwt.Infix
│
│ let main () =
│ let rec loop () =
│ Lwt.return ()
│ >>= fun () ->
│ loop ()
│ in
│ Lwt.async (loop ());
│ Lwt_io.printlf "this line never prints!"
│ ;;
│
│ let () = Lwt_main.run main ;;
└────
whereas the corresponding Async loop does not starve:
┌────
│ open! Async
│
│ let main () =
│ let rec loop () =
│ Deferred.return ()
│ >>= fun () ->
│ loop ()
│ in
│ don't_wait_for (loop ());
│ printf "this line does print!\n";
│ return ()
│ ;;
│
│ let () =
│ let cmd = Command.async_spec ~summary:"" Command.Spec.empty main in
│ Command.run cmd
│ ;;
└────
Fortunately there's a workaround. You can get something closer to the
Async-style behavior in Lwt by using `Lwt.yield ()' instead of
`Lwt.return ()'.
Spawning threads
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
From time to time you may need to run something in a system thread.
In Async you say `In_thread.run', whereas in Lwt you say
`Lwt_preemptive.detach'. For simple things they're pretty much
interchangeable, but one stumbling point for me was that in Async you
can create a named thread and always use that for the `In_thread.run',
with multiple simultaneous dispatches to that thread becoming
sequenced.
This is really useful for interacting with libraries that aren't so
thread friendly.
Lwt's detach doesn't provide an easy way to do this out of the box,
but I think you can still deal with thread unfriendly libraries by
using the `Lwt_preemptive.run_in_main' call.
Basically, never exit the detach thread you started to interact with
your library, and instead have it block on promise that gets filled
through run_in_main. In this way you can sequence your detached Lwt
thread similarly to Async.
Happy to explain further if this is unclear.
Other libraries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`Async.Unix' has a somewhat built-up conception of the UNIX API,
whereas `Lwt_main' is more a direct mapping of ocaml's `Unix' module
to promises.
Async `Clock.every' and `Clock.after' don't have exact analogs, but
you can make new versions pretty simply.
Example of a shallow imitation of Async `Clock.every'
┌────
│ let every span f =
│ Lwt.async (fun () ->
│ let span = Time.Span.to_sec span in
│ let rec loop () =
│ f ();
│ Lwt_unix.sleep span
│ >>= fun () ->
│ loop ()
│ in
│ loop ())
│ ;;
└────
*Open questions*
I haven't sorted out a good Lwt substitute that's as comfortable as
Async Pipe yet. Though some combination of Lwt_stream, Lwt_sequence
and `lwt-pipe' might fit the bill. If you just happen to know already
feel free to cluephone.
Closing remarks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This is basically everything? I'm almost suspicious that I'm not
having more problems, but will happily accept grace when it arises.
Raphaël Proust then said
────────────────────────
I haven’t sorted out a good Lwt substitute that’s as
comfortable as Async Pipe yet. Though some combination of
Lwt_stream, Lwt_sequence and `lwt-pipe' might fit the
bill. If you just happen to know already feel free to
cluephone.
The Tezos project has a pipe-like module:
[https://gitlab.com/tezos/tezos/-/blob/master/src/lib_stdlib/lwt_pipe.mli]
It hasn't been released as a standalone library (yet) but it is
released as part of the `tezos-stdlib' package.
I haven't used Async's pipe, so I don't know how close of a match it
is.
jose 0.4.0
══════════
Archive: [https://discuss.ocaml.org/t/ann-jose-0-4-0/5909/1]
Ulrik Strid announced
─────────────────────
A new release of JOSE has been published to opam
The following changes has been made
• RFC7638: Implement thumbprints @undu
• Make kid optional in the header and jwk to align better with the
spec, this is a breaking change
I have started dog fooding the library for a OpenID Connect client
which hopefully will help with the design going forward.
OCaml 4.11.0, second alpha release
══════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-second-alpha-release/5910/1]
octachron announced
───────────────────
A new alpha version of OCaml 4.11.0 has been published. Compared to
the first alpha version, this version contains the following new bug
fixes:
• *additional fixes* [6673], [1132], [+9617]: Relax the handling of
explicit polymorphic types (Leo White, review by Jacques Garrigue
and Gabriel Scherer)
• *additional fixes* [7364], [2188], [+9592], [+9609]: improvement of
the unboxability check for types with a single
constructor. Mutually-recursive type declarations can now contain
unboxed types. This is based on the paper
[https://arxiv.org/abs/1811.02300]
• [7817], [9546]: Unsound inclusion check for polymorphic variant
(Jacques Garrigue, report by Mikhail Mandrykin, review by Gabriel
Scherer)
• [9549], [9557]: Make -flarge-toc the default for PowerPC and
introduce -fsmall-toc to enable the previous behaviour. (David
Allsopp, report by Nathaniel Wesley Filardo, review by Xavier Leroy)
• [9320], [9550]: under Windows, make sure that the Unix.exec*
functions properly quote their argument lists. (Xavier Leroy, report
by André Maroneze, review by Nicolás Ojeda Bär and David Allsopp)
• [9490], [9505]: ensure proper rounding of file times returned by
Unix.stat, Unix.lstat, Unix.fstat. (Xavier Leroy and Guillaume
Melquiond, report by David Brown, review by Gabriel Scherer and
David Allsopp)
• [8676], [9594]: turn debugger off in programs launched by the
program being debugged (Xavier Leroy, report by Michael Soegtrop,
review by Gabriel Scherer)
• [9552]: restore ocamloptp build and installation (Florian Angeletti,
review by David Allsopp and Xavier Leroy)
• [7708], [9580]: Ensure Stdlib documentation index refers to
Stdlib. (Stephen Dolan, review by Florian Angeletti, report by
Hannes Mehnert)
• [9189], [9281]: fix a conflict with Gentoo build system by removing
an one-letter Makefile variable. (Florian Angeletti, report by Ralph
Seichter, review by David Allsopp and Damien Doligez)
The compiler can be installed as an OPAM switch with one of the
following commands
┌────
│ opam switch create ocaml-variants.4.11.0+alpha2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+alpha2+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where <VARIANT> is replaced with one of these: afl, flambda, fp,
fp+flambda
The source code for the alpha is also available at these addresses:
• [https://github.com/ocaml/ocaml/archive/4.11.0+alpha2.tar.gz]
• [https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+alpha2.tar.gz]
If you find any bugs, please report them here:
[https://github.com/ocaml/ocaml/issues]
[6673] https://github.com/ocaml/ocaml/issues/6673
[1132] https://github.com/ocaml/ocaml/issues/1132
[+9617] https://github.com/ocaml/ocaml/issues/9617
[7364] https://github.com/ocaml/ocaml/issues/7364
[2188] https://github.com/ocaml/ocaml/issues/2188
[+9592] https://github.com/ocaml/ocaml/issues/9592
[+9609] https://github.com/ocaml/ocaml/issues/9609
[7817] https://github.com/ocaml/ocaml/issues/7817
[9546] https://github.com/ocaml/ocaml/issues/9546
[9549] https://github.com/ocaml/ocaml/issues/9549
[9557] https://github.com/ocaml/ocaml/issues/9557
[9320] https://github.com/ocaml/ocaml/issues/9320
[9550] https://github.com/ocaml/ocaml/issues/9550
[9490] https://github.com/ocaml/ocaml/issues/9490
[9505] https://github.com/ocaml/ocaml/issues/9505
[8676] https://github.com/ocaml/ocaml/issues/8676
[9594] https://github.com/ocaml/ocaml/issues/9594
[9552] https://github.com/ocaml/ocaml/issues/9552
[7708] https://github.com/ocaml/ocaml/issues/7708
[9580] https://github.com/ocaml/ocaml/issues/9580
[9189] https://github.com/ocaml/ocaml/issues/9189
[9281] https://github.com/ocaml/ocaml/issues/9281
OCaml Workshop 2020: Call for Volunteers
════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-workshop-2020-call-for-volunteers/5913/1]
Ivan Gotovchits announced
─────────────────────────
The OCaml Workshop will be held in the virtual format this year, which
poses new challenges and requires people with special talents and
training. The Organizing Committee is seeking for members who will
volunteer to fill one (or more) of the following roles:
1. AV Editor
2. Session Host
3. Transcribers/Interpreter
4. Content Manager
5. Accessibility Chair
The roles are described in details below. We are asking prospective
Organizing Committee members to contact the Organizing Committee chair
([ivg@ieee.org]([mailto:ivg@ieee.org])), indicating which role(s) they
are ready to take.
[AV Editor]
╌╌╌╌╌╌╌╌╌╌╌
AV (Audio/Video) editors are responsible for previewing the
presentations and providing help and feedback to the authors. Ideally
we target for one editor per talk.
[AV Editor] https://icfp20.sigplan.org/home/ocaml-2020#av-editor
◊ [Duties]
• Preview and (if necessary) post-process or (ask the author to shoot
again) the pre-recorded videos.
• Advise authors and help in choice of software and hardware, teach
how to set up the camera, light, make sure that the audio is of good
quality and, in general, channel our quality guidelines.
• Ensure that all videos are of the same quality, the audio levels are
the same, and that everything is loud and clear.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Session Hosts]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Session hosts will assist session chairs in streaming the pre-recorded
videos as well as helping and moderating the Q&A sessions and the
panel session. They will also be responsible for security and be ready
to react to potential threats and wrongdoers. Since we will broadcast
sessions in several time zones we need several hosts for each session.
[Session Hosts] https://icfp20.sigplan.org/home/ocaml-2020#session-hosts
◊ [Duties]
• Moderating the text chats
• Controlling microphones in the video-conferencing
• Watching for the time
• Performing sound checks
• Welcoming and otherwise guiding participants
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Transcribers / Interpreters]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We would like to have at least English transcriptions for each talk
and translations to other languages are very welcome. Transcriptions
enable accessibility as well as potentially increase the audience and
publicity as they could be indexed by the search engines.
[Transcribers / Interpreters]
https://icfp20.sigplan.org/home/ocaml-2020#transcribers-interpreters
◊ [Duties]
• Create transcriptions for videos, potentially in other languages.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Content Manager]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The content manager will be responsible for maintaining the web
presence of the conference on [https://ocaml.org/]. We plan to have
all videos available, as well as maintain a page for each submitted
work.
[Content Manager]
https://icfp20.sigplan.org/home/ocaml-2020#content-manager
[Accessibility Chair]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We are striving to make the conference accessible to everyone and we
are looking for volunteers who have experience in online
accessibility.
[Accessibility Chair]
https://icfp20.sigplan.org/home/ocaml-2020#accessibility-chair
◊ [Duties]
• Helping with the selection of accessible platforms and tools.
• Working with attendees to ensure the necessary access services are
included.
• Establishing best practices for preparing and running accessible
sessions.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
Introduction to Lwt
═══════════════════
Archive: [https://discuss.ocaml.org/t/introduction-to-lwt/5940/1]
Raphaël Proust announced
────────────────────────
I've published
[https://raphael-proust.github.io/code/lwt-part-1.html], a 2-part
introduction to Lwt.
The main aim of the introduction is to give a good mental model of
what promises are, how they behave and how to use them. It assumes
basic familiarity with OCaml.
Don't hesitate to ask questions or share feedback.
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Using ASCII waveforms to test hardware designs]
[OCaml Planet] http://ocaml.org/community/planet/
[Using ASCII waveforms to test hardware designs]
https://blog.janestreet.com/using-ascii-waveforms-to-test-hardware-designs/
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 46346 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-16 8:36 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-06-16 8:36 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 12607 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 09 to 16,
2020.
Table of Contents
─────────────────
First release of monolith
Sylvain Conchon joined OCamlPro's team
First release of streaming
Senior software engineer at Asemio in Tulsa, OK
Other OCaml News
Old CWN
First release of monolith
═════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-first-release-of-monolith/5946/1]
François Pottier announced
──────────────────────────
It is my pleasure to announce the first release of Monolith.
Monolith offers facilities for testing an OCaml library (for instance,
a data structure implementation) by comparing it against a reference
implementation. It uses a form of black-box testing, and relies on
`afl-fuzz' for efficiency.
The user must describe what types and operations the library
provides. Under the best circumstances, this requires 2-3 lines of
code per type or operation. The user must also provide a reference
implementation of the library.
Then, like a monkey typing on a keyboard, Monolith attempts to
exercise the library in every possible way, in the hope of discovering
a scenario where the library behaves incorrectly. If such a scenario
is discovered, it is printed in the form of an OCaml program, so as to
help the user reproduce the problem.
At this time, a tutorial is not yet available. There is however an API
documentation and a number of demos.
Repository: [https://gitlab.inria.fr/fpottier/monolith]
API Documentation:
[http://cambium.inria.fr/~fpottier/monolith/doc/monolith/Monolith/index.html]
Installation:
┌────
│ opam update
│ opam install monolith
└────
Sylvain Conchon joined OCamlPro's team
══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/sylvain-conchon-joined-ocamlpros-team/5956/1]
OCamlPro announced
──────────────────
Sylvain Conchon joined OCamlPro's team as Formal Methods CSO. He
created Alt-Ergo and has been teaching OCaml in universities for about
20 years. He shares thoughts on interactions between industry and
research labs, and his vision of Formal methods and OCaml as language
for the industry. Read his interview on our blog:
[https://www.ocamlpro.com/2020/06/05/interview-sylvain-conchon-cso-on-formal-methods/]
First release of streaming
══════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-first-release-of-streaming/5961/1]
Rizo announced
──────────────
It is my pleasure to announce the first public release of `streaming'
– a library for building efficient, incremental data processing
pipelines that compose and don't leak resources.
I built streaming as a result of many experiments with different
streaming and iteration models for OCaml. There are multiple packages
on OPAM that share some of the goals of `streaming' (we even have
`Stdlib.Seq' now!), but none of them combine (1) excellent
performance, (2) safe resource handling and (3) pure functional style
for combinators. Streaming solves these problems by implementing
three basic and independent models: _sources_, _sinks_ and _flows_ –
they represents different parts of the pipeline that correspond to
producing, consuming and transforming elements. These models can be
defined and composed independently to produce reusable "streaming
blocks".
The library defines a central `Stream' model that relies on sources,
sinks and flows. This model is a push-based iterator with performance
characteristics similar to the `iter' iterator, which has type `('a ->
unit) -> unit', and is known for being very efficient. But unlike
`iter', it has a pure functional core (no need to use mutable state
and exceptions for flow control!) and can handle resource allocation
and clean up in a lazy and deterministic way. All of this while having
a slightly better performance for common stream operations.
For those who are curious about the performance characteristics of
`streaming' and other models, I created a dedicated repository for
stream benchmarks: [https://github.com/rizo/streams-bench]. In
particular, it includes a few simple benchmarks for `Gen',
`Base.Sequence', `Stdlib.Seq', `Iter', `Streaming.Stream' and
`Streaming.Source'.
The library should soon be published on opam. In the meantime, I
invite you to read the docs and explore the code:
• Library documentation: [https://odis-labs.github.io/streaming]
• Github project: [https://github.com/odis-labs/streaming]
Guillaume Bury askec
────────────────────
That's great ! From the benchmarks, it looks like you hit a really
good implementation !
I've looked (maybe a bit fast) at the API documentation, and it is
admittedly a bit outside the scope of streams/iterators, but I was
wondering if there was some proper way to:
• connect a sink to a source to create some loop
• have some kind of fixpoint on streams
I guess it would always be possible to use some references and/or some
complex functions to encode these into the provided API, but I was
wondering if there was a clean way to do it.
For a bit of context and explanation, what I have in mind is the case
of a program (let's say a type-checker or something close to the idea)
with a *persistent state*, that should operate over a stream of
inputs, which are top-level phrases, and produce some outputs, for
instance print some result for each correctly type-checked statement
(and an error otherwise). The type-checker would basically be a
function of type `(`input * `state) -> (`output * `state)', and
starting from an initial state, it would process an input element
(giving the output to some sink), and then the next input element
would be processed with the state that was reached after processing
the previous element: the state would reach the sink of the flow, and
then be inserted back into the source. Separately, imagine the
language being type-checked has a notion of include, then one of the
step of the flow would be to expand each include into a stream of
inputs/phrases, but each of the phrases in this stream would need to
be expanded, so a simple `flat_map~/~flatten' is not enough.
I already have a custom implementation that handle these features, but
I was wondering whether I could use `streaming' to handle most of the
code linking all of the steps, ^^
Rizo replied
────────────
if there was some proper way to:
• connect a sink to a source to create some loop
• have some kind of fixpoint on streams
Regarding the first point: yes! That's exactly the point of the
`Stream' module. You see, sources are pull-based abstractions, while
sinks are push-based. Source's type essentially says something like
_"I might give you some data, if you ask"_, while sink's type is the
opposite _"I might take some data, if you give it to me"_. They are
completely and intentionally decoupled; it is Stream's role to drive
the computation by pulling data from sources and pushing it into
sinks. So the easiest way to connect them is:
┌────
│ Stream.(from srouce |> into sink)
└────
Of course, that's not very useful per se, but it illustrates my
point. Take a look at the [`Stream.from'] code to see the
implementation of the loop you're asking for. It does some extra work
to ensure that resources are correctly handled, but it should be clear
what the loop is doing.
The stream types in the library are currently abstract because I
didn't want to commit to a particular representation just yet. If this
is a problem for your use case, let me know, I'll expose them in a
`Private' module.
Regarding the second point: I'm not sure what you mean in practice by
"fixpoint on streams". I guess the one thing that could help implement
something like that is the [`Stream.run'] function. It allows you to
continue reading elements from a source even after a sink is filled by
returning a leftover stream. This stream can be used with
`Stream.run' repeatedly.
Alternatively there's also [`Flow.through'], which consumes input
trying to fill sinks repeatedly and produces their aggregated values
as a stream. Super useful for things like streaming parsing. Might
even help with your use-case for top-level phrases.
On a more general note though, the type `('input * 'state) -> ('output
* 'state)' looks a lot like a [mealy machine]. `Streaming.Sink' is a
[moore machine], which is slightly less general because the output
values do not depend on input values, only on the state.
I thought about exposing different kinds of sinks in streaming, but
wanted to make sure that the common use cases are covered first. I'll
keep your case in mind for future versions of the library.
[`Stream.from']
https://github.com/odis-labs/streaming/blob/0.8.0/lib/Stream.ml#L42
[`Stream.run']
https://odis-labs.github.io/streaming/streaming/Streaming/Stream/index.html#val-run
[`Flow.through']
https://odis-labs.github.io/streaming/streaming/Streaming/Flow/index.html#val-through
[mealy machine] https://en.wikipedia.org/wiki/Mealy_machine
[moore machine] https://en.wikipedia.org/wiki/Moore_machine
Senior software engineer at Asemio in Tulsa, OK
═══════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/senior-software-engineer-at-asemio-in-tulsa-ok/5979/1]
Simon Grondin announced
───────────────────────
We are Asemio and our team of data scientists, software engineers,
architects, and management consultants are working together to achieve
a nationwide data ecosystem for social good.
You’ll be working on the Asemio Community Integration Platform. It
features state-of-the-art privacy-preserving, pre-processing and
pipeline management, as well as record linkage technology.
The back end is written in OCaml. The front end is compiled from OCaml
to JavaScript and uses a modern MVC framework. The work you’ll be
doing will touch numerous technical disciplines, including
cryptography, distributed systems, language design and implementation,
data analytics, and data visualizations.
We prefer candidates willing to relocate, but we could make an
exception for an exceptional candidate.
For more information or to apply, please refer to our SE listing:
[https://stackoverflow.com/jobs/401383/ocaml-senior-software-engineer-asemio]
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-C 21.0 (Scandium) is out. Download it here.]
• [Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-C 21.0 (Scandium) is out. Download it here.]
http://frama-c.com/index.html
[Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]
http://math.andrej.com/2020/06/09/epigram-2-autopsy-obituary-apology/
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 25107 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-30 7:00 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-06-30 7:00 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 7753 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 23 to 30,
2020.
Table of Contents
─────────────────
finch - static site generator
ANN: Releases of ringo
OCaml 4.11, first beta release
FlexDLL 0.38 released
Other OCaml News
Old CWN
finch - static site generator
═════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-finch-static-site-generator/6026/1]
roddy announced
───────────────
Announcing [finch], a simple static site generator. It uses content
written as Markdown plus YAML frontmatter like Jekyll/Hugo etc. and
produces output with [Jingoo] templates. It also has some integrations
with React (as in the JS library) in the form of Jingoo filters: the
motivation behind it was to make it easier to develop sites that use
React just for some in some parts rather than structuring the whole
site as a single page application.
[finch] https://github.com/roddyyaga/finch
[Jingoo] https://github.com/tategakibunko/jingoo
ANN: Releases of ringo
══════════════════════
Archive: [https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/3]
Raphaël Proust announced
────────────────────────
Version 0.5 of `ringo' and `ringo-lwt' are now available in
`opam'. Although this version changes `ringo-lwt' only, both packages
are released anew to keep the version numbers in sync. This version
includes:
• Improvement in documentation.
• Simplifications and reduction in the memory footprint of lwt-wrapped
caches.
• Fix for a race condition in the automatic cleanup (previously, on
weak caches only, a promise being rejected could cause a different
promise to be removed from the cache)
• Fix a leak
• More test, including a test for leakiness.
OCaml 4.11, first beta release
══════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-first-beta-release/6042/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is approaching.
After three alpha releases, we have created a first beta version to
help you adapt your software to the new features ahead of the release.
The compatibility of the opam ecosystem with OCaml 4.11.0 is currently
quite good, and it should be possible to test this beta without too
much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta1.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta1.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.11.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+beta1+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
We want to know about all bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
If you are interested by the list of new features, and the on-going
list of bug fixes the updated change log for OCaml 4.11.0 is available
at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
Compared to the last alpha release, this first beta release contains
the following new bug fixes:
Driver
╌╌╌╌╌╌
• [#9011]: Allow linking .cmxa files with no units on MSVC by not
requiring the .lib file to be present. (David Allsopp, report by
Dimitry Bely, review by Xavier Leroy)
[#9011] https://github.com/ocaml/ocaml/issues/9011
Typechecker
╌╌╌╌╌╌╌╌╌╌╌
• [#9384], [#9385]: Fix copy scope bugs in substitutions (Leo White,
review by Thomas Refis, report by Nick Roberts)
• [#9695], [#9702]: no error when opening an alias to a missing module
(Jacques Garrigue, report and review by Gabriel Scherer)
[#9384] https://github.com/ocaml/ocaml/issues/9384
[#9385] https://github.com/ocaml/ocaml/issues/9385
[#9695] https://github.com/ocaml/ocaml/issues/9695
[#9702] https://github.com/ocaml/ocaml/issues/9702
Warnings
╌╌╌╌╌╌╌╌
• [#7897], [#9537]: Fix warning 38 for rebound extension constructors
(Leo White, review by Florian Angeletti)
• [#9244]: Fix some missing usage warnings (Leo White, review by
Florian Angeletti)
[#7897] https://github.com/ocaml/ocaml/issues/7897
[#9537] https://github.com/ocaml/ocaml/issues/9537
[#9244] https://github.com/ocaml/ocaml/issues/9244
Toplevel
╌╌╌╌╌╌╌╌
• [#9415]: Treat `open struct' as `include struct' in toplevel (Leo
White, review by Thomas Refis)
• [#9416]: Avoid warning 58 in flambda ocamlnat (Leo White, review by
Florian Angeletti)
[#9415] https://github.com/ocaml/ocaml/issues/9415
[#9416] https://github.com/ocaml/ocaml/issues/9416
Flambda backend
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9163]: Treat loops properly in un_anf (Leo White, review by Mark
Shinwell, Pierre Chambart and Vincent Laviron)
[#9163] https://github.com/ocaml/ocaml/issues/9163
FlexDLL 0.38 released
═════════════════════
Archive: [https://discuss.ocaml.org/t/flexdll-0-38-released/6043/1]
David Allsopp announced
───────────────────────
We are pleased to announce the release of FlexDLL 0.38!
FlexDLL provides a dlopen-like interface for Windows and is used to
simplify the linking process for the native Windows ports of OCaml and
to allow dynamic loading of C code (bytecode stub libraries and native
Dynlink). It is also used for the same purpose in the Cygwin ports of
OCaml, except that they can be configured without shared library
support.
The release includes various bugfixes as well as proper support for
C++ linking on mingw and linking against data symbols in import
libraries.
Please see the [release page] for more information.
[release page] https://github.com/alainfrisch/flexdll/releases/tag/0.38
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-C 21.1 (Scandium) is out. Download it here.]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-C 21.1 (Scandium) is out. Download it here.]
http://frama-c.com/index.html
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 20340 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-07 10:05 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-07-07 10:05 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 25998 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 30 to July
07, 2020.
Table of Contents
─────────────────
Releases of ringo
Multicore OCaml: June 2020
Time expression demo
Interactive OCaml development with utop in Emacs
Old CWN
Releases of ringo
═════════════════
Archive: [https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/5]
Continuing this thread, Raphaël Proust said
───────────────────────────────────────────
Ringo provides bounded-size key-value stores. More specifically, it
provides a functor similar to `Hastbl.Make' except that the number of
bindings held by the tables is limited: inserting additional bindings
when the limit has been reached causes some previously inserted
binding to be removed.
More more specifically, Ringo provides a function `map_maker' that
takes parameters to customise the policies that determine the
behaviour of the cache when supernumerary bindings are inserted, and
returns the functor described above. Once a module `Cache' is
instantiated using this functor, it can be used as follows:
┌────
│ let cache = Cache.create size
│ let fetch_data uri =
│ match Cache.find_opt cache uri with
│ | Some data -> data
│ | None ->
│ let data = really_fetch_data uri in
│ Cache.replace cache uri data;
│ data
└────
The cache will only hold up to [size] bindings, which avoids leaking
memory. Additionally, the parameters for `map_maker' allow you to
customise:
• The replacement policy: which binding is removed when a
supernumerary is inserted (currently supports least-recently used
and first-in first-out).
• The overflow policy: whether the cache can weakly hold some
supernumerary elements (if so, the cache may hold more but the GC
can always collect them if space is lacking).
• The accounting precision: whether to keep precise track of
removed/replaced elements.
In addition, Ringo also provide set-caches: i.e., sets (rather than
maps) with bounded size and all the same properties as above.
Also note Ringo-Lwt (`ringo-lwt') provides Lwt wrappers around Ringo
caches.
If you have suggestions for a different concise synopsis for `opam',
feel free to send them this way.
Use cases are, I guess, caches. In particular those that might receive
many elements not all of which you can hold in memory. We use it in a
few places in the Tezos project to hold resources (blocks, operations,
etc.) that are fetched from the P2p layer: it avoids having to fetch
them again from the network.
I think `anycache', `lru', and `lru-cache' are all alternatives
available on opam.
Raphaël Proust later added
──────────────────────────
The documentation is now available online at
[https://nomadic-labs.gitlab.io/ringo/index.html]
Of particular interest:
• [The signature for a `ringo' key-value cache]
• [The entry point for the `ringo' library] (allowing you to
instantiate modules with the above signature as well as simple value
caches)
• [The signature for `ringo-lwt' cache]
[The signature for a `ringo' key-value cache]
https://nomadic-labs.gitlab.io/ringo/ringo/Ringo/module-type-CACHE_MAP/index.html
[The entry point for the `ringo' library]
https://nomadic-labs.gitlab.io/ringo/ringo/Ringo/index.html
[The signature for `ringo-lwt' cache]
https://nomadic-labs.gitlab.io/ringo/ringo-lwt/Ringo_lwt/Sigs/module-type-CACHE_MAP/index.html
Multicore OCaml: June 2020
══════════════════════════
Archive:
[https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047/1]
Anil Madhavapeddy announced
───────────────────────────
Welcome to the June 2020 [Multicore OCaml] report! As with [previous
updates], many thanks to @shakthimaan and @kayceesrk for collating the
updates for the month of June 2020. /This is an incremental update;
new readers may find it helpful to flick through the previous posts
first./
This month has seen a tremendous surge of activity on the upstream
OCaml project to prepare for multicore integration, as @xavierleroy
and the core team have driven a number of initiatives to prepare the
OCaml project for the full multicore featureset. To reflect this,
from next month we will have a status page on the ocaml-multicore wiki
with the current status of both our multicore branch and the upstream
OCaml project itself.
Why not from this month? Well, there's good news and bad news. [Last
month], I observed that we are a PR away from most of the opam
ecosystem working with the multicore branch. The good news is that we
are still a single PR away from it working, but it's a different one
:-) The retrofitting of the `Threads' library has brought up [some
design complexities], and so rather than putting in a "bandaid" fix,
we are integrating a comprehensive solution that will work with system
threads, domains and (eventually) fibres. That work has taken some
time to get right, and I hope to be able to update you all on an
opam-friendly OCaml 4.10.0+multicore in a few weeks.
Aside from this, there have been a number of other improvements going
into the multicore branches: [mingw Windows support], [callstack
improvements], [fixing the Unix module] and so on. The full list is in
the detailed report later in this update.
[Multicore OCaml] https://github.com/ocaml-multicore/ocaml-multicore
[previous updates] https://discuss.ocaml.org/tag/multicore-monthly
[Last month]
https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898
[some design complexities]
https://github.com/ocaml-multicore/ocaml-multicore/pull/342
[mingw Windows support]
https://github.com/ocaml-multicore/ocaml-multicore/pull/351
[callstack improvements]
https://github.com/ocaml-multicore/ocaml-multicore/pull/363
[fixing the Unix module]
https://github.com/ocaml-multicore/ocaml-multicore/pull/346
Sandmark benchmarks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
A major milestone in this month has been the upgrade to the latest
dune.2.6.0 to build Multicore OCaml 4.10.0 for the Sandmark
benchmarking project. A number of new OPAM packages have been added,
and the existing packages have been upgraded to their latest
versions. The Multicore OCaml code base has seen continuous
performance improvements and enhancements which can be observed from
the various PRs mentioned in the report.
We would like to thank:
• @xavierleroy for working on a number of multicore-prequisite PRs to
make stock OCaml ready for Multicore OCaml.
• @camlspotter has reviewed and accepted the camlimages changes and
made a release of camlimages.5.0.3 required for Sandmark.
• @dinosaure for updating the decompress test benchmarks for Sandmark
to build and run with dune.2.6.0 for Multicore OCaml 4.10.0.
A chapter on Parallel Programming in Multicore OCaml with topics on
task pool, channels section, profiling with code examples is being
written. We shall provide an early draft version of the document to
the community for your valuable feedback.
Papers
╌╌╌╌╌╌
Our "Retrofitting Parallism onto OCaml" paper has been officially
accepted at [ICFP 2020] which will be held virtually between August
23-28, 2020. A [preprint] of the paper was made available earlier, and
will be updated in a few days with the camera-ready version for ICFP.
Please do feel free to send on comments and queries even after the
paper is published, of course.
Excitingly, another multicore-related paper on [Cosmo: A Concurrent
Separation Logic for Multicore OCaml] will also be presented at the
same conference.
The Multicore OCaml updates are first listed in our report, which are
followed by improvements to the Sandmark benchmarking
project. Finally, the changes made to upstream OCaml which include
both the ongoing and completed tasks are mentioned for your reference.
[ICFP 2020]
https://icfp20.sigplan.org/track/icfp-2020-papers#event-overview
[preprint] https://arxiv.org/abs/2004.11663
[Cosmo: A Concurrent Separation Logic for Multicore OCaml]
http://gallium.inria.fr/~fpottier/publis/mevel-jourdan-pottier-cosmo-2020.pdf
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore#339] Proposal for domain-local
storage
An RFC proposal to implement a domain-local storage in Multicore
OCaml. Kindly review the idea and share your feedback!
• [ocaml-multicore/ocaml-multicore#342] Implementing the threads
library with Domains
An effort to rebase @jhwoodyatt's implementation of the Thread
library for Domains.
• [ocaml-multicore/ocaml-multicore#357] Implementation of systhreads
with pthreads
Exploring the possibilty of implementing systhreads with pthreads,
while still maintaining compatibility with the existing solution.
• [ocaml/dune#3548] Dune fails to pick up secondary compiler
The `ocaml-secondary-compiler' fails to install with
dune.2.6.0. This is required as Multicore OCaml cannot build the
latest dune without systhreads support.
[ocaml-multicore/ocaml-multicore#339]
https://github.com/ocaml-multicore/ocaml-multicore/issues/339
[ocaml-multicore/ocaml-multicore#342]
https://github.com/ocaml-multicore/ocaml-multicore/pull/342
[ocaml-multicore/ocaml-multicore#357]
https://github.com/ocaml-multicore/ocaml-multicore/issues/357
[ocaml/dune#3548] https://github.com/ocaml/dune/issues/3548
◊ Completed
• [ocaml-multicore/multicore-opam#22] Update dune to 2.6.0
The dune version in the Multicore OPAM repository is now updated to
use the latest 2.6.0.
• [ocaml-multicore/ocaml-multicore#338] Introduce Lazy.try_force and
Lazy.try_force_val
An implementation of `Lazy.try_force' and `Lazy.try_force_val'
functions to implement concurrent lazy abstractions.
• [ocaml-multicore/ocaml-multicore#340] Fix Atomic.exchange in
concurrent_minor_gc
A patch that introduces `Atomic.exchange' through `Atomic.get' that
provides the appropriate read barrier for correct exchange semantics
for `caml_atomic_exchange' in `memory.c'.
• [ocaml-multicore/ocaml-multicore#343] Fix extcall noalloc DWARF
The DWARF information emitted for `extcall noalloc' had broken
backtraces and this PR fixes the same.
• [ocaml-multicore/ocaml-multicore#345] Absolute exception stack
The representation of the exception stack is changed from relative
addressing to absolute addressing and the results are promising. The
Sandmark serial benchmark results after the change is illustrated in
the following graph:
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/b385409b3f9e44cbfef98de668b0b4d0ed403472_2_1380x436.png]
• [ocaml-multicore/ocaml-multicore#347] Turn on -Werror by default
Adds a `--enable-warn-error' option to `configure' to treat C
compiler warnings as errors.
• [ocaml-multicore/ocaml-multicore#353] Poll for interrupts in
cpu_relax without locking
Use `Caml_check_gc_interrupt' first to poll for interrupts without
locking, and then proceeding to handle the interrupt with the lock.
• [ocaml-multicore/ocaml-multicore#354] Add Caml_state_field to
domain_state.h
The `Caml_state_field' macro definition in domain_state.h is
required for base-v0.14.0 to build for Multicore OCaml 4.10.0 with
dune.2.6.0.
• [ocaml-multicore/ocaml-multicore#355] One more location to poll for
interrupts without lock
Another use of `Caml_check_gc_interrupt' first to poll for
interrupts without lock, similar to
[ocaml-multicore/ocaml-multicore#353].
• [ocaml-multicore/ocaml-multicore#356] Backup threads for domain
Introduces `backup threads' to perform GC and handle service
interrupts when the domain is blocked in the kernel.
• [ocaml-multicore/ocaml-multicore#358] Fix up bad CFI information in
amd64.S
Add missing `CFI_ADJUST' directives in `runtime/amd64.S' for
`caml_call_poll' and `caml_allocN'.
• [ocaml-multicore/ocaml-multicore#359] Inline caml_domain_alone
The PR makes `caml_domain_alone' an inline function to improve
performance for `caml_atomic_cas_field' and other atomics in
`memory.c'.
• [ocaml-multicore/ocaml-multicore#360] Parallel minor GC inline mask
rework
The inline mask rework for the promotion path to the
`parallel_minor_gc' branch gives a 3-5% performance improvement for
`test_decompress' sandmark benchmark, and a decrease in the executed
instructions for all other benchmarks.
• [ocaml-multicore/ocaml-multicore#361] Mark stack push work credit
The PR improves the Multicore mark work accounting to be in line
with stock OCaml.
• [ocaml-multicore/ocaml-multicore#362] Iloadmut does not clobber rax
and rdx when we do not have a read barrier
A code clean-up to free the registers `rax' and `rdx' for OCaml code
when `Iloadmut' is used.
[ocaml-multicore/multicore-opam#22]
https://github.com/ocaml-multicore/multicore-opam/pull/22
[ocaml-multicore/ocaml-multicore#338]
https://github.com/ocaml-multicore/ocaml-multicore/pull/338
[ocaml-multicore/ocaml-multicore#340]
https://github.com/ocaml-multicore/ocaml-multicore/pull/340
[ocaml-multicore/ocaml-multicore#343]
https://github.com/ocaml-multicore/ocaml-multicore/pull/343
[ocaml-multicore/ocaml-multicore#345]
https://github.com/ocaml-multicore/ocaml-multicore/pull/345
[ocaml-multicore/ocaml-multicore#347]
https://github.com/ocaml-multicore/ocaml-multicore/pull/347
[ocaml-multicore/ocaml-multicore#353]
https://github.com/ocaml-multicore/ocaml-multicore/pull/353
[ocaml-multicore/ocaml-multicore#354]
https://github.com/ocaml-multicore/ocaml-multicore/pull/354
[ocaml-multicore/ocaml-multicore#355]
https://github.com/ocaml-multicore/ocaml-multicore/pull/355
[ocaml-multicore/ocaml-multicore#356]
https://github.com/ocaml-multicore/ocaml-multicore/pull/356
[ocaml-multicore/ocaml-multicore#358]
https://github.com/ocaml-multicore/ocaml-multicore/pull/358
[ocaml-multicore/ocaml-multicore#359]
https://github.com/ocaml-multicore/ocaml-multicore/pull/359
[ocaml-multicore/ocaml-multicore#360]
https://github.com/ocaml-multicore/ocaml-multicore/pull/360
[ocaml-multicore/ocaml-multicore#361]
https://github.com/ocaml-multicore/ocaml-multicore/pull/361
[ocaml-multicore/ocaml-multicore#362]
https://github.com/ocaml-multicore/ocaml-multicore/pull/362
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-bench/sandmark#8] Ability to run compiler variants in
Sandmark
A feature to specify configure options when building compiler
variants such as `flambda' is useful for development and
testing. This feature is being worked upon.
• [ocaml-bench/sandmark#107] Add Coq benchmarks
We are continuing to add more benchmarks to Sandmark for Multicore
OCaml and investigating adding the [Coq] benchmarks to our
repertoire!
• [ocaml-bench/sandmark#124] User configurable paramwrapper added to
Makefile
A `PARAMWRAPPER' environment variable can be passed as an argument
by specifying the `--cpu-list' to be used for parallel benchmark
runs.
• [ocaml-bench/sandmark#131] Update decompress benchmarks
Thanks to @dinosaure for updating the decompress benchmarks in order
to run them with dune.2.6.0 for Multicore OCaml 4.10.0.
• [ocaml-bench/sandmark#132] Update dependency packages to use
dune.2.6.0 and Multicore OCaml 4.10.0
Sandmark has been running with dune.1.11.4, and we need to move to
the latest dune.2.6.0 for using Multicore OCaml 4.10.0 and beyond,
as mentioned in [Promote dune to > 2.0]. The PR updates over 30
dependency packages and successfully builds both serial and parallel
benchmarks!
[ocaml-bench/sandmark#8]
https://github.com/ocaml-bench/sandmark/issues/8
[ocaml-bench/sandmark#107]
https://github.com/ocaml-bench/sandmark/issues/107
[Coq] https://coq.inria.fr/
[ocaml-bench/sandmark#124]
https://github.com/ocaml-bench/sandmark/pull/124
[ocaml-bench/sandmark#131]
https://github.com/ocaml-bench/sandmark/pull/131
[ocaml-bench/sandmark#132]
https://github.com/ocaml-bench/sandmark/pull/132
[Promote dune to > 2.0]
https://github.com/ocaml-bench/sandmark/issues/106
◊ Completed
• [camlspotter/camlimages#1] Use dune-configurator instead of
configurator for camlimages
A new release of `camlimages.5.0.3' was made by @camlspotter after
accepting the changes to camlimages.opam in order to build with
dune.2.6.0.
• [ocaml-bench/sandmark#115] Task API Port: LU-Decomposition, Floyd
Warshall, Mandelbrot, Nbody
The changes to use the `Domainslib.Task' API for the listed
benchmarks have been merged.
• [ocaml-bench/sandmark#121] Mention sudo access for
run_all_parallel.sh script
The README.md file has been updated with the necessary `sudo'
configuration steps to execute the `run_all_parallel.sh' script for
nightly builds.
• [ocaml-bench/sandmark#125] Add cubicle benchmarks
The `German PFS' and `Szymanski's mutual exclusion algorithm'
cubicle benchmarks have been included in Sandmark.
• [ocaml-bench/sandmark#126] Update ocaml-versions README to reflect
4.10.0+multicore
The README has now been updated to reflect the latest 4.10.0
Multicore OCaml compiler and its variants.
• [ocaml-bench/sandmark#129] Add target to run parallel benchmarks in
the CI
The .drone.yml file used by the CI has been updated to run both the
serial and parallel benchmarks.
• [ocaml-bench/sandmark#130] Add missing dependencies in
multicore-numerical
The `domainslib' library has been added to the dune file for the
multicore-numerical benchmark.
[camlspotter/camlimages#1]
https://gitlab.com/camlspotter/camlimages/-/merge_requests/1
[ocaml-bench/sandmark#115]
https://github.com/ocaml-bench/sandmark/pull/115
[ocaml-bench/sandmark#121]
https://github.com/ocaml-bench/sandmark/pull/121
[ocaml-bench/sandmark#125]
https://github.com/ocaml-bench/sandmark/pull/125
[ocaml-bench/sandmark#126]
https://github.com/ocaml-bench/sandmark/pull/126
[ocaml-bench/sandmark#129]
https://github.com/ocaml-bench/sandmark/pull/129
[ocaml-bench/sandmark#130]
https://github.com/ocaml-bench/sandmark/pull/130
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9541] Add manual page for the instrumented runtime
The [instrumented runtime] has been merged to OCaml 4.11.0. A manual
for the same has been created and is under review.
• [sadigqj/ocaml#1] GC colours change
This PR removes the grey colour used in stock OCaml to match the
scheme used by the Multicore major collector. The performance and
considerations are included for review.
[ocaml/ocaml#9541] https://github.com/ocaml/ocaml/pull/9541
[instrumented runtime] https://github.com/ocaml/ocaml/pull/9082
[sadigqj/ocaml#1] https://github.com/sadiqj/ocaml/pull/1
◊ Completed
• [ocaml/ocaml#9619] A self-describing representation for function
closures
The PR provides a way to record the position of the environment for
each entry point for function closures.
• [ocaml/ocaml#9649] Marshaling for the new closure representation
The `output_value' marshaler has been updated to use the new closure
representation. There is no change required for the `input_value'
unmarshaler.
• [ocaml/ocaml#9655] Introduce type Obj.raw_data and functions
Obj.raw_field, Obj.set_raw_field to manipulate out-of-heap pointers
The PR introduces a type `Obj.bits', and functions `Obj.field_bits'
and `Obj.set_field_bits' to read and write bit representation of
block fields to support the no-naked-pointer operation.
• [ocaml/ocaml#9678] Reimplement Obj.reachable_word using a hash table
to detect sharing
The `caml_obj_reachable_words' now uses a hash table instead of
modifying the mark bits of block headers to detect sharing. This is
required for compatibility with Multicore OCaml.
• [ocaml/ocaml#9680] Naked pointers and the bytecode interpreter
The bytecode interpreter implementation is updated to support the
no-naked-pointers mode operation as required by Multicore OCaml.
• [ocaml/ocaml#9682] Signal handling in native code without the page
table
The patch uses the code fragment table instead of a page table
lookup for signal handlers to know whether the signal came from
ocamlopt-generated code.
• [ocaml/ocaml#9683] globroots.c: adapt to no-naked-pointers mode
The patch considers out-of-heap pointers as major-heap pointers in
no-naked-pointers mode for global roots management.
• [ocaml/ocaml#9689] Generic hashing for the new closure
representation
The hashing functions have been updated to use the latest closure
representation from [ocaml/ocaml#9619] for the no-naked-pointers
mode.
• [ocaml/ocaml#9698] The end of the page table is near
The PR eliminates some of the use of the page tables in the runtime
system when built with no-naked-pointers mode.
Our thanks to all the OCaml developers and users in the community for
their continued support and contribution to the project. Stay safe!
[ocaml/ocaml#9619] https://github.com/ocaml/ocaml/pull/9619
[ocaml/ocaml#9649] https://github.com/ocaml/ocaml/pull/9649
[ocaml/ocaml#9655] https://github.com/ocaml/ocaml/pull/9655
[ocaml/ocaml#9678] https://github.com/ocaml/ocaml/pull/9678
[ocaml/ocaml#9680] https://github.com/ocaml/ocaml/pull/9680
[ocaml/ocaml#9682] https://github.com/ocaml/ocaml/pull/9682
[ocaml/ocaml#9683] https://github.com/ocaml/ocaml/pull/9683
[ocaml/ocaml#9689] https://github.com/ocaml/ocaml/pull/9689
[ocaml/ocaml#9698] https://github.com/ocaml/ocaml/pull/9698
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• CFI: Call Frame Information
• CI: Continuous Integration
• DWARF: Debugging With Attributed Record Formats
• GC: Garbage Collector
• ICFP: International Conference on Functional Programming
• OPAM: OCaml Package Manager
• PR: Pull Request
• RFC: Request for Comments
Time expression demo
════════════════════
Archive: [https://discuss.ocaml.org/t/time-expression-demo/6052/1]
Darren announced
────────────────
An interactive demo for a small part of our time stuff and schedule
handling library is available here:
[https://daypack-dev.github.io/time-expr-demo/]
Time expression is in essence a language for specifying time points or
time slots precisely and concisely, while trying to mimic natural
language.
The implementation of the demo core itself can be seen here:
[https://github.com/daypack-dev/time-expr-demo/blob/master/src/demo.ml]
, where the usage of Daypack-lib is shown.
Lastly, the library is still a prototype, so expect some faults in the
outputs of the demo here and there.
Interactive OCaml development with utop in Emacs
════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/interactive-ocaml-development-with-utop-in-emacs/6058/1]
Samarth Kishor announced
────────────────────────
I made a [blog post] about REPL driven development with utop in Emacs
a few months ago. Please let me know if you found it useful or have
anything to add! I'm a bit new to OCaml so any feedback helps.
There was a [similar post about REPL driven development] last year and
my post addresses a lot of those points. I wish I'd seen that post
before I wrote this since there's a ton of useful information in the
comments.
[blog post]
https://samarthkishor.github.io/posts/interactive_ocaml_development/
[similar post about REPL driven development]
https://discuss.ocaml.org/t/ocaml-repl-driven-development/4068
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 39647 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-14 9:55 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-07-14 9:55 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7882 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 07 to 14,
2020.
Table of Contents
─────────────────
OCaml 4.11.0, second beta release
letters - simple client abstractions for sending emails over SMTP
A question about Ocaml
Alcotest 1.2.0
Set up OCaml 1.1.0
Old CWN
OCaml 4.11.0, second beta release
═════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-second-beta-release/6063/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is approaching. As one step further in
this direction, we have published a second beta release. This new
release fixes an MSVC-specific runtime issue.
The compatibility of the opam ecosystem with OCaml 4.11.0 is currently
quite good with only 7 packages not currently available, and it should
be possible to test this beta without too much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta2.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta2.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands:
┌────
│ opam switch create ocaml-variants.4.11.0+beta2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+beta2+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these: afl, flambda, fp,
fp+flambda
We would love to hear about any bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
If you are interested by the list of new features, and the on-going
list of bug fixes the updated change log for OCaml 4.11.0 is available
at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
Compared to the previous beta release, the exhaustive list of changes
is as follows:
Runtime
╌╌╌╌╌╌╌
• [#9714], [#9724]: Use the C++ alignas keyword when compiling in
C++. Fixes a bug with MSVC C++ 2015/2017. Add a terminator to the
`caml_domain_state' structure to better ensure that members are
correctly spaced. (Antonin Décimo, review by David Allsopp and
Xavier Leroy)
[#9714] https://github.com/ocaml/ocaml/issues/9714
[#9724] https://github.com/ocaml/ocaml/issues/9724
Manual and documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#8644]: fix formatting comment about @raise in stdlib's mli files
(Élie Brami, review by David Allsopp)
• [#9712]: Update the version format to allow "`". The new format is
"major.minor[.patchlevel][(+|')additional-info]", for instance
"4.12.0~beta1+flambda". This is a documentation-only change for the
4.11 branch, the new format will be used starting with the 4.12
branch. (Florian Angeletti, review by Damien Doligez and Xavier
Leroy)
[#8644] https://github.com/ocaml/ocaml/issues/8644
[#9712] https://github.com/ocaml/ocaml/issues/9712
letters - simple client abstractions for sending emails over SMTP
═════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-letters-simple-client-abstractions-for-sending-emails-over-smtp/6071/1]
Miko announced
──────────────
Earlier today I've published the first release of [letters]. This
library aims to provide simple to use client library for sending
emails over SMTP using _lwt_ for async execution.
It is build on top of _mrmime_ and _colombe_. While these libraries
are very capable, they aren't that simple to use, _letters_ is trying
to fill that gap. Anyway, big thanks for the authors of these projects
for doing the heavy lifting.
As this library is still in its early stage, I believe I will break
the API with first few releases. Luckily the API is quite simple so
following these changes should be quite easy.
To make this library awesome, any feedback or feature request is
welcome. I'll try to address them as quickly as I can.
I hope I've managed to scratch someone else's itch too, enjoy.
[letters] https://github.com/oxidizing/letters
A question about Ocaml
══════════════════════
Archive: [https://discuss.ocaml.org/t/a-question-about-ocaml/6075/21]
Deep in this theard, Yawar Amin said
────────────────────────────────────
A few ReasonML books:
• [Web Development With ReasonML]
• [Exploring ReasonML] (free online)
• [Learn Type-Driven Development] (co-authored by me)
[Web Development With ReasonML] https://pragprog.com/titles/reasonml/
[Exploring ReasonML] http://reasonmlhub.com/exploring-reasonml/toc.html
[Learn Type-Driven Development]
https://www.packtpub.com/application-development/learn-type-driven-development
Alcotest 1.2.0
══════════════
Archive: [https://discuss.ocaml.org/t/ann-alcotest-1-2-0/6089/1]
Craig Ferguson announced
────────────────────────
I'm pleased to announce the release of [Alcotest] 1.2.0, now available
on Opam.
This release includes:
• a new `alcotest-mirage' package for running tests on MirageOS;
• full UTF-8 support;
• default coloured output in Dune (without needing to pass
`--no-buffer');
• an improved output format.
The full changelog is available [here].
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/ac89cfe4dfeed063560212136c9e2b690a888b6c.png]
Thanks to our many contributors in this release cycle.
[Alcotest] https://github.com/mirage/alcotest/
[here] https://github.com/mirage/alcotest/blob/1.2.0/CHANGES.md
Set up OCaml 1.1.0
══════════════════
Archive: [https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-0/6093/1]
Sora Morimoto announced
───────────────────────
This release contains these changes:
• The default opam repository can now be set via input.
• Linux VMs now use opam 2.0.7.
[https://github.com/avsm/setup-ocaml/releases/tag/v1.1.0]
Sora Morimoto then added
────────────────────────
In fact, this release was a long time ago, but I completely forgot to
post this. By the way, we have made significant improvements to some
of the documentation. In particular, the action versioning section is
applicable to other GitHub Actions and definitely worth reading!
[https://github.com/avsm/setup-ocaml#how-to-specify-the-version]
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 20500 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-21 14:43 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-07-21 14:43 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7349 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 14 to 21,
2020.
Table of Contents
─────────────────
Dune-release: version 1.4.0 released
Using AF_XDP sockets for high-performance packet processing in OCaml
Ubase 0.03
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
Old CWN
Dune-release: version 1.4.0 released
════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/dune-release-version-1-4-0-released/6103/1]
Sonja Heinze announced
──────────────────────
This post is about [dune-release], a tool that helps users release
their packages to Opam in a fast and organized manner. You can install
it via `opam install dune-release'.
On behalf of the dune-release team at Tarides, I'm happy to announce
the new dune-release [1.4.0 release]. The release includes two new
subcommands described below and a variety of bug fixes and user
experience improvements. In particular, we've put some work into
improving the error handling and reporting.
One of the new subcommands is `dune-release config' , which inspects
and edits dune-release's global configuration, such as git related,
opam related and github related data. For example, if you insert a
typo when being asked for your github id during your first release
with dune-release, you can correct it comfortably with that new
subcommand.
The other new subcommand is `dune-release delegate-info', which helps
users with an alternative release workflow to integrate dune-release
into it: imagine you want to use dune-release only for a couple of
things, such as tagging the distribution and creating the distribution
tarball and the documentation. In that case, now you can integrate
the work done by dune-release into your individual release workflow by
accessing the path to the created tarball etc via `dune-release
delegate-info'. It forms part of the broader change in progress
described in the following post:
[https://discuss.ocaml.org/t/replacing-dune-release-delegates/4767]
[dune-release] https://github.com/ocamllabs/dune-release/#readme
[1.4.0 release]
https://github.com/ocamllabs/dune-release/releases/tag/1.4.0
Using AF_XDP sockets for high-performance packet processing in OCaml
════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/using-af-xdp-sockets-for-high-performance-packet-processing-in-ocaml/6106/1]
suttonshire announced
─────────────────────
I just wanted to share a fun result from a project I've been hacking
on. [ocaml-xsk] is a binding to AF_XDP interface of libbpf.
AF_XDP is an address family in Linux for high-performance packet
processing. With an AF_XDP socket a packet bypasses most of the kernel
networking stack and is passed directly to userspace program.
Depending on the configuration packets can be passed from the NIC
without any data copies on either Rx or Tx. If you're interested in
this kind of stuff here are a couple very useful resources:
• [https://github.com/torvalds/linux/blob/master/Documentation/networking/af_xdp.rst]
• [https://github.com/xdp-project/xdp-tutorial/tree/master/advanced03-AF_XDP]
The cool part is that without installing large dependencies like DPDK
you can get packets into your program basically as fast as your NIC
can provide them! It turns out this is true even if your program is
written in OCaml. Using ocaml-xsk I could receive or transmit 64 byte
UDP packets at 14.8M packets per second. This is the limit for a
10Gb/s NIC.
I'm still trying to figure out the best interface for AF_XDP. There
are several resources to manage, and simple receive and transmit
operations actually require a few steps. But it's encouraging know
OCaml doesn't get in the way of packet throughput.
[ocaml-xsk] https://github.com/suttonshire/ocaml-xsk
Ubase 0.03
══════════
Archive: [https://discuss.ocaml.org/t/ann-ubase-0-03/6115/1]
sanette announced
─────────────────
I'm happy to announce the release of [ubase], a tiny library whose
only purpose is to remove diacritics (accents, etc.) from utf8-encoded
strings using the latin alphabet.
It was created after the discussion:
[https://discuss.ocaml.org/t/simplify-roman-utf8/4398].
It's now available from `opam':
`opam install ubase'
This also installs an executable that you may use in a shell, for
instance:
┌────
│ $ ubase "et grønt træ"
│ et gront trae
│
│ $ ubase Anh xin lỗi các em bé vì đã đề tặng cuốn sách này cho một ông người lớn.
│ Anh xin loi cac em be vi da de tang cuon sach nay cho mot ong nguoi lon.
└────
More info [here].
[ubase] https://github.com/sanette/ubase
[here] https://sanette.github.io/ubase/
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
═══════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-clangml-4-2-0-ocaml-bindings-for-clang-api-for-c-and-c-parsing/6123/1]
Thierry Martinez announced
──────────────────────────
We are happy to announce the new clangml 4.2.0 release. Clangml
provides bindings for all versions of Clang, from 3.4 to the not yet
released 10.0.1.
The library can be installed via opam: `opam install clangml' The
documentation is online:
[https://memcad.gitlabpages.inria.fr/clangml/]
This new release improves C++ support, including C++20 specific
constructs.
All Clang C/C++ attributes should now be supported. You may have a
look to the interface of the new auto-generated module [`Attributes'].
There is now a lazy version of the AST (`Clang.Lazy.Ast'): this is
useful to explore large ASTs efficiently (note that Clang parsing
itself can still be slow; the lazy part only concerns the conversion
into the `Clang.Lazy.Ast' datatypes).
[`Attributes']
https://memcad.gitlabpages.inria.fr/clangml/doc/clangml/Clang__/Attributes/
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 18807 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-28 16:58 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-07-28 16:58 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 23258 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 21 to 28,
2020.
As I will be away with no internet next week, the next CWN will be on
August 11.
Table of Contents
─────────────────
Embedded ocaml templates
Proposal: Another way to debug memory leaks
Camlp5 (8.00~alpha01) and pa_ppx (0.01)
OCaml 4.11.0, third (and last?) beta release
Other OCaml News
Old CWN
Embedded ocaml templates
════════════════════════
Archive: [https://discuss.ocaml.org/t/embedded-ocaml-templates/6124/1]
Emile Trotignon announced
─────────────────────────
I am very happy to announce the release of ocaml-embedded-templates.
This is a tool similar to camlmix, but camlmix was not updated for 7
years, and there is no easy way to handle a lot of templates (my
command takes a directory as an argument and generate an ocaml module
by going through the directory recursively) I also choosed to use a
syntax similar to EJS, and there is a ppx for inline EML.
You can check it out here :
[https://github.com/EmileTrotignon/embedded_ocaml_templates]
Here is a more extensive exemple of what can be done with this :
[https://github.com/EmileTrotignon/resume_of_ocaml] (This project
generate my resume/website in both latex and html).
This is my first opam package : feedback is very much welcome.
Proposal: Another way to debug memory leaks
═══════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/proposal-another-way-to-debug-memory-leaks/6134/1]
Jim Fehrle said
───────────────
`memprof' helps you discover where memory was allocated, which is
certainly useful. However, that may not be enough information to
isolate a leak. Sometimes you'd like to know what variables refer to
excessive amounts of memory.
For this, you'd want to examine all the garbage collection roots and
report how much memory is used by each. This is useful information if
you can map a GC root back to a source file and variable.
I prototyped code to do that to help with Coq bug
[https://github.com/coq/coq/issues/12487]. It localized several leaks
enough across over 500 source files so that we could find and fix
them. But my prototype code is a bit crude. I'd like to clean it up
and submit it as a PR. Since this could be done in various ways, I
wanted to get some design/API feedback up front rather than maybe
doing some of it twice. Also I'd like to confident that such a PR
would be accepted and merged in a reasonable amount of time–otherwise
why bother.
[caml_do_roots] shows how to access the GC roots. There are several
types of roots:
• global roots, corresponding to top-level variables in source files
• dynamic global roots
• stack and local roots
• global C roots
• finalized values
• memprof
• hook
*API (in Gc):*
┌────
│ val print_global_reachable : out_channel -> int -> unit
└────
Prints a list to `out_channel' of the global roots that reach more
than the specified number of words. Each item shows the number of
reachable words, the associated index of the root in the `*glob' for
that file and the name of the source file.
Something like this (but with only filenames rather than pathnames):
┌────
│ 102678 field 17 plugins/ltac/pltac.ml
│ 102730 field 18 plugins/ltac/pltac.ml
│ 164824 field 20 plugins/ltac/tacenv.ml
│ 1542857 field 26 plugins/ltac/tacenv.ml
│ 35253743 field 65 stm/stm.ml
│ 35201913 field 8 vernac/vernacstate.ml
│ 8991864 field 24 vernac/library.ml
│ 112035 field 8 vernac/egramml.ml
│ 6145454 field 84 vernac/declaremods.ml
│ 6435878 field 89 vernac/declaremods.ml
└────
I would use ELF information in the binary file to map from `*glob'
back to a filename. For example, the address symbol of the entry
`camlTest' corresponds to `test.ml'. This would only work for binary
executables compiled with the `-g' option. It wouldn't work for
byte-compiled code. It would print an error message if it's not ELF
or not `-g'. Also, being a little lazy, how essential is it to
support 32-bit binaries? (Q: What happens if you have 2 source files
with the same name though in different directories? Would the symbol
table distinguish them?)
┌────
│ val get_field_index : Obj.t -> int
└────
Returns the `*glob' index number for the top-level variable (passed as
`Obj.repr var'). I expect there's no way to recover variable names
from the `*glob' index. In my experiments, it appeared that the
entries in `*glob' were in the same order as as the variable and
function declarations. This would let a developer do a binary search
in the code to locate the variable which it probably a necessity for
large, complex files such as Coq's `stm.ml'–3300 lines, 10+ modules
defined within the file. (I noticed that variables defined in modules
defined within the source file were not in `*glob'. I expect there is
a root for the module as a whole and that those variables can be
readily found within that root.)
This would need an extended explanation in `gc.mli'.
┌────
│ val print_stack_reachable : out_channel -> int -> unit
└────
Prints a backtrace to `out_channel' that also shows which roots for
each frame reach more than the specified number of words. (I'd keep
the "item numbers" since there's no way to translate them to variables
and they might give some clues.)
┌────
│ Called from file "tactics/redexpr.ml" (inlined), line 207, characters 29-40
│ 356758154 item 0 (stack)
│ Called from file "plugins/ltac/tacinterp.ml", line 752, characters 6-51
│ 17646719 item 0 (stack)
│ 119041 item 1 (stack)
│ Called from file "engine/logic_monad.ml", line 195, characters 38-43
│ 119130 item 0 (stack)
│ 373378237 item 1 (stack)
└────
As it turns out, 90% of the memory in Coq issue mentioned above is
reachable only from the stack.
I didn't consider the other types of roots yet, which I don't fully
understand, such as local roots. Just covering global and stack roots
seems like a good contribution. Dynamic global roots may be easy to
add if they are otherwise similar to global roots. For the others I
could print the reachable words, but I don't know how to direct the
developer to look at the relevant part of the code, especially if it's
in C code. I suppose `print_global_reachable' and
`print_stack_reachable' could be a single routine as well. That's
probably better.
Let me know your thoughts.
[caml_do_roots]
https://github.com/ocaml/ocaml/blob/80326033cbedfe59c0664e3912f21017e968a1e5/runtime/roots_nat.c#L399
Camlp5 (8.00~alpha01) and pa_ppx (0.01)
═══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-camlp5-8-00-alpha01-and-pa-ppx-0-01/6144/1]
Chet Murthy announced
─────────────────────
`Camlp5 (8.00~alpha01)' and `pa_ppx (0.01)'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I'm pleased to announce the release of two related projects:
1. [Camlp5]: version 8.00~alpha01 is an alpha release of Camlp5, with
full support for OCaml syntax up to version 4.10.0, as well as
minimal compatibility with version 4.11.0. In particular there is
full support for PPX attributes and extensions.
2. [pa_ppx]: version 0.01 is a re-implementation of a large number of
PPX rewriters (e.g. ppx_deriving (std (show, eq, map, etc), yojson,
sexp, etc), ppx_import, ppx_assert, others) on top of Camlp5, along
with an infrastructure for developing new ones.
This allows projects to combine the existing style of Camlp5 syntax
extension, with PPX rewriting, without having to jump thru hoops to
invoke camlp5 on some files, and PPX processors on others.
Camlp5 alone is not compatible with existing PPX rewriters: Camlp5
syntax-extensions (e.g. "stream parsers") would be rejected by the
OCaml parser, and PPX extensions/attributes are ignored by Camlp5
(again, without `pa_ppx'). `pa_ppx' provides Camlp5-compatible
versions of many existing PPX rewriters, as well as new ones, so that
one can use Camlp5 syntax extensions as well as PPX rewriters. In
addition, some of the re-implemented rewriters are more-powerful than
their original namesakes, and there are new ones that add interesting
functionality.
[Camlp5] https://github.com/camlp5/camlp5
[pa_ppx] https://github.com/chetmurthy/pa_ppx
For democratizing macro-extension-authoring in OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
TL;DR Writing OCaml PPX rewriters is *hard work*. There is a
complicated infrastructure that is hard to explain, there are multiple
such incompatible infrastructures (maybe these are merging?) and it is
hard enough that most Ocaml programmers do not write macro-extensions
as a part of their projects. I believe that using Camlp5 and pa_ppx
can make it easier to write macro-extensions, via:
1. providing a simple way of thinking about adding your extension to
the parsing process.
2. providing transparent tools (e.g. quotations) for
pattern-matching/constructing AST fragments
Explained below in [Macro Extensions with
Pa_ppx](#macro-extensions-with-pa_ppx).
◊ The original arguments against Camlp4
The original argument against using Camlp4 as a basis for
macro-preprocessing in Ocaml, had several points (I can't find the
original document, but from memory):
1. *syntax-extension* as the basis of macro-extension leads to brittle
syntax: multiple syntax extensions often do not combine well.
2. a different AST type than the Ocaml AST
3. a different parsing/pretty-printing infrastructure, which must be
maintained alongside of Ocaml's own parser/pretty-printer.
4. A new and complicated set of APIs are required to write syntax
extensions.
To this, I'll add
1. Camlp4 was *forked* from Camlp5, things were changed, and hence,
Camlp4 lost the contribution of its original author. Hence,
maintaining Camlp4 was always labor that fell on the Ocaml
team. [Maybe this doesn't matter, but it counts for something.]
◊ Assessing the arguments, with some hindsight
1. *syntax-extension* as the basis of macro-extension leads to brittle
syntax: multiple syntax extensions often do not combine well.
In retrospect, this is quite valid: even if one prefers and enjoys
LL(1) grammars and parsing, when multiple authors write
grammar-extensions which are only combined by third-party projects,
the conditions are perfect for chaos, and of a sort that
project-authors simply shouldn't have to sort out. And this chaos
is of a different form, than merely having two PPX rewriters use
the same attribute/extension-names (which is, arguably, easily
detectable with some straightforward predeclaration).
2. Camlp4/5 has a different AST type than the Ocaml AST
Over time, the PPX authors themselves have slowly started to
conclude that the current reliance on the Ocaml AST is fraught with
problems. The "Future of PPX" discussion thread talks about using
something like s-expressions, and more generally about a
more-flexible AST type.
3. a different parsing/pretty-printing infrastructure, which must be
maintained alongside of Ocaml's own parser/pretty-printer.
A different AST type necessarily means a different
parser/pretty-printer. Of course, one could modify Ocaml's YACC
parser to produce Camlp5 ASTs, but this is a minor point.
4. A new and complicated set of APIs are required to write syntax
extensions.
With time, it's clear that PPX has produced the same thing.
5. Maintaining Camlp4 was always labor that fell on the Ocaml team.
The same argument (that each change to the Ocaml AST requires work
to update Camlp5) can be made for PPX (specifically, this is the
raison d'etre of ocaml-migrate-parsetree). Amusingly, one could
imagine using ocaml-migrate-parsetree as the basis for making
Camlp5 OCaml-version-independent, too. That is, the "backend" of
Camlp5 could use ocaml-migrate-parsetree to produce ASTs for a
version of OCaml different from the one on which it was compiled.
Arguments against the current API(s) of PPX rewriting
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The overall argument is that it's too complicated for most OCaml
programmers to write their own extensions; what we see instead of a
healthy ecosystem of many authors writing and helping-improve PPX
rewriters, is a small number of rewriters, mostly written by Jane
Street and perhaps one or two other shops. There are a few big
reasons why this is the case (which correspond to the responses
above), but one that isn't mentioned is:
1. When the "extra data" of a PPX extension or attribute is
easily-expressed with the fixed syntax of PPX payloads, all is
`~well~' ok, but certainly not in great shape. Here's an example:
┌────
│ type package_type =
│ [%import: Parsetree.package_type
│ [@with core_type := Parsetree.core_type [@printer Pprintast.core_type];
│ Asttypes.loc := Asttypes.loc [@polyprinter fun pp fmt x -> pp fmt x.Asttypes.txt];
│ Longident.t := Longident.t [@printer pp_longident]]]
│ [@@deriving show]
└────
The expression-syntax of assignment is used to express type-expression
rewrites. And this is necesarily limited, because we cannot (for
example) specify left-hand-sizes that are type-expressions with
variables. It's a perversion of the syntax, when what we really want
to have is something that is precise: "map this type-expression to
that type-expression".
Now, with the new Ocaml 4.11.0 syntax, there's a (partial) solution:
use "raw-string-extensions" like `{%foo|argle|}'. This is the same as
`[%foo {|argle|}]'. This relies on the PPX extension to parse the
payload. But there are problems:
1. Of course, there's no equivalent `{@foo|argle|}' (and "@@", "@@@"
of course) for attributes.
2. If the payload in that string doesn't *itself* correspond to some
parseable Ocaml AST type, then again, we're stuck: we have to
cobble together a parser instead of being able to merely extend the
parser of Ocaml to deal with the case.
Note well that I'm not saying that we should extend the parsing rules
of the Ocaml language. Rather, that with an *extensible parser*
(hence, LL(1)) we can add new nonterminals, add rules that reference
existing nonterminals, and thereby get an exact syntax (e.g.) for the
`ppx_import' example above. That new nonterminal is used *only* in
parsing the payload – nowhere else – so we haven't introduced examples
of objection #1 above.
And it's not even very hard.
Macro Extensions with Pa_ppx
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The basic thesis of `pa_ppx' is "let's not throw the baby out with the
bathwater". Camlp5 has a lot of very valuable infrastructure that can
be used to make writing macro-preprocessors much easier. `pa_ppx'
adds a few more.
1. Quotations for patterns and expressions over all important OCaml
AST types.
2. "extensible functions" to make the process of recursing down the
AST transparent, and the meaning of adding code to that process
equally transparent.
3. `pa_ppx' introduces "passes" and allows each extension to register
which other extensions it must follow, and which may follow it;
then `pa_ppx' topologically sorts them, so there's no need for
project-authors to figure out how to order their PPX extension
invocations.
As an example of a PPX rewriter based on `pa_ppx', here's
[pa_ppx.here] from the `pa_ppx' tutorial. In that example, you'll see
that Camlp5 infrastructure is used to make things easy:
1. quotations are used to both build the output AST fragment, and to
pattern-match on inputs.
2. the "extensible functions" are used to add our little bit of
rewriter to the top-down recursion.
3. and we declare our rewriter to the infrastructure (we don't specify
what passes it must come before or after, since `pa_ppx.here' is so
simple).
[pa_ppx.here]
https://pa-ppx.readthedocs.io/en/latest/tutorial.html#an-example-ppx-rewriter-based-on-pa-ppx
Conclusion
╌╌╌╌╌╌╌╌╌╌
I'm not trying to convince you to switch away from PPX to Camlp5.
Perhaps, I'm not even merely arguing that you should use `pa_ppx' and
author new macro-extensions on it. But I *am* arguing that the
features of
1. quotations, with antiquotations in as many places as possible, and
hence, *in places where Ocaml identifiers are not permitted*.
2. facilities like "extensible functions", with syntax support for
them
3. a new AST type, that is suitable for macro-preprocessing, but isn't
merely "s-expressions" (after all, there's a reason we all use
strongly-typed languages)
4. an extensible parser for the Ocaml language, usable in PPX
attribute/extension payloads
are important and valuable, and a PPX rewriter infrastructure that
makes it possible for the masses to write their own macro-extensions,
is going to incorporate these things.
OCaml 4.11.0, third (and last?) beta release
════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-third-and-last-beta-release/6149/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is near. As one step further in this
direction, we have published a third and potentially last beta
release.
This new release fixes an infrequent best-fit allocator bug and an
issue with floating-point software emulation in the ARM EABI port. On
the ecosystem side, merlin is now available for this new version of
OCaml. The compatibility of the opam ecosystem with OCaml 4.11.0 is
currently good, and it should be possible to test this beta without
too much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta3.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta3.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands:
┌────
│ opam update
│ opam switch create ocaml-variants.4.11.0+beta3 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam update
│ opam switch create ocaml-variants.4.11.0+beta3+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
We would love to hear about any bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
Compared to the previous beta release, the exhaustive list of changes
is as follows:
Runtime:
╌╌╌╌╌╌╌╌
• [#9736], [#9749]: Compaction must start in a heap where all free
blocks are blue, which was not the case with the best-fit
allocator. (Damien Doligez, report and review by Leo White)
• + [*new bug fixes*] [#9316], [#9443], [#9463], [#9782]: Use typing
information from Clambda or mutable Cmm variables. (Stephen Dolan,
review by Vincent Laviron, Guillaume Bury, Xavier Leroy, and Gabriel
Scherer; temporary bug report by Richard Jones)
[#9736] https://github.com/ocaml/ocaml/issues/9736
[#9749] https://github.com/ocaml/ocaml/issues/9749
[#9316] https://github.com/ocaml/ocaml/issues/9316
[#9443] https://github.com/ocaml/ocaml/issues/9443
[#9463] https://github.com/ocaml/ocaml/issues/9463
[#9782] https://github.com/ocaml/ocaml/issues/9782
Manual and documentation:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9541]: Add a documentation page for the instrumented runtime;
additional changes to option names in the instrumented
runtime. (Enguerrand Decorne, review by Anil Madhavapeddy, Gabriel
Scherer, Daniel Bünzli, David Allsopp, Florian Angeletti, and
Sébastien Hinderer)
Entries marked with "+" were already present in previous alphas, but
they have been complemented by new bug fixes.
If you are interested by the list of new features, and the nearly
final list of bug fixes the updated change log for OCaml 4.11.0 is
available at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
[#9541] https://github.com/ocaml/ocaml/issues/9541
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-Clang 0.0.9 is out. Download it here.]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-Clang 0.0.9 is out. Download it here.]
http://frama-c.com/index.html
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].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 37178 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-08-18 7:26 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-08-18 7:26 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7186 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 11 to 18,
2020.
Table of Contents
─────────────────
Ppx: omp 2.0.0 and next steps
Old CWN
Ppx: omp 2.0.0 and next steps
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231/1>
Jérémie Dimino announced
────────────────────────
quick summary:
• ocaml-migrate-parsetree 2.0.0 release
• you should add a upper bound in your dev repos
• ppxlib compatible version coming soon
• ppxlib is now the official ppx library supported by the OCaml
platform
Hi everyone,
As [previously announced], we are [releasing the version 2.0.0 of
ocaml-migrate-parsetree]. At the moment nothing is compatible with the
new version and we will soon release a version of ppxlib that is
compatible with it. If your project depends on
ocaml-migrate-parsetree, you should add a upper bound to your
development repository.
If you plan to use ocaml-migrate-parsetree 2.0.0 directly, please note
however that this is a transitory package. The technology implemented
by ocaml-migrate-parsetree will live on and hopefully find a new home
in the compiler repository proper. However, ocaml-migrate-parsetree as
a standalone project will eventually stop being maintained.
I am also taking the opportunity to announce that *ppxlib is the first
ppx library officially supported by the OCaml platform*, and the one
we recommend all ppx authors to use. It is the library that we plan to
maintain for the long term.
Other libraries such as `ppx_tools' or `ppx_tools_versioned' may
continue to be maintained by open source contributors, however they
will not be maintained by the OCaml platform and will not receive
updates from the platform when new compilers are released. Only ppxlib
will receive updates from the platform.
If you would like to port your project to use ppxlib and are
experiencing difficulties or have any question, please get in touch by
replying to this post or opening a ticket on
<https://github.com/ocaml-ppx/ppxlib>.
The overall plan described in this post is the result of various
discussions and/or collaborative effort between the following people:
@avsm, @ceastlund, @Drup, @gasche, @jeremiedimino, @kit-ty-kate,
@let-def, @NathanReb and @pitag.
[previously announced]
<https://discuss.ocaml.org/t/ocaml-migrate-parsetree-2-0-0/5991>
[releasing the version 2.0.0 of ocaml-migrate-parsetree]
<https://github.com/ocaml/opam-repository/pull/16999>
Next steps
╌╌╌╌╌╌╌╌╌╌
As soon as the new version of ppxlib is released, we will work towards
our next milestone. As a reminder, our current goal is to setup a ppx
ecosystem that is continously compatible with the trunk of OCaml. To
achieve that goal, we plan to add a stable API called "Astlib" on top
of the compiler libraries. To keep things sustainable on the compiler
side and increase flexibility, Astlib will be minimal and will be
targeted at ppxlib only rather than be a general API aimed at ppx
authors.
The difficulty of this API is that it must expose a stable interface
to the OCaml AST, which is composed of a large collection of data
types. To make it work, we plan to use the technology developed in
ocaml-migrate-parsetree; i.e. whole AST migration functions.
While we eventually want Astlib to live in the compiler repository, we
will initially develop it inside the ppxlib repository. Once it is
ready, we will submit it for inclusion in the compiler. Although, we
will keep a copy inside ppxlib for older versions of the compiler.
We also plan to setup a smooth workflow for compiler developers to
update Astlib when they change the development AST.
Once this is all done, we will be in a situation where the ppx
ecosystem is compatible with the trunk of OCaml at all time. And as a
result, new releases of the compiler will no longer break ppx packages
as long as they limit themselves to the ppxlib API.
Future
╌╌╌╌╌╌
While this work will make the ecosystem compatible with the trunk of
OCaml at all times, it will essentially move the backward
compatibility issue from the compiler to ppxlib.[1] This will already
give us a lot more flexibility as for instance a single version of
ppxlib can be compatible with a wide range of OCaml versions. However,
we recognise that it is not usual to ask a community to rely on an
unstable API.
We made this choice as a trade-off between sustainability and
complexity. Indeed, we want to maintain Astlib and Ppxlib over the
long term and the best way to make things sustainable is to use simple
and clear designs. While we do have solutions in our sleeves that
would provide a fully stable ppx API, these are much more complicated
to maintain and work with.
To mitigate this, we are setting up a Dune based workflow to upgrade
all ppx rewriters at once. So once the system is rolling and if your
ppx rewriters are up to date and using Dune, you should expect to
receive pull requests as we update ppxlib. This last part will take
some time to be fully rolling, so please bear with us :)
In any case, about a year after this new world is fully setup, we will
review the situation and decide whether it is sustainable or whether
we need to go all the way and mint a fully stable ppx API.
Timeline
╌╌╌╌╌╌╌╌
• today: ocaml-migrate-parsetree 2.0.0 is being released
• next week: a ppxlib compatible version is released
• December 2020: astlib is ready inside the ppxlib repository
• next OCaml release after that: astlib lives in the compiler
• September 2021: we review the situation and decide what to do next
[1]: At any given time the API of ppxlib refer to a single version of
the OCaml AST. In order to allow OCaml users to enjoy both ppx
rewriters and new language features, the version of the AST selected
by ppxlib needs to be bumped after each release of the compiler, which
is a breaking change that has the potential to break several ppx
packages. As a result, ppx packages will still need to be regularly
updated in order to stay compatible with the latest version of ppxlib.
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18147 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-01 7:55 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-09-01 7:55 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15200 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 25 to
September 01, 2020.
Table of Contents
─────────────────
Writing bindings for Google Apps Script (GAS)
What the Jane Street interns have wrought
a small library for shell/AWK/Perl-like scripting
letters 0.2.0
raylib-ocaml 0.1.0
OCaml Workshop 2020 Online Conference is live now
Other OCaml News
Old CWN
Writing bindings for Google Apps Script (GAS)
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/writing-bindings-for-google-apps-script-gas/6293/1>
Danielo Rodríguez announced
───────────────────────────
Thanks to the help of this community I successfully completed a crazy
idea: To write some ocaml functions to use inside [Google Apps Script]
for a small stupid spreadsheet that I had.
The way it works now is by having a main index.js file that calls the
Ocaml functions that are available under a global Lib
namespace. Everything is bundled using parcel and the Idea was to use
as few JS code as possible. Because it was easier than I expected I
decided to go one step further and write some bindings for the GAS
functions I was using and reduce the glue JS code even more.
This are the bindings that I wrote so far. They work, but are not
usable inside Ocaml yet.
┌────
│ type spreadsheet
│ type sheet
│ type range
│ external getActiveSpreadsheet : unit -> spreadsheet = "getActiveSpreadsheet" [@@bs.val][@@bs.scope
│ "SpreadsheetApp"]
│ external getSheets : spreadsheet -> sheet array = "getSheets" [@@bs.send]
│ external getSheetByName : spreadsheet -> string -> sheet = "getSheetByName" [@@bs.send]
│ external getDataRange : sheet -> range = "getDataRange" [@@bs.send]
│ external getValues : range -> 'a array array = "getValues" [@@bs.send]
└────
My doubt are on the edges. When it is just obscure GAS stuff I have no
doubt, abstract types and functions to interact with them. Is when a
GAS function returns data where I have doubts. Usually they are just
arrays of arrays of Numbers or Strings. In the example above, the last
definition says that you will get an array of arrays of `'a', but that
is not true because it will be an array of "stuff" (strings, numbers,
floats). How should I type it in a way that it's flexible but not
cumbersome? For example, I don't think using a functor will help
because you will need to create a functor for every possible return
type, in my case if you have 3 sheets with 3 different shapes, you
will need 3 functors. An alternative that I have used was to provide
some helper functions to convert from JS to Ocaml types and then
unwrap the Ocaml types, like the example I'm doing with
Number_or_string. This is nothing serious and I will just add the
bindings that I may need for now, but I want to hear what the
community (and potential users) thinks.
If anyone is interested in taking a look on the project, it is here:
<https://github.com/danielo515/ElectronicProjectsSpreadsheet>
[Google Apps Script] <https://developers.google.com/apps-script>
Matthieu Dubuget said
─────────────────────
Not answering directly to your question, sorry.
But here is a binding I have been using for around 4 years:
<https://dubuget.fr/gitea/matthieu/ocaml-google-app.git>.
Hongbo Zhang also replied
─────────────────────────
For return type polymorphism, you can use GADT with bs.ignore, the
rough idea:
┌────
│ type 'a t = Int : int t | String : string t
│ external f : ('a t [@bs.ignore]) -> ... -> 'a = "xx"
└────
I read discuss.ocaml.org from time to time, but checks
<https://forum.rescript-lang.org/> daily where you can get a quick
answer
What the Jane Street interns have wrought
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/what-the-jane-street-interns-have-wrought/6294/1>
Yaron Minsky announced
──────────────────────
I thought folks here might find this interesting:
<https://blog.janestreet.com/what-the-interns-have-wrought-2020/>
The post summarizes three of the intern projects that happened this
summer at Jane Street. It might be interesting if you're looking for
an internship (or know someone who is), or if you're interested in any
of the underlying tech. For example, if there's significant interest
in a library for writing OCaml, we'd be more likely to open-source it.
a small library for shell/AWK/Perl-like scripting
═════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-08/msg00021.html>
Oleg announced
──────────────
Some time ago Chet Murthy asked about writing shell-like scripts in
OCaml. Prompted by it, I also want to report on my experience and
announce a small library that made it pleasant to do
shell/AWK/Perl-like scripting in OCaml.
The library is available at
<http://okmij.org/ftp/ML/myawk/0README.dr>
and consists of two small ML files, myawk.ml and strings.ml. The
latter collects general-purpose string operations, more convenient
than those in Stdlib.String. The rest of that web directory contains
half a dozen sample scripts with comments.
Here is the first example: a typical AWK script, but written in OCaml:
┌────
│ #!/bin/env -S ocaml
│
│ #load "myawk.cma"
│ open Myawk open Strings
│ let hash = string_of_int <|> Hashtbl.hash
│ ;;
│ (* Sanitize the files originally used by join1.ml and join2.ml
│ The files are made of space-separated fields; the first field is the
│ key. It is sensitive; but because it is a key it can't be replaced with
│ meaningless garbage. We obfuscate it beyond recognition. The third field
│ is obfuscated as well. The second and fourth can be left as they are,
│ and the fifth, if present, is replaced with XXX
│
│ The script is a proper filter: reads from stdin, writes to stdout
│ *)
│
│ for_each_line @@ map words @@ function (f1::f2::f3::f4::rest) ->
│ print [hash f1; f2; hash f3; f4; if rest = [] then "" else "XXX"]
│ ;;
└────
Here <|> is a function composition. I wish it were in Stdlib. The real
example, used in real life, was performing a database join
┌────
│ SELECT T2.* from Table1 as T1, Table2 as T2 where T1.f1 = T2.f1
└────
where Table1 and Table2 are text files with space-separated column
values. Table1 is supposed to be fed to stdin:
┌────
│ let () =
│ for_each_line @@ map words @@
│ map_option (function (x::_) -> Some x | _ -> None) @@
│ (ignore <|> shell "grep %s table1.txt")
└────
It is a typical rough-and-dirty script. Alas, it was too rough: I was
so excited that it typechecked and worked the first time, that I
didn't look carefully at the output and overlooked what I was looking
for (resulting in an unneeded hassle and apology). I should have
queried exactly for what I wanted:
┌────
│ SELECT T1.f1, T1.f4 FROM Table1 as T1, Table2 as T2
│ WHERE T1.f1 = T2.f1 AND T1.f3 <> "3"
└────
which is actually easy to write in myawk (probably not so in AWK
though)
┌────
│ let () =
│ for_each_line ~fname:"table2.txt" @@ map words @@
│ map_option (function (w::_) -> Some w | _ -> None) @@
│ fun w ->
│ for_each_line ~fname:"table1.txt" @@ map words @@
│ map_option (function
│ (x::f2::f3::f4::_) when x = w && f4 <> "3" -> Some [x;f4] | _ -> None) @@
│ print
└────
This is the classical nested loop join. Chet Murthy might be pleased
to see the extensive use of the continuation-passing style. I was
apprehensive at first, but it turned out not to be a hassle.
The library has a few other examples, including case-branching and
rewriting a real AWK script from the OCaml distribution.
Finally, let's compare with shell scripts. The example below doesn't
show off the library, but it does show the benefits of OCaml for
scripting. The original shell script is a sample GIT commit hook,
quoted in the comments:
┌────
│ (*
│ From GIT's sample hooks:
│ ANY-GIT-REPO/.git/hooks/commit-msg.sample
│
│ # Called by "git commit" with one argument, the name of the file
│ # that has the commit message. The hook should exit with non-zero
│ # status after issuing an appropriate message if it wants to stop the
│ # commit. The hook is allowed to edit the commit message file.
│
│ # This example catches duplicate Signed-off-by lines.
│
│ test "" = "$(grep '^Signed-off-by: ' "$1" |
│ sort | uniq -c | sed -e '/^[ ]*1[ ]/d')" || {
│ echo >&2 Duplicate Signed-off-by lines.
│ exit 1
│ }
│
│ *)
│ module H = Hashtbl
│
│ let commit_msg = Sys.argv.(1)
│ let ht = H.create 5
│ let () =
│ for_each_line ~fname:commit_msg @@ fun l ->
│ if is_prefix "Signed-off-by: " l <> None then begin
│ if H.find_opt ht l <> None then begin
│ prerr_endline "Duplicate Signed-off-by lines.";
│ exit 1
│ end else
│ H.add ht l ()
│ end
└────
Although the OCaml script seems to have more characters, one doesn't
need to type them all. Scripts like that are meant to be entered in an
editor; even ancient editors have completion facilities.
Looking at the original shell script brings despair, and drives me
right towards Unix Haters. Not only the script is algorithmically
ugly: if a duplicate signed-off line occurs near the beginning, we can
report it right away and stop. We don't need to read the rest of the
commit message, filter it, sort it, precisely count all duplicates and
filter again. Not only the script gratuitously wastes system resources
(read: the laptop battery) by launching many processes and allocating
communication buffers. Mainly, the script isn't good at its primary
purpose: it isn't easy to write and read. Pipeline composition of
small stream processors is generally a good thing – but not when each
stream processor is written in its own idiosyncratic
language. Incidentally, I have doubts about the script: I think that
quotes around $1 are meant to be embedded; but why they are not
escaped then? Probably it is some edge case of bash, out of several
0thousands.
In contrast, OCaml script does exactly what is required, with no extra
work. Everything is written in only one language.
letters 0.2.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-letters-0-2-0/6307/1>
Miko announced
──────────────
Getting this release done took a bit longer than expected due to some
real life factors, but finally here it is.
This one mainly focuses on the most requested features and
improvements like simplifying configuration around CA certificates,
provides some basic documentation and additionally adds support for
`multipart/alternative' emails with combined HTML and plain text
content.
jerben then added
─────────────────
Link to Github: <https://github.com/oxidizing/letters>
raylib-ocaml 0.1.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-raylib-ocaml-0-1-0/6313/1>
Tobias Mock announced
─────────────────────
I'd like to announce the first version of [raylib-ocaml], a binding to
the awesome [raylib] game development library. The release can be
found on opam as ["raylib"].
The bindings are nearly complete, as far as functions and types go,
but only a subset was tested so far. I will work on bringing more of
the numerous examples of the C version to OCaml in the future.
Currently, raylib-ocaml only works on Linux, but I plan to support
Windows (and possibly other targets) in the future.
Feel free to give it a spin and please report any issues you run into.
[raylib-ocaml] <https://github.com/tjammer/raylib-ocaml>
[raylib] <https://www.raylib.com/>
["raylib"] <https://opam.ocaml.org/packages/raylib/>
OCaml Workshop 2020 Online Conference is live now
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2020-online-conference-is-live-now/6287/30>
Deep in this thread, Didier Wenzek announced
────────────────────────────────────────────
[OCaml 2020 All Videos]
[OCaml 2020 All Videos]
<https://www.youtube.com/playlist?list=PLKO_ZowsIOu5fHjRj0ua7_QWE_L789K_f>
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [BuckleScript Good and Bad News]
• [What the interns have wrought, 2020 edition]
• [Coq 8.12.0 is out]
[OCaml Planet] <http://ocaml.org/community/planet/>
[BuckleScript Good and Bad News]
<http://psellos.com/2020/08/2020.08.east-van-girls.html>
[What the interns have wrought, 2020 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2020/>
[Coq 8.12.0 is out] <https://coq.inria.fr/news/coq-8-12-0-is-out.html>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 34062 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-08 13:11 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-09-08 13:11 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 29657 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 01 to
08, 2020.
Table of Contents
─────────────────
OCaml 4.11.1: early bugfix release
textmate-language 0.1.0
Batteries v3.1.0
Job offer in Paris - Be Sport
Some SIMD in your OCaml
A PPX Rewriter approach to ocaml-migrate-parsetree
telltime - when is when exactly?
Ocamlunit emacs minor-mode
Sihl 0.1.0
promise_jsoo 0.1.0
Other OCaml News
Old CWN
OCaml 4.11.1: early bugfix release
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-4-11-1-early-bugfix-release/6337/1>
octachron announced
───────────────────
A serious bug has been discovered last week in OCaml 4.11.0: explicit
polymorphic annotations are checked too permissively. Some incorrect
programs (possibly segfaulting) are accepted by the compiler in
4.11.0.
Programs accepted by OCaml 4.10 are unchanged.
We are thus releasing OCaml 4.11.1 as an early bugfix version. You
are advised to upgrade to this new version if you were using OCaml
4.11.0.
It is (or soon will be) available as a set of OPAM switches with
┌────
│ opam switch create 4.11.1
└────
and as a source download here:
<https://caml.inria.fr/pub/distrib/ocaml-4.11/>
This bug was introduced when making polymorphic recursion easier to
use. We are working on making the typechecker more robust and more
exhaustively tested to avoid such issues in the future.
Bug fixes:
╌╌╌╌╌╌╌╌╌╌
• [#9856], [#9857]: Prevent polymorphic type annotations from
generalizing weak polymorphic variables. (Leo White, report by
Thierry Martinez, review by Jacques Garrigue)
• [#9859], [#9862]: Remove an erroneous assertion when inferred
function types appear in the right hand side of an explicit :>
coercion (Florian Angeletti, report by Jerry James, review by Thomas
Refis)
[#9856] <https://github.com/ocaml/ocaml/issues/9856>
[#9857] <https://github.com/ocaml/ocaml/issues/9857>
[#9859] <https://github.com/ocaml/ocaml/issues/9859>
[#9862] <https://github.com/ocaml/ocaml/issues/9862>
Rwmjones then said
──────────────────
We've now got 4.11.1 in Fedora 33 & Fedora 34. No apparent problems
so far.
textmate-language 0.1.0
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-textmate-language-0-1-0/6339/1>
dosaylazy announced
───────────────────
I am pleased to announce [textmate-language 0.1.0]. Textmate-language
is a library for tokenizing code using TextMate grammars. Therefore,
it may be useful for implementing syntax highlighters. Please report
any bugs or API inconveniences you find.
[textmate-language 0.1.0]
<https://opam.ocaml.org/packages/textmate-language/textmate-language.0.1.0/>
Batteries v3.1.0
════════════════
Archive: <https://discuss.ocaml.org/t/batteries-v3-1-0/6347/1>
UnixJunkie announced
────────────────────
OCaml Batteries Included is a community-maintained extended standard
library for OCaml.
The latest API can be found here:
<https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>
This minor release adds support for OCaml 4.11. It has been available
in opam for some days.
Special thanks to all the contributors!
The changelog follows:
• Compatibility fixes for OCaml-4.11 [#962] (Jerome Vouillon)
• BatEnum: added combination [#518] (Chimrod, review by hcarty)
• fix benchmarks [#956] (Cedric Cellier)
• BatFile: added count_lines [#953] (Francois Berenger, review by
Cedric Cellier)
• BatArray: use unsafe_get and unsafe_set more often [#947] (Francois
Berenger, review by Cedric Cellier)
• fix some tests for ocaml-4.10.0 [#944] (kit-ty-kate)
• BatResult: BatPervasives.result is now equal to Stdlib.result
instead of sharing constructors without being the same type [#939],
[#957] (Clément Busschaert, Cedric Cellier).
[#962]
<https://github.com/ocaml-batteries-team/batteries-included/pull/962>
[#518]
<https://github.com/ocaml-batteries-team/batteries-included/pull/518>
[#956]
<https://github.com/ocaml-batteries-team/batteries-included/pull/956>
[#953]
<https://github.com/ocaml-batteries-team/batteries-included/pull/953>
[#947]
<https://github.com/ocaml-batteries-team/batteries-included/pull/947>
[#944]
<https://github.com/ocaml-batteries-team/batteries-included/pull/944>
[#939]
<https://github.com/ocaml-batteries-team/batteries-included/pull/939>
[#957]
<https://github.com/ocaml-batteries-team/batteries-included/pull/957>
Job offer in Paris - Be Sport
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-offer-in-paris-be-sport/6355/1>
Vincent Balat announced
───────────────────────
Be Sport is looking to hire an OCaml developer with skills in
• Mobile/web feature design
• Team management
• Use of Social networks
She/he will take part in the development of our Web and mobile apps,
entirely written in OCaml with Ocsigen, and participate in reflections
on features.
Please contact me for more information or send an email to
jobs@besport.com.
Some SIMD in your OCaml
═══════════════════════
Archive: <https://discuss.ocaml.org/t/some-simd-in-your-ocaml/6367/1>
Anmol Sahoo announced
─────────────────────
Fresh from a weekend of hacking, I would like to share some results of
an experiment I conducted of creating a library for exposing Intel
AVX2 intrinsics to OCaml code. AVX2 is an instruction set subset that
adds data-parallel operations in hardware.
I chose to fork the amazing [bigstringaf] library and modified it. You
can find the additions to the code here - [bigstringaf_simd].
[bigstringaf] <https://github.com/inhabitedtype/bigstringaf>
[bigstringaf_simd]
<https://github.com/anmolsahoo25/bigstringaf/blob/8df94c4fb5607317ee9634611784eea65368a270/lib/bigstringaf_simd.mli#L287>
Overview
╌╌╌╌╌╌╌╌
Given a type `Bigstring.t' (1 dimensional byte arrays) there now exist
functions such as -
┌────
│ val cmpeq_i8 : (t * int) -> (t * int) -> (t * int) -> unit
└────
So `cmpeq_i8 (x,o1) (y,o2) (z,03)' will compare 32 bytes starting at
`o1' and `o2' from `x' and `y' respectively and store the result in
`z' at `o3'.
Why?
╌╌╌╌
This was mainly an exercise in curiosity. I just wanted to learn
whether something like this is viable. I also want to see if adding
some type-directed magic + ppx spells can let us write data parallel
code much more naturally similar to what `lwt / async' did for async
code.
At the same time, you might ask - why not use something like Owl
(which already has good support for data-parallel operations)? Apart
from the fact that such libraries are oriented towards numerical code,
I would also like to explore if we can operate directly on OCaml types
and cast them into data parallel algorithms. Like how `simdjson'
pushed the boundaries of JSON parsing, it would be nice to port
idiomatic code to data-parallel versions in OCaml. Can we, at some
point, have generic traversals of data-types, which are actually
carried out in a data-parallel fashion?
Does it work?
╌╌╌╌╌╌╌╌╌╌╌╌╌
Given the limitation of the current implementation (due to foreign
function calls into C), I still found some preliminary results to be
interesting! Implementing the `String.index' function, which returns
the first occurence of a char, the runtime for finding an element at
the `n-1' position in an array with `320000000' elements is -
┌────
│ serial: 1.12 seconds
│ simd: 0.72 seconds (1.5x)
└────
I still have to do the analysis what the overhead of the function call
into C is (even with `[@@noalloc]'!
Future directions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
It would be interesting to see, if we can create a representation
which encapsulates the various SIMD ISA's such as AVX2, AVX512, NEON,
SVE etc. Further more, it would be really interesting to see if we can
use ppx to automatically widen `map` functions to operate on blocks of
code, or automatically cast data types in a data parallel
representation.
Disclaimer
╌╌╌╌╌╌╌╌╌╌
This was mostly a hobby project, so I cannot promise completing any
milestones or taking feature requests etc. I definitely do not
recommend using this in production, because of the lack of testing
etc.
A PPX Rewriter approach to ocaml-migrate-parsetree
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-ppx-rewriter-approach-to-ocaml-migrate-parsetree/6369/1>
Chet Murthy announced
─────────────────────
TL;DR
╌╌╌╌╌
Based on `camlp5' and the `pa_ppx' PPX rewriters, I've written a new
one, `pa_deriving_plugins.rewrite', that automates almost all the work
of writing a migration from one version of OCaml's AST to another.
1. It took a few days (b/c of laziness) to write the initial PPX
rewriter
2. A day to get 4.02->4.03 AST migration working
3. a couple of hours to get 4.03->4.02 working
4. and a few more hours to get 4.03<->4.04 and 4.04<->4.05 working
At this point, I fully expect that the other version-pairs will not be
difficult.
You can find this code [warning: very much a work-in-progress] at
<https://github.com/chetmurthy/pa_ppx/tree/migrate-parsetree-hacking>
The file `pa_deriving.plugins/pa_deriving_rewrite.ml' contains the
source for the PPX rewriter.
The directory `pa_omp' contains the migrations, typically named
`rewrite_NNN_MMM.ml'.
A slightly longer-winded explanation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you think about it, `ppx_deriving.map' isn't so different from what
we need for `ocaml-migrate-parsetree'. `ppx_deriving.map', from a
type definition for ~ 'a t~, will automatically generate a function
┌────
│ map_t : ('a -> 'b) -> 'a t -> 'b t
└────
If you think about it, if we could just substitute our own type for
the second occurrence of `t' (somehow …. yeah *grin*) then it would be
almost like what we want for o-m-p, yes?
With 11 versions of the Ocaml AST so far, maybe it's worth thinking
about how to automate more of the migration task. Also, since so much
of it is type-structure-driven, one would think that it would be an
excellent opportunity to apply PPX rewriting technology. *Indeed, one
might think that a good test of PPX rewriting, is the ability to
automate precisely such tasks.*
So what's hard about this migration task? Here are some issues (maybe
there are more):
1. the types are slightly differently-organized in different versions
of the AST. Types might move from one module to another.
2. sometimes new types are introduced and old ones disappear
3. constructor data-types may get new branches, or lose them
4. record-types may get new fields, or lose them
5. sometimes the analogous types in two consecutive versions are just
really, really different [but this is rare]: we need to supply the
code directly
6. when mapping from one version to another, sometimes features are
simply not mappable, and an error needs to be raised; that error
ought to contain an indication of where in the source that
offending feature was found
7. And finally, when all else fails, we might need to hack on the
migration code directly
But morally, the task is really straightforward (with problems listed
in-line):
1. use `ppx_import' to copy over types from each of the AST times of
each Ocaml version
• `ppx_import' works on `.cmi' files, and those have different
formats in different versions of Ocaml. Wouldn't it be nice if
it worked on `.mli' files, whose syntax (b/c OCaml is
well-managed) doesn't change much?
2. build a single OCaml module that has all the AST types in it (from
all the versions of OCaml)
• but without the form
┌────
│ type t = M.t = A of .. | B of ....
└────
that is, without the "type equation" that allows for a new
type-definition to precisely repeat a previous one.
3. Then use `ppx_import' against this single module to construct a
recursive type-declaration list of all the AST types for a
particular version of OCaml, and apply a "souped-up" version of
ppx_deriving.map to it, to map the types to *another* version of
the AST types.
• but `ppx_deriving.map' doesn't do this today, and besides, it
would have to provide a bunch of "escape hatches" for all the
special-cases I mentioned above.
But this is in principle doable, and it has the nice feature that all
the tedious boilerplate is mechanically-generated from
type-definitions, hence likely to not contain errors (assuming the PPX
rewriter isn't buggy).
So I decided to do it, and this little post is a result.
Discussion
╌╌╌╌╌╌╌╌╌╌
I think this is a quite viable approach to writing
`ocaml-migrate-parsetree', and I would encourage the PPX community to
consider it. One of the nice things about this approach, is that it
relies *heavily* on PPX rewriting itself, to get the job done. I
think one of the important things we've learned in programming
languages research, is that our tools need to be largely sufficient to
allow us to comfortably implement those same tools. It's a good test
of the PPX infrastructure, to see if you can take tedious tasks and
automate them away.
I'm not going to describe anymore of how this works, b/c I'd rather
get the rest of the migrations working, start figuring out how to
test, and get this code integrated with camlp5.
But for anybody who's interested, I'd be happy to interactively
describe the code and walk them thru how it works.
Louis Roché then asked
──────────────────────
For a person who hasn't digged into OMP, can you explain how it is
different from what is done currently? Because the idea I had of OMP
is basically what you describe, a set of functions transformation an
AST from vX to vX-1 and vX+1. So I am obviously missing something.
Chet Murthy replied
───────────────────
Yes, you're right: imagine a series of modules M2…M11. Each declares
the same set of types, but with different definitions, yes? Then
you'd have migration modules, `migrate_i_j' (j=i+1 or j=i-1) that have
functions that convert between the analogously-named types. The
entire question is: how are these functions implemented? By hand?
With significant mechanized support? They can't be implemented
fully-mechanically, because there are decisions to be made about how
to bridge differences in type-definitions. For instance, look at the
4.02 type `label' and the 4.03 type `arg_label'. Sometimes these are
analogous (and sometimes they're not). When they're analogous, the
code that converts between -cannot- be automatically inferred: a human
has to write it. But -most- of the code of these migration functions
can be inferred automatically from the type-definitions themselves.
And that's really all that my little experiment does: automatically
infer the migration code (most of the time) with some hints for those
cases where it's not possible to automatically infer.
Now, why would one do this? Well, two reasons:
1. it should be more maintainable to automatically generate most of
the code from types, and it should be quicker to bring online a
migration for a new version of the Ocaml AST.
2. this should be a good test of PPX rewriting. That is, if we're
going to build a macro-preprocessing support system, shouldn't it
be able to make solving such straightforward, but very tedious,
problems much, much easier?
Chet Murthy then added
──────────────────────
I forgot to add a third reason why this PPX-rewriter-based approach is
better:
1. If you look at ocaml-migrate-parsetree "migrations", you'll find
that they're almost all boilerplate code. But sprinkled
here-and-there, is actual logic, actual decisions about how to come
up with values for new fields, about which fields, when non-trivial
(e.g. not "[]") should lead to migration-failure, etc. It is this
code, that is the actual meat of the migration, and it's not at all
obvious, when sprinkled thru the mass of mechanically-produclble
boilerplate.
A mechanized production of that boilerplate would mean that we
retained explicitly only this nontrivial code, and hence for
maintenance we could focus on it, and make sure it does the right
thing.
Josh Berdine asked
──────────────────
Figuring out ways to make maintaining this stuff more efficient would
be great! One aspect that isn't clear to me is how this approach
compares to the process currently used to generate the omp code. I
haven't done it myself, but at first glance the tools to generate the
omp code (e.g. gencopy) seem to also accurately be describable as
heavily using ppx infrastructure in order to implement the map code
from one version to another. Is there an executive summary that
compares and contrasts that and this proposal?
Chet Murthy replied
───────────────────
From the README, gencopy is used to generate a prototype file for each
migration, and then a human goes in and fixes up the code. A way to
put my point is: gencopy should be provided the fixups in some compact
form, and apply them itself.
telltime - when is when exactly?
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-telltime-when-is-when-exactly/6372/1>
Darren announced
────────────────
I'm happy to announce release of [telltime] 0.0.1, a small cli tool
for interacting with Daypack-lib (a schedule, time, time slots
handling library) components.
It primarily answers time related queries, with support for union
(`||'), intersect (`&&') and "ordered select" (`>>', explanation of
this is at the bottom).
The query language, time expression, aims to mimic natural language,
but without ambiguity. The grammar is only documented in the online
demo [here] at the moment.
Some examples copied from the README are as follows.
[telltime] <https://github.com/daypack-dev/telltime>
[here] <https://daypack-dev.github.io/time-expr-demo/>
Search for time slots matching Daypack time expression
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
"Hm, I wonder what years have Febuary 29th?"
┌────
│ $ telltime search --time-slots 5 --years 100 "feb 29 00:00"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 03 19:24:15
│
│ Matching time slots (in above time zone):
│ [2024 Feb 29 00:00:00, 2024 Feb 29 00:00:01)
│ [2028 Feb 29 00:00:00, 2028 Feb 29 00:00:01)
│ [2032 Feb 29 00:00:00, 2032 Feb 29 00:00:01)
│ [2036 Feb 29 00:00:00, 2036 Feb 29 00:00:01)
│ [2040 Feb 29 00:00:00, 2040 Feb 29 00:00:01)
└────
"Would be handy to know what this cron expression refers to"
┌────
│ $ telltime search --time-slots 5 "0 4 8-14 * *"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 06 17:39:56
│
│ Matching time slots (in above time zone):
│ [2020 Sep 08 04:00:00, 2020 Sep 08 04:01:00)
│ [2020 Sep 09 04:00:00, 2020 Sep 09 04:01:00)
│ [2020 Sep 10 04:00:00, 2020 Sep 10 04:01:00)
│ [2020 Sep 11 04:00:00, 2020 Sep 11 04:01:00)
│ [2020 Sep 12 04:00:00, 2020 Sep 12 04:01:00)
└────
"I have a bunch of time ranges, but some of them overlap, and they are
not in the right order. If only there is a way to combine and sort
them easily."
┌────
│ $ telltime search --time-slots 1000 "2020 . jan . 1, 10, 20 . 13:00 to 14:00 \
│ || 2019 dec 25 13:00 \
│ || 2019 dec 25 10am to 17:00 \
│ || 2020 jan 5 10am to 1:30pm \
│ || 2020 . jan . 7 to 12 . 9:15am to 2:45pm"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 06 18:01:12
│
│ Matching time slots (in above time zone):
│ [2019 Dec 25 10:00:00, 2019 Dec 25 17:00:00)
│ [2020 Jan 01 13:00:00, 2020 Jan 01 14:00:00)
│ [2020 Jan 05 10:00:00, 2020 Jan 05 13:30:00)
│ [2020 Jan 07 09:15:00, 2020 Jan 07 14:45:00)
│ [2020 Jan 08 09:15:00, 2020 Jan 08 14:45:00)
│ [2020 Jan 09 09:15:00, 2020 Jan 09 14:45:00)
│ [2020 Jan 10 09:15:00, 2020 Jan 10 14:45:00)
│ [2020 Jan 11 09:15:00, 2020 Jan 11 14:45:00)
│ [2020 Jan 12 09:15:00, 2020 Jan 12 14:45:00)
│ [2020 Jan 20 13:00:00, 2020 Jan 20 14:00:00)
└────
Get exact time after some duration from now
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ $ telltime from-now "1 hour"
│ Now : 2020-09-03 15:53:29
│ Duration (original) : 1 hour
│ Duration (normalized) : 1 hours 0 mins 0 secs
│ Now + duration : 2020-09-03 16:53:29
└────
┌────
│ $ telltime from-now "1.5 days 2.7 hours 0.5 minutes"
│ Now : 2020-09-03 15:55:43
│ Duration (original) : 1.5 days 2.7 hours 0.5 minutes
│ Duration (normalized) : 1 days 14 hours 42 mins 30 secs
│ Now + duration : 2020-09-05 06:38:13
└────
Difference between ordered select and union
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`s1 >> s2' is similar to `s1 || s2', but `>>' picks between s1 and s2
in a round robin fashion, instead of just picking the smallest between
two.
One specific differing case would be when the search starts at 4pm
today, `3pm || 5pm' would return 5pm today and 3pm tomorrow, and so
on, while `3pm >> 5pm' would return 3pm tomorrow and 5pm tomorrow (a
5pm is only picked after a 3pm has been picked already).
Ocamlunit emacs minor-mode
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocamlunit-emacs-minor-mode/6373/1>
Manfred Bergmann announced
──────────────────────────
Here is a first version of this plugin that allows running `dune test'
with an Emacs key stroke. It shows the test result in a separate
buffer and a simple colorized status 'message'.
<https://github.com/mdbergmann/emacs-ocamlunit>
While it is possible to run `dune' in 'watch' mode I'd like to
manually run tests.
I didn't find a way to specify individual test modules in `dune'. Is
that possible?
Sihl 0.1.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-sihl-0-1-0/6374/1>
jerben announced
────────────────
I am happy to announce this milestone release of Sihl, a web framework
for OCaml.
Github: <https://github.com/oxidizing/sihl>
opam: <http://opam.ocaml.org/packages/sihl/>
Sihl is really just a collection of services that can be plugged into
each other and a tiny core that knows how to start them. The goal is
to take care of infrastructure concerns so you can focus on the
domain.
After many iterations, the API is in a shape where we dare to show it
to you :slight_smile: It is still under heavy development so expect
breakage without a major version bump. However, we just finished
migrating a project from Reason on NodeJS to OCaml on Sihl, so we use
it in production.
We provide service implementations that were useful to us so far. In
the future we want to provide many more to cover all kinds of
needs. (PRs are always welcome!)
Any feedback is greatly appreciated, thanks! :)
jerben then added
─────────────────
Here is an example of a tiny Sihl app:
┌────
│ module Service = struct
│ module Random = Sihl.Utils.Random.Service
│ module Log = Sihl.Log.Service
│ module Config = Sihl.Config.Service
│ module Db = Sihl.Data.Db.Service
│ module MigrationRepo = Sihl.Data.Migration.Service.Repo.MariaDb
│ module Cmd = Sihl.Cmd.Service
│ module Migration = Sihl.Data.Migration.Service.Make (Cmd) (Db) (MigrationRepo)
│ module WebServer = Sihl.Web.Server.Service.Make (Cmd)
│ module Schedule = Sihl.Schedule.Service.Make (Log)
│ end
│
│ let services : (module Sihl.Core.Container.SERVICE) list =
│ [ (module Service.WebServer) ]
│
│ let hello_page =
│ Sihl.Web.Route.get "/hello/" (fun _ ->
│ Sihl.Web.Res.(html |> set_body "Hello!") |> Lwt.return)
│
│ let routes = [ ("/page", [ hello_page ], []) ]
│
│ module App = Sihl.App.Make (Service)
│
│ let _ = App.(empty |> with_services services |> with_routes routes |> run)
└────
promise_jsoo 0.1.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-promise-jsoo-0-1-0/6377/1>
Max LANTAS announced
────────────────────
Hello! I am announcing the first release of `promise_jsoo', a library
for JS promises in Js_of_ocaml.
<https://github.com/mnxn/promise_jsoo>
<https://opam.ocaml.org/packages/promise_jsoo/>
The library has bindings to the core `Promise' methods as well as
helper functions that make it easier to deal with a `Promise' of an
`option' or `result'. It is also possible to use this library with
[gen_js_api] to make for an easier JavaScript binding experience
Inspired by [aantron/promise], this library also uses indirection
internally when handling nested promises in order to ensure that the
bindings are type safe.
This project is part of ongoing work to port [vscode-ocaml-platform]
to Js_of_ocaml.
Generated documentation can be found [here].
[gen_js_api] <https://github.com/LexiFi/gen_js_api>
[aantron/promise]
<https://github.com/aantron/promise#discussion-how-reason-promise-makes-promises-type-safe>
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[here]
<https://mnxn.github.io/promise_jsoo/promise_jsoo/Promise/index.html>
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Announcing Signals and Threads, a new podcast from Jane Street]
[OCaml Planet] <http://ocaml.org/community/planet/>
[Announcing Signals and Threads, a new podcast from Jane Street]
<https://blog.janestreet.com/announcing-signals-and-threads-index/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 48472 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-22 7:27 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-09-22 7:27 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15579 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 15 to
22, 2020.
Table of Contents
─────────────────
Liquidsoap 1.4.3
Simple63 v1: compression of integer sequences
bentov v1: streaming estimation of 1D histograms
opam-compiler 0.1.0
lua_parser 1.0.0
Merlin 3.4.0 : introducing external configuration readers
gRPC server and client in OCaml
Bitstring (and ppx_bitstring) 4.0.0
Old CWN
Liquidsoap 1.4.3
════════════════
Archive: <https://discuss.ocaml.org/t/ann-liquidsoap-1-4-3/6429/1>
Romain Beauxis announced
────────────────────────
I'm happy to announce that liquidsoap `1.4.3' is out at:
<https://github.com/savonet/liquidsoap/releases/tag/v1.4.3>
This is the 3rd bugfix release for the `1.4.x' branch. It contains
important fixes and a couple of new minor features. Update is
recommended and should be fairly safe.
Along we this release, we have now added builds for `arm64' debian
packages and docker-ready production images for `amd64' and `arm64'
architectures available at:
<https://hub.docker.com/repository/docker/savonet/liquidsoap>
Again, we would like to warmly thank all users, contributors and
reporters for helping us bring liquidsoap to the next step!
Also, please note that a couple of issues had to be left out to make
sure that the release comes out on time. These are listed [here] and
will be tackled as soon as possible.
Next for liquidsoap, we will focus on getting the current `2.x' branch
finalized and polished. We already have support for encoded content
and ffmpeg raw frames. We need to write a couple of inline encoders
and decoders and we'll have 90% of the features ready. This will be a
major update for us!
[here] <https://github.com/savonet/liquidsoap/milestone/7>
Simple63 v1: compression of integer sequences
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-simple63-v1-compression-of-integer-sequences/6431/1>
Mika Illouz announced
─────────────────────
This is to announce Simple63, an opam package for compression of
integer sequences; similar to Anh and Moffat's Simple-8b. More details
found in:
• github: [https://github.com/barko/simple63]
• documentation: [https://barko.github.io/simple63/]
Feedback and bug reports welcome.
[https://github.com/barko/simple63] <https://github.com/barko/simple63>
[https://barko.github.io/simple63/] <https://barko.github.io/simple63/>
bentov v1: streaming estimation of 1D histograms
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bentov-v1-streaming-estimation-of-1d-histograms/6434/1>
Mika Illouz announced
─────────────────────
This is to announce bentov, a opam package that implements a 1D
histogram-sketching algorithm. For more details:
• github: [https://github.com/barko/bentov]
• documentation: [https://barko.github.io/bentov]
Feedback and bug reports welcome.
[https://github.com/barko/bentov] <https://github.com/barko/bentov>
[https://barko.github.io/bentov] <https://barko.github.io/bentov>
opam-compiler 0.1.0
═══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-compiler-0-1-0/6442/1>
Etienne Millon announced
────────────────────────
On behalf of the opam maintainers, I'd like to announce the first
release of opam-compiler, a plugin to work with compiler variants,
branches and forks.
This can cover a pretty wide range of use cases, so the first version
is starting small with a single command to create a switch from a
branch or github PR:
┌────
│ % opam compiler create '#9921'
│ Opam plugin "compiler" is not installed. Install it on the current switch? [Y/n] y
│
│ ...
│
│ <><> Carrying on to "opam compiler create #9921" ><><><><><><><><><><><><><><><>
│
│ [ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised from
│ git+https://github.com/gasche/ocaml#Atomic.create
│ ocaml-variants is now pinned to git+https://github.com/gasche/ocaml#Atomic.create (version
│ 4.12.0+trunk)
│ % opam switch
│ ...
│ → ocaml-ocaml-9921
│ [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Atomic.make into Atomic.create
└────
You can also override the arguments passed to `--configure'.
As you can see in the above snippet, it's an opam plugin so it will
auto-install if needed (assuming you ran `opam update' recently) and
will be available across all switches. Its sources and issue tracker
are available [here].
For the next releases, our plan is to add a user-friendly way to setup
a switch based on a local git clone, so that it's easy to test your
compiler fork with opam packages. You can find the other features we'd
like to add in the future in [the relevant part of the opam roadmap].
Thanks and have fun compiling compilers!
[here] <https://github.com/ocaml-opam/opam-compiler>
[the relevant part of the opam roadmap]
<https://github.com/ocaml/opam/wiki/Spec-for-working-with-the-OCaml-compiler>
lua_parser 1.0.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-lua-parser-1-0-0/6445/1>
Jason Nielsen announced
───────────────────────
I've release [lua_parser] which is now up on opam. It is a parser and
pretty-printer for lua 5.2. Actually it was developed with luajit in
mind which is lua 5.1 plus goto/labels (which syntactically for the
purposes of parsing and pretty-printing is lua 5.2).
[lua_parser] <https://github.com/drjdn/ocaml_lua_parser>
Merlin 3.4.0 : introducing external configuration readers
═════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-merlin-3-4-0-introducing-external-configuration-readers/6446/1>
vds announced
─────────────
I am glad to announce, on behalf of the Merlin team, the release of
Merlin `3.4.0' which brings some major changes in the way
configuration is handled.
As you might know, Merlin reads its configuration from the closest
`.merlin' file to the source file being edited. These files tell
merlin where to find other source files and build artifacts, but also
which flags should be passed to the compiler, which syntax extensions
are enabled and which packages are used by the project.
In this setting the configuration is the same for all the source files
of a folder, regardless of their specificities. In other words, the
configuration loaded for a single source file contains the union of
the dependencies of this file and of all its siblings which is not an
optimal behavior.
Starting with version `3.4.0' merlin will ship with two packages:
`merlin' and `dot-merlin-reader' which, as the name suggests, reads
configuration from `.merlin' files. Both are necessary for proper
function.
When a `.merlin' file is present in the source folder the Merlin
server will start a `dot-merlin-reader' process and communicate with
it via standard input and output following a simple protocol. These
processes are halted with the server.
*This change should not have any visible impact on users' workflows as
long as the `dot-merlin-reader' binary is correctly installed and in
the path*. (which should be the case in opam-based setups)
This change in itself will not solve the granularity problem mentioned
earlier, but it paves the way for such improvements: in a near-future
Dune will stop generating `.merlin' files and Merlin will obtain
file-based configuration directly from the build system using the same
protocol as the one used by `dot-merlin-reader'.
Changelog
╌╌╌╌╌╌╌╌╌
⁃ merlin binary
• fix completion of pattern matchings with exception patterns
(#1169)
• delegate configuration reading to external programs via a simple
protocol and create a new package `dot-merlin-reader' with a
binary that reads `.merlin' files. (#1123, #1152)
gRPC server and client in OCaml
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/grpc-server-and-client-in-ocaml/6465/1>
blandinw announced
──────────────────
TL;DR <https://github.com/blandinw/ocaml-grpc-envoy/>
Hey, I'm new to OCaml after writing some Clojure, C++ and Haskell in
various contexts, including working at FB (relevant below).
After browsing this forum and Reddit for a bit, the assumption seems
to be that OCaml is not a good fit for gRPC, since there's no pure
implementation today. Now, this is something I have experience with,
so I thought I'd try and challenge this assumption.
As you may know, services inside FB use Thrift (both the format and
protocol) to communicate. The Thrift team worked primarily in C++ (for
good reasons), causing support for other languages to lag behind
despite their best efforts. Now, the interchange format (equivalent to
Protobuf) does not change very often so it's fine to have a
per-language implementation, but the client and server (equivalent to
HTTP2 + gRPC) frequently receive new features, optimizations and
fixes. After a valiant and continued effort to support most languages
used internally, the Thrift team came up with an idea. Instead of
maintaining multiple implementations and dealing with obscure FFI
bugs, ~FingerprintTrustManagerFactory~s and whatnot, they would focus
solely on the C++ implementation and provide a daemon to be ran
alongside whatever code you were trying to run. You could then use
simple IPC to exchange Thrift (the format) messages with that daemon,
and it would handle all the nitty-gritty of running a service at scale
(load balancing, connection pooling, service discovery, security,
retries, timeouts, network stats, hot restarts, etc.). Needless to
say, it worked remarkably well even at very high scale and everybody
was much happier.
I wanted to replicate this idea with OCaml and gRPC. We already have
support for protobuf thanks to the excellent `ocaml-protoc'. All we
need is a way to exchange protobuf messages reliably on the wire.
Instead of having an OCaml implementation that will have to stay
up-to-date and have its own set of bugs (the official `grpc/grpc-java'
repo has 4450 commits and 2400 issues at the moment), can we reuse
existing infra with already massive support and production time?
Fortunately, the people at Lyft built just that, open-sourced it and
contributed it to the Cloud Native Computing Foundation in late
2017. It is called Envoy and it is bliss.
I demonstrate how to fit these pieces together at
[blandinw/ocaml-grpc-envoy] to build a simple KV store, including a
gRPC client and server in 200 lines of OCaml code. The idea is to
spawn an Envoy process that will handle all gRPC communication for our
OCaml code. We use HTTP/1.1 to exchange Protobuf messages with it,
using for example `httpaf' and `Lwt'. This solution has the added
benefit that it is highly scalable from the start, allowing you for
instance to spawn one OCaml process per core and load balance between
them. You can also use Envoy (with proper config!) as your web reverse
proxy instead of say, nginx.
At the very least, this solution allows us to start writing gRPC code
today, and gracefully evolve towards HTTP/2, Multicore and maybe a
native OCaml implementation later.
I'm curious to hear your perspective on the future of building
services with OCaml, or your past experience like what went well, what
was missing, etc.
[blandinw/ocaml-grpc-envoy]
<https://github.com/blandinw/ocaml-grpc-envoy/>
Yawar Amin asked and blandinw replied
─────────────────────────────────────
Fantastic idea. So if I understand correctly, the only
thing that Envoy (server-side) is doing is translating the
Protobuf from gRPC HTTP2 transport to HTTP1, and
forwarding these Protobuf objects over HTTP1 to the OCaml
server? Envoy doesn't know to know about the actual gRPC
schema, because it doesn't touch the Protobuf objects
themselves, right?
That's correct. Envoy is only concerned with transporting bytes (along
with load balancing, routing, etc, etc). Only OCaml knows about the
Protobuf schemas.
In the OCaml server case, Envoy listens for HTTP/2 gRPC requests,
accesses the bytes payload with no knowledge of the actual
schema/layout and repackages these same bytes in a HTTP/1.1 request
that OCaml can process. OCaml then responds with bytes (an encoded
Protobuf response message) that Envoy sends back on the original HTTP2
connection.
Bitstring (and ppx_bitstring) 4.0.0
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bitstring-and-ppx-bitstring-4-0-0/6471/1>
xrguerin announced
──────────────────
Features
╌╌╌╌╌╌╌╌
• Add support for let bindings introduced in 4.08
• Switch to PPXLIB
Deprecations
╌╌╌╌╌╌╌╌╌╌╌╌
As PPXLIB requires `ocaml >= 4.04' support for earlier versions has
been dropped.
Breaking changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release splits the library from the PPX to reduce runtime
dependencies. Projects using the PPX from bitstring will need to also
depends on ppx_bitstring from now on.
Rudi Grinberg added
───────────────────
The project is hosted [here] for those who are interested.There's also
some excellent [docs]
[here] <https://github.com/xguerin/bitstring>
[docs] <https://bitstring.software/documentation/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 28846 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-29 7:02 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-09-29 7:02 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 14486 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 22 to
29, 2020.
Table of Contents
─────────────────
Opam-repository: security and data integrity posture
jsonoo 0.1.0
Interesting OCaml Articles
Rehabilitating Packs using Functors and Recursivity
the OCaml Software Foundation
dual 0.1.0
Old CWN
Opam-repository: security and data integrity posture
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478/1>
Chas Emerick said, spawning a huge thread
─────────────────────────────────────────
In connection with [another thread] discussing the fact that
Bitbucket's closure of mercurial support had affected the availability
of around 60+ projects' published versions, I learned of a number of
facts about how the opam repository is arranged, and how it is managed
that are concerning.
In summary, it seems that opam / opam-repository:
1. Never retains "published" artifacts, only links to them as provided
by library authors.
2. Allows very weak hashes (even md5).
3. Allows authors to _update_ artifact URLs and hashes of previously
"published" versions.
4. Offers scant support for individually signing artifacts or
metadata.
All of these are quite dangerous. As a point of reference, the
ecosystems I am most familiar with using prior to OCaml (JVM and
Javascript) each had very serious documented failures and exploits
(and many many more quiet ones) until their respective package
managers (Maven Central et al., and npm) plugged the above
vulnerabilities that opam-repository suffers from.
To make things concrete, without plugging the above (and especially
items 1-3):
• the availability and integrity of published libraries can be
impacted by third-party hosting services changing or going offline
(as in the case of the Bitbucket closure)
• the integrity of libraries can be impacted by authors
non-maliciously publishing updates to already-released versions,
affecting functionality, platform compatibility, build
reproducibility, or all of the above (anecdotes of which were shared
with me when talking about this issue earlier today)
• the integrity of libraries can be impacted by malicious authors
publishing updates to already-released versions
• the integrity of libraries can be impacted by malicious non-authors
changing the contents at tarball URLs to include changed code that
could e.g. exfiltrate sensitive data from within the organizations
that use those libraries. This is definitely the nuclear nightmare
scenario, and unfortunately opam is wide open to it thanks to
artifacts not being retained authoritatively and [essential
community libraries] continuing to use md5 in 2020.
Seeing that this has been well-established policy for years was
honestly quite shocking (again, in comparison to other languages'
package managers that have had these problems licked for a very very
long time). I understand that opam and its repository probably have
human-decades of work put into them, and that these topics have been
discussed here and there (in somewhat piecemeal fashion AFAICT), so
I'm certain I have not found (nevermind read) all of the prior art,
but I thought it reasonable to open a thread to gauge what the
projects' posture is in general.
[another thread]
<https://discuss.ocaml.org/t/bitbucket-stopped-supporting-mercurial-repositories/6324/3?u=cemerick>
[essential community libraries]
<https://github.com/ocaml/opam-repository/blob/master/packages/core/core.v0.14.0/opam>
Hannes Mehnert replied
──────────────────────
first of all thanks for your post raising this issue, which is
important for me as well.
I've been evaluating and working on improving the security of the
opam-repository over the years, including to not use `curl –insecure`
(i.e. properly validate TLS certificates) - the WIP result is [conex],
which aims at cryptographically signed community repositories without
single points of failures (threshold signatures for delegations,
built-in key rollover, …) - feel free to read the blog posts or OCaml
meeting presentations. Unfortunately it still has not enough traction
to be deployed and mandatory for the main opam repository. Without
cryptopgraphic signatures (and an established public key
infrastructure), the hashes used in opam-repository and opam are more
checksums (i.e. integrity protection) than for security. Threat models
- I recommend to read section [1.5.2 "goals to protect against
specific attacks"] - that's what conex above is based on and attempts
to mitigate. I'll most likely spend some time on improving conex over
the next year, and finally deploying it on non-toy repositories.
In the meantime, what you're mentioning:
1. "Never retains 'published' artifacts" <- this is not true, the
opam.ocaml.org host serves as an artifact cache, and is used by
opam when you use the default repository. This also means that the
checksums and the tarballs are usually taken from the same host ->
the one who has access there may change anything arbitrarily for
all opam users.
2. "Weak hashes" <- this is true, I'd appreciate if (a) opam would
warn (configurable to error out) if a package which uses weak
checksum algorithms, and (b) Camelus or some other CI step would
warn when md5/sha1 are used
3. "Authors can modify URLs and hashes" <- sometimes (when a
repository is renamed or moved on GitHub) the GitHub auto-generated
tarball has a different checksum. I'd appreciate to, instead of
updating that meta-data in the opam-repository to add new
patch-versions (1.2.3-1 etc.) with the new URL & hash - there could
as well be a CI job / Camelus check what is allowed to be modified
in an edit of a package (I think with the current state of the
opam-repository, "adding upper bounds" on dependencies needs to be
allowed, but not really anything else).
4. I'm not sure I understand what you mean - is it about cryptographic
signatures and setting up a public key infrastructure?
[conex] <https://github.com/hannesm/conex>
[1.5.2 "goals to protect against specific attacks"]
<https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification>
Anton Kochkov said
──────────────────
Closely related issue is
<https://discuss.ocaml.org/t/how-to-setup-local-opam-mirror/4423>,
since the integrity checks and verification will become even more
important if there will be multiple mirrors in the future.
jsonoo 0.1.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-jsonoo-0-1-0/6480/1>
Max LANTAS announced
────────────────────
Hello! I am announcing the first release of `jsonoo', a JSON library
for Js_of_ocaml.
<https://github.com/mnxn/jsonoo>
<https://opam.ocaml.org/packages/jsonoo>
This library provides a very similar API to the excellent BuckleScript
library, [bs-json] by [glennsl]. Unlike bs-json, this port of the
library tries to follow OCaml naming conventions and be easier to
interface with other OCaml types like `Hashtbl.t' . This library
passes a nearly equivalent test suite.
This project is part of ongoing work to port [vscode-ocaml-platform]
to Js_of_ocaml.
Generated documentation can be found [here].
[bs-json] <https://github.com/glennsl/bs-json>
[glennsl] <https://github.com/glennsl>
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[here] <https://mnxn.github.io/jsonoo/jsonoo/Jsonoo/index.html>
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/62>
Ryan Slade announced
────────────────────
<https://blog.darklang.com/fizzboom-benchmark/>
Rehabilitating Packs using Functors and Recursivity
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity/6497/1>
OCamlPro announced
──────────────────
Our new blogpost is about the redemption of packs in the OCaml
ecosystem. This first part shows our work to generate functor units
and functor packs : [Rehabilitating Packs using Functors and
Recursivity, part 1.]
Packs in the OCaml ecosystem are kind of an outdated
concept (options `-pack' and `-for-pack' the OCaml manual,
and their main utility has been overtaken by the
introduction of module aliases in OCaml 4.02. What if we
tried to redeem them and give them a new youth and utility
by adding the possibility to generate functors or
recursive packs?
This blog post covers the functor units and functor packs,
while the next one will be centered around recursive
packs. Both RFCs are currently developed by JaneStreet and
OCamlPro. This idea was initially introduced by functor
packs (Fabrice Le Fessant) and later generalized by
functorized namespaces (Pierrick Couderc /et al/.).
[Rehabilitating Packs using Functors and Recursivity, part 1.]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>
the OCaml Software Foundation
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/19>
gasche announced
────────────────
We were all very busy during the last semester, and have been mostly
quiet on the foundation activities, but of course our actions were
running in the background. Some highlights:
• Kate @kit-ty-kate Deplaix has worked on opam-repository QA for the
OCaml 4.11 release, and the work and results are just as superb as
for 4.10. We will fund Kate to work again on the upcoming 4.12
release.
• We are funding ongoing maintenance work on [ocaml-rs] (a port of the
OCaml FFI library from C to Rust) by its author and maintainer, Zach
@zshipko Shipko. Zach did a big round of cleanup changes this
summer, improving the overall design of the library and completing
its feature set.
• We are funding @JohnWhitington (the author of [OCaml from the Very
Beginning]) to do some technical writing work for OCaml
documentation. His contributions so far have been very diverse, from
a script to harmonize the documentation of List and ListLabels (and
Array and ArrayLabels, etc.) in the standard library, to small
cleanups and improvement to ocaml.org web pages. One focus of his
work is the upcoming documentation page "Up and running with OCaml",
taking complete newcomers through the basic setup, using the
toplevel and building and running a Hello World. ([ocaml.org#1165],
[rendered current state])
• Two [Outreachy] internships were supervised this summer, focusing on
the compiler codebase. Florian @Octachron Angeletti (INRIA)
supervised an intern on adding a JSON format for some compiler
messages (we expect PRs to be submitted soon). Vincent @vlaviron
Laviron and Guillaume @zozozo Bury (OCamlPro) supervised an intern
on reducing mutable state in the internal implementation.
• Inspired by [this Discuss thread], we are funding experimental work
by @sanette on the HTML rendering of the OCaml manual. This work is
in the process of being reviewed for upstreaming in the OCaml
compiler distribution. ([#9755].) This is a better end-result than I
had initially expected.
(We also had a couple non-highlights. For example, we funded a sprint
(physical development meeting) for the [Owl] contributors, with
Marcello @mseri Seri doing all the organization work; it was planned
for the end of March, and had to be postponed due to the pandemic.)
[ocaml-rs] <https://github.com/zshipko/ocaml-rs/>
[OCaml from the Very Beginning] <http://ocaml-book.com/>
[ocaml.org#1165] <https://github.com/ocaml/ocaml.org/pull/1165>
[rendered current state]
<https://github.com/johnwhitington/ocaml.org/blob/up-and-running/site/learn/tutorials/up_and_running.md>
[Outreachy] <https://outreachy.org>
[this Discuss thread]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
[#9755] <https://github.com/ocaml/ocaml/pull/9755>
[Owl] <https://github.com/owlbarn>
dual 0.1.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dual-0-1-0/6512/1>
Jason Nielsen announced
───────────────────────
I’ve released [dual] which is now up on opam. It is a dual numbers
library which includes a one dimensional root finder (via Newton's
method).
[dual] <https://github.com/drjdn/ocaml_dual>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26248 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-06 7:22 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-10-06 7:22 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 29 to
October 06, 2020.
Table of Contents
─────────────────
vue-jsoo 0.2
Rehabilitating packs using functors and recursivity, part 2
Clap 0.1.0 (Command-Line Argument Parsing)
Old CWN
vue-jsoo 0.2
════════════
Archive: <https://discuss.ocaml.org/t/ann-vue-jsoo-0-2/6522/1>
levillain.maxime announced
──────────────────────────
I'd like to announce the second release of vue-jsoo (vue-jsoo.0.2). A
js_of_ocaml binding and helpers to use the vue-js framework with
js_of_ocaml.
Xavier Van de Woestyne added
────────────────────────────
Here is the link: <https://gitlab.com/o-labs/vue-jsoo>
(Congratulation!)
Rehabilitating packs using functors and recursivity, part 2
═══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity-part-2/6525/1>
OCamlPro announced
──────────────────
Following the publication of [the first part] of our blogpost about
the redemption of packs in the OCaml ecosystem, we are pleased to
share "[Rehabilitating packs using functors and recursivity, part 2.]"
This blog post and the previous one about functor packs
covers two RFCs currently developed by OCamlPro and Jane
Street. We previously introduced functor packs, a new
feature adding the possiblity to compile packs as
functors, allowing the user to implement functors as
multiple source files or even parameterized libraries.
In this blog post, we will cover the other aspect of the
packs rehabilitation: allowing anyone to implement
recursive compilation units using packs (as described
formally in the RFC#20). Our previous post introduced
briefly how packs were compiled and why we needed some
bits of closure conversion to effectively implement big
functors. Once again, to implement recursive packs we will
need to encode modules through this technique, as such we
advise the reader to check at least the introduction and
the compilation part of functor packs.
[the first part]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>
[Rehabilitating packs using functors and recursivity, part 2.]
<https://www.ocamlpro.com/2020/09/30/rehabilitating-packs-using-functors-and-recursivity-part-2/>
Clap 0.1.0 (Command-Line Argument Parsing)
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-clap-0-1-0-command-line-argument-parsing/6544/1>
rbardou announced
─────────────────
I am happy to announce the first release of Clap.
Clap is a library for command-line argument parsing. Clap works by
directly consuming arguments in an imperative way. Traditionally,
argument parsing in OCaml is done by first defining a specification
(an OCaml value defining the types of arguments), and then parsing
from this specification. The "impure" approach of Clap skips the need
to define a specification and results in code which is quite simple in
practice, with limited boilerplate.
Clap is available as an opam package (`opam install clap').
Source code, API documentation and a full commented example are
available at: <https://github.com/rbardou/clap/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 15116 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-20 8:16 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-10-20 8:16 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 22169 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 13 to 20,
2020.
Table of Contents
─────────────────
Dialo is hiring frontend and backend OCaml developers (Remote)
Progress 0.1.0
Brr 0.0.1, a toolkit for programming browsers
New release of Conduit
Easy cross compilation using esy
OCaml User Survey 2020
Old CWN
Dialo is hiring frontend and backend OCaml developers (Remote)
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dialo-is-hiring-frontend-and-backend-ocaml-developers-remote/6604/1>
Wojtek Czekalski announced
──────────────────────────
[Dialo] is an early stage company with an experienced founding
team. Assembling a team that consists of the best and brightest is our
top priority. In the immediate term we are building a visual
programming language for conversational AI. Our long term vision is
that personalized contact we are enabling will cause deeper
relationships between users and businesses and turn all interactions
into a unified long term customer journey.
The work is quite demanding when it comes to both ideation and
implementation. We are aiming to provide a room for growth both
technically and/or as a leader. For current open source maintainers we
are willing to sponsor your work on OSS for 20% of time.
We use OCaml for frontend and backend (along with Python for machine
learning, natural language processing). We are hiring people for
different positions. Both people with extensive experience and
newcomers are encouraged to apply. We try to find the sharpest people
rather than checking boxes with particular skills.
The official job posting:
<https://dialo.recruitee.com/o/software-developer-ocamlreason> We are
also hiring for two other (related) positions:
• <https://dialo.recruitee.com/o/software-developer-frontend>
• <https://dialo.recruitee.com/o/software-developer-backend>
[Dialo] <https://dialo.ai>
Progress 0.1.0
══════════════
Archive: <https://discuss.ocaml.org/t/ann-progress-0-1-0/6607/1>
Craig Ferguson announced
────────────────────────
I'm pleased to announce the first release of [`Progress'], now
available on Opam.
<https://raw.githubusercontent.com/CraigFe/progress/main/.meta/example.svg>
`Progress' is a small library for quickly defining and using progress
bars in OCaml programs. It aims to provide the following:
• support for rendering multiple progress bars simultaneously;
• responds dynamically to changes in terminal size;
• allows user-defined progress bar layouts.
[`Progress'] <https://github.com/CraigFe/progress/>
Defining your own progress bars
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The example animation above uses a pre-provided progress bar layout
that should meet many needs ([`Progress_unix.counter']), but it's
fairly easy to re-define it ourselves using the low-level
[`Progress.Segment'] API:
┌────
│ let counter filename =
│ let proportion i = Int64.to_float i /. 1_000_000. in
│ let open Progress in
│ Segment.(
│ list
│ [
│ const filename;
│ Units.bytes of_pp;
│ Progress_unix.stopwatch ();
│ bar ~mode:`ASCII proportion;
│ using proportion (Units.percentage of_pp);
│ ]
│ |> box_winsize ~fallback:80 (* Dynamically scale to window size *)
│ |> periodic 100 (* Re-render once every 100 updates *)
│ |> accumulator Int64.add 0L (* Accumulate progress updates *))
│ |> make ~init:0L
└────
The `Segment' combinators are similar to those of general-purpose
pretty-printing libraries (e.g. [`pp'] and [`fmt']), but are equipped
with extra logic for "stateful" segments and segments that can have
dynamic width. Together, these make for a convenient way to express
common patterns when pretty-printing progress bars. For instance, the
stateful segment `periodic' seen above can be used to ensure that very
frequent updates from a hot-loop do not result in too much time spent
re-rendering the output.
The library is not yet feature-complete, but should still be
reasonably useful :slightly_smiling_face: Happy hacking!
[`Progress_unix.counter']
<https://craigfe.github.io/progress/progress/Progress_unix/index.html#val-counter>
[`Progress.Segment']
<https://craigfe.github.io/progress/progress/Progress/Segment/index.html>
[`pp'] <https://github.com/ocaml-dune/pp>
[`fmt'] <https://erratique.ch/software/fmt>
Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/1>
Daniel Bünzli announced
───────────────────────
I'd like to announce the first release of Brr.
The TL; DR is:
If you are looking for a productive way to program
browsers with js_of_ocaml but without ppx and ghost OCaml
objects, give Brr a try.
The details:
Brr is a toolkit for programming browsers in OCaml with
the [`js_of_ocaml'] compiler. It provides:
• Interfaces to a [selection] of browser APIs.
• Note based reactive support (optional and experimental).
• An [OCaml console] developer tool for live interaction
with programs running in web pages.
• A JavaScript FFI for idiomatic OCaml programming.
Brr is distributed under the ISC license. It depends on
[Note] and on the `js_of_ocaml' compiler and runtime – but
not on its libraries or syntax extension.
• Homepage: <https://erratique.ch/software/brr>
• API Docs & manuals: <https://erratique.ch/software/brr/doc/> or
`odig doc brr'
• Install: `opam install brr'
Brr is essentially what I need to be productive for browser
programming with js_of_ocaml: an obvious FFI with JavaScript objects
as abstract data types without OCaml object phantom types and binding
documentation precisely linking into MDN.
The OCaml console is the hack on the cake. In the past I often found
it frustrating to have OCaml programs running in my webpages and be
greeted with a JavaScript prompt in the browser dev tools. Quite a
bit of polishing could be done on that though. Some of which should
likely directly be done upstream in the toplevel machinery
(e.g. identifier completion, a better toploop API and support for easy
pretty printer installation). It would also be nice if we could cut
down on `js_of_ocaml''s toplevel compilation times ;–)
Parts of Brr have been seriously dogfooded in the past but that new
incarnation is largely untested for now and certain APIs might need
adjustements. Early adopters should study actual binding coverage,
expect glitches and little breakages in the future.
The Note reactive functionality was also seriously used in the past
but Note itself needs a new design round and I don't have the
ressources to do it right now, expect breakage, don't pay too much
attention to it for now.
My thanks to the `js_of_ocaml' developers for the nice ocaml to
javascript compiler and a special shootout to Hugo Heuzard for not
getting mad at me when pinging him directly for questions.
Happy browser compatibility bug hunting,
[`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml>
[selection]
<https://erratique.ch/software/brr/doc/index.html#supported_apis>
[OCaml console]
<https://erratique.ch/software/brr/doc/ocaml_console.html>
[Note] <https://erratique.ch/software/note>
gasche asked
────────────
It's not really released, but I'm curious about [Note] now: this is a
new FRP library from you, the author of [React] (the FRP library for
OCaml, not the Javascript framework of the same name).
Would you say a few words on why you went for a different library? My
guess would be that React depends on runtime mechanisms (weak
pointers) that are not well-supported in Javascript-lang; but even if
the guess is right, I'm not sure what would be the impact on the API
or properties of the library.
[Note] <https://erratique.ch/software/note>
[React] <https://erratique.ch/software/react>
Daniel Bünzli replied
─────────────────────
Would you say a few words on why you went for a different
library?
`Note' is the result from seeing people (and myself) struggling to use
~React~/FRP "correctly" over the years.
Some of this, I largely attribute to ergonomic problems with the
API. It's my hope for `Note' to address most of these points (one
thing that still needs to be done is replace fix points by a simple
lazy infinitesimal delay combinator).
I don't think I could have made all these changes in `React' itself so
I found it better to start a new library. Also I lost the trademark on
the name :–)
`Note' also tries to provide a much simpler implementation. `React''s
implementation was based on the [FrTime Phd thesis]. It's quite subtle
and involved and, as you suggested, uses weak pointer. `Note' tries to
avoid them since those are not available in the browser (but you have
things like [MutationObservers] which I use as gc in Brr's Note-based
[reactive dom support]).
However not using weak pointers has a semantic uncleanness cost whose
impact I'm unsure yet – without discipline from the programmer it may
lead to subtle and hard to track bugs when the reactive graph changes
dynamically, which I'm a bit wary of.
When my brain dumped `Note' I wrote a few more technical points in the
readme you can read them [here].
[FrTime Phd thesis] <http://cs.brown.edu/people/ghcooper/thesis.pdf>
[MutationObservers]
<https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver>
[reactive dom support]
<https://erratique.ch/software/brr/doc/Brr_note/Elr/index.html>
[here] <https://github.com/dbuenzli/note#history>
New release of Conduit
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611/1>
Calascibetta Romain announced
─────────────────────────────
*Conduit 3.0.0*
Hello everyone,
We're glad to announce the new release of [`conduit'], a framework
that allows to _abstract_ over transfer protocols. One of its main
advantages is allowing the implemententation of _free-dependencies_
protocols.
[`conduit'] <https://github.com/mirage/ocaml-conduit>
Introduction
╌╌╌╌╌╌╌╌╌╌╌╌
There are several ways to abstract over an implementation in
OCaml. However, those solutions are often lost deep in the stack of
protocols and allowing the user to choose the implementations of the
sub-procotols implies growing complexity as we move up through the
stack. (For example, allowing to abstract over the implementation of
the TLS protocol from the implementation of the HTTP protocol)
One of those solutions, the _functors_, can rapidly become a hellish
nightmare for the end-user. This is especially true in the case of
MirageOS, which literally wants to abstract over everything!
This is why Conduit was implemented: it aims to provide to the user a
cleaner abstraction mechanism which would allow the protocol
developers to get rid of most of the responsibilities concerning the
choice of sub-protocols (Like which TLS implementation use between
OpenSSL or our great [ocaml-tls] library), while giving the end-users
an easy way to compose the protocols of their choice and inject them
in the stack via conduit.
[ocaml-tls] <https://github.com/mirleft/ocaml-tls>
Usage of Conduit
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Such a framework allows us to separate the logic of a protocol from
underlying implementation needed to communicate with a peer. The
distribution of Conduit comes with [a simple tutorial] which explains
step by step how to implement a _ping-pong_ client & server and, most
importantly, how to upgrade them with TLS.
With Conduit, we ensure the compatibility with MirageOS (and specially
[mirage-tcpip]) while being useful for others. Of course, Conduit is
not mandatory to ensure this compatibility, but it helps us for
_higher_ libraries such as [ocaml-git]/[Irmin] or [Cohttp].
[a simple tutorial]
<https://mirage.github.io/ocaml-conduit/conduit/howto.html>
[mirage-tcpip] <https://github.com/mirage/mirage-tcpip>
[ocaml-git] <https://github.com/mirage/ocaml-git>
[Irmin] <https://github.com/mirage/irmin>
[Cohttp] <https://github.com/mirage/ocaml-cohttp>
Specific improvements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Abstract and destruct it!
The most requested feature on the new version of Conduit is the
ability to _destruct_ the [Conduit.flow][conduit-flow]. The ability to
abstract the protocol comes with the _abstract_ type
`Conduit.flow'. The new version permits to _destruct_ it to a
well-known value (such as an UNIX socket):
┌────
│ let handler flow = match flow with
│ | Conduit_lwt.TCP.T (Value file_descr) ->
│ let peer = Lwt_unix.getpeername file_descr in
│ ...
│ | flow -> ... (* other kind of protocol *)
│
│ let run =
│ Cohttp_lwt_unix.serve ~handler
│ { sockaddr= Unix.inet_addr_loopback }
└────
◊ The dispatch of the protocol
The second most interesting feature of Conduit is the full control
over the dispatch between protocols by the end-user. From a concrete
information such as an `Uri.t', the end-user is able to describe how
Conduit should choose the protocol (and with which value it should try
to initiate the connection):
┌────
│ let my_tls_config = Tls.Config.client ...
│
│ let connect uri =
│ let edn = Conduit.Endpoint.of_string
│ (Uri.host_with_default ~default:"localhost" uri) in
│ let resolvers = match Uri.scheme uri with
│ | Some "https" ->
│ let port = Option.value ~default:443 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt_tls.TCP.protocol
│ (Conduit_lwt_tls.TCP.resolve ~port ~config:my_tls_config)
│ Conduit.empty
│ | Some "http" | None ->
│ let port = Option.value ~default:80 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt.TCP.protocol
│ (Conduit_lwt.TCP.resolve ~port)
│ Conduit.empty in
│ Conduit_lwt.resolve ~resolvers edn >>= fun flow ->
│ ...
└────
◊ An explicit way to launch a server
Conduit comes with a new API for the server-side, where everything
becomes explicit: no dispatch, no hidden choice. It proposes now a
simple function to start the usual server loop:
┌────
│ let run handler =
│ Conduit_lwt.serve ~handler
│ Conduit_lwt.TCP.service
│ { Conduit_lwt.TCP.sockaddr= Unix.(ADDR_INET (inet_addr_loopback, 8080)
│ ; capacity= 40 }
└────
Reverse-dependencies
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Conduit is used by many libraries (~150 packages) and we spend 2
months to track this breaking-change. Currently, it's mostly about
[Cohttp] and [Irmin] and both have a PR according the new version of
Conduit. These packages will be released as soon as we can with the
new version of Conduit.
[Cohttp] <https://github.com/mirage/ocaml-cohttp>
[Irmin] <https://github.com/mirage/irmin>
Conclusion
╌╌╌╌╌╌╌╌╌╌
Conduit is a piece required by many libraries but nobody really uses
it. This new version wants to replace and redefine more concretely
what Conduit is. The update is [huge] for us but small for people
where we tried to keep the same global idea of the abstraction.
I would like to thank many people (MirageOS core team, Cohttp peoples,
some not so famous guys of the Reason/OCaml eco-system) who followed
us on this deep development (and tried and iterated on our
version). It does not change too much our world, but it paves the way
for a better MirageOS/OCaml eco-system.
As a french guy, I just would like to say: Conduit est mort, Vive
Conduit!
[huge] <https://github.com/mirage/ocaml-conduit/pull/311>
Easy cross compilation using esy
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-easy-cross-compilation-using-esy/6612/1>
EduardoRFS announced
────────────────────
I've been working on this for a couple of months now, and now it is
ready for an initial announcement of my tools to cross compiling OCaml
and ReasonML Native.
<https://github.com/EduardoRFS/reason-mobile>
What it can do
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Out of box it can cross compile most dune and topkg, packages
available on opam for a couple of platforms, there is also patches for
popular packages.
You can also compile opam packages by making an wrapper, like
<https://github.com/mirage/mirage-crypto/pull/84/files>
Limitations
╌╌╌╌╌╌╌╌╌╌╌
Your package should build with OCaml 4.10, and all the packages that
are built for the `host' will also be build for the `target', so
sometimes you need to fix a package that you will not use directly.
Some packages you will need to pin to a `dune-universe' fork version
How to use it
╌╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ ## compile your project
│ esy
│
│ ## generate the wrapper
│ esy add -D generate@EduardoRFS/reason-mobile:generate.json
│ esy generate android.arm64
│
│ ## build for android.arm64
│ esy @android.arm64
└────
Platforms
╌╌╌╌╌╌╌╌╌
All of the following are tested from Linux and macOS, but I would
suppose that FreeBSD should be also working as a build system.
━━━━━━━━━━━━━━━━━━━━━━
Targets
──────────────────────
android.arm64
android.x86_64
ios.arm64
ios.simulator.x86_64
linux.musl.arm64
linux.musl.x86_64
━━━━━━━━━━━━━━━━━━━━━━
What I tested
╌╌╌╌╌╌╌╌╌╌╌╌╌
In the past I was able to build `Revery' the UI framework for
`Android' and `iOS'
But recently I did compile `esy' the package manager itself for all of
the following platforms above from an `Arch Linux x86_64' and `macOS
Catalina x86_64'. Including `iOS', with the right version of OCaml it
will run inside of the new `macOS ARM64' and inside of a jailbroken
iPhone.
OCaml User Survey 2020
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/1>
gasche announced
────────────────
We are happy to announce the [OCaml User Survey 2020]. We are trying
to get a better picture of the OCaml community and its needs. It would
be very useful if you could fill the survey (10-15 minutes), and share
it widely with other OCaml programmers!
The survey is run by the [OCaml Software Foundation]. Thanks in
particular to our sponsors OCamlPro (@MuSSF) for preparing many of the
questions, Jane Street (@Yaron_Minsky) for excellent feedback, and to
Kim @K_N Nguyễn for his technical help.
This is our first year running the survey, we hope to continue in
following years. There are many things to improve; please feel free to
give us feedback! (There is a feedback question at the end of the
survey, or you can post here, or send me a message/email.)
The survey was inspired by programming-language surveys ran by other
communities. See for example past survey results for [Go], [Haskell],
[Rust], and [Scala].
[OCaml User Survey 2020] <https://forms.gle/MAT7ZE7RtxTWuNgK7>
[OCaml Software Foundation] <https://ocaml-sf.org/>
[Go] <https://blog.golang.org/survey2019-results>
[Haskell] <https://taylor.fausak.me/2019/11/16/haskell-survey-results/>
[Rust] <https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html>
[Scala] <https://scalacenter.github.io/scala-developer-survey-2019/>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 41767 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-27 8:44 Alan Schmitt
0 siblings, 0 replies; 43+ messages in thread
From: Alan Schmitt @ 2020-10-27 8:44 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 18183 bytes --]
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
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bisect-ppx-the-coverage-tool-now-has-excellent-integration-with-dune/6634/1>
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!
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>
<https://github.com/aantron/bisect_ppx>
[*Bisect_ppx*] <https://github.com/aantron/bisect_ppx>
[2.5.0] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
[instrumentation support]
<https://dune.readthedocs.io/en/stable/instrumentation.html?highlight=instrument-with>
[instructions] <https://github.com/aantron/bisect_ppx#Dune>
[Lambda Soup] <https://github.com/aantron/lambdasoup>
[`opam']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/lambdasoup.opam#L17-L22>
[`dune-project']
<https://github.com/aantron/lambdasoup/blob/master/dune-project#L1>
[`dune']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/src/dune#L7>
[`Makefile']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/Makefile#L15>
[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
Js_of_ocaml in the VSCode OCaml Platform
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/js-of-ocaml-in-the-vscode-ocaml-platform/6635/1>
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.
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform/>
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
═════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-10/msg00018.html>
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
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-2/6643/1>
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
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.2>
Set up OCaml 1.1.3
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-3/6644/1>
Sora Morimoto announced
───────────────────────
This release contains these changes:
• Update the `@actions/core' package to address [CVE-2020-15228]
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.3>
[CVE-2020-15228] <https://github.com/advisories/GHSA-mfwh-5m23-j46w>
First release of FSML
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-fsml/6645/1>
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].
[Rfsm] <http://github.com/jserot/rfsm>
[gtkwave] <http://gtkwave.sourceforge.net/>
[Github] <https://github.com/jserot/fsml>
[OPAM package] <https://opam.ocaml.org/packages/fsml>
Qrc 0.1.0, a QR code encoder
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qrc-0-1-0-a-qr-code-encoder/6647/1>
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
═════════════
Archive: <https://discuss.ocaml.org/t/ann-cumulus-0-0-1/6655/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.
[cumulus] <https://github.com/paurkedal/ocaml-cumulus/>
[`test_isecn.ml']
<https://github.com/paurkedal/ocaml-cumulus/blob/master/tests/test_isecn.ml>
[reactiveData] <https://github.com/ocsigen/reactiveData>
[OCaml project with the same name] <https://github.com/Cumulus/Cumulus>
Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/5>
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:
1. 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].
2. 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.
[FFI manual] <https://erratique.ch/software/brr/doc/ffi_manual.html>
[FFI cookbook] <https://erratique.ch/software/brr/doc/ffi_cookbook.html>
[here] <https://erratique.ch/software/brr/doc/index.html#supported_apis>
[`HTMLMediaElement']
<https://erratique.ch/software/brr/doc/Brr_io/Media/index.html#el>
[`HTMLCanvasElement']
<https://erratique.ch/software/brr/doc/Brr_canvas/Canvas/index.html>
[`HTMLFormElement']
<https://erratique.ch/software/brr/doc/Brr_io/Form/index.html>
[`HTMLInputElement']
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ifaces>
[attribute and property API]
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ats_and_props>
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].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35020 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, back to index
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-03 7:35 [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Alan Schmitt
2019-10-15 7:28 Alan Schmitt
2019-11-05 6:55 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-26 8:33 Alan Schmitt
2019-12-03 15:43 Alan Schmitt
2019-12-10 8:21 Alan Schmitt
2019-12-17 8:52 Alan Schmitt
2019-12-31 9:18 Alan Schmitt
2020-01-07 13:43 Alan Schmitt
2020-01-14 14:17 Alan Schmitt
2020-01-21 14:09 Alan Schmitt
2020-01-28 10:54 Alan Schmitt
2020-02-04 8:47 Alan Schmitt
2020-02-18 8:18 Alan Schmitt
2020-02-25 8:51 Alan Schmitt
2020-03-03 8:00 Alan Schmitt
2020-03-10 14:29 Alan Schmitt
2020-03-17 11:04 Alan Schmitt
2020-03-24 9:31 Alan Schmitt
2020-03-31 9:55 Alan Schmitt
2020-04-07 7:51 Alan Schmitt
2020-04-14 7:28 Alan Schmitt
2020-04-21 8:58 Alan Schmitt
2020-04-28 12:45 Alan Schmitt
2020-05-05 7:45 Alan Schmitt
2020-05-12 7:46 Alan Schmitt
2020-05-19 9:53 Alan Schmitt
2020-06-09 8:29 Alan Schmitt
2020-06-16 8:36 Alan Schmitt
2020-06-30 7:00 Alan Schmitt
2020-07-07 10:05 Alan Schmitt
2020-07-14 9:55 Alan Schmitt
2020-07-21 14:43 Alan Schmitt
2020-07-28 16:58 Alan Schmitt
2020-08-18 7:26 Alan Schmitt
2020-09-01 7:55 Alan Schmitt
2020-09-08 13:11 Alan Schmitt
2020-09-22 7:27 Alan Schmitt
2020-09-29 7:02 Alan Schmitt
2020-10-06 7:22 Alan Schmitt
2020-10-20 8:16 Alan Schmitt
2020-10-27 8:44 Alan Schmitt
caml-list - the Caml user's mailing list
Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list
AGPL code for this site: git clone https://public-inbox.org/ public-inbox