[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- Attachment #1: Type: text/plain, Size: 32510 bytes --] Hello Here is the latest OCaml Weekly News, for the week of October 27 to November 03, 2020. Table of Contents ───────────────── Brr 0.0.1, a toolkit for programming browsers New release of Monolith (20201026) MirageOS 3.9.0 released An AST typing problem erlang 0.0.14, a toolkit to manipulate Erlang sources opam-bin.1.0.0: binary packages for opam Interesting OCaml Articles Old CWN 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/9> Continuing this thread, Daniel Bünzli said ────────────────────────────────────────── One thing I forgot, is that there is a [todomvc] example in the repo, see `todomvc.{html,ml}' in [this directory]. It doesn't use the UI toolkit you mentioned, just the basic reactive DOM support provided by [`Brr_note'] and [`Brr_note_kit']. But you can see how quickly you get reusable and composable components like [`bool_editor'] and [`string_editor']. The program structure in that example is quite similar to the one I had in the drawing app. You define a purely functional, non reactive [data model], [actions] over the data model, create small UI fragments that renders parts of your data model and generate actions events for it, gradually glue them together using note combinators and finally define a [fixed point signal] that holds the data model as massaged by the actions events of your UI (as mentioned I'd like to replace fix points by direct `let rec' and a lazy infinitesimal delay combinator). There are a few pitfalls like you should avoid retaining parts of your data model in the UI otherwise you could get outdated data come back in your model (makes for very fun and spooky bugs though). Identity in the data model is also a bit tricky, it seems in todomvc I [used] `=='. That didn't work in the drawing app where my surfaces had properties that could be updated but they could also be linked toghether (that window belongs to that wall etc.) so I needed stable identifiers for which I introduced a little abstraction to identify values and define relations between them. One thing I remember fondly when doing the drawing app is that I would still get the odd interaction glitches you get when coding direct mouse manipulation interactions (surface definition/selection/move/transform) however thanks to the ability to denotationally reason and act (left leaning [`E.select']) on the simultaneity of events, they were easy to understand and fix in an explicit way (that is via a defining *expression*). Also if you get into [`Note'] the denotational semantics notation is not yet explained there, refer to the [one of react] it's the same. [todomvc] <http://todomvc.com/> [this directory] <https://github.com/dbuenzli/brr/tree/master/test> [`Brr_note'] <https://erratique.ch/software/brr/doc/Brr_note/index.html> [`Brr_note_kit'] <https://erratique.ch/software/brr/doc/Brr_note_kit/index.html> [`bool_editor'] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L229> [`string_editor'] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L213-L214> [data model] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L36> [actions] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L101> [fixed point signal] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L314-L324> [used] <https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L84> [`E.select'] <https://erratique.ch/software/note/doc/Note/E/index.html#val-select> [`Note'] <https://erratique.ch/software/note/doc/Note/> [one of react] <https://erratique.ch/software/react/doc/React/index.html#sem> Yoann Padioleau asked and Daniel Bünzli replied ─────────────────────────────────────────────── How hard would it be to build on top of Brr_note something like an Elm Architecture-style toolkit? I know there's a TEA-Bucklescript library, but I'd rather use something relying on dune/jsoo. I've read somewhere else that you were a bit skeptical about the advantage of MVU (movel-view-update) over MVC, but I personnaly find the counter UI example in ELM at <https://guide.elm-lang.org/architecture/buttons.html> far simpler than the corresponding one in Brr at <https://github.com/barko/brr-eg/blob/master/counter/counter.ml> I don't know. I didn't look into MVU too much, but to me it's largely a remix of MVC – despite what its proponents try to tell you. Since we now live in an age of software adverstising it's a bit hard to get frank assessments. As far as I'm concerned the compositionality story of MVU doesn't look great. Basically it enforces state machines on you, and composing state machines is a bit meh. In FRP state machines become signals (via `S.accum') which are highly composable entities with *fine granularity* (and bonus point, a well defined denotational semantics for equational reasoning). If you are looking for MVU I think you can simply jump on [LexiFI's vdom]. But when I see how you get to [compose two models] in that paradigm, I'm not convinced. There’s no need for those E.select. The UI is IMHO more declarative in ELM. That example could be rewritten (I didn't write the examples in this repo) to be more like the ELM one in it's declarations. But I think the ELM example is also more rigid. You may not like that `E.select' on this toy example, but you may get to enjoy it you when you start composing larger systems from smaller components. [LexiFI's vdom] <https://github.com/LexiFi/ocaml-vdom> [compose two models] <https://github.com/LexiFi/ocaml-vdom/blob/9c5e42888ba72e69d5a018e38a4633e400913bfb/examples/demo/demo.ml#L196-L223> Yaron Minsky then said ────────────────────── You might be interested in Bonsai! At some level, you can think of it as a library for building composable state machines. It uses [Incremental] as its engine for incrementalizing the computation of views, with a virtual-dom implementation underneath. <https://github.com/janestreet/bonsai> It's the primary tool we use for building UIs inside of Jane Street. In some ways, Bonsai is like Elm, but it has its own interesting ideas. Some of the concepts are borrowed from this paper: <https://www.cl.cam.ac.uk/~jdy22/papers/the-arrow-calculus.pdf> though I won't pretend to understand this paper myself! Bonsai doesn't yet have enough public-facing documentation, and really the bleeding edge version on github is considerably better and more usable than the one released into opam. But there's at least one public-facing UI that's built with it, if you want a real-world example. <https://blog.janestreet.com/finding-memory-leaks-with-memtrace/> [Incremental] <https://github.com/janestreet/incremental> Yoann Padioleau replied ─────────────────────── Thx for the links! The memtrace viewer example is pretty cool, but Bonsai looks far more complicated than ELM. If you look at the counter example (the hello world of UI), here: <https://github.com/janestreet/bonsai/blob/master/examples/counters/lib/bonsai_web_counters_example.ml> and you compare it to the one in ocaml-vdom (thx @dbuenzli for the link) at <https://github.com/LexiFi/ocaml-vdom/blob/master/examples/counters/counters.ml> there's a huge difference in simplicity. Ty Overby then said ─────────────────── Hi Aryx, I wrote the Bonsai example that you linked, and it certainly isn't the most concise, but that's because it was built for a tutorial on building small components (one counter is a single component), how to use more advanced combinators (Bonsai.assoc), and how to move data from one component to another (the add_counter_component into the associated counters component.) I think it's a great example of the power of structuring an UI as a DAG rather than a tree, but it definitely doesn't make for the most concise code! In the example, the comments that look like "CODE_EXCERPT_BEGIN" are actually preprocessor definitions that are used in the (honestly, kinda out of date) [tutorial here]. A bonsai app that wasn't written for such a tutorial would look more like [this]. [tutorial here] <https://github.com/janestreet/bonsai/blob/master/docs/getting_started/open_source/counters.mdx> [this] <https://gist.github.com/TyOverby/e0f7e944d002cdf7144aaf0102d16ed5> New release of Monolith (20201026) ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-monolith-20201026/6667/1> François Pottier announced ────────────────────────── It is my pleasure to announce a major new release of Monolith. ┌──── │ opam update && opam install monolith └──── Monolith offers facilities for testing an OCaml library (for instance, a data structure implementation) by comparing it against a reference implementation. It can be used to perform either random testing or fuzz testing. Fuzz testing relies on the external tool afl-fuzz. More information on Monolith is available [here] and in the draft paper [Strong Automated Testing of OCaml Libraries]. [here] <https://gitlab.inria.fr/fpottier/monolith> [Strong Automated Testing of OCaml Libraries] <http://cambium.inria.fr/~fpottier/publis/pottier-monolith-2021.pdf> MirageOS 3.9.0 released ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-mirageos-3-9-0-released/6668/1> Martin Lucina announced ─────────────────────── We are pleased to announce the release of MirageOS 3.9.0. Our last release announcement was for [MirageOS 3.6.0], so we will also cover changes since 3.7.x and 3.8.x in this announcement. New features: • The Xen backend has been [re-written from scratch] to be based on Solo5, and now supports PVHv2 on Xen 4.10 or higher, and QubesOS 4.0. • As part of this re-write, the existing Mini-OS based implementation has been retired, and all non-UNIX backends now use a unified OCaml runtime based on `ocaml-freestanding'. • OCaml runtime settings settable via the `OCAMLRUNPARAM' environment variable are now exposed as unikernel boot parameters. For details, refer to [#1180]. Security posture improvements: • With the move to a unified Solo5 and ocaml-freestanding base MirageOS unikernels on Xen gain several notable improvements to their overall security posture such as SSP for all C code, W^X, and malloc heap canaries. For details, refer to the mirage-xen 6.0.0 release [announcement]. API breaking changes: • Several Xen-specific APIs have been removed or replaced, unikernels using these may need to be updated. For details, refer to the mirage-xen 6.0.0 release [announcement]. Other notable changes: • `Mirage_runtime' provides event loop enter and exit hook registration ([#1010]). • All MirageOS backends now behave similarly on a successful exit of the unikernel: they call `exit' with the return value 0, thus `at_exit' handlers are now executed ([#1011]). • The unix backend used a toplevel exception handler, which has been removed. All backends now behave equally with respect to exceptions. • Please note that the `Mirage_net.listen' function still installs an exception handler, which will be removed in a future release. The out of memory exception is no longer caught by `Mirage_net.listen' ([#1036]). • To reduce the number of OPAM packages, the `mirage-*-lwt' packages are now deprecated. `Mirage_net' (and others) now use `Lwt.t' directly, and their `buffer' type is `Cstruct.t' ([#1004]). • OPAM files generated by `mirage configure' now include opam build and installation instructions, and also an URL to the Git `origin' ([#1022]). Known issues: • `mirage configure' fails if the unikernel is under version control and no `origin' remote is present ([#1188]). • The Xen backend has issues with event delivery if built with an Alpine Linux GCC toolchain. As a work-around, please use a Fedora or Debian based toolchain. Acknowledgements: • Thanks to Roger Pau Monné, Andrew Cooper and other core Xen developers for help with understanding the specifics of how Xen PVHv2 works, and how to write an implementation from scratch. • Thanks to Marek Marczykowski-Górecki for help with the QubesOS specifics, and for forward-porting some missing parts of PVHv2 to QubesOS version of Xen. • Thanks to @palainp on Github for help with testing on QubesOS. [MirageOS 3.6.0] <https://mirage.io/blog/announcing-mirage-36-release> [re-written from scratch] <https://github.com/mirage/mirage/issues/1159> [#1180] <https://github.com/mirage/mirage/pull/1180> [announcement] <https://github.com/mirage/mirage-xen/releases/tag/v6.0.0> [#1010] <https://github.com/mirage/mirage/pull/1010> [#1011] <https://github.com/mirage/mirage/pull/1011> [#1036] <https://github.com/mirage/mirage/issues/1036> [#1004] <https://github.com/mirage/mirage/issues/1004> [#1022] <https://github.com/mirage/mirage/pull/1022> [#1188] <https://github.com/mirage/mirage/issues/1188> An AST typing problem ═════════════════════ Archive: <https://discuss.ocaml.org/t/an-ast-typing-problem/3677/8> Chet Murthy announced ───────────────────── This note discusses the beginnings of an OCaml attribute-grammar evaluator generator. You can find this code on github at `camlp5/pa_ppx_ag'. All of this code is implemented using `camlp5' and the `pa_ppx' suite of PPX rewriters. Caveat: this code is less than a week old, so it's changing fast. In the unlkely event that anybody out there is actually interested in using this code, I'm happy to help in any way I can. But just be aware that it's changing -really- fast. Attribute Grammars for the multipass AST analysis problem ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ A year-and-a-half ago, the OP "An AST Typing Problem" (<https://discuss.ocaml.org/t/an-ast-typing-problem/3677>) raised the problem of how to deal with ASTs, in the presence of multiple passes of program-analysis, each of which will want to hang various bits of data off nodes. The author of the OP pointed also at a couple of posts on Lambda-the-Ultimate (LtU), discussing related problems. The author notes: There’s a lot of passes, many of which depend on the previous ones, each one making some slight change to the AST which might or might not result in having to walk through the whole AST to catch all occurrences of that particular node. Clearly you’ll want to encode semantic errors in the types, so each pass ends up having its own unique AST, each depending on the previous one. To change a single node deep in the AST I have to write about a hundred lines of types and mapping functions’ worth of boilerplate. Any change in the lower levels of the AST bubbles up to the higher ones, and refactoring becomes a nightmare. I've been thinking about this problem ever since, and at the time, had suggested that while it seemed like attribute-grammars might be a workable solution, they were a pretty heavy hammer. It doesn't help (of course) that there exist no attribute-grammar evaluator generators, for OCaml. Also, at least in the LtU threads, there was discussion of modifying the AST, and having the analyses automatically be updated for the modified AST. Obviously this would require an incremental re-attribution algorithm: more complexity and again, something that isn't implemented for OCaml. But imagine that there existed an attribute-grammar evaluator generator for OCaml. So for a simple language of expressions, with an assignment-operator, we could write an evaluator as an attribute-grammar. Imagine that you could write an ast like this (test1_ast.ml): ┌──── │ type expr = │ INT of int │ | BINOP of binop * expr * expr │ | UNOP of unop * expr │ | REF of string │ | ASSIGN of string * expr │ | SEQ of expr * expr │ and unop = UPLUS | UMINUS │ and binop = PLUS | MINUS | STAR | SLASH | PERCENT │ and prog = expr └──── and then (having elsewhere written parser/pretty-printer) declare attributes on those types (test1_variants.ml): ┌──── │ module Attributed = struct │ [%%import: Test1_ast.expr] │ [@@deriving attributed { │ attributed_module_name = AT │ ; normal_module_name = OK │ ; attributes = { │ expr = { │ inh_env = [%typ: (string * int) list] │ ; syn_env = [%typ: (string * int) list] │ ; value_ = [%typ: int] │ } │ ; prog = { │ value_ = [%typ: int] │ } │ ; binop = { │ oper = [%typ: int -> int -> int] │ } │ ; unop = { │ oper = [%typ: int -> int] │ } │ } │ }] │ end └──── and then declare attribute equations (test1_ag.ml): ┌──── │ module REC = struct │ [%%import: Test1_variants.Attributed.AT.expr] │ [@@deriving ag { │ module_name = AG │ ; storage_mode = Records │ ; axiom = prog │ ; attributes = { │ expr = { │ inh_env = [%typ: (string * int) list] │ ; syn_env = [%typ: (string * int) list] │ ; value_ = [%typ: int] │ } │ ; prog = { │ value_ = [%typ: int] │ } │ ; binop = { │ oper = [%typ: int -> int -> int] │ } │ ; unop = { │ oper = [%typ: int -> int] │ } │ } │ ; attribution = { │ expr__INT = ( │ [%nterm 0].syn_env := [%nterm 0].inh_env ; │ [%nterm 0].value_ := [%prim 1].intval │ ) │ ; expr__BINOP = ( │ [%nterm expr.(1)].inh_env := [%nterm expr].inh_env ; │ [%nterm expr.(2)].inh_env := [%nterm expr.(1)].syn_env ; │ [%nterm expr].syn_env := [%nterm expr.(2)].syn_env ; │ [%nterm expr].value_ := [%nterm binop.(1)].oper [%nterm expr.(1)].value_ [%nterm │ expr.(2)].value_ │ ) │ ; expr__UNOP = ( │ [%nterm expr.(1)].inh_env := [%nterm expr].inh_env ; │ [%nterm expr].syn_env := [%nterm expr.(1)].syn_env ; │ [%nterm expr].value_ := [%nterm unop.(1)].oper [%nterm expr.(1)].value_ │ ) │ ; expr__REF = ( │ [%nterm 0].syn_env := [%nterm 0].inh_env ; │ [%nterm 0].value_ := List.assoc [%prim 1].stringval [%nterm 0].inh_env │ ) │ ; expr__ASSIGN = ( │ [%nterm 0].syn_env := ([%prim 1].stringval, [%nterm expr.(1)].value_) :: [%nterm │ expr.(1)].syn_env ; │ [%nterm expr.(1)].inh_env := [%nterm 0].inh_env ; │ [%nterm 0].value_ := [%nterm expr.(1)].value_ │ ) │ ; expr__SEQ = ( │ [%nterm 1].inh_env := [%nterm 0].inh_env ; │ [%nterm 2].inh_env := [%nterm 1].syn_env ; │ [%nterm 0].syn_env := [%nterm 2].syn_env ; │ [%nterm 0].value_ := [%nterm 2].value_ │ ) │ ; prog = ( │ [%nterm 1].inh_env := [] ; │ [%nterm 0].value_ := [%nterm 1].value_ ; │ assert True │ ) │ ; unop__UPLUS = ( │ [%nterm unop].oper := fun x -> x │ ) │ ; unop__UMINUS = ( │ [%nterm unop].oper := fun x -> (- x) │ ) │ ; binop__PLUS = ( │ [%nterm binop].oper := (+) │ ) │ ; binop__MINUS = ( │ [%nterm binop].oper := (-) │ ) │ ; binop__STAR = ( │ [%nterm binop].oper := fun a b -> a*b │ ) │ ; binop__SLASH = ( │ [%nterm binop].oper := (/) │ ) │ ; binop__PERCENT = ( │ [%nterm binop].oper := (mod) │ ) │ } │ }] │ end └──── and then, turning a crank, you would get an evaluator: ┌──── │ let test_records ctxt = │ assert_equal 3 ({| x := 1 ; x ; y := 2 ; x + y |} |> pa_prog_attributed |> REC.AG.evaluate) │ ; assert_equal 0 ({| x := 1 ; y := 2 ; x / y |} |> pa_prog_attributed |> REC.AG.evaluate) └──── where `pa_prog_attributed' is a parser that parses the surface syntax into an AST, which has empty slots for all attributes, and `REC.AG.evaluate' evaluates attributes in its argument AST, and then returns a tuple of all the synthesized attributes of the root node. Retaining familiar surface syntax for pattern-matching and constructing ASTs ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Now, we don't want to give up easy pattern-matching and construction of the AST, just because the AST has attributes strewn throughout it. But we don't have to: with Camlp5's "quotations", once we define a surface syntax parser for the basic AST (unadorned with attributes – viz. `test1_ast.ml'), we can use that to bootstrap ourselves to a surface syntax parser for expressions and patterns over that AST, and then in a similar manner we can get them for the AST adorned with attributes. This has already been done for hashconsed ASTs, and ASTs with built-in unique-IDs, and and doing it for "attributed ASTs" isn't any harder. Those examples can be found in the github project `camlp5/pa_ppx_q_ast'. Limitations ╌╌╌╌╌╌╌╌╌╌╌ There are still limitations. 1. The current code only implements topological-order evaluation. That is, it builds the entire dependency-graph, topologically-sorts it, and then evaluates attributes. This is …. suboptimal, when we well know that almost all interesting AGs are already in the class of ordered attribute-grammars (OAGs). I plan to implement the OAG evaluation strategy next. 2. Traditionally AGs are defined over "productions" which are sequences of nonterminals and terminals. This doesn't correspond to the way we define OCaml constructor data-types. So instead of a constructor like ┌──── │ type expr = │ ... | Call of name * arg_list │ and arg_list = NoArgs | SomeArgs of expr * arg_list └──── we might want to use ~ 'a list~ ┌──── │ type expr = │ ... | Call of name * expr list └──── Problem is: defining attribute-equations for (effectively) an array of nodes, is not part of the standard lingo of AGs. But I believe we can invent new syntax and make this succinct. 3. Storage optimization. A naive implementation of AGs can store all attributes ever computed, at all the nodes in the AST. This can use a lot of memory. But there are well-known techniques to discard attributes once they'll never more be needed in the rest of the attribute-evaluation, and I plan to implement these techniques. There's an entire literature on things like remote-references in attribute grammars, aggregates, and other things, all of which can probably be usefully employed. Conclusion ╌╌╌╌╌╌╌╌╌╌ I think that attribute-grammars could be a useful way to structure complex multipass program-analysis, just as they used to do back in the good ol' days. Maybe worth a look-see! erlang 0.0.14, a toolkit to manipulate Erlang sources ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-erlang-0-0-14-a-toolkit-to-manipulate-erlang-sources/6694/1> ostera announced ──────────────── Hej, hope you're staying safe :raised_hands: I'm excited to share with you the first release of `erlang'. *tl;dr*: _parser/lexer/ast/printer for Erlang_ Description ╌╌╌╌╌╌╌╌╌╌╌ `erlang' is a toolkit for manipulating Standard Erlang and Core Erlang sources and their abstract syntax trees according to the Erlang specifications. Version 0.0.14 provides: • A lexer/parser written in Menhir for Standard Erlang • ASTs for Core Erlang and Standard Erlang • An AST helper module for constructing Standard Erlang programs • A printer for the Standard Erlang AST (of highly volatile prettiness) • Support to turn ASTs to S-expressions • `erldump', a binary tool for reading Erlang sources and printing their concrete syntax trees as S-expressions. It is distributed under Apache-2.0 license, depends on Menhir and Cmdliner, and it is being developed as part of the Caramel project. • *PR*: <https://github.com/ocaml/opam-repository/pull/17553> – should be on opam.ocaml.org sometime tomorrow :) • *Homepage*: <https://github.com/AbstractMachinesLab/caramel> • *Install*: `opam install erlang' • *API Docs & manuals*: maybe on next release, but _follow the types_, and the `Erlang.Ast_helper' module is modeled after the `Parsing.Ast_helper' so it should feel familiar. I started writing `erlang' to let Caramel do an entirely symbolic compilation from the OCaml typedtree that would still allow for other passes/checks to be made cleanly. It's come with a decent number of tests, and it can parse some OTP modules with small modifications. There's [a few outstanding issues] regarding the parsing for the next release, but it should be a starting point for anyone wanting to read sources and _do something_ with them. I plan on cover these issues in the rest of the year, but as with all open source, it may take longer. I'd like to add a few other things, like an AST invariants module to check that ASTs are actually valid Erlang programs, and transformations more suitable for static analyses of the sources. My thanks go to @antron, @c-cube, @Drup, @rgrinberg, and @mseri for helping me get around the OCaml compiler, Menhir, and eventually to get this version split from Caramel and released independently. Also a shoutout to the Js_of_ocaml project that served as a starting point for the parser/lexer work here. If you can give me some feedback on the design and implementation, I'd very much like to hear your thoughts :slight_smile: For those of you hoping to start using it, _do not_ let it crash. [a few outstanding issues] <https://github.com/AbstractMachinesLab/caramel/issues?q=is%3Aissue+is%3Aopen+label%3Alib%3Aerlang> opam-bin.1.0.0: binary packages for opam ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-bin-1-0-0-binary-packages-for-opam/6696/1> Fabrice Le Fessant announced ──────────────────────────── I am happy to announce the first stable release of `opam-bin', version 1.0.0, a framework to CREATE, USE and SHARE binary relocatable packages with opam, to speed-up installation of packages. It is easily installable from opam-repository, and available on Github: <https://ocamlpro.github.io/opam-bin> With opam-bin, you can : • build binary packages while installing their source counterpart with opam • automatically reuse previously created binary packages instead of compiling them again • export and share your binary packages as part of opam repositories for other users/computers to use `opam-bin' is a framework in 3 parts : • a tool `opam-bin' to create binary packages: <https://ocamlpro.github.io/opam-bin> • a set of patches to make some packages relocatable (`opam-bin' will apply them automatically when building packages), including patches to make the OCaml distribution relocatable from version 4.02.0 to 4.11.1: <https://github.com/ocamlpro/relocation-patches> • a set of contributed repositories of binary packages. For now, there is only one contribution, during the summer, by Origin Labs : <https://www.origin-labs.com/opam-bin/debian10.4-amd64/> containing 5 repos, among which the "4.10.0" repo contains more than 1800 packages. These repos can be used DIRECTLY WITH opam, WITHOUT USING opam-bin. This is the first stable release: • Specific support has been added in the current `master' branch of `opam' to make working with this version more convenient, by printing pre- and post- installation messages. Yet, it will still work with previous version of opam, but with no output on the terminal when calling opam. • The `sharing' option can be enabled to share files with hard-links between switches, making the creation of new local switches almost costless in time and disk space. `opam-bin' is a collaborative work between OCamlPro and Origin Labs. `opam-bin' is particularly useful if you create many local switches, as they become unexpensive. Tools like Drom (an OCaml project scaffolder, <https://ocamlpro.github.io/drom>) can take advantage of that to provide a cargo-like experience. Interesting OCaml Articles ══════════════════════════ Archive: <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/63> Ryan Slade announced ──────────────────── Anyone who's been following this blog probably saw this coming: <https://blog.darklang.com/leaving-ocaml/> It's an interesting read and hopefully can be used as constructive criticism in order to improve the state of the OCaml ecosystem. 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: 53584 bytes --]
[-- Attachment #1: Type: text/plain, Size: 22326 bytes --] Hello Here is the latest OCaml Weekly News, for the week of November 24 to December 01, 2020. Table of Contents ───────────────── drom.0.2.0: OCaml Project Manager, beta release OCaml on the BEAM webinar ocaml-lsp-server 1.3.0 OCaml User Survey 2020 http-cookie 2.0.0 reparse 2.0.0 VSCode OCaml Platform v1.5.0 Database modelling Opium 0.19.0 Operator lookup tool for OCaml Other OCaml News Old CWN drom.0.2.0: OCaml Project Manager, beta release ═══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-drom-0-2-0-ocaml-project-manager-beta-release/6841/1> Fabrice Le Fessant announced ──────────────────────────── I am happy to announce the first release of `drom', version 0.2.0, a tool to create and manage OCaml projects. `drom' is a simple layer on top of `opam' and `dune', with project and package descriptions written in TOML syntax. It is an attempt at providing a `cargo'-like experience for developers, with builtin support for standard OCaml tools (`opam', `dune', `odoc', etc.) and source managers (Github for now, with Github Actions and Github Pages). There are mainly 2 use-cases of `drom': • Scafolding tool: `drom' makes it easy to create OCaml projects by generating all the files needed for a standard OCaml project. It creates files for `opam' and `dune', formatters (`ocp-index' and `ocamlformat'), documentation (`sphinx' and `odoc'), testing directories and Github CI. Once these files have been created, `drom' is not needed anymore and you can keep using your preferred tools. • Management tool: `drom' can also be used to keep managing the project afterwards. It has commands like `drom build' to build the project, automatically installing a local switch with all needed dependencies, `drom doc' to generate the documentation and `drom test' to execute tests. `drom' works as a simple interface over `opam' and `dune' so you almost never need to use them directly. <https://ocamlpro.github.io/drom> (this site and the documentation was mostly generated by `drom' itself) `drom' is available in the official opam repository. Examples: ┌──── │ $ drom new mylib --skeleton library // generate library project │ // or │ $ drom new hello // generate program project │ │ $ cd hello │ $ emacs drom.toml // edit the project description │ $ drom project // update files │ $ drom build // create local switch and build │ // or │ $ drom build --switch 4.10.0 // use global switch and build │ $ ./hello // run the executable │ $ drom test // run tests │ $ drom install // install in opam switch └──── This is an early release to get feedback from users. `drom' has been tested on several of our internal projects, like `opam-bin' and `ez_file'. Since `drom' creates local `opam' switches for every project by default (though it is possible to use global switches too), it is advised to use it with `opam-bin' to speed up switch creation and upgrades. `drom' works by creating projects using "skeletons", i.e. project and package templates. `drom' comes with a few predefined skeletons (`program' or `library'), and allows users to add their own skeletons. We will of course extend the substitution language to help users develop such new skeletons. `drom' is a collaborative work between OCamlPro and Origin Labs. François Bobot asked and Fabrice Le Fessant replied ─────────────────────────────────────────────────── I'm very happy to see work in the OCaml world in that direction. I was currently looking for duniverse for that kind of need. Do they fullfil different needs or how do they compare? My understanding is that `duniverse' tackles the problem of the "mono-repo", i.e. when you want to manage many different projects as just one project, using `dune' capacity to build them all at once. I would say that `drom' tackles an orthogonal problem, which is to simplify the creation of simple OCaml projects (generating all the standard files you need, like Makefile, dune-project, dune, .ocamlformat, .github CI, documentation, license, etc.) and day-to-day management (changing dependencies, having a copy of headers that you can insert in new files, etc.). It also provides a single interface over basic opam/dune commands. It would probably be possible to use `duninverse' on a set of projects containing projects generated by `dune', but I don't know enough about `duniverse' to be sure. Of course, `drom' can manage projects composed of multiple libraries and executables (called `packages' because `drom' generates one `opam' file for every one of them), but I wouldn't call that a mono-repo, it's just frequent to have more than one package in a small project. OCaml on the BEAM webinar ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-on-the-beam-webinar/6851/1> Yawar Amin announced ──────────────────── Erlang Solutions is going to do a webinar on Leandro Ostera's new BEAM backend for OCaml: <https://www2.erlang-solutions.com/webinar-registration-2> Should be exciting! ocaml-lsp-server 1.3.0 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-3-0/6856/1> Rudi Grinberg announced ─────────────────────── On behalf of the ocaml-lsp team, I’d like to announce version 1.3.0. This release an improvement in keyword completion and a new code action. Keywords are now filtered by the context the user requested the completion, and there's a new code action to quickly populate .mli files with the the inferred types from the .ml file. OCaml User Survey 2020 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/28> Xavier Leroy announced ────────────────────── Here is a summary and analysis of the survey results I wrote on behalf of the OCaml Software Foundation: <https://www.dropbox.com/s/omba1d8vhljnrcn/OCaml-user-survey-2020.pdf?dl=0> Enjoy! http-cookie 2.0.0 ═════════════════ Archive: <https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/1> Bikal Lem announced ─────────────────── A new version of `cookies' package - now named `http-cookie'- has been released to opam. This version has been rewritten to remove all its external and ppx dependencies and now only depends on stock ocaml and its stdlib. `http-cookie' is a [RFC 6265] compliant HTTP cookie library. RFC 6265 is a HTTP cookie standard specifying cookie data validity requirements. Additionally, I have also removed the use of `Result.t' from the previous version and have used plain old exceptions to denote any cookie data validation errors. • [Github - http-cookie] • [Docs - http-cookie] [RFC 6265] <https://tools.ietf.org/html/rfc6265> [Github - http-cookie] <https://github.com/lemaetech/http-cookie> [Docs - http-cookie] <https://lemaetech.co.uk/http-cookie/> reparse 2.0.0 ═════════════ Archive: <https://discuss.ocaml.org/t/ann-reparse-2-0-0/6868/1> Bikal Lem announced ─────────────────── A new version of `reparse' 2.0.0 has been released to opam. Reparse is a monadic, recursive descent based, comprehensive, parser construction library for ocaml. CHANGES for version 2.0.0: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Rewrite the whole package to use exceptions rather than `result' type • Adds many more parsing combinators • Adds comprehensive unit tests • Adds comprehensive documentation, host documentation and add links in repo home page • Adds abstraction for input source • Provides unix file source and string input source • Adds separate package `reparse-unix' for unix file input • Adds calc.ml and json.ml in examples. Additionally, the API is now comprehensively documented with at least an example for each API call. • [Github Reparse] • [API Docs] [Github Reparse] <https://github.com/lemaetech/reparse> [API Docs] <https://lemaetech.co.uk/reparse/> VSCode OCaml Platform v1.5.0 ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-5-0/6871/1> Max Lantas announced ──────────────────── We are happy to announce the v1.5.0 release of [VSCode OCaml Platform], a Visual Studio Code extension for OCaml. It is available on the [VSCode Marketplace] and [Open VSX Registry]. This release has the following changes: • Highlight `rec' keyword in OCaml mli files for recursive modules ([#434]) • Highlight `cram' stanza in dune-project files ([#441]) • Fix reason highlighting of let extensions ([#447]) • Improve highlighting of Menhir new syntax ([#450]) • Improve Menhir syntax highlighting ([#455]) • Add `Alt + P' keyboard shortcut for infer interface code action ([#448]) • Infer interface when switching to a non-existing interface file ([#437]) This is the first release to be automatically published to Open VSX, which will benefit users of [VSCodium] and other editors. Please feel free to share feedback. [VSCode OCaml Platform] <https://github.com/ocamllabs/vscode-ocaml-platform> [VSCode Marketplace] <https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform> [Open VSX Registry] <https://open-vsx.org/extension/ocamllabs/ocaml-platform> [#434] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/434> [#441] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/441> [#447] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/447> [#450] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/450> [#455] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/455> [#448] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/448> [#437] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/437> [VSCodium] <https://github.com/VSCodium/vscodium> Database modelling ══════════════════ Archive: <https://discuss.ocaml.org/t/database-modelling/1150/2> Reviving this very old thread, paul announced ───────────────────────────────────────────── And a version for postgresql: <https://github.com/pat227/ocaml-pgsql-model.git> Opium 0.19.0 ════════════ Archive: <https://discuss.ocaml.org/t/ann-opium-0-19-0/6876/1> Thibaut Mattio announced ──────────────────────── On behalf of the Opium team, I am pleased to announce a new version of Opium (`0.19.0') is available on Opam. This release comes with a complete rewrite of Opium's internals to switch from Cohttp to Httpaf (work done by @anuragsoni). As demonstrated in several benchmarks, Httpaf's latency is much lower than Cohttp's in stress tests, so it is expected that Opium will perform better in these high-pressure situations. The underlying HTTP server implementation is now contained in a `rock' package, that provides a Service and Filter implementation, inspired by Finagle's. The architecture is similar to Ruby's Rack library (hence the name), so one can compose complex web applications by combining Rock applications. The `rock' package offers a very slim API, with very few dependencies, so it should be an attractive option for other Web frameworks to build on, which would allow the re-usability of middlewares and handlers, independently of the framework used (e.g. one could use Sihl middlewares with Opium, and vice versa). Apart from the architectural changes, this release comes with a lot of additional utilities and middlewares which should make Opium a better candidate for complex web applications, without having to re-write a lot of common Web server functionalities. The Request and Response modules now provide: • JSON encoders/decoders with `Yojson' • HTML encoders/decoders with `Tyxml' • XML encoders/decoders with `Tyxml' • SVG encoders/decoders with `Tyxml' • multipart/form encoders/decoders with `multipart_form_data' • urlencoded encoders/decoders with `Uri' And the following middlewares are now built-in: • `debugger' to display an HTML page with the errors in case of failures • `logger' to log requests and responses, with a timer • `allow_cors' to add CORS headers • `static' to serve static content given a custom read function (e.g. read from S3) • `static_unix' to serve static content from the local filesystem • `content_length' to add the `Content-Length' header to responses • `method_override' to replace the HTTP method with the one found in the `_method' field of `application/x-www-form-urlencoded' encoded `POST' requests. • `etag' to add `ETag' header to the responses and send an HTTP code `304' when the computed ETag matches the one specified in the request. • `method_required' to filter the requests by the HTTP method and respond with an HTTP code `405' if the method is not allowed. • `head' to add supports for `HEAD' request for handlers that receive `GET' requests. Lastly, this release also adds a package `opium-testing' that can be used to test Opium applications with Alcotest. It provides `Testable' modules for every Opium types, and implements helper functions to easily get an `Opium.Response' from an `Opium.Request'. As this release changes the API drastically, we will keep maintaining the `0.18.0' branch for bug fixes, for users who don't want to (or can't) migrate to `0.19.0'. What's next? ╌╌╌╌╌╌╌╌╌╌╌╌ Recent discussions have shown that building optimized applications was not trivial. This is partly due to the lack of documentation, and probably because some configurations that should come by default, are left to the user to optimize. Therefore, we will keep performance in mind for the next release and investigate the current bottlenecks in Opium. We will also continue adding higher-level functionalities to Opium to make users productive with real-world applications. This includes: • Sessions support (with signed cookies) • Handlers for authentication • Adding more middlewares (compression, flash messages, caching, etc.) Your feedback is welcome, don't hesitate to open Issues on Github! Andreas Poisel asked and Anurag Soni replied ──────────────────────────────────────────── Does Opium + Httpaf support TLS? It doesn't at the moment. Calascibetta Romain then said ───────────────────────────── According the interface of `opium', it's possible to have the support of TLS (with `ocaml-tls') with the [new version of Conduit] and [`paf'] (which is a MirageOS compatible layer of HTTP/AF - unreleased): ┌──── │ let stack ip = │ Tcpip_stack_socket.UDPV4.connect (Some ip) >>= fun udpv4 -> │ Tcpip_stack_socket.TCPV4.connect (Some ip) >>= fun tcpv4 -> │ Tcpip_stack_socket.connect [ ip ] udpv4 tcpv4 │ │ let http_with_conduit (ip, port) error_handler request_handler = │ Paf.https httpaf_config ~error_handler ~request_handler:(fun _ -> request_handler) │ ({ Paf.TCP.stack= stack ip │ ; keepalive= None │ ; nodelay= false │ ; port= port}, Tls.Config.server ~certificates ()) │ │ let () = match Lwt_main.run (Opium.run (https_with_conduit (Ipaddr.V4.localhost, 4343)) opium_app) with │ | Ok () -> () │ | Error err -> Fmt.epr "%a.\n%!" Conduit_mirage.pp_error err └──── I used it for a long time on my personal unikernels and did some tests to ensure that [it does fails when it handles many requests]. Note that you are able to use OpenSSL too if you want. [new version of Conduit] <https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611> [`paf'] <https://github.com/dinosaure/paf-le-chien/> [it does fails when it handles many requests] <https://github.com/dinosaure/paf-le-chien/pull/12> Robin Björklin also replied ─────────────────────────── If you want to use this new version of Opium there are ways around this problem. You could have Haproxy (or similar) terminate your TLS connections externally and if your environment requires TLS for your internal network something like [Consul Connect] can cover that use-case for you. [Consul Connect] <https://learn.hashicorp.com/tutorials/consul/get-started-service-networking?in=consul/getting-started> Operator lookup tool for OCaml ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-operator-lookup-tool-for-ocaml/6882/1> Craig Ferguson announced ──────────────────────── I'm pleased to announce the initial release of craigfe.io/operator-lookup/, a search tool for OCaml operators and syntax elements: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/ee41569b4426c9b77fd6d367e50ff5ac759f4e46_2_1034x558.png> For each operator, the tool provides a short explanation of its behaviour, examples of usage and warnings of common misuses and misunderstandings: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/8/879ae652a8895fa0258bc288c8d0c819cb9ef314_2_920x1000.png> The intent of writing this tool was to give OCaml beginners a quick way to find the standard / conventional operators in the language and to disambiguate "operator-like" syntax that can be hard to search for otherwise. It currently supports: • all standard library operators, • conventional infix operators (`>>=', `>>|', `>|='), • binding operators (`let+', `let*', `and+', etc.), • syntax that is often confused for an operator (`#', `;;'). Please let me know if you have any suggestions for improvements. I hope you find it useful! Acknowledgements ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This tool is heavily based on the [JavaScript operator lookup] utility by [Josh Comeau]. Thanks to him for the initial idea and for allowing me to re-use his design elements. [JavaScript operator lookup] <https://www.joshwcomeau.com/operator-lookup/> [Josh Comeau] <https://twitter.com/JoshWComeau> Kakadu asked and Craig Ferguson replied ─────────────────────────────────────── It's not obvious for me are these operators hardcoded or do you scan opam packages from time to time? They're hardcoded. The operators fall into three classes: • The vast majority of them are from the `Stdlib' module, so I don't expect those to change very regularly. • A small number of "conventional" operators used in the community (`>>=', `let*', etc.). Even for that small set there is some divergence in Opam – c.f. `>>|' vs `>|=' for a _map_ operator – so I suspect there are not many other candidates for this group. • There are a few regexes behind the scenes for catching valid operator names that don't fall into the first two categories. e.g. many search terms are classified as "_a left-associative operator_" with a correspondingly vague description. Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [“Universal” Dune Tip: Rebuild Stuff, Sometimes] [OCaml Planet] <http://ocaml.org/community/planet/> [“Universal” Dune Tip: Rebuild Stuff, Sometimes] <https://seb.mondet.org/b/0009-dune-universe-hack.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: 39166 bytes --]
[-- Attachment #1: Type: text/plain, Size: 20085 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 08 to 15, 2020. Table of Contents ───────────────── MirageOS 3.10 released Exception vs Result Release: scikit-learn, Numpy, Scipy for OCaml, 0.3.1 OCaml 4.10.2 BAP 2.2.0 Release Liquidshop 1.0, Jan. 17th and 18th, 2021 Opium 0.20.0 Set up OCaml 1.1.5 Other OCaml News Old CWN MirageOS 3.10 released ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-mirageos-3-10-released/6941/1> Hannes Mehnert announced ──────────────────────── we're pleased to announce MirageOS 3.10: IPv6 and dual (IPv4 and IPv6) stack support <https://github.com/mirage/mirage/pull/1187> <https://github.com/mirage/mirage/issues/1190> Since a long time, IPv6 code was around in our TCP/IP stack (thanks to @nojb who developed it in 2014). Some months ago, @hannesm and @MagnusS got excited to use it. After we managed to fix some bugs and add some test cases, and writing more code to setup IPv6-only and dual stacks, we are eager to share this support for MirageOS in a released version. We expect there to be bugs lingering around, but duplicate address detection (neighbour solicitation and advertisements) has been implemented, and (unless "–accept-router-advertisement=false") router advertisements are decoded and used to configure the IPv6 part of the stack. Configuring a static IPv6 address is also possible (with "–ipv6=2001::42/64"). While at it, we unified the boot arguments between the different targets: namely, on Unix (when using the socket stack), you can now pass "–ipv4=127.0.0.1/24" to the same effect as the direct stack: only listen on 127.0.0.1 (the subnet mask is ignored for the Unix socket stack). A dual stack unikernel has "–ipv4-only=BOOL" and "–ipv6-only=BOOL" parameters, so a unikernel binary could support both Internet Protocol versions, while the operator can decide which protocol version to use. I.e. now there are both development-time (stackv4 vs stackv6 vs stackv4v6) choices, as well as the run-time choice (via boot parameter). I'm keen to remove the stackv4 & stackv6 in future versions, and always develop with dual stack (leaving it to configuration & startup time to decide whether to enable ipv4 and ipv6). Please also note that the default IPv4 network configuration no longer uses 10.0.0.1 as default gateway (since there was no way to unset the default gateway <https://github.com/mirage/mirage/issues/1147>). For unikernel developers, there are some API changes in the Mirage module • New "v4v6" types for IP protocols and stacks • The ipv6_config record was adjusted in the same fashion as the ipv4_config type: it is now a record of a network (V6.Prefix.t) and gateway (V6.t option) Some parts of the Mirage_key module were unified as well: • Arp.ip_address is available (for a dual Ipaddr.t) • Arg.ipv6_address replaces Arg.ipv6 (for an Ipaddr.V6.t) • Arg.ipv6 replaces Arg.ipv6_prefix (for a Ipaddr.V6.Prefix.t) • V6.network and V6.gateway are available, mirroring the V4 submodule If you're ready to experiment with the dual stack: below is a diff for our basic network example (from mirage-skeleton/device-usage/network) replacing IPv4 with a dual stack, and the tlstunnel unikernel commit <https://github.com/roburio/tlstunnel/commit/2cb3e5aa11fca4b48bb524f3c0dbb754a6c8739b> changed tlstunnel from IPv4 stack to dual stack. ┌──── │ diff --git a/device-usage/network/config.ml b/device-usage/network/config.ml │ index c425edb..eabc9d6 100644 │ --- a/device-usage/network/config.ml │ +++ b/device-usage/network/config.ml │ @@ -4,9 +4,9 @@ let port = │ let doc = Key.Arg.info ~doc:"The TCP port on which to listen for │ incoming connections." ["port"] in │ Key.(create "port" Arg.(opt int 8080 doc)) │ │ -let main = foreign ~keys:[Key.abstract port] "Unikernel.Main" (stackv4 │ @-> job) │ +let main = foreign ~keys:[Key.abstract port] "Unikernel.Main" │ (stackv4v6 @-> job) │ │ -let stack = generic_stackv4 default_network │ +let stack = generic_stackv4v6 default_network │ │ let () = │ register "network" [ │ diff --git a/device-usage/network/unikernel.ml │ b/device-usage/network/unikernel.ml │ index 5d29111..1bf1228 100644 │ --- a/device-usage/network/unikernel.ml │ +++ b/device-usage/network/unikernel.ml │ @@ -1,19 +1,19 @@ │ open Lwt.Infix │ │ -module Main (S: Mirage_stack.V4) = struct │ +module Main (S: Mirage_stack.V4V6) = struct │ │ let start s = │ let port = Key_gen.port () in │ - S.listen_tcpv4 s ~port (fun flow -> │ - let dst, dst_port = S.TCPV4.dst flow in │ + S.listen_tcp s ~port (fun flow -> │ + let dst, dst_port = S.TCP.dst flow in │ Logs.info (fun f -> f "new tcp connection from IP %s on port %d" │ - (Ipaddr.V4.to_string dst) dst_port); │ - S.TCPV4.read flow >>= function │ + (Ipaddr.to_string dst) dst_port); │ + S.TCP.read flow >>= function │ | Ok `Eof -> Logs.info (fun f -> f "Closing connection!"); │ Lwt.return_unit │ - | Error e -> Logs.warn (fun f -> f "Error reading data from │ established connection: %a" S.TCPV4.pp_error e); Lwt.return_unit │ + | Error e -> Logs.warn (fun f -> f "Error reading data from │ established connection: %a" S.TCP.pp_error e); Lwt.return_unit │ | Ok (`Data b) -> │ Logs.debug (fun f -> f "read: %d bytes:\n%s" (Cstruct.len b) │ (Cstruct.to_string b)); │ - S.TCPV4.close flow │ + S.TCP.close flow │ ); │ │ S.listen s └──── Other bug fixes include <https://github.com/mirage/mirage/issues/1188> (in <https://github.com/mirage/mirage/pull/1201>) and adapt to charrua 1.3.0 and arp 2.3.0 changes (<https://github.com/mirage/mirage/pull/1199>). Exception vs Result ═══════════════════ Archive: <https://discuss.ocaml.org/t/exception-vs-result/6931/18> Continuing this thread, Vladimir Keleshev announced ─────────────────────────────────────────────────── A bit late to the party, but here's an overview of error handling methods that I did a while ago: [Composable Error Handling in OCaml (keleshev.com)] It compares the following approaches: • Exceptions • Result type with strings for errors • Result type with custom variants for errors • Result type with polymorphic variants for errors [Composable Error Handling in OCaml (keleshev.com)] <https://keleshev.com/composable-error-handling-in-ocaml> Release: scikit-learn, Numpy, Scipy for OCaml, 0.3.1 ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-scikit-learn-numpy-scipy-for-ocaml-0-3-1/6942/1> Ronan Le Hy announced ───────────────────── I've just released an update of OCaml wrappers for scikit-learn: • documentation: <https://lehy.github.io/ocaml-sklearn/> • code: <https://github.com/lehy/ocaml-sklearn> • `opam install sklearn' These bindings also come with bindings for Numpy (`opam install np') and Scipy (`opam install scipy'). Scikit-learn is all of these things: • Simple and efficient tools for predictive data analysis • Accessible to everybody, and reusable in various contexts • Built on NumPy, SciPy, and matplotlib • Open source, commercially usable - BSD license Scikit-learn is robust, well-engineered and covers most basic machine learning use cases. As a professional data scientist I use it extensively from Python. I built these wrappers because I felt challenged by my friend @UnixJunkie's funny R wrappers. I don't depend personally on these packages and maintain/improve them without any guarantees. They have many unpolished corners. However, they have tests and I don't expect them to add too many bugs to scikit-learn. Contributions and bug reports are welcome (but be aware that the bindings are generated from a big hairy Python script). Many thanks to everybody involved in opam! OCaml 4.10.2 ════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-4-10-2/6945/1> octachron announced ─────────────────── The OCaml team has the pleasure of celebrating the birthday of Grace Hopper by announcing the release of OCaml version 4.10.2. This exceptional release makes OCaml 4.10 available on the new macOS/arm64 platform, and fixes some compatibility issues for the mingw64 and FreeBSD/amd64 platform. If OCaml 4.10.1 already works on your platform of choice, this release should be completely transparent to you (and can be safely ignored). Note that those fixes were backported from OCaml 4.12: further improvement to the support of the macOS/arm64 platform will happen on the 4.12 branch. The release is available as a set of OPAM switches, and as a source download here: <https://github.com/ocaml/ocaml/archive/4.10.2.tar.gz> <https://caml.inria.fr/pub/distrib/ocaml-4.10/> OCaml 4.10.2 ╌╌╌╌╌╌╌╌╌╌╌╌ • [9938], [9939]: Define __USE_MINGW_ANSI_STDIO=0 for the mingw-w64 ports to prevent their C99-compliant snprintf conflicting with ours. (David Allsopp, report by Michael Soegtrop, review by Xavier Leroy) [9938] <https://github.com/ocaml/ocaml/issues/9938> [9939] <https://github.com/ocaml/ocaml/issues/9939> ◊ Supported platforms: • [9699], [10026]: add support for iOS and macOS on ARM 64 bits Backported from OCaml 4.12.0 (GitHub user @EduardoRFS, review by Xavier Leroy, Nicolás Ojeda Bär and Anil Madhavapeddy, additional testing by Michael Schmidt) [9699] <https://github.com/ocaml/ocaml/issues/9699> [10026] <https://github.com/ocaml/ocaml/issues/10026> ◊ Code generation and optimization • [9752], [10026]: Revised handling of calling conventions for external C functions. Provide a more precise description of the types of unboxed arguments, so that the ARM64 iOS/macOS calling conventions can be honored. Backported from OCaml 4.12.0 (Xavier Leroy, review by Mark Shinwell and Github user @EduardoRFS) • [9969], [9981]: Added mergeable flag tqo ELF sections containing mergeable constants. Fixes compatibility with the integrated assembler in clang 11.0.0. Backported from OCaml 4.12.0 (Jacob Young, review by Nicolás Ojeda Bär) [9752] <https://github.com/ocaml/ocaml/issues/9752> [10026] <https://github.com/ocaml/ocaml/issues/10026> [9969] <https://github.com/ocaml/ocaml/issues/9969> [9981] <https://github.com/ocaml/ocaml/issues/9981> Anil Madhavapeddy ───────────────── There is also a [macos/arm64 binary of opam] available from the releases page for your convenience, and opam repository has been updated to understand the new tier-1 constraints imposed by macos/arm (i.e. the only working compilers there are 4.10.2 and 4.12.0~dev, and `opam init' will now do the right thing). There will be a number of packages that are broken due to the shift to `/opt/homebrew' from `/usr/local' for Homebrew/ARM (due to the need to keep them simultaneously installed on the same Mac), so please feel free to submit PRs to opam-repository to fix this stuff. We'll shortly have Mac (both Intel and ARM) testing up and running on opam-repository, so CI will catch up with reality once more, thanks to furious hacking by @patricoferris to extend our ocurrent-based CI infrastructure to support the unique vagaries of the Mac environment (notably, a total lack of native containers). We have it working locally, and are just upstreaming it now. [macos/arm64 binary of opam] <https://github.com/ocaml/opam/releases/tag/2.0.7> BAP 2.2.0 Release ═════════════════ Archive: <https://discuss.ocaml.org/t/ann-bap-2-2-0-release/6950/1> Ivan Gotovchits announced ───────────────────────── We are proud to announce the 2.2.0 release of the Carnegie Mellon University [Binary Analysis Platform]. BAP is the framework and toolkit for analyzing programs in their machine code representation. This update has a lot of [new features] despite that originally it was more as a maintenance version. Special thanks to @XVilka and [@Phosphorus15] for contributing Thumb/ThumbV2 lifter and radare2 integration. We would also like to thank [ForAllSecure] for open-sourcing and contributing to us their x86 floating-point lifter. The new version of BAP is also much more efficient and we now have a much better symbolization facility (so we're no longer really dependent on the presence of external tools). Another nice addition is a new REPL powered by [ocaml-linenoise], see the demo below. <https://asciinema.org/a/358996> [Binary Analysis Platform] <https://github.com/BinaryAnalysisPlatform/bap> [new features] <https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.2.0> [@Phosphorus15] <https://github.com/Phosphorus15> [ForAllSecure] <https://forallsecure.com/> [ocaml-linenoise] <https://github.com/ocaml-community/ocaml-linenoise> Liquidshop 1.0, Jan. 17th and 18th, 2021 ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-liquidshop-1-0-jan-17th-18th-2021/6951/1> Romain Beauxis announced ──────────────────────── We are happy to announce that we'll be holding Liquidshop 1.0 these coming Jan. 17th & 18th, our first ever (online) conference and workshops on liquidsoap and other related technologies and projects! Liquidsoap is a statically typed scripting language with specialized primitives and operators for creating media streams used for media processing, online streaming and a lot more. It is written in OCaml and has been maintained for over a decade now. We will have 3 different tracks for the event, namely: • Showcases: short presentations about a website / radio / art installation that you built using Liquidsoap or other related tools • Tech talks: in-depth presentation of a technology related to Liquidsoap and streaming in general • Workshops: user-centered freeform discussions about your project or issues around Liquidsoap and streaming If you're interested to participate, wether as an attendee or a presenter, make sure to register via our website at: <http://www.liquidsoap.info/liquidshop/> or directly via the form available at: <https://forms.gle/HdGNLz5qM3HVU1ub7> We are super excited for this event. We have already secured a couple of interesting speakers and we would love to get to know the community better, see what y'all are doing with liquidsoap and other releated projects, community radios, live video, weird installations, etc. and meet with everyone. Also, if you have any suggestion about the best technical solutions to organize such an event, we'd be happy to hear about them. Finally, if any of y'all have some specific topics to discuss and would like to learn more about liquidsoap, this will be a great place to connect! Opium 0.20.0 ════════════ Archive: <https://discuss.ocaml.org/t/ann-opium-0-20-0/6955/1> Thibaut Mattio announced ──────────────────────── I'm pleased to announce a new version of [Opium] web framework (0.20.0) is available on Opam. Here's the changelog: [Opium] <https://github.com/rgrinberg/opium> Added ╌╌╌╌╌ • New `Auth' module to work with `Authorization' header ([#238]) • New `basic_auth' middleware to protect handlers with a `Basic' authentication method ([#238]) • New `Response.of_file' API for conveniently creating a response of a file ([#244]) • Add a package `opium-graphql' to easily create GraphQL server with Opium ([#235]) • Add a function `App.run_multicore' that uses pre-forking and spawns multiple processes that will handle incoming requests ([#239]) [#238] <https://github.com/rgrinberg/opium/pull/238> [#244] <https://github.com/rgrinberg/opium/pull/244> [#235] <https://github.com/rgrinberg/opium/pull/235> [#239] <https://github.com/rgrinberg/opium/pull/239> Fixed ╌╌╌╌╌ • Fix reading cookie values when multiple cookies are present in `Cookie' header ([#246]) Happy hacking :slight_smile: [#246] <https://github.com/rgrinberg/opium/pull/246> Set up OCaml 1.1.5 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-5/6971/1> Sora Morimoto announced ─────────────────────── This release reduces build time by up to 2 minutes by exporting modified `OPAMJOBS' environment variable. <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.5> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Memthol: exploring program profiling] • [Growing the Hardcaml toolset] • [ Editor Plugin for VSCode and Vim Officially Released!] • [Announcing Our Market Prediction Kaggle Competition] • [Every proof assistant: introducing homotopy.io – a proof assistant for geometrical higher category theory] [OCaml Planet] <http://ocaml.org/community/planet/> [Memthol: exploring program profiling] <https://www.ocamlpro.com/2020/12/01/memthol-exploring-program-profiling/> [Growing the Hardcaml toolset] <https://blog.janestreet.com/growing-the-hardcaml-toolset-index/> [ Editor Plugin for VSCode and Vim Officially Released!] <https://rescript-lang.org/blog/editor-support-release-1-0> [Announcing Our Market Prediction Kaggle Competition] <https://blog.janestreet.com/announcing-our-market-prediction-kaggle-competition-index/> [Every proof assistant: introducing homotopy.io – a proof assistant for geometrical higher category theory] <http://math.andrej.com/2020/11/24/homotopy-io/> 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: 36981 bytes --]
[-- Attachment #1: Type: text/plain, Size: 12455 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 15 to 22, 2020. Table of Contents ───────────────── ocaml-lsp-server 1.4.0 OCaml 4.12.0, third alpha release Lwt 5.4.0, Lwt_ppx 2.0.2, Lwt_react 1.1.4 releases Senior software engineer at Docent, France - Remote OK Old CWN ocaml-lsp-server 1.4.0 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-4-0/6996/1> Rudi Grinberg announced ─────────────────────── On behalf of the ocaml-lsp team, it is my pleasure to announce version 1.4.0. This release introduces support for [automatic signature help]. Signature help is not yet present in all possible contexts. We intend to improve to support as many relevant language constructs as possible in the future. Many thanks to @mnxn for implementing this feature. The full change log is replicated at the end of this post for your convenience. Happy Holidays! • Support cancellation notifications when possible. (#323) • Implement signature help request for functions (#324) • Server LSP requests & notifications concurrently. Requests that require merlin are still serialized. (#330) [automatic signature help] <https://code.visualstudio.com/api/language-extensions/programmatic-language-features#help-with-function-and-method-signatures> OCaml 4.12.0, third alpha release ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-third-alpha-release/6997/1> octachron announced ─────────────────── The release of OCaml 4.12.0 is approaching. We have released a third alpha version to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun. Beyond the usual bug fixes, this new alpha version contains two small API fixes for statmemprof and the Unix module. (Keen-eyed readers might notice a breaking change in the change log below but this concerns a corner case of a corner case of the type system that should not affect anyone.) The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.12.0~alpha3 │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can pick configuration options with ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~alpha3+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and afl enabled switch: ┌──── │ opam switch create 4.12.0~alpha3+flambda+afl │ --packages=ocaml-variants.4.12.0~alpha3+options,ocaml-option-flambda,ocaml-option-afl │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with "opam search ocaml-option". The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.12.0-alpha3.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~alpha3.tar.gz> If you want to test this version, it is advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various packages patched with fixes in the process of being upstreamed. Once the repository installed, these patched packages will take precedence over the non-patched version. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Changes from the second alpha: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • *additional fixes* [1128], [7503], [9036], [9722], +[10069]: EINTR-based signal handling. When a signal arrives, avoid running its OCaml handler in the middle of a blocking section. Instead, allow control to return quickly to a polling point where the signal handler can safely run, ensuring that • [9907]: Fix native toplevel on native Windows. (David Allsopp, review by Florian Angeletti) • [10056]: Memprof: ensure young_trigger is within the bounds of the minor heap in caml_memprof_renew_minor_sample (regression from [8684]) (David Allsopp, review by Guillaume Munch-Maccagnoni and Jacques-Henri Jourdan) • [10062]: set ARCH_INT64_PRINTF_FORMAT correctly for both modes of mingw-w64 (David Allsopp, review by Xavier Leroy) • [10025]: Track custom blocks (e.g. Bigarray) with Statmemprof (Stephen Dolan, review by Leo White, Gabriel Scherer and Jacques-Henri Jourdan) • [10070]: Fix Float.Array.blit when source and destination arrays coincide. (Nicolás Ojeda Bär, review by Alain Frisch and Xavier Leroy) • *additional fixes* [9869], +[10073]: Add Unix.SO_REUSEPORT (Yishuai Li, review by Xavier Leroy, amended by David Allsopp) • [9877]: manual, warn that multi-index indexing operators should be defined in conjunction of single-index ones. (Florian Angeletti, review by Hezekiah M. Carty, Gabriel Scherer, and Marcello Seri) • [10046]: Link all DLLs with -static-libgcc on mingw32 to prevent dependency on libgcc_s_sjlj-1.dll with mingw-w64 runtime 8.0.0 (previously this was only needed for dllunix.dll). (David Allsopp, report by Andreas Hauptmann, review by Xavier Leroy) • [9896]: Share the strings representing scopes, fixing some regression on .cmo/.cma sizes (Alain Frisch and Xavier Clerc, review by Gabriel Scherer) • [10044]: Always report the detected ARCH, MODEL and SYSTEM, even for bytecode- only builds (fixes a "configuration regression" from 4.08 for the Windows builds) (David Allsopp, review by Xavier Leroy) • [10071]: Fix bug in tests/misc/weaklifetime.ml that was reported in [10055] (Damien Doligez and Gabriel Scherer, report by David Allsopp) • *breaking change* [8907], [9878]: `Typemod.normalize_signature' uses wrong environment Does not treat submodules differently when normalizing conjunctive types in polymorphic variants. This may break code that expose conjunctive types in inferred interface. (Jacques Garrigue, report and review by Leo White) • [9739], [9747]: Avoid calling type variables, types that are not variables in recursive occurence error messages (for instance, "Type variable int occurs inside int list") (Florian Angeletti, report by Stephen Dolan, review by Armaël Guéneau) • [10048]: Fix bug with generalized local opens. (Leo White, review by Thomas Refis) [1128] <https://github.com/ocaml/ocaml/issues/1128> [7503] <https://github.com/ocaml/ocaml/issues/7503> [9036] <https://github.com/ocaml/ocaml/issues/9036> [9722] <https://github.com/ocaml/ocaml/issues/9722> [10069] <https://github.com/ocaml/ocaml/issues/10069> [9907] <https://github.com/ocaml/ocaml/issues/9907> [10056] <https://github.com/ocaml/ocaml/issues/10056> [8684] <https://github.com/ocaml/ocaml/issues/8684> [10062] <https://github.com/ocaml/ocaml/issues/10062> [10025] <https://github.com/ocaml/ocaml/issues/10025> [10070] <https://github.com/ocaml/ocaml/issues/10070> [9869] <https://github.com/ocaml/ocaml/issues/9869> [10073] <https://github.com/ocaml/ocaml/issues/10073> [9877] <https://github.com/ocaml/ocaml/issues/9877> [10046] <https://github.com/ocaml/ocaml/issues/10046> [9896] <https://github.com/ocaml/ocaml/issues/9896> [10044] <https://github.com/ocaml/ocaml/issues/10044> [10071] <https://github.com/ocaml/ocaml/issues/10071> [10055] <https://github.com/ocaml/ocaml/issues/10055> [8907] <https://github.com/ocaml/ocaml/issues/8907> [9878] <https://github.com/ocaml/ocaml/issues/9878> [9739] <https://github.com/ocaml/ocaml/issues/9739> [9747] <https://github.com/ocaml/ocaml/issues/9747> [10048] <https://github.com/ocaml/ocaml/issues/10048> Lwt 5.4.0, Lwt_ppx 2.0.2, Lwt_react 1.1.4 releases ══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-4-0-lwt-ppx-2-0-2-lwt-react-1-1-4-releases/7001/1> Raphaël Proust announced ──────────────────────── We are glad to announce the release of version 5.4.0 of Lwt, version 2.0.2 of Lwt_ppx, and version 1.1.4 of Lwt_react. <https://github.com/ocsigen/lwt/releases/tag/5.4.0> It can be installed from opam as usual: ┌──── │ opam update │ opam upgrade lwt lwt_ppx lwt_react └──── OCaml 4.12 compatibility ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ With this release, Lwt is now compatible with OCaml 4.12. Thanks @kit-ty-kate for the contribution towards this support. Thanks as well to all the other contributors for all the other improvements that made it into this release. Check-out the release's changelog (link above) for a full list of bugfixes and additions. Maintainers' notes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ As per [a previous announce] I am a co-maintainer of Lwt. With this release I'm taking on a more and more central role in the maintenance effort. Whilst I've received a lot of help getting this release together, I'm most likely the one responsible for any issues in the process. I'd like to thank @antron who is as stellar with maintenance of the project as he is with guiding me through the learning process. I'd also like to thank the opam-repository team who stepped up very quickly to fix some CI-related build-issues. And I'd like to thank my employer, [Nomadic Labs], who agreed to make Lwt maintenance part of my day job. I'm looking forward to all your bug reports, pull requests, comments, ideas, questions, remarks, as well as any sort of feedback. Don't hesitate to get in touch! [a previous announce] <https://discuss.ocaml.org/t/announcing-a-new-maintainer-for-lwt/6192> [Nomadic Labs] <https://nomadic-labs.com/> Senior software engineer at Docent, France - Remote OK ══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/senior-software-engineer-at-docent-france-remote-ok/7002/1> Thibaut Mattio announced ──────────────────────── Docent, a company I'm working with, is recruiting an OCaml developer. You can see the job post [here] The team and project are really nice, I would definitely recommend it! I've built the current version of the backend, so don't hesitate to reach out (thibaut.mattio@gmail.com) if you have any questions on the tech (or other). [here] <https://www.notion.so/docentart/OCaml-Developer-bc047ff6c80b448e814943f7116fa14b> 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: 24451 bytes --]
[-- Attachment #1: Type: text/plain, Size: 9463 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 22 to 29, 2020. Table of Contents ───────────────── ppx_deriving_yaml 0.1.0 A Heroku buildpack for OCaml opam-dune-lint - keep opam and dune dependencies in sync Scirep, a utility for literate programming Camel Calendar for 2021 Old CWN ppx_deriving_yaml 0.1.0 ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ppx-deriving-yaml-0-1-0/7007/1> Patrick Ferris announced ──────────────────────── I'm proud to announce the first release (and my first release) of [ppx_deriving_yaml]. If you are familiar with the excellent [ppx_deriving_yojson] then this library should come as no surprise. In fact it helped me a lot in writing this ppx, so thank you to its creators/maintainers. [ppx_deriving_yaml] <https://github.com/patricoferris/ppx_deriving_yaml> [ppx_deriving_yojson] <https://github.com/ocaml-ppx/ppx_deriving_yojson> Installation ╌╌╌╌╌╌╌╌╌╌╌╌ ┌──── │ $ opam update │ $ opam install ppx_deriving_yaml └──── Usage ╌╌╌╌╌ Ppx_deriving_yaml converts your OCaml types to the "basic" [OCaml Yaml value type] (the one that is currently compatible with ezjsonm). So for example you can have: ┌──── │ type t = { title: string; authors: string list } [@@deriving yaml] │ │ let () = │ let v = { title = "Yaml PPX!"; authors = [ "Patrick Ferris" ] } in │ let yaml = to_yaml v in │ Yaml.pp Format.std_formatter yaml; │ match of_yaml yaml with │ | Ok t -> Format.print_string t.title │ | Error (`Msg m) -> failwith m └──── The ppx generates two functions: ┌──── │ val of_yaml : Yaml.value -> t Yaml.res │ val to_yaml : t -> Yaml.value └──── And when built with this dune file: ┌──── │ (executable │ (name main) │ (libraries yaml) │ (preprocess │ (pps ppx_deriving_yaml))) └──── The following output is generated: ┌──── │ title: Yaml PPX! │ authors: │ - Patrick Ferris │ Yaml PPX! └──── The [README] contains some more information and the library is still a little rough around the edges, especially with error reporting, but I'm currently using it in a few places such as an "ocaml-ified" [github actions] library (ppx_deriving_yaml's [test workflow] was automatically generated with it :sparkles:). This is a nice example of how it can be used in a fairly straightforward way to generate OCaml versions of the many projects that use Yaml for configuration files. Happy yaml-ing :) [OCaml Yaml value type] <https://github.com/avsm/ocaml-yaml/blob/6de8fa6926d391334b945754619a64857d352e5d/lib/types.ml#L44> [README] <https://github.com/patricoferris/ppx_deriving_yaml#implementation-details> [github actions] <https://github.com/patricoferris/opam-github-workflow> [test workflow] <https://github.com/patricoferris/ppx_deriving_yaml/blob/main/.github/workflows/test.yml> A Heroku buildpack for OCaml ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-a-heroku-buildpack-for-ocaml/7012/1> roddy announced ─────────────── I wrote [a Heroku buildpack] for OCaml web apps that use opam/dune. [a Heroku buildpack] <https://github.com/roddyyaga/heroku-buildpack-ocaml> opam-dune-lint - keep opam and dune dependencies in sync ════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-dune-lint-keep-opam-and-dune-dependencies-in-sync/7014/1> Thomas Leonard announced ──────────────────────── We're pleased to announce the first release of [opam-dune-lint]. This little tool checks that every ocamlfind dependency listed in your `dune' files has the corresponding opam package listed as a dependency in your `*.opam' file(s). e.g. ┌──── │ $ cd charrua │ $ opam dune-lint │ charrua-client.opam: changes needed: │ "tcpip" {with-test & >= 6.0.0} [from test/client, test/client/lwt] │ charrua-server.opam: changes needed: │ "ppx_cstruct" {with-test & >= 6.0.0} [from (ppx), test] │ "tcpip" {with-test & >= 6.0.0} [from test] │ charrua-unix.opam: changes needed: │ "cstruct-lwt" {>= 6.0.0} [from unix] │ "ipaddr" {>= 5.0.1} [from unix] │ "tcpip" {>= 6.0.0} [from unix] │ charrua.opam: OK │ Note: version numbers are just suggestions based on the currently installed version. │ Write changes? [y] y │ Wrote "./charrua-client.opam" │ Wrote "./charrua-server.opam" │ Wrote "./charrua-unix.opam" └──── If your project generates the opam files from `dune-project', then it will update your `dune-project' instead. It can also be useful to run this in CI. It will exit with a non-zero exit status if anything needs to be changed. [ocaml-ci] runs this automatically as part of the "lint-opam" check. [opam-dune-lint] <https://github.com/ocurrent/opam-dune-lint> [ocaml-ci] <https://ci.ocamllabs.io/> Scirep, a utility for literate programming ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/scirep-a-utility-for-literate-programming/7016/1> Philippe announced ────────────────── I wrote a utility called [scirep] to render a markdown file with OCaml code blocks as an HTML document, which provides some support for graphics. Here are some examples of generated documents: [one based on vg], and [another using owl-plplot]. It can also be used downstream of [mdx] as a markdown-to-html converter that detects pictures in the toplevel's standard output and renders them in the final document. It is really a hack, and it is poorly documented, but I'm advertising it in case it might be useful to others. [scirep] <https://github.com/pveber/scirep> [one based on vg] <http://pveber.github.io/scirep/fold.html> [another using owl-plplot] <http://pveber.github.io/scirep/damped.html> [mdx] <https://github.com/realworldocaml/mdx> Camel Calendar for 2021 ═══════════════════════ Archive: <https://discuss.ocaml.org/t/camel-calendar-for-2021/7020/1> Florent Monnier announced ───────────────────────── I would like to share with you a [camel calendar for 2021 in pdf] with the nice theme from ocaml dot org. It was generated from an ocaml script that you can find in this repo: [svg calendar generator]. Several scripts are available, you can find some results on this [web page]. At the beginning of 2020 I was searching for a free software to generate calendars in SVG that I could customise for my own use, but I was unable to install the Perl script that exists (it has a lot of dependencies and the error message when I try to install it didn't help us to find what's wrong with it). This explains the design of these scripts, that are made to work without any dependencies and without any compilation. There's code duplication, but every script only need the ocaml interpreter to be run, so most people comfortable with the command line should be able to use it. (I also tried to sell some [on Etsy] but didn't sold a single one.) By default 12 languages are included in every script, but you can generate the calendars for more than 200 languages if you use [these dates locales] that come from the CLDR repository. You can also switch monday first or sunday first. These generators are provided under Zlib license. I hope some will enjoy! [camel calendar for 2021 in pdf] <http://decapode314.free.fr/cal/cal-camel/cal-camel-2021-en.pdf> [svg calendar generator] <https://github.com/fccm/ocaml-cal-svg> [web page] <http://decapode314.free.fr/cal/> [on Etsy] <https://www.etsy.com/fr/shop/Decapode> [these dates locales] <https://github.com/fccm/DateLocale-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: 21680 bytes --]
[-- Attachment #1: Type: text/plain, Size: 14635 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 29, 2020 to January 05, 2021. Table of Contents ───────────────── First release of Feat OCluster and OBuilder Plotting 3D vectors Marshal determinism and stability It there a tutorial for `js_of_ocaml' with simple graphics? Interesting OCaml exercises from François Pottier available online Old CWN First release of Feat ═════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-feat/7033/1> François Pottier announced ────────────────────────── A brief note to announce the first release of Feat: ┌──── │ opam update │ opam install feat └──── Feat is a library that offers support for counting, enumerating, and sampling objects of a certain kind, such as (say) the inhabitants of an algebraic data type. Feat was inspired by the paper "Feat: Functional Enumeration of Algebraic Types" by Jonas Duregård, Patrik Jansson and Meng Wang (2012). More details can be found here: <https://gitlab.inria.fr/fpottier/feat/> OCluster and OBuilder ═════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocluster-and-obuilder/7035/1> Thomas Leonard announced ──────────────────────── I'm pleased to announce the first release of [OCluster]. A user can submit a build job (either a Dockerfile or an OBuilder spec) to the scheduler, which then runs the build on a worker machine, streaming the logs back to the client. This is the build scheduler / cluster manager that we use for e.g. [opam-repo-ci] (which you may have seen in action if you submitted a package to opam-repository recently). See [ocurrent/overview] for a quick overview of the various other CI services using it too. To install and run the scheduler use e.g. ┌──── │ opam depext -i ocluster │ mkdir capnp-secrets │ ocluster-scheduler \ │ --capnp-secret-key-file=./capnp-secrets/key.pem \ │ --capnp-listen-address=tcp:0.0.0.0:9000 \ │ --capnp-public-address=tcp:127.0.0.1:9000 \ │ --state-dir=/var/lib/ocluster-scheduler \ │ --pools=linux-arm32,linux-x86_64 └──── It will generate `key.pem' on the first run, as well as various capability files granting access for workers and clients. You then copy each generated pool capability (e.g. `pool-linux-x86_64.cap') to each machine you want in that pool, and run `ocluster-worker pool-linux-x86_64.cap' to start the worker agent. See the [README] for full details. [OBuilder] is an alternative to `docker build'. The main differences are that it takes a spec in S-expression format, which is easier to generate than a Dockerfile, handles concurrent builds reliably, and keeps copies of the logs so that you still see the output even if someone else performed the same build step earlier and the result is therefore taken from the cache. It currently supports ZFS and Btrfs for storage (it needs cheap snapshots) and `runc' for sandboxing builds. [macos support] is under development, but not yet upstreamed. It should be fairly easy to add support for any platform that has some form of secure chroot. OCluster supports monitoring with Prometheus, so you can see what the cluster is doing: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/d/d5ff5aaa0259d7b59445b156e6b642a421040b64_2_920x750.png> [OCluster] <https://github.com/ocurrent/ocluster> [opam-repo-ci] <https://github.com/ocurrent/opam-repo-ci> [ocurrent/overview] <https://github.com/ocurrent/overview> [README] <https://github.com/ocurrent/ocluster/blob/master/README.md> [OBuilder] <https://github.com/ocurrent/obuilder> [macos support] <https://github.com/ocurrent/obuilder/issues/57> Plotting 3D vectors ═══════════════════ Archive: <https://discuss.ocaml.org/t/plotting-3d-vectors/7038/1> Andreas Poisel asked ──────────────────── I'm doing linear algebra with Owl. Owl-plplot works great for visualizing 2D vectors, but it doesn't seem to capable of plotting 3D vectors. I took a (fast) look at vanilla [Plplot], [Oplot], and the [GNUplot bindings], but I didn't find a simple way to plot 3D vectors. I don't need high quality plots, 3D surfaces, a lot of control or fancy features, just a coordinate system and some function to draw geometric primitives (points, lines, circles, etc.). Did I miss anything or do I have to build this myself with the good old Graphics module? [Plplot] <http://plplot.org/> [Oplot] <https://github.com/sanette/oplot> [GNUplot bindings] <https://github.com/c-cube/ocaml-gnuplot> Marshall Abrams replied ─────────────────────── What kind of vector representation do you want? Just lines/arrows in 3D? That's just a curve in 3D, so it should be possible with Owl and plplot, at least. Looks like it should be easy with oplot, too (but I haven't used oplot). There are some 3D Owl plplot examples, with source code, on these pages: <https://ocaml.xyz/book/visualisation.html> <https://github.com/owlbarn/owl/wiki/Tutorial:-How-to-Plot-in-Owl%3F> <https://github.com/owlbarn/owl/wiki/Plot-Gallery> I don't know whether it will be easy to adapt them to your needs. I wrote the last example on the last page above. It's a plot of a series 2D curves in 3D. Maybe some of the techniques can be adapted to your needs. (The code is a few years old. I'm not sure whether it works with the current version of Owl.) (If you end up having to use low-level bindings to plplot, oplot, etc. from Owl, you might consider contributing a wrapper module that makes it easy to do the kind of plot you want.) Andreas Poisel then said ──────────────────────── Thank you for your answer. I'd just like to draw 3D vectors in a cartesian coordinate system. A plot should look similar to this: <https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/3D_Vector.svg/800px-3D_Vector.svg.png> I wouldn't even need arrows, simple lines would be ok. Maybe there is a way to use one of the 3D functions (`Plot.surf', `Plot.mesh', `Plot.contour'), but I can't figure it out. Hezekiah Carty replied ────────────────────── It's been a while since I worked with plplot but what you showed should be possible. The [plline3] function allows you to plot line segments in 3d space. The function is setup to take multiple segments in a single call. For a single segment each array would hold a single value. Colors can be set between draw calls. [plline3] <http://plplot.org/docbook-manual/plplot-html-5.15.0/plline3.html> sanette also replied ──────────────────── in oplot, there is the Curve3d object that should do it, <https://sanette.github.io/oplot/oplot/Oplot/Plt/index.html#type-plot_object.Curve3d> although it is quite rudimentary Marshal determinism and stability ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/marshal-determinism-and-stability/7041/25> Deep in this thread, Bikal Lem mentioned and Raphaël Proust described ───────────────────────────────────────────────────────────────────── [Binary module of data-encoding] Quick notes about this approach: • It is used extensively in the Tezos codebase. For data exchange (in the p2p layer), for data at rest (configuration files), and for a mix of the two (serialisation of economic protocol data which is both exchanged by peers and stored on disk). • It is flexible in that you have great control over the representation of data and the serialisation/deserialisation procedure. There is a medium-term plan to allow even more control. For now you can decide, say, if 8 booleans are represented as one byte, 8 bytes, or 8 words (or something else altogether) (see code below). • Some of the responsibility for correctness rests upon your shoulders as a user. E.g., when you encode a tuple, the left element must have either a fixed length (e.g., be an int8, int32, etc., be a fixed-length string, or be a tuple of fixed-length values) or be prefixed by a length marker (which the library provides a combinator for). Most of the errors for this are raised when you declare the encoding and a few are raised when you use the encoding. I recommend writing some tests to check that your encodings accept the range of values that you are going to throw at them. • The library is well tested: there are tests using crowbar to check that encoding and decoding are actual inverse of each others. Let me know if you have more questions. And in the meantime, here's two different encodings for a tuple of 8 booleans: ┌──── │ (* easy-encoding, produces 8 bytes *) │ let boolsas8bytes = │ tup8 bool bool bool bool bool bool bool bool │ │ (* very-compact encoding, produces 1 byte *) │ let boolsas1byte = │ conv │ (fun (b1, b2, b3, b4, b5, b6, b7, b8) -> │ let acc = 0 in │ let acc = if b1 then acc lor 0b10000000 else acc in │ let acc = if b2 then acc lor 0b01000000 else acc in │ let acc = if b3 then acc lor 0b00100000 else acc in │ … │ acc) │ (fun i -> │ let b1 = i land 0b10000000 <> 0 in │ let b1 = i land 0b01000000 <> 0 in │ let b1 = i land 0b00100000 <> 0 in │ … │ (b1, b2, b3, b4, b5, b6, b7, b8)) │ uint8 └──── In general, data-encoding is probably slower than marshal, but its strong points are: • it offers some type guarantees, • it gives you some control over the representation of the data, • it allows you to define representations that are easy to parse in other languages or in other versions of the same language, • it generates documentation about the data-representation. [Binary module of data-encoding] <https://gitlab.com/nomadic-labs/data-encoding> It there a tutorial for `js_of_ocaml' with simple graphics? ═══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/it-there-a-tutorial-for-js-of-ocaml-with-simple-graphics/4636/7> Deep in this thread, Phat Ky said ───────────────────────────────── This is a really, really late reply but this youtube video was very helpful to me … <https://www.youtube.com/watch?v=h_e5pPKI0K4> Interesting OCaml exercises from François Pottier available online ══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/interesting-ocaml-exercises-from-francois-pottier-available-online/7050/1> gasche announced ──────────────── The recent URL <https://ocaml-sf.org/learn-ocaml-public/#activity%3Dexercises> contains auto-graded OCaml exercises, in particular a bunch of advanced and fairly interesting exercices written by François Pottier, which I would recommend for anyone knowledgeable in OCaml and curious about algorithms and functional programming. (You have to scroll down to see those, the exercises at the top come from the OCaml MOOC.) See for example François' exercises on: • [Alpha-Beta Search], • [Parser combinators], • [Huffman Compression], • [Implementing backtracking with continuations], or • my personal favorite, [reimplementing the core of a pretty-printer]. Context: the exercise platform is [LearnOCaml], initially written by OCamlPro for the OCaml MOOC and maintaing by Yann Régis-Gianas (@yurug) on behalf of the [OCaml Software Foundation]. We (at the Foundation) are trying to assemble a corpus of nice OCaml exercises for teachers and people self-studying, and the nice exercises by François Pottier (@fpottier) were written as part of this initiative. [Alpha-Beta Search] <https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/alpha_beta%26tab%3Dtext%26prelude%3Dshown> [Parser combinators] <https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/parser_combinators%26tab%3Dtext> [Huffman Compression] <https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/huffman%26tab%3Dtext%26prelude%3Dshown> [Implementing backtracking with continuations] <https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/nondet_monad_cont%26tab%3Dtext%26prelude%3Dshown> [reimplementing the core of a pretty-printer] <https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/pprint%26tab%3Dtext%26prelude%3Dshown> [LearnOCaml] <https://github.com/ocaml-sf/learn-ocaml> [OCaml Software Foundation] <http://ocaml-sf.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: 29747 bytes --]
[-- Attachment #1: Type: text/plain, Size: 19040 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 05 to 12, 2021. Table of Contents ───────────────── Marshal determinism and stability Sedlex + Menhir parser for both tty and file parsing First release of awa-ssh Introducing Feather: A lightweight shell-scripting library for OCaml postdoc researcher and research engineer positions for CHERI and Arm verification First ocb (OCaml Badgen) release Release of OCaml-Git v3.0 and co Other OCaml News Old CWN Marshal determinism and stability ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/marshal-determinism-and-stability/7041/28> Continuing this thread, David Allsopp said ────────────────────────────────────────── A couple of notes on `Marshal', which I don't think have been covered • Although the guarantee is only between identical versions of OCaml, the implementation actually goes to considerable lengths to maintain backwards compatibility (so a value _written_ by older OCaml remains _readable_ in newer OCaml). Our own testsuite, for example, indirectly [includes a test which unmarshals a 3.12.1 value]. I don't know exactly how far back the support goes. • As it happens, the change which affected Unison in 4.08 was the first breaking change to Marshal since either 4.00 or 4.01. The fact that it doesn't break often (and that the two code paths - at least at present - are small) meant I have suggested a few months back that we could in future add an additional flag in the style of `Compat_32' to allow values to be written in a way which should be readable on older versions of OCaml. Indeed, it's small enough that flags could be added for the changes in 4.08 ([PR#1683]) and in 4.11 ([PR#8791]). • Neither point undermines using alternative formats either for network serialisation or persistent storage, for the many reasons discussed above! [includes a test which unmarshals a 3.12.1 value] <https://github.com/ocaml/ocaml/blob/trunk/testsuite/tests/lib-hashtbl/compatibility.ml> [PR#1683] <https://github.com/ocaml/ocaml/pull/1683> [PR#8791] <https://github.com/ocaml/ocaml/pull/8791> Sedlex + Menhir parser for both tty and file parsing ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/sedlex-menhir-parser-for-both-tty-and-file-parsing/7055/1> Bernard Sufrin announced ──────────────────────── I am a great fan of Menhir, and have used it in several private language projects, using the ulexing scanner generator to provide Unicode-capable scanners. Alarmed by the obsolescence of ulexing, and needing a utf8-capable scanner in a hurry I decided to (teach myself to) use Sedlex. On the whole the experience was very satisfactory, and I found it straightforward to produce a variant of the sedlexing library which supports buffers with variable chunk sizes, thereby enabling efficient lexing on channels connected to files as well as immediately responsive lexing on channels connected to terminals. I also wanted to teach myself how to use the error-reporting, incremental, interfaces to Menhir-generated parsers. In the hope that it might be useful to others facing the same learning task, or the problem of adapting Sedlex for efficient interactive use, I have placed the example mock-S-Expression parser that resulted from this excursion in: [Git Repository: github.com/sufrin/InteractiveSedlexMenhirExample] [Git Repository: github.com/sufrin/InteractiveSedlexMenhirExample] <https://github.com/sufrin/InteractiveSedlexMenhirExample> First release of awa-ssh ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh/7057/1> Hannes Mehnert announced ──────────────────────── I'm happy to announce that `awa-ssh' (<https://github.com/mirage/awa-ssh>) has just been merged into opam-repository. It is a pure OCaml implementation of the ssh (secure shell, <https://en.wikipedia.org/wiki/SSH_(Secure_Shell)>) protocol. This is the initial release, please report issues you encounter. It was initially developed by Christiano Haesbaert in 2016, and revived mid-2019 by myself and in 2020 it was migrated to the MirageOS organization on GitHub for further development and maintenance. Both client and server code are present in the library (pure code in the main awa package), though the awa-lwt package implements only a server, and the awa-mirage package implements only a client. Tests and examples are in the test subdirectory. The MirageOS client has been successfully used to clone git repositories (on private servers, on GitHub, etc.). It supports apart from RSA keys also ED25519 keys (and key exchanges). Introducing Feather: A lightweight shell-scripting library for OCaml ════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/introducing-feather-a-lightweight-shell-scripting-library-for-ocaml/7059/1> Charles announced ───────────────── I wrote a shell scripting library called [Feather]. I like idea of writing bash-like code quickly, later being able to intersperse OCaml to add more typeful components as needed. It's kind of like [Shexp] but without the monadic interface and with Async support. ([Feather_async]) There's a tutorial and some examples in the link above but here's a quick taste: ┌──── │ open Feather │ │ let lines = find "." ~name:"*.ml" │ |. tr "/" "\n" │ |. map_lines ~f:String.capitalize │ |. sort │ |. process "uniq" [ "-c" ] │ |. process "sort" [ "-n" ] │ |. tail 4 │ |> collect_lines │ in │ String.concat ~sep:", " lines |> print_endline └──── Let me know if you have any feedback! And feel free to file bug reports [here]. Hope it ends up being useful, entertaining, or both! [Feather] <https://hg.sr.ht/~etc/feather> [Shexp] <https://github.com/janestreet/shexp/> [Feather_async] <https://hg.sr.ht/~etc/feather_async> [here] <https://todo.sr.ht/~etc/feather> postdoc researcher and research engineer positions for CHERI and Arm verification ═════════════════════════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-01/msg00023.html> Peter Sewell announced ────────────────────── We are looking for postdoctoral researchers and postdoctoral or postgraduate research engineers to help develop semantics and verification to improve the foundations and security of mainstream computer systems, for CHERI and Arm system software verification, at the University of Cambridge. OCaml expertise to help develop verification tools will be especially welcome. Closing date 13 January 2021 - see the advert <http://www.jobs.cam.ac.uk/job/28012/>. First ocb (OCaml Badgen) release ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-ocb-ocaml-badgen-release/7073/1> zapashcanon announced ───────────────────── A few days ago, I released [ocb]. It's a library and a command-line tool to generate SVG badges. To get started quickly: ┌──── │ ocb --label Hello --color green --style flat --labelcolor white --status Goodbye └──── Will gives this result: [SVG example]. My first use case was [To.ml] where I'm using [bisect_ppx] to generate and deploy a [coverage report]. I wanted to display the coverage percentage in the README and tried existing tools but wasn't fully satisfied as they didn't work or were failing randomly. Now, [I'm generating the badge directly in a GitHub action]. The project was inspired by [badgen]. I still have to add support for icons and to improve the documentation but it's usable. [ocb] <https://github.com/ocamlpro/ocb> [SVG example] <https://raw.githubusercontent.com/OCamlPro/ocb/master/example/cli.svg> [To.ml] <https://github.com/ocaml-toml/To.ml> [bisect_ppx] <https://github.com/aantron/bisect_ppx> [coverage report] <https://ocaml-toml.github.io/To.ml/coverage/> [I'm generating the badge directly in a GitHub action] <https://github.com/ocaml-toml/To.ml/blob/6ac580848ad1d34ec3032da8672bbd9aca203cc4/.github/workflows/deploy.yml#L34> [badgen] <https://github.com/badgen/badgen> Release of OCaml-Git v3.0 and co ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-ocaml-git-v3-0-and-co/7076/1> Ulugbek Abdullaev announced ─────────────────────────── We, the [`ocaml-git'] team, are happy to announce a new major release of `ocaml-git v3.0' and related libraries. [`ocaml-git'] <https://github.com/mirage/ocaml-git> Release Notes ╌╌╌╌╌╌╌╌╌╌╌╌╌ OCaml-Git v3.0 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄ [*OCaml-Git*] is a library that implements `git' format and protocol implementation in pure OCaml. The library is used by libraries such as [`irmin'], a git-like distributed database, or [`pasteur'], a MirageOS unikernel-based snippet storage service. [*OCaml-Git*] <https://github.com/mirage/ocaml-git> [`irmin'] <https://github.com/mirage/irmin> [`pasteur'] <https://github.com/dinosaure/pasteur> Changes ┈┈┈┈┈┈┈ The main goal behind this major release was to get better compatibility with various platforms, including [~MirageOS~](mirage.io), 32-bit platforms, and `js_of_ocaml'. In order to achieve that, we broke down `ocaml-git' into several components, which are represented as sub-libraries. We will describe some of those components later in this post. Along with better support for various platforms, `ocaml-git 3.0' also comes with SSH support for `fetch/push' and various bug fixes. The rest of the changes are mostly internal and pave a way for interesting features such as a full-blown `git' [garbage collector] and wire protocol v2 ([announcment] and [spec]). *References:* • Full [changes list] • [PR] that introduced the major rewrite of `ocaml-git' — In the new version of `ocaml-git', we try to have better separation of concerns by breaking some of the `ocaml-git' components into sub-libraries, which do not contain `git'-specific logic and can be reused for other purposes. [garbage collector] <https://git-scm.com/docs/git-gc> [announcment] <https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html> [spec] <https://github.com/git/git/blob/master/Documentation/technical/protocol-v2.txt> [changes list] <https://github.com/mirage/ocaml-git/blob/master/CHANGES.md> [PR] <https://github.com/mirage/ocaml-git/pull/395> Carton ┄┄┄┄┄┄ Git uses [PACK files] to store old git objects such as commits and transfer objects over wire using git's wire protocols (`git-nss' library mentioned below implements [v1] of the protocol; [v2] implementation is in progress). [*Carton*] is a library to work with PACK files. The library does not contain git-specific code, so one can easily reuse the library and PACK format for non-git objects. One can see how `ocaml-git' uses `carton' for its purposes [here]. *References:* • [PR] that introduces `carton' [PACK files] <https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt> [v1] <https://github.com/git/git/blob/master/Documentation/technical/pack-protocol.txt> [v2] <https://github.com/git/git/blob/master/Documentation/technical/protocol-v2.txt> [*Carton*] <https://github.com/mirage/ocaml-git/tree/master/src/carton> [here] <https://github.com/mirage/ocaml-git/tree/master/src/carton-git> [PR] <https://github.com/mirage/ocaml-git/issues/375> Git-NSS (Not So Smart) ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ When one wants to synchronize with a remote repository using git, they need to use `git fetch/push'. Communication and synchronization/negotiation is defined by git *wire protocol*, which has two versions: older version 1 and newer leaner version 2. The protocols are defined for four wire transports: HTTP(S), SSH, and `git://' (TCP). [`Not-So-Smart'] library is a library that allows for such synchronization based on the git wire protocols but without git-specific code, meaning that files being fetched do not need to be git objects or that there is no assumptions on the "repository" that one is synchronizing with. So, as well as `carton', the library aims to be reusable for other purposes. This release features support for SSH using [awa-ssh] by @hannesm (see [the release]), support for [partial-clone] (of various `depth'), and memory consumption fixes for unikernels. *Note 1:* The library's name "Not so smart" is a play on the git's "smart" protocol, a part of wire protocol v1 over HTTP(S) transport. *Note 2:* only client side logic is implemented for wire protocols. The server-side is planned but not yet implemented. One can use `git' as the server for now. [`Not-So-Smart'] <https://github.com/mirage/ocaml-git/tree/master/src/not-so-smart> [awa-ssh] <https://github.com/mirage/awa-ssh> [the release] <https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh/7057> [partial-clone] <https://git-scm.com/docs/partial-clone> Mimic ┄┄┄┄┄ [*Mimic*] is a small reimplementation of [`conduit'], a library that helps to abstract over a transport protocol such as HTTP(S) or SSH. In other words, the code using `mimic' can deal not with different types that represent an HTTP or SSH connection, but just deal, e.g., read from or write to, with a `flow' value, which hides protocol-specific details under its hood. — There are several independent libraries that were upgraded along with `ocaml-git 3.0'. [*Mimic*] <https://github.com/mirage/ocaml-git/tree/master/src/mimic> [`conduit'] <https://github.com/mirage/ocaml-conduit> Duff v0.3 ┄┄┄┄┄┄┄┄┄ [*Duff*] is a library that implements git's [`libXdiff'] (`xdiff' algorithm) in OCaml. PACK files use a binary diff algorithm, `xdiff', to compress binary data. More on the project [page] and release [notes] for `ocaml-git 2.0'. [*Duff*] <https://github.com/mirage/duff> [`libXdiff'] <http://www.xmailserver.org/xdiff-lib.html> [page] <https://github.com/mirage/duff> [notes] <https://discuss.ocaml.org/t/ann-ocaml-git-2-0/2740> Changes ┈┈┈┈┈┈┈ This release fixes the support for 32-bit architecture platforms. Encore v0.7 ┄┄┄┄┄┄┄┄┄┄┄ [*Encore*] is a library that can create an encoder/decoder based on the format given. It also ensures isomorphism by construction. [*Encore*] <https://github.com/mirage/encore> Changes ┈┈┈┈┈┈┈ Extensive changes to the API. See the project page. Decompress v1.2.0 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ [*Decompress*] is an OCaml implementation of certain decompression algorithms such as `Zlib', `Gzip', etc. [*Decompress*] <https://github.com/mirage/decompress> Changes ┈┈┈┈┈┈┈ `ocaml-git 3.0' uses new version of `decompress' with extensive performance improvements documented in *Tarides's* blog [API changes] and [performance improvements]. We'd be happy to get your feedback or questions! :-) [API changes] <https://tarides.com/blog/2019-08-26-decompress-the-new-decompress-api> [performance improvements] <https://tarides.com/blog/2019-09-13-decompress-experiences-with-ocaml-optimization> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [How We Lost at The Delphi Oracle Challenge] • [Tarides sponsors the Oxbridge Women in Computer Science Conference 2020] • [Coq 8.12.2 is out] • [First release of MetAcsl plugin] • [Announcing MirageOS 3.10] • [ ReScript 8.4] • [Coq 8.13+beta1 is out] [OCaml Planet] <http://ocaml.org/community/planet/> [How We Lost at The Delphi Oracle Challenge] <https://seb.mondet.org/b/0010-delphi-challenge-post-vivum.html> [Tarides sponsors the Oxbridge Women in Computer Science Conference 2020] <https://tarides.com/blog/2020-12-14-tarides-sponsors-the-oxbridge-women-in-computer-science-conference-2020> [Coq 8.12.2 is out] <https://coq.inria.fr/news/coq-8-12-2-is-out.html> [First release of MetAcsl plugin] <https://frama-c.com/fc-plugins/metacsl.html> [Announcing MirageOS 3.10] <https://mirage.io/blog/announcing-mirage-310-release> [ ReScript 8.4] <https://rescript-lang.org/blog/bucklescript-release-8-4> [Coq 8.13+beta1 is out] <https://coq.inria.fr/news/coq-8-13beta1-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: 32830 bytes --]
[-- Attachment #1: Type: text/plain, Size: 22382 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 12 to 19, 2021. Table of Contents ───────────────── Irmin 2.3.0 Dune 2.8.0 lwt-canceler.0.3 Interesting OCaml Articles OCaml 4.12.0, first beta release OCaml for ARM MacOS Talk on OCaml Batteries at Houston Functional Programmers Other OCaml News Old CWN Irmin 2.3.0 ═══════════ Archive: <https://discuss.ocaml.org/t/ann-irmin-2-3-0/7084/1> Craig Ferguson announced ──────────────────────── I'm very happy to announce the release of the Irmin 2.3.0 family of packages, including: • [`irmin-pack.2.3.0'], a storage backend for Irmin designed for and used by Tezos. This release contains a host of performance improvements as well as offline CLI features such as integrity checking. It also contains a number of high-level design changes, which were discussed in a recent [Tarides blog post]. Finally, `irmin-pack.2.3.0' also contains a prototype of the [_layered_] `irmin-pack' store, which provides an [OverlayFS]-esque mode of operation for `irmin-pack' in which the causal history of the store can be chunked into independently-accessable substores. This feature will eventually be deployed in a [future version of Tezos]. • [`irmin-containers'], a collection of pre-defined mergeable data structures built using Irmin and compatible with any backend. These were originally provided by @kayceesrk as part of [`ezirmin'], and has since been modernised and upstreamed by Anirudh S. • `irmin-bench', a suite of benchmarks for Irmin for use with [`current-bench'], an experimental continuous benchmarking infrastructure for OCaml projects. Lots of work has been going on behind the scenes to make this a general benchmarking infrastructure for the Mirage ecosystem, including a recent [fancy UI overhaul] by new contributor @rizo. • [`repr'], an extraction of the `Irmin.Type' type representation library for use in other packages. This package contains a set of combinators for building run-time representations of types, along with various generic operations defined over those representations, including: equality, comparison, pretty-printing, JSON / binary codecs, etc. The API of this library is currently a work-in-progress, but we hope to use it more widely in the Mirage ecosystem soon. • [`semaphore-compat'], an extraction of the `Semaphore' library in OCaml 4.12, for libraries that want to maintain compatibility with earlier versions of OCaml. The full list of changes to Irmin can be found [here]. Many thanks to our open-source contributors and collaborators. Happy hacking! [`irmin-pack.2.3.0'] <https://www.youtube.com/watch?v=v1lfMUM332w> [Tarides blog post] <https://tarides.com/blog/2020-09-08-irmin-september-2020-update> [_layered_] <https://gist.github.com/icristescu/1afb7f9f862f8e989b8b6c195908e7d0> [OverlayFS] <https://en.wikipedia.org/wiki/OverlayFS> [future version of Tezos] <https://gitlab.com/tezos/tezos/-/merge_requests/2127> [`irmin-containers'] <https://mirage.github.io/irmin/irmin-containers/Irmin_containers/index.html> [`ezirmin'] <https://github.com/kayceesrk/ezirmin> [`current-bench'] <https://github.com/ocurrent/current-bench/> [fancy UI overhaul] <https://github.com/ocurrent/current-bench/pull/20> [`repr'] <https://github.com/mirage/repr> [`semaphore-compat'] <https://github.com/mirage/semaphore-compat> [here] <https://github.com/mirage/irmin/blob/master/CHANGES.md#230-2020-01-12> Dune 2.8.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-2-8-0/7090/1> Rudi Grinberg announced ─────────────────────── On behalf of the dune, I'm pleased to announce the release of dune 2.8.0. This release contains many bug fixes, performance improvements, and interesting new features. I'll point out two new features that I'm most excited about. First is the experimental `dune_site' extension that makes it possible to register and load plugins at runtime. This feature is quite involved, but we've documented it extensively [in the manual]. Another cool feature is that we've eliminated the need for .merlin files and all the caveats that came with them. Now, merlin talks to dune directly to get precise configuration for every module. Say goodbye to all those "approximate .merlin file" warnings! I encourage everyone to upgrade as soon as possible, as earlier versions are not compatible with OCaml 4.12. Happy Hacking. Full change log: [in the manual] <https://dune.readthedocs.io/en/stable/sites.html> 2.8.0 (13/01/2021) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • `dune rules' accepts aliases and other non-path rules (#4063, @mrmr1993) • Action `(diff reference test_result)' now accept `reference' to be absent and in that case consider that the reference is empty. Then running `dune promote' will create the reference file. (#3795, @bobot) • Ignore special files (BLK, CHR, FIFO, SOCKET), (#3570, fixes #3124, #3546, @ejgallego) • Experimental: Simplify loading of additional files (data or code) at runtime in programs by introducing specific installation sites. In particular it allow to define plugins to be installed in these sites. (#3104, #3794, fixes #1185, @bobot) • Move all temporary files created by dune to run actions to a single directory and make sure that actions executed by dune also use this directory by setting `TMPDIR' (or `TEMP' on Windows). (#3691, fixes #3422, @rgrinberg) • Fix bootstrap script with custom configuration. (#3757, fixes #3774, @marsam) • Add the `executable' field to `inline_tests' to customize the compilation flags of the test runner executable (#3747, fixes #3679, @lubegasimon) • Add `(enabled_if ...)' to `(copy_files ...)' (#3756, @nojb) • Make sure Dune cleans up the status line before exiting (#3767, fixes #3737, @alan-j-hu) • Add `{gitlab,bitbucket}' as options for defining project sources with `source' stanza `(source (<host> user/repo))' in the `dune-project' file. (#3813, @rgrinberg) • Fix generation of `META' and `dune-package' files when some targets (byte, native, dynlink) are disabled. Previously, dune would generate all archives for regardless of settings. (#3829, #4041, @rgrinberg) • Do not run ocamldep to for single module executables & libraries. The dependency graph for such artifacts is trivial (#3847, @rgrinberg) • Fix cram tests inside vendored directories not being interpreted correctly. (#3860, fixes #3843, @rgrinberg) • Add `package' field to private libraries. This allows such libraries to be installed and to be usable by other public libraries in the same project (#3655, fixes #1017, @rgrinberg) • Fix the `%{make}' variable on Windows by only checking for a `gmake' binary on UNIX-like systems as a unrelated `gmake' binary might exist on Windows. (#3853, @kit-ty-kate) • Fix `$ dune install' modifying the build directory. This made the build directory unusable when `$ sudo dune install' modified permissions. (fix #3857, @rgrinberg) • Fix handling of aliases given on the command line (using the `@' and `@@' syntax) so as to correctly handle relative paths. (#3874, fixes #3850, @nojb) • Allow link time code generation to be used in preprocessing executable. This makes it possible to use the build info module inside the preprocessor. (#3848, fix #3848, @rgrinberg) • Correctly call `git ls-tree' so unicode files are not quoted, this fixes problems with `dune subst' in the presence of unicode files. Fixes #3219 (#3879, @ejgallego) • `dune subst' now accepts common command-line arguments such as `--debug-backtraces' (#3878, @ejgallego) • `dune describe' now also includes information about executables in addition to that of libraries. (#3892, #3895, @nojb) • instrumentation backends can now receive arguments via `(instrumentation (backend <name> <args>))'. (#3906, #3932, @nojb) • Tweak auto-formatting of `dune' files to improve readability. (#3928, @nojb) • Add a switch argument to opam when context is not default. (#3951, @tmattio) • Avoid pager when running `$ git diff' (#3912, @AltGr) • Add `(root_module ..)' field to libraries & executables. This makes it possible to use library dependencies shadowed by local modules (#3825, @rgrinberg) • Allow `(formatting ...)' field in `(env ...)' stanza to set per-directory formatting specification. (#3942, @nojb) • [coq] In `coq.theory', `:standard' for the `flags' field now uses the flags set in `env' profile flags (#3931 , @ejgallego @rgrinberg) • [coq] Add `-q' flag to `:standard' `coqc' flags , fixes #3924, (#3931 , @ejgallego) • Add support for Coq's native compute compilation mode (@ejgallego, #3210) • Add a `SUFFIX' directive in `.merlin' files for each dialect with no preprocessing, to let merlin know of additional file extensions (#3977, @vouillon) • Stop promoting `.merlin' files. Write per-stanza Merlin configurations in binary form. Add a new subcommand `dune ocaml-merlin' that Merlin can use to query the configuration files. The `allow_approximate_merlin' option is now useless and deprecated. Dune now conflicts with `merlin < 3.4.0' and `ocaml-lsp-server < 1.3.0' (#3554, @voodoos) • Configurator: fix a bug introduced in 2.6.0 where the configurator V1 API doesn't work at all when used outside of dune. (#4046, @aalekseyev) • Fix `libexec' and `libexec-private' variables. In cross-compilation settings, they now point to the file in the host context. (#4058, fixes #4057, @TheLortex) • When running `$ dune subst', use project metadata as a fallback when package metadata is missing. We also generate a warning when `(name ..)' is missing in `dune-project' files to avoid failures in production builds. • Remove support for passing `-nodynlink' for executables. It was bypassed in most cases and not correct in other cases in particular on arm32. (#4085, fixes #4069, fixes #2527, @emillon) • Generate archive rules compatible with 4.12. Dune longer attempt to generate an archive file if it's unnecessary (#3973, fixes #3766, @rgrinberg) • Fix generated Merlin configurations when multiple preprocessors are defined for different modules in the same folder. (#4092, fixes #2596, #1212 and #3409, @voodoos) • Add the option `use_standard_c_and_cxx_flags' to `dune-project' that 1. disables the unconditional use of the `ocamlc_cflags' and `ocamlc_cppflags' from `ocamlc -config' in C compiler calls, these flags will be present in the `:standard' set instead; and 2. enables the detection of the C compiler family and populates the `:standard' set of flags with common default values when building CXX stubs. (#3875, #3802, fix #3718 and #3528, @voodoos) lwt-canceler.0.3 ════════════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-canceler-0-3/7092/1> Raphaël Proust announced ──────────────────────── On behalf of [Nomadic Labs], I'm happy to announce the release of Lwt-canceler version 0.3. Lwt-canceler is a small library to help programs written using Lwt to synchronise promises around resource clean-up. This library was developed as part of the [Tezos codebase] before being released. With this version, the code has matured significantly (including tests, documentation and some refactoring); the next release will probably be a version 1.0 at which point a more robust versioning scheme will be used. The documentation is available online: <https://nomadic-labs.gitlab.io/lwt-canceler/lwt-canceler/Lwt_canceler/index.html> The code is released under MIT License and hosted on Gitlab: <https://gitlab.com/nomadic-labs/lwt-canceler> The new version is available on opam: `opam install lwt-canceler' Happy hacking! [Nomadic Labs] <https://nomadic-labs.com/> [Tezos codebase] <https://gitlab.com/tezos/tezos> Interesting OCaml Articles ══════════════════════════ Archive: <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/90> Weng Shiwei announced ───────────────────── Let me share my new blog post on understanding `format6' with examples. <https://blog.tail.moe/2021/01/13/format6.html> It's almost my reading note for the paper Format Unraveled (on module Format) and experiments on utop. I tried not to be too verbose though. Weng Shiwei later said ────────────────────── Well, I made a sequel of `format6' post, *Understanding `format6' in OCaml by diagrams* <https://blog.tail.moe/2021/01/15/format6-diagram.html> This time I just use four examples with four diagrams e.g. it's the one for `Scanf.sscanf' <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/f/f18093391072f739d70c68c2ccf4be92441078c2_2_1034x432.png> p.s. It's a pity that I missed Gabriel's post [The 6 parameters of (’a, ’b, ’c, ’d, ’e, ’f) format6] after writing that one. [The 6 parameters of (’a, ’b, ’c, ’d, ’e, ’f) format6] <http://gallium.inria.fr/blog/format6/> OCaml 4.12.0, first beta release ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-first-beta-release/7099/1> octachron announced ─────────────────── The release of OCaml 4.12.0 is close. The set of new features has been stabilized, and core opam packages already work with this release. 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. Compared to the last alpha, this beta contains only three new bug fixes and one change to the standard library. The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.12.0~beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can pick configuration options with ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~beta1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and afl enabled switch: ┌──── │ opam switch create 4.12.0~beta1+flambda+afl │ --packages=ocaml-variants.4.12.0~beta1+options,ocaml-option-flambda,ocaml-option-afl │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with "opam search ocaml-option". The source code is available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.12.0-beta1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~beta1.tar.gz> If you want to test this version, you may want to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git This alpha repository contains various packages patched with fixes in the process of being upstreamed. Once the repository installed, these patched packages will take precedence over the non-patched version. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Changes from the third alpha release ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Postponed features ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [9533], [10105], [10127] : Added String.starts_with and String.ends_with. (Bernhard Schommer, review by Daniel Bünzli, Gabriel Scherer and Alain Frisch) [9533] <https://github.com/ocaml/ocaml/issues/9533> [10105] <https://github.com/ocaml/ocaml/issues/10105> [10127] <https://github.com/ocaml/ocaml/issues/10127> Additional bug fixes ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [9096], [10096]: fix a 4.11.0 performance regression in classes/objects declared within a function (Gabriel Scherer, review by Leo White, report by Sacha Ayoun) • [10106], [10112]: some expected-type explanations where forgotten after some let-bindings (Gabriel Scherer, review by Thomas Refis and Florian Angeletti, report by Daniil Baturin) • [9326], [10125]: Gc.set incorrectly handles the three `custom_*' fields, causing a performance regression (report by Emilio Jesús Gallego Arias, analysis and fix by Stephen Dolan, code by Xavier Leroy, review by Hugo Heuzard and Gabriel Scherer) [9096] <https://github.com/ocaml/ocaml/issues/9096> [10096] <https://github.com/ocaml/ocaml/issues/10096> [10106] <https://github.com/ocaml/ocaml/issues/10106> [10112] <https://github.com/ocaml/ocaml/issues/10112> [9326] <https://github.com/ocaml/ocaml/issues/9326> [10125] <https://github.com/ocaml/ocaml/issues/10125> OCaml for ARM MacOS ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-for-arm-macos/6019/23> Deep in this thread, Xavier Leroy said ────────────────────────────────────── It's quite easy to get up to speed using the precompiled OPAM binary for macOS/ARM64. • Download [opam-2.0.7-arm64-macos]. • Move it to some directory in your PATH, rename it to `opam', and make it executable. From a Terminal window: ┌──── │ mv ~/Downloads/opam-2.0.7-arm64-macos /usr/local/bin/opam │ chmod +x /usr/local/bin/opam └──── • Try to execute it: `opam init'. You will be blocked by the macOS security checks, as the binary is not signed. • Open Preferences / Security and Privacy. There should be a notice "opam was blocked because…" and an "Allow Anyway" button. Click on that button. • Try again to execute `opam init'. You will be blocked again, but now there is an "Open" button. Click on that button. `opam init' should run and install the OCaml 4.10.2 compiler. • From now on, you can run `opam' without being blocked. Use this freedom to `opam install' the packages you need. • Some packages that depend on external C libraries may fail to install because these C libraries are not available. Normally we would rely on Homebrew or MacPorts to provide these C libraries, but these package collections are still being ported to macOS/ARM64. As a reward for these minor inconveniences, you'll get excellent performance running OCaml software such as Coq. Single-core performance on a MacBook Air M1 is 20% better than the best x86 workstation I have access to. [opam-2.0.7-arm64-macos] <https://github.com/ocaml/opam/releases/download/2.0.7/opam-2.0.7-arm64-macos> Talk on OCaml Batteries at Houston Functional Programmers ═════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/talk-on-ocaml-batteries-at-houston-functional-programmers/7103/1> Claude Jager-Rubinson announced ─────────────────────────────── @UnixJunkie will be speaking (virtually, of course) on *OCaml Batteries Included* at Houston Functional Programmers, this coming Wednesday, Jan 20 at 7pm (U.S. Central time). His talk will cover Batteries' history, place within the OCaml ecosystem, and comparisons with OCaml's other alternative standard libraries. All are welcome to join us, even if you're not from Houston. Complete details and Zoom info are at [hfpug.org]. [hfpug.org] <https://hfpug.org> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Coq 8.13.0 is out] [OCaml Planet] <http://ocaml.org/community/planet/> [Coq 8.13.0 is out] <https://coq.inria.fr/news/coq-8-13-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: 36261 bytes --]
[-- Attachment #1: Type: text/plain, Size: 31437 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 19 to 26, 2021. Table of Contents ───────────────── How to get pleasant documentation for a library using Dune? Alt-Ergo 2.4.0 release First release of Art - Adaptive Radix Tree in OCaml perf demangling of OCaml symbols (and a short introduction to perf) Decimal 0.2.1 - arbitrary-precision decimal floating point Basic GitLab CI configuration OCaml Office Hours? json-data-encoding 0.9 VSCode OCaml Platform v1.6.0 release 0.3.0 of drom, the OCaml project creator Old CWN How to get pleasant documentation for a library using Dune? ═══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/how-to-get-pleasant-documentation-for-a-library-using-dune/7121/1> gasche announced ──────────────── I'm working to publish a small library using Dune. The documentation automatically generated by `dune build @doc' looks fairly unpleasant to me, as I don't see an easy way to explain what the library is about. I'm creating this topic in case I am missing something simple, and to get other people to share their library-documentation practices or examples. Problem description ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ For the sake of the example let's imagine that the library is called `Foo' and contains three modules `A', `B' and `C'. I'm using the standard dune approach of wrapped modules, so I get three compilation units `Foo.A', `Foo.B', `Foo.C'. Each module has a `.mli' file with documentation comments. When I run `dune build @doc', dune generates an `index.html' file with basically no content, pointing to a `foo/index.html' file with basically no content, pointing to a `foo/Foo/index.html' looking like this: Up – foo » Foo *Module `Foo'* `module A : sig ... end' `module B : sig ... end' `module C : sig ... end' It's easy to skip the first two pages, and use the third page as a landing page for the documentation of my library. However, this landing page is not very pleasant: 1. It should explain what the library is about. 2. It should briefly describe what each module does, so that users know which module they want to look at first. (Point 2 is especially important with "wrapped libraries", where it's not necessarily obvious which of the several modules is the main entry point with the important functions to look at first. In comparison, in a design where the "entry point" is in the `Foo' module, with `Foo.A' and `Foo.B' as more advanced submodules (or `Foo_A' and `Foo_B' in the old days) the user is guided to look at `Foo' first.) My problem is: what should I change in my Dune setup to be able to do this? I have read the [dune documentation on documentation], but I could not find an answer to this question. [dune documentation on documentation] <https://dune.readthedocs.io/en/stable/documentation.html> Rough ideas ╌╌╌╌╌╌╌╌╌╌╌ Roughly I see two ways to get what I want, that I have not tried yet: 1. I could write my own landing page for the library as a separate `doc.mld' file, use the `(documentation)' stanza to get it included in the built documentation, and use this as the entry point into my library. 2. In could write my own `foo.ml' module instead of using Dune's default wrapped-module scaffolding, inserting my own `module A = Foo__A' aliases, with documentation comments in the standard style. Then I suppose that `foo/Foo/index.html' would get this content in the way I expect. They feel a bit complex to me, and (2) involves the tedious work of redoing the wrapping logic myself. I guess that (1) is not so bad, and I would be inclined to do this if it was documented somewhere as the recommended approach. (Maybe there is some odoc option that would help solve this problem?) Examples from other people? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Do you have a library built using dune with nice documentation? If so, can you show the documentation and the corresponding sources (in particular dune setup)? Thibaut Mattio replied ────────────────────── I think the documentation of [Streaming] is a great example of the option 1 you describe. The corresponding Dune setup can be found [here] That's also the approach we took for [Opium's documentation], although the index page is certainly not as impressive as Streaming's. [Streaming] <https://odis-labs.github.io/streaming/streaming/index.html> [here] <https://github.com/odis-labs/streaming/blob/master/streaming/dune> [Opium's documentation] <https://rgrinberg.github.io/opium/opium/index.html> gasche then said ──────────────── Thanks! It looks like these systems rely on an undocumented feature of the `(documentation)' stanza (or odoc), which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. The opium documentation also [uses] the `{!modules: modulename ...}' markup directive, which is a way to include the module index within this manually-written landing page without having to duplicate the markup. Streaming¹ uses [inline html] instead to get a nicer-looking result, but it is too much effort. Maybe there is a better way, or the tools could be improved to make this easier. ¹: I'm ashamed to admit that I wasn't aware of this very nice library [Streaming], am I consuming the wrong sources of information on the OCaml ecosystem? Finally, the Opium documentation manifestly has a short synopsis for each module in its listing, which corresponds to my "It should briefly describe what each module does" requirement. I believe that this comes from the first line of the first documentation comment of the module. There are module-global documentation comments in the library I'm working on, but they do not include such first-line headers. Once I have the impression of understanding what is a good way to do this, I may try to contribute better documentation in `dune'. [uses] <https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74> [inline html] <https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68> [Streaming] <https://odis-labs.github.io/streaming/streaming/index.html> Gabriel Radanne replied ─────────────────────── It looks like these systems rely on an undocumented feature of the `(documentation)' stanza (or odoc), which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. I confirm this feature is here to stay, is the right one to customize your index page, and in the future will benefit from good support from odoc directly. The opium documentation also [uses] the `{!modules: modulename ...}' markup directive, which is a way to include the module index within this manually-written landing page without having to duplicate the markup. Streaming¹ uses [inline html] instead to get a nicer-looking result, but it is too much effort. Maybe there is a better way, or the tools could be improved to make this easier. I would strongly advise to use the `modules' markup directive, and to suggests output improvements on odoc's bug instead of hacking HTML together. We could absolutely add the synopsis of the module here, for instance. [uses] <https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74> [inline html] <https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68> Daniel Bünzli then said ─────────────────────── which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. This is also the correct way to customize the landing page of your package for `odig' generated doc sets, see [here] for more information. I confirm this feature is here to stay, is the right one to customize your index page, and in the future will benefit from good support from odoc directly. There's an open issue about that [here]. [here] <https://erratique.ch/software/odig/doc/packaging.html#odoc_api_and_manual> [here] <https://github.com/ocaml/odoc/issues/297> Alt-Ergo 2.4.0 release ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-alt-ergo-2-4-0-release/7134/1> OCamlPro announced ────────────────── We are pleased to announce a new release of Alt-Ergo! Alt-Ergo 2.4.0 is now available from [Alt-Ergo’s website]. An associated opam package will be published in the next few days. This release contains some major novelties: • Alt-Ergo supports incremental commands (push/pop) from the[ smt-lib] standard. • We switched command line parsing to use[ cmdliner]. You will need to use –<option name> instead of -<option name>. Some options have also been renamed, see the manpage or the documentation. • We improved the online documentation of your solver, available[ here]. This release also contains some minor novelties: • .mlw and .why extension are depreciated, the use of .ae extension is advised. • Add –input (resp –output) option to manually set the input (resp output) file format • Add –pretty-output option to add better debug formatting and to add colors • Add exponentiation operation, ** in native Alt-Ergo syntax. The operator is fully interpreted when applied to constants • Fix –steps-count and improve the way steps are counted (AdaCore contribution) • Add –instantiation-heuristic option that can enable lighter or heavier instantiation • Reduce the instantiation context (considered foralls / exists) in CDCL-Tableaux to better mimic the Tableaux-like SAT solver • Multiple bugfixes The full list of changes is available [here]. As usual, do not hesitate to report bugs, to ask questions, or to give your feedback! [Alt-Ergo’s website] <https://alt-ergo.ocamlpro.com/> [ smt-lib] <https://smtlib.cs.uiowa.edu/> [ cmdliner] <https://erratique.ch/software/cmdliner> [ here] <https://ocamlpro.github.io/alt-ergo/> [here] <https://ocamlpro.github.io/alt-ergo/About/changes.html> First release of Art - Adaptive Radix Tree in OCaml ═══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-art-adaptive-radix-tree-in-ocaml/7142/1> Calascibetta Romain announced ───────────────────────────── I'm glad to announce the first release of [`art'], an implementation of [the Adaptive Radix Tree] in OCaml. The goal of this library is to provide a data-structure such as `Map.S' (and keep the order) with performances of `Hashtbl.t'. [`art'] <https://github.com/dinosaure/art> [the Adaptive Radix Tree] <https://db.in.tum.de/~leis/papers/ART.pdf> Performances ╌╌╌╌╌╌╌╌╌╌╌╌ `art' uses [Bechamel] as a tool for micro-benchmarking and it compares performances about [insertion] and [lookup]. As you can see, about insertion, `art' is definitely more fast than `Hashtbl.t'. For the _lookup_ operation, we are slightly more fast than the `Hashtbl.t'. The main advantage comparing to `Hashtbl.t' is the ability to use `maximum~/~minimum' or to `iter' over the whole data-structure with a certain order. On details, benchmarks use a normal distribution of `strings' about their lengths. As a practical example where `art' will be better than `Hashtbl.t' is when you want to _index_ several words (such as email addresses). [Bechamel] <https://github.com/mirage/bechamel> [insertion] <https://dinosaure.github.io/art/bench/insert.html> [lookup] <https://dinosaure.github.io/art/bench/find.html> Tests ╌╌╌╌╌ Of course, the library provide [a fuzzer] and tests have a coverage of: 91.93 % [a fuzzer] <https://github.com/dinosaure/art/blob/master/fuzz/fuzz.ml> Read Optimized Write Exclusion - ROWEX ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Even if it's not a part of the package, the distribution comes with _lock-free_ implementation of `art': `rowex'. This implementation comes from [a research paper] about data-structure and atomic operations. ROWEX provides a _persistent_ implementation which manipulates a file to store the whole data-structure. The goal is to provide an _indexer_ free to be manipulated by several processes in parallel. Currently, the implementation of ROWEX in OCaml is not well-tested and it is no distributed. It does not take the advantage of [ocaml-multicore] (but it should) but outcomes are good and the development will be more focus on this part. So feel free to play with it a bit :+1:. [a research paper] <https://db.in.tum.de/~leis/papers/artsync.pdf> [ocaml-multicore] <https://github.com/ocaml-multicore/ocaml-multicore> perf demangling of OCaml symbols (and a short introduction to perf) ═══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-perf-demangling-of-ocaml-symbols-a-short-introduction-to-perf/7143/1> Fabian announced ──────────────── As a project sponsored by the [OCaml software foundation], I've worked on demangling OCaml symbols in [perf]. Some screenshots are below. The work is currently being upstreamed. In the meantime, it can be used as follows: ┌──── │ git clone --depth=1 https://github.com/copy/linux.git │ # or: │ # wget https://github.com/copy/linux/archive/master.tar.gz && tar xfv master.tar.gz │ cd linux/tools/perf │ make │ alias perf=$PWD/perf │ # or copy perf to somewhere in your PATH └──── Your distribution's version of perf will also work for the examples below, but will have less readable symbols :-) [OCaml software foundation] <https://ocaml-sf.org/> [perf] <https://perf.wiki.kernel.org/index.php/Main_Page> Short intruction to perf ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Perf is a Linux-only sampling profiler (and more), which can be used to analyse the performance profile of OCaml and other executables. When compiling with ocamlopt, add `-g' to include debug information in the executable. dune does this automatically, even in the release profile. To start a program and record its profile: ┌──── │ perf record --call-graph dwarf program.exe └──── Or record a running program: ┌──── │ perf record --call-graph dwarf -p `pidof program.exe` └──── Then, view a profile using: ┌──── │ perf report # top-down │ perf report --no-children # bottom-up └──── Within the report view, the following keybindings are useful: • `+': open/close one callchain level • `e': open/close entire callchain • `t': Toggle beween current thread and all threads (e.g., only `dune', `ocamlopt', etc.) Or generate a flamegraph: ┌──── │ git clone https://github.com/brendangregg/FlameGraph │ cd FlameGraph │ perf script -i path/to/perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > perf-flamegraph.svg └──── You may need to run the following command to allow recording by non-root users ([more infos]): ┌──── │ echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid └──── [more infos] <https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html#unprivileged-users> Sources ╌╌╌╌╌╌╌ • [Profiling OCaml code] • <https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record> • <http://www.brendangregg.com/perf.html#FlameGraphs> Before: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/95433869e4d55c6c822a096a901483304d44338d_2_1380x602.png> After: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/3/3bf847ea23608973644175927e09d4d039ab720e_2_1380x602.png> Bottom-up: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/0/01042663ccf66e8b955723fae3cd1c6ff9e0b029_2_1380x602.png> Flamegraph (cropped): <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/c/c8e3e0f5b9e1d879198892395529ebb3c339c791_2_1380x602.png> [Profiling OCaml code] <https://github.com/ocaml-bench/notes/blob/master/profiling_notes.md> Decimal 0.2.1 - arbitrary-precision decimal floating point ══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/decimal-0-2-1-arbitrary-precision-decimal-floating-point/7144/1> Yawar Amin announced ──────────────────── Happy to announce that `decimal' 0.2.1 has been [pubished on opam]. `decimal' is a port of [Python's `decimal' module] to OCaml and implements the [General Decimal Arithmetic Specification]. However note that it is a port in progress–basic arithmetic and rounding functions have been ported, but I am still working on powers and logs. The ported functions pass the same unit test suite that the Python version does (with some minor modifications). Another caveat: currently the library is only supported on 64-bit architectures due to (exponent) overflow issues on 32-bit. If anyone is willing to test and fix overflows on 32-bit, I am more than happy to accept PRs. Here's an example of using the module: ┌──── │ (* Rosetta Code Currency Example *) │ │ (* Demo purposes, normally you'd prefix module name or local open *) │ open Decimal │ │ let hamburger_qty = of_string "4_000_000_000_000_000" │ let hamburger_amt = of_string "5.50" │ let milkshake_qty = of_int 2 │ let milkshake_amt = of_string "2.86" │ │ (* Shortcut to divide 7.65 by 100 *) │ let tax_rate = of_string "7.65e-2" │ │ let subtotal = hamburger_qty * hamburger_amt + milkshake_qty * milkshake_amt │ let tax = round ~n:2 (subtotal * tax_rate) │ let total = subtotal + tax │ │ let () = Format.printf "Subtotal: %a │ Tax: %a │ Total: %a\n" pp subtotal pp tax pp total └──── You can get the package with: `opam install decimal'. Minimum OCaml version 4.08. [pubished on opam] <http://opam.ocaml.org/packages/decimal/> [Python's `decimal' module] <https://docs.python.org/3/library/decimal.html> [General Decimal Arithmetic Specification] <http://speleotrove.com/decimal/decarith.html> Basic GitLab CI configuration ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/basic-gitlab-ci-configuration/3327/25> gasche announced ──────────────── After a long ci-golfing adventure (83 tests), I got a `.gitlab-ci.yml' file that I think is reusable and useful for small projects / libraries: • project: <https://gitlab.com/gasche/gitlab-ocaml-ci-example> • configuration file: <https://gitlab.com/gasche/gitlab-ocaml-ci-example/-/blob/main/.gitlab-ci.yml> Features: • It is project-agnostic, so it should work unchanged for your own (simple) projects. • It caches the opam dependencies. • It builds the project, runs the tests and builds the documentation. • Several compiler versions can be tested in parallel. • It provides an easy way to upload the documentation as "Gitlab project Pages". CI times are satisfying: on very small libraries I observe a 11mn job time on the first run (or when cleaning the opam cache), and 2mn job time on following runs. The expected usage-mode of this CI configuration is that you copy it in your own project. If you find that you need/want additional features, ideally you would try to write them in a project-agonistic way and contribute them back to the example repository. This configuration does not use @smondet's trick of generating a docker image on the fly. I think this would be an excellent idea to get more reliable caching, but it is too complex for me and I don't see how to do it in a maintainable and project-agnostic way. Current status ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I wrote this CI configuration over the week-end, and have not used it much. I expect it to keep evolving somewhat before it stabilizes. Feedback from other people trying to use the configuration would be warmly welcome. Aside on `_build' caching ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I also implemented caching of dune's `_build' data, inspired by the [data-encoding] example of @raphael-proust. I don't need it for my small projects (dune build is 3s, compared to 1m setting up the Docker image), but I thought it would make the CI configuration scale better to larger projects. When I tested this CI configuration, I discovered that caching the dune `_build' data does not work as well as I had expected. (Tracking issue: [dune#4150]). I can tell because I am asking dune to tell me about what it is rebuilding (`dune build --display short'). I suspect that projects that cache the `_build' data *without* logging what dune (re)builds are also not caching as much as they think they are. (But then maybe the use of a fixed-compiler OPAM image, as data-encoding is using, solves the issue.) [data-encoding] <https://gitlab.com/nomadic-labs/data-encoding/-/blob/master/.gitlab-ci.yml> [dune#4150] <https://github.com/ocaml/dune/issues/4150> official CI template? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I considered submitting this CI configuration as an "OCaml Gitlab CI template" to go with the official list of "blessed" CI templates in [the documentation]. But reading the [Development guide for Gitlab CI/CD templates] convinced me that my CI configuration is nowhere ready to serve this role. Gitlab developers apparently expect that users will be able to "include" those CI templates by pointing to their URL, and then tune it for their own use-case (without modifying it) by performing some (unreasonable?) inheritance tricks using whatever those configurations offers as abstraction/inheritance/extension/overriding mechanism. Let's just say that this is next-level CI configuration writing, and that my script is not ready for this. [the documentation] <https://docs.gitlab.com/ee/ci/examples/README.html#cicd-templates> [Development guide for Gitlab CI/CD templates] <https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/cicd/templates.md> OCaml Office Hours? ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-office-hours/7132/4> Deep in this thread, UnixJunkie said ──────────────────────────────────── In addition to mailing lists and discuss, there is also an IRC channel where people can interact with some ocaml experts in a more "interactive" manner (<irc://irc.freenode.net/#ocaml>) json-data-encoding 0.9 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157/1> Raphaël Proust announced ──────────────────────── On behalf of [Nomadic Labs], I'm happy to announce the release of json-data-encoding version 0.9. The code is hosted on Gitlab: <https://gitlab.com/nomadic-labs/json-data-encoding> It is distributed under GNU LGPL with linking exception. The documentation is available online: <https://nomadic-labs.gitlab.io/json-data-encoding/> The package is available under opam: `opam install json-data-encoding' json-data-encoding is a library to define encoder/decoder values to translate OCaml values to JSON and back. It also generates JSON schemas so you can document the value representation. It can use either Ezjsonm or Yojson as backends. The version 0.9 has the following new features: • more tests • memoisation of fixpoint encoding to avoid repeated computations • support for `format' field for string schemas (see <https://json-schema.org/understanding-json-schema/reference/string.html#format>) (contributed by @levillain.maxime) • fixed integer bound printing in schemas (bug report by @pw374) • support for json-lexeme streaming (see details below) • support for inclusion/exclusion of default-value fields during serialisation (contributed by @levillain.maxime) • improved union-of-object schemas (contributed by @levillain.maxime) One major difference with the previous release is the inclusion of a lexeme-streaming JSON constructor. Specifically, the function ┌──── │ val construct_seq : 't encoding -> 't -> jsonm_lexeme Stdlib.Seq.t └──── generates a sequence of `Jsonm.lexeme' (the . This sequence is lazy (in the sense of `Stdlib.Seq' not of `Stdlib.Lazy') and it paves the way to a similar feature in `data-encoding'. An interesting feature of sequences is that they can be used in Vanilla OCaml settings as well as Lwt/Async settings where they allow user-driven yielding in between elements. [Nomadic Labs] <https://nomadic-labs.com/> VSCode OCaml Platform v1.6.0 ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-6-0/7164/1> Rudi Grinberg announced ─────────────────────── On behalf of the vscode-ocaml-platform team, I'm pleased to announce 1.6.0. This release contains a new activity tab for managing opam switches developed by @tmattio. We hope you find it useful. Change log: ┌──── │ - Highlight token aliases in Menhir associativity declarations (#473) │ │ - Activate the extension when workspace contains OCaml, Reason sources or │ project marker files. (#482) │ │ - Add `ocaml.useOcamlEnv` setting to determine whether to use `ocaml-env` for │ opam commands from OCaml for Windows (#481) │ │ - Fix terminal creation when using default shell and arguments (#484) │ │ - Add an OCaml activity tab. │ │ The activity tab provides three views: the available switches, the build │ commands and an Help and Feedback section with links to community channels. │ │ - Support `eliom` and `eliomi` file extensions (#487) │ │ - Fix ocaml/ocaml-lsp#358: automatic insertion of an inferred interface was │ inserting code incorrectly on the second switch to the newly created (unsaved) │ `mli` file. If the new `mli` file isn't empty, we don't insert inferred │ interface (#498) └──── release 0.3.0 of drom, the OCaml project creator ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-0-3-0-of-drom-the-ocaml-project-creator/7166/1> Fabrice Le Fessant announced ──────────────────────────── We are pleased to release version 0.3.0 of `drom', the OCaml project creator. `drom' is born from a simple observation: every time you create a new OCaml project, you spend time searching and copy-pasting files from other projects, adapting them to the new one. `drom' does that for you: it comes with a set of predefined skeleton projects, that you can easily configure and adapt to your goal. It's as easy as: ┌──── │ $ drom new │ # check the list of skeletons │ $ drom new PROJECT_NAME --skeleton SKELETON_NAME │ $ cd PROJECT_NAME │ $ emacs drom.toml │ # ... edit basic description, dependencies, etc. ... │ $ drom project │ $ drom build └──── Thanks to contributors (Maxime Levillain and David Declerck), the list of project skeletons for drom 0.3.0 has grown: • OCaml projects: library menhir mini_lib mini_prg ppx_deriver ppx_rewriter program • C Bindings: c_binding ctypes_foreign ctypes_stubs • Javascript projects: js_lib js_prg vue wasm_binding and you can easily contribute your own: for example, `gh:USER/SKELETON' will trigger the download of the `USER/SKELETON' project from Github as a template for your new project. `drom' is available from `opam': `opam update && opam install drom.0.3.0' <https://github.com/ocamlpro/drom> Enjoy ! 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: 49515 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18840 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 26 to February 02, 2021. Table of Contents ───────────────── release 0.2.2 of ppx_deriving_encoding OCaml 4.12.0, second beta release OCaml Office Hours? Timere 0.1.3 - Dealing with time and time zones have never been easier Interesting OCaml Articles json-data-encoding 0.9 ocamlearlybird 1.0.0 beta1 Cmdliner cheatsheet containers 3.2 OCaml Café: Thu, Feb 11 @ 7pm (U.S. Central) Dependency graph of some OCaml source files Other OCaml News Old CWN release 0.2.2 of ppx_deriving_encoding ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-0-2-2-of-ppx-deriving-encoding/7169/1> levillain.maxime announced ────────────────────────── Following the release of [json-data-encoding.0.9], I am happy to announce the release of ppx_deriving_encoding.0.2.2. The code source and some documentation is available on [gitlab], and the package can be installed with opam (`opam install ppx_deriving_encoding'). This ppx allows to derive encoding of json-data-encoding library from most of ocaml types. Have fun! [json-data-encoding.0.9] <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157> [gitlab] <https://gitlab.com/o-labs/ppx_deriving_encoding> OCaml 4.12.0, second beta release ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-second-beta-release/7171/1> octachron announced ─────────────────── The release of OCaml 4.12.0 is on the horizon. We have created a new beta version to help you adapt your software to the new features ahead of the release. Compared to the first beta release, this new release contains one fix for the Thread library (for a race condition on Windows), and experimentally re-enables building the compiler on illumos and Oracle Solaris. We are expecting this beta to be the last one before the release. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Happy hacking, – Florian Angeletti for the OCaml team. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.12.0~beta2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can pick configuration options with ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~beta2+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and afl enabled switch: ┌──── │ opam switch create 4.12.0~beta2+flambda+afl │ --packages=ocaml-variants.4.12.0~beta2+options,ocaml-option-flambda,ocaml-option-afl │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with "opam search ocaml-option". The source code is available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.12.0-beta2.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~beta2.tar.gz> If you want to test this version, you may want to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various packages patched with fixes in the process of being upstreamed. Once the repository installed, these patched packages will take precedence over the non-patched version. Changes from the first beta ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Thread library ┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • *additional fixes* [9757], [9846], +[10161]: check proper ownership when operating over mutexes. Now, unlocking a mutex held by another thread or not locked at all reliably raises a Sys_error exception. Before, it was undefined behavior, but the documentation did not say so. Likewise, locking a mutex already locked by the current thread reliably raises a Sys_error exception. Before, it could deadlock or succeed (and do recursive locking), depending on the OS. (Xavier Leroy, report by Guillaume Munch-Maccagnoni, review by Guillaume Munch-Maccagnoni, David Allsopp, and Stephen Dolan) [9757] <https://github.com/ocaml/ocaml/issues/9757> [9846] <https://github.com/ocaml/ocaml/issues/9846> [10161] <https://github.com/ocaml/ocaml/issues/10161> Build system ┄┄┄┄┄┄┄┄┄┄┄┄ • [10063]: (Re-)enable building on illumos (SmartOS, OmniOS, …) and Oracle Solaris; x86_64/GCC and 64-bit SPARC/Sun PRO C compilers. (partially revert [2024]). (Tõivo Leedjärv and Konstantin Romanov, review by Gabriel Scherer, Sébastien Hinderer and Xavier Leroy) [10063] <https://github.com/ocaml/ocaml/issues/10063> [2024] <https://github.com/ocaml/ocaml/issues/2024> Documentation ┄┄┄┄┄┄┄┄┄┄┄┄┄ • [9755]: Manual: post-processing the html generated by ocamldoc and hevea. Improvements on design and navigation, including a mobile version, and a quick-search functionality for the API. (San Vũ Ngọc, review by David Allsopp and Florian Angeletti) • [10142], [10154]: improved rendering and latex code for toplevel code examples. (Florian Angeletti, report by John Whitington, review by Gabriel Scherer) [9755] <https://github.com/ocaml/ocaml/issues/9755> [10142] <https://github.com/ocaml/ocaml/issues/10142> [10154] <https://github.com/ocaml/ocaml/issues/10154> OCaml Office Hours? ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-office-hours/7132/9> Deep in this thread, Orbifx said ──────────────────────────────── And there is XMPP: <xmpp:ocaml@conference.orbitalfox.eu?join> Timere 0.1.3 - Dealing with time and time zones have never been easier ══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-timere-0-1-3-dealing-with-time-and-time-zones-have-never-been-easier/7173/1> Darren announced ──────────────── I am happy to announce first release of [Timere], a time handling and reasoning library, which @Drup and I have been working on recently. [Timere] <https://github.com/daypack-dev/timere> Examples ╌╌╌╌╌╌╌╌ Christmases which fall on Wednesday from now ┌──── │ let () = │ let open Timere in │ match │ resolve ( │ after (Date_time.now ()) │ & months [`Dec] │ & days [25] │ & weekdays [`Wed] │ ) │ with │ | Error msg -> failwith msg │ | Ok s -> │ Fmt.pr "%a@." (pp_intervals ~sep:(Fmt.any "@.") ()) s └──── gives ┌──── │ [2024 Dec 25 00:00:00 +00:00:00, 2024 Dec 26 00:00:00 +00:00:00) │ [2030 Dec 25 00:00:00 +00:00:00, 2030 Dec 26 00:00:00 +00:00:00) │ [2041 Dec 25 00:00:00 +00:00:00, 2041 Dec 26 00:00:00 +00:00:00) │ [2047 Dec 25 00:00:00 +00:00:00, 2047 Dec 26 00:00:00 +00:00:00) │ [2052 Dec 25 00:00:00 +00:00:00, 2052 Dec 26 00:00:00 +00:00:00) │ [2058 Dec 25 00:00:00 +00:00:00, 2058 Dec 26 00:00:00 +00:00:00) │ ... └──── See [here] for more examples [here] <https://github.com/daypack-dev/timere/tree/main/examples> Features ╌╌╌╌╌╌╌╌ • Timestamp and date time handling with platform independent time zone support • Subset of the IANA time zone database is built into this library • Reasoning over time intervals via timere objects/expressions, examples: • Pattern matching time and intervals. These work across DST boundaries. • Intersection and union • Chunking at year or month boundary, or in fixed sizes • Evaluate (sub)expressions with a different time zone (e.g. intersection of 9am to 5pm of Sydney and 9am to 5pm of New York) Links ╌╌╌╌╌ • Repo: <https://github.com/daypack-dev/timere> • API doc: <https://daypack-dev.github.io/timere/timere/Timere/index.html> Interesting OCaml Articles ══════════════════════════ Archive: <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/92> Yawar Amin announced ──────────────────── Not primarily a programming article but I thought this is an interesting exception because it may be the first time OCaml has been mentioned in the Financial Times: <https://www.ft.com/content/81811f27-4a8f-4941-99b3-2762cae76542> json-data-encoding 0.9 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157/2> Raphaël Proust announced ──────────────────────── On behalf of Nomadic Labs, it is my pleasure to release json-data-encoding.0.9.1. The code of this packaging-fix release is identical to the recent json-data-encoding.0.9 but the license information has been corrected. The previous release had _LGPL with linking exception_ headers in the source files, LICENSE file in the repository, and license field in the opam file. However, the code was actually under MIT as per agreement of the copyright holders. Release 0.9.1 has the correct license headers, LICENSE file and license field in the opam files. The code of 0.9/0.9.1 is in dual license. Future releases will be under MIT license only. ocamlearlybird 1.0.0 beta1 ══════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180/1> 文宇祥 announced ──────────────── I'm pleased to annonce that [ocamlearlybird] 1.0.0~beta1 just released. Will soon be available on opam. This is a big step that we toward 1.0.0. We solved lots of issues and tested with realy ocaml projects such as utop, ocamlformat, and so on. And certainly, it can debug ocamlearlybird itself. Try yourself! [ocamlearlybird] <https://github.com/hackwaly/ocamlearlybird> NOTES. ╌╌╌╌╌╌ • New version only support OCaml 4.11. If you need other versions support, please let me know. • Dune-release do not support `1.0.0~beta1' version string. So we released 1.0.0 as 1.0.0~beta1 on opam. KNOWN ISSUES: ╌╌╌╌╌╌╌╌╌╌╌╌╌ • Continue run command may hit on last removed breakpoint once when debug utop. 文宇祥 ────── Since the post has edited over 3 times. I can't edit it anyway. I uploaded demo video here: [Debug utop] [Debug utop] <https://media.githubusercontent.com/media/hackwaly/ocamlearlybird/master/_assets/utop.webp> Cmdliner cheatsheet ═══════════════════ Archive: <https://discuss.ocaml.org/t/cmdliner-cheatsheet/7185/1> Martin Jambon announced ─────────────────────── As a follow-up to [an earlier conversation], I made a [cheatsheet and a template] for using cmdliner by @dbuenzli. It was done quickly and I don't know everything about cmdliner, so please let me know if you see mistakes. [an earlier conversation] <https://discuss.ocaml.org/t/what-are-some-libraries-you-almost-always-use/7165/17?u=mjambon> [cheatsheet and a template] <https://github.com/mjambon/cmdliner-cheatsheet> Christian Lindig then said ────────────────────────── Good to see this. I believe a common use case is to add are sub commands as popularised by `git'. It looks like this in my code: ┌──── │ module C = Cmdliner │ │ let report = │ let doc = "generate HTML or JSON report for an outing" in │ let man = .. in │ C.Term. │ (ret (const make $ common_options $ json $ path), info "report" ~doc ~man) │ │ let default = │ let help = `Help (`Pager, None) in │ let doc = "GPS analysis for rowers" in │ C.Term.(ret @@ const help, info "eightplus" ~doc ~man) │ │ let cmds = [ export; report; topspeed; debug; summary; help ] │ let main () = C.Term.(eval_choice default cmds |> exit) │ let () = if !Sys.interactive then () else main () └──── Martin Jambon later said ──────────────────────── I just added a demo/template for subcommand handling. There are now [two demo programs]. One is focused on the different kinds of arguments and the other one on subcommands. [two demo programs] <https://github.com/mjambon/cmdliner-cheatsheet/tree/main/src> Shon also replied ───────────────── In this same vein, I've been compiling "executable notes" whenever I find myself needing a certain Cmdlner recipe. I took took these recent discussion as an occasion to document the module a bit: <https://github.com/shonfeder/kwdcmd> The aim is to provide "self-documenting" constructors that encode the composition of common CLI terms into module namespaces, labeled args, and type aliases. The hope being that I can have the type signature of a combinator give me all the hints I need to avoid having to look up the documentation every time :laughing: It's just a very rough (and quite imperfect) collection of idioms I've found useful, but it could be worth a look! When i get a chance, I hope to look through your cheat sheet to make sure I have a representative constructor for each idiom you've documented. containers 3.2 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-containers-3-2/7196/1> Simon Cruanes announced ─────────────────────── I'm happy to announce that containers 3.2 has just been [released]. It should arrive on opam soon. It notably contains an `Either' compatibility wrapper, more formatting functions, list functions, and a bunch of fixes. Many thanks to @darrenldl for contributing some initial fuzzing support. [released] <https://github.com/c-cube/ocaml-containers/releases/tag/v3.2> OCaml Café: Thu, Feb 11 @ 7pm (U.S. Central) ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-cafe-thu-feb-11-7pm-u-s-central/7197/1> Claude Jager-Rubinson announced ─────────────────────────────── Join us with your questions about the OCaml language, or just to hang out with the OCaml community. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions about the language and ecosystem. Whether you’re still trying to make sense of currying or can spot non-tail-recursive code from across the room, we hope that you’ll join us on Thursday, February 11 at 7pm (U.S. Central time). Meeting info and additional details can be found at [https://hfpug.org]. [https://hfpug.org] <https://hfpug.org> Dependency graph of some OCaml source files ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/dependency-graph-of-some-ocaml-source-files/7198/6> Deep in this thread, Jun FURUSE said ──────────────────────────────────── You may be interested in [cmgraph] which scrapes the compiled modules (`*.cmi/*.cmo/*.cmx') instead of the source code. It needs no compilation switch options since it does not scrape source code. [cmgraph] <https://gitlab.com/camlspotter/cmgraph> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Recent and upcoming changes to Merlin] • [The road ahead for MirageOS in 2021] • [Release of Alt-Ergo 2.4.0] [OCaml Planet] <http://ocaml.org/community/planet/> [Recent and upcoming changes to Merlin] <https://tarides.com/blog/2021-01-26-recent-and-upcoming-changes-to-merlin> [The road ahead for MirageOS in 2021] <https://hannes.nqsb.io/Posts/NGI> [Release of Alt-Ergo 2.4.0] <https://www.ocamlpro.com/2021/01/22/release-of-alt-ergo-2-4-0/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 37092 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18679 bytes --] Hello Here is the latest OCaml Weekly News, for the week of February 09 to 16, 2021. Table of Contents ───────────────── opam 2.0.8 release opam 2.1.0~beta4 Set up OCaml 1.1.6 Set up OCaml 1.1.7 Old CWN opam 2.0.8 release ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-0-8-release/7242/1> R. Boujbel announced ──────────────────── We are pleased to announce the minor release of [opam 2.0.8]. This new version contains some fixes, mainly for sandbox and fish scripts. You can find more information in this [blog post], and more detailed in the [release note]. /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.8] <https://github.com/ocaml/opam/releases/tag/2.0.8> [blog post] <https://opam.ocaml.org/blog/opam-2-0-8> [release note] <https://github.com/ocaml/opam/releases/tag/2.0.8> opam 2.1.0~beta4 ════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0-beta4/7252/1> David Allsopp announced ─────────────────────── On behalf of the opam team, it gives me great pleasure to announce the third beta release of opam 2.1. Don’t worry, you didn’t miss beta3 - we had an issue with a configure script that caused beta2 to report as beta3 in some instances, so we skipped to beta4 to avoid any further confusion! We encourage you to try out this new beta release: there are instructions for doing so in [our wiki]. The instructions include taking a backup of your `~/.opam' root as part of the process, which can be restored in order to wind back. _Please note that local switches which are written to by opam 2.1 are upgraded and will need to be rebuilt if you go back to opam 2.0_. This can either be done by removing `_opam' and repeating whatever you use in your build process to create the switch, or you can use `opam switch export switch.export' to backup the switch to a file before installing new packages. Note that opam 2.1 _shouldn’t_ upgrade a local switch unless you upgrade the base packages (i.e. the compiler). [our wiki] <https://github.com/ocaml/opam/wiki/How-to-test-an-opam-feature> What’s new in opam 2.1? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Switch invariants • Improved options configuration (see the new `option' and expanded `var' sub-commands) • Integration of system dependencies (formerly the opam-depext plugin), increasing their reliability as it integrates the solving step • Creation of lock files for reproducible installations (formerly the opam-lock plugin) • CLI versioning, allowing cleaner deprecations for opam now and also improvements to semantics in future without breaking backwards-compatibility • Performance improvements to opam-update, conflict messages, and many other areas • New plugins: opam-compiler and opam-monorepo Switch invariants ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ In opam 2.0, when a switch is created the packages selected are put into the “base” of the switch. These packages are not normally considered for upgrade, in order to ease pressure on opam’s solver. This was a much bigger concern early on in opam 2.0’s development, but is less of a problem with the default mccs solver. However, it’s a problem for system compilers. opam would detect that your system compiler version had changed, but be unable to upgrade the ocaml-system package unless you went through a slightly convoluted process with `--unlock-base'. In opam 2.1, base packages have been replaced by switch invariants. The switch invariant is a package formula which must be satisfied on every upgrade and install. All existing switches’ base packages could just be expressed as `package1 & package2 & package3' etc. but opam 2.1 recognises many existing patterns and simplifies them, so in most cases the invariant will be `"ocaml-base-compiler" {= 4.11.1}', etc. This means that `opam switch create my_switch ocaml-system' now creates a _switch invariant_ of `"ocaml-system"' rather than a specific version of the `ocaml-system' package. If your system OCaml package is updated, `opam upgrade' will seamlessly switch to the new package. This also allows you to have switches which automatically install new point releases of OCaml. For example: ┌──── │ opam switch create ocaml-4.11 --formula='"ocaml-base-compiler" {>= "4.11.0" & < "4.12.0~"}' │ --repos=old=git+https://github.com/ocaml/opam-repository#a11299d81591 │ opam install utop └──── Creates a switch with OCaml 4.11.0 (the `--repos=' was just to select a version of opam-repository from before 4.11.1 was released). Now issue: ┌──── │ opam repo set-url old git+https://github.com/ocaml/opam-repository │ opam upgrade └──── and opam 2.1 will automatically offer to upgrade OCaml 4.11.1 along with a rebuild of the switch. There’s not yet a clean CLI for specifying the formula, but we intend to iterate further on this with future opam releases so that there is an easier way of saying “install OCaml 4.11.x”. opam depext integration ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ opam has long included the ability to install system dependencies automatically via the [depext plugin]. This plugin has been promoted to a native feature of opam 2.1.0 onwards, giving the following benefits: • You no longer have to remember to run `opam depext', opam always checks depexts (there are options to disable this or automate it for CI use). Installation of an opam package in a CI system is now as easy as `opam install .', without having to do the dance of `opam pin add -n/depext/install'. Just one command now for the common case! • The solver is only called once, which both saves time and also stabilises the behaviour of opam in cases where the solver result is not stable. It was possible to get one package solution for the `opam depext' stage and a different solution for the `opam install' stage, resulting in some depexts missing. • opam now has full knowledge of depexts, which means that packages can be automatically selected based on whether a system package is already installed. For example, if you have *neither* MariaDB nor MySQL dev libraries installed, `opam install mysql' will offer to install `conf-mysql' and `mysql', but if you have the MariaDB dev libraries installed, opam will offer to install `conf-mariadb' and `mysql'. [depext plugin] <https://github.com/ocaml-opam/opam-depext> opam lock files and reproducibility ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ When opam was first released, it had the mission of gathering together scattered OCaml source code to build a [community repository]. As time marches on, the size of the opam repository has grown tremendously, to over 3000 unique packages with over 18000 unique versions. opam looks at all these packages and is designed to solve for the best constraints for a given package, so that your project can keep up with releases of your dependencies. While this works well for libraries, we need a different strategy for projects that need to test and ship using a fixed set of dependencies. To satisfy this use-case, opam 2.0.0 shipped with support for _using_ `project.opam.locked' files. These are normal opam files but with exact versions of dependencies. The lock file can be used as simply as `opam install . --locked' to have a reproducible package installation. With opam 2.1.0, the creation of lock files is also now integrated into the client: • `opam lock' will create a `.locked' file for your current switch and project, that you can check into the repository. • `opam switch create . --locked' can be used by users to reproduce your dependencies in a fresh switch. This lets a project simultaneously keep up with the latest dependencies (without lock files) while providing a stricter set for projects that need it (with lock files). [community repository] <https://github.com/ocaml/opam-repository> CLI Versioning ┄┄┄┄┄┄┄┄┄┄┄┄┄┄ A new `--cli' switch was added to the first beta release, but it’s only now that it’s being widely used. opam is a complex enough system that sometimes bug fixes need to change the semantics of some commands. For example: • `opam show --file' needed to change behaviour • The addition of new controls for setting global variables means that the `opam config' was becoming cluttered and some things want to move to `opam var' • `opam switch create 4.11.1' still works in opam 2.0, but it’s really an OPAM 1.2.2 syntax. Changing the CLI is exceptionally painful since it can break scripts and tools which themselves need to drive `opam'. CLI versioning is our attempt to solve this. The feature is inspired by the `(lang dune ...)' stanza in `dune-project' files which has allowed the Dune project to rename variables and alter semantics without requiring every single package using Dune to upgrade their `dune' files on each release. Now you can specify which version of opam you expected the command to be run against. In day-to-day use of opam at the terminal, you wouldn’t specify it, and you’ll get the latest version of the CLI. For example: `opam var --global' is the same as `opam var --cli=2.1 --global'. However, if you issue `opam var --cli=2.0 --global', you will told that `--global' was added in 2.1 and so is not available to you. You can see similar things with the renaming of `opam upgrade --unlock-base' to `opam upgrade --update-invariant'. The intention is that `--cli' should be used in scripts, user guides (e.g. blog posts), and in software which calls opam. The only decision you have to take is the _oldest_ version of opam which you need to support. If your script is using a new opam 2.1 feature (for example `opam switch create --formula=') then you simply don’t support opam 2.0. If you need to support opam 2.0, then you can’t use `--formula' and should use `--packages' instead. opam 2.0 does not have the `--cli' option, so for opam 2.0 instead of `--cli=2.0' you should set the environment variable `OPAMCLI' to `2.0'. As with _all_ opam command line switches, `OPAMCLI' is simply the equivalent of `--cli' which opam 2.1 will pick-up but opam 2.0 will quietly ignore (and, as with other options, the command line takes precedence over the environment). Note that opam 2.1 sets `OPAMCLI=2.0' when building packages, so on the rare instances where you need to use the `opam' command in a _package_ `build:' command (or in your build system), you _must_ specify `--cli=2.1' if you’re using new features. There’s even more detail on this feature [in our wiki]. We’re still finalising some details on exactly how `opam' behaves when `--cli' is not given, but we’re hoping that this feature will make it much easier in future releases for opam to make required changes and improvements to the CLI without breaking existing set-ups and tools. [in our wiki] <https://github.com/ocaml/opam/wiki/Spec-for-opam-CLI-versioning> What’s new since the last beta? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • opam now uses CLI versioning ([#4385]) • opam now exits with code 31 if all failures were during fetch operations ([#4214]) • `opam install' now has a `--download-only' flag ([#4036]), allowing opam’s caches to be primed • `opam init' now advises the correct shell-specific command for `eval $(opam env)' ([#4427]) • `post-install' hooks are now allowed to modify or remove installed files ([#4388]) • New package variable `opamfile-loc' with the location of the installed package opam file ([#4402]) • `opam update' now has `--depexts' flag ([#4355]), allowing the system package manager to update too • depext support NetBSD and DragonFlyBSD added ([#4396]) • The format-preserving opam file printer has been overhauled ([#3993], [#4298] and [#4302]) • pins are now fetched in parallel ([#4315]) • `os-family=ubuntu' is now treated as `os-family=debian' ([#4441]) • `opam lint' now checks that strings in filtered package formulae are booleans or variables ([#4439]) and many other bug fixes as listed [on the release page]. [#4385] <https://github.com/ocaml/opam/pull/4385> [#4214] <https://github.com/ocaml/opam/issues/4214> [#4036] <https://github.com/ocaml/opam/issues/4036> [#4427] <https://github.com/ocaml/opam/pull/4427> [#4388] <https://github.com/ocaml/opam/pull/4388> [#4402] <https://github.com/ocaml/opam/pull/4402> [#4355] <https://github.com/ocaml/opam/issues/4355> [#4396] <https://github.com/ocaml/opam/pull/4396> [#3993] <https://github.com/ocaml/opam/issues/3993> [#4298] <https://github.com/ocaml/opam/pull/4298> [#4302] <https://github.com/ocaml/opam/pull/4302> [#4315] <https://github.com/ocaml/opam/issues/4315> [#4441] <https://github.com/ocaml/opam/pull/4441> [#4439] <https://github.com/ocaml/opam/issues/4439> [on the release page] <https://github.com/ocaml/opam/releases/tag/2.1.0-beta4> New Plugins ╌╌╌╌╌╌╌╌╌╌╌ Several features that were formerly plugins have been integrated into opam 2.1.0. We have also developed some _new_ plugins that satisfy emerging workflows from the community and the core OCaml team. They are available for use with the opam 2.1 beta as well, and feedback on them should be directed to the respective GitHub trackers for those plugins. opam compiler ┄┄┄┄┄┄┄┄┄┄┄┄┄ The [`opam compiler'] plugin can be used to create switches from various sources such as the main opam repository, the ocaml-multicore fork, or a local development directory. It can use Git tag names, branch names, or PR numbers to specify what to install. Once installed, these are normal opam switches, and one can install packages in them. To iterate on a compiler feature and try opam packages at the same time, it supports two ways to reinstall the compiler: either a safe and slow technique that will reinstall all packages, or a quick way that will just overwrite the compiler in place. [`opam compiler'] <https://github.com/ocaml-opam/opam-compiler> opam monorepo ┄┄┄┄┄┄┄┄┄┄┄┄┄ The [`opam monorepo'] plugin lets you assemble standalone dune workspaces with your projects and all of their opam dependencies, letting you build it all from scratch using only Dune and OCaml. This satisfies the “monorepo” workflow which is commonly requested by large projects that need all of their dependencies in one place. It is also being used by projects that need global cross-compilation for all aspects of a codebase (including C stubs in packages), such as the MirageOS unikernel framework. [`opam monorepo'] <https://github.com/ocamllabs/opam-monorepo> Next Steps ╌╌╌╌╌╌╌╌╌╌ This is anticipated to be the final beta in the 2.1 series, and we will be moving to release candidate status after this. We could really use your help with testing this release in your infrastructure and projects and let us know if you run into any blockers. If you have feature requests, please also report them on [our issue tracker] – we will be planning the next release cycle once we ship opam 2.1.0 shortly. [our issue tracker] <https://github.com/ocaml/opam/issues> Set up OCaml 1.1.6 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-6/7276/1> Sora Morimoto announced ─────────────────────── This release includes a change to make the OCaml CI workflow on Windows faster! I tested this on one of my repos where the build itself is mere seconds. Before this change, setup-ocaml needed an average of 5:39 to install OCaml+opam and 1:53 to build the dependencies of the library. After this change, it needs an average of 3:15 for the installation and 1:27 for the deps. Changed ╌╌╌╌╌╌╌ • Windows installs Cygwin to `D:\cygwin', using faster Azure temporary storage. <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.6> Set up OCaml 1.1.7 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-7/7279/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • Ubuntu and macOS runners no longer display "No switch is currently installed." before building the compiler. • Ubuntu no longer installs the system ocaml packages. • macOS no longer builds two compilers on every run. • Upgrade opam to 2.0.8 for Linux VMs. <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.7> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 32262 bytes --]
[-- Attachment #1: Type: text/plain, Size: 15261 bytes --] Hello Here is the latest OCaml Weekly News, for the week of February 16 to 23, 2021. Table of Contents ───────────────── OCamlFormat 0.17.0 Set up OCaml 1.1.8 Set up OCaml 1.1.9 OCaml 4.12.0, first release candidate Ppxlib.0.22: an update on the state of ppx OCaml-based trading firm is hiring remote devs ocamlearlybird 1.0.0 beta1 OCaml for ARM MacOS Old CWN OCamlFormat 0.17.0 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-17-0/7287/1> Guillaume Petiot announced ────────────────────────── On behalf of the OCamlFormat development team I am pleased to announce the release of [ocamlformat.0.17.0] :tada:. OCamlformat is an auto-formatter for OCaml code, writing the parse tree and comments in a consistent style, so that you do not have to worry about formatting it by hand, and to speed up code review by focusing on the important parts. OCamlFormat is beta software. We expect the program to change considerably before we reach version 1.0.0. In particular, upgrading the `ocamlformat' package will cause your program to get reformatted. Sometimes it is relatively pain-free, but sometimes it will make a diff in almost every file. We are working towards having a tool that pleases most usecases in the OCaml community, please bear with us! To make sure your project uses the last version of ocamlformat, please set ┌──── │ version=0.17.0 └──── in your `.ocamlformat' file. Main changes in `ocamlformat.0.17.0' are: • the `let-open' option, deprecated since 0.16.0, has been removed • support for OCaml 4.06 and 4.07 has been removed, minimal version requirement bumped to OCaml 4.08 • the `extension-sugar' option, deprecated since 0.14.0, has been removed • the syntax of infix set/get operators is now preserved (`String.get' and similar calls used to be automatically rewritten to their corresponding infix form `.()', that was incorrect when using the `-unsafe' compilation flag. Now the concrete syntax of these calls is preserved) • all sugared extension points are now preserved • injectivity type annotations (OCaml 4.12 feature) are now supported • various fixes about comments positions 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 have a [FAQ for new users ] that should help you decide if ocamlformat is the right choice for you. [ocamlformat.0.17.0] <https://github.com/ocaml-ppx/ocamlformat> [FAQ for new users ] <https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users> Set up OCaml 1.1.8 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-8/7288/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • The Windows opam wrapper is fractionally less-archaically named opam.cmd, with no loss in arcaneness. • Export `CYGWIN_ROOT' on the Windows runners, allowing bash to be invoked as `%CYGWIN_ROOT%\bin\bash~/~$env:CYGWIN_ROOT\bin\bash' (and similarly for Cygwin `setup-x86_64.exe'). • The Windows runner no longer prepends `%CYGWIN_ROOT%\bin' to `PATH'. Fixed ╌╌╌╌╌ • Switches in Unix are now properly initialized before running depext. <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.8> Set up OCaml 1.1.9 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-9/7293/1> Sora Morimoto announced ─────────────────────── Fixed ╌╌╌╌╌ • Further fix to switch initialisation. <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.9> OCaml 4.12.0, first release candidate ═════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294/1> octachron announced ─────────────────── The release of OCaml 4.12.0 is expected next week. We have created a release candidate that you can test. Most opam packages should work with this release candidate (without the need for an alpha repository). Compared to the last beta, this new release only contains one fix for Solaris and illumos. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Happy hacking, – Florian Angeletti for the OCaml team. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.12.0~rc1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can pick configuration options with ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~rc1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where `<option_list>' is a comma separated list of ocaml-option-* packages. For instance, for a flambda and afl enabled switch: ┌──── │ opam switch create 4.12.0~rc1+flambda+afl --packages=ocaml-variants.4.12.0~rc1+options,ocaml-option-flambda,ocaml-option-afl │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with `opam search ocaml-option'. The source code is available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.12.0-rc1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~rc1.tar.gz> Ppxlib.0.22: an update on the state of ppx ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296/1> Nathan Rebours announced ──────────────────────── We're happy to announce the release of ppxlib.0.22.0, the fist release of ppxlib fully compatible with OCaml 4.12. The main and only feature of this release is the bump of the internal OCaml AST used by ppxlib from 4.11 to 4.12, allowing you to use 4.12 language features with ppxlib and any ppxlib-based ppx. Note that ppxlib was compatible with the 4.12 compiler since 0.19.0 but that you couldn't use 4.12 language features until now. This is the third such AST bump release since we announced our plan to improve the state of the PPX ecosystem [here] and we though it'd be a good time to report back to you and tell you how things are going on this front. For those of you who aren't familiar with this plan, the goal is to upstream a minimal, stable, ocaml-migrate-parsetree-like API on top of the compiler-libs called `Astlib'. It will allow us to keep ppxlib and any ppx based on ppxlib compatible with OCaml trunk at all time. To allow better performances and a clear compisition semantic, all the ppxlib-based ppx-es need to use the same AST (as opposed to ocaml-migrate-parsetree based ppx-es) so from a certain perspective, this plan simply moves the breaking API up one step, from compiler-libs to ppxlib. In order to greatly ease the maintainenance of ppx-es and to prevent opam-universe splits we decided that everytime we cut a breaking ppxlib release, we will send patches to keep the existing ppx-es compatible with the latest version and therefore with the latest OCaml compilers and language features. While this seems like a tremendous task and a huge amount of work, dune and other tools that raised in its wake such as [opam-monorepo] incredibly simplified this kind of work. Ahead of OCaml releases, we prepare a branch of ppxlib with the upgraded AST. We then fetch opam-repository to gather a list of sensible reverse dependencies (i.e. packages whose latest version depends on ppxlib and is compatible with ppxlib's latest version) and assemble a dune workspace with a clone of each of those reverse dependencies, our ppxlib branch and all of their dependencies thanks to opam-monorepo. We then use dune to build all the packages we're interested in and simply follow the compilation errors until everything builds successfully with the new ppxlib. What remains is to create PRs on the relevant repositories to upstream those changes, after which maintainers have everything they need to cut a new compatible release. Most of this process is automated using scripts but it still requires a bit of handiwork. We aim at extracting tools to further improve this workflow and reduce the time and effort required but it has been surprisingly smooth. Our experience with the 4.10, 4.11 and 4.12 upgrades so far is that most reverse dependencies don't need an upgrade and that it's far less demanding for one person to upgrade all the packages that need it than it would be for each individual maintainers to understand the changes in the AST and do the upgrade themselves. It's worth noting that for this to work well, the ppx-es and all their dependencies have to build with dune. We do maitain a separate opam-repository with dune ports of commonly used packages so in practice most projects fall into this category but a few exceptions remain and they are therefore not taken into account for this upgrade process. We're also trying to improve the tracking of the upgrade's progress and for the 4.12 compatible release we created a [github project] to have a list of all the packages we considered and see where they are. We also keep track of the packages we had to exclude and why. During this upgrade, we considered 80 opam packages, out of which only 4 needed to be patched and 6 had to be excluded from the process as we couldn't reasonably get them to build in our workspace. Once we have a better idea of what makes a package easy to upgrade we plan on releasing a set of reasonable rules to follow to benefit from those upgrades, we'll keep you updated on this! All in all we're pretty happy with this new process and although it needs to be refined, we're confident it can grow into something sustainable by creating tools and CI to support it. Hopefully these will also benefit the wider community and help grow a healthier Opam universe. [here] <https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231> [opam-monorepo] <https://github.com/ocamllabs/opam-monorepo> [github project] <https://github.com/ocaml-ppx/ppxlib/projects/2> Jason Nielsen asked ─────────────────── Curious about the current status of `Astlib'. I was closely following [ppx] at one point but it hasn't seen much activity recently. Thanks for all your hard work. [ppx] <https://github.com/ocaml-ppx/ppx> Jérémie Dimino ────────────── It's in progress. Not much happened in the past couple of months while we were finishing the port of a few projects to ppxlib and doing the 4.12 upgrade. But @pitag re-started working `Astlib' as of a week ago. You can follow our progression via [the public meeting notes]. Note however that the [ppx] project was for our original goal or providing a "forever stable" API for ppx rewriters. It has been in pause since August 2020 while were trying the "upgrade the world" method, which as @NathanReb pointed out is working pretty well practice. At this point, it's looking more and more likely that we won't resurect the ppx project. [the public meeting notes] <https://github.com/ocaml-ppx/ppxlib/wiki> [ppx] <https://github.com/ocaml-ppx/ppx> OCaml-based trading firm is hiring remote devs ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-based-trading-firm-is-hiring-remote-devs/7298/1> Michael Bacarella announced ─────────────────────────── BTG is a trading firm founded by ex-Jane Street devs looking to hire some more devs. The role is primarily remote, working with the rest of our mostly remote team, though we hope to resume regular on-sites in Puerto Rico. We operate 24/7 and will consider employees anywhere in the world. Prior experience with OCaml is a plus, though any solid programming experience with an interest in functional programming and strong static types is also fine. Comfort navigating Linux is essential. Shoot me a message with a copy of your résumé or C.V. to discuss the opportunity further: [michael.bacarella@gmail.com] Feel free to re-post this elsewhere. [michael.bacarella@gmail.com] <mailto:michael.bacarella@gmail.com> ocamlearlybird 1.0.0 beta1 ══════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180/21> 文宇祥 announced ──────────────── Hi, all. All the issues of beta1 have been fixed. Beta2 will be released soon. <https://github.com/ocaml/opam-repository/pull/18191> OCaml for ARM MacOS ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-for-arm-macos/6019/24> Aaron L. Zeng announced ─────────────────────── I noticed that opam 2.08 is now available for ARM Macs using [Homebrew], and I was able to confirm on my machine. `brew install opam' away :) [Homebrew] <https://github.com/Homebrew/homebrew-core/pull/71605> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 29081 bytes --]
[-- Attachment #1: Type: text/plain, Size: 10261 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 02 to 09, 2021. Table of Contents ───────────────── Working on an app to learn and execute OCaml on iPhone/iPad/Mac for beginners ERic (Entity-Relation interactive calculator) version 0.3 OCaml Café: Tue, March 9 @ 7-9pm (CST) Functional Programming User Study (Specifically in OCaml) OCaml 4.12.0 released (with 4.11.2 too) Other OCaml News Old CWN Working on an app to learn and execute OCaml on iPhone/iPad/Mac for beginners ═════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/working-on-an-app-to-learn-and-execute-ocaml-on-iphone-ipad-mac-for-beginners/7392/1> Nathan Fallet announced ─────────────────────── I started to work on a new project recently: My goal is to provide an iOS app for beginners to learn OCaml and practice on their device. I think it is a good idea to get started easily. Here are some screenshots of what I’ve done so far: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/ef66cf62d1ab605542033f09040cc964787cbb65_2_462x1000.jpeg> I’m open to feedback and opinion about this project idea Nathan Fallet then added ──────────────────────── I made it available for pre order on the App Store - I will keep improving it with time, and I think it can be a great tool for beginners [https://apps.apple.com/app/ocaml-learn-code/id1547506826] [https://apps.apple.com/app/ocaml-learn-code/id1547506826] <https://apps.apple.com/app/ocaml-learn-code/id1547506826> Yawar Amin replied ────────────────── This is really cool. I just want to point out that your app is the sole search result for 'OCaml' in the App Store. So that's a first :-) Incidentally, there is an 'OCaml Toplevel' app on the Android Play Store: <https://play.google.com/store/apps/details?id=fr.vernoux.ocaml> Your app looks more sophisticated though. Hopefully one day we have something like [Swift Playgrounds] and people can start learning OCaml interactively on their devices directly. [Swift Playgrounds] <https://www.apple.com/ca/swift/playgrounds/> ERic (Entity-Relation interactive calculator) version 0.3 ═════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-eric-entity-relation-interactive-calculator-version-0-3/7408/1> Damien Guichard announced ───────────────────────── The [programming languages zoo] is a great resource for wanna-be interpreter/compiler writers. The [ICFP 2000 programming contest] is another great resource for wanna-be ray tracers. However until now there has been no OCaml resource for wanna-be Knowledge Representation tool-ers. This makes sound like KR tool is a more difficult area than other projects. ERic v0.3 demonstrates the opposite as it's about 1200 lines size (lexer & hand-written parser included) and reads/writes a [Conceptual Graph] Interchange Format (CGIF) notation. • ERic v0.3 [Zip archive] • ERic v0.3 [SVN repository] [programming languages zoo] <http://plzoo.andrej.com/> [ICFP 2000 programming contest] <https://www.cs.cornell.edu/icfp/contest_results.htm> [Conceptual Graph] <https://en.wikipedia.org/wiki/Conceptual_graph> [Zip archive] <http://damien-guichard.developpez.com/downloads/ERic-0.3.zip> [SVN repository] <http://subversion.developpez.com/projets/ERic/trunk/> OCaml Café: Tue, March 9 @ 7-9pm (CST) ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-cafe-tue-march-9-7-9pm-cst/7409/1> Claude Jager-Rubinson announced ─────────────────────────────── Please join us next Tuesday at 7pm Central time for the second meeting of OCaml Café. Zoom connection info is available at [Houston Functional Programmers]. OCaml Café offers a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Whether you’re still trying to make sense of currying or can spot non-tail-recursive code from across the room, we hope that you’ll join us with your questions about OCaml, or just to hang out with the OCaml community. [Houston Functional Programmers] <https://hfpug.org> Functional Programming User Study (Specifically in OCaml) ═════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/functional-programming-user-study-specifically-in-ocaml/7410/1> Ahan Malhotra announced ─────────────────────── We are doing user studies to help us understand how to help people understand and navigate complex information about programming documentation, *specifically in OCaml*. You will complete a series tasks that help us understand working memory and how you navigate a new interface. After examining a layout of the data (interface) for a short, predetermined amount of time, you will be asked a set of comprehension and/or qualitative questions to measure whether the methods of presenting this information has any impact on your performance. *The study will take around 55 minutes, and you will be entered into a lottery for a $150 Amazon gift card as compensation for your time.* *A bit more about this study* The user study will be done virtually on Zoom. You will be asked to various tasks with the interface. The interface is deployed as a public web application so you don’t have to install anything. This research is governed by Harvard University's Committee on the Use of Human Subjects. *Eligibility* You also don’t have to be an expert in anything to participate. You just need to be fluent in English and over 18 years of age. If you are interested, please fill out this survey to confirm your eligibility, and we will follow up to schedule the study session: <https://forms.gle/q6vkyEE2tSjjZoiSA> If you have any questions, please email ahanmalhotra@college.harvard.edu. OCaml 4.12.0 released (with 4.11.2 too) ═══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-12-0-released-with-4-11-2-too/7358/13> Continuing this thread from last week, Hannes Mehnert said ────────────────────────────────────────────────────────── Congratulations to the new release. For the curious who intend to install a flambda version of 4.12 and are surprised that `ocaml-variants.4.12.0+flambda' does not exist, from [this thread] the opam layout has changed, and now the following works: ┌──── │ $ opam sw create <my-switch-name> --packages=ocaml-variants.4.12.0+options,ocaml-options-only-flambda └──── There are more configuration options available, take a look at the output of `opam search ocaml-option' for all options. (I've not been involved with this development. I don't quite understand why there is for each `Y' a `ocaml-option-Y' and a `ocaml-options-only-Y'.) I also have not figured out whether there's a way to pass `-O3' in the just created switch. Maybe it is worth to embed such information in the very nicely styled OCaml manual (considering that opam got quite some traction over the years and is recommended for OCaml developers)? [this thread] <https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Release of Frama-Clang 0.0.10] • [Qubes-lite with KVM and Wayland] • [Florence and beyond: the future of Tezos storage] • [The ReScript Association] [OCaml Planet] <http://ocaml.org/community/planet/> [Release of Frama-Clang 0.0.10] <https://frama-c.com/fc-plugins/frama-clang.html> [Qubes-lite with KVM and Wayland] <https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/> [Florence and beyond: the future of Tezos storage] <https://tarides.com/blog/2021-03-04-florence-and-beyond-the-future-of-tezos-storage> [The ReScript Association] <https://rescript-lang.org/blog/rescript-association-rebranding> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 21846 bytes --]
[-- Attachment #1: Type: text/plain, Size: 5376 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 09 to 16, 2021. Table of Contents ───────────────── Links from the OCaml Discourse findlib-1.9 Compiler Explorer now supports OCaml 4.12.0 Old CWN Links from the OCaml Discourse ══════════════════════════════ The editor says ─────────────── Due to a [global Discourse change] that disabled the mailing list mode, I was no able to collect the bodies of the news from the OCaml Discourse for several days. This has now been fixed and next week’s OCaml Weekly News should be as usual. In the meantime, here are links to the main announcements. Do not hesitate to [contact me] if you want to give feedback about this newsletter. • [Release 1.0.0 of bag] • [Plan for Dune 3.0] • [lascar 0.7.0 - a library for manipulating Labeled Transition Systems in OCaml] • [dirsift 0.0.3 - Search for directories by type] • [FSML 0.3.0 - an OCaml library for describing and describing synchronous finite state machines] • [Multicore OCaml: February 2021] • [VSCode OCaml Platform v1.7.0 - v1.8.0] • [ca-certs and ca-certs-nss] • [Js_of_Ocaml position at TrustInSoft] • [Senior Developer vacancy at Cryptosense, France (or remote)] • [hxd.0.3.1 - A simple hexdump tool in OCaml] • [Release of Gopcaml-mode (0.0.2) - Unicode & Compatibility Update] [global Discourse change] <https://meta.discourse.org/t/mailing-list-mode-mysteriously-deactivated/182650> [contact me] <mailto:alan.schmitt@polytechnique.org> [Release 1.0.0 of bag] <https://discuss.ocaml.org/t/ann-release-1-0-0-of-bag/7464> [Plan for Dune 3.0] <https://discuss.ocaml.org/t/plan-for-dune-3-0/7414> [lascar 0.7.0 - a library for manipulating Labeled Transition Systems in OCaml] <https://discuss.ocaml.org/t/ann-lascar-0-7-0-a-library-for-manipulating-labeled-transition-systems-in-ocaml/7443> [dirsift 0.0.3 - Search for directories by type] <https://discuss.ocaml.org/t/ann-dirsift-0-0-3-search-for-directories-by-type/7435> [FSML 0.3.0 - an OCaml library for describing and describing synchronous finite state machines] <https://discuss.ocaml.org/t/ann-fsml-0-3-0-an-ocaml-library-for-describing-and-describing-synchronous-finite-state-machines/7445> [Multicore OCaml: February 2021] <https://discuss.ocaml.org/t/multicore-ocaml-february-2021/7449> [VSCode OCaml Platform v1.7.0 - v1.8.0] <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-7-0-v1-8-0/7424> [ca-certs and ca-certs-nss] <https://discuss.ocaml.org/t/ann-ca-certs-and-ca-certs-nss/6804/7> [Js_of_Ocaml position at TrustInSoft] <https://discuss.ocaml.org/t/js-of-ocaml-position-at-trustinsoft/7429> [Senior Developer vacancy at Cryptosense, France (or remote)] <https://discuss.ocaml.org/t/senior-developer-vacancy-at-cryptosense-france-or-remote/7431> [hxd.0.3.1 - A simple hexdump tool in OCaml] <https://discuss.ocaml.org/t/ann-hxd-0-3-1-a-simple-hexdump-tool-in-ocaml/7417> [Release of Gopcaml-mode (0.0.2) - Unicode & Compatibility Update] <https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-2-unicode-compatibility-update/7425> findlib-1.9 ═══════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00012.html> Gerd Stolpmann announced ──────────────────────── findlib-1.9 is out. Changes: • Overhaul how separately installed packages (e.g. num) are handled (by David Allsopp). • Switch to opam-2.0 file format (by David Allsopp). • Fix an incomaptibility with ocaml-4.13 (by David Allsopp). • Expose the native toplevel (by Louis Gesbert). • Fix an incompatibility with "Jane Street Style" (by Mark Laws). • Switch from m4 to sed (by kit-ty-kate). For manual, download, manuals, etc. see here: <http://projects.camlcity.org/projects/findlib.html> An updated OPAM package will follow soon. Compiler Explorer now supports OCaml 4.12.0 ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-compiler-explorer-now-supports-ocaml-4-12-0/7479/1> Sora Morimoto announced ─────────────────────── Sorry to the OCaml hacker using Compiler Explorer for the late update (it took some time to deploy the infrastructure, etc.), but it now supports OCaml 4.12.0, but also 4.10.2 and 4.11.2! <https://godbolt.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 16008 bytes --]
[-- Attachment #1: Type: text/plain, Size: 7202 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 16 to 23, 2021. Table of Contents ───────────────── findlib-1.9.1 Conformist 0.2.1 Compiler Explorer now supports OCaml 4.12.0 Annoucement of OFLAT, a web-based platform to support courses on Formal Languages and Automata Theory Old CWN findlib-1.9.1 ═════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00014.html> Gerd Stolpmann announced ──────────────────────── a couple of installation problems slipped into findlib-1.9, mostly missing files in the release tarball, but also a FreeBSD incompatibility. For that reason, there is now findlib-1.9.1 fixing the problems (so far known, and I hope we caught them all). Same link as before: <http://projects.camlcity.org/projects/findlib.html> Conformist 0.2.1 ════════════════ Archive: <https://discuss.ocaml.org/t/ann-conformist-0-2-1/7482/1> jerben announced ──────────────── I am happy to announce the release of conformist 0.2.1. [Conformist] deals with schema definition and validation. It supports decoding to bridge the gap between runtime types and static types without ppx. ┌──── │ type occupation = │ | Mathematician │ | Engineer │ │ type user = │ { occupation : occupation │ ; email : string │ ; birthday : int * int * int │ ; nr_of_siblings : int │ ; comment : string option │ ; wants_premium : bool │ } │ │ let user occupation email birthday nr_of_siblings comment wants_premium = │ { occupation; email; birthday; nr_of_siblings; comment; wants_premium } │ ;; │ │ let occupation_decoder = function │ | "mathematician" -> Ok Mathematician │ | "engineer" -> Ok Engineer │ | _ -> Error "Unknown occupation provided" │ ;; │ │ let occupation_encoder = function │ | Mathematician -> "mathematician" │ | Engineer -> "engineer" │ ;; │ │ let user_schema = │ Conformist.( │ make │ Field. │ [ custom │ occupation_decoder │ occupation_encoder │ "occupation" │ ~meta:() │ ; string "email" │ ; date "birthday" │ ; int ~default:0 "nr_of_siblings" │ ; optional (string "comment") │ ; bool "wants_premium" │ ] │ user) │ ;; │ │ let input = │ [ "occupation", [ "engineer" ] │ ; "email", [ "test@example.com" ] │ ; "birthday", [ "2020-12-01" ] │ ; "nr_of_siblings", [ "3" ] │ ; "comment", [ "hello" ] │ ; "wants_premium", [ "true" ] │ ] │ │ let user = │ Conformist.decode Schema.user_schema input │ │ let validation_errors = │ Conformist.validate Schema.user_schema input └──── The `user_schema' and the `user' create function are guaranteed to be in sync at compile time. [Conformist] <https://github.com/oxidizing/conformist> Compiler Explorer now supports OCaml 4.12.0 ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-compiler-explorer-now-supports-ocaml-4-12-0/7479/3> Continuing this thread, Sora Morimoto announced ─────────────────────────────────────────────── Today we deployed 4.12.0 flambda. It must already be available! Annoucement of OFLAT, a web-based platform to support courses on Formal Languages and Automata Theory ═════════════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00026.html> Antonio Ravara announced ──────────────────────── <http://ctp.di.fct.unl.pt/FACTOR/OFLAT/> To support students’ autonomous work on topics related with Formal Languages and Automata Theory (FLAT), interactive tools that allow them to experiment with examples and solve exercises are very important - several studies demonstrate this. There are applications with this aim. While some are impressively complete, but are mainly Desktop applications (like JFLAP), others that can be used via a web browser are under-developed. Moreover, these applications are often not fully interactive - illustrations or even step-by-step execution is key to understand the algorithms - and, due to the programming languages used, implement the concepts in a way quite distant from the textbook Mathematical definitions. Code that implements closely the definitions is also a relevant pedagogical tool. With three concerns in mind - availability in mobile devices, interactive run of the algorithms (or at least presenting clear explanations), and code following closely the definitions - we developed OFLAT, a web-based tool to represent and illustrate graphically classical mechanisms and algorithms of Formal Languages and Automata Theory. It includes not only exercises evaluated automatically and providing feedback, but also allows students to create their own exercises. An integration with a grading platform like Learn-OCaml is underway. The tool is implemented in OCaml and is organised in two parts: a library - OCamlFLAT - which concentrates the logic of FLAT concepts, and the interactive applicational part - OFLAT. To run on browsers, the application uses the OCaml to Javascript translator Js_of_OCaml. To implement the interactive graphics, it uses Cytoscape, a Javascript library for graphs. All code is available in the Git of the project: <https://gitlab.com/releaselab/leaf/OCamlFlat>, <https://gitlab.com/releaselab/leaf/OFLAT>. The development of new functionalities is ongoing (we're now working more animations and on Context-Free Grammar and Pushdown Automata). Comments most welcome. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 21239 bytes --]
[-- Attachment #1: Type: text/plain, Size: 21208 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 23 to 30, 2021. Table of Contents ───────────────── Theorem Proving with Coq and Ocaml ocaml-aws 1.2 Release of `fmlib.0.2.0' soupault: a static website generator based on HTML rewriting Timere-parse 0.0.2, natural language parsing of date, time and duration ocamlnet-4.1.9 Release of cohttp 4.0.0 New Try-Alt-Ergo website Other OCaml News Old CWN Theorem Proving with Coq and Ocaml ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/theorem-proving-with-coq-ocaml/7524/1> Gregory Malecha announced ───────────────────────── I lead the formal methods team at Bedrock Systems (<https://bedrocksystems.com>) and we are looking to hire a full-time engineer working on automation in the Coq proof assistant (which is written in Ocaml). We're very interested in candidates with strong Ocaml background especially in topics related to automated theorem proving, e.g. SAT/SMT solvers, datalog, superposition, resolution, etc. While Coq experience is great, you do not need to be a Coq expert to apply to this position, we're happy to marry your Ocaml expertise with our Coq expertise. Formal methods are at the core of BedRock's business and we are deeply committed to solving problems of system verification at industrial scale. We get FM techniques and insights into the code early on and use them to build, maintain, and evolve code. This includes developing more agile techniques to keep evolving verified systems once they're built. We have eight folks on the formal methods team today, hailing from MPI-SWS, MIT CSAIL, Princeton, and other leading research groups. If you're interested, send me an email or you can inquire more broadly at jobs@bedrocksystems.com. *Company overview:* BedRock is building a *trustworthy compute base for mission-critical applications* . The foundation of the platform is an open source, multi-core, capability-based micro-hypervisor that we are developing and verifying. On top of these deep specifications we are writing and verifying applications to provide an extensible and configurable core. Our contention is that the *time is ripe for verifiably trustworthy systems*, for everything from secure phones and industrial IoT to autonomous systems and financial infrastructure. With significant seed funding, great investors, and commercial projects underway, we are growing our team in Boston, the Bay Area, DC, and Germany. ocaml-aws 1.2 ═════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-aws-1-2/7526/1> Tim Mc Gilchrist announced ────────────────────────── I'm pleased to announce the release of [ocaml-aws] 1.2. ocaml-aws aims to provide generated bindings to many AWS services using the botocore specifications. In this version we've bumped version bounds on a bunch of depedencies and also added new bindings for: • RDS • Route53 • SDB • SQS Please check it out and report any issues. [ocaml-aws] <https://opam.ocaml.org/packages/aws/> Release of `fmlib.0.2.0' ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-fmlib-0-2-0/7527/1> Hbr announced ───────────── I am pleased to announce the second release (0.2.0) of fmlib, a functional library with managed effects. The library has up to now 4 components: • [Some standard datatypes] • [Pretty printing functions] • [Parsing combinator library] • [Primitives to compile to javascript] The last component is the new one in version 0.2.0. Internally it uses `js_of_ocaml' to compile to javascript. It is an easy to use library of primitive functions to access mainly browser functionality from ocaml and some rudimentary functions to access nodejs functionality. It can be installed via opam by ┌──── │ opam update │ opam install fmlib │ opam install fmlib_js └──── It is located at [github] [Some standard datatypes] <https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_std/index.html> [Pretty printing functions] <https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_pretty/Print/index.html> [Parsing combinator library] <https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_parse/index.html> [Primitives to compile to javascript] <https://hbr.github.io/fmlib/odoc/fmlib_js/index.html> [github] <https://github.com/hbr/fmlib> Hbr added ───────── Hint: `fmlib' is still a bundle of three libraries i.e. three toplevel modules `Fmlib_std', `Fmlib_pretty' and `Fmlib_parse'. Therefore they have to be used in a `dune' file with ┌──── │ (libraries fmlib.fmlib_std fmlib.fmlib_pretty fmlib.fmlib_parse ...) └──── while the new library can be used with ┌──── │ (libraries fmlib_js ...) └──── This inconvenience will be corrected in the next release. 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/14> Daniil Baturin announced ──────────────────────── [soupault 2.5.0] offers some features that are unique among SSGs. There are two new built-in widgets for rewriting internal links, which is useful if you don't host your website at the server root. For example, if you host it at `example.com/~user', you cannot just write `<img src="/header.png">': it will point to `example.com/header.png' while you want `example.com/~user/header.png' instead. The `relative_links' widget will convert all internal links to relative links according to their depth in the directory tree. For example, suppose you have `<img src="/header.png">' in your page template. Then in `about/index.html' that link will become `<img src="../header.png">'; in `books/magnetic-fields/index.html' it will be `<img src="../../header.png">' and so on. This way you can move the website to a subdirectory and it will still work. The `absolute_links' widget prepends a prefix to every internal link. Conceptually similar to the site URL option in other SSGs and CMSes, but works for all links, not only links generated by the SSG itself. [soupault 2.5.0] <https://soupault.app/blog/soupault-2.5.0-release/> Timere-parse 0.0.2, natural language parsing of date, time and duration ═══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-timere-parse-0-0-2-natural-language-parsing-of-date-time-and-duration/7532/1> Darren announced ──────────────── I'm happy to announce the release of Timere-parse 0.0.2, the natural language parsing component of Timere, a date time handling and reasoning library. Both packages are under the [Timere repo]. Timere-parse allows interpretation of common descriptions of date, time and duration. [Timere repo] <https://github.com/daypack-dev/timere> Date time examples ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Input strings are in `""', indented lines are pretty printed output. ┌──── │ "2020 jun 6 10am" │ Ok 2020-06-06T10:00:00Z │ "2020 jun 6th 10:15" │ Ok 2020-06-06T10:15:00Z │ "Australia/Sydney 2020 jun 6 10am" │ Ok 2020-06-06T10:00:00+10:00 │ "01-06-2020 10:10" │ Ok 2020-06-01T10:10:00Z │ "2020/06/01 10am" │ Ok 2020-06-01T10:00:00Z │ "jul 6 2021 9:15am" │ Ok 2021-07-06T09:15:00Z │ "2020/06/01" │ Ok 2020-06-01T00:00:00Z └──── Duration examples ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ┌──── │ "24h" │ Ok 1 days 0 hours 0 mins 0 secs │ "16.5 hours" │ Ok 16 hours 30 mins 0 secs │ "1h20min" │ Ok 1 hours 20 mins 0 secs │ "1 hour 2.5 minutes" │ Ok 1 hours 2 mins 30 secs │ "100 seconds" │ Ok 1 mins 40 secs │ "2.25 minutes 1 seconds" │ Ok 2 mins 16 secs │ "5 days 6.5 hours" │ Ok 5 days 6 hours 30 mins 0 secs └──── Timere object examples ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ┌──── │ "2020 jun" │ Ok (pattern (years 2020) (months Jun)) │ "jan" │ Ok (pattern (months Jan)) │ jan 6 12pm to 2pm" │ Ok (bounded_intervals whole (duration 366 0 0 0) (points (pick mdhms Jan 6 12 0 0)) (points (pick hms 14 0 0))) │ "12th, 13 to 15, 20" │ Ok (pattern (month_days 12 13 14 15 20)) │ "16th 7:30am" │ Ok (pattern (month_days 16) (hours 7) (minutes 30) (seconds 0)) │ "16th 8am to 10am, 11am to 12pm" │ Ok (inter (pattern (month_days 16)) (union (bounded_intervals whole (duration 1 0 0 0) (points (pick hms 8 0 0)) │ (points (pick hms 10 0 0))) (bounded_intervals whole (duration 1 0 0 0) (points (pick hms 11 0 0)) (points (pick hms │ 12 0 0))))) │ "2020 jun 16th 10am to jul 1 12pm" │ Ok (bounded_intervals whole (duration 366 0 0 0) (points (pick ymdhms 2020 Jun 16 10 0 0)) (points (pick mdhms Jul │ 1 12 0 0))) └──── Corpus ╌╌╌╌╌╌ For the full corpus/examples, see [corpus/] for code and [corpus-outputs/] for generated outputs. [corpus/] <https://github.com/daypack-dev/timere/tree/main/corpus> [corpus-outputs/] <https://github.com/daypack-dev/timere/blob/main/corpus-outputs> ocamlnet-4.1.9 ══════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00028.html> Gerd Stolpmann announced ──────────────────────── there is now ocamlnet-4.1.9 available: • compatibility with upcoming OCaml-4.12 • some fixes regarding TLS (https) • a few build-related details See the project page for download, documentation, a detailed changelog, and the mailing list: <http://projects.camlcity.org/projects/ocamlnet.html> The repository is at <https://gitlab.com/gerdstolpmann/lib-ocamlnet3/> opam follows soon. Release of cohttp 4.0.0 ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537/1> Marcello Seri announced ─────────────────────── We are glad to announce the [upcoming release] of [`cohttp 4.0.0'], a low-level OCaml library for HTTP clients and servers. This release comes with a big update of the documentation and the examples, both in the [README] and in the codebase, and improvements and bug fixes from many contributors 🙇 which you will find listed below. A huge thank you to all the people that helped to get this release ready by raising issues, participating in discussions, sending PRs, and otherwise using our library. [upcoming release] <https://github.com/ocaml/opam-repository/pull/18385> [`cohttp 4.0.0'] <https://github.com/mirage/ocaml-cohttp> [README] <https://github.com/mirage/ocaml-cohttp> The future of cohttp ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ To quote @avsm from [another post] The development process […] is driven by a simple principle that is inspired by OCaml itself: don't needlessly break backwards compatibility without good reason, and when it is necessary, justify it. Our tools are embedded in projects that have lifespans measured in the decades, and we take compatibility seriously. That’s why we take pains to provide migration paths […] that are as invisible as possible. Since in this release we have decided to include a number of fixes and improvements which modified Cohttp module signatures, we decided to signal the potential breackage by bumping the major version of the library. In most cases, however, you don't need to do anything and your code will keep working with the latest cohttp. Moving forward, we have agreed to start working on the API and the internals of cohttp to modernize it and get it ready for multicore support and also for eventual unification with the h2 stack that offers HTTP2/3 support. To be able to move forward and avoid stalling improvements for months, we will be less shy of major releases. However, to remain true to the principle above, we will be careful to introduce one breakage at a time, carefully justify its need and provide a clear upgrade path in the changelog. The version history is: • cohttp 2.5.5: security backports (changelog below) • cohttp 3.0.0: skipped (explained below) • cohttp 4.0.0: the next release (changelog below) • cohttp 5.0.0: will include a long-awaited change in [how headers are treated]: which fixes a multitude of past issues and simplifies the internals of the module. For the people that need stability, *we have decided to keep backporting important security fixes to the `2.5.x' branch of the project*. In fact, `cohttp 2.5.5', released just a few days ago was the first release with the backport of a security issue. [another post] <https://discuss.ocaml.org/t/defining-standard-ocaml-development-lifecycle-processes/7486/5> [how headers are treated] <https://github.com/mirage/ocaml-cohttp/pull/747> What happened to 3.0.0? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The release of `cohttp 3.0.0' has been long awaited, and we are extremely grateful to @dinosaure for the enormous work that went into designing and implementing `conduit 3.0.0' and `cohttp 3.0.0' (part of which remained in `4.0.0' as bug fixes and API improvements). However, a discussion started soon after the release pointing out that there could be further room of improvement also with the new design, particularly with respect to backwards compatibility. Since the design discussion did not reach consensus, these changes were reverted to preserve better compatibility with existing cohttp users and `cohttp 3.0.0' was [marked as unavailable] on the opam repository. As maintainers, our "lesson learnt" is to not do releases incrementally when they span multiple libraries: we were caught in an awkward spot when conduit 3 was released, but without cohttp 3. The work on the new conduit is steadily progressing and will be integrated in a new major release of cohttp in the future, once we will be confident that the API is settled. If you want to try using it immediately, then it is available as the [mimic] library in ocaml-git. [marked as unavailable] <https://github.com/mirage/ocaml-cohttp/issues/736> [mimic] <https://github.com/mirage/ocaml-git/tree/master/src/mimic> Change Log ╌╌╌╌╌╌╌╌╌╌ v4.0.0 ┄┄┄┄┄┄ • cohttp.response: fix malformed status header for custom status codes (@mseri @aalekseyev #752) • remove dependency to base (@samoht #745) • add GitHub Actions workflow (@smorimoto #739) • `cohttp-lwt-jsoo': Forward exceptions to caller when response is null (@mefyl #738) • Use implicit executable dependency for generate.exe (@TheLortex #735) • cohttp: update HTTP codes (@emillon #711) • cohttp: fix chunked encoding of empty body (@mefyl #715) • cohttp-async: fix body not being uploaded with unchunked Async.Pipe (@mefyl #706) • cohttp-{async, lwt}: fix suprising behaviours of Body.is_empty (@anuragsoni #714 #712 #713) • refactoring of tests (@mseri #709, @dinosaure #692) • update documentation (@dinosaure #716, @mseri #720) • fix deadlock in logging (@dinosaure #722) • improve media type parsing (@seliopou #542, @dinosaure #725) • [reverted] breaking changes to client and server API to use conduit 3.0.0 (@dinosaure #692). However, as the design discussion did not reach consensus, these changes were reverted to preserve better compatibility with existing cohttp users. (#741, @samoht) *Potentially breaking changes* • remove `wrapped false' from the codebase (@rgrinberg #734) • cohttp: add Uti.t to uri scheme (@brendanlong #707) • cohttp-lwt-jsoo: rename Cohttp_lwt_xhr to Cohttp_lwt_jsoo for consistency (@mseri #717) • cohttp: fix transfer-encoding ordering in headers (@mseri #721) • lower-level support for long-running cohttp-async connections (@brendanlong #704) • add of_form and to_form functions to body (@seliopou #440, @mseri #723) • cohttp-lwt: partly inline read_response, fix body stream leak (@madroach @dinosaure #696). Note: there is a new warning that may show up in your logs when bodies are leaked, see also [#730]. • add comparison functions for Request.t and Response.t via ppx_compare (@msaffer-js @dinosaure #686) [#730] <https://github.com/mirage/ocaml-cohttp/issues/730> v2.5.5 ┄┄┄┄┄┄ • `Cohttp_async.resolve_local_file', `Cohttp_lwt.resolve_local_file' and `Cohttp_lwt_unix.resolve_file' are now the same code under the hood (`Cohttp.Path.resolve_local_file'). The old names have been preserved for compatibility, but will be marked as deprecated in the next release. This changes the behavior of `Cohttp_lwt_unix.resolve_file': it now percent-decodes the paths and blocks escaping from the docroot correctly. This also fixes and tests the corner cases in these methods when the docroot is empty. (@ewanmellor #755) *Double check your code base for uses of `Cohttp_lwt_unix.resolve_file': it is unsafe with respect to path handling*. If you cannot upgrade to `cohttp 2.5.5', you should modify your code to call `Cohttp_lwt.resolve_local_file' instead. New Try-Alt-Ergo website ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-try-alt-ergo-website/7555/1> OCamlPro announced ────────────────── We are pleased to announce the new version of the [Try Alt-Ergo website]! As a reminder, Try Alt-Ergo allows you to write and run your problems in your browser without any server computation. It was designed to be a powerful and simple tool to use. Updates concern these parts of the site: • A new back end in JavaScript • Front end with news features (Ace editor, top panel, right panel, etc.) Take a look at [our blogpost] to read how we have updated the Try Alt-Ergo website and what's new! You can also visit the [Try Alt-Ergo website] directly. As usual, do not hesitate to report bugs, to ask questions, or to give your feedback. [Try Alt-Ergo website] <https://try-alt-ergo.ocamlpro.com/> [our blogpost] <https://www.ocamlpro.com/2021/03/29/new-try-alt-ergo/> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [New Try-Alt-Ergo] • [TZComet's New Token Viewer] [OCaml Planet] <http://ocaml.org/community/planet/> [New Try-Alt-Ergo] <https://www.ocamlpro.com/2021/03/29/new-try-alt-ergo/> [TZComet's New Token Viewer] <https://seb.mondet.org/b/0012-tzcomet-token-viewer.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 35049 bytes --]
[-- Attachment #1: Type: text/plain, Size: 10885 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 30 to April 06, 2021. Table of Contents ───────────────── Ecosystem Engineer and Technical Writer positions Release of cohttp 4.0.0 Timere-parse 0.0.2, natural language parsing of date, time and duration agrid 0.1 State of OCaml and web assembly containers 3.3 New OCaml books? Old CWN Ecosystem Engineer and Technical Writer positions ═════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-ecosystem-engineer-and-technical-writer-positions/7571/1> Celine announced ──────────────── [Tarides] is hiring an [Ecosystem Engineer] and a [Technical Writer]. Tarides is a tech startup based in Paris and founded in 2018. We develop a software infrastructure platform to deploy secure, distributed applications with strict resource contraints and low-latency performance requirements. We welcome applications from people of all backgrounds. We are working hard to create a representative, inclusive and friendly team, because we know that different experiences, perspectives and backgrounds make for a better place. Please, don't hesitate to contact me if you have any question, I'll be more than happy to reply! :) [Tarides] <https://tarides.com/> [Ecosystem Engineer] <https://tarides.com/jobs/ecosystem-engineer> [Technical Writer] <https://tarides.com/jobs/technical-writer> Release of cohttp 4.0.0 ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537/2> Continuing this thread, Calascibetta Romain said ──────────────────────────────────────────────── The work on the new conduit is steadily progressing and will be integrated in a new major release of cohttp in the future, once we will be confident that the API is settled. If you want to try using it immediately, then it is available as the [mimic ] library in ocaml-git. I just take the opportunity to show up a tutorial about `mimic' which is now available into the distribution of it: see [here]. Thanks for your work about the release process. [mimic ] <https://github.com/mirage/ocaml-git/tree/master/src/mimic> [here] <https://mirage.github.io/ocaml-git/mimic/index.html> Timere-parse 0.0.2, natural language parsing of date, time and duration ═══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-timere-parse-0-0-2-natural-language-parsing-of-date-time-and-duration/7532/2> Continuing this thread, Darren said ─────────────────────────────────── The demo site has been updated to use Timere-parse, you can now try interacting with `Timere_parse.timere' in web browser at <https://daypack-dev.github.io/timere-parse-demo/> agrid 0.1 ═════════ Archive: <https://discuss.ocaml.org/t/ann-agrid-0-1/7587/1> zapashcanon announced ───────────────────── I'm pleased to announce the first release of [agrid]. Agrid stands for *Adjustable Grid*. Adjustable grids are basically two dimensional arrays whose width/height can be changed by adding or removing row/column at either end (one at a time). Here's a very short example : ┌──── │ let () = │ let grid = Agrid.of_list [[1; 2]; [3; 4]] in │ let grid = Agrid.snoc_row grid (Flex_array.of_list [5; 6]) in │ Agrid.pp Format.pp_print_int Format.std_formatter grid │ (* prints: │ * 1; 2 │ * 3; 4 │ * 5; 6 │ *) └──── It's based on the great [flex-array] library by [Jean-Christophe Filliâtre] and is mainly a wrapper around it to make it easier for the special case of two dimensional arrays. It's been developped at [OCamlPro] while working on [mosaic] when we wanted to ease the dataset input process, switching from a basic textarea based input to something which looks like a spreadsheet (this work is not yet published on the online version). [agrid] <https://ocamlpro.github.io/agrid> [flex-array] <https://github.com/backtracking/flex-array> [Jean-Christophe Filliâtre] <https://www.lri.fr/~filliatr/> [OCamlPro] <https://www.ocamlpro.com/> [mosaic] <https://mosaic.univ-lyon1.fr/> gasche asked and zapashcanon replied ──────────────────────────────────── Out of curiosity: In a spreadsheet, I would assume that inserting/removing rows or columns in the middle is also a useful operation. Would you be able to add this operation? It's not really a spreadsheet, it's more something [like this]. I don't think it would be really useful in the case of mosaic because for big inputs, users are more likely to import the data from a file. Anyway, it's possible to add this operation, but I can't think of an efficient way to do it. I'll think about it and may add such an operation. Actually, if it's added to flex-array, it would be trivial to add it to agrid, so I'll probably try to add it there. [like this] <https://www.zapashcanon.fr/~leo/atable/> State of OCaml and web assembly ═══════════════════════════════ Archive: <https://discuss.ocaml.org/t/state-of-ocaml-and-web-assembly/2725/15> Deep in this thread, Emilio Jesús Gallego Arias announced ───────────────────────────────────────────────────────── Yup, we didn't make it yet the "official" release, but it has been used by quite a few people to avoid lack of tail-call optimization in jsoo, live versions: • <https://jscoq.github.io/wa/> • <https://jscoq.github.io/wa/scratchpad.html> It literally flies. I guess @corwin-of-amber is the right person to comment more on his superb efforts. Shachar Itzhaky then added ────────────────────────── Hi there @camarick; ocaml-wasm is very much bleeding-edge but it already works surprisingly well and I have used it to run Coq, esp. for the purpose of making the interactive version of Vols. I,II from the Software Foundations textbook (see <https://jscoq.github.io/ext/sf> and <https://jscoq.github.io/ext/sf/tools/jscoq-tester.html>). Of course @ejgallego is exaggerating when he says that it flies, it still runs OCaml bytecode in interpreted mode on top of the WASM JIT. Performance is pretty reasonable still, except in the case some intensive Coq tactics (in which case this is a third level of interpreter… :man_facepalming: ). The main gap right now is the standard libraries `str', `unix', and `threads', for which I have compiled empty stubs, because dynamic loading of libraries in WASI is still immature. I *have* been able to compile `num' and it works correctly because it does not depend on anything else. I am currently investigating how to build `zarith' (which requires `gmp') because Coq 8.13 depends on it. So yeah, this is not at all the coveted WASM backend for `ocamlc', but it's one existing solution and you can hack on it right now. Any help or comments are welcome! containers 3.3 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-containers-3-3/7594/1> Simon Cruanes announced ─────────────────────── I'm glad to announce the release of containers 3.3. Containers is an extension to OCaml's standard library that strives to be compatible with it, with more features and a few additional modules to get dynamic arrays, heaps, S-expression parser/printer, etc. In this release, we have new support for parsing/printing canonical S-expressions (a simple binary-safe format), a code-generation module for bitfields, and many improvements to existing modules in particular in the interface between maps/set/hashtbl and iterators. More details [in the github release]. Many thanks to the contributors, in particular @Fardale for his work on CI and auto-doc-generation. [in the github release] <https://github.com/c-cube/ocaml-containers/releases/tag/v3.3> New OCaml books? ════════════════ Archive: <https://discuss.ocaml.org/t/new-ocaml-books/5789/6> Deep in this thread, Damien Guichard announced ────────────────────────────────────────────── I’m also working on a free culture book. The preview is at <https://damien-guichard.developpez.com/downloads/Algorithmic-with-OCaml.pdf> It’s under CC-BY-SA. Planned chapters include : Records, Type polymorphism, Modules as functions, Conceptual graphs. The reason why i don't contribute to @dmbaturin's effort is that my main topic is algorithmic, ocaml is more a good way than a goal. Damien Guichard later added ─────────────────────────── Sorry, you have to be a member of <https://www.developpez.com/> to access this link. Here is my 2nd try. I hope you don't need to be a member of <https://www.aeriesguard.com/> this time. <https://www.aeriesguard.com/media/get/504bfbe34d3f517c8acf37ffbe200f84698aca0c/Algorithmic-with-_OCaml.pdf> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 23290 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18195 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 13 to 20, 2021. Table of Contents ───────────────── Preface (initial release) OCaml Users and Developers Workshop 2021 Timere 0.1.3 - Dealing with time and time zones has never been easier Release of `multipart_form.0.2.0' Engineer position for the development of the Squirrel prover Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central Old CWN Preface (initial release) ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-preface-initial-release/7669/1> Xavier Van de Woestyne announced ──────────────────────────────── Hello, @d-plaindoux and @pytre and I are very happy to present *Preface*, a project that has occupied part of our free time for almost 2 years. We received a lot of help from various people (as mentioned in the [CREDITS] page), including some present on this forum (@gasche, @octachron and @snowleopard) Preface is an opinionated library designed to facilitate the handling of recurring functional programming idioms in [OCaml]. Many of the design decisions were made in an attempt to calibrate, as best as possible, to the OCaml language. Trying to get the most out of the module language. *The name "preface" is a nod to "Prelude"* . • [Github repository] • [Online documentation] [CREDITS] <https://github.com/xvw/preface/blob/master/CREDITS.md#warm-thanks-and-help> [OCaml] <https://ocaml.org> [Github repository] <https://github.com/xvw/preface> [Online documentation] <https://ocaml-preface.github.io/preface/Preface/index.html> About the project, and motivation ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ When learning functional programming, one is often confronted with constructs derived (or not) from category theory. Languages such as Haskell offer very complete libraries to use them, and thus, facilitate their learning. In OCaml, it often happens that these abstractions are buried in the heart of certain libraries/projects ([Lwt], [Cmdliner], [Bonsai], [Dune] etc.). This is why one of the objectives of Preface is to propose tools for concretising these abstractions, at least as a pedagogical tool. [Lwt] <https://ocsigen.org/lwt/latest/manual/manual> [Cmdliner] <https://erratique.ch/logiciel/cmdliner> [Bonsai] <https://github.com/janestreet/bonsai> [Dune] <https://dune.build> Is Preface useful ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Since OCaml allows for efficient imperative programming, Preface is probably not really useful for building software. However, we (the maintainers) think that Preface can be useful for a few things: • technical experimentation with abstractions (especially those from the Haskell world) that allow programming in a fun style. • As an educational tool. Many teaching aids generally only offer the minimal interfaces to these abstractions. Preface tries to be as complete as possible. • It was a lot of fun to make. The last point is obviously the lightest but building Preface was really fun! So even if some people won't see the point… *we had fun making it*! Let's imagine this scenario! Oh, there's this article that seems to describe quite precisely how to solve `this complex problem', elegantly, using this `collection of abstractions'. After reading, the article is clear and I know how to use this `collection of abstractions' in practice. I would like to test it. Not having enough RAM to install Cabal, I decided to do it in OCaml. But as one abstraction leads to another, I am obliged to build an armada of things and I abandon my experimentation. So now, rather than doing it, locally, for the understanding of an article, I add it in Preface. Additional links ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The [README] is quite expansive on motivations and some design choices, but we have tried to add some concrete guides: • [ Understanding the module breakdown of Preface] • [Effect handling using Freer] • [Error handling with Result/Validation and a Free Applicative] And in addition here is a project, by a friend of ours, that uses Preface, to build static blog generators (very original isn't it :P), the code is highly documented and can be an entry point into how to use it: [Github repository of the project] [README] <https://github.com/xvw/preface#preface> [ Understanding the module breakdown of Preface] <https://github.com/xvw/preface/blob/master/guides/option_instantiation.md> [Effect handling using Freer] <https://github.com/xvw/preface/blob/master/guides/freer_effect_handling.md> [Error handling with Result/Validation and a Free Applicative] <https://github.com/xvw/preface/blob/master/guides/error_handling.md> [Github repository of the project] <https://github.com/xhtmlboi/wordpress> Conclusion ╌╌╌╌╌╌╌╌╌╌ Preface does not offer much that is new, but we have tried to make it user-friendly and to document as much as possible the code and design choices. It's a lot of fun to build… and it will probably be just as much fun to maintain. *We are extremely open to contributions and feedback.* And my last words will be a warm thank you to the OCaml ecosystem that has facilitated so much of our development: Testing with [Alcotest] and [QCheck] is a pleasure. [Dune] is a fast and pleasant build system. [ODoc] has allowed us to have more control over the generation of documentation, especially with the `@inline' comment (on includes) which allows signatures from different modules to be merged. And [MDX] which I did not know at all and which is used extensively for guides. I hope you can find interest in this project! Good luck with the rest of the containment (for those concerned). [Alcotest] <https://github.com/mirage/alcotest> [QCheck] <https://github.com/c-cube/qcheck> [Dune] <https://dune.build> [ODoc] <https://github.com/ocaml/odoc> [MDX] <https://github.com/realworldocaml/mdx> OCaml Users and Developers Workshop 2021 ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-users-and-developers-workshop-2021/7673/1> Frédéric Bour announced ─────────────────────── It is my pleasure to invite submissions to the OCaml Users and Developers Workshop 2021, which is again co-located with ICFP and will be held virtually this year. The OCaml Users and Developers Workshop brings together industrial users of OCaml with academics and hackers who are working on extending the language, type system, and tools. Previous editions have been co-located with ICFP 2012 in Copenhagen, ICFP 2013 in Boston, ICFP 2014 in Gothenburg, ICFP 2015 in Vancouver, ICFP 2016 in Nara, ICFP 2017 in Oxford, ICFP 2018 in St Louis, ICFP 2019 in Berlin, and was virtual for ICFP 2020, following the OCaml Meetings in Paris in 2010 and 2011. Important Links ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • [https://icfp21.sigplan.org/home/ocaml-2021 ] • [https://ocaml2021.hotcrp.com ] [https://icfp21.sigplan.org/home/ocaml-2021 ] <https://icfp21.sigplan.org/home/ocaml-2021> [https://ocaml2021.hotcrp.com ] <https://ocaml2021.hotcrp.com> Important dates ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Thursday 20th May (any time zone): Abstract submission deadline • Friday 18th July: Author notification • Friday 27th August: OCaml Workshop 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 ╌╌╌╌╌╌╌╌╌╌╌╌╌ Presentations will be held in the online format. Each presentation comprise a prerecorded presentation and an interactive live Q&A session after the talk. Each talk will be re-translated three times in different time zones. Session chairs and volunteers will assist the authors in preparing and casting the presentation. Each presentation will be made available through the ocaml.org website. Submission ╌╌╌╌╌╌╌╌╌╌ To submit a presentation, please register a description of the talk (about 2 pages long) at <https://ocaml2021.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. Camera ready presentations ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ A pre-recorded versions of accepted presentation shall be provided before August, 13th. Volunteers will provide technical assistance to authors as well as provide necessary feedback and ensure that all videos match our quality standards. 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 Commitee ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Frédéric Bour, Tarides, France • Cristina Rosu, Janestreet, UK • Hakjoo Oh, Korea University, Korea • Hugo Heuzard, Janestreet, UK • Jeffrey A. Scofield, Formalsim, USA • Jonathan Protzenko, MSR, USA • Joris Giovanangeli, Ahrefs, Singapore • Jun Furuse, Dailambda, Japan • Kihong Heo, KAIST, Korea • Kate Deplaix, OCaml Labs, UK • Medhi Bouaziz, Nomadic Labs, France • Simon Castellan, INRIA, France • Ryohei Tokuda, Idein, Japan • Vaivaswatha Nagaraj, Zilliqa, India • Youyou Cong, Tokyo Institute of Technology, Japan Questions and contact ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Please contact the PC Chair ([Frédéric Bour]) for any questions. [Frédéric Bour] <mailto:frederic.bour@lakaban.net> Timere 0.1.3 - Dealing with time and time zones has never been easier ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-timere-0-1-3-dealing-with-time-and-time-zones-has-never-been-easier/7173/2> Darren announced ──────────────── Timere 0.2.1 has landed! This release adds nanosecond precision support to timere (and fractional second support at various places), along with other small improvements. Release of `multipart_form.0.2.0' ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-multipart-form-0-2-0/7704/1> Calascibetta Romain announced ───────────────────────────── I am pleased to announce the release of [`multipart_form']. Throughout the development of [mrmime], we have gained a thorough knowledge of the RFCs about email. However, these RFCs also describe mechanisms that are found in HTTP/1.1. [`multipart_form'] <https://github.com/dinosaure/multipart_form> [mrmime] <https://github.com/mirage/mrmime> Genesis ╌╌╌╌╌╌╌ More specifically, a lot of work has been done on [RFC 2045] & [RFC 2046] (see [RFC 7578 § 4]) which describe the `multipart' format (found in emails and in `HTTP/1.{0,1}' requests when serializing a `<form>'). From this work (~ 2 years), we decided to extract the parts allowing to manipulate a `multipart/form-data' content for `HTTP/1.{0,1}' responses (plus [RFC 2183]). This resulted in the creation of `multipart_form'. This project is a cross between what many users have been waiting for (for [CoHTTP] and [http/af]), a knowledge of what exists and its limitations, and finally a development in the spirit of MirageOS. The result is an API that is _"full stream"_. Indeed. a question arose from the beginning, how to manipulate this format while: • not having access to a file system (MirageOS) • not exploding memory usage for file uploads [RFC 2045] <https://tools.ietf.org/html/rfc2045> [RFC 2046] <https://tools.ietf.org/html/rfc2046> [RFC 7578 § 4] <https://tools.ietf.org/html/rfc7578#section-4> [RFC 2183] <https://tools.ietf.org/html/rfc2183> [CoHTTP] <https://github.com/mirage/ocaml-cohttp> [http/af] <https://github.com/inhabitedtype/httpaf> Memory bound implementation ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ With the help of @Armael and the [`memtrace'] tool, we were able to implement and extend `multipart_form' so that it is easier to use and really ensures our original assumption about memory consumption. So we experimented with use cases like uploading very large files. Here is the result that `memtrace' gives us with a 100Mb file: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/92ee2ab6fa1d4da62d894749aa4b161a95b53fb2_2_1034x590.png> The application tries to save the games in files. We use [opium] (and thus http/af) but tests were also done with CoHTTP. The code is available [here] for people who want to reproduce. [`memtrace'] <https://blog.janestreet.com/finding-memory-leaks-with-memtrace/> [opium] <https://github.com/rgrinberg/opium> [here] <https://gist.github.com/dinosaure/299c421c95cec4255df7b9289eb53815> Documentation & encoding ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Finally, a major effort has been made in the documentation to explain in detail how to use `multipart_form'. Version `0.2.0' also adds a way to produce a `multipart/form-data' document (experimental) with the same constraints on memory usage. I hope this work will be useful to a lot of people. The documentation is available [here]. [here] <https://dinosaure.github.io/multipart_form/multipart_form/index.html> Engineer position for the development of the Squirrel prover ════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-04/msg00022.html> David Baelde announced ────────────────────── We are looking for an engineer to support the development of Squirrel, an interactive theorem prover for security protocols. The position will be funded by ERC POPSTAR. You may find more details here: <https://people.irisa.fr/Stephanie.Delaune/internship/sujet-engineer-squirrel.pdf> Skilled OCaml developers would be most welcome! Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central ═════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/martin-jambon-presentation-on-semgrep-wed-april-21-7pm-central/7709/1> Claude Jager-Rubinson announced ─────────────────────────────── Please join us this coming Wednesday at 7pm Central when @mjambon will talk about Semgrep, an open-source ployglot static analysis tool written in OCaml. Details and connection info are available at [Houston Functional Programmers]. [Houston Functional Programmers] <https://hfpug.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 30654 bytes --]
[-- Attachment #1: Type: text/plain, Size: 26103 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 20 to 27, 2021. Table of Contents ───────────────── docs.ocaml.pro : an OCaml Documentation Hub Decompress 1.4.0 elliptic curves - maintainable and verified (full stack, from primitives to TLS) First release of Docteur, an opiniated read-only file-system for MirageOS Ocaml-solidity, a new OCaml library for Solidity Migrating to floatarray (blog post) Old CWN docs.ocaml.pro : an OCaml Documentation Hub ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-docs-ocaml-pro-an-ocaml-documentation-hub/7718/1> Fabrice Le Fessant announced ──────────────────────────── We are pleased to announce that we just published the first version of the OCaml Documentation Hub on: <https://docs.ocaml.pro> The OCaml Documentation Hub can be used to browse the sources and the documentations of more than 2000 opam packages, following links between them when useful. This is a work-in-progress, and we are working on improving it with many more features, such as source annotations with types, full-text and type-driven searches, improvements in the general readability of documentation, etc. The site is generated using an open-source tool called digodoc, available on: <https://github.com/OCamlPro/digodoc> Digodoc is able to build a map of an opam switch, with links between files, opam packages, ocaml libraries, meta packages and ocaml modules. It is also able to generate documentation using odoc with cross-indexes between all these kinds of packages. We welcome feedback and contributions! Enjoy ! Simon Cruanes said and Anil Madhavapeddy added ────────────────────────────────────────────── Great work on this site, and I love the domain name as well ;-) The cross linking between packages is fantastic. As a bit of background on why documentation cross-linking has taken so long, there is a lonnnggg history intertwined with many people's contributions to opam, build systems (ocamlbuild and dune), conventions (findlib and odig) and of course [odoc] itself. The major milestones along the way have been: • [odoc 1.0], first began in 2014 as a quick project to pull together typing information from cmt[i] files, but which ran into the problem that it needs a consistent set of compiled cmt files to actually work, and so needs help from external tools to pull that set of compiled libraries together. • [odig], which pulls together multiple opam packages (and a filesystem layout for metadata) and runs odoc on then. This allowed for the creation of <https://docs.mirage.io> a few years ago which cross-references a smaller number of packages • opam-repo itself has had better and better bulk builds over the years to ensure that we can actually automatically compile all the artefacts needed for docs builds, thanks to efforts like [health check] and [ocurrent]. • odoc 2.0, which featured a multi-year [rewrite] of the OCaml module resolver and introduced a new [output IR]. This forthcoming release was presented in this [OCaml 2020 talk] by @jonludlam. And now with all these pieces in place, the OCaml documentation spring has arrived! The OCamlPro one posted here as the first of the "new batch" of mass documentation indexers, and I'm aware of concurrent efforts by the odoc/ocaml.org maintainer teams to push a central one out to ocaml.org, as well as by the MirageOS team who are refreshing docs.mirage.io with the latest and greatest. I'm sure when the dust has settled on all these indexers we can look for common pieces, but for now it's lovely to see so much innovation happening at pace. For the community: now is the time to fix your docstrings in your libraries, as there will many cool tools parsing and processing them, and rendering them into all kinds of output formats! To the [odoc contributors], thank you! The journey to get to this documentation site started here seven years ago: ┌──── │ commit ef91571cab31d9ece7af965ed52eaaff57a12efc │ Author: Leo White <lpw25@cl.cam.ac.uk> │ Date: Thu Oct 16 19:20:18 2014 +0100 │ │ Initial commit └──── @lefessan one thing I'm not sure about in your site is the "copyright library authors" claim. That's murky legal ground – it's worth establishing if the odoc HTML has gone through a compilation process and so is no longer copyright the authors (just as a binary output is not copyright the original source code). If the output _is_ copyright the authors, then they have reasonable grounds to claim that you should also reproduce the copyright notice and other license restrictions. Personally, I prefer to claim that there is no copyright to the original authors in odoc output, and sidestep this issue. [odoc] <https://github.com/ocaml/odoc> [odoc 1.0] <https://github.com/ocaml/odoc> [odig] <https://github.com/dbuenzli/odig> [health check] <https://github.com/ocurrent/opam-health-check> [ocurrent] <https://github.com/ocurrent/overview> [rewrite] <https://github.com/ocaml/odoc/pull/439> [output IR] <https://github.com/ocaml/odoc/pull/423> [OCaml 2020 talk] <https://www.youtube.com/watch?v=wVyZ-KveN-w&t=3s> [odoc contributors] <https://github.com/ocaml/odoc/graphs/contributors> Fabrice Le Fessant replied ────────────────────────── Thanks @avsm , all these projects were indeed important milestones towards the creation of this site. However, I wouldn't want this history perspective to give the wrong feeling that building this site was easy, it is the result of a very good, long and hard work by the team at OCamlPro to make it work despite a road paved with many obstacles. It also benefited from OCamlPro's long history of innovative projects for the OCaml community, that lead for example in the past to Opam, [Try-OCaml], Memprof/[Memthol,] [Opam-builder], [Learn-OCaml], the Typerex tools (ocp-indent, ocp-index, ocp-build, etc.) and more recently [opam-bin] and [drom]. As I said, this is a work-in-progress, and there are many features that we will be adding in the next months to make this website much easier to navigate, for users to rapidely reach the information that matters for them. We hope it will be inspirational for all the other developers who are working on similar projects, and we are looking forward to using their projects soon too! [Try-OCaml] <https://try.ocamlpro.com/> [Memthol,] <https://www.ocamlpro.com/2020/12/01/memthol-exploring-program-profiling/> [Opam-builder] <https://hal.inria.fr/hal-01352008> [Learn-OCaml] <https://github.com/ocaml-sf/learn-ocaml> [opam-bin] <https://github.com/OCamlPro/opam-bin> [drom] <https://github.com/OCamlPro/drom/> Daniel Bünzli said ────────────────── I'd just like to stress that `odig' documents OCaml package installs regardless of the package manager used as long the install structure follows [these conventions] (which are automatically followed by [dune installs]) . Also for people using my packages, I'd just like to mention they may miss important documentation bits on [https://docs.ocaml.pro] until [that issue] is resolved. [these conventions] <https://erratique.ch/software/odig/doc/packaging.html> [dune installs] <https://dune.readthedocs.io/en/stable/opam.html#odig-conventions> [https://docs.ocaml.pro] <https://docs.ocaml.pro/> [that issue] <https://github.com/OCamlPro/digodoc/issues/33> Much later in the thread, Kiran Gopinathan said ─────────────────────────────────────────────── It's not quite the same as hoogle, but merlin has a functionality to search for functions by type signature - the feature doesn't seem to get much attention apparently - probably the interface is a little lacking, but with some extra elisp tuning, it can work quite smoothly: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/3/3c2d1c63fac7cbd7dd1bb5b9a406589e031cb795.gif> Yawar Amin then added ───────────────────── The command line for this: ┌──── │ ocamlmerlin single search-by-polarity -position 0 -query '-int +string' └──── (To search for values of type `int -> string'.) Decompress 1.4.0 ════════════════ Archive: <https://discuss.ocaml.org/t/ann-decompress-1-4-0/7724/1> Charles Edouard Lecat announced ─────────────────────────────── Greetings everyone, ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I am happy to announce the new release of [decompress 1.4.0], available for installation via OPAM. Decompress is a library containing a pure OCaml implementation of several compression algorithms: • RFC1951 • Zlib • Gzip • LZO It's goal is to provide several algorithms for both the inflation and the deflation of objects, in the form of a stream API allowing to call the chosen algorithm one bit at a time. Such behavior allows for an easy use of decompress in situations where we would not be able to have the input in one go, or where we would like to output the result in a non blocking way. This new release comes with several improvements to the documentation and bug fixes, but even more, with a whole new implementation for the rfc 1951 and zlib algorithms. [decompress 1.4.0] <https://github.com/mirage/decompress/releases/tag/v1.4.0> Non-stream implementation for rfc 1951 and zlib ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Up to this day, decompress was used in several projects like ocaml-git. However, as time passed by, it appeared that in some cases, the current implementation of decompress was not the optimal solution: As useful as a stream implementation is, it requires to save a lot of information about the state of the compression, in order to resume it once we have enough input. This is why, in some cases where we would be sure that we have our whole input in one go, we might want to avoid all of these side-costs, and directly go to the point. State of the art: libdeflate ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ This new problematic in mind, we have started thinking about the existing implementations of these algorithms which were also bypassing the stream behavior. One implementation that proved to be a suitable example for our problem, was the library `libdeflate', an implementation in C. It's main advantages being: a better compression ratio than zlib and with faster runtime. It was used as the solid base for the OCaml implementation provided by this new release. OCaml version of libdeflate, performances and use cases ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Inheriting the logic of libdeflate, the new implementation now has a better compression ratio, while being slightly faster at it. On the other side, the decompression is way faster, with `33% of speed increase in most tested cases: On the ~book2' (from the Calgary corpus) file: • `decompress' (stream): 15 Mb/s (deflation), 76 Mb/s (inflation), ratio: 42.46 % • `decompress' (non-stream): 17 Mb/s (deflation), 105 Mb/s (inflation), ratio: 34.66 % Now that this is in place, the users of decompress will be able to choose between the two versions, according to their needs. In the case of ocaml-git, the vast majority of the git objects are small and will be compressed in one go. This is why we updated with the new implementation when possible. Writing optimized code and profiling it ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ One of the biggest concerns of this release was to be able to produce optimized code. The base code being coded in C, a lot of sub-optimal behavior where ported in the OCaml version: `for' and `while' loops, references everywhere, mixes of `struct' and `union.', it needed a lot of clean up. This is why once the main iteration was done, we have spent several weeks profiling the code base, using the OCaml library `landmarks', `flamegraph' or simply the linux binary `perf'. This work, sometimes tedious, proved to be helpful and healthy for both the harmonization of the code and it's performances. Decompress & MirageOS ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Compression algorithms are a really important piece in many projects, and operating systems do not avoid this. `decompress' was coded from the start with the idea of being used in the much larger project MirageOS. This release is another opportunity to broaden MirageOS’s reach, by providing one more algorithm to it’s stack, allowing us to specialise even more the unikernels that would have a need for inflation/deflation algorithms. This more restrictive implementation, as we need to have the whole input in one go, will allow us to take advantage of the situation and give more flexibility for the user. The positive aspects of this release will most likely show up soon enough, as we make use of decompress to its full potential elliptic curves - maintainable and verified (full stack, from primitives to TLS) ════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-elliptic-curves-maintainable-and-verified-full-stack-from-primitives-to-tls/7729/1> Hannes Mehnert announced ──────────────────────── over the last month I worked on upgrading the cryptography stack for OCaml and MirageOS. I just published a [blog post]. Enhancments of [OCaml-TLS] ([usenix security paper from 2015]) and [X.509] are in place. The main achievement after TLS 1.3 support (since May 2020, 0.12.0) is that elliptic curve certificates are now supported. Elliptic curve cryptography uses [fiat]. The X509 implementation now supports PKCS 12 (used by browsers and other software (e.g. OpenVPN) to bundle certificates and private keys). Get mirage-crypto-ec, x509 0.13.0 and tls 0.13.1 (all available in the opam-repository). Discussion and feedback appreciated. [blog post] <https://hannes.robur.coop/Posts/EC> [OCaml-TLS] <https://github.com/mirleft/ocaml-tls> [usenix security paper from 2015] <https://usenix15.nqsb.io> [X.509] <https://github.com/mirleft/ocaml-x509> [fiat] <https://github.com/mit-plv/fiat-crypto> First release of Docteur, an opiniated read-only file-system for MirageOS ═════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-docteur-an-opiniated-read-only-file-system-for-mirageos/7743/1> Calascibetta Romain announced ───────────────────────────── I'm glad to announce the first release of [`docteur'], a simple tool to make and use (in read-only) a "file-system" for [MirageOS]. As you know, with MirageOS, we don't have _sockets_, _kernel space_ or even _file-descriptor_. It's not possible to manipulate files _standalonely_ and many _primitives_ commonly available with the `unix' module don't exists in our space. Therefore, it is difficult to imagine making a website that displays local files or a database system. But in our spirit of separation of services, it becomes possible for your unikernel to communicate over the network to a "file system" or a database. For quite some time we have been experimenting with a file system external to our unikernel called Git. This is the case of [`pasteur'] which saves the pastes in a Git repository. It is also the case of [`unipi'] or [Canopy] which display the content of a Git repository and can resynchronize with it using a hook. Or the case of [our primary DNS server] whose zone file comes from a Git repository - we can then trace all the changes on this file. However, we have several limitations: 1) it requires the Git repository to load into memory in your unikernel 2) it requires a communication (external with GitHub or internal in a private network) The persistent aspect is very important. We should always be able to launch a unikernel and not lose the data if our system shuts down. The mutable aspect (modify a file) is useful in some cases but not in others. As for `unipi' for example (a simple static web site), the difference between resynchronizing with a hook or restarting the unikernel with a new version of your filesystem is minor. [`docteur'] <https://github.com/dinosaure/docteur> [MirageOS] <https://mirage.io/> [`pasteur'] <https://github.com/dinosaure/pasteur> [`unipi'] <https://github.com/roburio/unipi> [Canopy] <https://github.com/Engil/Canopy> [our primary DNS server] <https://github.com/roburio/dns-primary-git> Docteur as a second solution ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This is where Doctor comes in. It solves both of our problems by offering the generation of a file system from scratch: • a Git repository (local or available on a service) • a specific folder Doctor is able to create a complete representation of a folder and to compress it at such a ratio that a generation of the documentation of several OPAM packages with all their versions making 14 Gb is reduced to an image of only 280 Mb! Such a high compression ratio is in particular due to a double level of compression by [`decompress'] and [`duff']. For more details, Docteur just generates a slightly modified PACK file with [carton]. Then, Docteur proposes a simple library which makes available 2 ways to manipulate this image for your unikernel: 1) a way that is fast but with a consequent boot time 2) a slower way but with no cost to the boot time The first way will simply "analyze" the image to re-extract the layout of your file system. Then it uses the [ART data-structure] to save this layout. So, whenever you want a specific file and according to [ART benchmarks], you have access to the content very quickly. The problem remains the analysis which takes place at boot time and which can take a very long time (it depends essentially on the number of files you have). There can also be an impact on memory usage as the ART data structure is in memory - the more files there are, the bigger the structure is. The second method is more "silly". Each time you request a file, we will have to rebuild the entire path and therefore deserialize several objects (like folders). The advantage is that we don't analyze the image and we don't try to maintain a layout of your file system. [`decompress'] <https://github.com/mirage/decompress> [`duff'] <https://github.com/mirage/duff> [carton] <https://github.com/mirage/ocaml-git/tree/master/src/carton> [ART data-structure] <https://github.com/dinosaure/art> [ART benchmarks] <https://dinosaure.github.io/art/bench/find.html> Example ╌╌╌╌╌╌╌ Docteur is meant to be simple. The generation of the image is done very simply by the command `make': ┌──── │ $ docteur.make -b refs/heads/main https://github.com/dinosaure/docteur disk.img │ $ docteur.make -b refs/heads/main git@github.com:dinosaure/docteur disk.img │ $ docteur.make -b refs/heads/main git://github.com/dinosaure/docteur disk.img │ $ docteur.make -b refs/heads/main file://$(pwd)/dev/docteur disk.img └──── Then, Docteur proposes 2 supports: Unix & [Solo5]. For Unix, you just have to name explicitly the image file to use. For the case of Solo5 (and thus of virtualization). You just have to find a name for a "block device" and to reuse this name with the Solo5 "tender" specifying where the image is. ┌──── │ $ cd unikernel │ $ mirage configure -t unix --disk disk.img │ $ make depends │ $ mirage build │ $ ./simple --filename README.md └──── ┌──── │ $ cd unikernel │ $ mirage configure -t hvt --disk docteur │ $ make depends │ $ mirage build │ $ solo5-hvt --block:docteur=disk.img -- simple.hvt --filename README.md └──── Finally, Docteur proposes another tool that checks (and analyzes) an image to give you the version of the commit used (if the image comes from a Git repository) or the hash of your file system produced by the calculation of a [Merkle tree]. ┌──── │ $ docteur.verify disk.img │ commit : ad8c418635ca6683177c7ff3b583e1ea5afea78f │ author : "Calascibetta Romain" <romain.calascibetta@gmail.com> │ root : bea10b6874f51e3f6feb1f9bcf3939933b2c4540 │ │ Merge pull request #11 from dinosaure/fix-tree-expanding │ │ Fix how we expand our file-system └──── [Solo5] <https://github.com/Solo5/solo5> [Merkle tree] <https://en.wikipedia.org/wiki/Merkle_tree> Conclusion ╌╌╌╌╌╌╌╌╌╌ Many times people ask me for a purpose in MirageOS such as a website or a particular service. I think that Docteur shows one essential thing about MirageOS, it is a tool and an ecosystem. But it's not an endpoint that is concretized in a specific application. Docteur is not THE solution to our problems and answers a specific use case. What is important to note is not what Docteur does but the possibility for our ecosystem and our tools to allow the development of Docteur. As it allows the development of a trillion applications! As such, I say to those people to "play" with MirageOS if they want to learn more. Our goal is not to show you applications that you could then deploy easily (even if we are working on this aspect too) but to give you the possibility to imagine your OS (independently from our vision)! And if you try, we'll be happy to help you! Ocaml-solidity, a new OCaml library for Solidity ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-solidity-a-new-ocaml-library-for-solidity/7746/1> OCamlPro announced ────────────────── We are pleased to announce our new OCaml library, ocaml-solidity ! [Ocaml-solidity] is a program manipulation library that provides a Solidity parser and typechecker. Our library is made for developers on Solidity code analysis, it builds a typechecked AST that can be analyzed with a provided visitor. Please note that our parser and typecheck conforms mostly to Solidity 0.7, inline assembly is not supported. Take a look at [our documentation]. You can test it and report bugs just [here]! [Ocaml-solidity] <https://github.com/OCamlPro/ocaml-solidity> [our documentation] <https://ocamlpro.github.io/ocaml-solidity/> [here] <https://github.com/OCamlPro/ocaml-solidity/issues> Migrating to floatarray (blog post) ═══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/migrating-to-floatarray-blog-post/7749/1> Nicolás Ojeda Bär announced ─────────────────────────── At LexiFi we recently migrated our codebase to use `floatarray' in place of `float array' in order to disable the "flat float array" mode in the compiler. If you are interested in finding out more about how we did it, we wrote a blog post about it <https://www.lexifi.com/blog/ocaml/floatarray-migration/>. Enjoy! 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 38337 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6297 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 27 to May 04, 2021. Table of Contents ───────────────── Ocaml-solidity, a new OCaml library for Solidity Release of ocaml-pandoc 0.1.0 Stdlib vs Containers vs Batteries vs Base : Core functions comparison Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central ocaml-lsp-server 1.6.0 Other OCaml News Old CWN Ocaml-solidity, a new OCaml library for Solidity ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-solidity-a-new-ocaml-library-for-solidity/7746/2> Continuing the thread from last week, Fabrice Le Fessant announced ────────────────────────────────────────────────────────────────── I should add that the project is now available in the opam-repository, see [solidity-parser] and [solidity-typechecker]. [solidity-parser] <https://opam.ocaml.org/packages/solidity-parser/> [solidity-typechecker] <https://opam.ocaml.org/packages/solidity-typechecker/> Release of ocaml-pandoc 0.1.0 ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-ocaml-pandoc-0-1-0/7759/1> Samuel Mimram announced ─────────────────────── I have just released [ocaml-pandoc], a native OCaml library to write filters for [pandoc], which is a markdown-to-anything converter. It has allowed me to write some simple filters I needed (such as for including code snippets, which is not supported natively). The support is not complete yet however, I might add more if needed (and pull-requests are of course accepted :slight_smile:). [ocaml-pandoc] <https://github.com/smimram/ocaml-pandoc> [pandoc] <https://pandoc.org/> Stdlib vs Containers vs Batteries vs Base : Core functions comparison ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/stdlib-vs-containers-vs-batteries-vs-base-core-functions-comparison/7766/1> Jp R announced ────────────── You want to compare the main core functions found in the OCaml Stdlib (v4.12.0), Containers (v3.3), Batteries (v3.3.0) and Base (v0.14.1) libraries ? Check it out ! <https://github.com/Fourchaux/ocaml-stdlib-containers-batteries-base-comparisons> Vladimir Keleshev then added ──────────────────────────── Someone reading this might be also interested in my (less formal) comparison between OCaml Stdlib and Base: <https://gist.github.com/keleshev/764edad011a6a7a40da11716b19ddb75> Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central ═════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/martin-jambon-presentation-on-semgrep-wed-april-21-7pm-central/7709/5> Claude Jager-Rubinson announced ─────────────────────────────── The recording of Martin's talk is now available: <https://hfpug.org/2021/05/01/martin-jambon-9-languages-how-we-built-semgrep-a-polyglot-static-analysis-tool/> Martin Jambon then added ──────────────────────── Thanks Claude! The talk [starts at 1:45]. [starts at 1:45] <https://www.youtube.com/watch?v=H6TgK-LMA4Y&t=105s> Ryan Slade then said ──────────────────── [Comby] may also be of interest, it's a similar project also written in OCaml. [Comby] <https://comby.dev/> ocaml-lsp-server 1.6.0 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-6-0/7774/1> Rudi Grinberg announced ─────────────────────── On behalf of the ocaml-lsp team, I'd like to announce version 1.6.0 of ocaml-lsp-server. The highlight of this release is the updated version of merlin which brings lots of new bug fixes. 1.6.0 (04/30/2020) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Features ┄┄┄┄┄┄┄┄ • Code action to annotate a value with its type (#397) Fixes ┄┄┄┄┄ • Fix interface/implementation switching on Windows (#427) • Correctly parse project paths with spaces and other special characters that must be escaped. • Print types with `-short-paths' even if the project wasn't built yet Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Cryptography updates in OCaml and MirageOS] [OCaml Planet] <http://ocaml.org/community/planet/> [Cryptography updates in OCaml and MirageOS] <https://hannes.nqsb.io/Posts/EC> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 17101 bytes --]
[-- Attachment #1: Type: text/plain, Size: 27361 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 04 to 11, 2021. Table of Contents ───────────────── Software engineer position at LexiFi (Paris) Open source editor for iOS, iPadOS and macOS Backend developer position at Issuu (Copenhagen) 25 years of OCaml OCaml compiler development newsletter, issue 1: before May 2021 After so many years, I discover 'Str.bounded_full_split regexp str n' Parser for the Scala programming language? Old CWN Software engineer position at LexiFi (Paris) ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-software-engineer-position-at-lexifi-paris/7782/1> Alain Frisch announced ────────────────────── [LexiFi] is hiring! We are looking for a fully-time software engineer to join our core development team. The vast majority of our stack is implemented in OCaml, and we have plenty of exciting projects on a wide range of topics. More info on <https://www.lexifi.com/careers/software_engineer/> [LexiFi] <https://www.lexifi.com> Open source editor for iOS, iPadOS and macOS ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/open-source-editor-for-ios-ipados-and-macos/7624/15> Continuing this thread, Nathan Fallet announced ─────────────────────────────────────────────── Just updated the editor, I redesigned the macOS version, and it just looks better and more native <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/6/6b03c462755fb37a2d5018013c3d1c8bd45f53bf_2_1380x766.jpeg> What are your first impressions on it? Backend developer position at Issuu (Copenhagen) ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-backend-developer-position-at-issuu-copenhagen/7793/1> Dario Teixeira announced ──────────────────────── We are looking for a Backend Developer with experience in machine learning – and preferably also OCaml! – to join our Research & Development team. You will help build machine learning research prototypes and be responsible for integrating them into new and existing products. At Issuu, we use OCaml extensively in our production systems. If you love OCaml and functional programming in general, Issuu is a great place to put your passion into real-world products! Please find more information about this position at the following link: <https://jobs.lever.co/issuu/f502cb20-b216-4c67-8357-d748e1b35178> Anentropic asked and Dario Teixeira replied ─────────────────────────────────────────── I would love to hear more about your OCaml backend stack Well, we love to talk about our OCaml stack! :slightly_smiling_face: We rely on the Jane Street ecosystem a lot, using Core as a Stdlib replacement and Async for monadic concurrency. AMQP forms the backbone of our messaging system, and therefore we use [amqp-client] extensively. We use both MySQL and Postgresql databases in production. For the former we use [ppx_mysql], and for the latter, [PGOCaml]. (Thanks to Docker, we can give PGOCaml compile-time access to the DB without having to depend on the actual production DB.) We currently use Protobuf for serialisation, but spend a great amount of time complaining about it. We rely on [ocaml-protoc-plugin] to generate the OCaml code from Protobuf definitions. Anyway, that's just the basics of our stack. Do let me know if there's something else you'd like to know in more detail! [amqp-client] <https://github.com/andersfugmann/amqp-client> [ppx_mysql] <https://github.com/issuu/ppx_mysql> [PGOCaml] <https://github.com/darioteixeira/pgocaml> [ocaml-protoc-plugin] <https://github.com/issuu/ocaml-protoc-plugin> roddy asked and Dario Teixeira replied ────────────────────────────────────── Do you use Protobuf for interop with non-OCaml systems? If not, I'm curious about whether you've considered [bin_prot] as an alternative; it seems like an obvious choice if you're using Core/Async. Yes, we use Protobuf mainly because we have a heterogeneous stack, where besides OCaml we also have services running Python, Kotlin, or Elixir. [bin_prot] <https://github.com/janestreet/bin_prot/blob/master/README.md> Tim McGilchrist asked and Dario Teixeira ──────────────────────────────────────── I'm curious about how you structure the business code (for want of a better word), in between the technical layers of talking to AMQP or an SQL store. Are there larger scale patterns like CQRS or DDD that you use to organise code? How do you package up code for deployment? Docker / AWS something. We're slowly migrating to a micro-service architecture (the pros and cons of which are outside the scope of this thread; that's a can of worms I'd rather not open…) whose cast of characters includes "entities" (responsible for storing/retrieving data from DBs), generic backend services that encapsulate business logic, frontend services, and backend-for-frontend services. We're using Docker for deployment on AWS (mostly), and slowly migrating from Docker Swarm to Kubernetes. 25 years of OCaml ═════════════════ Archive: <https://discuss.ocaml.org/t/25-years-of-ocaml/7813/1> Xavier Leroy announced ────────────────────── 25 years ago, on May 9th 1996, release 1.00 of the Objective Caml language and system was announced: <https://sympa.inria.fr/sympa/arc/caml-list/1996-05/msg00003.html> It was already the consolidation of many years of work, integrating Jérôme Vouillon and Didier Rémy's work on objects and classes within Caml Special Light, itself a combination of my work on modules and native-code compilation with earlier code taken from Caml Light, especially Damien Doligez's GC. Little did I know that O(bjective) Caml would still be there 25 years later! A lot happened during this time, including several major evolutions of the language, and, much more importantly, the emergence of a community of users and an ecosystem of tools and libraries. But maybe this was just the beginning for something even bigger? We'll see… Happy birthday, OCaml! David Allsopp replied ───────────────────── Most pleasingly, with a [very small number of patches], the Windows port still works in Visual Studio 2019: ┌──── │ C:\Birthday>ocaml.exe │ Objective Caml version 1.00 │ │ #print_endline "Happy 25th Birthday, OCaml!";; │ Happy 25th Birthday, OCaml! │ - : unit = () │ ##quit;; │ │ C:\Birthday>type hooray.ml │ let rec hip_hip n = │ if n > 0 then │ let () = print_endline "hip hip! hooray!" in │ hip_hip (pred n) │ │ let () = hip_hip 25 │ C:\Birthday>ocamlopt -o hooray.exe hooray.ml │ │ C:\Birthday>hooray │ hip hip! hooray! │ ... └──── [very small number of patches] <https://github.com/dra27/ocaml/commits/25-years-of-ocaml> On the OCaml Maling List, Roberto Di Cosmo also replied ─────────────────────────────────────────────────────── Long live OCaml! Thanks Xavier, and to all the brilliant minds that contributed to the evolution and adoption of this beautiful language, and system, in this past quarter of a century. If I may add a personal note, one truly remarkable fact is that some rather complex code written in 1998 using OCaml 1.07 [1] could be compiled and run last year using OCaml 4.x *without modifications*: the only visible changes were the new warnings spotting potential issues in the code, thanks to the many improvements to the compiler over time. For the curious, all the details are here: <https://www.dicosmo.org/Articles/2020-ReScienceC.pdf> Cheers Roberto [1] that was the first version including support for marshalling closures, added in a fantastic one week-spring in Pisa exactly for this code :-) OCaml compiler development newsletter, issue 1: before May 2021 ═══════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-1-before-may-2021/7831/1> gasche announced ──────────────── I'm happy to introduce the first issue of the "OCaml compiler development newsletter". I asked frequent contributors to the OCaml compiler codebase to write a small burb on what they have been doing recently, in the interest of sharing more information on what people are interested in, looking at and working on. This is by no means exhaustive: many people didn't end up having the time to write something, and it's fine. But hopefully this can give a small window on development activity related to the OCaml compiler, structured differently from the endless stream of [Pull Requests] on the compiler codebase. (This initiative is inspired by the excellent Multicore newsletter. Please don't expect that it will be as polished or consistent :yo-yo: .) Note: • Feel free of course to comment or ask questions, but I don't know if the people who wrote a small blurb will be looking at the thread, so no promises. • If you have been working on the OCaml compiler and want to say something, please feel free to post! If you would like me to get in touch next time I prepare a newsletter issue (some random point in the future), please let me know by email at (gabriel.scherer at gmail). [Pull Requests] <https://github.com/ocaml/ocaml/pulls> @dra27 (David Allsopp) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Compiler relocation patches now exist. There's still a few left to write, and they need splitting into reviewable PRs, but the core features are working. A compiler installation can be copied to a new location and still work, meaning that local switches in opam may in theory be renamed and, more importantly, we can cache previously-built compilers in an opam root to allow a new switch's compiler to be a copy. This probably won't be reviewed in time for 4.13, although it's intended that once merged opam-repository will carry back-ports to earlier compilers. A whole slew of scripting pain has lead to some possible patches to reduce the use of scripts in the compiler build to somewhat closer to none. FlexDLL bootstrap has been completely overhauled, reducing build time considerably. This will be in 4.13 (#[10135]) [10135] <https://github.com/ocaml/ocaml/pull/10135> @nojb (Nicolás Ojeda Bär) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I am working on #[10159], which enables debug information in `-output-complete-exe' binaries. It uses [incbin] under Unix-like system and some other method under Windows. [10159] <https://github.com/ocaml/ocaml/pull/10159> [incbin] <https://github.com/graphitemaster/incbin> @gasche (Gabriel Scherer) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I worked on bringing more PRs to a decision (merge or close). The number of open PRs has gone from 220-ish to 180, which feels nice. I have also contributed to @Ekdohibs' project [camlboot], which is a "bootstrap-free" implementation of OCaml able to compile the OCaml compiler itself. It currently targets OCaml 4.07 for various reasons. We were able to do a full build of the OCaml compiler, and check that the result produces bootstrap binaries that coincide with upstream bootstraps. This gives extremely strong confidence that the OCaml bootstrap is free from "trusting trust" attacks. For more details, see our [draft paper]. [camlboot] <https://github.com/Ekdohibs/camlboot> [draft paper] <http://gallium.inria.fr/~scherer/drafts/camlboot.pdf> with @Octachron (Florian Angeletti) ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ I worked with Florian Angeletti on deprecating certain command-line warning-specifier sequences, to avoid usability issues with (new in 4.12) warning names. Before `-w -partial-match' disables warning 4, but `-w -partial' is interpreted as the sequence `w -p -w a -w r -w t -w i -w a -w l', most of which are ignored but `-w a' silences all warnings. Now multi-letter sequences of "unsigned" specifiers (`-p' is signed, `a' is unsigned) are deprecated. (We first deprecated all unsigned specifiers, but Leo White tested the result and remarked that `-w A' is common, so now we only warn on multi-letter sequences of unsigned specifiers. I am working with @Octachron (Florian Angeletti) on grouping signature items when traversing module signatures. Some items are "ghost items" that are morally attached in a "main item"; the code mostly ignores this and this creates various bugs in corner cases. This is work that Florian started in September 2019 with #[8929], to fix a bug in the reprinting of signatures. I only started reviewing in May-September 2020 and we decided to do sizeable changes, he split it in several smaller changes in January 2021 and we merged it in April 2021. Now we are looking are fixing other bugs with his code (#[9774], #[10385]). Just this week Florian landed a nice PR fixing several distinct issues related to signature item grouping: #[10401]. [8929] <https://github.com/ocaml/ocaml/pull/8929> [9774] <https://github.com/ocaml/ocaml/pull/9774> [10385] <https://github.com/ocaml/ocaml/pull/10385> [10401] <https://github.com/ocaml/ocaml/pull/10401> @xavierleroy (Xavier Leroy) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I fixed #[10339], a mysterious crash on the new Macs with "Apple silicon". This was due to a ARM (32 and 64 bits)-specific optimization of array bound checking, which was not taken into account by the platform-independent parts of the back-end, leading to incorrect liveness analysis and wrong register allocation. #[10354] fixes this by informing the platform-independent parts of the back-end that some platform-specific instructions can raise. In passing, it refactors similar code that was duplicating platform-independent calculations (of which instructions are pure) in platform-dependent files. I spent quality time with the Jenkins continuous integration system at Inria, integrating a new Mac Mini M1. For unknown reasons, Jenkins ran the CI script in x86-64 emulation mode, so we were building and testing an x86-64 version of OCaml instead of the intended ARM64 version. A bit of scripting later (8b1bc01c3) and voilà, arm64-macos is properly tested as part of our CI. Currently, I'm reading the "safe points" proposal by Sadiq Jaffer (#[10039]) and the changes on top of this proposed by Damien Doligez. It's a necessary step towards Multicore OCaml, so we really need to move forward on this one. It's a nontrivial change involving a new static analysis and a number of tweaks in every code emitter, but things are starting to look good here. [10339] <https://github.com/ocaml/ocaml/pull/10339> [10354] <https://github.com/ocaml/ocaml/pull/10354> [10039] <https://github.com/ocaml/ocaml/pull/10039> @mshinwell (Mark Shinwell) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I did a first pass of review on the safe points PR (#[10039]) and significantly simplified the proposed backend changes. I've also been involved in discussions about a new function-level attribute to cause an error if safe points (including allocations) might exist within a function's body, to make code that currently assumes this robust. There will be a design document for this coming in due course. I fixed the random segfaults that were occurring on the RISC-V Inria CI worker (#[10349]). In Flambda 2 land we spent two person-days debugging a problem relating to Infix_tag! We discovered that the code in OCaml 4.12 onwards for traversing GC roots in static data ("caml_globals") is not correct if any of the roots are closures. This arises in part because the new compaction code (#[9728]) has a hidden invariant: it must not see any field of a static data root more than once (not even via an Infix_tag). As far as we know, these situations do not arise in the existing compiler, although we may propose a patch to guard against them. They arise with Flambda 2 because in order to compile statically-allocated inconstant closures (ones whose environment is partially or wholly computed at runtime) we register closures directly as global roots, so we can patch their environments later. [10039] <https://github.com/ocaml/ocaml/pull/10039> [10349] <https://github.com/ocaml/ocaml/pull/10349> [9728] <https://github.com/ocaml/ocaml/pull/9728> @garrigue (Jacques Garrigue) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I have been working on a number of PRs fixing bugs in the type system, which are now merged: • #[10277] fixes a theoretical bug in the principality of GADT type inference (#[10383] applies only in -principal mode) • #[10308] fixes an interaction between local open in patterns and the new syntax for introducing existential type variables • #[10322] is an internal change using a normal reference inside of a weak one for backtracking; the weak reference was an optimization when backtracking was a seldom used feature, and was not useful anymore • #[10344] fixes a bug in the delaying of the evaluation of optional arguments • #[10347] cleans up some code in the unification algorithm, after a strengthening of universal variable scoping • #[10362] fixes a forgotten normalization in the type checking algorithm Some are still in progress: • #[10348] improves the way expansion is done during unification, to avoid some spurious GADT related ambiguity errors • #[10364] changes the typing of the body of the cases of pattern-matchings, allowing to warn in some non-principal situations; it also uncovered a number of principality related bugs inside the the type-checker Finally, I have worked with Takafumi Saikawa (@t6s) on making the representation of types closer to its logical meaning, by ensuring that one always manipulate a normalized view in #[10337] (large change, evaluation in progress). [10277] <https://github.com/ocaml/ocaml/pull/10277> [10383] <https://github.com/ocaml/ocaml/pull/10383> [10308] <https://github.com/ocaml/ocaml/pull/10308> [10322] <https://github.com/ocaml/ocaml/pull/10322> [10344] <https://github.com/ocaml/ocaml/pull/10344> [10347] <https://github.com/ocaml/ocaml/pull/10347> [10362] <https://github.com/ocaml/ocaml/pull/10362> [10348] <https://github.com/ocaml/ocaml/pull/10348> [10364] <https://github.com/ocaml/ocaml/pull/10364> [10337] <https://github.com/ocaml/ocaml/pull/10337> @let-def (Frédéric Bour) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ For some time, I have been working on new approaches to generate error messages from a Menhir parser. My goal at the beginning was to detect and produce a precise message for the ‘let ;’ situation: ┌──── │ let x = 5; │ let y = 6 │ let z = 7 └──── LR detects an error at the third ‘let’ which is technically correct, although we would like to point the user at the ‘;’ which might be the root cause of the error. This goal has been achieved, but the prototype is far from being ready for production. The main idea to increase the expressiveness and maintainability of error context identification is to use a flavor of regular expressions. The stack of a parser defines a prefix of a sentential form. Our regular expressions are matched against it. Internal details of the automaton does not leak (no reference to states), the regular language is defined by the grammar alone. With appropriate tooling, specific situations can be captured by starting from a coarse expression and refining it to narrow down the interesting cases. Now I am focusing on one specific point of the ‘error message’ development pipeline: improving the efficiency of ‘menhir –list-errors’. This command is used to enumerate sentences that cover all erroneous situations (as defined by the LR grammar). On my computer and with the OCaml grammar, it takes a few minutes and quite a lot of RAM. Early results are encouraging and I hope to have a PR for Menhir soon. The performance improvement we are aiming for is to make the command almost real time for common grammars and to tackle bigger grammars by reducing the memory needs. For instance, in the OCaml case, the runtime is down from 3 minutes to 2–3 seconds and memory consumption goes from a few GiB down to 200 MiB. Daniel Bünzli asked and gasche replied ────────────────────────────────────── > […] @Ekdohibs’ project [camlboot ], which is a “bootstrap-free” > implementation of OCaml able to compile the OCaml compiler itself. It currently targets OCaml 4.07 for various > reasons. We were able to do a full build of the OCaml compiler, and check that the result produces bootstrap > binaries that coincide with upstream bootstraps. This gives extremely strong confidence that the OCaml bootstrap is > free from “trusting trust” attacks. For more details, see our [draft paper]. Something that is not clear to me (but I read quickly) is the impact of `guile` itself being not bootstrapped yet. Could there be a *very* elaborate attack (with probability 0 of existing) on both the guile and ocaml bootstrap or is there something in the whole scheme that prevents it ? Yes, currently Guile needs to be trusted, and it would be possible that a bootstrapping virus in Guile would break our correctness result. (It would need to reproduce itself through our compiler and interpreter that were written after Guile itself, but I think in theory this could be done with an almost-infinitely clever program analysis.) Of course, an attack at the source level (inserting malicious source, instead of malicious binaries) is also possible anywhere in the chain. Our main reason for using Guile is that this is the high-level language community most active on debootstrapping-towards-the-metal (through the Guix connection), so we believe it is more likely to manage debootstrapping and maintain it in the longer run. (The seed that Guile depends on is its macro-expander, which is written using macros itself. In theory one may perform the macro-expansion of the expander, and then manually review the two versions to verify the absence of attack there.) [camlboot ] <https://github.com/Ekdohibs/camlboot> [draft paper] <http://gallium.inria.fr/~scherer/drafts/camlboot.pdf> After so many years, I discover 'Str.bounded_full_split regexp str n' ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/after-so-many-years-i-discover-str-bounded-full-split-regexp-str-n/7838/1> UnixJunkie said ─────────────── This is so useful and powerful: ┌──── │ #require "str";; │ Str.bounded_full_split (Str.regexp "[()]") "toto (titi, tata (et tutu)) vont au parc (en courant)" 1024;; │ - : Str.split_result list = │ [Str.Text "toto "; Str.Delim "("; Str.Text "titi, tata "; Str.Delim "("; │ Str.Text "et tutu"; Str.Delim ")"; Str.Delim ")"; Str.Text " vont au parc "; │ Str.Delim "("; Str.Text "en courant"; Str.Delim ")"] └──── Still finding hidden pearls in the stdlib after so many years! :slight_smile: Parser for the Scala programming language? ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/parser-for-the-scala-programming-language/7541/18> Deep in this thread, Yoann Padioleau announced ────────────────────────────────────────────── I ended up porting the recursive descent parser in the Scala compiler to OCaml … I think it was the fastest way to get a working parser from OCaml … <https://github.com/returntocorp/pfff/blob/develop/lang_scala/parsing/Parser_scala_recursive_descent.ml> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 43022 bytes --]
[-- Attachment #1: Type: text/plain, Size: 16462 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 18 to 25, 2021. Table of Contents ───────────────── Applied PL research at Jane Street IRC channels available on libera.chat B Trees in Ocaml via Fmlib 0.3.0 GitHub Actions for OCaml: now stable and on the ocaml org Set up OCaml 2.0.0-alpha FrontC 4.1.0 (Vingt ans après) Old CWN Applied PL research at Jane Street ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-applied-pl-research-at-jane-street/7877/1> Yaron Minsky announced ────────────────────── This isn't exactly news, but we're (still) actively looking to hire people to do applied PL research, with a particular focus on type-level work. Follow this link if you want to see how to apply. <https://blog.janestreet.com/applied-PL-research/> Please share it around with anyone who you think might be on the market! *About the job* Part of our ambition is to grow OCaml into a language that does an ever better job of being convenient and expressive by default, while allowing for the kind of precise control you need when building high performance systems, where it's needed. That's led us to do research on stack-allocation, unboxed types, algebraic effects, type-level resource tracking, and more. We think it's an exciting direction for the language, and there's a lot of challenging and novel work to be done, and the main thing that could speed us up is having more of the right people to work on it! Jane Street is an excellent laboratory for this kind of work: big enough to have serious and demanding use-cases, but small and nimble enough to be able to try out new language features, and then back out of them or change them in incompatible ways if need be. And all the work we do on the compiler is in the open, with the goal of getting the final results into a state where they can be upstreamed. Also, it's a great team! Full of serious experts who have collectively contributed a lot to OCaml and PL research over the years, and also a really nice set of people to work with. And I think the team has a good balance of the practical and theoretical: working hard to do the right thing, but also finding practical ideas that can make forward progress in the near term. *Who are we looking for* We're looking for people with a good balance of theoretical and engineering backgrounds, since the work is demanding on both fronts. We're happy to hire people at a range of experience levels: people who have just finished a post-doc or PhD, up to experienced academics and people in industry. The team has a presence in New York and London, and we're hiring in both offices. No remote work, I'm afraid. IRC channels available on libera.chat ═════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-05/msg00022.html> Adrien Nader announced ────────────────────── Due to the recent troubles on freenode[1][2], I've connected to irc.libera.chat early in order to create and register the same channels that I know and take care ofa on freenode (i.e. #ocaml and #ocaml-fr). I am not stating libera.chat is better than freenode.net although the amount of staffers moving makes me think freenode.net will not be running fine for a much longer time. At the moment I believe it is better to keep both channels running and to encourage people to connect on libera.chat too. In the future, I might force migration by progressively silencing the channel that should be abandoned. If you maintain a relay bot, can you please add it on libera.chat too? As far as I know, there is no Matrix bridge available currently. It seems the discussion/process for bridge additions occurs at [3]. A good news is that I've gotten the full rights on the channel, something which was requiring paperwork on freenode (which I had already mentioned but never got around to doing and for which I never even remotely got time for). [1] <https://lwn.net/Articles/856543/> (this still constantly changes) [2] <https://en.wikipedia.org/wiki/Freenode#2021_ownership_change_and_conflict> [3] <https://github.com/matrix-org/matrix-appservice-irc/issues/208> B Trees in Ocaml via Fmlib 0.3.0 ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/b-trees-in-ocaml-via-fmlib-0-3-0/7880/1> Hbr announced ───────────── I am pleased to announce the release (0.3.0) of fmlib, a functional library with managed effects. The main new feature of release 0.3.0 are B trees. B trees can be used to implement finite sets and finite maps. Fmlib's B trees have functionality similar to the modules `Set' and `Map' of the standard library. The modules `Set' and `Map' of the standard library are based on AVL trees. B trees offer the same functionality but have on modern processors a better cache performance and have better data locality. The current B tree implementation in `Fmlib' implements B trees by using arrays which are guaranteed to fit into a cache line. The design of B trees is described [here]. The API can be found [here]. The library `Fmlib' has four main components: • [Standard Datatypes]: This component offers some modules from `Stdlib' with additional functionality. E.g. `Fmlib_std.Array' offers functions to insert elements into arrays, remove elements from an array and binary search in a sorted array. It has the modules `Result' and `Option' which can be used to avoid exceptions and use exceptions in a more structured way. The modules `Result' and `Option' in `Fmlib' offer a complete monadic interface and offer the `let*' operator to write well readable monadic code. • [Pretty Printing]: Print tree like structures in a nice way and use the library completely functional. The library does not assume a specific IO method. The pretty printer generates a lazy stream of characteres which can be written by all io functions. • [Combinator Parsing]: Easily parse textual input by the use of combinators. The library supports indentation sensitivity and can therefore be used to parse yaml files, haskell, python, etc. Furthermore no input method is assumed. The generated parsers are sink of tokens (or characters). You can choose any input method and push the tokens/characters into the parsers. The generated parsers are fully incremental. Parser can be stored at any position of the input stream and in case of interactive editing, parsing can be resumed from any point of the stream. • [Interface to Javascript]: This components contains primitives to interface to javascript via `js_of_ocaml'. `Fmlib' can be installed via opam: ┌──── │ opam update │ opam install fmlib │ opam install fmlib_std │ opam install fmlib_pretty │ opam install fmlib_parse │ opam install fmlib_js └──── The source code of the library is located at [github] [here] <https://fmlib_ocaml.readthedocs.io> [here] <https://hbr.github.io/fmlib/odoc/fmlib_std> [Standard Datatypes] <https://hbr.github.io/fmlib/odoc/fmlib_std> [Pretty Printing] <https://hbr.github.io/fmlib/odoc/fmlib_pretty> [Combinator Parsing] <https://hbr.github.io/fmlib/odoc/fmlib_parse> [Interface to Javascript] <https://hbr.github.io/fmlib/odoc/fmlib_js> [github] <https://github.com/hbr/fmlib> GitHub Actions for OCaml: now stable and on the ocaml org ═════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/github-actions-for-ocaml-now-stable-and-on-the-ocaml-org/7889/1> Anil Madhavapeddy announced ─────────────────────────── I [announced a beta] of OCaml/opam support for GitHub Actions back in Nov 2019, and the functionality has turned out to be popular. A number of projects in our community have been using the Action, and it can be found in the [GitHub Marketplace]. It has been sufficiently popular that it's definitely time to get it off my personal GitHub account, and so I have transferred it to its new home at <https://github.com/ocaml/setup-ocaml>. I am also very pleased to announce that @smorimoto and @dra27 are also now maintainers – they have both made significant improvements to it, and @smorimoto in particular has been working with the GitHub ecosystem to further improve the efficiency of the Action (such as by adding reliable caching). Thank you to them both and [all the other contributors] for your help improving the CI experience around OCaml. If anyone else wishes to contribute to improving the action, please do get involved on [the issue tracker]. And of course, if you are still referencing `avsm/setup-ocaml' in your own workflow definition, this is a good time to change it to `ocaml/setup-ocaml'. This is probably a good time to note that the other [ci-scripts] repository on the ocaml/ GitHub organisation is in sore need of either new maintainers (for the Travis CI), or being retired due to lack of support (primarily due to the shift to GitHub Actions). I'm immensely grateful to Travis CI for the decade of mostly free builds they have provided our community to date. [announced a beta] <https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745> [GitHub Marketplace] <https://github.com/marketplace/actions/set-up-ocaml> [all the other contributors] <https://github.com/ocaml/setup-ocaml/graphs/contributors> [the issue tracker] <https://github.com/ocaml/setup-ocaml/issues> [ci-scripts] <https://github.com/ocaml/ocaml-ci-scripts> Set up OCaml 2.0.0-alpha ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-alpha/7895/1> Sora Morimoto announced ─────────────────────── This is the announcement of the first alpha release of setup-ocaml v2. This includes quite a few changes, including reliable cache, as described in a recent [post]. There are so many changes, so I would like to list only the notable changes. (The full changelog can be found at the bottom of the post.) [post] <https://discuss.ocaml.org/t/github-actions-for-ocaml-now-stable-and-on-the-ocaml-org/7889> The "ocaml-version" input is now named "ocaml-compiler" ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This was changed because calling it "OCaml Version" is not appropriate enough, e.g. to use the new variant naming convention introduced from 4.12. 32 bits compiler support ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Semver-style version matching support ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ With the naughty exception of `4.02.2' , point releases are meant to be strictly compatible, so once OCaml dev team release a new point release, upgrading should be a no-brainer. With that in mind, it's obviously not smart to rewrite every workflow every time a new point release is released, so you can now specify versions in the style like `4.12.x'. Reliable cache feature ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The action supports not only the compiler cache, but also the [dune cache]. However, note that it is not available on the macOS runners until opam 2.0.9 is released. The dune cache is actually quite powerful for large projects, if you're interested in it, check out the comparison section of [ocaml/setup-ocaml#66]. The reliable cache feature uses the [@actions/cache] package internally, and I worked with the GitHub team to make it fast enough for setup-ocaml to be up to 4x faster. For the Ubuntu runners, you can set up your environment with cache in about 30~40 seconds at the fastest. [dune cache] <https://github.com/ocaml/dune/blob/2.8.5/doc/caching.rst> [ocaml/setup-ocaml#66] <https://github.com/ocaml/setup-ocaml/pull/66> [@actions/cache] <https://github.com/actions/toolkit/tree/main/packages/cache> Automatic pinning and depext handling of local packages ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ For example, if you have a very large number of local packages, like the [Irmin] project, it can be quite a pain for a human to have to write a script to pin them all in your workflow. The action pins and depext the local packages if they exist in the repository by default. You can also use the glob pattern to select which local packages to handle, as described [here]. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-alpha> [Irmin] <https://github.com/mirage/irmin> [here] <https://github.com/ocaml/setup-ocaml/blob/master/examples.md#using-glob-patterns-to-filter-local-packages> FrontC 4.1.0 (Vingt ans après) ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-frontc-4-1-0-vingt-ans-apres/7906/1> Ivan Gotovchits announced ───────────────────────── More than twenty years after its original release [FrontC] is still alive and getting new updates. Mostly it started with my frustration with its Makefiles that ended up in switching to menhir and dune and adding cram tests that finally enabled us to safely touch the grammar definitions and introduce a few c99 … c11 language features as well as more GNU extensions. Our end goal is to get a robust and easy-to-use C parser that is capable of taking a C program on a modern Linux distribution and get it parsed into a C abstract tree. It is not that trivial as it may sound as modern C library headers (especially GNU libc) use non-standard or standard but very modern C features, and most of the OCaml parsers that I have seen are still unable to parse them, including parsers from FramaC, C11parser, and even compcert parser (mostly they do not handle complex floating-point types and various extension types and some GCC attributes). Therefore, FrontC is still useful, especially if all that you want is to start doing program analysis with minimal initial effort, just do (but wait until it is [merged]) ┌──── │ opam install FrontC └──── and start hacking! With that said, FrontC is mostly maintained at leisure time by volunteers, so the pull requests are very welcome. [FrontC] <https://github.com/BinaryAnalysisPlatform/FrontC> [merged] <https://github.com/ocaml/opam-repository/pull/18736> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 27729 bytes --]
[-- Attachment #1: Type: text/plain, Size: 30677 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 25 to June 01, 2021. Table of Contents ───────────────── Dream — a simple, yet feature-complete Web framework Ocaml developer at Routine, Paris, Remote OK Feather 0.2.0 BAP 2.3.0 Release Building Ahrefs codebase with Melange Lwt 5.4.1 Other OCaml News Old CWN Dream — a simple, yet feature-complete Web framework ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/dream-a-simple-yet-feature-complete-web-framework/7909/1> Anton Bachin announced ────────────────────── I am pleased to announce [*Dream*], a very easy-to-use Web framework with high performance, secure defaults, and thorough documentation! <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/3/3384d2a4557f6ab17b585711a47e4f6c90a77652.png> It is available now from opam, with `opam install dream'. Dream offers: • [WebSockets] and [GraphQL]. • A [template syntax], which you can see in the image above. • Trivial [HTTPS and HTTP/2 support], allowing simple deployments without a proxy. • [Sessions] with pluggable [back ends]. • Easy [secure cookies] and [CSRF-safe forms]. …and more, yet Dream sticks to a simple programming model: • Web apps are just [bare functions] from requests to responses. • [Middlewares] are just higher-order wrapper functions. • [Routes] tell the [router] which of these functions to call. Indeed, for those who like algebra, there is a certain [structure] to Dream. However, that's not the point of this post! Dream is meant to be very easy to understand. It sticks to base types, introducing only a few types of its own, and uses existing languages, such as HTML for templates, and URLs for routes. Dream itself is one module in one opam package, which lives in a monorepo. The [docs] are on one page. Dream is loosely coupled. Even though Dream offers many defaults, it is unopinionated, and you can quickly configure or replace anything. For example, it is easy to [use TyXML] for templates, and Dream happily supports such usage with examples. Security-sensitive features, such as cookies, are arranged so that simple and obvious usage is automatically secure. Wherever security still depends on the Dream app, the docs [highlight] it. Dream has selected a modern [cipher] as a default, supports [key rotation], and offers suggestions for other purposes, such as password hashing. It implements and abstracts away all of the [OWASP] security guidelines that are relevant to its level. Dream is designed for full internationalization. It has a centralized [error handler] that intercepts even lower-level HTTP errors, so that you can decorate them with your app's own error template, and leak no hardcoded strings. Dream's URL encoders [favor] internationalized (UTF-8) URIs, and the router accepts them. Finally, Dream is designed for a wide range of applications, including with or without a proxy, standalone or embedded in larger binaries, and with external static assets or [assets compiled in]. [*Dream*] <https://github.com/aantron/dream> [WebSockets] <https://github.com/aantron/dream/tree/master/example/k-websocket#files> [GraphQL] <https://github.com/aantron/dream/tree/master/example/w-graphql-subscription#files> [template syntax] <https://github.com/aantron/dream/tree/master/example/7-template#files> [HTTPS and HTTP/2 support] <https://github.com/aantron/dream/tree/master/example/l-https#files> [Sessions] <https://github.com/aantron/dream/tree/master/example/b-session#files> [back ends] <https://aantron.github.io/dream/#back-ends> [secure cookies] <https://aantron.github.io/dream/#cookies> [CSRF-safe forms] <https://aantron.github.io/dream/#forms> [bare functions] <https://aantron.github.io/dream/#type-handler> [Middlewares] <https://aantron.github.io/dream/#type-middleware> [Routes] <https://aantron.github.io/dream/#type-route> [router] <https://aantron.github.io/dream/#val-router> [structure] <https://aantron.github.io/dream/#algebra> [docs] <https://aantron.github.io/dream/> [use TyXML] <https://github.com/aantron/dream/tree/master/example/w-tyxml#files> [highlight] <https://github.com/aantron/dream/tree/master/example/7-template#security> [cipher] <https://aantron.github.io/dream/#cryptography> [key rotation] <https://aantron.github.io/dream/#servers> [OWASP] <https://cheatsheetseries.owasp.org/> [error handler] <https://github.com/aantron/dream/tree/master/example/9-error#files> [favor] <https://aantron.github.io/dream/#val-to_percent_encoded> [assets compiled in] <https://github.com/aantron/dream/tree/master/example/w-one-binary#files> Documentation ╌╌╌╌╌╌╌╌╌╌╌╌╌ Dream is very extensively documented. See… • [*Examples*], the first several of which make up a tutorial. Each example is a complete project. • The online [*playground*], which features many of the examples, and is itself a [Dream app]! • The [*API docs*]. In particular, see • Deployment examples for [Heroku], Digital Ocean [with Docker], and Digital Ocean [with systemd], all of which include GitHub Actions scripts and instructions. • Full-stack examples with [js_of_ocaml], [ReScript], and [Melange]. • Examples in [Reason syntax]. • Development [watching] and [live reloading]. [*Examples*] <https://github.com/aantron/dream/tree/master/example#readme> [*playground*] <http://dream.as/ocaml> [Dream app] <https://github.com/aantron/dream/tree/master/example/z-playground> [*API docs*] <https://aantron.github.io/dream/> [Heroku] <https://github.com/aantron/dream/tree/master/example/z-heroku#files> [with Docker] <https://github.com/aantron/dream/tree/master/example/z-docker-esy#files> [with systemd] <https://github.com/aantron/dream/tree/master/example/z-systemd#files> [js_of_ocaml] <https://github.com/aantron/dream/tree/master/example/w-fullstack-jsoo#files> [ReScript] <https://github.com/aantron/dream/tree/master/example/w-fullstack-rescript#files> [Melange] <https://github.com/aantron/dream/tree/master/example/r-fullstack-melange#files> [Reason syntax] <https://github.com/aantron/dream/tree/master/example#reason> [watching] <https://github.com/aantron/dream/tree/master/example/w-fswatch#files> [live reloading] <https://github.com/aantron/dream/tree/master/example/w-live-reload#files> Contributing ╌╌╌╌╌╌╌╌╌╌╌╌ Dream has already received several very helpful [contributions], and more are very welcome! See [`CONTRIBUTING.md']. I must also acknowledge all the people working on Dream's [dependecies] and [prior art]. In particular, Dream relies heavily on the HTTP and WebSocket [servers] primarily by Spiros Eliopoulos (@seliopou) and Antonio Nuno Monteiro (@anmonteiro). Apart from accepting code, docs, and examples, Dream will happily link to: • Blogs and articles, as different people learn best from different presentations. • "Downstream" libraries to use with Dream. For example, Thibaut Mattio (@tmattio) is working on [dream-livereload], a live-reloading middleware for Dream, similar to the [example], which he also contributed! Once dream-livereload is slightly more mature, Dream will link to it from its README. There is also [dream-serve], a live-reloading static site server based on Dream and libuv, which was used to develop the docs. [contributions] <https://github.com/aantron/dream/graphs/contributors> [`CONTRIBUTING.md'] <https://github.com/aantron/dream/blob/master/docs/CONTRIBUTING.md> [dependecies] <https://github.com/aantron/dream/blob/b79b06dd6add32beba6eee6864ce99413634b7b3/dream.opam#L49-L111> [prior art] <https://github.com/aantron/dream#acknowledgements> [servers] <https://github.com/aantron/dream/tree/b79b06dd6add32beba6eee6864ce99413634b7b3/src/vendor> [dream-livereload] <https://github.com/tmattio/dream-livereload> [example] <https://github.com/aantron/dream/tree/master/example/w-live-reload#files> [dream-serve] <https://github.com/aantron/dream-serve> Roadmap ╌╌╌╌╌╌╌ Dream is currently in an alpha state. It is thought (by me) to be internally quite stable. However, there will probably be various API tweaks before release 1.0.0. My current, rough plan is to release several alphas of Dream over six months or so. The releases will address: 1. Flow control for very large responses, and getting the "advanced" part of the I/O API to be as close to zero-copy and non-allocating as possible (or reasonable). 2. Remaining (optional) [security enhancements], such as a [default content security policy]. 3. Remaining [session improvements], such as re-keying. 4. Friction in handling of JSON, database access, etc. This is not properly part of or due to Dream, but it should be addressed for a better Web development experience. 5. Multicore and effects support. That's all. Let's bring OCaml to the Web! Happy Web programming! <https://github.com/aantron/dream> [security enhancements] <https://github.com/aantron/dream/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity> [default content security policy] <https://github.com/aantron/dream/issues/48> [session improvements] <https://github.com/aantron/dream/issues/13> Anton Bachin then added ─────────────────────── For readers who saw the repo during the earlier ["leak,"] the main updates are: • A large number of new examples, including [deployment]. • The [playground], which runs the examples, and itself served as a test. • An esy-based [quick start] script. There have also been very many smaller changes to the code, API, and the rest of the docs, but the above changes are the biggest "chunks." The rest is too much to detail :) ["leak,"] <https://discuss.ocaml.org/t/7605> [deployment] <https://github.com/aantron/dream/tree/master/example#deploying> [playground] <http://dream.as> [quick start] <https://github.com/aantron/dream#quick-start> Ivan Gotovchits asked and Anton Bachin replied ────────────────────────────────────────────── I was always wondering how does the source code that uses [templates] work with OCaml tooling, in particular with merlin, ocp-indent, ocaml-format, tuareg and other editor modes? It doesn't work well in practice with anything other than syntax highlighting. Note that you control the syntax mode with the extension. If your template is mostly HTML, you can name it `foo.eml.html'. The intent is that the templates should contain mostly HTML in a large project, and most of them would be in their own `template/' subdirectory. OCaml tooling wouldn't be needed for these mostly-HTML files. For a still-small, but real example of this, see the Playground's [`client.eml.html']. The one-file `.ml' projects with templates, where tooling is a problem, are mostly good for the very first steps of getting started, and examples. There is also an issue about this in the repo, [#55 " how to apply ocamlformat"]. Note that, as in the announcement text, you can use Dream with other templaters, including [TyXML], which has an [HTML PPX]. In addition, if you are using Reason, you can use [TyXML JSX]. Either of these options interacts well with tooling, as far as I know. I didn't make TyXML the default because it considerably increases the Dream learning curve for getting basic tasks done. However, Dream still supports the choice of using TyXML with examples and links. [templates] <https://aantron.github.io/dream/#templates> [`client.eml.html'] <https://github.com/aantron/dream/blob/fa20aebf36307a07b59c9ea018c25e508415d91a/example/z-playground/client/client.eml.html> [#55 " how to apply ocamlformat"] <https://github.com/aantron/dream/issues/55> [TyXML] <https://github.com/aantron/dream/tree/master/example/w-tyxml#files> [HTML PPX] <https://github.com/aantron/dream/tree/master/example/w-tyxml#html-syntax> [TyXML JSX] <https://github.com/aantron/dream/tree/master/example/r-tyxml#files> Ocaml developer at Routine, Paris, Remote OK ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-ocaml-developer-at-routine-paris-remote-ok/7911/1> mefyl announced ─────────────── Routine (<https://routine.co>) is looking for an OCaml developer. Routine is a personal productivity assistant. The technological revolves heavily around OCaml which represents 90% of the codebase, the remaining 10% being the UI in Typescript and Vue.js. We target both the browser and desktop through electron, using Js_of_ocaml. While the product is "just" a web app, our technological and academic background leads us to use designs that, I think, can pique the interest of seasoned Ocaml developer. Amongst other things : • Type-driven programming based on ppx derivers that produces typescript declaration for frontend bindings, JSON schema to expose and consume external REST APIs (Google, Notion, …), automatic SQL bindings, etc. • Angstrom based parsing for the interactive console with highlighting and completion. • Incremental based state updates to refresh minimal subsets of the app. • Highly concurrent implementation through Lwt, exception-free design. We use state of the art CI/CD and development processes. We plan on distributing open sources packages of these utilities (type-driven system, Google API bindings, Notion API bindings, …). Future exciting subjects could be extending Angstrom with manual rollback to implement generic completions or binding Vue in OCaml directly using melange or rescript to achieve rock solid typing down to the very frontend code (highly prospective teases, don't quote me on this yet :). The company is very much a startup, having just completed YC batch W21 and closed its first round of investment. Salary is up to market standard depending on the profile, plus usual options package, to be discussed. While we expect great OCaml and general computer science proficiency, we're open to most levels of experience. Thoroughness and a love for well rounded, robust and beautiful software design is a must have - but that comes bundled with OCaml love, right ? Do not hesitate to reach out for any question here, at quentin.hocquet@routine.co or refer this to someone who may be interested. Thanks for your time and happy camel riding ! Feather 0.2.0 ═════════════ Archive: <https://discuss.ocaml.org/t/ann-feather-0-2-0/7916/1> Charles announced ───────────────── I'm happy to announce feather version 0.2.0! Feather is a minimal library for bash-like scripting and process execution. ([github], [opam]) This release fixes some bugs and adds three new functions • `val and_ : cmd -> cmd -> cmd' — chain two commands, short circuiting if the first fails, akin to bash's `&&' operator. • `val or_ : cmd -> cmd -> cmd' — chain two commands, short circuiting if the first succeeds, akin to bash's `||' operator. • `val sequence : cmd -> cmd -> cmd' — chain two commands regardless of exit status. We include two new operators `&&.' and `||.' which correspond to `and_' and `or_' respectively. They'll be found in the `Feather.Infix' module, which has been renamed from `Feather.File_redirection_infix'. Many thanks to new contributors @Firobe @juxd and @tmarti2 for making this release possible! [github] <https://github.com/charlesetc/feather> [opam] <https://opam.ocaml.org/packages/feather/> BAP 2.3.0 Release ═════════════════ Archive: <https://discuss.ocaml.org/t/ann-bap-2-3-0-release/7926/1> Ivan Gotovchits announced ───────────────────────── We're proud to release the next stable version of Carnegie Mellon University Binary Analysis Platform ([BAP]). The full list of changes can be found on the [release page] but the most interesting new features are highlighted below. [BAP] <https://github.com/BinaryAnalysisPlatform/bap> [release page] <https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.3.0> The Primus Lisp Frontend ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Now BAP is able to understand not only binary programs but sources written in Primus Lisp. In case if you don't know, [Primus Lisp] is our DSL for writing analysis and library stubs (e.g., to specify semantics of missing library functions). Now, it is possible to reify Primus Lisp programs into static representation. For example, we can translate the following Lisp program ┌──── │ ;; file demo.lisp │ │ (defun example1 (x) │ (set R0 1) │ (set R1 2) │ (set R3 (+ R1 R2 (* R1 R2 3))) │ (memory-write R4 (+ R3 R1)) │ (if (> R0 (* R0 R0)) │ (exec-addr 0xDEADBEEF) │ (set R0 (* R0 R2 R3)))) └──── into the BIL (BAP Instruction Language) AST and then pretty print it, ┌──── │ $ bap show --primus-lisp-load=demo --target=armv7+le -obap:bil example1 │ example1: │ "{ │ R0 := 1 │ R1 := 2 │ R3 := R1 + R2 + R1 * R2 * 3 │ mem := mem with [R4] <- low:8[R3 + R1] │ #1 := R0 * R0 < R0 │ if (#1) { │ jmp 0xDEADBEEF │ } │ else { │ R0 := R0 * R2 * R3 │ } │ }" └──── This new feature not only allows us to reify our Lisp stubs into static form but also enables the main killer feature. It is now possible to specify the semantics of machine instructions in Primus Lisp. This feature enables rapid development and experimentation with CPU semantics. And this brings us to the next new feature. [Primus Lisp] <https://binaryanalysisplatform.github.io/bap/api/master/bap-primus/Bap_primus/Std/Primus/Lisp/index.html> New Target: RISC-V ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The first application of the Primus Lisp Frontend was writing the RISC-V semantics. It took me only one day to write the semantic of the [minimal subset] of RISC-V instruction. Well, partially it is because RISCV-V is truly RISC, like the `add' instruction just adds, ┌──── │ (defun ADDI (dst rm rn) │ (set$ dst (+ rm rn))) └──── [minimal subset] <https://github.com/BinaryAnalysisPlatform/bap/pull/1287> New Target: ARMv8 (Aarch64) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The next target that we tried was Aarch64, the 64-bit ARM architecture. It was a little bit [harder] but still definitely more readable than the official ARM semantics. [harder] <https://github.com/BinaryAnalysisPlatform/bap/blob/master/plugins/arm/semantics/aarch64.lisp> Adds namespaces (packages) to Primus Lisp ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Since now we have much more code in Primus Lisp we found ourselves struggling with name clashes. The Primus Lisp program model is a set of mututally recursive overloaded definitions, so naming things is crucial for us. Therefore we implemented namespaces (which are, following Common Lisp trandition, named packages). We ended up in a very Common Lisp look and fill but without inheriting CL problems, like the dependency on the order of inclusion and package redefinitions, and so on. Given our model, and that Primus Lisp features type inference and Haskell-style type classes for overloading, it wasn't that easy to implement :) Adds the `bap dependencies' command ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The [command] outputs program dependencies such as libraries and symbols. The information is collected recursively with various output options, including dependency graph, YAML, JSON, and SEXP. Much like `nm~+~ldd' on steroids and cross-platform (works on PE/ELF/COFF, and on binaries that are not native to the host). So it could be quite useful even if you're not doing program analysis, but just want to solve a nasty missing library feature or figure our what programs use what libraries, e.g., ┌──── │ $ bap dependencies `which ping` --recursive --ldconfig -ograph | graph-easy --as boxart │ ┌────────────────┐ │ │ libresolv.so.2 │ ──────────────────────────────────┐ │ └────────────────┘ │ │ ▲ │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────────────────┐ ┌────────────────┐ │ │ │ libidn.so.11 │ ◀── │ ping │ ──▶ │ libnettle.so.6 │ │ │ └──────────────┘ └──────────────────────────┘ └────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ┌────────────────┐ │ │ │ │ │ │ libcap.so.2 │ │ │ │ │ │ └────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ │ ┌──────────────────────────┐ │ │ │ └────────────────▶ │ libc.so.6 │ ◀─────┘ │ │ └──────────────────────────┘ │ │ │ ▲ │ │ │ └───────────────────────────┘ │ ▼ │ ┌────────────────┐ │ │ ld-linux.so.2 │ │ └────────────────┘ └──── [command] <https://github.com/BinaryAnalysisPlatform/bap/pull/1294> What's Next? ╌╌╌╌╌╌╌╌╌╌╌╌ We are working on decompilation and integrating with Ghidra, so in 2.4.0 you should expect that bap will output C code for binaries. But it is not all, we're even working into turning BAP into a program analysis framework that enables analysis of source code programs. And even crazier, we're working on adding compilation capabilities to BAP, i.e., an ability to compile/recompile the input sources. So soon BAP will outlive its name, or we will need to find a new interpretation for the BAP acronym, something like the Best Analysis Platform ;) We also plan to make BAP more available for non-seasoned OCaml users and want to push bap into mainstream Linux distributions and overall lower the entrance barrier. Of course, with the end goal to lure users into installing opam)) Questions and Suggestions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Please, do not hesitate to ask questions and provide your suggestions and, ideally, join our [community]. Even if you don't plan to work on binary analysis, BAP offers lots of opportunities for writing your toy programs for learning the language, or maybe even student projects. [community] <https://gitter.im/BinaryAnalysisPlatform/bap> Building Ahrefs codebase with Melange ═════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/building-ahrefs-codebase-with-melange/7941/1> Javier Chávarri announced ───────────────────────── At Ahrefs, we make extensive use of OCaml and ReScript —previously [known as BuckleScript]. So we have been following the latest developments in the ReScript ecosystem with great interest. A few months ago, [António Monteiro] released [Melange], a fork of ReScript with an emphasis of keeping compatibility with OCaml ecosystem. One of the key features of Melange is that it uses OCaml 4.12, with all the upsides that that entails (ppxlib, let syntax, better errors, …). Besides that, Melange has been modeled recently [as just a `compiler-libs' library], so it can be integrated with other OCaml code in a single opam switch. We decided to give Melange a try recently at Ahrefs, and shared the results of this experiment in a blog post: <https://tech.ahrefs.com/building-ahrefs-codebase-with-melange-9f881f6d022b> We are currently looking into how a deeper integration with Dune would look like. If your team or company has tried Melange, or is interested on doing so, we would be very interested to hear your use cases and share experiences. [known as BuckleScript] <https://rescript-lang.org/blog/bucklescript-is-rebranding> [António Monteiro] <https://discuss.ocaml.org/u/anmonteiro/summary> [Melange] <https://github.com/melange-re/melange> [as just a `compiler-libs' library] <https://github.com/melange-re/melange/pull/107> Lwt 5.4.1 ═════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-4-1/7943/1> Raphaël Proust announced ──────────────────────── We are glad to announce the release of version 5.4.1 of Lwt: a bugfix-only release. <https://github.com/ocsigen/lwt/releases/tag/5.4.1> You can update to this version in `opam': ┌──── │ opam update │ opam upgrade lwt └──── Thanks to the contributors for finding and fixing the bugs, leading to this release. Check out the release notes (link above) for a full list. Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Beta release of Frama-C 23.0~rc1 (Vanadium)] • [Building Ahrefs codebase with Melange] • [Computing an integer using a Grothendieck topos] • [ ReScript 9.1] • [Tutorial: Format Module of OCaml] • [Tarides project SCoP is selected as one of the brightest Data Portability projects in Europe!] • [Alt-Ergo Users’ Club Annual Meeting (2021)] [OCaml Planet] <http://ocaml.org/community/planet/> [Beta release of Frama-C 23.0~rc1 (Vanadium)] <https://frama-c.com/fc-versions/vanadium.html> [Building Ahrefs codebase with Melange] <https://tech.ahrefs.com/building-ahrefs-codebase-with-melange-9f881f6d022b> [Computing an integer using a Grothendieck topos] <http://math.andrej.com/2021/05/18/computing-an-integer-using-a-sheaf-topos/> [ ReScript 9.1] <https://rescript-lang.org/blog/release-9-1> [Tutorial: Format Module of OCaml] <https://www.ocamlpro.com/2021/05/06/tutorial-format-module-of-ocaml/> [Tarides project SCoP is selected as one of the brightest Data Portability projects in Europe!] <https://tarides.com/blog/2021-04-30-scop-selected-for-dapsi-initiative> [Alt-Ergo Users’ Club Annual Meeting (2021)] <https://www.ocamlpro.com/2021/04/29/alt-ergo-users-club-annual-meeting-2021/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 42545 bytes --]
[-- Attachment #1: Type: text/plain, Size: 17154 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 15 to 22, 2021. Table of Contents ───────────────── First releases of dirsp-exchange: auditable variant of Signal Protocol and ProScript-to-OCaml translator Job offer: 3 year research engineer in static analysis of OCaml programs at Inria Rennes IRC channels available on libera.chat Set up OCaml 2.0.0-beta First release of Jsonxt - a set of JSON parsers and writers mula 0.1.0, ML's radishal Universal Levenshtein Automata library New release of mlcuddidl, the OCaml interface to the CUDD BDD library first release of orf: OCaml Random Forests Old CWN First releases of dirsp-exchange: auditable variant of Signal Protocol and ProScript-to-OCaml translator ════════════════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-releases-of-dirsp-exchange-auditable-variant-of-signal-protocol-and-proscript-to-ocaml-translator/8008/1> jbeckford announced ─────────────────── I'm pleased to announce the first release of [dirsp-exchange], available today from the Opam repositories. The intent of the *[dirsp]* libraries is to provide software engineers with auditable source code that has some level of safety assurance (typically proofs) from security researchers. The first libraries are: • dirsp-exchange-kbb2017 0.1.0 - The KBB2017 protocol for securing a two-party conversation. Similar to Signal Protocol v3 and Olm Cryptographic Ratchet. • dirsp-ps2ocaml 0.1.0 - A ProScript to OCaml translator. ProScript is an executable subset of JavaScript that can be formally verified. and a couple more supporting libraries. `dirsp-exchange-kbb2017' has a build process that generates its own OCaml code using `dirsp-ps2ocaml' on formally verified ProScript source code. The canonical example for `dirsp-exchange-kbb2017' is: ┌──── │ module P = Dirsp_proscript_mirage.Make() │ module ED25519 = P.Crypto.ED25519 │ module K = Dirsp_exchange_kbb2017.Make(P) │ module U = K.UTIL │ │ (* Alice sends a message to Bob *) │ let aliceSessionWithBob = T.newSession (* ... supply some keys you create with ED25519 and U ... *) ;; │ let aliceToBobSendOutput = T.send │ aliceIdentityKey │ aliceSessionWithBob │ (P.of_string "Hi Bob!") │ │ (* Now you can send the output "aliceToBobSendOutput" from Alice to Bob. │ Let's switch to Bob's computer. He gets notified of a new message using a notification library of │ your choosing, and then does ... *) │ │ let bobSessionWithAlice = T.newSession (* ... supply some keys ... *);; │ let bobFromAliceReceiveOutput = T.recv │ bobIdentityKey │ bobSignedPreKey │ bobSessionWithAlice │ theEncryptedMessageBobReceivedFromAlice │ assert (bobFromAliceReceiveOutput.output.valid) │ Format.printf "Bob just received a new message: %s\n" │ (bobFromAliceReceiveOutput.plaintext |> P.to_bytes |> Bytes.to_string) └──── These are early releases, especially `dirsp-ps2ocaml'. Online docs are at <https://diskuv.github.io/dirsp-exchange> Feedback, contributions and downloads are very welcome! [dirsp-exchange] <https://github.com/diskuv/dirsp-exchange#readme> Job offer: 3 year research engineer in static analysis of OCaml programs at Inria Rennes ════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-offer-3-year-research-engineer-in-static-analysis-of-ocaml-programs-at-inria-rennes/8012/1> Benoit Montagu announced ──────────────────────── as part of a project between Inria and Nomadic Labs, we are offering a 3 year research engineer position, to work on static analysis for OCaml programs. The position will start in October in the Celtique Inria research team, in the vibrant city of Rennes, France. If you are a talented OCaml programmer, if you are interested in static analysis, or if you simply want to know more about this project, please contact me! The detailed job description is here: <https://jobs.inria.fr/public/classic/fr/offres/2021-03821> Please feel free to transfer this announce to people that you think could be interested. IRC channels available on libera.chat ═════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-06/msg00014.html> Deep in this thread, Romain Calascibetta announced ────────────────────────────────────────────────── Just to let you know that I spent a time to re-implement the IRC protocol in OCaml and to deploy a simple MirageOS as a logger to save discussions into a Git repository. The bot is currently deployed, the explanation is available here: <https://github.com/dinosaure/cri/tree/master/unikernel> And used for #mirage@irc.libera.chat It's a nice example about MirageOS/unikernel and I may deploy one to save #ocaml@irc.libera.chat as whitequark already does with her bot. Set up OCaml 2.0.0-beta ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta/8016/1> Sora Morimoto announced ─────────────────────── Hopefully, this will be the last release before stable 2.0.0. This release allows you to add multiple custom repositories, which enables testing with multicore and beta repository. ┌──── │ - name: Use Multicore OCaml │ uses: ocaml/setup-ocaml@v2 │ with: │ ocaml-compiler: ocaml-variants.4.12.0+domains+effects │ opam-repositories: | │ multicore: https://github.com/ocaml-multicore/multicore-opam.git │ default: https://github.com/ocaml/opam-repository.git └──── First release of Jsonxt - a set of JSON parsers and writers ═══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-jsonxt-a-set-of-json-parsers-and-writers/8018/1> Stephen Bleazard announced ────────────────────────── Jsonxt provides a number of JSON parsers and writers for RFC 8259 compliant JSON as well as non-standard extensions supported by Yojson. Features include • RFC 8259 compliant when in strict and basic mode • Performance focused especially for files and strings • Support for standard and extended JSON tree types: • Strict follows a strict interpretation of RFC 8259 with all numbers represented as floats. • Basic extends the strict type to include convenience types while maintaining RFC compliance. This is compatible with Yojson's Basic type • Extended adds additional non-standard types including tuples and variants and is not RFC compliant. This is compatible with Yojson's Safe type • A number of different parsers including • A standard JSON tree parser for various sources including string, file and channel • A Stream parser that returns a stream of raw JSON tokens. • A monad based parser compatible with async • Writers including • File and string writers • A monad based writer that is compatible with async • A stream writer that converts a stream of JSON tokens • Support for streaming JSON via the [Stream] module • Standard interfaces including Yojson compatibility • Support for `ppx_deriving_yojson' and `ppx_yojson_conv' via Yojson compatibility The package is available via opam, with documentation on [github.io]. The source can be found at [github/jsonxt] [Stream] <https://ocaml.org/api/Stream.html> [github.io] <https://stevebleazard.github.io/ocaml-jsonxt/jsonxt/index.html> [github/jsonxt] <https://github.com/stevebleazard/ocaml-jsonxt> mula 0.1.0, ML's radishal Universal Levenshtein Automata library ════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-mula-0-1-0-mls-radishal-universal-levenshtein-automata-library/8021/1> Ifaz Kabir announced ──────────────────── I'm happy to announce the release of my library `mula'. The package uses Universal Levenshtein Automata (ULA) to not only check if a word is within a certain edit distance of another, but to also output what the edit distance is! It uses the automata themselves to calculate edit distances. A fun use case for this is that we can feed a set of words to the automaton and immediately rank the words by their edit distance. `Mula' supports both the standard Levenshtein edit distance as well as the Demarau-Levenshtein distance which counts transpositions of two adjacent characters as a single edit. I also support getting live error counts, so you can feed part of a string into an automaton, and get the minimum number of errors that have occurred so far. I currently have matching working using non-deterministic ULA, but I have partially started the work toward the deterministic versions. It should be possible to pre-compute the DFAs for up to edit distance 3 and pack it with the library, never needing to be recomputed because the Universal Automata are independent of the input strings. But the non-deterministic automata support very large edit distances: (Sys.int_size - 1)/2, so they have value on their own. This library came about from a desire to add a "did you mean" feature to a toy compiler, but not wanting to write the kind of dynamic programming code that you can find in the OCaml compiler [1] or merlin/spelll [2,3]. You can find the library [here] and the documentation [here]. It's not on `opam' yet, but I have submitted a [pull request]. Happy OCamling! References: 1. Edit distance in the OCaml compiler. <https://github.com/ocaml/ocaml/blob/e5e9c5fed56efdd67601e4dbbaebeb134aee361c/utils/misc.ml#L516>. 2. Edit distance in merlin. <https://github.com/ocaml/merlin/blob/444f6e000f6b7dc58dac44d6ac096fc0e09894cc/src/utils/misc.ml#L527> 3. Edit distance in spelll. <https://github.com/c-cube/spelll/blob/3da1182256ff2507a0be812f945a7fe1a19adf9b/src/Spelll.ml#L26> [here] <https://github.com/ifazk/mula/> [here] <https://ifazk.github.io/mula/mula/index.html> [pull request] <https://github.com/ocaml/opam-repository/pull/18895> Ifaz Kabir then added ───────────────────── Some details: ╌╌╌╌╌╌╌╌╌╌╌╌╌ I followed the paper by Touzet [1] as much as possible. If you take a look at the code, you'll see a a lot of +1's for 1-indexing. This was to keep the implementation as close to the paper as possible! (If you do want to check the implementation against the paper, note that the paper has a typo in Definition 2). For the Demarau-Levenshtein automaton, I adapted Figure 9 from Mitankin's thesis [2]. I'm convinced that my adaptation works, but my adaptation of Touzet's subsumption relation for Demarau-Levenshtein might be slightly sub-optimal. If you have question about the adaptation, feel free to ask! `mula' does not completely replace c-cube's `spelll' package. In particular I don't support any indexs, etc. But there are some interesting differences in the automata they use. (`w' stands for the base word here) 1. The `spelll' package creates the Levenshtein Automaton for a single string/word (LA_w), `mula' uses Universal Levenshtein Automata (ULA). 2. `Spelll' computes a DFA from a non-deterministic automaton that uses eplison transitions. ULA do not have epsilon transitions, but for transitions it looks ahead into the base word `w'. Additionally the NFA's states/transitions are computable on the fly, so there is no need to store the NFA in memory. 3. `Spelll''s automata transitions using characters. `mula' computes a bitvector from an input character to transition from states to states. (Computing the bitvector is where the look ahead comes in). 4. `Spelll''s automata return `true~/~false', and uses a separate function to calculate edit distances. `Mula' uses the automaton itself to calculate edit distances, the outputs have type `int option'. (LA_w can be modified to support this though!) References: 1. On the Levenshtein Automaton and the Size of the Neighborhood of a Word. Hélène Touzet <https://hal.archives-ouvertes.fr/hal-01360482/file/LATA2016.pdf> 2. Universal Levenstein Automata: Building and Properties. Petar Nikolaev Mitankin. <https://store.fmi.uni-sofia.bg/fmi/logic/theses/mitankin-en.pdf> New release of mlcuddidl, the OCaml interface to the CUDD BDD library ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-mlcuddidl-the-ocaml-interface-to-the-cudd-bdd-library/8028/1> nberth announced ──────────────── I'm pleased to write this first release announcement for the [mlcuddidl] package. These bindings to the CUDD BDD library were initially written by Bertrand Jeannet and have been around as an OPAM package for quite some time now. The source code is now hosted on [framagit]. This release of version 3.0.7 mostly ports the package to OCaml versions ≥ 4.10. [mlcuddidl] <https://opam.ocaml.org/packages/mlcuddidl> [framagit] <https://framagit.org/nberth/mlcuddidl> first release of orf: OCaml Random Forests ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-orf-ocaml-random-forests/8034/1> UnixJunkie announced ──────────────────── I finished implementing a classifier and regressor using Random Forests (seminal paper: <https://link.springer.com/article/10.1023/A:1010933404324>): <https://github.com/UnixJunkie/orf> Some caveats: • this is somewhat slow; especially the classifier (and I don’t know so much how to accelerate it; probably two orders of magnitude slower than sklearn). • this is not super generic (int IntMap sparse features only; i.e. a sparse vector of integers represents a sample). The package is now available in opam (opam install orf). Two interfaces are exposed: RFC (for classification) <https://github.com/UnixJunkie/orf/blob/master/src/RFC.mli> RFR (for regression) <https://github.com/UnixJunkie/orf/blob/master/src/RFR.mli> The test file shows some usage examples: <https://github.com/UnixJunkie/orf/blob/master/src/test.ml> If you want to help, I tried to flag a few things for the near future: <https://github.com/UnixJunkie/orf/issues> If you use it and if it is useful to you, I would be happy to know. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 31402 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18172 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 22 to 29, 2021. Table of Contents ───────────────── wasicaml - a code emitter for OCaml targeting WebAssembly opam 2.1.0~rc2 Set up OCaml 2.0.0-beta2 Any OCaml bindings to Apache Arrow? Compiler engineer for OCaml and WebAssembly, Germany v3.0.0 release of reparse, reparse-lwt, reparse-lwt-unix Progress 0.2.0 http-multipart-formdata v2.0.0 Old CWN wasicaml - a code emitter for OCaml targeting WebAssembly ═════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-06/msg00017.html> Gerd Stolpmann announced ──────────────────────── I'd like to announce a new project to develop a code generator that emits WebAssembly: <https://github.com/remixlabs/wasicaml> With the support of RemixLabs I could already create a very first version that takes the OCaml bytecode as input and translates it to WebAssembly. While this approach probably doesn't lead to the fastest code, it is easy to accomplish, and it demonstrates the challenge (and already shows how to solve many of the part problems along the road). To be precisely, the target of the translator is wasm32-unknown-wasi, i.e. the WASI ABI. This ABI is still in early development, but provides already the syscalls (or better, host calls) to access files, to get the current time, and to read the environment. This is almost enough to run a compiler - I only had to add system() so that ocamlc can start external preprocessors. Also, due to the fact that the current wasm implementations still lack exception handling, I had to assume the presence of a host emulation of exceptions (which is easy to provide if the host environment is Javascript, but not necessarily for other environments). The translator takes the OCaml bytecode as input, i.e. you first create an excecutable ┌──── │ $ ocamlc -o myexec ... └──── and then make wasm out of it: ┌──── │ $ wasicaml -o myexec.wasm myexec └──── If you omit the .wasm suffix, wasicaml will put a preamble in front of the wasm code that starts the execution: ┌──── │ $ wasicaml -o myexec_wasm myexec │ $ ./myexec_wasm └──── Because of this trick, many problems of cross-compiling can be avoided. You may ask what the benefits of yet another "Web" language are. We already have two emitters targeting Javascript - isn't that enough? Well, two answers here. First, WASI is a proper LLVM target. Because of this, you can link code from other languages with your executable (e.g. C or Rust). So you are not limited to OCaml but can use any language that also targets the WASI ABI. E.g. you can do ┌──── │ $ wasicaml -o myexec.wasm myexec -ccopt -lfoo └──── to also link in libfoo.a (which must also be compiled to wasm). So it is multi-lingual from the beginning. Second, WebAssembly can be used outside the web, too. WASI targets more the command-line, and server plugins, and generally any OS-independent environments. For example, imagine you have an Electron app with a great UI, but for some special functionality you need to include some OCaml code, too. You don't want to give up the OS-independence, and WASI gives you now a natural option to add the OCaml code. And you still have access to the filesystem without hassle. - Another example is edge computing, i.e. when the cloud is extended by computers outside the data center, and the code should be in a form so that it can be run on as many platforms as possible. - All in all, WASI plays well when you need to combine OS-independence with a classic way of organizing the code as command or as server function, and you also need predictable performance. The challenge of translating OCaml to wasm is mainly the garbage collector. Wasm doesn't permit many of the tricks ocamlopt is using to know in which memory (or register) locations OCaml values are stored. In wasm, there are no registers but the closest vehicle are local variables. Now, it is not possible to scan these variables from the GC function, making it practically impossible to put OCaml values there while a function is called that might trigger a GC. There is also no really cheap way of obtaining a stack descriptor. Wasicaml inherits the stack from the bytecode interpreter and uses it as its own shadow stack for OCaml values. As wasicaml bases on the bytecode representation of the code, the bytecode instructions already ensure that values always live in this stack when the GC might run. Wasicaml additionally tries to identify values that don't need this special treatment (like ints and bools) and that are preferably stored in local variables, giving the wasm executor freedom to put these into registers or other high-speed locations. (Unfortunately, most of the type information is already erased in the bytecode, and this is definitely one of the deficiencies of the bytecode approach.) In order to maximize the performance, it is probably best to avoid the stack whenever possible. The current approach of transforming the bytecode hasn't brought to an end yet with respect to such optimizations. For example, there could be more analyses that figure out when GC runs are actually possible and when it is safe to use local variables. Another problem of the bytecode basis is that all function calls are indirect, preventing the wasm executor from inlining functions. As a project, I'd like to see wasicaml progressing in two directions. First, make the current approach as good as possible - although basing it on the bytecode representation has its downsides, it is easy to understand and it is possible to figure out what the necessary ingredients for fast code are. Second, get an idea where a possible real wasm backend would fit into the OCaml compiler (maybe it is c– but maybe this doesn't give us much and you start better with lambda). Anyway, welcome to the new world of WebAssembly! Gerd PS. If you are interested in WebAssembly and like to work with me on another Wasm port for some time, there is a position: <https://www.mixtional.de/recruiting/2021-01/index.html> PPS. Wasicaml is a project of Figly, Inc., commonly known as RemixLabs, developing a reactive low-code and code collaboration platform. <https://remixlabs.com/> opam 2.1.0~rc2 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0-rc2/8042/1> David Allsopp announced ─────────────────────── The opam team has great pleasure in announcing opam 2.1.0~rc2! The focus since beta4 has been preparing for a world with more than one released version of opam (i.e. 2.0.x and 2.1.x). The release candidate extends CLI versioning further and, under the hood, includes a big change to the opam root format which allows new versions of opam to indicate that the root may still be read by older versions of the opam libraries. A plugin compiled against the 2.0.9 opam libraries will therefore be able to read information about an opam 2.1 root (plugins and tools compiled against 2.0.8 are unable to load opam 2.1.0 roots). Please do take this release candidate for a spin! It is available in the Docker images at ocaml/opam on [Docker Hub] as the opam-2.1 command (or you can `sudo ln -f /usr/bin/opam-2.1 /usr/bin/opam' in your `Dockerfile' to switch to it permanently). The release candidate can also be tested via our installation script (see the [wiki] for more information). Thank you to anyone who noticed the unannounced first release candidate and tried it out. Between tagging and what would have been announcing it, we discovered an issue with upgrading local switches from earlier alpha/beta releases, and so fixed that for this second release candidate. Assuming no showstoppers, we plan to release opam 2.1.0 next week. The improvements made in 2.1.0 will allow for a much faster release cycle, and we look forward to posting about the 2.2.0 plans soon! [Docker Hub] <https://hub.docker.com/r/ocaml/opam/tags> [wiki] <https://github.com/ocaml/opam/wiki/How-to-test-an-opam-feature#from-a-tagged-release-including-pre-releases> Set up OCaml 2.0.0-beta2 ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta2/8046/1> Sora Morimoto announced ─────────────────────── This release includes changes to address a corner case primarily related to multicore OCaml. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta2> Any OCaml bindings to Apache Arrow? ═══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/any-ocaml-bindings-to-apache-arrow/8047/2> UnixJunkie asked and Laurent Mazare announced ───────────────────────────────────────────── Looks interesting: <https://arrow.apache.org/> <https://arrow.apache.org/overview/> I've put together some simple [ocaml-arrow] library. It works reasonably well and is quite battle tested but definitely needs a bit of cleanup as the bits under src/ are deprecated in favor of the ones under c_api/. There is also a ppx to automatically convert ocaml records to/from arrow. Some examples using this can be seen in the [tests directory]. If there is some interest, I can certainly push up on cleaning this and make an actual opam package. [ocaml-arrow] <https://github.com/LaurentMazare/ocaml-arrow> [tests directory] <https://github.com/LaurentMazare/ocaml-arrow/blob/master/c_api/tests/ppx.ml> Compiler engineer for OCaml and WebAssembly, Germany ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/compiler-engineer-for-ocaml-and-webassembly-germany/8053/1> Gerd Stolpmann announced ──────────────────────── 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, C, Elm, and Javascript. We are looking for a compiler engineer with skills in code generation for WebAssembly: • Translation of an intermediate representation to WebAssembly • Writing runtimes and SDKs targeting WebAssembly • Code optimization See the full ad here: <https://www.mixtional.de/recruiting/2021-01/index.html> v3.0.0 release of reparse, reparse-lwt, reparse-lwt-unix ════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-v3-0-0-release-of-reparse-reparse-lwt-reparse-lwt-unix/8058/1> Bikal Lem announced ─────────────────── I am happy to announce v3.0.0 of `reparse' - an OCaml library for constructing various types of parsers in OCaml. The release follows a complete overhaul of the internal working of the library to achieve the following goals: 1. Allow construction of efficient, zero-copy parsers. See [String parser for example]. The library provides a [Make functor] parametrised over a `Promise' and a `Input' type allowing you control over both parser memory allocation and copying. 2. Support usage of async libraries - lwt and async. Following the first point the library can now be used together with `lwt' and/or `async'. A lwt parse - for example - can now be used seamlessly with your other lwt code. The integration is seamless. 3. Provide `Make_buffered' functor to produce parsers where the input type natively doesn't allow random read, for example sockets, lwt streams and channels. There is now two new supporting packages `reparse-lwt' which provides parsing from `char Lwt_stream.t' input type and `reparse-lwt-unix' which provides parsing from `Lwt_unix.file_descr' and ~Lwt_unix.input_channel' respectively. 4. Provide `Make_unbuffered' functor to produce parsers where the input type natively supports random read, for example strings, bigstrings, bytes. 5. Introduce function `unsafe_any_char' to allow efficient (zero-copy?) parsing. 6. Prune dependencies by removing `base'. P.S. The documentation is bit behind in this release so please bear with me while work through the issues in the coming days. [Reparse repo] [String parser for example] <https://github.com/lemaetech/reparse/blob/master/lib/reparse.mli#L1237> [Make functor] <https://github.com/lemaetech/reparse/blob/master/lib/reparse.mli#L1230> [Reparse repo] <https://github.com/lemaetech/reparse/blob/master/lib/reparse.ml> Progress 0.2.0 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-progress-0-2-0/8063/1> Craig Ferguson announced ──────────────────────── I'm pleased to announce the 0.2.0 release of [`Progress'], now available via Opam. <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/7/727d878b6d17f3c48e6946f4df424bcc59938da3.png> `Progress' is an OCaml library for defining and using progress bars. It has the following features: • allows user-defined progress bar layouts; • supports rendering multiple progress bars simultaneously; • dynamically responds to changes in terminal size; • supports interleaving logging with progress bar rendering. This second release contains a much-improved DSL for specifying progress bars, alongside improvements and extensions to the rendering logic. The bars in the screenshot above are defined as follows: ┌──── │ let bar ~color ~total = │ let open Progress.Line in │ list │ [ spinner ~color:(Progress.Color.ansi ~green) () │ ; brackets (elapsed ()) │ ; bar ~color total │ ; bytes │ ; parens (const "eta: " ++ eta total) │ ] └──── It also comes with more complete [documentation] and many more [examples], including: • a Cargo-like progress bar w/ logging of intermediate results: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/4/4b148999f7b6029ac0155b049b6a7cf1fa8b40f1_2_1380x500.png> • a Yarn-like stack of spinners: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/6/67ccf011a403a4c082829f69d5a609b4c0c23f6e.png> • a showcase of various progress bar styles: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/d/d4df4a2df07fd161982243251fbee56d52a4afbf_2_1034x538.png> The changelog is [here] and the API documentation is [here]. The library is not yet feature-complete, but should still be reasonably useful :-) Happy hacking! [`Progress'] <https://github.com/craigfe/progress> [documentation] <https://craigfe.github.io/progress/progress/Progress/index.html> [examples] <https://github.com/CraigFe/progress/tree/main/examples> [here] <https://github.com/CraigFe/progress/blob/0.2.0/CHANGES.md#020-2021-06-26> [here] <https://craigfe.github.io/progress/progress/Progress/index.html> http-multipart-formdata v2.0.0 ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v2-0-0/8064/1> Bikal Lem announced ─────────────────── I am pleased to announce v2.0.0 release of `http-multpart-formdata'. This release departs from previous in-memory representation of http multipart forms to a streaming, memory efficient representation. The new streaming mechanism should help when processing larg file uploads in your OCaml web applications. 1. [httpaf sample web app] 2. [http-multipart-formdata repo] [httpaf sample web app] <https://github.com/lemaetech/http-multipart-formdata/blob/master/examples/multipart_httpaf.ml> [http-multipart-formdata repo] <https://github.com/lemaetech/http-multipart-formdata> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 30089 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18790 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 29 to July 06, 2021. Table of Contents ───────────────── LibreRef - LablGtk-based Digital Reference Tool Application u2f - universal second factor Reproducible OPAM packages / MirageOS Dune 2.9.0 Hardcaml MIPS CPU Learning Project and Blog dune-release 1.5.0 anders 0.7.1 Old CWN LibreRef - LablGtk-based Digital Reference Tool Application ═══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-libreref-lablgtk-based-digital-reference-tool-application/8077/1> Kiran Gopinathan announced ────────────────────────── I'm not sure if this is that close to the typical uses of OCaml, but posting this here just in case anyone was interested in another end-user facing application using LablGtk. <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/b72b4bd7838e41dbaed2254350799c5e75245a3d_2_250x250.png> LibreRef is a free as in freedom digital referencing tool for artists. It's written in OCaml using LablGtk and Cairo to implement the GUI. You can find the source code at: [gitlab] ([github mirror]) A picture is worth a thousand words, so before I continue, here are a few examples of it in action: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/126997c61b83b700feac41e380b42c560bdf2340.gif> <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/4/49b11ef943e491ba220332d257bc6a15b506ed6b.gif> Overall, getting LablGtk to work was fairly straightforward, although the documentation was a bit lacking (although the same might be said of Gtk itself). I was able to piece together the correct uses of most of the API calls by relying on either the examples from the repository or by translating snippets of code from online back into LablGtk. As for deploying it as an application, I found the AppImage & LinuxDeploy toolchain to work well with the resulting binary (admittedly I've only tested it with two devices so far), and it meant that I could publish the program without having to ask people to setup the full OCaml & Opam toolchain, which would probably be a large ask. As for the implementation, I think it was fairly elegant (if I say so myself :slight_smile:), although I may have gone overboard with functors (see this higher-order functor in the GUI interface: <https://gitlab.com/gopiandcode/libre-ref/-/blob/master/gui.mli#L175>) and some aspects of the separation of concerns weren't so well established. [gitlab] <https://gitlab.com/gopiandcode/libre-ref> [github mirror] <https://github.com/Gopiandcode/LibreRef> u2f - universal second factor ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-u2f-universal-second-factor/8078/1> Hannes Mehnert announced ──────────────────────── it is our pleasure to announce the just released opam package u2f, which is a server side implementation of the FIDO standard for two-factor authentication using a special device (yubikey etc.). The device does challenge-response authentication with the server using public key cryptography. The implementation is stateless and does not use a specific IO library, but only achieves the logic for constructing a registration request, verifying a response thereof, and authorization requests with responses thereof. Please have a look at <https://github.com/roburio/u2f> if you're interested. It is licensed under the permissive 2-clause BSD license. We use this library in an example server (in the `bin' directory) that uses dream. The live server is online at <https://u2f-demo.robur.coop> – please let us know if you run into any trouble, or open an issue on the GitHub repository. One question though: we're unable to generate the documentation from the mli – already asked on discord with no result. Anyone with a better understanding of odoc etc. can take a look why `dune build @doc' outputs a nearly empty file? Thanks a lot :) The development was sponsored by skolem.tech. Reproducible OPAM packages / MirageOS ═════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/reproducible-opam-packages-mirageos/8079/1> Hannes Mehnert announced ──────────────────────── we are pleased to announce reproducible binary images for MirageOS unikernels (see the blog post at <https://hannes.robur.coop/Posts/Deploy>). The binaries are located at <https://builds.robur.coop> (all components are open source and linked from the page). Additionally, the required tools to achieve reproducible builds are released as binary packages for various operating systems as well on the same site. They are used by the infrastructure to run daily builds (always with the HEAD of opam-repository to not loose any updates / new releases). The custom overlay <https://git.robur.io/robur/unikernel-repo> is used that adds some development packages. Happy to hear your thoughts and feedback here. (Earlier post <https://discuss.ocaml.org/t/reproducible-builds-with-ocaml-opam-and-mirageos/4877>) This work was funded by the [NGI Pointer] project "Funding The Next Generation Ecosystem of Internet Architects". [NGI Pointer] <https://pointer.ngi.eu> Dune 2.9.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-2-9-0/8087/1> Emilio Jesús Gallego Arias announced ──────────────────────────────────── Dear all, on behalf of the Dune team I'm pleased to announce the release of Dune 2.9.0. This is the last release on the Dune 2.x series and could be considered a maintenance release as it mostly consists on bug fixes and miscellaneous tweaks and features for sites, instrumentation, and mdx support. Please find the full list of changes below: • Add `(enabled_if ...)' to `(mdx ...)' (<https://github.com/ocaml/dune/pull/4434>, @emillon) • Add support for instrumentation dependencies (<https://github.com/ocaml/dune/pull/4210>, fixes <https://github.com/ocaml/dune/issues/3983>, @nojb) • Add the possibility to use `locks' with the cram tests stanza (<https://github.com/ocaml/dune/pull/4480>, @voodoos) • Allow to set up merlin in a variant of the default context (<https://github.com/ocaml/dune/pull/4145>, @TheLortex, @voodoos) • Add `(package ...)' to `(mdx ...)' (<https://github.com/ocaml/dune/pull/4691>, fixes <https://github.com/ocaml/dune/issues/3756>, @emillon) • Handle renaming of `coq.kernel' library to `coq-core.kernel' in Coq 8.14 (<https://github.com/ocaml/dune/pull/4713>, @proux01) • Fix generation of merlin configuration when using `(include_subdirs unqualified)' on Windows (<https://github.com/ocaml/dune/pull/4745>, @nojb) • Fix bug for the install of Coq native files when using `(include_subdirs qualified)' (<https://github.com/ocaml/dune/pull/4753>, @ejgallego) • Allow users to specify install target directories for `doc' and `etc' sections. We add new options `--docdir' and `--etcdir' to both Dune's configure and `dune install' command. (<https://github.com/ocaml/dune/pull/4744>, fixes <https://github.com/ocaml/dune/issues/4723>, @ejgallego, thanks to @JasonGross for reporting this issue) • Fix issue where Dune would ignore `(env ... (coq (flags ...)))' declarations appearing in `dune' files (<https://github.com/ocaml/dune/pull/4749>, fixes <https://github.com/ocaml/dune/issues/4566>, @ejgallego @rgrinberg) • Disable some warnings on Coq 8.14 and `(lang coq (>= 0.3))' due to the rework of the Coq "native" compilation system (<https://github.com/ocaml/dune/pull/4760>, @ejgallego) • Fix a bug where instrumentation flags would be added even if the instrumentatation was disabled (@nojb, <https://github.com/ocaml/dune/pull/4770>) • Fix <https://github.com/ocaml/dune/issues/4682>: option `-p' takes now precedence on environement variable `DUNE_PROFILE' (<https://github.com/ocaml/dune/pull/4730>, <https://github.com/ocaml/dune/pull/4774>, @bobot, reported by @dra27 <https://github.com/ocaml/dune/issues/4632>) • Fix installation with opam of package with dune sites. The `.install' file is now produced by a local `dune install' during the build phase (<https://github.com/ocaml/dune/pull/4730>, <https://github.com/ocaml/dune/pull/4645>, @bobot, reported by @kit-ty-kate <https://github.com/ocaml/dune/issues/4198>) • Fix multiple issues in the sites feature (<https://github.com/ocaml/dune/pull/4730>, <https://github.com/ocaml/dune/pull/4645> @bobot, reported by @Lelio-Brun <https://github.com/ocaml/dune/issues/4219>, by @Kakadu <https://github.com/ocaml/dune/issues/4325>, by @toots <https://github.com/ocaml/dune/issues/4415>) Hardcaml MIPS CPU Learning Project and Blog ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088/1> "Alexander (Sasha) Skvortsov announced ────────────────────────────────────── Tl;dr: I’m [writing a blog] about making a MIPS CPU in Hardcaml. Hi! My name is Sasha, and I’m a student at Penn State majoring in CS and Math. Last semester, I took a computer engineering class where we built a pipelined MIPS CPU in Verilog as a semester-long project. I enjoyed the class, but a lot of frustration came from Verilog itself. A few months ago, I came across the [Signals and Threads Programmable Hardware episode]. I really liked the idea of [Hardcaml]: a library to write and test hardware designs in OCaml. Representing circuits as functions felt like a good abstraction, and I’ve been wanting to learn OCaml for a while. So this summer, a friend and I are rewriting the Verilog MIPS CPU we made last semester into Hardcaml. We’re still working on the project, but have made some good progress and wanted to share it in case anyone finds it interesting / useful. If anyone wants to take a look, it’s [up on GitHub]. We’ve written some blog posts about our project: 1. [Some more background on what we’re doing and why] 2. [An ELI5 overview of how hardware, and pipelined CPUs in particular, work] 3. [Another high-level overview of Verilog, hardware design, FPGAs, and why I think OCaml might be a great fit for hardware design] 4. [How to set up a Hardcaml project, including testing and Verilog generation] 5. [How to split Hardcaml circuits into multiple modules] There’s also a few more that we’ve written code for, but are still drafting blog posts about: • How to work with memory in Hardcaml • How to design stateful, sequential circuits in Hardcaml • A safer design pattern for Hardcaml circuits I’m new to both OCaml and blogging, and this has definitely been a fun experience so far! Would love to hear any feedback / comments. [writing a blog] <https://ceramichacker.com/> [Signals and Threads Programmable Hardware episode] <https://signalsandthreads.com/programmable-hardware/> [Hardcaml] <https://github.com/janestreet/hardcaml> [up on GitHub] <https://github.com/askvortsov1/hardcaml-mips> [Some more background on what we’re doing and why] <https://ceramichacker.com/blog/1-1x-hardcaml-mips-intro-what-and-why> [An ELI5 overview of how hardware, and pipelined CPUs in particular, work] <https://ceramichacker.com/blog/2-2x-a-bit-on-computers-hardware-and-cpus> [Another high-level overview of Verilog, hardware design, FPGAs, and why I think OCaml might be a great fit for hardware design] <https://ceramichacker.com/blog/4-3x-verilog-fpgas-and-why-ocaml> [How to set up a Hardcaml project, including testing and Verilog generation] <https://ceramichacker.com/blog/5-4x-ocaml-setup-hardcaml-basics-and-project-plan> [How to split Hardcaml circuits into multiple modules] <https://ceramichacker.com/blog/11-5x-multi-module-circuits-in-hardcaml> dune-release 1.5.0 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-dune-release-1-5-0/8095/1> Nathan Rebours announced ──────────────────────── On behalf of the dune-release team I'm pleased to announce that we're releasing dune-release.1.5.0. It has been quite a while since the last release so there are numerous changes and improvements in this one, along with a lot of bug fixes. The two main new features in 1.5.0 are: • A draft release mode that creates a draft Github release and a draft PR to opam-repository. It comes with an `undraft' command that will undraft both and update the opam file's `url.src' field accordingly. We believe this feature will prove helpful to maintainers of tools such as `dune' which releases are often watched by distribution maintainers. Draft releases allow you to wait until you have opam-repository's CI approval to actually create a GH release that will notify anyone watching the repository. This feature is still a bit experimental, we have ideas on how to improve it but we wanted to get a first version out to collect feedback on how it is used and what you folks expect from it. • A `check' command that you can run ahead of a release to know if dune-release has all the information it needs in the repository, along with running the lint, build and test checks it normally runs after building the tarball. We're aware that it can be frustrating to see dune-release fail right in the middle of the release process. We're trying to improve this situation and this is a first step in that direction. You can see the full changelog [here] You'll note we also deprecated a few features such as delegates (as we announced in [this post]), opam 1.x and the `--user' option and corresponding config file field. This release is likely to be the last 1.x release of `dune-release' except for important bug fixes as we'll start working on 2.0 soon. Our main goals for 2.0 are to make the experience for github users as seemless as possible. We want the tool to do the right thing for those users without them having to configure anything. Delegates got in the way there and that's why we're removing them. We do care about our non github users and we've worked on making it as configurable as possible so that you can integrate it in your release workflow. The situation should already have improved quite a bit with this release as we fixed several bugs for non github hosted repositories. We want to make sure that these users will be happy with dune-release 2.0 as well. Hopefully in the future dune-release will support other release workflows such as handling gitlab hosted repositories but we want to make sure our main user base is happy with the tool before adding this. We'll communicate a bit more on our plans for 2.0 in the next few months. Our hope is that it will hit opam before the end of this year. We hope that you'll like this new version and wish you all successful and happy releases! [here] <https://github.com/ocamllabs/dune-release/releases/tag/1.5.0> [this post] <https://discuss.ocaml.org/t/replacing-dune-release-delegates/4767> anders 0.7.1 ════════════ Archive: <https://discuss.ocaml.org/t/ann-anders-0-7-1/8098/1> Namdak Tonpa announced ────────────────────── The HTS language proposed by Voevodsky exposes two different presheaf models of type theory: the inner one is homotopy type system presheaf that models HoTT and the outer one is traditional Martin-Löf type system presheaf that models set theory with UIP. The motivation behind this doubling is to have an ability to express semisemplicial types. Theoretical work on merging meta-theoretical and homotopical languages was continued in [2LTT] [Anenkov, Capriotti, Kraus, Sattler]. While we are on our road to HTS with Lean-like tactic language, currently we are at the stage of regular cubical (HoTT) type checker with CHM-style primitives, or more general CCHM type checker. You may try it at Github: [groupoid/anders]. ┌──── │ $ opam install anders │ $ anders │ Anders theorem prover [PTS][MLTT][CCHM-4][HTS]. │ │ invoke = anders | anders list │ list = [] | command list │ command = check filename | lex filename │ | parse filename | help │ | cubicaltt filename | girard │ | trace └──── Anders is idiomatic and educational. We carefully draw the favourite Lean-compatible syntax to fit 130 LOC in Menhir, the MLTT core (based on Mini-TT) is 500 LOC and pretypes presheaf is another 500 LOC. [2LTT] <https://arxiv.org/pdf/1705.03307.pdf> [groupoid/anders] <https://github.com/groupoid/anders> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 31723 bytes --]
[-- Attachment #1: Type: text/plain, Size: 24945 bytes --] Hello Here is the latest OCaml Weekly News, for the week of July 13 to 20, 2021. Table of Contents ───────────────── Writing a REST API with Dream OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library soupault: a static website generator based on HTML rewriting OCaml 4.13.0, second alpha release OCamlFormat 0.19.0 OCaml Café: Wed, Aug 4 @ 7pm (U.S. Central) Old CWN Writing a REST API with Dream ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/writing-a-rest-api-with-dream/8150/1> Joe Thomas announced ──────────────────── I've written a short [blog post] about the positive experience I had using Dream to build a REST API. The accompanying source code is available here: <https://github.com/jsthomas/sensors> I'm interested in adding more examples and tutorials to the OCaml ecosystem and would be happy to get your feedback on this writeup (here or via email/github). [blog post] <https://jsthomas.github.io/ocaml-dream-api.html> OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library ══════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-otoml-0-9-0-a-compliant-and-flexible-toml-parsing-manipulation-and-pretty-printing-library/8152/1> Daniil Baturin announced ──────────────────────── I don't really like to base a release announcement on bashing another project, but this whole project is motivated by my dissatisfaction with [To.ml]—the only TOML library for OCaml, so here we go. OTOML is a TOML library that you (hopefully) can use without writing long rants afterwards. ;) In short: • [TOML 1.0-compliant] (To.ml is not). • Good error reporting. • Makes it easy to look up nested values. • Bignum and calendar libraries are pluggable via functors. • Flexible pretty-printer with indentation. OPAM: <https://opam.ocaml.org/packages/otoml/> GitHub: <https://github.com/dmbaturin/otoml> Now let's get to details. TOML is supposed to be human-friendly so that people can use it as a configuration file format. For that, both developer and end-user experience must be great. To.ml provides neither. I've been using To.ml in my projects for a long time, and [To.ml] <https://opam.ocaml.org/packages/toml/> [TOML 1.0-compliant] <https://toml.io/en/v1.0.0> Standard compliance ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ TOML is neither minimal nor obvious really, it's much larger than the commonly used subset and the spec is not consistent and not easy to read, but To.ml fails at rather well-known things, like dotted keys, arrays of tables and heterogeneous arrays. OTOML passes all tests in the [test suite], except the tests related to bignum support. Those tests fail because the default implementation maps integers and floats to the native 31/63-bit OCaml types. More on that later. [test suite] <https://github.com/BurntSushi/toml-test> Error reporting ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Let's look at error reporting. To.ml's response to any parse error is a generic error with just line and column numbers. ┌──── │ utop # Toml.Parser.from_string "foo = [" ;; │ - : Toml.Parser.result = │ `Error │ ("Error in <string> at line 1 at column 7 (position 7)", │ {Toml.Parser.source = "<string>"; line = 1; column = 7; position = 7}) └──── Menhir offers excellent tools for error reporting, so I took time to make descriptive messages for many error conditions (there _are_ generic "syntax error" messages still, but that's better than nothing at all). ┌──── │ utop # Otoml.Parser.from_string_result "foo = [" ;; │ - : (Otoml.t, string) result = │ Error │ "Syntax error on line 1, character 8: Malformed array (missing closing square bracket?)\n" │ │ utop # Otoml.Parser.from_string_result "foo = {bar " ;; │ - : (Otoml.t, string) result = │ Error │ "Syntax error on line 1, character 12: Key is followed by end of file or a malformed TOML construct.\n" └──── Looking up nested values ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Nested sections are common in configs and should be easy to work with. This is how you do it in OTOML: ┌──── │ utop # let t = Otoml.Parser.from_string "[this.is.a.deeply.nested.table] │ answer=42";; │ val t : Otoml.t = │ Otoml.TomlTable │ [("this", │ Otoml.TomlTable... │ │ utop # Otoml.find t Otoml.get_integer ["this"; "is"; "a"; "deeply"; "nested"; "table"; "answer"] ;; │ - : int = 42 └──── For comparison, this is how it was done in To.ml: ┌──── │ utop # let toml_data = Toml.Parser.(from_string " │ [this.is.a.deeply.nested.table] │ answer=42" |> unsafe);; │ val toml_data : Types.table = <abstr> │ │ utop # Toml.Lenses.(get toml_data ( │ key "this" |-- table │ |-- key "is" |-- table │ |-- key "a" |-- table │ |-- key "deeply" |-- table │ |-- key "nested" |-- table │ |-- key "table" |-- table │ |-- key "answer"|-- int ));; │ - : int option = Some 42 └──── Extra dependencies ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The TOML spec includes first-class RFC3339 dates, for better or worse. The irony is that most uses of TOML (and, indeed, most configuration files in the world) don't need that, so it's arguably a feature bloat—but if we set out to support TOML as it's defined, that question is academic. The practical implication is that if the standard library of a language doesn't include a datetime type, a TOML library has to decide how to represent those values. To.ml makes ISO8601 a hard dependency, so if you don't use dates, you end up with a useless dependency. And if you prefer another library (or need functionality no present in ISO8601), you end up with two libraries: one you chose to use, and one more forced on you. Same goes for the arbitrary precision arithmetic. Most configs won't need it, but the standard demands it, so something needs to be done. Luckily, in the OCaml land we have functors, so it's easy to make all these dependencies pluggable. So I made it a functor that takes three modules. ┌──── │ module Make (I : TomlInteger) (F : TomlFloat) (D : TomlDate) : │ TomlImplementation with type toml_integer = I.t and type toml_float = F.t and type toml_date = D.t └──── This is how to use Zarith for big integers and keep the rest unchanged: ┌──── │ (* No signature ascription: │ `module BigInteger : Otoml.Base.TomlInteger` would make the type t abstract, │ which is inconvenient. │ *) │ module BigInteger = struct │ type t = Z.t │ let of_string = Z.of_string │ let to_string = Z.to_string │ let of_boolean b = if b then Z.one else Z.zero │ let to_boolean n = (n <> Z.zero) │ end │ │ module MyToml = Otoml.Base.Make (BigInteger) (Otoml.Base.OCamlFloat) (Otoml.Base.StringDate) └──── Printing ╌╌╌╌╌╌╌╌ To.ml's printer can print TOML at you, that's for certain. No indentation, nothing to help you navigate nested values. ┌──── │ utop # let toml_data = Toml.Parser.(from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |> unsafe) |> │ Toml.Printer.string_of_table |> print_endline;; │ [foo.bar] │ baz = false │ [foo.quux] │ xyzzy = [1, 2] └──── We can do better: ┌──── │ utop # let t = Otoml.Parser.from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |> │ Otoml.Printer.to_channel ~indent_width:4 ~collapse_tables:false stdout;; │ │ [foo] │ │ [foo.bar] │ baz = false │ │ [foo.quux] │ xyzzy = [1, 2] │ val t : unit = () │ │ utop # let t = Otoml.Parser.from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |> │ Otoml.Printer.to_channel ~indent_width:4 ~collapse_tables:false ~indent_subtables:true stdout;; │ │ [foo] │ │ [foo.bar] │ baz = false │ │ [foo.quux] │ xyzzy = [1, 2] │ val t : unit = () └──── Maintenance practices ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Last but not least, good maintenance practices are also important, not just good code. To.ml is at 7.0.0 now. It has a [CHANGES.md] file, but I'm still to see the maintainers document what the breaking change is, who's affected, and what they should do to make their code compatible. For example, in 6.0.0 the breaking change was a rename from `TomlLenses' to `Toml.Lenses'. In an earlier release, I remember the opposite rename. Given the standard compatibility problems going unfixed for years, that's like rearranging furniture when the roof is leaking. I promise not to do that. [CHANGES.md] <https://github.com/ocaml-toml/To.ml/blob/master/CHANGES.md> Conclusion ╌╌╌╌╌╌╌╌╌╌ I hope this library will help make TOML a viable configuration file format for OCaml programs. It's just the first version of course, so there's still room for improvement. For example, the lexer is especially ugly: due to TOML being highly context-sensitive, it involves massive amounts of lexer hacks for context tracking. Maybe ocamllex is a wrong tool for the job abd it should be replaced with something else (since I'm using Menhir's incremental API anyway, it's not tied to any lexer API). The printer is also less tested than the parser, so there may be unhandled edge cases. It also has some cosmetic issues like newlines between parent and child tables. Any feedback and patches are welcome! 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/15> Daniil Baturin announced ──────────────────────── [soupault 3.0.0] is now available. It now uses the new [OTOML] library for loading the configs, which has some positive side effects, e.g. keys in the output of `soupault --show-effective-config' (that shows your config plus default values you didn't set explicitly) now come in the same order as in your config file. It also provides TOML and YAML parsing functions to Lua plugins and has colored log headers (can be disabled with NO_COLOR environment variables). [soupault 3.0.0] <https://soupault.app/blog/soupault-3.0.0-release/> [OTOML] <https://opam.ocaml.org/packages/otoml/> OCaml 4.13.0, second alpha release ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-13-0-second-alpha-release/8164/1> octachron announced ─────────────────── The release of OCaml 4.13.0 is approaching. We have released a second alpha version to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions). You can see the progress on this front at <https://github.com/ocaml/opam-repository/issues/18791> . Beyond the usual bug fixes (see the full list below), this second alpha integrates a new feature for native code: poll points. Those poll points currently fixes some issues with signals in non-allocating loops in native code. More importantly, they are prerequisite for the multicore runtime. Another change is the removal of the removal of interbranch propagation of type information. The feature, already postponed from 4.12, has been removed to focus for now on better error message in the `-principal' mode. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> The first beta release may follow soon since the opam ecosystem is in quite good shape; and we are on track for a full release in September. Happy hacking, Florian Angeletti for the OCaml team. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.13.0~alpha2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.13.0~alpha2+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.13.0~alpha2+flambda+nffa │ --packages=ocaml-variants.4.13.0~alpha2+options,ocaml-option-flambda,ocaml-option-no-flat-float-array │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with "opam search ocaml-option". If you want to test this version, it is advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various fixes in the process of being upstreamed. The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.13.0-alpha2.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.13/ocaml-4.13.0~alpha2.tar.gz> Changes since the first alpha release ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ New feature ┄┄┄┄┄┄┄┄┄┄┄ • [10039]: Safepoints Add poll points to native generated code. These are effectively zero-sized allocations and fix some signal and remembered set issues. Also multicore prerequisite. (Sadiq Jaffer, Stephen Dolan, Damien Doligez, Xavier Leroy, Anmol Sahoo, Mark Shinwell, review by Damien Doligez, Xavier Leroy, and Mark Shinwell) [10039] <https://github.com/ocaml/ocaml/issues/10039> New bug fixes ┄┄┄┄┄┄┄┄┄┄┄┄┄ • [10449]: Fix major GC work accounting (the GC was running too fast). (Damien Doligez, report by Stephen Dolan, review by Nicolás Ojeda Bär and Sadiq Jaffer) • [10454]: Check row_more in nondep_type_rec. (Leo White, review by Thomas Refis) • [10468]: Correctly pretty print local type substitution, e.g. type t := …, with -dsource (Matt Else, review by Florian Angeletti) • [10461], [10498]: `caml_send*' helper functions take derived pointers as arguments. Those must be declared with type Addr instead of Val. Moreover, poll point insertion must be disabled for `caml_send*', otherwise the derived pointer is live across a poll point. (Vincent Laviron and Xavier Leroy, review by Xavier Leroy and Sadiq Jaffer) • [10478]: Fix segfault under Windows due to a mistaken initialization of thread ID when a thread starts. (David Allsopp, Nicolás Ojeda Bär, review by Xavier Leroy) • [9525], [10402]: ocamldoc only create paragraphq at the toplevel of documentation comments (Florian Angeletti, report by Hendrik Tews, review by Gabriel Scherer) • [10206]: Split labels and polymorphic variants tutorials Splits the labels and polymorphic variants tutorial into two. Moves the GADTs tutorial from the Language Extensions chapter to the tutorials. (John Whitington, review by Florian Angeletti and Xavier Leroy) [10449] <https://github.com/ocaml/ocaml/issues/10449> [10454] <https://github.com/ocaml/ocaml/issues/10454> [10468] <https://github.com/ocaml/ocaml/issues/10468> [10461] <https://github.com/ocaml/ocaml/issues/10461> [10498] <https://github.com/ocaml/ocaml/issues/10498> [10478] <https://github.com/ocaml/ocaml/issues/10478> [9525] <https://github.com/ocaml/ocaml/issues/9525> [10402] <https://github.com/ocaml/ocaml/issues/10402> [10206] <https://github.com/ocaml/ocaml/issues/10206> Removed feature ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [ *breaking change* ] [9811]: remove propagation from previous branches Type information inferred from previous branches was propagated in non-principal mode. Revert this for better compatibility with -principal mode. For the time being, infringing code should result in a principality warning. (Jacques Garrigue, review by Thomas Refis and Gabriel Scherer) The up-to-date list of changes for OCaml 4.13 is available at <https://github.com/ocaml/ocaml/blob/4.13/Changes> . [9811] <https://github.com/ocaml/ocaml/issues/9811> OCamlFormat 0.19.0 ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-19-0/8167/1> Guillaume Petiot announced ────────────────────────── We are happy to announce the release of [OCamlFormat 0.19.0]. OCamlformat is an auto-formatter for OCaml code, writing the parse tree and comments in a consistent style, so that you do not have to worry about formatting it by hand, and to speed up code review by focusing on the important parts. OCamlFormat is beta software. We expect the program to change considerably before we reach version 1.0.0. In particular, upgrading the `ocamlformat` package will cause your program to get reformatted. Sometimes it is relatively pain-free, but sometimes it will make a diff in almost every file. We are working towards having a tool that pleases most usecases in the OCaml community, please bear with us! To make sure your project uses the last version of ocamlformat, please set ┌──── │ version=0.19.0 └──── in your `.ocamlformat' file. Main changes in `ocamlformat.0.19.0' are: • OCaml 4.13 features are supported • `ppxlib' dependency has been dropped • A new `line-endings={lf,crlf}' option has been added for windows compatibility Here is the [full list of changes]. 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 have a [FAQ for new users ] that should help you decide if ocamlformat is the right choice for you. [OCamlFormat 0.19.0] <https://github.com/ocaml-ppx/ocamlformat> [full list of changes] <https://github.com/ocaml-ppx/ocamlformat/releases/tag/0.19.0> [FAQ for new users ] <https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users> Nicolás Ojeda Bär then added ──────────────────────────── A new `line-endings={lf,crlf}' option has been added for windows compatibility Just to expand a bit on this feature: previously, `ocamlformat' would use the system EOL convention (ie LF on Unix-like OSs and CRLF on Windows). This meant that if you applied `ocamlformat' on systems with different EOL conventions, you would get a diff on every line on every file purely due to the changed newlines. Furthermore, this meant `ocamlformat' was hard to use if your project used LF on Windows (a common usage). With the new option, `ocamlformat' enforces a given EOL convention. The system EOL convention is no longer used for any purpose and the EOL convention used is the one specified in `ocamlformat''s config (LF by default). OCaml Café: Wed, Aug 4 @ 7pm (U.S. Central) ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-cafe-wed-aug-4-7pm-u-s-central/8169/1> Michael Bacarella announced ─────────────────────────── Please join us at the next OCaml Cafe, a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Bring your code and we’ll be happy to review it, assist with debugging, and provide recommendations for improvement. This month, OCaml Café will consist of two parts. First, Rudi Grinberg of [OCaml Labs] will present an informal introduction to [Dune], the OCaml build system. Learn about Dune from one the people developing it. Following Rudi’s presentation, we will open the discussion to all things OCaml-related. Full [Zoom meeting details here]. • Add to your [Google Calendar] • Add to your [iCal] [OCaml Labs] <https://ocamllabs.io/> [Dune] <https://dune.build/> [Zoom meeting details here] <https://hfpug.org/event/ocaml-cafe-introduction-to-dune-and-open-forum/> [Google Calendar] <https://www.google.com/calendar/event?action=TEMPLATE&text=OCaml+Caf%C3%A9%3A+Introduction+to+Dune+and+Open+Forum&dates=20210804T190000/20210804T210000&details=OCaml+Caf%C3%A9+offers+a+friendly%2C+low+stakes+opportunity+to+ask+questions+about+the+OCaml+language+and+ecosystem%2C+work+through+programming+problems+that+you%E2%80%99re+stuck+on%2C+and+get+feedback+on+your+code.+Especially+geared+toward+new+and+intermediate+users%2C+experienced+OCaml+developers+will+be+available+to+answer+your+questions.%C2%A0+Bring+your+code+and+we%26%238217%3Bll+be+happy+to+review+it%2C+assist+with+debugging%2C+and+provide+recommendations+for+improvement.+%0AThis+month%2C+OCaml+Caf%C3%A9+will+consist+of+two+parts.%C2%A0+First%2C+Rudi+Grinberg+of+OCaml+Labs+will+present+an+informal+introduction+to+Dune%2C+the+OCaml+build+system.%C2%A0+Learn+about+Dune+from+one+the+people+developing+it.%C2%A0+Following+Rudi%26%238217%3Bs+presentation%2C+we+will+open+the+discussion+to+all+things+OCaml-related.+%0AWhether+you%E2%80%99re+still+trying+to+make+sense+of+currying+or+can+spot+non-tail-recursive+code+from+across+the+room%2C+we+hope+that+you%E2%80%99ll+join+us+with+your+questions+about+OCaml%2C+or+just+to+hang+out+with+the+OCaml+community.+%0A%0AClaude+Ru+%28View+Full+Event+Description+Here%3A+https%3A%2F%2Fhfpug.org%2Fevent%2Focaml-cafe-introduction-to-dune-and-open-forum%2F%29&location=Zoom&trp=false&sprop=website:https://hfpug.org&ctz=America%2FChicago> [iCal] <https://hfpug.org/event/ocaml-cafe-introduction-to-dune-and-open-forum/?ical=1> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 44538 bytes --]
[-- Attachment #1: Type: text/plain, Size: 19204 bytes --] Hello Here is the latest OCaml Weekly News, for the week of July 20 to 27, 2021. Table of Contents ───────────────── pyre-ast: full-fidelity Python parser in OCaml OCaml+Opam Images for Docker for Windows Borns a stream talking about OCaml/Reason & ReScript language An Update on the State of the PPX Ecosystem and `ppxlib''s Transition How to send email from Dream Old CWN pyre-ast: full-fidelity Python parser in OCaml ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pyre-ast-full-fidelity-python-parser-in-ocaml/8177/1> Jia Chen announced ────────────────── I am happy to announce the initial opam release of [`pyre-ast'], a Python parsing library. The library features its full-fidelity to the official Python spec. Apart from a few technical edge cases, as long as a given file can be parsed/rejected by the CPython interpreter, `pyre-ast' will be able to parse/reject it as well. Furthermore, abstract syntax trees obtained from `pyre-ast' is guaranteed to 100% match the results obtained by Python's own `ast.parse' API, down to every AST node and every line/column number. Another notable feature of this library is that it represents the Python syntax using the *tagless-final style*. This style typically offers more flexibility and extensibility for the downstream consumers of the syntax, and allow them to build up their analysis without explicitly constructing a syntax tree. That said, for developers who are less familiar with the tagless-final approach, we also offer alternative interfaces that operates on traditional syntax tree represented as algebraic data types. Documentation of the library can be found [here]. The reason why we can can claim full-conformance with CPython is really simple: the library is, under the hood, merely an OCaml wrapper around the parsing logic in CPython source code. The project was initially motivated to replace the custom `menhir'-based parser currently used in the Pyre type checker (hence the name), but I figured that it would be useful to release this as a standalone `opam' package to the community so other static Python analyzers or other DSLs with Python-based syntax can leverage it as well. The library has yet to be put into production for Pyre (I'm working on it though) so please do expect bugs/jankiness at times. Feedback and bug reports are very welcomed. Happy parsing! [`pyre-ast'] <https://github.com/grievejia/pyre-ast> [here] <https://grievejia.github.io/pyre-ast/doc/pyre-ast/> OCaml+Opam Images for Docker for Windows ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-opam-images-for-docker-for-windows/8179/1> Antonin Décimo announced ──────────────────────── I'm glad to announce the availability of OCaml and opam [native Windows Container][windows-containers] images for Docker for Windows. This is the result of my hard work at Tarides, with precious help from @dra27, @talex5, @avsm, and the rest of the team. They can be found under the [ocaml/opam][hub] repository in the Docker Hub. Try them with [Docker for Windows][docker-for-windows]! Be sure to [switch Docker to Native Windows Containers][enable-native]. ┌──── │ docker run -it ocaml/opam:windows-mingw │ docker run -it ocaml/opam:windows-msvc └──── We provide images for the mingw-w64 (from OCaml 4.02 to 4.12) and the MSVC (from OCaml 4.06 to 4.12) ports. They are based on each release of Windows 10 amd64 currently supported by [Microsoft on the Docker Hub][mcr]. The images use opam 2.0, and we plan to update to opam 2.1 when it's released. The images also ship a [Cygwin][cygwin] installation, [Git for Windows][git-for-windows], and the [winget package manager][winget]. We use @fdopen's [OCaml for Windows][ocaml-for-windows] distribution and opam-repository fork. As it is getting deprecated at the end of August 2021, we'll transition to opam 2.1 and the standard opam-repository when that happens. In order to get the correct environment for any `RUN' command involving OCaml or opam, prefix the command with • `ocaml-env exec --64 --' if based on mingw-w64; or • `ocaml-env exec --64 --ms=vs2019 --' if based on MSVC. The images are built at <https://base-images.ocamllabs.io/>, using an [OCurrent][ocurrent] pipeline that [builds Docker images][docker-base-images]. You can rebuild them yourself using the [OCluster][ocluster] set of tools that I have ported to Windows. We provide a comprehensive set of tags (replace _port_ with either _mingw_ or _msvc_): • `windows-port': the latest version of OCaml for each Windows version; • `windows-port-winver': the latest version of OCaml for Windows 10 _winver_; • `windows-port-ocaml-mlver': OCaml version _mlver_ for each Windows version; • `windows-port-winver-ocaml-mlver': OCaml version _mlver_ for Window 10 _winver_. When the Windows version is not specified in the tag, the image is a multiarch image that will work on every supported version of Windows 10. Docker automatically selects the appropriate one based on the host version. We will be using these images in the upcoming `ocaml-ci' and `opam-repo-ci' for Windows. Further work on these include the transition to opam 2.1, and we'll provide the Cygwin port of OCaml when it's fixed upstream and available in the Cygwin package repository. Happy hacking! Borns a stream talking about OCaml/Reason & ReScript language ═════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-borns-a-stream-talking-about-ocaml-reason-rescript-language/8185/1> David Sancho announced ────────────────────── I'm very excited to announce starting a new show in Twitch to bring OCaml, Reason and ReScript community best brains to casually talk. It's called emelleTV It's made by [@fakenickels] and myself [@davesnx], and we will try to do our best! Our first guest is [@___zth___] <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/e9f08607687aeb843968a430e4e9082541cf87c2_2_1380x690.jpeg> We go live on [http://twitch.tv/emelletv] next Wednesday. Subscribe to not miss it! Thanks for reading, hope to see you there! [@fakenickels] <https://twitter.com/fakenickels> [@davesnx] <https://twitter.com/davesnx> [@___zth___] <https://twitter.com/___zth___> [http://twitch.tv/emelletv] <http://twitch.tv/emelletv> An Update on the State of the PPX Ecosystem and `ppxlib''s Transition ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/an-update-on-the-state-of-the-ppx-ecosystem-and-ppxlib-s-transition/8200/1> Sonja Heinze announced ────────────────────── I hope you're all having a nice summer (or a nice whichever season you're in, of course)! We've set up a new [wiki page on the ppxlib repository] containing a status overview of the current `ppxlib' transition, which aims at keeping the PPX ecosystem always up-to-date. We'll keep that wiki page up-to-date, as well. @jeremiedimino and @NathanReb have already explained our three-part plan for this transition in different posts here on discuss. Nothing has changed in that plan, but it has been a while since we [last posted about the overall transition] and even longer since we [last posted about the `Astlib' transition in detail]. So if you want, you can refresh your memory about that transition and get updated about its current state (in more detail than the new wiki page) by reading this post. [wiki page on the ppxlib repository] <https://github.com/ocaml-ppx/ppxlib/wiki/The-State-of-the-PPX-Transition> [last posted about the overall transition] <https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296> [last posted about the `Astlib' transition in detail] <https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231> Which Issues `ppxlib' was Facing ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ With `ocaml-migrate-parsetree' (`OMP'), the PPX ecosystem became cross-compiler-compatible. With `ppxlib', the latest compiler features were supported more easily and broadly within the PPX ecosystem, while `ppxlib' also brought along other improvements such as the one in performance and the clear composition semantics when using several PPXs. With that, both `OMP' and `ppxlib' have taken away several maintenance burdens from the PPX maintainers and have created a more homogeneous and up-to-date PPX ecosystem. However, we were facing the following issues: 1. To keep the PPX ecosystem cross-compiler compatible 1. `ppxlib' was handling parts of the unstable `compiler-libs' API to abstracting them away; 2. the `OMP~/~ppxlib' maintainers needed to keep the AST migration information up-to-date by coordination with the compiler devs. 2. To guarantee new feature support, `ppxlib' needed to bump the `ppxlib' AST to the newest version. 3. Bumping the AST implies a breaking change. That was an issue for a homogeneous and up-to-date PPX ecosystem. 4. Not all PPXs migrated from `OMP' to `ppxlib'. That was also an issue for a homogeneous and up-to-date PPX ecosystem. Some time ago, there was the very ambitious plan of tackling Issues 1, 2, and 3 all at once by writing a stable AST abstraction and upstreaming it to the compiler. That plan has been put on ice for now. Instead we're currently on track with a more down-to-earth plan, outlined below. Tackling the Issues in Three Parts ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The plan we're currently following contains three simultaneous parts. It approaches three of the four issues I've pointed out above. However, it leaves the need to bump the AST (Issue 2) untouched. Part One: `Astlib' as an Interface between `ppxlib' and the Compiler ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ The first part works towards continuous cross-compiler compatibility (Issue 1 above) while making the situation of still having PPXs based on `OMP' (Issue 4 above) even more of a problem. It consists of implementing an interface module called `Astlib' between `ppxlib' and the compiler, then upstreaming it to the compiler. As long as `Astlib' is stable and up-to-date, the rest of `ppxlib' won't be affected by any compiler changes—neither by new AST versions nor by compiler library changes. The first step of this part of the plan was moving the `OMP' driver and other `OMP' features from `OMP' to `ppxlib'. That was done in August 2020, and it introduced `OMP2'. Since the PPX driver has to be unique, this was the start of having the PPX ecosystem split into the two incompatible worlds of `OMP1' PPXs on one hand and `ppxlib' PPXs on the other hand. By now, we have written [`Astlib' as an internal `ppxlib' library] and have reduced `ppxlib''s compiler library usage as much as possible to keep `Astlib' minimal. As you can see, it contains a minimal compiler library sub-API in addition to the former `OMP' modules of our supported ASTs and the migration information between them. We will upstream `Astlib' to the compiler asking for it to be kept stable and up-to-date, while also keeping our local copy for old compiler support. [`Astlib' as an internal `ppxlib' library] <https://github.com/ocaml-ppx/ppxlib/tree/master/astlib> Part Two: Sending Patch PRs when Bumping the AST ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ So, thanks to Part One of the plan, `ppxlib' will always be compatible with the development compiler _OCaml trunk_ and the newest compiler version. However, to also support the newest compiler features, we need to bump the internal `ppxlib' AST to the newest version. That modifies some of the AST nodes and so it breaks any PPX that rewrites one of those nodes (Issue 3 above). Usually just a handful of PPXs are affected, but we still want them to be up-to-date. Our current plan doesn't provide a solution for that problem, but it does make handling the problem more efficient and, once again, it takes away the burden from the PPX maintainers. Since the AST bump to `4.10', whenever we bump the AST, we send patch PRs to the PPXs we break. Not much has changed since February, when @NathanReb last [explained our workflow of sending patch PRs] in detail. To some it up: we create a workspace with all `ppxlib' reverse dependencies on opam fulfilling a certain standard, which we call the _ppx-universe_. We then fix the PPXs that break all at once and open the PRs. Lately, the _ppx-universe_ has also proven very useful to make well-founded decisions regarding our API by having an easy look at our reverse dependencies. You can find a [_ppx-universe_ snapshot], currently from March, on our repo. In our experience, once the _ppx-universe_ is created and "builds up to the expected breakages," writing a couple of patches takes very little time, so we plan to make the tooling that creates and interacts with the workspace more sophisticated. [explained our workflow of sending patch PRs] <https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296> [_ppx-universe_ snapshot] <https://github.com/ocaml-ppx/ppx_universe> Part Three: Porting PPXs to Put an End to the "Split-World Situation" ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ As explained above, Part One split the PPXs into the two incompatible worlds of `OMP1' PPXs on one hand and `ppxlib' PPXs on the other hand. That made the fact that some PPXs were still based on `OMP' (Issue 4 above) even more of a problem. For some PPX maintainers, the reason to avoid porting their PPXs to `ppxlib' was that `ppxlib' depended on `base' and `stdio', so we decided to tackle this situation by three means: • Dropping the `base' and the `stdio' dependencies, which was done in August last year. Now, all dependencies are the very basic `ocaml', `dune', `ocaml-compiler-libs', `stdlib-shims', `sexplib0' and `ppx_derivers'. • Porting and reviewing some of the most important PPXs ourselves. So far we've ported `js_of_ocaml', `bisect_ppx', and `tyxml' with the help of the respective maintainers, and we've also reviewed several ports. • Spreading the word about the need to port PPXs and asking for help. About a year ago, we made a non-exhaustive [list of PPXs that needed to be ported]. Since then, this community has proven to be awesome and there has been an amazing porting effort by a lot of people. So by now, all packages on that list have been ported with the exception of one(*). So hopefully the "split world" situation can soon be considered past. :tada: By the way, thanks to all involved in porting PPXs to `ppxlib'! It has been a great joint effort so far. :heart: And if anyone still has or comes across a project somewhere that needs porting and wants to port it, that's awesome! You can find the full list of opam packages that are still stuck in the `OMP1' world by [filtering for them in opam's health check pipeline]. However, notice that that's a generated list, so it also contains libraries that intrinsically form part of the `OMP1' ecosystem (such as `ppx_tools_versioned'), PPXs that have already been ported but haven't relesed their port on opam yet (such as `graphql_ppx'), deprecated PPXs that aren't marked as deprecated yet (such as `mirage-dns'), and several PPXs that only transitively depend on `OMP1'. (*) `ppx_import' has a PR for a port to `ppxlib', but it's not quite ready to be merged just yet. [list of PPXs that needed to be ported] <https://github.com/ocaml-ppx/ppxlib/issues?q=is%3Aissue+label%3Aport-to-ppxlib+> [filtering for them in opam's health check pipeline] <http://check.ocamllabs.io:8080/?comp=4.12&available=4.12&show-latest-only=true&sort-by-revdeps=true&maintainers=&logsearch=ocaml-migrate-parsetree%5C.1%5C.8%5C.0&logsearch_comp=4.12> How to send email from Dream ════════════════════════════ Archive: <https://discuss.ocaml.org/t/how-to-send-email-from-dream/8201/1> Joe Thomas announced ──────────────────── I’ve written a short [blog post ] about what I learned building simple email features for a web server written in the Dream framework. The accompanying source code is available here: <https://github.com/jsthomas/dream-email-example> I’m interested in adding more examples and tutorials to the OCaml ecosystem and would be happy to get your feedback, positive or negative, on this write-up (here or via email/github/discord). [blog post ] <https://jsthomas.github.io/ocaml-email.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 30858 bytes --]
[-- Attachment #1: Type: text/plain, Size: 10581 bytes --] Hello Here is the latest OCaml Weekly News, for the week of August 03 to 10, 2021. Table of Contents ───────────────── Lwt 5.4.2 OCaml Workshop 2021: Call for Volunteers opam 2.1.0! containers 3.5 Short contract job for OCaml/C++ programmer http-multipart-formdata v3.0.1 released wtr (Well Typed Router) v2.0.0 released New playlist just dropped Other OCaml News Old CWN Lwt 5.4.2 ═════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-4-2/8248/1> Raphaël Proust announced ──────────────────────── We are glad to announce the release of version 5.4.2 of Lwt: a bugfix-only release. <https://github.com/ocsigen/lwt/releases/tag/5.4.2> You can update to this version in `opam' : ┌──── │ opam update │ opam upgrade lwt └──── Thanks to the contributors for finding and fixing the bugs, leading to this release. Check out the release notes (link above) for a full list. OCaml Workshop 2021: Call for Volunteers ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-workshop-2021-call-for-volunteers/8253/1> Frédéric Bour announced ─────────────────────── The OCaml Workshop will be held virtually, just like last year. We are looking for volunteers to fill the role of session host. [Session Hosts] ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ On August 27, the session hosts will assist session chairs in streaming the pre-recorded videos as well as helping and moderating the Q&A sessions. They will also be responsible for security and be ready to react to potential threats and wrongdoers. This year there will be only one broadcast for each session, but the workshop day will be quite long. There will be six sessions, lasting one hour and a half, as well as a one hour keynote. [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> opam 2.1.0! ═══════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0/8255/1> R. Boujbel announced ──────────────────── We are happy to announce two opam releases: the freshly new [2.1.0] & the LTS support [2.0.9]. [2.1.0] <https://github.com/ocaml/opam/releases/tag/2.1.0> [2.0.9] <https://github.com/ocaml/opam/releases/tag/2.0.9> What's new in opam 2.1.0? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Integration of system dependencies (formerly the `opam-depext` plugin), increasing their reliability as it integrates the solving step • Creation of lock files for reproducible installations (formerly the `opam-lock` plugin) • Switch invariants, replacing the _"base packages"_ in opam 2.0 and allowing for easier compiler upgrades • Improved options configuration (see the new `option` and expanded `var` sub-commands) • CLI versioning, allowing cleaner deprecations for opam now and also improvements to semantics in future without breaking backwards-compatibility • opam root readability by newer and older versions, even if the format changed • Performance improvements to opam-update, conflict messages, and many other areas You'll find these features presentation in the [blog post] ; and for a full complete you can take a look [pre-releases changelogs]. [blog post] <https://opam.ocaml.org/blog/opam-2-1-0> [pre-releases changelogs] <https://github.com/ocaml/opam/releases> What's in 2.0.9 ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This 2.0.9 version contains back-ported fixes, you can find more information in this [blog post], especially for fish users & sandbox updates. *Tremendous thanks to all involved people, all those who've tested, re-tested, tested again, given feedback, commented on issues, tested, tested, tested again…!* /The opam team/ 🐪 [blog post] <https://opam.ocaml.org/blog/opam-2-0-9> containers 3.5 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-containers-3-5/8257/1> Simon Cruanes announced ─────────────────────── I'm glad to announce that version 3.5 of [containers] has just been released. There's a bugfix for bitvectors, and a tasteful assortment of new functions (see changelog). I want to thank all the contributors, among whom first time contributor @favonia. The release and changelog can be found [here] [containers] <https://github.com/c-cube/ocaml-containers> [here] <https://github.com/c-cube/ocaml-containers/releases/tag/v3.5> Short contract job for OCaml/C++ programmer ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/short-contract-job-for-ocaml-c-programmer/8260/1> Ashish Agarwal announced ──────────────────────── We have a small project (possibly only days of work) for an experienced OCaml and C++ programmer. If you are available for a short engagement as a contractor, please DM me. Thank you. http-multipart-formdata v3.0.1 released ═══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v3-0-1-released/8261/1> Bikal Lem announced ─────────────────── I am pleased to announce v3.0.1 of `http-multipart-formdata'. This release follows a major overhaul of the parser as well as the design of the library. Here is the summary of changes: 1. Flatten module `Part_header' to `part_header' 2. Implement reader/pull based parser to retrieve multipart parts, i.e. implement a `streaming' design. This is very useful if the HTTP file upload is large. 3. Implement push-based incremental input model, i.e. the library is now a non-blocking multipart parser 4. Remove dependency on IO based libs such as `lwt, async' since it is no longer needed due to point 3 above. Github repo: [http-multipart-formdata] API doc : [API manual] [http-multipart-formdata] <https://github.com/lemaetech/http-multipart-formdata> [API manual] <https://lemaetech.co.uk/http-multipart-formdata/http-multipart-formdata/Http_multipart_formdata/index.html> wtr (Well Typed Router) v2.0.0 released ═══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-wtr-well-typed-router-v2-0-0-released/8262/1> Bikal Lem announced ─────────────────── I am pleased to announce v2.0.0 release of `wtr (Well Typed Router)'. `wtr' is a trie-based router for OCaml HTTP web applications. v2.0.0 release adds support for specifying and matching HTTP methods in a router. So now we can do the following; ┌──── │ Wtr.( │ create │ [ {%wtr| get,post,head,delete ; /home/about/ |} about_page │ ; {%wtr| head ; /home/:int/ |} prod_page │ ] └──── Note: we can specify single or multiple HTTP methods supported by a route. The release also features a pretty-printer - `Wtr.pp' - for a `Wtr.t' type. This has proven to be very useful when diagnosing/understanding routing issues. Sample output below, ┌──── │ POST │ /home │ /about │ / │ /:float │ / │ HEAD │ /home │ /about │ / │ /:int │ / └──── The manual has also been improved in this release. • [wtr API] • [CoHTTP demo] • [CLI demo] • [Changes v2.0.0] [wtr API] <https://lemaetech.co.uk/wtr/wtr/Wtr/index.html> [CoHTTP demo] <https://github.com/lemaetech/wtr/blob/main/examples/cohttp.ml> [CLI demo] <https://github.com/lemaetech/wtr/blob/main/examples/demo.ml> [Changes v2.0.0] <https://github.com/lemaetech/wtr/blob/main/CHANGES.md#v200-2021-08-02> New playlist just dropped ═════════════════════════ Archive: <https://discuss.ocaml.org/t/new-playlist-just-dropped/8272/1> Rahul announced ─────────────── Haven't watched them all yet, but these look like they'd be a great resource for anyone wanting to learn OCaml: <https://www.youtube.com/watch?v=MUcka_SvhLw&list=PLre5AT9JnKShBOPeuiD9b-I4XROIJhkIU> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [opam 2.1.0 is released!] • [opam 2.0.9 release] [OCaml Planet] <http://ocaml.org/community/planet/> [opam 2.1.0 is released!] <https://www.ocamlpro.com/2021/08/05/opam-2-1-0-is-released/> [opam 2.0.9 release] <https://www.ocamlpro.com/2021/08/05/opam-2-0-9-release/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 22895 bytes --]
[-- Attachment #1: Type: text/plain, Size: 9249 bytes --] Hello Here is the latest OCaml Weekly News, for the week of August 10 to 17, 2021. Table of Contents ───────────────── http-multipart-formdata v3.0.1 released Call for participation: ML Family Workshop 2021 Coq-of-ocaml to translate OCaml to Coq Old CWN http-multipart-formdata v3.0.1 released ═══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v3-0-1-released/8261/2> Continuing the thread from last week, Hannes Mehnert asked ────────────────────────────────────────────────────────── Thanks for your work on that. I'm curious about the different "multipart" libraries now available for OCaml – anyone has a brief comparison of them? • [http-multipart-formdata] as announced above • [multipart_form] by @dinosaure • [multipart-form-data] by cryptosense Are there functional differences? Correctness? Performance? Or just a matter of style and co-development? [http-multipart-formdata] <https://github.com/lemaetech/http-multipart-formdata> [multipart_form] <https://github.com/dinosaure/multipart_form/> [multipart-form-data] <https://github.com/cryptosense/multipart-form-data> Bikal Lem replied ───────────────── One obvious difference among the three is `http-multipart-formdata' doesn't depend on any IO/Promise libraries, such as lwt or async. so you may find it easier to integrate in your project. `mulitpart-form-data' exposes a callback based streaming api, whereas http-multipart-formdata exposes a non-callback, non-blocking based API streaming api. The API surface of `http-multipart-formdata' is kept as low as possible, primarily 3 API calls - `boundary, reader' and `read' call. The dependency list of `http-multipart-formdata' is the thinnest. This may or may not be an issue depending on your aesthetics. However, relatively/comparatively the less your dependencies, the easier it is to integrate the lib with other OCaml libs and environments such as various OSes. Bikal Lem added ─────────────── I should also add `http-multipart-formdata' has been implemented with zero-copy streaming and minimal allocation in mind. Call for participation: ML Family Workshop 2021 ═══════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-08/msg00005.html> Jonathan Protzenko announced ──────────────────────────── We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. We invite you to subscribe to, and attend the workshop, in addition to the main ICFP conference. We are thrilled to announce that Don Syme will give this year's keynote: "Narratives and Lessons from The Early History of F#". Please join us! The program features 14 exciting submissions, including 4 short talks. The workshop will be held online in the 6pm-3am time band (Seoul Time). Talks will be pre-recorded and uploaded online for those who cannot attend. • Program: <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#program> • Keynote: <https://icfp21.sigplan.org/details/mlfamilyworkshop-2021-papers/15/Keynote-Narratives-and-Lessons-from-The-Early-History-of-F>- • ICFP home: <http://icfp21.sigplan.org/home> Program committee ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Danel Ahman (University of Ljubljana) • Robert Atkey (University of Strathclyde) • Frédéric Bour (Tarides) • Ezgi Çiçek (Facebook London) • Youyou Cong (Tokyo Institute of Technology) • Richard A. Eisenberg (Tweag I/O) • Martin Elsman (University of Copenhagen, Denmark) • Ohad Kammar (University of Edinburgh) • Naoki Kobayashi (University of Tokyo, Japan) • Benoît Montagu (Inria) • Jonathan Protzenko (Microsoft Research) (Chair) • Kristina Sojakova (INRIA Paris) • Don Syme (Microsoft) • Matías Toro (University of Chile) • Katsuhiro Ueno (Tohoku University) Coq-of-ocaml to translate OCaml to Coq ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/coq-of-ocaml-to-translate-ocaml-to-coq/8288/1> Guillaume Claret announced ────────────────────────── I am pleased to present the [coq-of-ocaml] project, to translate a subset of OCaml to the [Coq] proof assistant. The aim is to do formal verification on OCaml programs. The idea is to generate a Coq translation as close as possible to the original code in terms of intent but using the Coq syntax. As a short example, if we take the following OCaml code and run `coq-of-ocaml': ┌──── │ type 'a tree = │ | Leaf of 'a │ | Node of 'a tree * 'a tree │ │ let rec sum tree = │ match tree with │ | Leaf n -> n │ | Node (tree1, tree2) -> sum tree1 + sum tree2 └──── we get the following Coq file: ┌──── │ Require Import CoqOfOCaml.CoqOfOCaml. │ Require Import CoqOfOCaml.Settings. │ │ Inductive tree (a : Set) : Set := │ | Leaf : a -> tree a │ | Node : tree a -> tree a -> tree a. │ │ Arguments Leaf {_}. │ Arguments Node {_}. │ │ Fixpoint sum (tree : tree int) : int := │ match tree with │ | Leaf n => n │ | Node tree1 tree2 => Z.add (sum tree1) (sum tree2) │ end. └──── We support the following OCaml features: • the core of OCaml (functions, let bindings, pattern-matching,…) • type definitions (records, inductive types, synonyms, mutual types) • monadic programs • modules as namespaces • modules as polymorphic records (signatures, functors, first-class modules) • multiple-file projects (thanks to Merlin) • both `.ml' and `.mli' files • existential types (we use impredicative sets option in Coq) We also have some support for the GADTs, the polymorphic variants, and the extensible types. We are in particular working on having an axiom-free translation of the GADTs to Coq. We do not support: • side-effects outside of a monad (references, exceptions, …); • object-oriented programming; • various combinations of OCaml features for which `coq-of-ocaml' should generate a warning. Our main example and use case is the [coq-tezos-of-ocaml] project. This contains a translation of most of the [economic protocol] of the [Tezos] blockchain (around 30.000 lines of OCaml translated to 40.000 lines of Coq). For example, we verify the comparison functions defined in [src/proto_alpha/lib_protocol/script_comparable.ml] with [src/Proto_alpha/Proofs/Script_comparable.v]. We are looking for the application to other projects too. We think the best way to use `coq-of-ocaml' is to continue developing in OCaml and run `coq-of-ocaml' to keep a synchronized translation in Coq. Having a working Coq translation (as compiling in Coq) forces us to avoid some OCaml constructs. We believe these constructs would probably be hard to verify anyway. Then, on the Coq side, we can verify some important or easy to catch properties. If there is a regression in the OCaml code, re-running `coq-of-ocaml' should make the proofs break. [coq-of-ocaml] <https://clarus.github.io/coq-of-ocaml/> [Coq] <https://coq.inria.fr/> [coq-tezos-of-ocaml] <https://nomadic-labs.gitlab.io/coq-tezos-of-ocaml/> [economic protocol] <https://gitlab.com/tezos/tezos/-/tree/master/src/proto_alpha/lib_protocol> [Tezos] <https://tezos.com/> [src/proto_alpha/lib_protocol/script_comparable.ml] <https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/script_comparable.ml> [src/Proto_alpha/Proofs/Script_comparable.v] <https://nomadic-labs.gitlab.io/coq-tezos-of-ocaml/docs/proofs/script_comparable> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 20527 bytes --]
[-- Attachment #1: Type: text/plain, Size: 13392 bytes --] Hello Here is the latest OCaml Weekly News, for the week of August 17 to 24, 2021. Table of Contents ───────────────── routes v1.0.0 released Feather 0.3.0 Release of GopCaml-mode (0.0.3) and GopCaml-mode-Merlin (0.0.4) - Wizardry release Share my experience about running OCaml on WebAssembly Old CWN routes v1.0.0 released ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-routes-v1-0-0-released/8319/1> Anurag Soni announced ───────────────────── I'd like to announce release of version 1.0.0 of [routes]. The PR to opam repository has been merged, and the new release should be available via opam once the package cache refreshes. *Routes* provides a DSL for bi-directional URI dispatch. It allows writing route definitions that can be used for both matching, and printing URI paths. Changes since the last opam release: • Support for merging two routers by adding a union operation ([#115], [@Chattered]) • Support for wildcard parameters ([#118], [#129], [@Lupus]) -> Compile time checks ensure that wildcard parameters can only be defined at the end of a route • Support `map' operation for path parameter definitions, and support defining path prefixes that can be pre-prended to other routes ([#121], [@Chattered]) • Addition of a `ksprintf' style function for routes. ([#123], [@Chattered]) Examples of how to use the library are available in the [tests] and in a [small demo] Documentation can be found [here] *Edit* 1.0.0 is available via opam now - <http://opam.ocaml.org/packages/routes/routes.1.0.0/> [routes] <https://github.com/anuragsoni/routes/> [#115] <https://github.com/anuragsoni/routes/pull/115> [@Chattered] <https://github.com/Chattered> [#118] <https://github.com/anuragsoni/routes/pull/118> [#129] <https://github.com/anuragsoni/routes/pull/129> [@Lupus] <https://github.com/Lupus> [#121] <https://github.com/anuragsoni/routes/pull/121> [#123] <https://github.com/anuragsoni/routes/pull/123> [tests] <https://github.com/anuragsoni/routes/blob/b9bb8a0f50b7bd9fbd0c79113142ea82830ce2bb/test/routing_test.ml> [small demo] <https://github.com/anuragsoni/routes/blob/b9bb8a0f50b7bd9fbd0c79113142ea82830ce2bb/example/no_http.ml> [here] <https://anuragsoni.github.io/routes/> Feather 0.3.0 ═════════════ Archive: <https://discuss.ocaml.org/t/ann-feather-0-3-0/8322/1> Charles announced ───────────────── I'm happy to announce Feather 0.3.0! Feather is a minimal library for bash-like scripting and process execution. ([github/tutorial], [documentation]) This release adds two major features: [github/tutorial] <https://github.com/charlesetc/feather> [documentation] <https://www.charlesetc.com/feather/feather/Feather/index.html> 1. A new interface for collecting the exit status, stdout, and stderr of a Feather command. ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ For example, you can easily print a process's stderr if it exits non-zero: ┌──── │ open Feather;; │ let stderr, status = │ process "ls" [ "/tmp/does-not-exist" ] |> collect stderr_and_status │ in │ if status <> 0 then failwith ("ls failed with stderr:\n" ^ stderr) └──── where the types are ┌──── │ val process : string -> string list -> cmd │ │ type 'a what_to_collect │ val stderr_and_status : (string * int) what_to_collect │ │ val collect : │ ?cwd:string -> │ ?env:(string * string) -> │ 'a what_to_collect -> │ cmd -> │ 'a └──── as you can imagine, we expose several of these `what_to_collect''s. Here's the full set: ┌──── │ val stdout : string what_to_collect │ val stderr : string what_to_collect │ val status : int what_to_collect │ │ val stdout_and_stderr : (string * string) what_to_collect │ val stdout_and_status : (string * int) what_to_collect │ val stderr_and_status : (string * int) what_to_collect │ │ type everything = { stdout : string; stderr : string; status : int } │ val everything : everything what_to_collect └──── We considered different design approaches here. I think what we landed on keeps the call site readable and the types of the interface simple. It should be noted: the simplest way to run a command without collecting anything is to use [Feather.run]. [Feather.run] <https://www.charlesetc.com/feather/feather/Feather/index.html#val-run> 2. The ability to wait on background processes and collect their output. ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Starting with Feather 0.1.0, you were able to start processes in the background, but the only way to wait for them to complete was to use Feather's [async wrapper]. For those wanting an async-less, direct-style interface, we now expose new methods to do this properly: ┌──── │ type 'a background_process │ │ val run_in_background : │ ?cwd:string -> │ ?env:(string * string) Base.list -> │ cmd -> │ unit background_process │ │ val collect_in_background : │ ?cwd:string -> │ ?env:(string * string) list -> │ 'a what_to_collect -> │ cmd -> │ 'a background_process │ │ val wait : 'a background_process -> 'a │ val wait_all : unit -> unit └──── where an example use might be ┌──── │ let server_process = │ process "my-server.exe" [] |> collect_in_background stdout_and_status │ in │ ... do other things ... │ match Feather.wait server_process with │ | (stdout, 0) -> ... │ | (_, 1) -> ... └──── Thanks again to @Firobe and @tmarti2 for their contributions to this release! I think we've made a lot of progress here and I'm excited to see where things go :slight_smile: [async wrapper] <https://www.charlesetc.com/feather/feather_async/Feather_async/index.html> Release of GopCaml-mode (0.0.3) and GopCaml-mode-Merlin (0.0.4) - Wizardry release ══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-3-and-gopcaml-mode-merlin-0-0-4-wizardry-release/8333/1> Kiran Gopinathan announced ────────────────────────── I'm pleased to announce the latest version of *GopCaml-mode* (0.0.3), and the new release of *GopCaml-mode-Merlin* (0.0.4). GopCaml-mode-Merlin is a brand *new!* variant of GopCaml-mode that uses the Merlin parser rather than the OCaml compiler-libs one, and thus has some level of robustness to invalid syntax: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a09586b9db3bf19667b6969c701a40f0791a2a9d.gif> If that's piqued your interest, I'd recommend checking out the release posts for the previous versions for more details on what GopCaml can do, and how to get it: [0.0.2 release], [0.0.1 release] The Merlin parser seems to assign text-regions for syntactic constructs slightly more liberally than the standard OCaml parser, so the overlays can feel a bit weird if you're used to the normal GopCaml overlays, but the benefit is that all your favorite structural movement/transformation operations work even when you're dealing with ill-formed programs, allowing for a more fluid editing experience: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/9/9f2976b47018e2d892b9cea09da913d07f8c1f00.gif> [0.0.2 release] <https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-2-unicode-compatibility-update/7425> [0.0.1 release] <https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310> Detailed Changelog ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • *new!* [for GopCaml-mode-Merlin] *Robustness to ill-formated syntax* • Vendored a copy of Merlin to reuse its parser and thereby gain it's robustness to invalid syntax. • *new!* *Added support for customisable verbosity* • Customise the Emacs variable `gopcaml-messaging-level` to change the level of messages that are output by GopCaml. Set it to `'none` to disable messages entirely. • *new!* *Fixed bug when starting zipper mode at the start of a file.* • Zipper mode selects the immediately prior byte position to avoid inconsistencies when the cursor is just on the edge of an expression, but when the cursor is at position 1, this causes an error as 0 is not a valid point. • *new!* *Special casing of shebangs* • Added support for handling shebangs at the start of a buffer. • Implemented as part of a larger library for preprocessing buffertext before running the parser on it - could be extended to support additional preprocessing in the future. • Another possible direction for extension is to use an Emacs callback to modify the text, although this may not be ideal, as the parsing has to be as fast as possible. Get Gopcaml-mode ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Its as easy as 1, 2, 3! 1. Install from opam (either `gopcaml-mode` xor `gopcaml-mode-merlin`): ┌──── │ opam install gopcaml-mode └──── or ┌──── │ opam install gopcaml-mode-merlin └──── 2. Compile your emacs with support for dynamic modules 3. Load gopcaml-mode in your init.el: ┌──── │ (let ((opam-share (ignore-errors (car (process-lines "opam" "var" "share"))))) │ (when (and opam-share (file-directory-p opam-share)) │ ;; Register Gopcaml mode │ (add-to-list 'load-path (expand-file-name "emacs/site-lisp" opam-share)) │ (autoload 'gopcaml-mode "gopcaml-mode" nil t nil) │ (autoload 'tuareg-mode "tuareg" nil t nil) │ (autoload 'merlin-mode "merlin" "Merlin mode" t) │ ;; Automatically start it in OCaml buffers │ (setq auto-mode-alist │ (append '(("\\.ml[ily]?$" . gopcaml-mode) │ ("\\.topml$" . gopcaml-mode)) │ auto-mode-alist)) │ )) └──── See the [release post ] for version 0.0.1 for detailed instructions on how you can install it. [release post ] <https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310> Contribute ╌╌╌╌╌╌╌╌╌╌ • Github: [GitHub - Gopiandcode/gopcaml-mode: [MIRROR] Ultimate Ocaml Editing Mode] • Gitlab: [Kiran Gopinathan / gopcaml-mode · GitLab ] [GitHub - Gopiandcode/gopcaml-mode: [MIRROR] Ultimate Ocaml Editing Mode] <https://github.com/Gopiandcode/gopcaml-mode> [Kiran Gopinathan / gopcaml-mode · GitLab ] <https://gitlab.com/gopiandcode/gopcaml-mode> Share my experience about running OCaml on WebAssembly ══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/share-my-experience-about-running-ocaml-on-webassembly/8343/1> Vincent Chan announced ────────────────────── In the last two weeks, I was working on migrating OCaml to WebAssembly. I wrote an article to share my experience. [Run OCaml in the browser by WebAssembly | by Vincent Chan | Aug, 2021 | Medium] [Run OCaml in the browser by WebAssembly | by Vincent Chan | Aug, 2021 | Medium] <https://okcdz.medium.com/run-ocaml-in-the-browser-by-webassembly-31ce464594c6> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 27625 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18117 bytes --] Hello Here is the latest OCaml Weekly News, for the week of August 31 to September 07, 2021. Table of Contents ───────────────── Just reinvented OOP v3.OCaml.org: A roadmap for OCaml's online presence Become an Outreachy Mentor: support the growth and diversity of the OCaml community Generating static and portable executables with OCaml OCaml quant-developer at Bloomberg. London or New York HTTP client library Other OCaml News Old CWN Just reinvented OOP ═══════════════════ Archive: <https://discuss.ocaml.org/t/just-reinvented-oop/8399/1> Yawar Amin said ─────────────── ┌──── │ let ( .![] ) obj f = f obj │ │ type person = { id : int; name : string } │ │ let id { id; _ } = id │ │ let bob = { id = 1; name = "Bob" } │ let next_id = bob.![id].![succ] └──── ==> 2 Kiran Gopinathan replied ──────────────────────── Haha, what a coincidence, just did the same very recently while translating a rust library to OCaml: <https://github.com/Gopiandcode/ego/blob/5daf312f8a444f9abcde5996c671b9282727a972/lib/generic.ml#L211> ┌──── │ let eclasses = eg.@[eclasses] in │ let cost_map = Id.Map.create 10 in │ let node_total_cost node = │ let has_cost id = Id.Map.mem cost_map (eg.@[find] id) in │ if List.for_all has_cost (L.children node) │ then let cost_f id = fst @@ Id.Map.find cost_map (eg.@[find] id) in Some (E.cost cost_f │ node) │ else None in │ (* ... *) └──── with `.@[]' defined as: ┌──── │ let (.@[]) self fn = fn self [@@inline always] └──── for bonus(?) points, you can name the first parameter self: ┌──── │ let add_enode self (node: Id.t L.shape) = │ let node = self.@[canonicalise] node in │ (* ... *) └──── I don't normally write code like this in OCaml, but in this case, it made porting from rust easier, because the code mostly looked the same. hyphenrf also replied ───────────────────── You can use the multiple-indexing syntax to implement slicing (well, technically subs) sugar: ┌──── │ let (.:[;..]) s = function │ | [|start; finish|] -> String.sub s start (finish - start) │ | _ -> raise (Invalid_argument "slice takes exactly two indexes") └──── ┌──── │ # "hello world".:[1;5];; │ - : string = "ello" └──── The new indexing syntax is quite versatile :> Kiran Gopinathan added ────────────────────── Oh wow, this is perfect! brb, off to reimplement the python slicing semantics in OCaml: ┌──── │ let (.@[;..]) ls = function[@warning "-8"] │ | [| start; -1 |] -> │ List.to_iter ls │ |> Iter.zip_i │ |> Iter.drop_while (Pair.fst_map ((>) start)) │ |> Iter.map snd │ | [| start; finish |] -> │ List.to_iter ls │ |> Iter.zip_i │ |> Iter.drop_while (Pair.fst_map ((>) start)) │ |> Iter.take_while (Pair.fst_map ((>) finish)) │ |> Iter.map snd │ | [| start; finish; step |] -> │ List.to_iter ls │ |> Iter.zip_i │ |> Iter.drop_while (Pair.fst_map ((>) start)) │ |> Iter.take_while (Pair.fst_map ((>) finish)) │ |> Iter.filter (Pair.fst_map (fun ind -> (ind - start) mod step = 0)) │ |> Iter.map snd └──── v3.OCaml.org: A roadmap for OCaml's online presence ═══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocamls-online-presence/8368/19> Continuing this thread, Anil Madhavapeddy replied to many comments ────────────────────────────────────────────────────────────────── Many thanks for all the constructive comments and suggestions so far, and also for those who have gotten in touch to contribute. Please do keep them coming (either on this thread or on the various issue trackers that @jonludlam and @patricoferris have pointed to). I'll answer some earlier questions here: Having said that, the colors on the [packages landing page ] feel very aggressive to me. Might be my setup here, but I would like to have a slightly less harsh contrast. Also, there is a bit of an overlap in content with [https://ocamlverse.github.io/ ] for some things (eg best practices, community) but the (to me) most valuable feature is missing: The ecosystems overview, where I can find packages sorted thematically. Could such a section also have a place in the packages subpage somewhere? Alternatively, maybe opam can allow to “tag” packages in the future so one could see all packages for graphics, databases etc. The styling of the /packages sub-URL does indeed differ from the main design, but this is simply due to a temporary technical detail. The majority of the site uses React/NextJS to generate the frontend, and this uses the now-trendy medium-contrast colours and also features like fast-page-switching that NextJS offers. However, the documentation portion generated around 2.7 million individual pages when run across the full opam repository, and so we restored to dynamic generation of the content for that. What's going to happen next is a rationalisation of the code across the ReScript and OCaml frontends so that there will be no observable difference in the colour schemes across the full site. Regarding creating a categorised list of recommendations, that is absolutely in scope for the v3 iteration of the site. However, this metadata should ideally live in the opam-repository (for example, using `tags' as you suggest, which opam already supports). If anyone would like to have a go at this, I'd encourage PRs to the opam-repository to add the relevant tag metadata for a codex. Meanwhile, @lambda_foo @tmattio and @patricoferris are working on the core OCaml Platform workflow information for the guides section of the website which will cover opam, merlin, lsp-server, dune and so on. Do we have access to all of the previous years’ workshops to add to [watch.ocaml.org]? I can see pieces of 2015, 2017, 2020 and this year. @avsm Is it possible to add the ML Workshop as well? Absolutely. The watch.ocaml.org has held up nicely after the OCaml Workshop, so I think it's in good shape to populate with more videos. This needs a volunteer to help us upload the past [nine years] of videos from YouTube to watch.ocaml.org. If anyone wants to have a go, please message me and I'll create you an account. It’s a bit unclear what you meant in this paragraph. Does that mean that you plan to kill the ocaml planet ? I would find it a little bit sad. One of the reason why you may feel it doesn’t work well may be that it has been constantly broken in the current version of the site… I'm not sure why you think the current ocaml.org new feed has been broken – it's been working fairly reliably for the past decade. The only real problem came up a few times when a feed's domain expired and got taken over by domain squatters, at which point we got spam into the main page of ocaml.org. What I meant with that part of the announcement is that the syndication feed should not be mistaken with original news on the website. Right now it's difficult to distinguish official announcements (such as compiler or opam releases) as they are a little scattered (e.g. on opam.ocaml.org). The plan is to combine the [platform-blog] with the new website directly. I've also been considering just having a special tag on this forum so that nice announcement posts could also be syndicated to the website easily (for example, @gasche's compiler newsletters). My general desire is to _grow_ the planet feed and syndication system, but to clearly demarcate them as not being published by ocaml.org and to manage them via more modern decentralised techniques that feature spam, moderation and archival. PeerTube is a good example of this for videos that is working well, and I'd welcome suggestions for Atom/RSS (there must be something in this space, ideally ActivityPub-based). Depending on how the experiments go, it's very likely that we'll have a Matrix homeserver for ocaml.org where CI bots can report status information (see this [prototype PR]) for ocaml-ci that will also apply to opam-repository. The goal here is to for ocaml.org to publish its data using an open protocol, which can then be syndicated into whatever technologies are in vogue (e.g. Discord, Slack, Teams, …). So if you spot some decentralised syndication system that you think might be interesting for OCaml, please do let me know. Even better, if you'd like to develop one to tailor it to our needs, let me know even sooner ;-) [packages landing page ] <https://v3.ocaml.org/packages> [https://ocamlverse.github.io/ ] <https://ocamlverse.github.io/> [watch.ocaml.org] <http://watch.ocaml.org> [nine years] <https://ocaml.org/meetings/ocaml/2012/> [platform-blog] <https://github.com/ocaml/platform-blog> [prototype PR] <https://github.com/ocurrent/ocaml-ci/pull/362> Become an Outreachy Mentor: support the growth and diversity of the OCaml community ═══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213/3> Anil Madhavapeddy announced ─────────────────────────── There's been a very disappointing response to this call for mentors to increase the diversity of our community. Precisely *noone* has been in touch for the winter call, leaving the burden of mentorship on the same people that did all the work this summer. Before making [new calls for programs like GSoC], let's get Outreachy onto more sustainable ground please. We are purely limited by mentorship time at present. This can be as simple as organising new first issues for projects in the ecosystem, and all the way to pair programming with a mentee. You can chose how to be involved. [new calls for programs like GSoC] <https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocamls-online-presence/8368/16?u=avsm> Generating static and portable executables with OCaml ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/generating-static-and-portable-executables-with-ocaml/8405/1> OCamlPro announced ────────────────── It has been a few times now that we have been tasked to generate portable binaries for different projects. Over time, we have gathered quite some know-how and, seeing the question frequently arise in the community, we decided to share this experience. You can find the article written by Louis Gesbert on[ the OCamlPro blog] Distributing OCaml software on opam is great (if I dare say so myself), but sometimes you need to provide your tools to an audience outside of the OCaml community, or just without recompilations or in a simpler way. However, just distributing the locally generated binaries requires that the users have all the required shared libraries installed, and a compatible libc. It's not something you can assume in general, and even if you don't need any C shared library or are confident enough it will be installed everywhere, the libc issue will arise for anyone using a distribution based on a different kind, or a little older than the one you used to build. There is no built-in support for generating static executables in the OCaml compiler, and it may seem a bit tricky, but it's not in fact too complex to do by hand, something you may be ready to do for a release that will be published. So here are a few tricks, recipes and advice that should enable you to generate truly portable executables with no external dependency whatsoever. Both Linux and macOS will be treated, but the examples will be based on Linux unless otherwise specified. Don't hesitate to share your thoughts with us, have a good reading! [ the OCamlPro blog] <https://www.ocamlpro.com/2021/09/02/generating-static-and-portable-executables-with-ocaml/> OCaml quant-developer at Bloomberg. London or New York ══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-quant-developer-at-bloomberg-london-or-new-york/8409/1> Philip Craig announced ────────────────────── Extend a financial contracts DSL that is implemented in OCaml. It's London or New York based. It's not a remote position. Please see details and/or apply at (<https://careers.bloomberg.com/job/detail/93825>) HTTP client library ═══════════════════ Archive: <https://discuss.ocaml.org/t/ann-http-client-library/8428/1> Hannes Mehnert announced ──────────────────────── we just released to the opam-repository the [`http-lwt-client'] package, which consists of both a library doing HTTP requests and a binary (`hurl') that does HTTP requests. The code is based on [HTTP/AF] and [H2], and uses [tls] for HTTPS connections. Both HTTP/1(.1) and HTTP/2 protocols are supported. The motivation behind this package is to have a http client that has a reasonably small dependency cone, is purely implemented in OCaml, and uses the asynchronous task library lwt. This package uses [happy-eyeballs] to connect to a remote host via IPv4 and IPv6, as proposed by IETF [RFC 8305]: on any computer with either IPv4 or IPv6 connectivity, a remote IPv6 or IPv4 server will be connected. Preference is given to IPv6. If a https url is provided, the server certificate is verified using the [ca-certs] package. If you experience any issues or have further needs for this package, please report an issue on the GitHub issue tracker. The installation is just an `opam install http-lwt-client' away :) [`http-lwt-client'] <https://github.com/roburio/http-lwt-client> [HTTP/AF] <https://github.com/inhabitedtype/httpaf> [H2] <https://github.com/anmonteiro/ocaml-h2> [tls] <https://github.com/mirleft/ocaml-tls> [happy-eyeballs] <https://github.com/roburio/happy-eyeballs> [RFC 8305] <https://tools.ietf.org/html/rfc8305> [ca-certs] <https://github.com/mirage/ca-certs> Hannes Mehnert later added ────────────────────────── now [0.0.2] is released that unifies the response type and API (previously it was a variant and clients had to write code for both HTTP1 and HTTP2). Now, a single record and Status/Headers/Version module aliases are provided (very close to HTTP/AF). Enjoy. [0.0.2] <https://github.com/ocaml/opam-repository/pull/19410> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Goodbye Core_kernel] • [Tarides Engineers to Present at ICFP 2021] • [Benchmarking OCaml projects with current-bench] • [What the interns have wrought, 2021 edition] [OCaml Planet] <http://ocaml.org/community/planet/> [Goodbye Core_kernel] <https://blog.janestreet.com/goodbye-Core_kernel/> [Tarides Engineers to Present at ICFP 2021] <https://tarides.com/blog/2021-08-26-tarides-engineers-to-present-at-icfp-2021> [Benchmarking OCaml projects with current-bench] <https://tarides.com/blog/2021-08-26-benchmarking-ocaml-projects-with-current-bench> [What the interns have wrought, 2021 edition] <https://blog.janestreet.com/what-the-interns-have-wrought-2021/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 34198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 14820 bytes --] Hello Here is the latest OCaml Weekly News, for the week of September 14 to 21, 2021. Table of Contents ───────────────── opam-grep: search through the sources of all the packages in opam-repository Hardcaml MIPS CPU Learning Project and Blog Puzzling through some GADT errors Parany for multicore OCaml OCaml 4.13.0, second release candidate Unicode 14.0.0 update for Uucd, Uucp, Uunf and Uuseg Set up OCaml 2.0.0-beta4 Become an Outreachy Mentor: support the growth and diversity of the OCaml community The OCaml 4.13 preview for Merlin is now available Old CWN opam-grep: search through the sources of all the packages in opam-repository ════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-grep-search-through-the-sources-of-all-the-packages-in-opam-repository/8434/3> Kate announced ────────────── I've just released opam-grep.0.2.0 with quite a bit of change compared to the previous version. Here is the highlight: • Complete rewrite from shell script to OCaml, making it more portable • Use the faster `ripgrep' and `ugrep' over `grep' when available (suggestion by @Engil) • Use the `progress' library to show progress instead of a non-portable/DIY spinner See the [changelog] for the full list of relevant changes. *Big thanks to @CraigFe for the `progress' library (such a treat!) and to @dbuenzli for `bos' and `cmdliner' in particular, making it easy to do such rewrite* :relaxed: [changelog] <https://github.com/kit-ty-kate/opam-grep/blob/master/CHANGES.md> Hardcaml MIPS CPU Learning Project and Blog ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088/10> Alexander (Sasha) Skvortsov announced ───────────────────────────────────── Hi everyone! We are excited to announce that we have completed this project and blog. Progress has been slow these past few months due to work, internships, and college, but we’ve now released [v1.0.0 on GitHub]. We also published posts on: • [Design patterns, conventions, and testing] • [How the Always DSL can be used to write safe “pseudo-imperative” code in Hardcaml] • [Hardcaml’s testing and interactive simulation tools] • [A recap of some interesting hardware/CPU features in our design] Finally, we published a [conclusion blog post], which wraps up some strengths/weaknesses of Hardcaml, as well as some takeaways on OCaml and blogging more generally. Thank you to @andyman and @fyquah95 for building Hardcaml, and for helping us out on GitHub issues! We really appreciate your time and suggestions. Overall, we’ve come to the conclusion that Hardcaml is a much better tool for hardware design than Verilog. This has been a great experience, and we walk away with a better understanding of hardware, functional programming, and technical writing. [v1.0.0 on GitHub] <https://github.com/askvortsov1/hardcaml-mips/releases/tag/v1.0.0> [Design patterns, conventions, and testing] <https://ceramichacker.com/blog/14-8x-design-patterns-conventions-and-testing> [How the Always DSL can be used to write safe “pseudo-imperative” code in Hardcaml] <https://ceramichacker.com/blog/15-9x-always-dsl-and-the-control-unit> [Hardcaml’s testing and interactive simulation tools] <https://ceramichacker.com/blog/16-10x-testing-and-debugging-hardcaml> [A recap of some interesting hardware/CPU features in our design] <https://ceramichacker.com/blog/18-11x-cpu-functionality-wrap-up> [conclusion blog post] <https://ceramichacker.com/blog/20-1212-project-conclusion> Puzzling through some GADT errors ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/puzzling-through-some-gadt-errors/8478/8> Deep in this thread, gasche said ──────────────────────────────── Not exactly what you are asking for, but @Octachron wrote an excellent [chapter on GADTs] in the OCaml manual, which could be recommended to people starting GADT programming. It explains why recursive functions on GADT need "explicit polymorphic annotations" in less "implementation driven" terms. (The chapter also demonstrates the new naming scheme for existential type variables introduced by GADT constructors, which can help a lot working through type errors, but are still a bit heavy and deserve a gentle introduction.) [chapter on GADTs] <https://ocaml.org/releases/4.12/manual/gadts.html> octachron then added ──────────────────── I have only written the nomenclature part and a bit of the explanation for recursive functions in this chapter, @garrigue is the author of most of this chapter. Parany for multicore OCaml ══════════════════════════ Archive: <https://discuss.ocaml.org/t/parany-for-multicore-ocaml/8495/1> UnixJunkie announced ──────────────────── There is now an implementation using multicore-OCaml in the 'domains' branch. <https://github.com/UnixJunkie/parany/tree/domains> People are very welcome to give it a try and share the speedup they observe, especially compared to fork-based parallelism. Thanks to @nilsbecker for having motivated me. UnixJunkie later added ────────────────────── If you don't use the domains branch, then parany is using fork-based parallelism. If you want to use the domains branch, you need to install multicore-ocaml first: ┌──── │ opam switch create 4.12.0+domains │ eval `opam config env` └──── OCaml 4.13.0, second release candidate ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-13-0-second-release-candidate/8496/1> octachron announced ─────────────────── The release of OCaml 4.13.0 is expected for next week. Since we had a native code generation bug fix and two minor configuration tweaks since the first release candidate, we are publishing a second release candidate. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Happy hacking, Florian Angeletti for the OCaml team. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.13.0~rc2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.13.0~rc2+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where <option_list> is a comma separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.13.0~rc2+flambda+nffa │ --packages=ocaml-variants.4.13.0~rc2+options,ocaml-option-flambda,ocaml-option-no-flat-float-array │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with "opam search ocaml-option". The source code for the release candidate is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.13.0-rc2.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.13/ocaml-4.13.0~rc2.tar.gz> Changes since the first release candidate ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • [#10626], [#10628]: Wrong reloading of the x86-64 instruction for integer multiplication by a constant, causing the assembler to reject the ocamlopt-generated code. (Xavier Leroy, report by Dave Aitken, review by Vincent Laviron) • [#10176], [#10632(new in rc2)]: By default, call the assembler through the C compiler driver (Sébastien Hinderer, review by Gabriel Scherer, David Allsopp and Xavier Leroy) • [#10451], [#10635(new in rc2)]: Replace the use of iconv with a C utility to convert $(LIBDIR) to a C string constant on Windows when building the runtime. Hardens the generation of the constant on Unix for paths with backslashes, double-quotes and newlines. (David Allsopp, review by Florian Angeletti and Sébastien Hinderer) [#10626] <https://github.com/ocaml/ocaml/issues/10626> [#10628] <https://github.com/ocaml/ocaml/issues/10628> [#10176] <https://github.com/ocaml/ocaml/issues/10176> [#10632(new in rc2)] <https://github.com/ocaml/ocaml/issues/10632> [#10451] <https://github.com/ocaml/ocaml/issues/10451> [#10635(new in rc2)] <https://github.com/ocaml/ocaml/issues/10635> Unicode 14.0.0 update for Uucd, Uucp, Uunf and Uuseg ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-unicode-14-0-0-update-for-uucd-uucp-uunf-and-uuseg/8497/1> Daniel Bünzli announced ─────────────────────── Unicode 14.0.0 was released on the 14th of september. It adds 838 new characters to the standard including, for our friends from Central Asia, support for [Old Uyghur]. For information about all the other additions, see [the announcement 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. Best, Daniel P.S. Though I'm not very fond of the concept, I recently enabled sponsors on my github account as an experiment. So I'd like to thanks my [github sponsors], @davesnx became the first one monday. [Old Uyghur] <https://unicode.org/charts/PDF/Unicode-14.0/U140-10F70.pdf> [the announcement page] <http://blog.unicode.org/2021/09/announcing-unicode-standard-version-140.html> [github sponsors] <https://github.com/sponsors/dbuenzli/> Set up OCaml 2.0.0-beta4 ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta4/8501/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • Set `OPAMSOLVERTIMEOUT' to `1000' to avoid a timeout even if the opam solver is slow. • Increase cache hit ratio by loosening restore keys of opam cache. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta4> Become an Outreachy Mentor: support the growth and diversity of the OCaml community ═══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213/8> Sonja Heinze announced ────────────────────── Hey all, I've just submitted an Outreachy project for the winter round. The project is to write the basic ppx_deriving plugins in ppxlib; that is, the ones that don't already have a version based on ppxlib. I think both, having them available to use, and having their code available as simple examples of how to use Ppxlib.Deriving would be very nice! And improving ppxlib's documentation and finding simple issues on already existing PPXs to prepare for Outreachy, will be beneficial as well. Of course, it's not clear if someone with the right interest comes along for this project, but if we don't find an intern for it this round, I can just re-submit the same project next round. Sonja Heinze ──────────── Btw, the deadline to submit projects was extended and is now Sept 23rd. So the timeline in our post above is slightly outdated. The OCaml 4.13 preview for Merlin is now available ══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-the-ocaml-4-13-preview-for-merlin-is-now-available/8436/6> Continuing this thread, Kate announced ────────────────────────────────────── The OCaml 4.13 preview for ocaml-lsp-server is now available as well. To install it along with the OCaml 4.13 rc, please refer to the first post. If you encounter any problems while using ocaml-lsp-server, please feel free to report it directly in <https://github.com/ocaml/ocaml-lsp/pull/506> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 26751 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6911 bytes --] Hello Here is the latest OCaml Weekly News, for the week of September 21 to 28, 2021. Table of Contents ───────────────── Brr 0.0.2, a toolkit for programming browsers Become an Outreachy Mentor: support the growth and diversity of the OCaml community OCaml 4.13.0 (and 4.12.1) Other OCaml News Old CWN Brr 0.0.2, a toolkit for programming browsers ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-brr-0-0-2-a-toolkit-for-programming-browsers/8521/1> Daniel Bünzli announced ─────────────────────── It's my pleasure to announce the release `0.0.2' of [`Brr'], a toolkit for programming browsers in OCaml with the [`js_of_ocaml'] compiler. Once it has made it to the repo, install with `opam install brr' and consult the [API docs and manuals] (or via `odig doc brr'). This release fixes binding bugs, adds a few new bindings and tweaks some existing signatures. Thanks to all of those who provided bug reports, suggestions and code. The [release notes] have all the details. [`Brr'] <https://erratique.ch/software/brr> [`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml> [API docs and manuals] <https://erratique.ch/software/brr/doc/> [release notes] <https://github.com/dbuenzli/brr/blob/master/CHANGES.md#v002-2020-09-23-zagreb> Become an Outreachy Mentor: support the growth and diversity of the OCaml community ═══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213/13> Thibaut Mattio announced ──────────────────────── I've submitted two projects for the winter session: • Integrate a package health check in ocaml.org To essentially integrate a version of check.ocamllabs.io that can be used by opam-repository maintainers and opam users into the next version of ocaml.org (<https://v3.ocaml.org>). • Support `.eml' files in OCaml's VSCode extension To add support for Dream's [`.eml' files] syntax in the extension, and eventually have error reporting for these files from OCaml LSP Server. I'm more than interested in having co-mentors for these two projects, so if you wanted to mentor Outreachy interns but didn't have any project ideas, don't hesitate to reach out :slight_smile: Another way to help that does not involve mentoring is to find good first issues that will help onboard and select candidates for the projects. Any help on this effort to identify, create and document good first issues for the different projects is more than welcome! [`.eml' files] <https://github.com/aantron/dream/tree/master/example/7-template> OCaml 4.13.0 (and 4.12.1) ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-13-0-and-4-12-1/8529/1> octachron announced ─────────────────── The OCaml team ha the pleasure of celebrating the 175th anniversary of the discovery of Neptune by announcing the joint releases of OCaml version 4.13.0 and 4.12.1 . Some of the highlights in the 4.13.0 release are: • Safe points: a multicore prerequisite that ensures that ocamlopt-generated code can always be interrupted. • The best-fit GC allocation policy is now the default policy (and many other GC improvements). • Named existential type variables in pattern matching: `Showable (type a) (x, show : a * (a -> string))'. • Improved error messages for functor application and functor types. • Let-punning for monadic let: `let* x = x in' can be shortened to `let* x in'. • Module type substitutions: `SIG with module type T = F(X).S'. • Many other quality of life improvements • Many bug fixes The 4.12.1 release is a collection of safe bug fixes, cherry-picked from the 4.13.0 development cycle. If you were using OCaml 4.12.0 and cannot yet upgrade to 4.13.0, this release is for you. The full list of changes can be found in the changelogs below. (*Editor note*: as it’s quite long, it is not included here. Please follow the link to the original article to read it.) Those releases are available as OPAM switches, and as a source download here: • <https://github.com/ocaml/ocaml/archive/4.13.0.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.13/> and there: • <https://github.com/ocaml/ocaml/archive/4.12.1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.12/> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Announcing Tezos’ 8th protocol upgrade proposal: Hangzhou] • [Measuring OCaml compilation speed after a refactoring] • [Writing Lifters Using Primus Lisp] • [Tarides Returns to FIC 2021] • [Generating static and portable executables with OCaml] [OCaml Planet] <http://ocaml.org/community/planet/> [Announcing Tezos’ 8th protocol upgrade proposal: Hangzhou] <https://marigold.dev/blog/announcing-hangzhou/> [Measuring OCaml compilation speed after a refactoring] <http://gallium.inria.fr/blog/measuring-compilation-time/> [Writing Lifters Using Primus Lisp] <http://binaryanalysisplatform.github.io/2021/09/15/writing-lifters-using-primus-lisp/> [Tarides Returns to FIC 2021] <https://tarides.com/blog/2021-09-06-tarides-returns-to-fic-2021> [Generating static and portable executables with OCaml] <https://www.ocamlpro.com/2021/09/02/generating-static-and-portable-executables-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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 17425 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6261 bytes --] Hello Here is the latest OCaml Weekly News, for the week of October 12 to 19, 2021. Table of Contents ───────────────── Verification for Dummies: SMT and Induction OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central) Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0) Release of ocaml-sf/learn-ocaml:0.13.0 Old CWN Verification for Dummies: SMT and Induction ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/verification-for-dummies-smt-and-induction/8631/1> OCamlPro announced ────────────────── We are pleased to share with you [Verification for Dummies: SMT and Induction], a complete and detailed series of blogposts written by Adrien Champion about Induction as a formal verification technique. The subject is treated with many concrete and executable examples. All examples can be (and should be) launched locally by readers thanks to small and easy to find tools. Modification and experimentation are strongly encouraged! Take a look at all the notions covered: • introduction to formal logics and formal frameworks; • SMT-solving: modern, low-level verification building blocks; • declarative transition systems; • transition system unrolling; • BMC and induction proofs over transition systems; • candidate strengthening. We hope you enjoy reading and we look forward to your feedback! [Verification for Dummies: SMT and Induction] <https://www.ocamlpro.com/2021/10/14/verification-for-dummies-smt-and-induction/> OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central) ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-cafe-wed-oct-13-1pm-u-s-central/8610/14> Claude Jager-Rubinson announced ─────────────────────────────── The video of @dra27's talk on OPAM is now available: <https://youtu.be/RHSdlH4el0g>. Thanks so much for the great talk, David! And thanks to everybody who attended! (The video starts a couple of minutes into the talk because yours truly forgot to start recording. D'oh!) We already have some ideas for the next meeting but if there's a topic that you'd like to hear about or are interested on presenting on, please message me. Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0) ════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-windows-friendly-ocaml-4-12-distribution-2nd-preview-release-0-2-0/8488/3> jbeckford announced ─────────────────── 0.2.5 is available. This release brings significant user friendly improvements. There is a new binary called `with-dkml.exe'. Just plop `with-dkml' in front of a Windows command that requires access to Unix scripts (ie. `with-dkml opam install') and it should just work. There is now a section called **Beyond Basics** in [the Diskuv OCaml user documentation] that walks through: • the first and second tutorials of [Getting Started - Learn OCaml] • the bare Opam essentials you need as a beginner (how to find and select an Opam switch, and how to find and install packages using `with-dkml opam install'), all without leaving the Command Prompt • installing Visual Studio Code with the OCaml plugin Huge thanks to @Butanium who lent me much of his time to validate usability from the perspective of a newcomer. More feedback is always welcome. Links: • [Installation instructions for the latest version] • [Release notes for all versions] PS. You won't need `with-dkml' most of the time. The Beyond Basics documentation shows how to run Dune and the OCaml native compiler directly from the Visual Studio Command Prompt. [the Diskuv OCaml user documentation] <https://diskuv.gitlab.io/diskuv-ocaml/index.html> [Getting Started - Learn OCaml] <https://ocaml.org/learn/tutorials/> [Installation instructions for the latest version] <https://diskuv.gitlab.io/diskuv-ocaml/index.html#two-step-installation-instructions> [Release notes for all versions] <https://gitlab.com/diskuv/diskuv-ocaml/-/releases> Release of ocaml-sf/learn-ocaml:0.13.0 ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-ocaml-sf-learn-ocaml-0-13-0/8577/6> Erik Martin-Dorel announced ─────────────────────────── Just FYI, a bugfix release learn-ocaml `0.13.1' has just been tagged and: • [released in GitHub] ← see the Release Notes and binaries-assets • [pushed to Docker Hub] ← `ocamlsf/learn-ocaml' being the official distribution of Learn-OCaml • [submitted to OPAM default repository] [released in GitHub] <https://github.com/ocaml-sf/learn-ocaml/releases/tag/v0.13.1> [pushed to Docker Hub] <https://hub.docker.com/r/ocamlsf/learn-ocaml/tags> [submitted to OPAM default repository] <https://github.com/ocaml/opam-repository/pull/19787> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 16445 bytes --]
[-- Attachment #1: Type: text/plain, Size: 7801 bytes --] Hello Here is the latest OCaml Weekly News, for the week of October 26 to November 02, 2021. Table of Contents ───────────────── Lists.ocaml.org: service temporarily sunsetted Talk at Func Prog Sweden First OPAM releases of Scad_ml and [@@deriving scad] Other OCaml News Old CWN Lists.ocaml.org: service temporarily sunsetted ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/lists-ocaml-org-service-temporarily-sunsetted/8692/1> Anil Madhavapeddy announced ─────────────────────────── *This note does not concern the main OCaml email list, which continues to be available through <https://sympa.inria.fr/sympa/arc/caml-list/>* The lists.ocaml.org e-mail service has been going through a rough time in the past few years, with vast swathes of spam regularly hitting our ingress email server and require manual unblocking every time. It was set up [back in 2012] as an augmentation of the main OCaml mailing list and really helped with some big projects in the early days (the design of and migration to ppx from camlp4, for example). However, in the intervening years e-mail has reduced in importance as a primary community communication mechanism (as evidenced, for example, in this forum). With the latest spam surge, I've moved the service into read-only mode with all the mailboxes and archives still available on the website, but with mail delivery and list creation/admin disabled. All existing links should continue to work to historical links online without change. The only mailing list on there that was still active to my knowledge is the opam-commits cron list, which will be replaced by an ocurrent-based deployer for that website shortly. I hope to bring e-mail back to ocaml.org sometime in 2022, as it's an important communications medium that is highly accessible. One challenge is spam, and another is the inflexibility of GNU Mailman and its upgrade mechanism (essentially a manual process from 2 to 3). Therefore, if there is anyone in the community interested in building a simple e-mail list manager in OCaml, that would be of interest :slight_smile: [back in 2012] <https://sympa.inria.fr/sympa/arc/caml-list/2012-12/msg00015.html> Talk at Func Prog Sweden ════════════════════════ Archive: <https://discuss.ocaml.org/t/talk-at-func-prog-sweden/8703/1> Leonardo Laguna Ruiz announced ────────────────────────────── Here's a link for the talk I gave at the Func Prog Sweden meetup. In that talk I show the process we follow some years ago in order to move all our code base to OCaml and why it was an excellent decision. <https://youtu.be/FGXiAARXE2M> [Wolfram System Modeler] is a simulation environment that can be used to model multi-domain systems. For example systems composed of electrical, thermal, hydraulic, mechanical, etc, components. One of the main parts of System Modeler is the model compiler (Kernel) which takes models written in the Modelica language and compiles them into efficient simulation executables. This compiler was ported to OCaml by using custom tool that performed the code to code translation of our old code base. Slides <https://a2076202-c90b-450e-901b-cb56c346913c.usrfiles.com/ugd/a20762_adfa899586c7413a8c17f7b708dbc177.pdf> [Wolfram System Modeler] <https://www.wolfram.com/system-modeler/> First OPAM releases of Scad_ml and [@@deriving scad] ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-opam-releases-of-scad-ml-and-deriving-scad/8718/1> geoffder announced ────────────────── I'd like to announce the first release onto opam of [Scad_ml] and [ppx_deriving_scad]. The former being a DSL front-end to the [OpenSCAD] solid modelling language, and the latter providing transformation function generation for custom types (a pattern that I have found useful during my time using `Scad_ml'. When I decided I wanted to pick up OpenScad, I was pleasantly surprised to discover that the `Scad_ml' library already existed on GitHub, credits to <https://github.com/namachan10777>. Over time I filled out the rest of the OpenSCAD language coverage, as well as some additional helpful math, and reorganized things to try and keep it from getting too messy as more and more was tacked on. Finally, after some help in the ocaml discord (from NULL and octachron), we also now can track whether shapes are 2D or 3D with minimal changes to the user interface, preventing misapplications of operations that would otherwise only appear in the OpenSCAD console. The `[@@deriving scad]' ppx is my solution to make a habit I developed to get around the otherwise fully declarative nature of working in OpenSCAD more ergonomic. Shapes in OpenSCAD cannot be queried in any way, so upon creation, the locations of it's vertices or it's origin are not available. Of course, since you created it, you know exactly it's dimensions, and where you have moved it, but what if you want to use the location of one of it's vertices, wherever that ends up after a series of transformations? What I did for some time before learning how to write a ppx, was put the coordinates I cared about into a record with the shape, and mapped over the type (by hand (and regex)) with the relevant functions (typically transform and rotate). Turns out writing a ppx with `Ppxlib' and `metaquot' isn't so bad, and I really wish I did it sooner! Anyway, to the few of you out there that might use OpenSCAD, I hope that these tools might come in handy! [Scad_ml] <https://github.com/namachan10777/scad-ml> [ppx_deriving_scad] <https://github.com/geoffder/ppx_deriving_scad> [OpenSCAD] <https://openscad.org/> Other OCaml News ════════════════ >From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Hiring a Developer Educator] • [Verification for Dummies: SMT and Induction] • [SCoP Passed Phase 1 of the DAPSI Initiative!] [OCaml Planet] <http://ocaml.org/community/planet/> [Hiring a Developer Educator] <https://blog.janestreet.com/hiring-a-developer-educator/> [Verification for Dummies: SMT and Induction] <https://www.ocamlpro.com/2021/10/14/verification-for-dummies-smt-and-induction/> [SCoP Passed Phase 1 of the DAPSI Initiative!] <https://tarides.com/blog/2021-10-14-scop-selected-for-dapsi-phase2> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 17655 bytes --]
[-- Attachment #1: Type: text/plain, Size: 12022 bytes --] Hello Here is the latest OCaml Weekly News, for the week of November 02 to 09, 2021. Table of Contents ───────────────── OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library Build System Engineer at Jane Street Real-world use example of ts2ocaml First release of `ts2ocaml' - generates OCaml bindings from .d.ts files! OUPS meetups are back! Old CWN OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library ══════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-otoml-0-9-0-a-compliant-and-flexible-toml-parsing-manipulation-and-pretty-printing-library/8152/9> Daniil Baturin announced ──────────────────────── OTOML 0.9.2 is now available from the OPAM repository. Breaking changes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ It makes a breaking change to the `get_array' accessor: it now has type `Otoml.get_array' now has type `?strict:bool -> (t -> 'a) -> t -> 'a list' , that is, it requires an accessor function that will be applied to every item of the array. For example, you can use `Otoml.find t (Otoml.get_array Otoml.get_string) ["foo"]' to retrieve an array of strings from a TOML document's key `foo' . The motivation for the change is that it allows retrieving arrays of unwrapped OCaml values in one step. The old behaviour can still be emulated using an identify function for the accessor, for example the built-in `Otoml.get_value : 'a -> 'a' . New features ╌╌╌╌╌╌╌╌╌╌╌╌ New `Otoml.path_exists t ["some"; "table"; "key"]' allows checking if a key path exists in a TOML document. `Otoml.Printer.to_string/to_channel' functions now provide `~force_table_array' option. When set to true, it forces every array that contains nothing but tables to be rendered using the `[[...]]~' table array syntax. Bug fixes ╌╌╌╌╌╌╌╌╌ Unicode escape sequences are now printed correctly. If a table has subtables and non-table items, the non-table items are forcibly moved before the first subtable for printing. This way the output parses correctly, otherwise the non-table items would be mistakenly treated as subtable members. This way hand-constructed TOML tables are always formatted correctly even if the user inserts non-table items after a subtable. Testing ╌╌╌╌╌╌╌ I added a minimal test suite for the read-write interface. If anyone wants to contribute to it, that will be much appreciated. Ideally, all lookup functions and all accessors/constructors should be tested to work as expected. Both parser and formatter are now tested with the [github.com/BurntSushi/toml-test] and are fully compliant (one formatter test is skipped because the test itself is malformed). [github.com/BurntSushi/toml-test] <https://github.com/BurntSushi/toml-test> Future plan ╌╌╌╌╌╌╌╌╌╌╌ My idea was to call it 1.0.0 when it passes both parsing and formatter tests. That goal is reached now, but I'd like to see if anyone has any more ideas for the API that cannot be implemented without breaking changes. If not, I'll call it 1.0.0 in the next release. Build System Engineer at Jane Street ════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-build-system-engineer-at-jane-street/8737/1> Andrey Mokhov announced ─────────────────────── Jane Street is looking for new build system engineers! I've worked in this team for two years and I love the job. Here is why: • You frequently change focus from low-level work, like debugging a weird file-system issue, to high-level work, like designing a cloud build cache. • Your colleagues are amazing. If you're like me, you'll feel like an imposter in most conversations but it's OK since everyone is kind and helpful, so you'll learn something new every day. • Most of your work is open-source and benefits the wider OCaml community. For balance, let me also say a few words about challenges. • Build systems accumulate years of knowledge of many people on how to get things done. When this knowledge goes out of date, you are often the only person to fix it. For this reason, build systems work can be daunting. • It's far from our core business, so you don't get to work on any of our cool trading systems. Your role is to empower others. • Our team is small, so we may have to turn down some good candidates. However, please don't get discouraged by this! If in doubt, send me a message and we'll chat. • There is no remote work for now. To apply, follow [this link] and mention the build systems role in your application. Our plans for 2022 include: implementing cloud builds in Dune, better integration with other tools like IDEs and the OCaml compiler, and making Dune even faster than it is today. To learn more about our work, listen to [this podcast]. And feel free to message me or @jeremiedimino if you have any questions! [this link] <https://janestreet.com/join-jane-street/position/4274814002/> [this podcast] <https://signalsandthreads.com/build-systems/> Real-world use example of ts2ocaml ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/real-world-use-example-of-ts2ocaml/8745/1> Sora Morimoto announced ─────────────────────── Some OCaml/JavaScript enthusiasts may know that we spent almost two years working on a tool automatically generating OCaml bindings from TypeScript's type definition files. To prepare for its release, we just published a repository to show an example use of it. <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/3/3473fc11da0c56335e8de2b91bd7d9172444913a_2_1380x374.png> <https://github.com/ocsigen/ts2ocaml-example> This example generates and actually uses a binding to a small JavaScript library called [pretty-bytes], and it doesn't only generate the binding, but also converts JSDoc comments to odoc ones. We believe we can release ts2ocaml as early as this month, please look forward to the new announcement! [pretty-bytes] <https://github.com/sindresorhus/pretty-bytes> First release of `ts2ocaml' - generates OCaml bindings from .d.ts files! ════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-ts2ocaml-generates-ocaml-bindings-from-d-ts-files/8772/1> Cannorin announced ────────────────── We're pleased to announce that ts2ocaml is now public! <https://github.com/ocsigen/ts2ocaml> This is a tool which parses TypeScript definition files (`.d.ts') of a JS package and then generates an OCaml binding for the package. ts2ocaml currently supports js_of_ocaml as a target via [LexiFi/gen_js_api], and ReScript is also going to be supported too! You can install ts2ocaml from NPM: `npm install -g @ocsigen/ts2ocaml'. Please take a look at the documentation on our GitHub repository before using it. Also, we appreciate any feedback or bug reports, especially since this is the first release of ts2ocaml! This tool is heavily inspired by ts2fable, which generates Fable (F# AltJS) bindings from `.d.ts' files. This tool is also written in Fable. Thank you very much for the great language and an awesome ecosystem, Fable team! [LexiFi/gen_js_api] <https://github.com/LexiFi/gen_js_api> OUPS meetups are back! ══════════════════════ Archive: <https://discuss.ocaml.org/t/oups-meetups-are-back/8776/1> zapashcanon announced ───────────────────── We (@Vertmo, @lsylvestre, Colin González and myself) are happy to announce that the [OUPS (OCaml Users in PariS) meetups] are back. If you're not familiar with OUPS, the idea is to have people using OCaml (developers, applications' users, researchers, …) to meet in Paris where a talk is given, followed by some discussions while eating pizza and drinking beer. We're planning to have the first meetup happening this year in December. Thus we're looking for speakers willing to give a talk for the first meetups or the following ones. The talks usually happen at [IRILL]'s offices, [4 Place Jussieu, 75005 Paris]. We'll prefer talks in french and with someone able to be physically present, but we're open about english and remote talks. If you want to give a talk in December or in the future, you can let us know here or [on zulip] where we plan to have our main discussions. We also have [a group on Framagit] where we'll store some stuff. If you don't like Zulip, I'm also on IRC (#oups in [libera.chat]) and [matrix] but not everyone is. The four of us are doing a PhD in the following places: [ENS] ([Parkas team]), [Université de Paris] ([Irif]) + [Nomadic Labs], [Université Paris-Saclay] ([LMF]) + [OCamlPro], [Sorbonne Université] ([APR team - LIP6]) ; so we have a good coverage of the OCaml users in Paris but we don't know everyone. Even if you don't want to give a talk, if you know someone that may be interested, please talk to him about OUPS ! :) Also, if there's a subject you'd like to hear about at OUPS, you can tell us and we'll try to find a speaker to give a talk about it. We'll come back to you very quickly about the December meetup. [OUPS (OCaml Users in PariS) meetups] <https://www.meetup.com/fr-FR/ocaml-paris/> [IRILL] <https://www.irill.org/> [4 Place Jussieu, 75005 Paris] <https://www.openstreetmap.org/#map=19/48.84650/2.35457> [on zulip] <https://oups.zulipchat.com> [a group on Framagit] <https://framagit.org/oups> [libera.chat] <https://libera.chat/> [matrix] <https://matrix.to/#/#oups:matrix.org> [ENS] <https://www.ens.psl.eu/> [Parkas team] <https://parkas.di.ens.fr/> [Université de Paris] <https://u-paris.fr/> [Irif] <https://www.irif.fr/> [Nomadic Labs] <https://www.nomadic-labs.com/> [Université Paris-Saclay] <https://www.universite-paris-saclay.fr/> [LMF] <https://lmf.cnrs.fr/> [OCamlPro] <https://www.ocamlpro.com/> [Sorbonne Université] <https://www.sorbonne-universite.fr/> [APR team - LIP6] <https://www.lip6.fr/recherche/team.php?acronyme=APR> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 23231 bytes --]
[-- Attachment #1: Type: text/plain, Size: 20114 bytes --] Hello Here is the latest OCaml Weekly News, for the week of November 09 to 16, 2021. Table of Contents ───────────────── Early preview of the Algorithmic with OCaml Book pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications ocaml-wayland (pure OCaml wayland protocol library) Set up OCaml 2.0.0-beta6 Set up OCaml 2.0.0-beta7 Set up OCaml 2.0.0-beta8 phylogenetics, a library for molecular evolution release of svmwrap: a wrapper around libsvm-tools GeoPub - A XMPP web client Old CWN Early preview of the Algorithmic with OCaml Book ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/early-preview-of-the-algorithmic-with-ocaml-book/8785/1> Damien Guichard announced ───────────────────────── Please report bugs, bad English & nonsenses. But do not report omissions (it is work-in-progress plus it's not an ocaml bible). <https://www.cjoint.com/c/KKjulI1Dx03> Why the book is not bottom up, instead some concepts are used without explained ? • Because some notions (what is the `unit' type ? what is a queue ?) are considered easy-enough to go without saying. What will be in the missing chapter 6 ? • Type polymorphism, universal quantification, `Stdlib.compare', weak polymorphism, constrained polymorphism, phantom types, type variance. What will be in the chapters 12 and more ? • High performance lexing • Recursive-descent parsing • The art of searching • Detailed construction of the ERic 0.3 application Will the source files go to a repository ? • No. The source files are already included in the zip archive. pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications ════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786/1> Ryan Moore announced ──────────────────── I wanted to announce the first release of [pyml_bindgen], a CLI app for generating Python bindings using [pyml] directly from OCaml value specifications. Manually writing bindings to Python libraries can get tedious pretty quickly. `pyml_bindgen' aims to help you avoid a lot of the repetitive work when binding Python libraries by letting you focus on the OCaml side of things and (mostly) not worrying about the implementation of the pyml bindings. [pyml_bindgen] <https://github.com/mooreryan/ocaml_python_bindgen> [pyml] <https://github.com/thierry-martinez/pyml/> Quick start ╌╌╌╌╌╌╌╌╌╌╌ First, install `pyml_bindgen'. It is available on [Opam]. ┌──── │ $ opam install pyml_bindgen └──── Say you have a Python class you want to bind and use in OCaml. (Filename: `adder.py') ┌──── │ class Adder: │ @staticmethod │ def add(x, y): │ return x + y └──── To do so, you write OCaml value specifications for the class and methods you want to bind. (Filename: `val_specs.txt') ┌──── │ val add : x:int -> y:int -> unit -> int └──── Then, you run `pyml_bindgen'. ┌──── │ $ pyml_bindgen val_specs.txt adder Adder --caml-module Adder > lib.ml └──── Now you can use your generated functions in your OCaml code. (Filename: `run.ml') ┌──── │ open Lib │ │ let () = Py.initialize () │ │ let result = Adder.add ~x:1 ~y:2 () │ │ let () = assert (result = 3) └──── Finally, set up a dune file and run it. ┌──── │ (executable │ (name run) │ (libraries pyml)) └──── ┌──── │ $ dune exec ./run.exe └──── [Opam] <https://opam.ocaml.org/packages/pyml_bindgen/> Documentation ╌╌╌╌╌╌╌╌╌╌╌╌╌ For more information on installing and using `pyml_bindgen', check out the [docs]. There you will find lots of tips and examples to help you get started! [docs] <https://mooreryan.github.io/ocaml_python_bindgen/> ocaml-wayland (pure OCaml wayland protocol library) ═══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-wayland-pure-ocaml-wayland-protocol-library/7616/2> Thomas Leonard announced ──────────────────────── ocaml-wayland has been very stable over the last few months and so I've now released [version 1.0]. The main changes are improved error handling and diagnostics. I've been using this to write an Xwayland adaptor, which acts as an X11 window manager to Xwayland, converting between the two protocols. This allows running X11 apps in VMs and having them appear alongside other application windows on the host. It can also be used to fix other problems, such as support for HiDPI screens and Sway's buggy clipboard support: <https://roscidus.com/blog/blog/2021/10/30/xwayland/> [version 1.0] <https://github.com/talex5/ocaml-wayland/releases/tag/v1.0> Set up OCaml 2.0.0-beta6 ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta6/8795/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • Unlock opam 2.1 on the Ubuntu and macOS runners. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta6> Set up OCaml 2.0.0-beta7 ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta7/8796/1> Sora Morimoto announced ─────────────────────── Fixed ╌╌╌╌╌ • Return an empty array to avoid depext failure when depext flags are not passed. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta7> Set up OCaml 2.0.0-beta8 ════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta8/8821/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • Use 2.1 mode instead of 2.0 mode on the Ubuntu and macOS runners. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta8> phylogenetics, a library for molecular evolution ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-phylogenetics-a-library-for-molecular-evolution/8812/1> Philippe announced ────────────────── I'm happy to announce the availability on opam of [phylogenetics], a bioinformatics library dedicated to [molecular evolution] and phylogeny. It provides a few algorithms and data structures that can be useful to study how biological sequences like proteins or genes have evolved, or to simulate datasets under various evolutionary models. Comments/questions welcomed on the repo's issue tracker! [phylogenetics] <https://github.com/biocaml/phylogenetics> [molecular evolution] <https://en.wikipedia.org/wiki/Molecular_evolution> release of svmwrap: a wrapper around libsvm-tools ═════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-svmwrap-a-wrapper-around-libsvm-tools/8818/1> UnixJunkie announced ──────────────────── I am pleased to announce the availability in opam of the svmwrap package. A wrapper around libsvm's svm-train and svm-predict executables. Currently, only regression modeling is supported, using the linear, RBF, sigmoid or polynomial kernel. <https://github.com/UnixJunkie/svmwrap> The quite scary usage looks like this: ┌──── │ usage: svmwrap │ -i <filename>: training set or DB to screen │ --feats <int>: number of features │ [-o <filename>]: predictions output file │ [-np <int>]: ncores │ [--kernel <string>] choose kernel type {Lin|RBF|Sig|Pol} │ [-c <float>]: fix C │ [-e <float>]: epsilon in the loss function of epsilon-SVR; │ (0 <= epsilon <= max_i(|y_i|)) │ [-g <float>]: fix gamma (for RBF and Sig kernels) │ [-r <float>]: fix r for the Sig kernel │ [--iwn]: turn ON instance-wise-normalization │ [--scale]: turn ON [0:1] scaling (NOT PRODUCTION READY) │ [--no-plot]: no gnuplot │ [{-n|--NxCV} <int>]: folds of cross validation │ [-q]: quiet │ [-v|--verbose]: equivalent to not specifying -q │ [--seed <int>]: fix random seed │ [-p <float>]: training set portion (in [0.0:1.0]) │ [--pairs]: read from .AP files (atom pairs; will offset feat. indexes by 1) │ [--train <train.liblin>]: training set (overrides -p) │ [--valid <valid.liblin>]: validation set (overrides -p) │ [--test <test.liblin>]: test set (overrides -p) │ [{-l|--load} <filename>]: prod. mode; use trained models │ [{-s|--save} <filename>]: train. mode; save trained models │ [-f]: force overwriting existing model file │ [--scan-c]: scan for best C │ [--scan-e <int>]: epsilon scan #steps for SVR │ [--scan-g]: scan for best gamma │ [--regr]: regression (SVR); also, implied by -e and --scan-e │ [--e-range <float>:<int>:<float>]: specific range for e │ (semantic=start:nsteps:stop) │ [--c-range <float,float,...>] explicit scan range for C │ (example='0.01,0.02,0.03') │ [--g-range <float,float,...>] explicit range for gamma │ (example='0.01,0.02,0.03') │ [--r-range <float,float,...>] explicit range for r │ (example='0.01,0.02,0.03') └──── For people who know my linwrap opam package (a wrapper around liblinear tools), this is quite similar. <https://github.com/UnixJunkie/linwrap> GeoPub - A XMPP web client ══════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-geopub-a-xmpp-web-client/8819/1> pukkamustard announced ────────────────────── I'd like to announce an initial, proof-of-concept release of GeoPub - an XMPP web client. Unlike many XMPP clients the focus is not on instant messaging but on creating, displaying and managing things such as events, maps, information on local organizations and other local knowledge (see [the openEngiadina] project for the context). This initial release is not really anything useful but a proof-of-concept how such an application can be developed using XMPP and OCaml. There are many rough edges and broken hacks that need fixing. I'd be very grateful for your feedback, thoughts and ideas. The source code of the app is on [codeberg] and a pre-built hosted version is available [here]. The application consists of some parts and ideas that I'd like to illustrate separately: [the openEngiadina] <https://openengiadina.net> [codeberg] <https://codeberg.org/openEngiadina/geopub> [here] <https://geopub.openengiadina.net/> ocaml-xmpp ╌╌╌╌╌╌╌╌╌╌ [ocaml-xmpp] is a XMPP client library for OCaml (documentation available [online]. [ocaml-xmpp] <https://codeberg.org/openEngiadina/ocaml-xmpp> [online] <https://inqlab.net/projects/ocaml-xmpp/> Reactive ┄┄┄┄┄┄┄┄ ocaml-xmpp is reactive in the sense that the XMPP connection is abstracted as a React event of Stanzas (small pieces of information that flow over XMPP): ┌──── │ val stanzas : t -> Stanza.t React.event └──── This React event can be filtered for messages in a specific conversation, for example. Transports ┄┄┄┄┄┄┄┄┄┄ XMPP works with different transport mechanisms and ocaml-xmpp supports this. Currently ocaml-xmpp can be used from Unix with a TCP/SSL connection to a XMPP server and from web browsers with a WebSocket connection. This is implemented by abstracting the XMPP transport: ┌──── │ module type TRANSPORT = sig │ (** {2 Connection} *) │ │ type options │ (** Additional options that may be passed to the transport *) │ │ type t │ (** Type of an instantiated connection to an XMPP server *) │ │ val connect : host:string -> options -> t Lwt.t │ │ val close : t -> unit Lwt.t │ │ val closed : t -> unit Lwt.t │ │ (** {2 XML Stream} *) │ │ type stream │ │ val open_stream : t -> to':string -> stream Lwt.t │ │ val stream_id : stream -> string Lwt.t │ │ val send_xml : stream -> Xmlc.t -> unit Lwt.t │ │ val signals : stream -> Xmlc.signal Lwt_stream.t │ │ val stop_stream : stream -> unit Lwt.t │ end └──── A transport establishes the underlying connection to a server and can create XML streams (in XMPP a connection is by multiple XML streams sequentially). For technical reasons XML parsing is also handled by the transport and a stream of XML signals (element start, data, element end) is returned. This is due to the fact that XML parsing in XMPP needs to be done slightly differently when using TCP (a single XML document over the entire stream) or WebSockets (every WebSocket frame is a parse-able XML document). The Unix/TCP/SSL transport uses Markup.ml and whereas the WebSocket transport uses Xmlm (and Brrr). Parser combinators for XML ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ For parsing streams of XML signals to OCaml types ocaml-xmpp contains a parser combinator helper library: [Xmlc]. This allows parser for XML such as this: ┌──── │ <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><jid>w4iu4ckn3kjbqvcd@demo.openengiadina.net/z8Pkzfa8</jid></bind> └──── to be parses like this: ┌──── │ Xmlc.Parser.( │ element (Ns.bind "bind") (fun _ -> │ element (Ns.bind "jid") (fun _ -> │ text >>| String.concat "" >>= fun jid_s -> │ match Jid.of_string jid_s with │ | Some jid -> return jid │ | None -> fail_with "invalid JID"))) └──── [Xmlc] <https://inqlab.net/projects/ocaml-xmpp/xmlc/Xmlc/index.html> XMPP extensions ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Inspiration for the scope of the core library is taken from the [Strophe] XMPP libraries - everything that does not have directly to do with XMPP transport, authentication or stream management is kept outside of the core library. There are already some "extension" libraries outside of the core for useful XMPP features (e.g. [Roster management], [PubSub] and [pinging]). One thing that I do want to add to the core library is stream management according to [XEP-0198]. I expect this addition to change the core library API - the API is not stable yet! Much inspiration was taken from [Jackline] - an OCaml XMPP client - and in particular [this post] on Jackline. Many thanks to @hannes. [Strophe] <http://strophe.im/> [Roster management] <https://inqlab.net/projects/ocaml-xmpp/xmpp/Xmpp_roster/index.html> [PubSub] <https://inqlab.net/projects/ocaml-xmpp/xmpp/Xmpp_pubsub/index.html> [pinging] <https://inqlab.net/projects/ocaml-xmpp/xmpp/Xmpp_ping/index.html> [XEP-0198] <https://xmpp.org/extensions/xep-0198.html> [Jackline] <https://github.com/hannesm/jackline> [this post] <https://hannes.nqsb.io/Posts/Jackline> reactor ╌╌╌╌╌╌╌ GeoPub uses Brr. I had some trouble figuring out a suitable "architecture" for managing complex logic and ended up hacking an [Elm] inspired helper library: [reactor.mli]. State updates for the entire application are then handled in a single [update function]. I'm not yet very happy with this machinery and I'm pretty sure I'm using react in wrong and dangerous ways. I'd be very grateful for ideas on how to improve this. THis might be related to this discussion: <https://discuss.ocaml.org/t/structuring-frp-specifically-note-applications/8645/17>. The reason for using React over Note is because ocaml-xmpp uses a lot of Lwt and `Lwt_react' provides nice bindings for working with both. I guess something similar could be created for Note (e.g. `Lwt_note') and I'm open to using Note (also in ocaml-xmpp). [Elm] <https://elm-lang.org/> [reactor.mli] <https://codeberg.org/openEngiadina/geopub/src/branch/main/src/reactor/reactor.mli> [update function] <https://codeberg.org/openEngiadina/geopub/src/branch/main/src/geopub/main.ml#L28> Leaflet ╌╌╌╌╌╌╌ GeoPub displays a map using the [Leaflet.js] JavaScript library. GeoPub contains OCaml bindings to Leaflet using Brr: [leaflet.mli]. Writing this was very straightforward and pleasant (I like Brr!). One issue I have is that the Leaflet map needs to be manipulated very imperatively, whereas the rest of the application is much more functional. This causes some mismatches. I guess one needs to find a way of hiding the impressiveness of Leaflet (e.g. like [react-leaflet]). [Leaflet.js] <https://leafletjs.com/> [leaflet.mli] <https://codeberg.org/openEngiadina/geopub/src/branch/main/src/leaflet/leaflet.mli> [react-leaflet] <https://github.com/PaulLeCam/react-leaflet> Guix for build and development environments ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I use [Guix] for providing a build and development environment. With guix installed one can run `guix shell' in the GeoPub repository to get a reproducible build environment. All dependencies are fetched and made available by Guix in this environment (e.g. `ocaml-xmpp' or the OCaml compiler). I will publish `ocaml-xmpp' on OPAM once the API is more stable and an initial release can be made. [Guix] <https://guix.gnu.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 36569 bytes --]
[-- Attachment #1: Type: text/plain, Size: 21112 bytes --] Hello Here is the latest OCaml Weekly News, for the week of November 23 to 30, 2021. Table of Contents ───────────────── opam 2.1.1, opam 2.0.10, and opam-depext 1.2 OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library New release of Fix New release of Menhir (20211125) Lwt 5.5.0, Lwt_domain 0.1.0, Lwt_react.1.1.5 OCaml's CI is gradually moving to GitHub Actions How to combine 3 monads: Async/Lwt, Error and State? Old CWN opam 2.1.1, opam 2.0.10, and opam-depext 1.2 ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-1-opam-2-0-10-opam-depext-1-2/8872/1> R. Boujbel announced ──────────────────── We are pleased to announce several minor releases: [opam 2.0.10], [opam 2.1.1], and [opam-depext 1.2]. The opam releases consist of backported fixes, while `opam-depext' has been adapted to be compatible with opam 2.1, to allow for workflows which need to maintain compatibility with opam 2.0. With opam 2.1.1, if you export `OPAMCLI=2.0' into your environment then workflows expecting opam 2.0 should now behave even more equivalently. You'll find more information in the [blog post ]. [opam 2.0.10] <https://github.com/ocaml/opam/releases/tag/2.0.10> [opam 2.1.1] <https://github.com/ocaml/opam/releases/tag/2.1.1> [opam-depext 1.2] <https://github.com/ocaml-opam/opam-depext/releases/tag/1.2> [blog post ] <https://opam.ocaml.org/blog/opam-2-0-10-2-1-1-depext/> OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library ══════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-otoml-0-9-0-a-compliant-and-flexible-toml-parsing-manipulation-and-pretty-printing-library/8152/10> Daniil Baturin announced ──────────────────────── A new 0.9.3 relase is available. Still not 1.0.0 just in case. The change I'm most glad I managed to make is that the lexer is now re-entrant and doesn't use any mutable state. Where can I apply for the "Designed for multicore OCaml" certification sticker? ;) Breaking change in the functor interface ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I found an oversight that took a breaking change to fix. It didn't break any package that was already in the OPAM repository, so I'm glad I noticed it before it caused anyone trouble. My idea to make the functor take separate integer and float modules turned out to be misguided: it wouldn't compose with `Otoml.get_float ~strict:false' and similar functions that apply type conversions. Logically, `Otoml.get_float ~strict:false (Otoml.integer 5)' should produce `Otoml.TomlFloat 5.0'. However, it means that `get_float' needs to know how to convert integers to float. If integer and float types are in separate modules, that isn't possible. So I combined both integers and floats in a single `TomlNumber'. That way people who want to bring their own bignum libraries will have to write more code, but numbers will behave as they are expected to in a dynamically typed format. ┌──── │ module BigNumber = struct │ type int = Z.t │ type float = Decimal.t │ │ let int_of_string = Z.of_string │ let int_to_string = Z.to_string │ let int_of_boolean b = if b then Z.one else Z.zero │ let int_to_boolean n = (n <> Z.zero) │ │ (* Can't just reuse Decimal.to/of_string because their optional arguments │ would cause a signature mismatch. *) │ let float_of_string s = Decimal.of_string s │ │ (* Decimal.to_string uses "NaN" spelling │ while TOML requires all special float values to be lowercase. *) │ let float_to_string x = Decimal.to_string x |> String.lowercase_ascii │ let float_of_boolean b = if b then Decimal.one else Decimal.zero │ let float_to_boolean x = (x <> Decimal.zero) │ │ let float_of_int = Decimal.of_bigint │ let int_of_float = Decimal.to_bigint │ end │ │ module Otoml = Otoml.Base.Make (BigNumber) (Otoml.Base.StringDate) └──── The next release will likely be 1.0.0 for real. New release of Fix ══════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-fix/8895/1> François Pottier announced ────────────────────────── I am pleased to announce a new release of Fix, with several new modules contribued by Frédéric Bour (thanks!). In short, Fix is a toolkit that helps perform memoization and fixed point computations (including data flow analyses). More generally, it offers a number of basic algorithmic building blocks that can be useful in many circumstances. ┌──── │ opam update │ opam install fix.20211125 └──── Documentation can be found here: • <https://gitlab.inria.fr/fpottier/fix/-/blob/master/README.md> • <http://cambium.inria.fr/~fpottier/fix/doc/fix/Fix/index.html> Enjoy, François Pottier francois.pottier@inria.fr <http://cambium.inria.fr/~fpottier/> 2021/11/25 ╌╌╌╌╌╌╌╌╌╌ • The new module `CompactQueue' offers a minimalist mutable FIFO queue. It is comparable with OCaml's `Queue' module. In comparison with `Queue', it uses a more compact internal representation: elements are stored contiguously in a circular array. This has a positive impact on performance: both time and memory consumption are reduced. This data structure is optimized for maximum throughput. (Contributed by Frédéric Bour, reviewed by François Pottier.) • The new functor `DataFlow.ForCustomMaps' offers a forward data flow analysis that is tuned for greater performance. (Contributed by Frédéric Bour, reviewed by François Pottier.) • The new module `Indexing' offers a safe API for manipulating indices into fixed-size arrays. This API involves some dynamic checks as well as static type checks, thereby (hopefully) greatly reducing the risk of confusion in code that uses many arrays and many indices into these arrays. (Contributed by Frédéric Bour, reviewed by François Pottier.) • In `DataFlow', allow the function `foreach_root' (which is part of the signature `DATA_FLOW_GRAPH') to call `contribute x _' several times at a single root `x'. New release of Menhir (20211125) ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-menhir-20211125/8896/1> François Pottier announced ────────────────────────── I am pleased to announce a new release of Menhir, with an exciting contribution by Frédéric Bour: a groundbreaking performance improvement in `menhir --list-errors'. This is made possible by an entirely new reachability algorithm, which has been designed and implemented by Frédéric, and which is described in our paper "Faster Reachability Analysis for LR(1) Parsers". This is the link to the paper: <http://cambium.inria.fr/~fpottier/publis/bour-pottier-reachability.pdf> To install the new release, just type ┌──── │ opam update │ opam install menhir.20211125 └──── Enjoy! François Pottier Francois.Pottier@inria.fr <http://cambium.inria.fr/~fpottier/> • The command `menhir --list-errors' has been sped up by a factor of up to x100, and requires up to x1000 less memory, thanks to a new LR(1) reachability algorithm, which has been designed and implemented by Frédéric Bour. • Better document the restricted way in which the `error' token must be used when using `--strategy simplified'. Menhir now checks that this token is used only at the end of a production, and warns if this is not the case. (Better yet, our suggestion is to not use the `error' token at all!) • The `$syntaxerror' keyword is now forbidden when using `--strategy simplified'. This keyword will be entirely removed in the next release. Incidentally, we have just found out that it behaves differently under the code back-end and under the table back-end. • Disable OCaml warning 39 (unused rec flag) in the OCaml code produced by Menhir's code back-end. This does not affect the table back-end. (Reported by Armaël Guéneau.) • Fix a bug in `--random-*' which could cause Menhir to diverge if the grammar uses the `error' token. • Warn if a terminal symbol is named `Error'. This creates a name clash in the public interface of the generated parser. • Menhir now requires OCaml 4.03.0 (instead of 4.02.3) and Dune 2.8.0 (instead of 2.0.0). Lwt 5.5.0, Lwt_domain 0.1.0, Lwt_react.1.1.5 ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-5-0-lwt-domain-0-1-0-lwt-react-1-1-5/8897/1> Raphaël Proust announced ──────────────────────── It is my pleasure to announce the release of Lwt version 5.5.0, Lwt_domain version 0.1.0, Lwt_react version 1.1.5, Lwt_ppx version 2.0.3 and Lwt_ppx_let version 5.5.0. <https://github.com/ocsigen/lwt/releases/tag/5.5.0> All those packages can be installed via opam as usual. :rotating_light: Deprecation ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ One notable change is the deprecation of `Lwt_main.yield' and `Lwt_unix.yield'. It is recommended to use `Lwt.pause' instead. :rocket: Lwt_domain: an interface to multicore parallelism ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Another notable change is the addition of the Lwt_domain package. This package includes a single module `Lwt_domain' with functions to execute some computations in parallel, using the features of Multicore OCaml. The package requires an OCaml compiler with domains support to install. Code for this package is the work of @sudha with reviews and packaging from Lwt contributors. Other changes ╌╌╌╌╌╌╌╌╌╌╌╌╌ The full list of changes is available in the [CHANGES file]. [CHANGES file] <https://github.com/ocsigen/lwt/blob/5.5.0/CHANGES> OCaml's CI is gradually moving to GitHub Actions ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamls-ci-is-gradually-moving-to-github-actions/8902/1> Sora Morimoto announced ─────────────────────── The OCaml team started switching to GitHub Actions last year for some of the official OCaml repositories. Also, we have released some CI related stuff, such as setup-ocaml, to the community. Some OCaml hackers also know that CI in the OCaml community is gradually switching to GitHub Actions nowadays. However, what gradually became a problem when we started switching was that the number of concurrent jobs that could run in a free account on GitHub was not enough for our activeness. One of the major pain points for compiler contributors is that the wait time for CI to complete, which is unrelated to the actual build, is too long. However, this has been a pain point in all services, even before GitHub Actions. The GitHub team did their best to help us make it better. As a result, they offered to upgrade the OCaml organization's plan to the team plan for free, which means that we can now benefit from a range of features, including access to 3x more concurrent runners than before. • About team plan: <https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration> • Concurrency/plan: <https://docs.github.com/en/get-started/learning-about-github/githubs-products#github-team> We would like to thank GitHub for supporting our team and Ahmed Bilal, who supported this effort. How to combine 3 monads: Async/Lwt, Error and State? ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/how-to-combine-3-monads-async-lwt-error-and-state/8906/9> Deep in this thread, Ivan Gotovchits said ───────────────────────────────────────── The monads library provides the transformers for some well-known monads. All these monads have a more or less standard implementation, offering the same performance as any other monadic library can offer. Like there is no better way of implementing the state monad other than a function. We have experimented a lot with different performance optimizations, such as boxing and unboxing it and inlining various operators, and keep experimenting to get the maximum from the current compiler. In BAP, we heavily use the monads library, first of all for our [knowledge representation and reasoning engine], which is the foundation for all BAP analyses. We also use it for [emulating binary programs]. The rich interface is here to make our life easier and more comfortable when we use monads. It definitely comes for free¹ as the number of functions doesn't affect the performance of the underlying monad. But… there is always a but :) Stacking monads using a transformer does have a price. Even with the flambda compiler. The latter is doing an excellent job of unstacking them and eliminating the overhead of having a chain of monads. But our latest experiments show that a custom-made monad (still with the monads library) performs better under either branch of the compiler. We [have rewritten our main monads] that were relying on transformers and got from 20% to 50% performance improvement. But that is not to say that the monads library itself is slow or that we're not using it, it is to say that there are other options to transformers that might work in some cases. See the linked PR if you want to learn the trick. ¹⁾ Provided that we ignore the size of the executable, e.g., linking the core_kernel library results in a quite large binary, which may increase the startup time. Insignificantly, but in some use cases, it might be a significant factor. [knowledge representation and reasoning engine] <https://binaryanalysisplatform.github.io/bap/api/master/bap-knowledge/Bap_knowledge/Knowledge/index.html> [emulating binary programs] <https://binaryanalysisplatform.github.io/bap/api/master/bap-primus/Bap_primus/Std/index.html> [have rewritten our main monads] <https://github.com/BinaryAnalysisPlatform/bap/pull/1361> Ivan Gotovchits then said ───────────────────────── As it was already suggested, you can use [monad transformers], to compose several monads into a single monad. As a show-case, we will use the [monads] library (disclaimer, I am an author of this library), which you can install with ┌──── │ opam install monads └──── It offers most of the well-known monads in a form of a monad transformer, which in terms of OCaml, is a functor that takes a monad and returns a new monad that enriches it with some new behavior. For example, to make a non-deterministic error monad, we can do `Monad.List.Make(Monad.Result.Error)' and get a monadic structure (i.e., a module that implements the [Monad.S] interface) that is both a list monad and an error monad. The small caveat is that the operations of the wrapped monad, the error monad in our case, are not available directly, so we have to _lift_ them, e.g., ┌──── │ let fail p = lift @@ Monad.Result.Error.fail p └──── So that in the end, the full implementation of the transformed monad still requires some boilerplate code, ┌──── │ module ListE = struct │ type 'a t = 'a list Monad.Result.Error.t │ include Monad.List.Make(Monad.Result.Error) │ let fail p = lift@@Monad.Result.Error.fail p │ (* and so on for each operation that is specific to the wrapped monad *) │ end └──── Now, let's try wrapping the Lwt monad into the state. We don't want to add the Error monad because Lwt is already the error monad and adding an extra layer of errors monad is not what we want. First of all, we need to adapt the `Lwt' monad to the `Monad.S' interface, e.g., ┌──── │ module LwtM = struct │ type 'a t = 'a Lwt.t │ include Monad.Make(struct │ type 'a t = 'a Lwt.t │ let return = Lwt.return │ let bind = Lwt.bind │ let map x ~f = Lwt.map f x │ let map = `Custom map │ end) │ end └──── If we want to keep the state type monomorphic, then we will need a module for it. Suppose your state is represented as, ┌──── │ module State = struct │ type t = string Map.M(String).t │ end └──── Now, we can use it to build our `State(Lwt)' Russian doll, ┌──── │ module IO = struct │ include Monad.State.T1(State)(LwtM) │ include Monad.State.Make(State)(LwtM) │ │ (* let's lift [read] as an example *) │ let read fd buf ofs len = │ lift (Lwt_unix.read fd buf ofs len) │ end └──── The `Monad.State.T1' functor is used to create the types for the generated monad. You can write them manually, of course, like as we did in the List(Error) example, but the type generating modules are here for the convenience¹ Now, let's get back to the problem of the lifting. It looks tedious to impossible to lift every operation from Lwt. Commonly, we try to put the smaller monad inside, to minimize the work, but it doesn't work with Lwt as the latter is not a transformer. So what is the solution? For me, the solution is to not lift the operations at all, but instead, define your IO abstraction and hide that it is using Lwt underneath the hood. This will make the code that uses this new abstraction more generic and less error-prone so that it can focus on the business logic and the implementation details could be hidden inside the monad implementation. This is what the monads are for, anyway. ¹⁾ We omit the types from the output of the `Make' functor since for a long time OCaml didn't allow the repetition of types in a structure so having the types in it will prevent us from composing various flavors of monads using `include'. It is also a long-time convention widely used in many OCaml libraries, including Core and Async. A convention that we probably don't need anymore. [monad transformers] <https://en.wikipedia.org/wiki/Monad_transformer> [monads] <https://binaryanalysisplatform.github.io/bap/api/master/monads/Monads/Std/index.html> [Monad.S] <https://binaryanalysisplatform.github.io/bap/api/master/monads/Monads/Std/Monad/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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 39307 bytes --]
[-- Attachment #1: Type: text/plain, Size: 15299 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 07 to 14, 2021. Table of Contents ───────────────── kqueue-ml 0.2.0 and poll 0.1.0 SWIPl-OCaml v0.5 - Never write your own unification algorithms again! opam 2.1.2 Set up OCaml 2.0.0-beta10 A hassle-free setup to release binaries for different platforms: the opam release process experiment Set up OCaml 2.0.0-beta11 What's the best way to save an huge amount of data in a file p5scm 0.1.0 nanoid 1.0.0 Other OCaml News Old CWN kqueue-ml 0.2.0 and poll 0.1.0 ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-kqueue-ml-0-2-0-and-poll-0-1-0/8958/1> Anurag Soni announced ───────────────────── I'd like to announce new releases for [kqueue-ml] (version 0.2.0) and an initial release of [poll] (version 0.1.0). *Kqueue-ml*: Thin bindings to the kqueue event notification system. Changes since the last release: • Remove dependency on ctypes • Limit support to 64 bit systems • Adds constant values to be used as filter flags in the public API Installation: [opam install kqueue] Caveat: This is again mostly tested on macOS, but I plan to work on testing and fixing bugs for getting the library to work well on the various BSD systems, so please open issues if you use it on a BSD system and notice problems (Thanks!). *Poll*: Portable OCaml interface to macOS/Linux/Windows native IO event notification mechanisms Installation: [opam install poll] This is the first release of poll, which builds on top of `kqueue-ml' and adds bindings to the system IO event notifications on linux and windows to provide a portable polling interface. It uses kqueue on macOS, epoll on linux, and uses [wepoll] on windows so it can leverage IOCP on windows instead of select. All io events will be level triggered, i.e. there will be a notification as long as the file descriptor being watched is ready to read/write. If you experience any problems, please open an issue on the Github Issue tracker :slightly_smiling_face: [kqueue-ml] <https://github.com/anuragsoni/kqueue-ml/> [poll] <https://github.com/anuragsoni/poll> [opam install kqueue] <https://opam.ocaml.org/packages/kqueue/> [opam install poll] <https://opam.ocaml.org/packages/poll/poll.0.1.0/> [wepoll] <https://github.com/piscisaureus/wepoll> SWIPl-OCaml v0.5 - Never write your own unification algorithms again! ═════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-swipl-ocaml-v0-5-never-write-your-own-unification-algorithms-again/8968/1> Kiran Gopinathan announced ────────────────────────── Hey all! I am just posting to announce a new package I've been working on: OCaml bindings to SWI-Prolog (ver 8.5 or higher)! <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/b/b5a466fc6bc98f83b6935205ea9b4ff1d16a324d.png> It's currently in the process of being submitted to OPAM, but it's my first time writing a package with bindings to C (using ctypes), so some further changes might be needed? maybe?, but you can find the source code repository here: [repo]/[github mirror]. As a sneak peek of what the API looks like, here's a hello world: ┌──── │ (* initialise SWIProlog *) │ let () = Swipl.initialise () │ (* setup the prolog database with some facts *) │ let () = Swipl.load_source "hello :- writeln('hello world')." │ (* construct a Swipl term in OCaml *) │ let hello = Swipl.Syntax.(!"hello") │ (* send the term to the Prolog engine *) │ let () = Swipl.with_ctx @@ fun ctx -> Swipl.call ctx hello └──── I've taken care to provide some detailed documentation + quick start guide using odoc (see <https://gopiandcode.github.io/SWIPL-OCaml/swipl/index.html>) - the quick start guide shows a step by step walkthrough on using the library to write a type inference algorithm for lambda calculus using OCaml+Prolog (no need to write your own UF). Anyway, hope this might be useful for others - I have spent way too long racking my brains on writing dumb custom unification algorithms, but now, no more! [repo] <https://gitlab.com/gopiandcode/swipl-ocaml> [github mirror] <https://github.com/Gopiandcode/SWIPL-OCaml> Kiran Gopinathan later added ──────────────────────────── Here's another example that might be interesting for those who have experience with SWI-Prolog. You can even get native interaction with CHR: <https://en.wikipedia.org/wiki/Constraint_Handling_Rules> is a very elegant framework which comes bundled with SWI Prolog that allows users to write complex domain specific constraint solving engines in a concise declaritive way. Here's a CHR system that models the interaction between `salt' and `water' (basic I know, but look up CHR to see some more powerful examples): ┌──── │ let () = Swipl.load_source " │ :- use_module(library(chr)). │ │ :- chr_constraint salt/0, water/0, salt_water/0. │ │ salt, water <=> salt_water. │ │ reducesTo_(Goal, C) :- │ call(Goal), │ call(user:'$enumerate_constraints'(C)). │ reducesTo(Goal, Constraints) :- │ findall(Constraint, reducesTo_(Goal, Constraint), Constraints). │ " └──── Which we can then embed into OCaml using the following code: ┌──── │ let solve_constraints ls = │ (* Create a new term variable context *) │ Swipl.with_ctx (fun ctx -> │ (* create a term for the result *) │ let result = Swipl.fresh ctx in │ (* encode the constraint store *) │ let goal = encode ls in │ (* send the query to the Prolog engine *) │ Swipl.call ctx (reducesTo goal result); │ (* extract the result *) │ decode ctx result │ ) │ (* val solve_constraints: t list -> t list *) └──── (Again, some steps have been omitted for brevity, and you should check out the quick start guide for a step by step walkthrough). opam 2.1.2 ══════════ Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-2/8973/1> Kate announced ────────────── We are pleased to announce the minor release of [opam 2.1.2]. This opam release consists of [backported] fixes, including: • Fallback on `dnf' if `yum' does not exist on RHEL-based systems ([#4825]) • Use `--no-depexts' in CLI 2.0 mode. This further improves the use of opam 2.1 as a drop-in replacement for opam 2.0 in CI, for example with setup-ocaml in GitHub Actions. ([#4908]) To upgrade simply run: ┌──── │ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.1.2" └──── [opam 2.1.2] <https://github.com/ocaml/opam/releases/tag/2.1.2> [backported] <https://github.com/ocaml/opam/issues/4920> [#4825] <https://github.com/ocaml/opam/pull/4825> [#4908] <https://github.com/ocaml/opam/pull/4908> Set up OCaml 2.0.0-beta10 ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta10/8974/1> Sora Morimoto announced ─────────────────────── Added ╌╌╌╌╌ • Added "extends" experimentally. Changed ╌╌╌╌╌╌╌ • Remove some hacks as `--no-depexts' is now used in CLI 2.0 mode from opam 2.1.2. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta10> A hassle-free setup to release binaries for different platforms: the opam release process experiment ════════════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/a-hassle-free-setup-to-release-binaries-for-different-platforms-the-opam-release-process-experiment/8975/1> Kate announced ────────────── On top of the [opam 2.1.2 announcement], I’d like share an experiment with the opam release script used for this release. As you might know, for each releases of opam we provide pre-compiled binaries for ease of use. We’ve had a release script which up to this point required a specific setup to get it running correctly. For instance we had to setup a local OpenBSD machine (possibliy virtualised), a macOS/x86_64 machine and a macOS/arm64. This setup is rather tedious to reproduce. To improve this situation I’ve experimented over the past week with [QEMU] and [Rosetta 2] to make it a "one click script": <https://github.com/ocaml/opam/pull/4947> This change makes so that the script now only requires a macOS/arm64. From there you can: • compile locally for macOS/arm64 binaries • compile locally for macOS/x86_64 binaries (using Rosetta 2) • compile for BSDs (using QEMU) • compile for Linux (using Docker) With this, the [binaries] for this release have been compiled with this more reproducible setup, and now include FreeBSD/x86_64 binaries as well :sparkles: If someone wants to have a similar setup to distribute binaries here is the git repository (using Git LFS to store the large files). Feel free to use and experiment with it: <https://gitlab.com/kit-ty-kate/qemu-base-images> For now it only has OpenBSD/x86_64 and FreeBSD/x86_64 images but it could theoretically have more. Although I’m not accepting PRs for now (for obvious security reasons), I’m open to suggestions to add more platforms. See the [README] for high level details about the setup. [opam 2.1.2 announcement] <https://discuss.ocaml.org/t/ann-opam-2-1-2/8973> [QEMU] <https://en.wikipedia.org/wiki/QEMU> [Rosetta 2] <https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2> [binaries] <https://github.com/ocaml/opam/releases/tag/2.1.2> [README] <https://gitlab.com/kit-ty-kate/qemu-base-images/-/blob/master/README.md> Set up OCaml 2.0.0-beta11 ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta11/9002/1> Sora Morimoto announced ─────────────────────── Fixed ╌╌╌╌╌ • Add support for more styles for the ocamlformat configuration in lint-fmt action. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta11> What's the best way to save an huge amount of data in a file ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/whats-the-best-way-to-save-an-huge-amount-of-data-in-a-file/9003/5> Deep in this thread, Simon Cruanes announced ──────────────────────────────────────────── What a coincidence, I wrote an [Avro library] very recently. The paint is still fresh. However, it might be worth giving it a try as it's exactly the targeted use case: many rows of relatively simple data, encoded as binary; it also supports gzip compression (per "block" of N many rows, with N configurable). And there's no need to worry about endianess. It typically uses code generation from a schema (a json file). There's libraries for Avro in java (with all the Spark ecosystem) and also python (see "fastavro"). [Avro library] <https://github.com/c-cube/ocaml-avro> p5scm 0.1.0 ═══════════ Archive: <https://discuss.ocaml.org/t/ann-p5scm-0-1-0/9014/1> Jason Nielsen announced ─────────────────────── I’ve released [p5scm] which is now up on `opam'. It is a scheme-like implementation on top of `camlp5''s [pa_schemer.ml] extension. I know that `camlp5' isn't the cool kid on the block these days but it is a powerful tool and pretty cool in my estimation ;-). [p5scm] <https://github.com/drjdn/p5scm> [pa_schemer.ml] <https://github.com/camlp5/camlp5/blob/master/etc/pa_schemer.ml> nanoid 1.0.0 ════════════ Archive: <https://discuss.ocaml.org/t/ann-nanoid-1-0-0/9017/1> mefyl announced ─────────────── I'm pleased to announce the release of [nanoid 1.0.0]. NanoID are [popular unique ids] amongst the javascript ecosystem. This library brings an equivalent native implementation and a virtual library to transparently branch between the native implementation and the original javascript one. The intent is to enable pieces of code generating such ids to be moved transparently between frontend and backend of a web stack. This is an humble first contribution to gain some experience and will hopefully be followed by more of our internal developments. [nanoid 1.0.0] <https://github.com/routineco/ocaml-nanoid> [popular unique ids] <https://github.com/ai/nanoid> Other OCaml News ════════════════ >From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [Monorobot: a Slack bot for monorepos] • [opam 2.1.2 release] [OCaml Planet] <http://ocaml.org/community/planet/> [Monorobot: a Slack bot for monorepos] <https://tech.ahrefs.com/monorobot-a-slack-bot-for-monorepos-374260e2ca43?source=rss----303662d88bae--ocaml> [opam 2.1.2 release] <http://opam.ocaml.org/blog/blog/opam-2-1-2/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 30884 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4053 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 14 to 21, 2021. Table of Contents ───────────────── Are you teaching using the Learn-OCaml platform? A SOCKS implementation for OCaml Old CWN Are you teaching using the Learn-OCaml platform? ════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-12/msg00007.html> Erik Martin-Dorel announced ─────────────────────────── The OCaml Software Foundation is developing the teaching platform Learn-OCaml that provides auto-graded exercises for OCaml, and was initially authored by OCamlPro for the OCaml MOOC: <https://ocaml-sf.org/learn-ocaml/> The platform is free software and easy to deploy; this is great, but as a result we keep learning of users/deployments that we had no idea of. We would be interested in having a better view of our user-base. If you use Learn-OCaml as a teacher, could you answer this email (To: e.mdorel@gmail.com) and let us know? Ideally we would like to know: • Where are you using Learn-OCaml? → in which university (in a specific course?), or in which company, online community or … ? • How many students/learners use your deployment in a year? Also FYI: • For an example of Learn-OCaml instance, see <https://discuss.ocaml.org/t/interesting-ocaml-exercises-from-francois-pottier-available-online/7050> • Last October we had a 0.13.0 release, full of new features: <https://discuss.ocaml.org/t/ann-release-of-ocaml-sf-learn-ocaml-0-13-0/8577> • For any question related to Learn-OCaml, feel free to create a discussion topic on <https://discuss.ocaml.org/> , category Community, tag /learn-ocaml/. • And if need be, opening an issue in <https://github.com/ocaml-sf/learn-ocaml/issues> if of course warmly welcome as well. A SOCKS implementation for OCaml ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/a-socks-implementation-for-ocaml/9041/1> Renato Alencar announced ──────────────────────── I have been working on a SOCKS implementation for OCaml and specially for MirageOS. It's not really complete or stable yet (not even published), it only has a couple of proof of concepts on the examples directory and it doesn't integrate with the well known libraries of the ecosystem. I would like to ask for feedback, and some thoughts about how could we have that in Conduit and Cohttp for example, so It'd be just plugged in into those libraries without having to directly depending on it. I plan to implement that for those libraries and have it submitted upstream, but not without some clear thoughts about how to make a clear interface for that. Besides being sloppy, I have a few issues described on GitHub, and it should be addressed on the next few days. Anyone is welcome to discuss those issues as some of them are still foggy for me, and having some other views on that would be great. <https://github.com/renatoalencar/ocaml-socks-client> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 14267 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4612 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 21 to 28, 2021. Happy Winter Solstice! Table of Contents ───────────────── New release of Feat Debugger support for OCaml Old CWN New release of Feat ═══════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-12/msg00010.html> François Pottier announced ────────────────────────── I am happy to announce a new release of Feat, a library that offers support for counting, enumerating, and sampling objects of a certain kind, such as (say) the inhabitants of an algebraic data type. This new release integrates a contribution by Jonah Beckford. The library is now split in three packages: `feat-core' is parameterized over an implementation of big integers; `feat' instantiates `feat-core' with big integers provided by `zarith'; `feat-num' instantiates it with big integers provided by `num'. ┌──── │ opam update │ opam install feat │ # or: opam install feat-num └──── More details can be found here: <https://gitlab.inria.fr/fpottier/feat/> Debugger support for OCaml ══════════════════════════ Archive: <https://discuss.ocaml.org/t/debugger-support-for-ocaml/9057/1> Christian Lindig asked ────────────────────── What is the current state of debugger support for OCaml? I am aware of ocamldebug but every time I'm trying to use it I feel thrown back to 2000 where it essentially existed in the same form (and still has no command line editing built in). Despite the powerful concept of time traveling, it does not seem very useful today. For example, it can't be attached to a running program and it does not work with native code. What is the state of GDB support? What debugger would one use on macOS? linoscope replied ───────────────── Have you taken a look at ocamlearlybird ([github], [announcement])? I have never used it myself, but based on [the demo] it seems pretty nice. [github] <https://github.com/hackwaly/ocamlearlybird> [announcement] <https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180> [the demo] <https://imgur.com/U3GDHXM> Sid Kshatriya also replied ────────────────────────── I agree that debugging in OCaml seems to be stuck in time. This is extremely unfortunate because it is able to do time traveling (as you mention) which is something that many other languages still cannot boast. • `ocamldebug' does not work properly when there is more than 1 OS thread • As types are erased during compile time in OCaml, it can be difficult to debug polymorphic functions. Rust and C/C++ monomorphise all code so there is never any confusion about the type of anything in the debugger. Golang and Java have type information available during runtime so again, debugging is easy. In this respect OCaml is similar to Haskell while using the byte-code debugger. • The future of ocamldebug is unknown on multicore As far as GDB support is concerned, there was a project to improve GDB support (so you could print out variables like in ocamldebug IIUC) but it never got merged into trunk. However, if you are interested in low level debugging in gdb, here is a [recent] answer related to this. My guess is that `ocamldebug' will continue to work for the single domain, single thread case in OCaml 5.00 but ocamldebug is currently broken in multicore there (AFAIK). [recent] <https://discuss.ocaml.org/t/multicore-ocaml-september-2021-effect-handlers-will-be-in-ocaml-5-0/8554/9> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 14891 bytes --]
[-- Attachment #1: Type: text/plain, Size: 22488 bytes --] Hello Here is the latest OCaml Weekly News, for the week of December 28, 2021 to January 04, 2022. Table of Contents ───────────────── A hack for toplevel breakpoints using effect handlers Multi-shot continuations gone forever? New release of Menhir (20211230) Improved documentation for Fix pp-binary-ints 0.1.1 Old CWN A hack for toplevel breakpoints using effect handlers ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/a-hack-for-toplevel-breakpoints-using-effect-handlers/9065/1> wiktor announced ──────────────── I started playing with effect handlers and wondered if they could be used to implement toplevel breakpoints. It's a big hack and probably unsound at the moment, but it works and here's an example interaction: ┌──── │ let arr = │ let fact n = │ let arr = Array.make (n+1) 1 in │ let rec loop i = │ if i <= n then begin │ Break.break ["i", i; "arr", arr]; │ arr.(i) <- arr.(i-1) * i; │ loop (i+1) │ end │ in │ (loop 1; arr) │ in │ fact 5;; │ # (* We hit a breakpoint and obtain the continuation k *) │ k ();; │ - : bool = true │ # (* the bools are leaking from the execute_phrase function │ * inside the toplevel *) │ k ();; │ - : bool = true │ # i;; │ - : int = 3 │ # arr;; │ - : int array = [|1; 1; 2; 1; 1; 1|] │ # (* let's disturb the computation of factorials *) │ arr.(i-1) <- 42;; │ - : unit = () │ # k ();; │ - : bool = true │ # (* btw: here the user is like a scheduler for yield-based async *) │ k ();; │ - : bool = true │ # k ();; │ val arr : int array = [|1; 1; 42; 126; 504; 2520|] │ - : bool = true └──── Currently I don't try to clean up bindings or values, which is a source of unsoundness. After the last `k ()' we got two results: First the computation of `let arr ...' finished, and then the computation of `k ()' finished. But `k' is a part of the execution of `let arr ...', so these two executions "intersect" without one being contained in the other. This makes the question of what should the current variable bindings be complicated. Setting the bindings at end of execution is futile, when a continuation may in such a way leak bindings from breakpoint time. Possibly a stack discipline for the execution of phrases is required to make the environments behave properly: at the end of executing a phrase we cancel (with another effect, maybe) other executions which "depend" on the current execution (evaluate the `k' obtained from a breakpoint in the current execution). This should eliminate these "intersections" and we could throw out the bindings added by the cancelled executions. I haven't tried anything with polymorphism yet, but type variables should probably be changed into abstract types inside the binders. Here's the code: <https://github.com/ocaml-multicore/ocaml/compare/multicore-pr...wiktorkuchta:toplevel-break> wiktor later said ───────────────── Well, this might have been unnecessary, as most of it can be done properly in userspace (with more syntactic overhead). ┌──── │ open EffectHandlers │ open Deep │ │ type ('a, 'b) res = │ | Bp of 'a * ((unit, ('a, 'b) res) continuation) │ | Fin of 'b │ │ module type P1 = sig val i : int val arr : int array end │ type payload = P1 of (module P1) │ type _ eff += Break : payload -> unit eff │ │ let arr () = │ let fact n = │ let arr = Array.make (n+1) 1 in │ let rec loop i = │ if i <= n then begin │ perform (Break (P1 (module struct let i = i let arr = arr end))); │ arr.(i) <- arr.(i-1) * i; │ loop (i+1) │ end │ in │ (loop 1; arr) │ in │ fact 5;; │ │ let with_break th = │ try_with (fun () -> Fin (th ())) () │ { effc = fun (type a) (e : a eff) -> │ match e with │ | Break p -> Some (fun (k : (a,_) continuation) -> Bp (p, k)) │ | _ -> None } │ │ let cont = function │ | Bp (_, k) -> continue k () │ | Fin _ -> failwith "computation finished, cannot continue" │ │ let get = function │ | Bp (r, _) -> r │ | Fin _ -> failwith "computation finished, no breakpoint payload" │ │ let get1 r = match get r with P1 m -> m └──── ┌──── │ # let r = with_break arr;; │ val r : (payload, int array) res = Bp (P1 <module>, <abstr>) │ # open (val get1 r);; │ val i : int = 1 │ val arr : int array = [|1; 1; 1; 1; 1; 1|] └──── The main pain point is having to define the payload types. In basic cases the payload type could be just a simple polymorphic variant. It would be nice if it could be completely inferred, but it's unlikely as `Break` has to have a statically known argument. With a bit of help from tooling (ppxes for code generation and shorthands in the toplevel), this could be better than printf debugging. Guillaume Munch-Maccagnoni then said ──────────────────────────────────── This is an interesting experiment. • This reminds me of the idea of high-level stack inspection for debugging and security (articulated for instance in Clements' PhD thesis _[Portable and high-level access to the stack with Continuation Marks]_; here's [another more recent paper] from the Racket people that might be relevant). One can ask whether a PPX can provide high-level stack inspection or if one needs support from the compiler for that. It's nice to experiment. • A few years ago someone asked whether there could be a use to untyped algebraic effects in OCaml (in the sense that they do not appear in the effect annotation in function types). I proposed debugging as an example. Someone suggested that it is not too hard to adapt the interface types of all functions in the call chain to add the appropriate effect annotation (and remove it afterwards), but I was not convinced. [Portable and high-level access to the stack with Continuation Marks] <https://www2.ccs.neu.edu/racket/pubs/dissertation-clements.pdf> [another more recent paper] <https://dl.acm.org/doi/10.1145/3385412.3385981> Multi-shot continuations gone forever? ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/multi-shot-continuations-gone-forever/9072/1> cyberpink asked ─────────────── What happens with multi-shot continuations now that Obj.clone_continuation was removed? ([https://github.com/ocaml-multicore/ocaml-multicore/pull/651]) Anything that requires a "fork" operation, like say, a probabilistic programming EDSL, needs this. None of the old examples I've looked at like [Delimcc on top of effects] have been updated to use a new method, and I haven't been able to find any hints of one. Are multi-shot continuations just not possible now? Are there plans to add something equivalent back in later? [https://github.com/ocaml-multicore/ocaml-multicore/pull/651] <https://github.com/ocaml-multicore/ocaml-multicore/pull/651> [Delimcc on top of effects] <https://github.com/ocaml-multicore/effects-examples/blob/master/delimcc.ml> Nicolás Ojeda Bär replied ───────────────────────── Yes, multi-shot continuations are gone and is unlikely that they will find their way back any time soon. One (good) reason is explained in <https://dl.acm.org/doi/10.1145/3434314> : <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/8/8d26520ef0f790fd3dc4407458d925c1a28fdbca.png> and <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/b/b28fa14f967364743277c0132a804c430d2d66d1.png> Guillaume Munch-Maccagnoni then said ──────────────────────────────────── I think the question still stands. You cut the sentence “_Extending our system with multi-shot continuations is future work (§8)_”. Also the paper is about a particular model based on separation logic rather than OCaml itself (for instance the authors also mention that their continuations are affine instead of linear unlike in OCaml multicore). Nevertheless, the multicore designers were aware that duplicating continuations makes it complicated to reason about resources. The topic of mixing continuations and linearity has been better studied from the angle of algebraic models of computation and proof theory. Essentially, with an effect system you could ensure that certain kinds of effects do not happen in the delimited part of the program (including allocating a resource), which controls copiability of the stack from the point of view of reasoning about the program. This is inspired by some logics that mix classical and intuitionistic or linear logic. From this angle the ability to copy a continuation would be restricted to a sub-part of the language which is pure to some degree. This should also be a suitable starting point if one wanted to develop a program logic to formalise the reasoning about such programs. However according to [#651] there were more technical reasons to drop `clone_continuation', such as breaking compiler optimizations. I am curious as well to know whether there are plans to reintroduce `clone_continuation' at some point, but obviously this would require some effort. [#651] <https://github.com/ocaml-multicore/ocaml-multicore/pull/651> KC Sivaramakrishnan said ──────────────────────── @nojb and @gadmm have already answered why we've dropped support for `clone_continuation' now. We will need to track the copiability of the continuation in the continuation type and compiler optimisations also need to be made aware of the possibility of copying. Given the pervasive nature of its effects, there are no immediate plans to bring the feature back. We will have to come back to this after we have typed effects. Anything that requires a “fork” operation, like say, a probabilistic programming EDSL One can get pretty far with PPL with just one-shot continuations. My student and I did some experiments building a DSL for a PPL to learn about the space: <https://github.com/Arnhav-Datar/EffPPL>. Having spoken to PPL experts there are indeed some usecases where multi-shot continuations are useful, but from what I understand, the one-shotness isn't a blocker for PPL. I would be interested in collecting usecases where multi-shot continuations are absolutely necessary. gasche then said ──────────────── Interesting! My (probably naive) mental model of HANSEI-style libraries, using multishot continuations, is that they are extensions/generalization of a non-probabilistic "logic/non-deterministic monad" that searches for the set of solutions to a problem. Multishot continuations are naturally used in non-deterministic computations at backtracking points, to explore different search directions and collect the result. It is possible to avoid multishot continuations by replaying the whole search from the start each time (reference: [Capturing the future by replaying the past]), but this involves duplicated computations so it is less efficient (reference: [Asymptotic speedup with first-class control]). Can you give some intuition of how other approaches to probalistic inference work, that do not require multishot continuations? Are they also duplicating computations, or are they using a magic trick to avoid this issue with a different inference algorithm? I tried to find an answer to this question by reading the [internship report], but I couldn't locate an answer. (The report mentions HANSEI in the related work, but it does not discuss this question.) The report explains that the inference algorithm, called HMC (Hamiltonian Monte Carlo), uses automatic differenciation; so it uses a sort of symbolic manipulation / analysis of the probabilistic program to sample. But does this avoid repeated computations? It may be the case instead that the differential is as large or larger than the program itself, and that the search algorithm using this differential in effect perform a program-sized computation at each search step, duplicating computations. [Capturing the future by replaying the past] <https://arxiv.org/pdf/1710.10385> [Asymptotic speedup with first-class control] <https://arxiv.org/abs/2007.00605> [internship report] <https://github.com/Arnhav-Datar/EffPPL/blob/main/EffPPL_Report.pdf> Sadiq said ────────── Not a PPL but I've been hacking on a little effects-based model checker for concurrent data structures that implements dynamic partial order reduction (<https://github.com/sadiqj/dscheck/> - a WIP!). Multi-shot continuations would have been very useful. I ended up implementing something that involves maintaining a schedule and repeatedly replaying the computation. It looks very similar to what [Capturing the future..] proposes. [Capturing the future..] <https://arxiv.org/pdf/1710.10385> New release of Menhir (20211230) ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-menhir-20211230/9077/1> François Pottier announced ────────────────────────── Dear OCaml & Menhir users, I am pleased to announce a new release of Menhir, with a major improvement. The code back-end has been rewritten from the ground up by Émile Trotignon and by myself, and now produces efficient and well-typed OCaml code. The infamous Obj.magic is not used any more. Furthermore, the new code back-end produces code that is more aggressively optimized, leading to a significant reduction in memory allocation and a typical performance improvement of up to 20% compared to the previous code back-end. ┌──── │ opam update │ opam install menhir.20211230 └──── Happy well-typed parsing in 2022! 2021/12/30 ╌╌╌╌╌╌╌╌╌╌ • The code back-end has been rewritten from the ground up by Émile Trotignon and François Pottier, and now produces efficient and *well-typed* OCaml code. The infamous `Obj.magic' is not used any more. The table back-end and the Coq back-end are unaffected by this change. The main side effects of this change are as follows: • The code back-end now needs type information. This means that /either/ Menhir's type inference mechanism must be enabled (the easiest way of enabling it is to use Menhir via `dune' and to check that the `dune-project' file says `(using menhir 2.0)' or later) /or/ the type of every nonterminal symbol must be explicitly given via a `%type' declaration. • The code back-end no longer allows the type of any symbol to be an open polymorphic variant type, such as `[> `A ]'. As a workaround, we suggest using a closed polymorphic variant instead. • The code back-end now adheres to the /simplified/ error-handling strategy, as opposed to the /legacy/ strategy. For grammars that do /not/ use the `error' token, this makes no difference. For grammars that use the `error' token in the limited way permitted by the simplified strategy, this makes no difference either. The simplified strategy makes the following requirement: the `error' token should always appear at the end of a production, whose semantic action should abort the parser by raising an exception. Grammars that make more complex use of the `error' token, and therefore need the `legacy' strategy, cannot be compiled by the new code back-end. As a workaround, it is possible to switch to the table back-end (using `--table --strategy legacy') or to the ancient code back-end (using `--code-ancient'). *In the long run, we recommend abandoning the use of the `error' token*. Support for the `error' token may be removed entirely at some point in the future. The original code back-end, which has been around since the early days of Menhir (2005), temporarily remains available (using `--code-ancient'). It will be removed at some point in the future. The new code back-end offers several levels of optimization, which remain undocumented and are subject to change in the future. At present, the main levels are roughly as follows: • `-O 0 --represent-everything' uses a uniform representation of the stack and produces straightforward code. • `-O 0' uses a non-uniform representation of the stack; some stack cells have fewer fields; some stack cells disappear altogether. • `-O 1' reduces memory traffic by moving `PUSH' operations so that they meet `POP' operations and cancel out. • `-O 2' optimizes the reduction of unit productions (that is, productions whose right-hand side has length 1) by performing a limited amount of code specialization. The default level of optimization is the maximum level, `-O 2'. • The new command line switch `--exn-carries-state' causes the exception `Error' to carry an integer parameter: `exception Error of int'. When the parser detects a syntax error, the number of the current state is reported in this way. This allows the caller to select a suitable syntax error message, along the lines described in [Section 11] of the manual. This command line switch is currently supported by the code back-end only. • The `$syntaxerror' keyword is no longer supported. • Document the trick of wrapping module aliases in `open struct ... end', like this: `%{ open struct module alias M = MyLongModuleName end %}'. This allows you to use the short name `M' in your grammar, but forces OCaml to infer types that refer to the long name `MyLongModuleName'. (Suggested by Frédéric Bour.) [Section 11] <http://cambium.inria.fr/~fpottier/menhir/manual.html#sec68> Improved documentation for Fix ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-improved-documentation-for-fix/9079/1> François Pottier announced ────────────────────────── My last contribution for 2021 is an improved documentation for Fix, a library that helps with various algorithmic constructions that involve memoization, recursion, and numbering. The documentation can be [viewed online]. It can also be viewed locally (on your own machine) as follows: ┌──── │ opam update │ opam install fix.20211231 │ opam install odig │ odig odoc # this may take some time │ odig doc fix # this opens the doc in your browser └──── Happy fix'in' in 2022! [viewed online] <http://cambium.inria.fr/~fpottier/fix/doc/fix/> pp-binary-ints 0.1.1 ════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pp-binary-ints-0-1-1/9080/1> Ifaz Kabir announced ──────────────────── Tired of printing octals and hexadecimals and then mentally converting them to bits. Ever wanted to just see the bits in an int? Now you can! Just run `opam install pp-binary-ints' and off you go: ┌──── │ # Pp_binary_ints.Int.to_string 0b10101001;; │ - : string = "10101001" └──── You can find the documentation for the project and more examples of how to use it [here]. The library is very customizable. • You can choose to print with `0b' prefixes and `_' separators. • You can choose to print zeros just like the non-zeros, with prefixes and separators. • If you use zero padding, you can control how many leading zeros show up with the `~min_width' argument. • It correctly handles the edge cases when adding `_' separators: you won’t get leading underscores. • It includes pretty printers that work with `Format' and `Fmt' , not just `to_string' functions. • Supports `int', `int32', `int64', and `nativeint'. • Don't like the default prefixes and suffixes? Customize the prefixes and suffixes with the provided functor. [here] <https://ifazk.github.io/pp-binary-ints/pp-binary-ints/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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 41929 bytes --]
[-- Attachment #1: Type: text/plain, Size: 13456 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 04 to 11, 2022. Table of Contents ───────────────── New release of PPrint (20220103) Bogue, the OCaml GUI Cohttp 5.0.0 and 2.5.6 Multicore OCaml: December 2021 and the Big PR Set up OCaml 2.0.0-beta12 Old CWN New release of PPrint (20220103) ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-new-release-of-pprint-20220103/9097/1> François Pottier announced ────────────────────────── I am pleased to announce a new release of PPrint, the pretty-printing library, with [improved documentation]. The documentation can also be viewed offline: ┌──── │ opam update │ opam install pprint.20220103 │ opam install odig │ odig odoc # this may take some time │ odig doc pprint # this opens the doc in your browser └──── Happy pretty-printing! [improved documentation] <http://cambium.inria.fr/~fpottier/pprint/doc/pprint/> Bogue, the OCaml GUI ════════════════════ Archive: <https://discuss.ocaml.org/t/ann-bogue-the-ocaml-gui/9099/1> sanette announced ───────────────── I'm happy to announce a brand new version of [Bogue], a GUI (Graphical User Interface) library entirely written in `ocaml', using SDL2 for hardware accelerated graphics. The doc can be found [here], it will be enriched over time. Install with `opam install bogue' In addition to the library, this installs an executable `boguex' to showcase about 50 useful constructions, see `boguex -h' for the list. Some screenshots of a demo compiled with the latest version: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/6/619a6b3c5d7a9860e4c24df7d8b931815e9b95a1.png> <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/3/3e5e04d1db0022d4070b7fd3dab45f4399828e90.png> Note that many widgets are not shown in this demo: tables, menus, drop-down select lists, knob buttons,… I will add more images to the doc when I have some time! [Bogue] <https://github.com/sanette/bogue> [here] <http://sanette.github.io/bogue/Principles.html> Cohttp 5.0.0 and 2.5.6 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-cohttp-5-0-0-and-2-5-6/9109/1> Marcello Seri announced ─────────────────────── We are glad to announce the release of version [5.0.0] and [2.5.6] of cohttp and its dependent packages. The latter is a bug fix release that in particular backports the compatibility with the upcoming release 0.15 of core and async. The first introduces the breaking changes [announced in the previous release]. I append the changelog below, which explains in details the changes and emphasizes the breaking changes: [5.0.0] <https://github.com/ocaml/opam-repository/pull/20246#issue-1080986510> [2.5.6] <https://github.com/ocaml/opam-repository/pull/20245#issue-1080822215> [announced in the previous release] <https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537> Cohttp.Header: new implementation (lyrm #747) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • New implementation of Header modules using an associative list instead of a map, with one major semantic change (function `get', see below), and some new functions (`clean_dup', `get_multi_concat') • More Alcotest tests as well as fuzzing tests for this particular module. Purpose ┄┄┄┄┄┄┄ The new header implementation uses an associative list instead of a map to represent headers and is focused on predictability and intuitivity: except for some specific and documented functions, the headers are always kept in transmission order, which makes debugging easier and is also important for [RFC7230§3.2.2] that states that multiple values of a header must be kept in order. Also, to get an intuitive function behaviour, no extra work to enforce RFCs is done by the basic functions. For example, RFC7230§3.2.2 requires that a sender does not send multiple values for a non list-value header. This particular rule could require the `Header.add' function to remove previous values of non-list-value headers, which means some changes of the headers would be out of control of the user. With the current implementation, an user has to actively call dedicated functions to enforce such RFCs (here `Header.clean_dup'). [RFC7230§3.2.2] <https://tools.ietf.org/html/rfc7230#section-3.2.2> Semantic changes ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Two functions have a semantic change : `get' and `update'. get ┈┈┈ `get' was previously doing more than just returns the value associated to a key; it was also checking if the searched header could have multiple values: if not, the last value associated to the header was returned; otherwise, all the associated values were concatenated and returned. This semantics does not match the global idea behind the new header implementation, and would also be very inefficient. ⁃ The new `get' function only returns the last value associated to the searched header. ⁃ `get_multi_concat' function has been added to get a result similar to the previous `get' function. update ┈┈┈┈┈┈ `update' is a pretty new function (#703) and changes are minor and related to `get' semantic changes. ⁃ `update h k f' is now modifying only the last occurrences of the header `k' instead of all its occurrences. ⁃ a new function `update_all' function has been added and work on all the occurrences of the updated header. New functions : ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ⁃ `clean_dup' enables the user to clean headers that follows the [RFC7230§3.2.2] (no duplicate, except `set-cookie') ⁃ `get_multi_concat' has been added to get a result similar to the previous `get' function. [RFC7230§3.2.2] <https://tools.ietf.org/html/rfc7230#section-3.2.2> Cohttp.Header: performance improvement (mseri, anuragsoni #778) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ *Breaking* the headers are no-longer lowercased when parsed, the headers key comparison is case insensitive instead. cohttp-lwt-unix: Adopt ocaml-conduit 5.0.0 (smorimoto #787) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ *Breaking* `Conduit_lwt_unix.connect''s `ctx' param type chaged from `ctx' to `ctx Lazy.t' other changes ╌╌╌╌╌╌╌╌╌╌╌╌╌ • cohttp-mirage: fix deprecated fmt usage (tmcgilchrist #783) • lwt_jsoo: Use logs for the warnings and document it (mseri #776) • lwt: Use logs to warn users about leaked bodies and document it (mseri #771) • lwt, lwt_unix: Improve use of logs and the documentation, fix bug in the Debug.enable_debug function (mseri #772) • lwt_jsoo: Fix exception on connection errors in chrome (mefyl #761) • lwt_jsoo: Fix `Lwt.wakeup_exn' `Invalid_arg' exception when a js stack overflow happens in the XHR completion handler (mefyl #762). • lwt_jsoo: Add test suite (mefyl #764). We wish to thank to all the users and the contributors for their help leading to this release. Multicore OCaml: December 2021 and the Big PR ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/multicore-ocaml-december-2021-and-the-big-pr/9115/1> Anil Madhavapeddy announced ─────────────────────────── Welcome to the December 2021 [Multicore OCaml] monthly report! The [previous updates] along with this update have been compiled by myself, @ctk21, @kayceesrk and @shakthimaan. Well, it's finally here! @kayceesrk opened the [Multicore OCaml PR#10831] to the main OCaml development repository that represents the "minimum viable" implementation of multicore OCaml that we decided on in [November's core team review]. The branch pushes the limits of GitHub's rendering capability, with around 4000 commits. Once the PR was opened just before Christmas, the remaining effort has been for a number of developers to pore over [the diff] and look for any unexpected changes that crept in during multicore development. A large number of code changes, improvements and fixes have been merged into the ocaml-multicore trees since the PR was opened to facilitate this upstreaming process. We're expecting to have the PR merged during January, and then will continue onto the "post-MVP" tasks described last month, but working directly from ocaml/ocaml from now on. We therefore remain on track to release OCaml 5.00 in 2022. In the multicore ecosystem, progress also continued: • `Eio' continues to improve as the recommended effects-based direct-style IO library to use with Multicore OCaml. • A newer `domainslib.0.4.0' has been released that includes bug fixes and API changes. • The continuous benchmarking pipeline with further integration enhancements between Sandmark and current-bench is making progress. We would like to acknowledge the following external contributors as well:: • Danny Willems (@dannywillems) for an OCaml implementation of the Pippenger benchmark and reporting an undefined behaviour. • Matt Pallissard (@mattpallissard) reported an installation issue with `Eio' with vendored uring. • Edwin Torok (@edwintorok) for contributing a PR to `domainslib' to allow use of a per-channel key. As always, the Multicore OCaml updates are listed first, which contain the upstream efforts, improvements, fixes, test suite, and documentation changes. This is followed by the ecosystem updates to `Eio', `Tezos', and `Domainslib'. The Sandmark, sandmark-nightly and current-bench tasks are finally listed for your reference. /editor’s note: please follow the archive link above for the full changelog./ [Multicore OCaml] <https://github.com/ocaml-multicore/ocaml-multicore> [previous updates] <https://discuss.ocaml.org/tag/multicore-monthly> [Multicore OCaml PR#10831] <https://github.com/ocaml/ocaml/pull/10831> [November's core team review] <https://discuss.ocaml.org/t/multicore-ocaml-november-2021-with-results-of-code-review/8934#core-team-code-review-1> [the diff] <http://github.com/ocaml/ocaml/pull/10831.diff> Stéphane Lavergne asked and Robin Björklin replied ────────────────────────────────────────────────── To clarify for relative newbies like myself: this would be a new way to do concurrent I/O, like Async and Lwt, but unlike those, it wouldn't require the use of a promise monad? In other words, does this mean that we'll have the choice between Async, Lwt and Eio in the near future for our concurrent I/O needs? That's correct as far as I can tell. This presentation provides an introduction to the current state of eio: <https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89> Set up OCaml 2.0.0-beta12 ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta12/9123/1> Sora Morimoto announced ─────────────────────── Fixed ╌╌╌╌╌ • Fallback to the version in which the assets exist if no assets exist in the latest opam release. • Instruct Cygwin setup to use "sys" symlinks during setup (partial workaround for bug with native symlinks in Cygwin setup - some depexts may still be affected) <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta12> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 25652 bytes --]
[-- Attachment #1: Type: text/plain, Size: 14277 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 18 to 25, 2022. Table of Contents ───────────────── wu-manber-fuzzy-search 0.1.0 (new library) findlib-1.9.2 Signals and Threads on Memory Management OCaml 4.14.0, first alpha release A brief survey for Learn-OCaml Community Blog post: Js_of_ocaml, a bundle size study Interesting OCaml Articles Old CWN wu-manber-fuzzy-search 0.1.0 (new library) ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-wu-manber-fuzzy-search-0-1-0-new-library/9173/1> Ifaz Kabir announced ──────────────────── I'm happy to introduce wu-manber-fuzzy-seach, my library for doing fuzzy searches using the Wu and Manber fuzzy search algorithm. The novel part of this library particularly, when compared to `agrep/ocamlagrep', is that I additionally provide a right-leaning variant of the algorithm. The variant reports better matches and error counts when looking at the first match. Here's an example of the differences. ┌──── │ # open Wu_Manber;; │ # StringSearch.(search ~k:2 ~pattern:"brown" ~text:"quick brown fox" |> report);; │ - : string = "Pattern matched with 2 errors at character 9 of text" │ # StringSearch.(search_right_leaning ~k:2 ~pattern:"brown" ~text:"quick brown fox" |> report);; │ - : string = "Pattern matched with 0 errors at character 11 of text" └──── It's a pure OCaml implementation, using `Optint.Int63.t' as bit-vectors. I don't current support all the extensions that `agrep/ocamlagrep' supports, and will definitely not match the performance: OCaml+C vs pure OCaml. The documentation for the library can be found [here]. It's not on `opam' yet, but there is a [PR]. Expect more bitvector, Levenshtein distance, and fuzzy search shenanigans in the near future! [here] <https://ifazk.github.io/wu-manber-fuzzy-search/> [PR] <https://github.com/ocaml/opam-repository/pull/20479> findlib-1.9.2 ═════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-01/msg00040.html> Gerd Stolpmann announced ──────────────────────── findlib-1.9.2 is out. The only change is a fix for a build problem regarding the OCaml-5 trunk. For manual, download, manuals, etc. see here: <http://projects.camlcity.org/projects/findlib.html> An updated OPAM package will follow soon. Signals and Threads on Memory Management ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/signals-and-threads-on-memory-management/9190/1> gasche said ─────────── I just had an excellent time listening to the last Signals and Threads podcast episode on [Memory Management], with Stephen Dolan (@stedolan) as the guest and Yaron Minsky (@Yaron_Minsky) as the host discussing: • memory management in programming languages in general • memory management in OCaml • ongoing research by Stephen and Leo White (@lpw25) on memory-management and data-representation features for OCaml (unboxed types, local values on the stack). The link <https://signalsandthreads.com/memory-management/> contains both the audio and a full text transcript. I would warmly recommend giving it a try if you are interested in programming language implementation. There is new stuff to learn for everyone, and I also liked the presentation of the parts I was already familiar with. [Memory Management] <https://signalsandthreads.com/memory-management/> Yaron Minsky replied ──────────────────── Thanks for the nice words. Interviewing Dolan was fun and I learned a lot. Local types are still very new: we're hoping to start rolling it out in a limited way internally in the next few weeks, and I expect we'll learn a lot from that. We plan on discussing it more publicly as well, but that's a bit farther out. In the meantime, the source is all available [on Github] if anyone wants to poke around. The approach to stack allocation is different and simpler than the one in Rust, as Dolan explained in the episode. Instead of having implicit, polymorphic lifetime variables, function arguments can be marked as local, which prevents the function in question from stashing a reference to those types. This avoids the need to deal with higher-rank polymorphism, which Rust's lifetime approach requires, and as a result makes inference work nicely. Another neat trick is that you can create functions that can allocate on the parent stack frame (by dint of not having their own stack frame). This lets you build smart constructors for stack-allocated values. Local types are apparently an example of modal types, though I don't really know enough type theory to have a deep sense of what that means. But it's a powerful thing, and local types appear to be useful for more than just stack allocation, as we're just starting to discover. [on Github] <https://github.com/ocaml-flambda/ocaml-jst> Yaron Minsky then added ─────────────────────── And, I suppose as I should always mention: we're looking for people to come and work with Dolan and Leo and the rest of the team on this kind of stuff. More here: <https://blog.janestreet.com/applied-PL-research/> OCaml 4.14.0, first alpha release ═════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-14-0-first-alpha-release/9191/1> octachron announced ─────────────────── The set of new features for the future version 4.14.0 of OCaml has been (finally) stabilized, three months after the release of OCaml 4.13.1. I am thus happy to announce the first alpha release for OCaml 4.14.0 . This alpha version is here to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions). You can see the progress on this front at <https://github.com/ocaml/opam-repository/issues/20501> . If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Most major OCaml developer tools are already supported with this alpha (from odoc to merlin), thus I expect us to switch to beta releases in the beginning of February. The full release is expected to happen in late February. This early release will give us time to focus on the release of OCaml 5.0. If you are interested by the list of new features and the ongoing list of bug fixes, the updated change log for OCaml 4.14.0 is available at: <https://github.com/ocaml/ocaml/blob/4.14/Changes> Happy hacking, Florian Angeletti for the OCaml team. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.14.0~alpha1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── With opam 2.1, the previous command line can be simplified to ┌──── │ opam update │ opam switch create 4.14.0~alpha1 └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.14.0~alpha1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── or with opam 2.1: ┌──── │ opam update │ opam switch create <switch_name> ocaml-variants.4.14.0~alpha1+options <option_list> └──── where `<option_list>' is a comma separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.14.0~alpha1+flambda+nffa ocaml-variants.4.14.0~alpha1+options ocaml-option-flambda │ ocaml-option-no-flat-float-array └──── All available options can be listed with `opam search ocaml-option'. If you want to test this version, it is advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various fixes in the process of being upstreamed. The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.14.0-alpha1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.0~alpha1.tar.gz> A brief survey for Learn-OCaml Community ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/a-brief-survey-for-learn-ocaml-community/9193/1> Erik Martin-Dorel announced ─────────────────────────── [This post is just a follow-up of an earlier message on [caml-list], intended to reach more learn-ocaml instructors, so you can ignore this one if you already replied!] The OCaml Software Foundation is developing the teaching platform Learn-OCaml that provides auto-graded exercises for OCaml, and was initially authored by OCamlPro for the OCaml MOOC: <https://ocaml-sf.org/learn-ocaml>. The platform is free software and easy to deploy; this is great, but as a result we keep learning of users/deployments that we had no idea of. We would be interested in having a better view of our user-base. If you use Learn-OCaml as a teacher, could you fill *[this Evento survey]* to let us know? (the survey will be closed on 2022-02-07) → It contains these questions: • Where are you using Learn-OCaml? (in which university (a specific course?), which company, online community or…?) • Would you like to see your university/company added in [github.com/ocaml-sf/learn-ocaml-places]? • How many students/learners use your deployment in a year? And just to recall, a few links: • For an example of Learn-OCaml instance, see <https://discuss.ocaml.org/t/interesting-ocaml-exercises-from-francois-pottier-available-online/7050> • Last October we had a 0.13.0 release with several new features: <https://discuss.ocaml.org/t/ann-release-of-ocaml-sf-learn-ocaml-0-13-0/8577> • For any question related to Learn-OCaml, feel free to create a discussion topic on <https://discuss.ocaml.org>, category *`Community'*, tag *`learn-ocaml'* (/similarly to this discussion topic!/ :slight_smile:) • And if need be, opening an issue in <https://github.com/ocaml-sf/learn-ocaml/issues> if of course warmly welcome as well. [caml-list] <https://sympa.inria.fr/sympa/arc/caml-list/2021-12/msg00007.html> [this Evento survey] <https://evento.renater.fr/survey/learn-ocaml-community-survey-vsn3yc7j> [github.com/ocaml-sf/learn-ocaml-places] <https://github.com/ocaml-sf/learn-ocaml-places#readme> Blog post: Js_of_ocaml, a bundle size study ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/blog-post-js-of-ocaml-a-bundle-size-study/9211/1> Javier Chávarri announced ───────────────────────── Hi all, I hope your Monday is going great. :slight_smile: I wanted to analyze bundle size performance in Js_of_ocaml, so I rewrote an existing ReScript web app to compare both outputs. Here is the blog post with all the data, conclusions, and takeaways: <https://www.javierchavarri.com/js_of_ocaml-bundle-size-study/> It has been a very interesting experiment, that helped me learn more about Js_of_ocaml and the way it generates JavaScript code, and also improve some small things along the way in the libraries I was using for the project. The conclusions, while maybe already known by others, are also quite exciting to me, as the experiment confirms my suspicion that Js_of_ocaml bundle size scales just fine as applications get more complex, so it is suitable for a quite significant number of real world scenarios. I hope you find it interesting and exciting as well. Please share any feedback you might have! Or any questions if anything is unclear. Interesting OCaml Articles ══════════════════════════ Archive: <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/94> Yotam Barnoy said ───────────────── <https://blog.darklang.com/first-thoughts-on-rust-vs-ocaml/#tooling-musing> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 27784 bytes --]
[-- Attachment #1: Type: text/plain, Size: 21540 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 25 to February 01, 2022. Table of Contents ───────────────── ppx_seq v0.1.1 OCaml Labs Joins Tarides For Diversity and the OCaml Community: Get Involved in Outreachy Summer 2022 Set up OCaml 2.0.0-beta13 First release of scfg Brr 0.0.3, a toolkit for programming browsers (anonymous?) polymorphic records 2 postdoc positions on Runtime Verification at CEA LIST, Université Paris-Saclay, France Old CWN ppx_seq v0.1.1 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-ppx-seq-v0-1-1/9227/1> hyphenrf announced ────────────────── Hello everyone, my first contribution to opam-repository has just been merged and is waiting to hit the caches of [opam.ocaml.org]. [ppx_seq] is a cute un-intrusive literal syntax for `Seq'. The rewriter is simple and has very small surface area: just `[%seq x; y; z; ...]' and `[%seq.empty]'. It tries to be maximally compatible with all OCaml releases from 4.07 (when `Seq' was introduced) to 4.14 and beyond The reason I created this rewriter is to make it an easier choice to reach first for `Seq' as a general data structure (instead of e.g. list). That wasn't quite attractive before because of how minimal the `Seq' module was, it was mostly used as an intermediate step between two types of collections, but now with 4.14 about to be released, `Seq' is becoming a first-class data structure with a very versatile API. I hope my little rewriter helps make it even more attractive to use. Check it out and maybe leave me some feedback. Thanks <3 [opam.ocaml.org] <https://opam.ocaml.org> [ppx_seq] <https://github.com/hyphenrf/ppx_seq> OCaml Labs Joins Tarides ════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-labs-joins-tarides/9229/1> Thomas Gazagnaire announced ─────────────────────────── Gemma Gordon (@gemmag) and I are delighted to announce that OCaml Labs, a spinout from the University of Cambridge, is joining Tarides. After successfully collaborating on many OCaml projects over the last four years, this alliance will formally combine the expertise of both groups. Joining forces will accelerate OCaml development and its broader adoption, and enable us to continue with our shared goal of bringing OCaml into mainstream use. Furthermore, it will bring the security, portability and performance of OCaml to a large spectrum of use-cases: from academic endeavours such as formal methods and existing threats within cyber security, to real-world applications for climate change, sustainable agriculture, and even space exploration! All of OCaml Labs’ existing responsibilities and open source commitments will migrate over to Tarides, and thanks to how closely the teams already work, business will continue without interruption to continuity or delivery. Gemma Gordon will step up as CEO of Tarides, and I will lead the technological vision and strategy as CTO. The OCaml 5.0 release will support multicore and effects handlers, influencing every aspect of the language and its ecosystem. The update will significantly improve both performance and user experience, whilst maintaining existing features that the community loves. Using the teams’ combined experience and zest for innovation, Tarides is looking to the future of the OCaml language and community with excitement. Since Tarides’ inception we have envisioned a future where all OCaml applications are easily deployable as specialised, secure and energy-efficient MirageOS unikernels. We believe that this alliance is a step further in that direction. _This alliance will complement the commercial offerings of Tarides and contribute to Tarides' mission: empowering developers, communities and organisations to adopt OCaml as their primary programming experience by providing training, expertise and development services around the OCaml language._ Read the full announcement [here], including details of our goals and the focus for 2022. This alliance brings the headcount of Tarides up to 60+ people, all working towards making OCaml the best language for any, and every project. Join our team and reach out for commercial services at: [https://tarides.com/] [here] <https://tarides.com/blog> [https://tarides.com/] <https://tarides.com/company> For Diversity and the OCaml Community: Get Involved in Outreachy Summer 2022 ════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/for-diversity-and-the-ocaml-community-get-involved-in-outreachy-summer-2022/9234/1> Sonja Heinze announced ────────────────────── As @patricoferris [has mentioned] previously, the Outreachy call for open-source communities and project submissions has started. As a reminder, [Outreachy] is an initiative that provides a framework through which open-source communities can offer three month internships directed at people from any kind of under-represented background in open source. With that, Outreachy helps open-source communities grow on several levels: diversity, experience, size, and popularity. The OCaml community participated in Outreachy in summer 2019, summer 2020, [summer 2021], and currently in [winter 2021/22]. All our interns have done and are doing really amazing jobs, and summer 2022 is just around the corner! The following timeline illustrates the process: <https://i.imgur.com/DbzeiMO.png> So let's start getting involved! [has mentioned] <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213/15?u=pitag> [Outreachy] <https://www.outreachy.org> [summer 2021] <https://discuss.ocaml.org/t/outreachy-summer-2021/8438> [winter 2021/22] <https://discuss.ocaml.org/t/announcing-our-new-outreachy-interns/8932> Ways to Get Involved ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Community members can take on different roles in the Outreachy effort, and all of them are very important! Maybe the most important (and most involved) role is being a mentor. Mentoring ┄┄┄┄┄┄┄┄┄ Mentors have two responsibilities: leading the project and guiding the interns/applicants. Leading the Project ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ One responsability is leading the project. Concretely, that means outlining an internship project, submitting a project description to Outreachy, making sure that the context repo for that project gets ready for the application/"contribution" phase, and guiding the project throughout the internship, including reacting to changes. All of that must match the Outreachy framework, which we [explained in detail] last round, based on the timeline structure shown above. [explained in detail] <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213#step-by-step-process-for-being-a-mentor-11> Guiding the Intern and the Applicants ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ Their other responsibility is personal guidance. During the application/"contribution" period, mentors answer questions and review code for multiple applicants. During the internship, they also offer pair-programming sessions and facilitate more specific guidance, and general support for their interns. All of that is usually quite time-intensive, so it's important to have some support from other community members and strong support from a concrete co-mentor. Co-mentoring ┄┄┄┄┄┄┄┄┄┄┄┄ A co-mentor does the same job as described in the "Guiding the Intern and the Applicants" tasks above, so having a co-mentor is very important! Of course, if a co-mentor also wants to take part in the project's direction, that's great as well! This means that the line between co-mentoring and mentoring isn't always clear. Volunteering (aka "Acting as a Joker :bat:") ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Mentors and co-mentors receive a lot of general questions related to OCaml and programming in addition to specific questions about the project. That's where Outreachy volunteers can be very helpful! They help all applicants and interns across projects with (usually) project-unspecific questions and give a very important technical base support. Point Out Potential Project Ideas ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Apart from not having enough time, the main reason that stops folks from becoming a mentor is the lack of project ideas. So if you have potential project ideas, please point them out, even if you don't have time to mentor! Generally, a self-contained, uncontroversial, and incremental project makes the most suitable project for Outreachy. It's also important for a project to be associated with a repo that can serve as a basis for easy contributions during the application phase. When in doubt, don't keep your ideas to yourself. Any idea can be helpful! Prepare Your Repos ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ In general, if you maintain a repo, it's really nice to be welcoming to new contributors. Concretely, that means having clear contributing guidelines, good newcomer issues, and well-labeled issues. As a nice side-effect, this also makes your project a better target for future Outreachy projects. Ready to Get Involved? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ If you've gotten interested in any of those roles or have any other comments, please just answer here in the thread. It would be super nice to get a discussion going and start our Outreachy efforts early! Sudha Parimala then said ──────────────────────── I along with @shakthimaan @gs0510 are submitting a project: • Extend OCaml 5's parallel benchmark suite. The idea is to gather parallel benchmarks available elsewhere and make them available in our benchmark suite, to aid the development of the OCaml compiler and parallel programming libraries. Relevant repos: [sandmark] and [current-bench]. [sandmark] <https://github.com/ocaml-bench/sandmark> [current-bench] <https://github.com/ocurrent/current-bench> Set up OCaml 2.0.0-beta13 ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta13/9248/1> Sora Morimoto announced ─────────────────────── Changed ╌╌╌╌╌╌╌ • Do not install opam-depext if it's not enabled. Fixed ╌╌╌╌╌ • Print a proper error if the version not found in the `.ocamlformat' file. <https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta13> First release of scfg ═════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-scfg/9249/1> zapashcanon announced ───────────────────── I'm pleased to announce the first release of [scfg] on opam. It provides a library and an executable to work with the [scfg configuration file format]. (disclaimer: scfg has been created by my good friend @emersion) Here's an example of an scfg file taken from the specification: ┌──── │ train "Shinkansen" { │ model "E5" { │ max-speed 320km/h │ weight 453.5t │ │ lines-served "Tōhoku" "Hokkaido" │ } │ │ model "E7" { │ max-speed 275km/h │ weight 540t │ │ lines-served "Hokuriku" "Jōetsu" │ } │ } └──── Scfg is a file format designed to be simple and indeed the implementation was really straightforward. I'm planning to use it in small tools I wrote (mostly [sway] tools written in OCaml) but never released because I couldn't stand having to use TOML, YAML or JSON for them… The library provides an executable to validate and pretty-print an scfg file. It'll indent it properly, remove useless quoting and whitespaces: ┌──── │ $ scfg spec.scfg │ train Shinkansen { │ model E5 { │ max-speed 320km/h │ weight 453.5t │ lines-served Tōhoku Hokkaido │ } │ model E7 { │ max-speed 275km/h │ weight 540t │ lines-served Hokuriku Jōetsu │ } │ } └──── The library is made of four modules : `Types', `Parse', `Pp' and `Query'. The `Types' module simply defines the following types, which are all you need to deal with scfg: ┌──── │ (** A directive has a name, a list of parameters and children (a list of directive). *) │ type directive = │ { name : string │ ; params : string list │ ; children : directive list │ } │ │ (** A config is a list of directives. *) │ type config = directive list └──── The others modules can be used as follow: ┌──── │ let file = {| │ train A-Train { │ bla bla bla │ } │ train "John Col Train" { │ tut tut tut │ } │ |} │ │ (* parsing the file *) │ let config = │ (* there's also a `Parse.from_file` function that should be more useful *) │ match Scfg.Parse.from_string file with │ | Error e -> │ Format.eprintf "error: %s@." e; │ exit 1 │ | Ok config -> config │ │ (* printing the file *) │ let () = │ Format.printf "```scfg@.%a@.```@." Scfg.Pp.config config │ │ (* querying the file *) │ let () = │ (* gets the first directive with the name `train` *) │ match Scfg.Query.get_dir "train" config with │ | None -> Format.printf "No train found.@." │ | Some train -> ( │ (* get the parameter at index 0 in the `train` directive *) │ match Scfg.Query.get_param 0 train with │ | Error _e -> Format.printf "Train has no name.@." │ | Ok name -> Format.printf "The first train is `%s`.@." name ) └──── For more have a look at the [project's README], the [documentation] or feel free to ask here ! :partying_face: [scfg] <https://git.zapashcanon.fr/zapashcanon/scfg> [scfg configuration file format] <https://git.sr.ht/~emersion/scfg> [sway] <https://swaywm.org/> [project's README] <https://git.zapashcanon.fr/zapashcanon/scfg/src/branch/master#scfg> [documentation] <https://doc.zapashcanon.fr/scfg/> Brr 0.0.3, a toolkit for programming browsers ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-brr-0-0-3-a-toolkit-for-programming-browsers/9252/1> Daniel Bünzli announced ─────────────────────── It's my pleasure to announce the release `0.0.3' of [`Brr'], a toolkit for programming browsers in OCaml with the [`js_of_ocaml'] compiler. Once it has made it to the repo, install with `opam install brr' and consult the [API docs and manuals] (or via `odig doc brr'). Among small additions and fixes, this release brings support for `js_of_ocaml' 4.0.0. Thanks to Hugo Heuzard (@hhugo) who has made the ground work in `js_of_ocaml' this means that: 1. `Brr', `js_of_ocaml' and ([soon]) `gen_js_api' JavaScript bindings can now all be used in the same program without problems (issue [#2]). 2. You no longer need to specify the `-no-check-prim' flag at bytecode link time. Linking against the `brr' library is sufficient, see the [build instructions]. The [release notes] have all the details. [`Brr'] <https://erratique.ch/software/brr> [`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml> [API docs and manuals] <https://erratique.ch/software/brr/doc/> [soon] <https://github.com/LexiFi/gen_js_api/pull/164> [#2] <https://github.com/dbuenzli/brr/issues/2> [build instructions] <https://erratique.ch/software/brr/doc/web_page_howto.html> [release notes] <https://github.com/dbuenzli/brr/blob/master/CHANGES.md#v003-2022-01-30-la-forclaz-vs> (anonymous?) polymorphic records ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/anonymous-polymorphic-records/9256/1> nrolland asked ────────────── Is there a way to avoid to create records only to preserve polymorphism ? Say, for this, in haskell style ┌──── │ h :: (forall r. (r -> a) -> (f r -> f b)) -> f a -> f b │ h malg = malg id └──── octachron replied ───────────────── You can use objects, they can have polymorphic methods: ┌──── │ let f (id:<f:'a. 'a -> 'a>) = id#f 0, id#f "zero" └──── Maëlan also replied ─────────────────── The following doesn’t help reducing the syntactic noise, but note that when using a record for non-prenex polymorphism like this, your record has only one field and is immutable, so (with a recent enough OCaml) you can unbox it and get rid of the runtime overhead: ┌──── │ type ('a, 'b) fwrap = { f : 'r. ('r -> 'a) -> 'r list -> 'b list } [@@unboxed] │ │ let apply_id : type a b. (a, b) fwrap -> a list -> b list = │ fun w xs -> w.f Fun.id xs │ (* is compiled the same as just: *) │ let apply_id_magic : type a b. (a, b) fwrap -> a list -> b list = │ fun w xs -> (Obj.magic w) Fun.id xs │ │ let mwrap : type a. (a, a) fwrap = { f = List.map } │ (* is compiled to nothing at all (alias of List.map). *) └──── 2 postdoc positions on Runtime Verification at CEA LIST, Université Paris-Saclay, France ════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-02/msg00001.html> Julien Signoles announced ───────────────────────── The Software Safety and Security Lab at CEA LIST, Université Paris-Saclay, France has 2 open postdoc positions in the area of runtime verification for code safety and security: • Designing Compilation Techniques for Improving Efficiency of E-ACSL, a Runtime Assertion Checker for C Programs <http://julien-signoles.fr/positions/postdoc-eacsl.pdf> • Control Flow Integrity for Remote Attestation <http://julien-signoles.fr/positions/postdoc-cfi.pdf> The candidates will: • solve challenging research problems; • implement their results in Frama-C, an industrial-strength open-source framework for analyses of C code; • evaluate their solutions on concrete benchmarks or/and use cases; • publish their results in international conferences and journals. Strong knowledge in at least one of the following areas is welcome: • programming • OCaml and C • formal semantics • formal verification • runtime verification, static analysis, formal specification languages, … • compilation • code generation, program transformation, type system, … Interested applicants should send a CV and a motivation letter to Julien Signoles (julien dot signoles at cea dot fr). 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 38539 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4624 bytes --] Hello Here is the latest OCaml Weekly News, for the week of February 01 to 08, 2022. Table of Contents ───────────────── Functori is hiring full-time engineers and Interns Permanent position for Computer Scientist in cybersecurity verification at CEA List, France pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications Old CWN Functori is hiring full-time engineers and Interns ══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/functori-is-hiring-full-time-engineers-interns/9266/1> Mohamed Iguernlala announced ──────────────────────────── Functori, a young and dynamic company based in Paris, is hiring talented engineers/PhDs to expand its team. Please find more details in the announcement (in French): <https://functori.com/annonce-recrutement.pdf> We are also looking for interns in the fields of programming languages, formal methods, and blockchains (details available on request). Feel free to share with anyone who may be interested. Permanent position for Computer Scientist in cybersecurity verification at CEA List, France ═══════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-02/msg00004.html> ANTIGNAC Thibaud announced ────────────────────────── We would like to share with you an exciting opportunity to join the Frama-C team at CEA List (a French public research institute). We are opening a permanent computer scientist position to work on formal verification of cybersecurity properties. More details about the position and the qualifications expected are available here: <https://frama-c.com/jobs/2022-02-01-permanent-computer-scientist-cyber-security-verification.html> Please do not hesitate to reach out or to share with potentially interested people! pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications ════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786/5> Ryan Moore announced ──────────────────── New version ╌╌╌╌╌╌╌╌╌╌╌ I wanted to announce a new version of `pyml_bindgen' has been merged into the opam repository, version 0.2.0. Whenever it hits, feel free to try it out! The main addition is now you can embed Python files directly into the generated OCaml module and it will be evaluated at run time. In this way, you don't need your users to mess with the `PYTHONPATH' environment variable or need them to install a particular Python module when using the generated OCaml code. (Another thanks to UnixJunkie and Thierry Martinez for their help with this!) There were also a few bugfixes and some nice new [examples] added to the GitHub repository. One cool thing about the examples is that they show you how to set up your project to use Dune rules to automatically generate Python bindings whenever the value specification files change! [examples] <https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 14229 bytes --]
[-- Attachment #1: Type: text/plain, Size: 21864 bytes --] Hello Here is the latest OCaml Weekly News, for the week of February 15 to 22, 2022. Table of Contents ───────────────── OCAML goes Quantum computing Layout Parsing and Nicely Formatted Error Messages ptime 1.0.0 and mtime 1.4.0 Timedesc 0.6.0 OCaml from the Very Beginning now free in PDF and HTML formats Dune 3.0.0 Blog Post "2021 at OCamlPro" Packstream 0.1 OCaml 4.14.0, first beta release Old CWN OCAML goes Quantum computing ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-goes-quantum-computing/9333/1> Florian said ──────────── It seems that silently OCAML is now entering the Quantum world. It looks that the Interpreter for "Twist" [New programming language for Quantum computing] is made with OCAML: [GitHub for Twist] [New programming language for Quantum computing] <https://scitechdaily.com/twist-mits-new-programming-language-for-quantum-computing/> [GitHub for Twist] <https://github.com/psg-mit/twist-popl22> Anton Kochkov then added ──────────────────────── Haskell has a nice package for quantum computing - Quipper. I recommend to take a look to it for inspiration as well: • <https://hackage.haskell.org/package/quipper-language> • <http://www.mathstat.dal.ca/~selinger/quipper/> • <https://arxiv.org/pdf/1304.3390.pdf> • <https://arxiv.org/pdf/2105.03522.pdf> (a new language that reuses linear types in the Haskell to represent quantum specifics during the Quipper type check) Layout Parsing and Nicely Formatted Error Messages ══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-layout-parsing-and-nicely-formatted-error-messages/9343/1> Hbr announced ───────────── In a previous [post] I have described my way from LALR parsing to combinator parsing. Now I am more and more convinced that combinator parsing is really a good and flexible way to write parsers. The new release 0.5.0 of `Fmlib` focuses on layout parsing and nicely formatted error messages by using combinator parsing. The library can be installed via opam by `opam install fmlib'. There is a [github repository] hosting the source code. The [API] can be found online. See also a [tutorial] on combinator parsing. [post] <https://discuss.ocaml.org/t/my-way-from-lalr-parsing-to-combinator-parsing/7377> [github repository] <https://github.com/hbr/fmlib> [API] <https://hbr.github.io/fmlib/odoc/index.html> [tutorial] <https://hbr.github.io/fmlib/odoc/fmlib_parse/parse.html> Layout Parsing ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Most programming languages express hierarchical structures by some kind of parentheses. Algol like languages use `begin' `end', C like languages use curly braces `{', `}' to enclose blocks of code. Since blocks can be nested inside blocks, the hierarchical or tree structure is well expressed by the syntax. For the human reader blocks are usually indented to make the hierarchical structure graphically visible. Programming languages like *Haskell* and *Python* ommit the parentheses and express the hierarchical structure by indentation. I.e. the indentation is part of the grammar. This is pleasing to the eye, because many parentheses can be ommitted. The hierarchical structure in the following schematical source file is immediately visible without the need of parentheses. ┌──── │ xxxxxxxxxxx │ xxx │ xxx │ xxxxxxx │ xxxxxxxx │ xxx └──── Lower level blocks are indented with respect to their parent block and siblings at the same level are vertically aligned. Because of this good readability configuration languages like yaml have become very popular. Unfortunately there are not many parsers available which support indentation sensitivity. The library [Fmlib] has support to parse languages whose grammar uses indentation to structure blocks hierarchically. There are only 3 combinators needed to introduce layout parsing in combinator parsing. Suppose that `p' is a combinator parsing a certain contruct. Then we have • `indent 4 p': Parse the construct described by `p' indented at least 4 columns relative to its environment • `align p': Parse the construct desribed by `p' aligned vertically with its siblings • `detach p': Parse the construct described by `p' without any indentation or alignment restrictions In order to parse a list of ~p~s vertically aligned and indented relative to its environment by at least one column we just write ┌──── │ one_or_more (align p) |> indent 1 └──── and parse a structure with the schematic layout ┌──── │ xxxxxxxx │ │ pppppppp │ │ pppppp │ │ pppp │ │ xxxxx └──── [Fmlib] <https://hbr.github.io/fmlib/odoc/fmlib_parse/Fmlib_parse/index.html> User Frienly Error Messages ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ It is important to for a parser writer to make syntax error messages user friendly. [Fmlib] has some support to write friendly error messages. There is the operator `<?>' copied from the Haskell library `parsec' which helps to equip combinators with descriptive error message in case they fail to parse the construct successfully. At the end of a failed parsing, the syntax (or semantic) errors have to be presented to the user. Suppose there is a combinator parser for a yaml like structure. The library writes by default for you error messages in the form ┌──── │ 1 | │ 2 | names: │ 3 | - Alice │ 3 | - Bob │ 4 | │ 5 | category: encryption │ ^ │ │ I have encountered something unexpected. I was │ expecting one of │ │ - at 3 columns after │ │ - sequence element: "- <yaml value>" │ │ - at 2 columns before │ │ - key value pair: "<key>: <yaml value>" │ │ - end of input └──── The raw information (line and column numbers, individual expectations, failed indentation or alignment expectation) is available as well so that you can present the error messages to the user in any different form. There is also a component [Fmlib_pretty] in the library for pretty printing any ascii text. [Fmlib] <https://hbr.github.io/fmlib/odoc/fmlib_pretty/Fmlib_pretty/index.html> [Fmlib_pretty] <https://hbr.github.io/fmlib/odoc/fmlib_pretty/Fmlib_pretty/index.html> ptime 1.0.0 and mtime 1.4.0 ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ptime-1-0-0-and-mtime-1-4-0/9344/1> Daniel Bünzli announced ─────────────────────── It's my pleasure to announce new releases of ptime and mtime. Ptime and mtime provide types and clocks for POSIX and monotonic time. These releases change the JavaScript support strategy for clocks by implementing the primitives in pure JavaScript and linking them via `js_of_ocaml'. This means that both the `ptime.clock.jsoo' and `mtime.clock.jsoo' libraries no longer exist[^1]. Instead simply use the `ptime.clock.os' or `mtime.clock.os' libraries like you would do for your regular programs. By side effect, the packages also no longer depend on any of `js_of_ocaml''s packages. Thanks to Hugo Heuzard (@hhugo) for suggesting and implementing these changes. Thanks also to Jonah Beckford for his Windows build patches. Other changes are described in the release notes for [`ptime'] and [`mtime']. Home pages: [ptime], [mtime] Docs & manuals: [ptime], [mtime] or `odig doc ptime mtime' Install: `opam install ptime mtime' [^1]: I had intended to only deprecate these libraries by `warning' in the `META' files and requiring the replacement library but it seems the warning won't show up in many contexts including `dune' builds. So a breaking change it is. [`ptime'] <https://github.com/dbuenzli/ptime/blob/master/CHANGES.md#v100-2022-02-16-la-forclaz> [`mtime'] <https://github.com/dbuenzli/mtime/blob/master/CHANGES.md#v140-2022-02-17-la-forclaz-vs> [ptime] <https://erratique.ch/software/ptime> [mtime] <https://erratique.ch/software/mtime> [ptime] <https://erratique.ch/software/ptime/doc> [mtime] <https://erratique.ch/software/mtime/doc> Timedesc 0.6.0 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-timedesc-0-6-0/9349/1> Darren announced ──────────────── I am pleased to announce the release of [Timedesc] 0.6.0. Timedesc is a very comprehensive date time handling library with good support of time zone. [Timedesc] <https://github.com/daypack-dev/timere> Features: ╌╌╌╌╌╌╌╌╌ • Timestamp and date time handling with platform independent time zone support • Subset of the IANA time zone database is built into this library • Supports Gregorian calendar date, ISO week date, and ISO ordinal date • Supports nanosecond precision • ISO8601 parsing and RFC3339 printing Changes ╌╌╌╌╌╌╌ This release adds a fair number of quality of life improvements and additional features. Many thanks to @glennsl for the suggestions and feedback! The most important sections of the changelog are as follows: • Main breaking changes: • Changes in ISO week date functions (shorting label for arguments, quality of life changes) • Removed `_date' suffix in names of `Date.Ymd_date' and `Date.ISO_ord_date' • Added "partial date" modules with ISO8601 parsing and printing facilities • `ISO_week' • `Ym' • Added additional ISO8601 printing facilities for all three calendar systems • `Date.Ymd.pp/to_iso8601' (these are just aliases to the RFC3339 printers) • `Date.ISO_week_date.pp/to_iso8601' • `Date.ISO_ord.pp/to_iso8601' • Added additional ISO8601 parsing facilities for all three calendar systems • `Date.Ymd.of_iso8601[_exn]' • `Date.ISO_week_date.of_iso8601[_exn]' • `Date.ISO_ord.of_iso8601[_exn]' • Added additional comparison functions to `Date' • `lt', `le', `gt', `ge', `compare' • Added arithemtic functions to `Date' • Added `pp/to_iso8601' functions as aliases to the rfc3339 functions to `Timedesc' • Patched ISO8601 parsers and RFC3339/ISO8601 printers to handle second level time zone offset • Rare occurrence in tzdb but picked up by some new tests OCaml from the Very Beginning now free in PDF and HTML formats ══════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-from-the-very-beginning-now-free-in-pdf-and-html-formats/9361/1> John Whitington announced ───────────────────────── Thanks to a grant from the [OCaml Software Foundation], I am able to release my book [OCaml from the Very Beginning] at no cost in its existing PDF format, and in a new HTML format too. You can find it here: [https://johnwhitington.net/ocamlfromtheverybeginning/]. The paperback and Kindle versions continue to be available from Amazon as before. The book has recently been updated to make it ready for OCaml 4.14 which involved only minor changes to error handling and warnings. I have also opened the [source]. [OCaml Software Foundation] <https://ocaml-sf.org/> [OCaml from the Very Beginning] <https://ocaml-book.com> [https://johnwhitington.net/ocamlfromtheverybeginning/] <https://johnwhitington.net/ocamlfromtheverybeginning/> [source] <https://github.com/johnwhitington/mlbook> Dune 3.0.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-0-0/9374/1> Rudi Grinberg announced ─────────────────────── On behalf of the dune team, I’m delighted to announce the availability of dune 3.0. The team has been working on this release for over 6 months, and there’s a bunch of new work to report. I’ll only highlight the some of the interesting new developments: • The watch mode has been rewritten from scratch to be faster and more scalable. We also no longer rely on any 3rd party tools such as fswatch. If any of you still have a dune workspace dune is still struggling with, we cannot wait to hear from you. • The watch mode now also starts an RPC server in the background. This RPC protocol is going to be the basis for other tools to interact with dune. Watch out for announcement on the LSP side to see how we’ll be making use of it to improve the editing experience. • The dune cache has been rewritten as well. It is now simpler and more reliable. There are still some components missing, such as distribution of the artifacts on the network. Nevertheless, we welcome you all to experiment with this feature and give us feedback. • We’ve addressed one of our oldest feature requests: high level rules for ctypes projects. This feature is still experimental, so we need feedback from real world projects before declaring it as mature. Of course, there are many other fixes, enhancements, and only a few breaking changes in this release. We hope you have an easy time upgrading. Happy Hacking. /Editor’s note: for the full changelog, please follow the archive link above./ Blog Post "2021 at OCamlPro" ════════════════════════════ Archive: <https://discuss.ocaml.org/t/blog-post-2021-at-ocamlpro/9390/1> Fabrice Le Fessant announced ──────────────────────────── We just published a review of what OCamlPro did in 2021: <https://www.ocamlpro.com/blog/2022_01_31_2021_at_ocamlpro> A lot of OCaml, but also some Rust, Cobol, Solidity, and a lot of Formal Verification! OCamlPro is always looking for skilled OCaml developers to hire, so if you are interested, contact us at contact@ocamlpro.com Packstream 0.1 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-packstream-0-1/9392/1> Tomasz Barański announced ───────────────────────── I have a pleasure to announce the release of [Packstream] 0.1. Packstream is a library to parse/serialize [Packstream binary format]. This is the initial release. It is functional but very very limited in scope. It allows parsing a binary stream into a Packstream datatype and serializing the datatype into a binary stream. [Packstream] <https://github.com/tomob/packstream> [Packstream binary format] <https://7687.org/packstream/packstream-specification-1.html> OCaml 4.14.0, first beta release ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-14-0-first-beta-release/9396/1> octachron announced ─────────────────── The release of OCaml 4.14.0 is close. The set of new features has been stabilized, and most opam packages already work with this release. After two alpha releases, we have created a first beta version to help you update your softwares and libraries ahead of the release. If you find any bugs, please report them at: <https://github.com/ocaml/ocaml/issues> The full release of OCaml 4.14.0 is currently expected for the middle of March. Compared to the last alpha, we have a last minute correction for one of the new function in the Seq module, some documentation improvements, few configuration and internal tweaks. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.14.0~beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── With opam 2.1, the previous command line can be simplified to ┌──── │ opam update │ opam switch create 4.14.0~beta1 └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.14.0~beta1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── or with opam 2.1: ┌──── │ opam update │ opam switch create <switch_name> ocaml-variants.4.14.0~beta1+options <option_list> └──── where `<option_list>' is a comma separated list of `ocaml-option-*' packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.14.0~beta1+flambda+nffa ocaml-variants.4.14.0~beta1+options ocaml-option-flambda │ ocaml-option-no-flat-float-array └──── All available options can be listed with `opam search ocaml-option'. The source code for the beta is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.14.0-beta1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.0~beta1.tar.gz> Changes compared to the last alpha ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The full list of changes for OCaml 4.14 is available at <https://github.com/ocaml/ocaml/blob/4.14/Changes> Standard library ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • *additional fixes* [10583], +[10998]: Add over 40 new functions in Seq. (François Pottier and Simon Cruanes, review by Nicolás Ojeda Bär, Daniel Bünzli, Naëla Courant, Craig Ferguson, Wiktor Kuchta, Xavier Leroy, Guillaume Munch-Maccagnoni, Raphaël Proust, Gabriel Scherer and Thierry Martinez) [10583] <https://github.com/ocaml/ocaml/issues/10583> [10998] <https://github.com/ocaml/ocaml/issues/10998> Documentation ┄┄┄┄┄┄┄┄┄┄┄┄┄ • [10397]: Document exceptions raised by Unix module functions on Windows (Martin Jambon, review by Daniel Bünzli, David Alsopp, Damien Doligez, Xavier Leroy, and Florian Angeletti) • [10794]: Clarify warning 57 (Ambiguous or-pattern variables under guard) (Wiktor Kuchta, review by Gabriel Scherer) [10397] <https://github.com/ocaml/ocaml/issues/10397> [10794] <https://github.com/ocaml/ocaml/issues/10794> Build system ┄┄┄┄┄┄┄┄┄┄┄┄ • [10828] Build native-code compilers on OpenBSD/aarch64 (Christopher Zimmermann) • [10835] Disable DT_TEXTREL warnings on x86 32 bit architecture by passing -Wl,-z,notext in mksharedlib and mkmaindll. Fixes relocation issues, reported in [9800], making local patches in Debian, Alpine, and FreeBSD superfluous. (Hannes Mehnert with Kate Deplaix and Stéphane Glondu, review by Xavier Leroy) [10828] <https://github.com/ocaml/ocaml/issues/10828> [10835] <https://github.com/ocaml/ocaml/issues/10835> [9800] <https://github.com/ocaml/ocaml/issues/9800> Code generation ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [10719]: Ensure that build_apply respects Lambda.max_arity (Stephen Dolan, review by Xavier Leroy) [10719] <https://github.com/ocaml/ocaml/issues/10719> Internal/compiler-libs ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • *additional fixes* [10718], +[11012]: Add "Shape" information to the cmt files. Shapes are an abstraction of modules that can be used by external tooling to perform definition-aware operations. (Ulysse Gérard, Thomas Refis and Leo White, review by Florian Angeletti) [10718] <https://github.com/ocaml/ocaml/issues/10718> [11012] <https://github.com/ocaml/ocaml/issues/11012> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 35952 bytes --]
[-- Attachment #1: Type: text/plain, Size: 25341 bytes --] Hello Here is the latest OCaml Weekly News, for the week of February 22 to March 01, 2022. Table of Contents ───────────────── data-encoding.0.5 release Tutorial: Roguelike with effect handlers For Diversity and the OCaml Community: Outreachy Summer 2022 Bogue, the OCaml GUI Friday 03/04 Intern presentations – open attendance! Affect: Composable concurrency primitives for OCaml 5.0 Segfault Systems Joins Tarides OCaml User Survey 2022 Old CWN data-encoding.0.5 release ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-data-encoding-0-5-release/9420/1> Raphaël Proust announced ──────────────────────── On behalf of [Nomadic Labs], I'm happy to announce the release of data-encoding version 0.5. This new version brings several bug fixes, some increased test coverage, minor improvements in the API, and a major new feature: [Nomadic Labs] <https://www.nomadic-labs.com/> Compact encodings: sub-byte tag sizes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This new version provides a new set of combinators for _compact_ encodings. These compact encodings will handle all the verbose and error-prone bit-twidling process needed to combine multiple sub-byte discriminators into a single byte-size one. E.g., the encoding `let e1 = either (either bool unit) (option bool)' uses three bits in the shared tag and zero bytes after that; the encoding `let e2 = either int32 int64' uses one bit in the shared tag and either 4 or 8 bytes to represent the integer; the product encoding `let ee = tup2 e1 e2' uses four (3 + 1) bits in the shared tag and either 4 or 8 bytes to represent the integer of `e2'. How to get ╌╌╌╌╌╌╌╌╌╌ The code is available under MIT license on <https://gitlab.com/nomadic-labs/data-encoding>. It can be installed via `opam'. Dario Teixeira asked and Raphaël Proust replied ─────────────────────────────────────────────── Hi @raphael-proust! I have a question regarding the connection between `data-encoding' and `json-data-encoding', also developed at Nomadic Labs. The latter seems tied to JSON, whereas the former is more flexible, supporting also binary encodings. However, since `data-encoding' also supports JSON, doesn't it subsume `json-data-encoding' completely? The `data-encoding' library uses `json-data-encoding' for its JSON backend. It delegates conversion from OCaml values into and from JSON to the primitives provided in the interface of `json-data-encoding'. In a way, yes, as an end-user you don't need to use `json-data-encoding' directly because you can use the `Json' module of `data-encoding' instead. There are three possible reasons why you might add `json-data-encoding' as a (non-transitive) dependency to your project and use it directly in your code: • You want to keep the dependency set and the number of abstraction layers as small as possible. E.g., in order to reduce binary size. • You want some static guarantees that some encodings are only every used for JSON. E.g., in your logging system. • You need to define a JSON encoding which is rejected by `data-encoding' on grounds that it is invalid in binary. Note that • This is very specific to some combinators but basically some combinators will reject their inputs (raise `Invalid_argument') because using the serialiser would lead to undecodable data. Most typically, this happens if you try to concatenate two fields of unknown length. Decoding the result becomes a guessing game as to were one field stops and where the next begins. These could easily be represented as an array in JSON which includes all the delimiters you need to decode it. • There are other workarounds (e.g., prefixing the fields with a length field), but going for the JSON encoding directly is a valid approach if you only need JSON. Raphaël Proust later announced ────────────────────────────── Version 0.5.1 of the data-encoding has just been released. This is a bugfix release making one of the library's internal checks more permissive. Without this fix (i.e., using version 0.5), some valid encodings are rejected (raising `Invalid_argument') by the library. You can update via opam: `opam install data-encoding.0.5.1' Tutorial: Roguelike with effect handlers ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/tutorial-roguelike-with-effect-handlers/9422/1> art-w announced ─────────────── The recent conversations about [`eio' 0.1] and [agnostic blocking] have made me very curious about effect handlers. The multicore team has done an [awesome] job with their [tutorials], [examples] and [talks], but the laymen have been too quiet for such an exciting feature! Where are all the blog posts about how "you could have invented algebraic effects" and "one-shot continuations are like spaghetti"? In any case, I'm hoping to tease some of you into trying them out with [a simple tutorial about programming a roguelike with effect handlers] :) There's nothing new here besides the fun use-case! So if you already have an intuitive understanding of the syntax and motivations, you may be more interested by [a deeper look at the scope of effect handlers] – and a soft introduction to some less common features of the type system. /(this link was previously posted deep into the `eio' thread)/ I would be grateful if you spot any mistake! I'm also curious of other fun applications for effect handlers… and if you feel like sharing your own surprises and discoveries, I believe it could really help others learn faster :) [`eio' 0.1] <https://discuss.ocaml.org/t/eio-0-1-effects-based-direct-style-io-for-ocaml-5/9298/97> [agnostic blocking] <https://discuss.ocaml.org/t/how-to-block-in-an-agnostic-way/9368/51> [awesome] <https://github.com/patricoferris/awesome-multicore-ocaml> [tutorials] <https://github.com/ocamllabs/ocaml-effects-tutorial> [examples] <https://github.com/ocaml-multicore/effects-examples> [talks] <https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89> [a simple tutorial about programming a roguelike with effect handlers] <https://hackmd.io/@yF_ntUhmRvKUt15g7m1uGw/BJBZ7TMeq> [a deeper look at the scope of effect handlers] <https://hackmd.io/@yF_ntUhmRvKUt15g7m1uGw/Bk-5NXh15> Kiran Gopinathan then said ────────────────────────── Great blog post! That seems like a very elegant implementation! Funny you should make a rougelike :smiley: , I guess effect handlers + games might be popular for games, because I also had a blog post about effect handlers and their applications, in particular for games, although in my case it was for animations: <https://gopiandcode.uk/logs/log-bye-bye-monads-algebraic-effects.html> gasche also replied ─────────────────── Note: the "upstream" status of effect handlers is a little uncertain/confusing right now. Your blog post (I didn't get a chance to read it yet, but it sounds very nice!) uses the experimental syntax of multicore-4.12+effects, but that syntax was intentionally /not/ upstreamed, and it will /not/ be part of OCaml 5.0. I think there is a risk of confusion because the community is aware that Multicore OCaml has effect handlers, and also that Multicore OCaml has been merged upstream. So it can be tempting to believe that the upcoming OCaml release (or maybe one or two releases after that, we said the first Multicore release would be more like a preview) will support effect handlers as a language feature. It will not! Effects as a language feature were removed from Multicore OCaml before the upstream merge. And /no one knows/ if/when they will be supported upstream. So: I think that your blog posts on using effect handlers could have somewhere a short mention that the code is using an experimental extension of OCaml that is not supported by the upstream implementation. The reasoning for this choice is that we want to give a chance to a type system for effect handlers, but that still need quite a bit more time than the Multicore runtime itself. We don't want to encourage the ecosystem to rely on untyped effects, if it means a lot of pain upgrading to typed effects later (or risk having to support both). 5.0 only contains basic support for effect handlers as a /runtime primitive/, but dos /not/ support handlers as a /language feature/. I think they should be considered experimental: you can rely on them for their intended purpose of exposing a flexible interface for concurrent fibers, but uses beyond that may break in the future. So, in a sense, we don't want people to use them. It's of course fine to use experimental features from experimental forks of the OCaml compiler (effect handlers, modular implicits or explicits, runtime type representations and what not), and the people working on these experimental features do benefit from other people trying them and giving them feedback. But we don't want people to depend on it /in production/, whatever that means. (For example, code using it is likely to get stuck on 4.12 forever and never see an upgrade to upcoming OCaml versions, although of course people could choose to port the experimental branch forward.) For Diversity and the OCaml Community: Outreachy Summer 2022 ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/for-diversity-and-the-ocaml-community-outreachy-summer-2022/9234/4> Sonja Heinze announced ────────────────────── Just in case anyone is actually interested in this: the project submission deadline has been extended from March 4th to March 23rd. So the updated timeline now looks as follows: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/5/534ca9a08bce10f13530e6c98eae1797fdf13e52.png> where 2. and 3. probably need to be done a bit in parallel. Bogue, the OCaml GUI ════════════════════ Archive: <https://discuss.ocaml.org/t/ann-bogue-the-ocaml-gui/9099/23> sanette announced ───────────────── Hi, some new developments. I have implemented a new `Sdl_area' widget where one can conveniently issue any SDL function (from the SDL Renderer API). Here is (below) the new 'labelled graph' example. In this example I am using regular "label" widgets for creating the nodes, and I am using an Sdl_area for drawing the lines. The nice things for labels to be regular widgets is that one can click on them. To demonstrate this, in this example they react to a click by jumping to another random location (with animation). <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/f/f9575838a7e5ea4c58485b955e96f7c9bbda384f_2_1266x1000.png> <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/d/d6958e266f27a557c5c8d8d37099d532eacf2c1c.gif> ┌──── │ open Bogue │ module W = Widget │ module L = Layout │ │ let n = 15 (* number of discs *) │ let radius = 20 │ let width = 800 │ let height = 600 │ │ let c = Draw.find_color "#e5b92c" │ let cb = Draw.find_color "#7b6b35" │ let disc_style = Style.( │ create ~border:( │ mk_border ~radius (mk_line ~color:Draw.(opaque c) ~width:1 ~style:Solid ())) │ ~background:(color_bg Draw.(opaque cb)) ()) │ │ let background = L.style_bg Style.( │ of_bg (gradient ~angle:45. Draw.[opaque grey; opaque black])) │ │ let fg = Draw.(opaque white) │ │ let create_disc i (x,y) = │ let w = 2*radius + 1 in │ let bg = Box.create ~style:disc_style ~width:w ~height:w () in │ W.label ~fg (string_of_int i) │ |> L.resident ~background:(L.box_bg bg) ~x:(x-radius) ~y:(y-radius) ~w ~h:w │ │ let move_disc (x,y) d = │ let (x0, y0) = L.xpos d, L.ypos d in │ L.animate_x d (Avar.fromto x0 x); │ L.animate_y d (Avar.fromto y0 y) │ │ let random_center _ = │ radius + Random.int (width - 2*radius), │ radius + Random.int (height - 2*radius) │ │ let area = │ let sdlw = W.sdl_area ~w:width ~h:height () in │ let sdla = W.get_sdl_area sdlw in │ let centers = Array.init n random_center in │ let color = Draw.(opaque grey) in │ let draw_lines renderer = let open Draw in │ for i = 0 to n - 2 do │ let x0, y0 = to_pixels centers.(i) in │ let x1, y1 = to_pixels centers.(i+1) in │ line renderer ~color ~thick:6 ~x0 ~y0 ~x1 ~y1 │ done in │ Sdl_area.add sdla draw_lines; │ let discs = Array.mapi create_disc centers |> Array.to_list in │ (* move the disc when click on it *) │ List.iteri (fun i d -> │ W.on_click ~click:(fun _ -> │ centers.(i) <- random_center 0; │ Sdl_area.update sdla; │ let x,y = centers.(i) in │ move_disc (x - radius, y - radius) d) (L.widget d)) │ discs; │ L.superpose ~w:width ~h:height ~background (L.resident sdlw :: discs) │ │ let board = Bogue.make [] [area] │ │ let () = Bogue.run board └──── Friday 03/04 Intern presentations – open attendance! ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/friday-03-04-intern-presentations-open-attendance/9429/1> Aya announced ───────────── This is Aya, one of the three [Outreachy] interns working on OCaml this winter :camel: After 3 very fast months, our internships are already coming to a close. We have had such a great time working on our projects and learning OCaml that we want to hold an event to mark the end of the internships, and we decided to open it up to the community :tada: As you might have seen in the [initial announcement], @pitag @shonfeder @gs0510 @tmattio and @pkel all volunteered to mentor us from December 2021 to now. Thank you all so so much for mentoring us and introducing us to OCaml :heart: :fire: It's been such an enjoyable experience! We are inviting anyone who is interested to attend a virtual session of 3 short presentations on *Friday, March 4th, 4-5pm CET* (we will post the link to join on Thursday). There will be time for Q&A after each presentation, and the whole session will be recorded and posted online shortly after as well. • @ayc9 will present on updating a standard PPX deriver (mentors: @pitag @shonfeder) • @SaySayo will present on syntax highlighting and other updates to the vscode extension (mentors: @tmattio @gs0510) • @JiaeK will present on building a basic monitoring dashboard for [ocaml.org] (mentors: @tmattio) We hope you can make it! -@ayc9 @SaySayo @JiaeK [Outreachy] <https://outreachy.org/> [initial announcement] <https://discuss.ocaml.org/t/announcing-our-new-outreachy-interns/8932> [ocaml.org] <http://ocaml.org/> Affect: Composable concurrency primitives for OCaml 5.0 ═══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/affect-composable-concurrency-primitives-for-ocaml-5-0/9430/1> Daniel Bünzli announced ─────────────────────── I looked a bit into the kind of fiber abstraction and concurrency structure I would like to use with the new tools OCaml 5.0 is going to offer. You can find some results in affect's [`Fiber'] module. This fiber abstraction supports terminating by returning values or abnormally (by aborting or via a spurious exception). Termination of a fiber is aligned on function scopes: all the fibers spawn by a fiber function have to terminate in order for it to terminate. This means that if your fiber returns a value it waits for its spawns to terminate (in any way) before returning the value. And if your fiber returns abnormally (uncaught eception or explicit abort) it first aborts all its non-terminated spawns before returning abnormally – this provides affect's notion of cancellation. Explicit fiber aborts raise the `Abort' exception in fibers. Combined with a disciplined use of `Fun.protect' and an optional `finally' handler specified at fiber spawn, this lets them release the ressources they may hold when it's time to say goodbye. The module also provides a generic way of blocking and unblocking fibers that you can use to interface with your favourite event loop. It does so without requiring to fiddle with effects, you just need to make judicious use of [`Fiber.block'] and provide a suitable function to `Fiber.run''s built-in scheduler to let it know about fibers that can be unblocked. A grab bag of comments: 1. The first goal of affect is to seek a concurrency and abort structure that are easy to understand, use and compose with event loops. Right now some efficiency and implementation aspects need to be improved. This will likely change the exposed set of primitive effects which doesn't feel exactly right yet (if you want to build your own scheduler). 2. I use abort rather than cancel terminology. From my non-native english speaker perspective, cancelling is more about not doing something that was planned but didn't happen yet. Aborting is more about stopping something that is going on. It also melds better with the uncaught exception case. 3. Say no to `unit' soups! Let fibers return values. 4. At that point I don't feel the need to add a promise/future abstraction to the toolbox. The whole point of direct style is to get rid of this async madness. 5. There's no synchronisation structure yet. Semaphores are always useful for throttling so I'll certainly add that at some point or a more fundamental primitive like an mvar. 6. The [`Funix'] module has a few fiber friendly `Unix' module functions for playing with timers and the network, see [`ping.ml'] for an example of use. In practice you want to be able to use something else than `select(2)' though. There are various ways one could go about this, see for example point 6. in these [design notes]. 7. The [`mouse.ml'] has a basic example on how to interface with the SDL event loop which provides another example on how one goes to interface `Fiber' with event loops. I'm not fully convinced by everything yet. It will certainly need one or two more design rounds. If you try it, feel free to comment or make suggestions on the issue tracker. Home page: <https://erratique.ch/software/affect> API docs: <https://erratique.ch/software/affect/doc/> (or `odig doc affect') Install: ┌──── │ opam switch create 5.0.0+trunk │ opam pin add https://erratique.ch/repos/affect.git └──── [`Fiber'] <https://erratique.ch/software/affect/doc/Fiber/index.html> [`Fiber.block'] <https://erratique.ch/software/affect/doc/Fiber/index.html#val-block> [`Funix'] <https://erratique.ch/software/affect/doc/Funix/index.html> [`ping.ml'] <https://github.com/dbuenzli/affect/blob/master/test/ping.ml> [design notes] <https://github.com/dbuenzli/affect/blob/master/DESIGN.md> [`mouse.ml'] <https://github.com/dbuenzli/affect/blob/master/test/mouse.ml> Segfault Systems Joins Tarides ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/segfault-systems-joins-tarides/9431/1> Thomas Gazagnaire announced ─────────────────────────── @kayceesrk and I are delighted to announce that Segfault Systems, a spinout from IIT-Madras, is joining Tarides. Tarides has worked closely with Segfault Systems over the last couple of years, most notably on the award-winning Multicore OCaml project and the upstreaming plans for OCaml 5.0. This alliance furthers the goals of Tarides, bringing the compiler and benchmarking expertise of the Segfault team directly into the Tarides organisation, where it can be commercially funded and supported. All of Segfault Systems’ existing responsibilities and open-source commitments will migrate over to Tarides, where work will continue towards the three main objectives in 2022: • Releasing OCaml 5.0 with support for domains and effect handlers • Supporting the ecosystem to migrate the OCaml community over to OCaml 5.0 • Improving developer productivity for OCaml 5.0 by releasing the best platform tools This alliance will complement the commercial offerings of Tarides – already strengthened by the integration of [OCaml Labs] – and contribute to Tarides’ mission: empowering developers, communities, and organisations to adopt OCaml as their primary programming experience by providing training, expertise, and development services around the OCaml language. Read the full announcement [here], including details of our goals and the focus for 2022. This alliance brings the headcount of Tarides up to 60+ people, all working towards making OCaml the best language for any and every project. Join our team and reach out for commercial services at [https://tarides.com/]. [OCaml Labs] <https://discuss.ocaml.org/t/ocaml-labs-joins-tarides/9229> [here] <https://tarides.com/blog/2022-03-01-segfault-systems-joins-tarides> [https://tarides.com/] <https://tarides.com/> OCaml User Survey 2022 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2022/9433/1> Kim Nguyễn announced ──────────────────── we are delighted to announce the [OCaml User Survey 2022]. With this survey, the OCSF is trying to get a better picture of the OCaml community and its needs. It would be very helpful if you could take a few minutes (10 to 15) to fill the survey and share it with other OCaml programmers. [https://forms.gle/oKy2Joz1cZhCPNtf6] The survey is run by the [OCaml Software Foundation]. It builds on [the previous iteration] issued in 2020. The results will be published here on discuss and on the [website of the OCSF]. We would like to particularly thank @cjr for his help as well as everyone who commented on the previous survey. We tried our best to take all remarks into account but surely missed something. Don't hesitate to give us your feedback (you can post here or send me a message/email). The survey will remain opened until March 11th 2022 (AOE). [OCaml User Survey 2022] <https://forms.gle/oKy2Joz1cZhCPNtf6> [https://forms.gle/oKy2Joz1cZhCPNtf6] <https://forms.gle/oKy2Joz1cZhCPNtf6> [OCaml Software Foundation] <https://ocaml-sf.org/> [the previous iteration] <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624> [website of the OCSF] <https://ocaml-sf.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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 44434 bytes --]
[-- Attachment #1: Type: text/plain, Size: 13917 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 08 to 15, 2022. Table of Contents ───────────────── Robur Reproducible Builds OCaml TeXmacs plugin Release of ocaml-sf/learn-ocaml:0.14.0 Tutorial: Roguelike with effect handlers Awesome Multicore OCaml and Multicore Monorepo ppx_viewpattern initial release Old CWN Robur Reproducible Builds ═════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-robur-reproducible-builds/8827/6> Continuing this thread, Hannes Mehnert announced ──────────────────────────────────────────────── The background article by @rand is now online <https://r7p5.earth/blog/2022-3-7/Builder-web%20visualizations%20at%20Robur> OCaml TeXmacs plugin ════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-03/msg00009.html> Nicolas Ratier announced ──────────────────────── I made a basic OCaml plugin for TeXmacs (<http://www.texmacs.org>) I would like to keep it simple, but comments and improvements are welcome. <http://forum.texmacs.cn/t/ocaml-a-basic-ocaml-plugin-for-texmacs/813> Release of ocaml-sf/learn-ocaml:0.14.0 ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-ocaml-sf-learn-ocaml-0-14-0/9491/1> Yurug announced ─────────────── We are very pleased to announce the latest stable release of [Learn-OCaml], version `0.14.0'. Many thanks to all users and developers who reported bugs, contributed features, or patches! Special thanks to @erikmd who made many of the changes included in this release. A (mostly) comprehensive list of the features, fixes, and enhancements offered by this release is available in [the Release Notes ]. A brief and incomplete summary of the changes: • A long-standing bug has been fixed. This bug was triggered when the user opened several sessions: the auto-sync mechanism could lead to overwriting the student's code with an older version. • The release assets now include a zip file containing the contents of the `www` directory. This eases the usage of the distributed binaries. If need be, feel free to open issues in the [Learn-OCaml bug tracker] or the [learn-ocaml.el bug tracker], or post in this thread to share thoughts or experience-feedback. Happy OCaml learning and teaching! [Learn-OCaml] <https://github.com/ocaml-sf/learn-ocaml> [the Release Notes ] <https://github.com/ocaml-sf/learn-ocaml/releases/tag/v0.14.0> [Learn-OCaml bug tracker] <https://github.com/ocaml-sf/learn-ocaml/issues> [learn-ocaml.el bug tracker] <https://github.com/pfitaxel/learn-ocaml.el/issues> Tutorial: Roguelike with effect handlers ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/tutorial-roguelike-with-effect-handlers/9422/18> Continuing this thread, stw said ──────────────────────────────── Sorry about the late reply, I was busy actually verifying that my concept works out. Thankfully it does :smile: The UI framework is inspired by [Concur] which means that every widget listens for some set of events and suspends computation until one of these events occurs. Once it does, it continues execution until it encounter the next await at which point it will suspend once more. Once a widget has fulfilled its purpose it terminates with some return value (e.g. text input is confirmed with enter -> return with a string). Complex UIs are then built by composing simpler widgets. A more detailed explanation can be found in the link above. I've implemented this concept using an await function that takes a list of triggers and a handler for each possible event: ┌──── │ effect Await : Event.t list -> Event.t │ let rec await triggers handler = │ handler (EffectHandlers.perform (Await triggers)) │ │ let rec check_box checked = │ (* display check box *) │ ...; │ await [Mouse_press; Key_press] (function │ | Mouse_press -> │ print_endline "I've been (un-)checked!"; │ check_box (not checked) │ | Key_press -> (* Terminate if any key is pressed *) checked) └──── Every widget can then be implemented as a function which displays the widget and performs an `Await triggers' which is resumed by passing an event from `triggers', for example the check box above. The most complex widget I've implemented so far is a single line text input. It can be clicked or selected with tab. Moving the mouse while holding the button down changes the selection. As an automaton: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/5/574e164b6189608283de32d9f375534ca80caffa.png> Obviously, this is not a directed acyclic graph and therefore not a perfect fit for the implicit state stored in the continuation. Specifically, `Pressed' has an edge to one of its multiple parents. We can extract the `Pressed' state into its own function and therefore avoid this issue by 'duplicating' this state. Now `Pressed' no longer has multiple parents: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/7/70a34d2f4bb81800a5e3b12b8e49147a0d80ece4.png> Some cycles remain and we can't remove them because they are essential to the functionality. Instead we throw an `exception Repeat' that returns us to a parent node (explicitly shown for Focused -> Pressed -> Released -> Focused). To do that we modify `await': ┌──── │ let rec await triggers handler = │ try handler (EffectHandlers.perform (Await triggers)) with │ | Repeat -> await triggers handler └──── In the end this results in this main method for the text input, with only minor simplifications: ┌──── │ method execute = │ (* Represent the Pressed state. │ We await the Mouse_release and handle Mouse_motion while we wait. *) │ let pressed (x,_) = │ selection <- Point x; │ await [`Mouse_release; `Mouse_motion] @@ function │ | `Mouse_release (_, LMB) -> │ () │ | `Mouse_motion (x,_) -> │ self#select x; │ raise Repeat (* This restarts the await function *) │ | _ -> │ raise Repeat │ in │ │ (* We start in the Unfocused state *) │ begin │ await [`Mouse_press; `Key_press] @@ function │ | `Mouse_press (pos, LMB) -> │ (* We have registered the press, but only when it is released │ will we be focused. *) │ pressed pos │ | `Key_press Tab -> │ selection <- Area (0, List.length keys) │ | _ -> raise Repeat │ end; │ │ (* We move into the Focused state *) │ begin │ await [`Codepoint; `Key_press; `Mouse_press] @@ function │ | `Key_press Tab | `Key_press Return -> │ () (* The only path without raising Repeat. │ Therefore we only leave this await when a tab or return occurs *) │ | `Mouse_press (pos, LMB) -> │ pressed pos; │ raise Repeat │ | `Key_press c -> │ self#insert c; │ raise Repeat │ | _ -> raise Repeat │ end; │ (* We have reached the finished state. We can now return the entered text. *) │ self#text └──── I think that this method captures the automaton above quite nicely and can be relatively easily understood (hopefully even when one is unfamiliar with the framework and accepts that some magic is happening in the background (: ). Implementing automatons in terms of effect handlers seems to work quite well, at least for games and UIs. What these automatons have in common is that they can be thought of as flows, starting at some state and ending at one of multiple final states and only have few edges that don't fit this scheme, turning them into 'directed almost acyclic graphs'. There is obviously a lot more necessary for a UI framework (e.g. resizing the window/widgets, delegating the events to the correct widget, composing widgets, drawing on the screen etc.) and I plan to write about it at some point in the future. But for that I will first need to actually solve these problems as right now their implementation is quite barebones. The code can be found here for those interested (still very early in development!): <https://github.com/Willenbrink/bogue/> [Concur] <https://ajnsit.github.io/concur-documentation/ch02-01-anatomy-of-a-widget.html> Awesome Multicore OCaml and Multicore Monorepo ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/awesome-multicore-ocaml-and-multicore-monorepo/9515/1> Patrick Ferris announced ──────────────────────── A short announcement of two repositories which some people may or may not have seen. Firstly, [Awesome Multicore OCaml], a place for gathering all of the rapidly changing experiments, ideas, libraries and resources for Multicore OCaml (including some of the discuss threads). If you are working on something or feel anything is missing please open a PR! Secondly, a [Multicore Monorepo] which aims to provide a very quick and easy way to try out effects and parallelism with quite a few libraries (such as Eio, Dream etc.). The breaking changes introduced by OCaml 5 can make it frustrating to get such a setup in place, although this is less and less true thanks to the [alpha repository]. The idea is that you should just be able to clone this repository, create a new `5.0.0+trunk' switch, install `dune' and start hacking. If that's not the case please do open an issue. [Awesome Multicore OCaml] <https://github.com/patricoferris/awesome-multicore-ocaml> [Multicore Monorepo] <https://github.com/patricoferris/ocaml-multicore-monorepo> [alpha repository] <https://github.com/kit-ty-kate/opam-alpha-repository> ppx_viewpattern initial release ═══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ppx-viewpattern-initial-release/9516/1> Simmo Saan announced ──────────────────── I'm glad to announce the initial release of [ppx_viewpattern] – transformation for view patterns in OCaml. It _attempts to_ imitate [Haskell view patterns]. I wrote this ppx rewriter mostly out of curiosity, rather than need, but it turned out neat enough that others might find it interesting or even useful. [ppx_viewpattern] <https://github.com/sim642/ppx_viewpattern> [Haskell view patterns] <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/view_patterns.html> Syntax ╌╌╌╌╌╌ Use `[%view? pat when exp]' as a pattern to apply `exp' to whatever the pattern is matching and match the result of the `exp' application against `pat'. This is analogous to the Haskell view pattern `exp -> pat'. The above extension node payload syntax is the best I could come up with to combine an expression and a pattern. Honestly, I was even surprised that `when exp' is attached to a pattern in the AST (not a case), because normally it isn't part of the pattern itself. Example ╌╌╌╌╌╌╌ This allows one to write ┌──── │ (* These cases are exactly like reduction rules! *) │ let rec reduce = function │ | Add (Int n1, Int n2) -> Some (Int (n1 + n2)) │ | Add ([%view? Some p1' when reduce], p2) -> Some (Add (p1', p2)) │ | Add (p1, [%view? Some p2' when reduce]) -> Some (Add (p1, p2')) │ (* ... *) │ | _ -> None └──── instead of ┌──── │ (* These nested cases are so annoying! *) │ let rec reduce = function │ | Add (Int n1, Int n2) -> Some (Int (n1 + n2)) │ | Add (p1, p2) -> │ begin match reduce p1 with │ | Some p1' -> Some (Add (p1', p2)) │ | None -> │ begin match reduce p2 with │ | Some p2' -> Some (Add (p1, p2')) │ | None -> None │ end │ end │ (* ... *) │ | _ -> None └──── See [`examples/' on GitHub] for more. [`examples/' on GitHub] <https://github.com/sim642/ppx_viewpattern/tree/master/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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 33372 bytes --]
[-- Attachment #1: Type: text/plain, Size: 14712 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 15 to 22, 2022. Table of Contents ───────────────── Friday 03/04 Intern presentations – open attendance! Multicore OCaml: February 2022 OCaml 4.14.0, second release candidate For Diversity and the OCaml Community: Outreachy Summer 2022 Understanding cancellation (in eio) Atdpy: derive safe JSON interfaces for Python Old CWN Friday 03/04 Intern presentations – open attendance! ════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/friday-03-04-intern-presentations-open-attendance/9429/8> Continuing this thread, Aya announced ───────────────────────────────────── [Here is the link] to the video recording of the presentations! Thanks again to everyone who attended :pray: :tada: [Here is the link] <https://watch.ocaml.org/videos/watch/f3829e4b-e2cd-443e-8502-f406e893fe5f> Multicore OCaml: February 2022 ══════════════════════════════ Archive: <https://discuss.ocaml.org/t/multicore-ocaml-february-2022/9522/1> Anil Madhavapeddy announced ─────────────────────────── Welcome to the February 2022 [Multicore OCaml] monthly report! As with [previous updates], these have been compiled by me, @ctk21, @kayceesrk and @shakthimaan. Progress towards a stable OCaml 5.0.0 release have been moving forward at full steam, with most of the multicore OCaml work now happening directly within the main ocaml/ocaml repository. As a number of [deprecations] have happened in OCaml 5.0+trunk, it can be a little tricky in the immediate term to get a working development environment. You may find these resources helpful: • There is a [multicore monorepo] which is a 'fast clone and dune build' with a number of ecosystem libraries. (thanks @patricoferris) • There is an [alpha-opam-repository] which contains work-in-progress packages. If a package you maintain is in there, now would be a good time to start releasing it to the mainline opam-repository. Remember that while we can propose changes, only the community maintainers of the relevant projects can do the actual release, so *your help with making OCaml 5.0-compatible releases of your projects would be very much appreciated*. (thanks @kit-ty-kate) For mainline development, the [compiler development newsletter] has an overview of what's been happening in the compiler. From a multicore perspective: • the [ARM64 PR] has been merged, so your shiny Mac M1s will now work • we continue to work on the post-Multicore merge tasks for an upcoming 5.0.0+trunk release. The documentation efforts on the OCaml memory model, runtime system, and STW synchronization have also started. • The [eio project] is actively being developed which now includes UDP support with Eio's networking interface. There has been [robust discussion] on several aspects of eio which is all influencing the next iteration of its design (thank you to everyone!). For those of you who do not wish to participate in public discussion, feel free to get in touch with me or @kayceesrk for a private discussion, particularly if you have a large OCaml codebase and opinions on concurrency. We'll summarise all these discussions as best we can over the coming months. • `Sandmark-nightly' and `Sandmark' have a custom variant support feature to build trunk, developer branches, or a specific commit to assess any performance regressions. The backend tooling with UI enhancements continue to drive the `current-bench' project forward. As always, the Multicore OCaml updates are listed first, which are then followed by the ecosystem tooling updates. Finally, the sandmark, sandmark-nightly and current-bench project tasks are mentioned for your reference. /Editor’s note: please find the full update at the archive link above./ [Multicore OCaml] <https://github.com/ocaml-multicore/ocaml-multicore> [previous updates] <https://discuss.ocaml.org/tag/multicore-monthly> [deprecations] <https://github.com/ocaml/ocaml/blob/trunk/Changes> [multicore monorepo] <https://discuss.ocaml.org/t/awesome-multicore-ocaml-and-multicore-monorepo/9515> [alpha-opam-repository] <https://github.com/kit-ty-kate/opam-alpha-repository/tree/master/packages> [compiler development newsletter] <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-5-november-2021-to-february-2022/9459> [ARM64 PR] <https://github.com/ocaml/ocaml/pulls/10972> [eio project] <https://github.com/ocaml-multicore/eio> [robust discussion] <https://discuss.ocaml.org/tag/effects> OCaml 4.14.0, second release candidate ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-14-0-second-release-candidate/9528/1> octachron announced ─────────────────── The release of OCaml 4.14.0 is imminent. As a last test that everything is in order, we are publishing a second release candidate for OCaml 4.14.0. We are directly jumping to the second release candidate due to a type system regression discovered during the release process of the first release candidate. Compared to the last beta, this release candidate includes a regression fix when typing recursive constraints, two backend fixes (one for the frame-pointer mode and the other one for the RISC-V architecture), one configuration fix for musl/arm64, and the manual chapter for the TMC transformation. If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> The full release of OCaml 4.14.0 is currently planned for next week. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands ┌──── │ opam update │ opam switch create 4.14.0~rc2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.4.14.0~rc2+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── where `<option_list>' is a comma separated list of `ocaml-option-*' packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 4.14.0~rc2+flambda+nffa │ --packages=ocaml-variants.4.14.0~rc2+options,ocaml-option-flambda,ocaml-option-no-flat-float-array │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── All available options can be listed with `opam search ocaml-option'. The source code for the release candidate is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/4.14.0-rc2.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.0~rc2.tar.gz> Changes since the last beta ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Type system regression fix ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#11101], [#11109]: A recursive type constraint fails on 4.14 (Jacques Garrigue, report and review by Florian Angeletti) [#11101] <https://github.com/ocaml/ocaml/issues/11101> [#11109] <https://github.com/ocaml/ocaml/issues/11109> Backend fixes ┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#10688]: Move frame descriptor table from `rodata` to `data` section on RISC-V. Improves support for building DLLs and PIEs. In particular, this applies to all binaries in distributions that build PIEs by default (eg Gentoo and Alpine). (Alex Fan, review by Gabriel Scherer) • [#11031]: Exception handlers restore the rbp register when using frame-pointers on amd64. (Fabrice Buoro, with help from Stephen Dolan, Tom Kelly and Mark Shinwell, review by Xavier Leroy) [#10688] <https://github.com/ocaml/ocaml/issues/10688> [#11031] <https://github.com/ocaml/ocaml/issues/11031> Configuration fix ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#11025], [#11036]: Do not pass -no-pie to the C compiler on musl/arm64 (omni, Kate Deplaix and Antonio Nuno Monteiro, review by Xavier Leroy) [#11025] <https://github.com/ocaml/ocaml/issues/11025> [#11036] <https://github.com/ocaml/ocaml/issues/11036> Documentation ┄┄┄┄┄┄┄┄┄┄┄┄┄ • *updated entry* [#181], [#9760], +[#10740]: opt-in tail-modulo-cons (TMC) transformation ┌──── │ let[@tail_mod_cons] rec map f li = ... └──── (Frédéric Bour, Gabriel Scherer, Basile Clément, review by Basile Clément and Pierre Chambart, tested by Konstantin Romanov) [#181] <https://github.com/ocaml/ocaml/issues/181> [#9760] <https://github.com/ocaml/ocaml/issues/9760> [#10740] <https://github.com/ocaml/ocaml/issues/10740> For Diversity and the OCaml Community: Outreachy Summer 2022 ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/for-diversity-and-the-ocaml-community-outreachy-summer-2022/9234/5> Continuing this thread, Patrick Ferris said ─────────────────────────────────────────── Thanks for the updates @pitag! For this summer's round I'll be mentoring a project to [Extend ocaml-geojson to support TopoJSON] which will likely be a separate package. This is part of a larger effort I'm embarking on to provide better [geospatial libraries and tools in OCaml]! I'd be very happy to have a co-mentor if the project (or just the idea of Outreachy) interests anyone. Don't hesitate to reach out to me on discuss publicly or privately if you are interested or have more questions :camel: [Extend ocaml-geojson to support TopoJSON] <https://www.outreachy.org/apply/project-selection/#ocaml> [geospatial libraries and tools in OCaml] <https://github.com/geocaml> Understanding cancellation (in eio) ═══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/understanding-cancellation-in-eio/9369/45> Deep in this thread, Simon Cruanes announced ──────────────────────────────────────────── I still have reservations about the capabilities aspect of Eio, but the structured concurrency part looks very nice. Just a few notes, for future reference to readers of this thread (if I haven't missed them being posted above already): Another interesting post about structured concurrency and cancellation: <https://250bpm.com/blog:71/> A structured concurrency library in python: [trio], which might be relatively similar to Eio's switches in concept (esp since @talex linked [this])? Companion post to the trio blogpost: <https://vorpus.org/blog/timeouts-and-cancellation-for-humans/> which is directly relevant to the current topic. [trio] <https://trio.readthedocs.io/en/stable/index.html> [this] <https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/> Atdpy: derive safe JSON interfaces for Python ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/atdpy-derive-safe-json-interfaces-for-python/9544/1> Martin Jambon announced ─────────────────────── On behalf of the ATD team, I'd like to announce atdpy, which is part of the release 2.3.x of the ATD tools. For now, the best installation method with via opam: ┌──── │ $ opam install atdpy └──── Atdpy is a new backend for [ATD]. It takes a collection of type definitions and derives Python classes with mypy type annotations that validate the JSON data. A [short introduction] is included in the documentation. Use cases: • Safe communication with another program that also uses an ATD interface. Other supported languages are OCaml (including Bucklescript), Java, and Scala. • Need for [mostly] type-safe Python methods via mypy. • Need for a good Python API to communicate with an OCaml executable or service. • Need for sum types (variants, algebraic data types, tagged unions). ATD sum types are ordinary types that include pure enums. Atdpy was developed as part of our work on [Semgrep] at [r2c]. Many thanks to @mseri for his massive help during the opam release of the 7 ATD packages, and to the Ahrefs folks and @Khady in particular for supporting the project. [ATD] <https://github.com/ahrefs/atd> [short introduction] <https://atd.readthedocs.io/en/latest/atdpy.html> [Semgrep] <https://semgrep.dev/> [r2c] <https://r2c.dev/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 26263 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 25400 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 22 to 29, 2022. Table of Contents ───────────────── pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications Tarides is hiring! For Diversity and the OCaml Community: Outreachy Summer 2022 Caqti 1.8.0 and related news First release of prbnmcn-dagger MirageOS 4.0 OCaml 4.14.0 is released ocaml-in-python.0.1.0: Effortless Python bindings for OCaml modules Old CWN pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications ════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786/6> Ryan Moore announced ──────────────────── New releases ╌╌╌╌╌╌╌╌╌╌╌╌ Version 0.3.0 and 0.3.1 are now available on [GitHub]. 0.3.0 has been merged into opam, and a PR for 0.3.1 has been opened. The [change log] has more details about the changes. [GitHub] <https://github.com/mooreryan/ocaml_python_bindgen/tags> [change log] <https://github.com/mooreryan/ocaml_python_bindgen/blob/main/CHANGELOG.md> Binding tuples ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ You can now bind tuples directly. Here's a Python function that takes two lists of points (where each "point" is a tuple like `(x, y)') and adds them together ┌──── │ def add(points1, points2): │ return [(x1 + y1, x2 + y2) for (x1, x2), (y1, y2) in zip(points1, points2)] └──── And you could bind it using tuples from the OCaml side as well. ┌──── │ val add : points1:(int * int) list -> points2:(int * int) list -> unit -> (int * int) list └──── Note there are some restrictions regarding tuples, which you can read about [here], [here], or [here]. [here] <https://mooreryan.github.io/ocaml_python_bindgen/tuples/> [here] <https://github.com/mooreryan/ocaml_python_bindgen/blob/main/examples/README.md> [here] <https://github.com/mooreryan/ocaml_python_bindgen/blob/main/CHANGELOG.md#030-2022-03-18> Attributes ╌╌╌╌╌╌╌╌╌╌ You can use attributes on value specifications. Currently the only one supported is `py_fun_name', which allows you to decouple the Python method name and the generated OCaml function name. As an example, take the following Python function, which adds to "things". ┌──── │ def add(x, y): │ return x + y └──── You could bind multiple OCaml functions to this single function now. ┌──── │ val add_int : x:int -> y:int -> unit -> int │ [@@py_fun_name add] │ │ val add_float : x:float -> y:float -> unit -> float │ [@@py_fun_name add] │ │ val add_string : x:string -> y:string -> unit -> string │ [@@py_fun_name add] └──── Python magic methods ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ This is also nice for binding Python [magic methods]. For example, you don't have to use `__init__' as the name of the OCaml function you use to make instances of a Python class. You can bind it to a more natural name like `create' or `make'. ┌──── │ val create : name:string -> age:int -> unit -> t │ [@@py_fun_name __init__] └──── [magic methods] <https://docs.python.org/3/reference/datamodel.html#specialnames> Using Pytypes.pyobject directly ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Sometimes you may not want to bother converting Python types to normal OCaml types at all. You can do that now in value specifications by using the `Pytypes.pyobject' and `Py.Object.t' types directly. Fewer dependencies ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ `re' is now used instead of `re2', which drops the number of dependencies that need to be installed by about half. Additionally, `core', `core_bench', and `bisect_ppx' don't need to be installed if you want to install `pyml_bindgen' directly from the git repository, which greatly cuts the required dependencies in this case. Thanks again to UnixJunkie for spurring many of these updates! Tarides is hiring! ══════════════════ Archive: <https://discuss.ocaml.org/t/tarides-is-hiring/9553/1> Thomas Gazagnaire announced ─────────────────────────── Following the recent announcement about Tarides (joining forces with [OCaml Labs] and [Segfault System]), we are now looking to expand our team with experienced software engineers, compassionate team leads and experts in software consulting services. Our ambition is to bring OCaml to a vast set of new developers and industries. We want to make developers more productive by spending less time on fixing bugs and more on writing new features. And we want the software industry to build more robust and performant systems that can last for decades. We are looking for: • Experienced [Software Engineer(s)] to take part in the development of Irmin. You will be part of the team that designs, builds and ships Irmin libraries and applications to our community and customers. • [Team Lead(s)] who cares about motivating their team members, supporting their growth and development and successfully delivering the team's objectives on time. • A [Head of Consulting Services] to diversify our technical teams and commercial services portfolio. You'll be the first hire for this brand new department and will have the opportunity to help us build our services structure from scratch, including our strategy, processes, tools, and team. We are always looking for great OCaml enthusiasts to join our team, so even if these job descriptions do not fit your profile precisely, you are welcome to send us [a spontaneous application]! [OCaml Labs] <https://tarides.com/blog/2022-01-27-ocaml-labs-joins-tarides> [Segfault System] <https://tarides.com/blog/2022-03-01-segfault-systems-joins-tarides> [Software Engineer(s)] <https://tarides.com/jobs/senior-software-engineer> [Team Lead(s)] <https://tarides.com/jobs/team-lead-engineering> [Head of Consulting Services] <https://tarides.com/jobs/head-of-consulting-services> [a spontaneous application] <https://tarides.com/jobs/spontaneous-application> For Diversity and the OCaml Community: Outreachy Summer 2022 ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/for-diversity-and-the-ocaml-community-outreachy-summer-2022/9234/6> Deep in this thread, Aya announced ────────────────────────────────── @pitag and I have resubmitted the PPX derivers project for this Summer 2022 round: *Expand OCaml's library of standard derivers*! This is the same project I was the intern for this past Winter 2022 round, where the goal is to build up a [standard derivers] library, like `ppx_deriving', using the updated `ppxlib' API. I'm excited to be supporting @pitag with mentoring, and for the opportunity to stay involved now that my internship has ended :smiley: [standard derivers] <https://github.com/ocaml-ppx/standard_derivers> Caqti 1.8.0 and related news ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-caqti-1-8-0-and-related-news/9561/1> "Petter A. Urkedal announced ──────────────────────────── I am happy to announce the second release of [Caqti] this year. The reason for the quick succession is partly an adjustment to the [new API for request construction] and partly that [matchable error conditions] did not make it into the previous release. You can see the full release notes below. I would also like to thank [OCaml Software Foundation] for sponsoring my efforts on the Caqti project this year, also including most of the work that went into the previous release. One [feature in progress] is a new driver based on the pure-OCaml [pgx] which should make it possible, with some additional changes to the way drivers are loaded, to target MirageOS. I am note sure if this can be done in a minor release or will require a Caqti 2 branch. [Caqti] <https://github.com/paurkedal/ocaml-caqti> [new API for request construction] <https://paurkedal.github.io/ocaml-caqti/caqti/Caqti_request/Infix/index.html> [matchable error conditions] <https://github.com/paurkedal/ocaml-caqti/issues/72> [OCaml Software Foundation] <https://ocaml-sf.org> [feature in progress] <https://github.com/paurkedal/ocaml-caqti/issues/38> [pgx] <https://github.com/arenadotio/pgx> Release Notes ╌╌╌╌╌╌╌╌╌╌╌╌╌ New features: • A matchable representation of common causes of errors on the database side is now available, with limitations. It focuses on conditions which seem most likely useful to handle. At the moment we lack extended error codes from SQLite3 needed to make the cause fully precise. • Expose the underlying error details from database client libraries. This is meant to be use as a last resort, and requires directly linking with the relevant drivers. • A second set of request construction operators `->.', `->?', `->!', and `->*' were introduced after experience with converting existing code. Given the parameter and result type they return a function which constructs a request directly from a query string. Avoiding the need to compose with `@:-' simplifies local opens and usage with `List.map' etc. • Environment variables are now expanded in the debug log when using the new request constructors introduced in 1.7.0. • A new `?tweaks_version' connection parameter has been added to control when the client is ready to adapt to changes in database session parameters or other adjustments of the interaction with specific database systems. [[More details available in the documentation.]] • Enable foreign key constraint checks for SQLite3 starting at tweaks version 1.7. Fixes: • Fixed debug logging to pass the correct driver info to the query callback instead of a dummy driver info which would cause a failure if unsupported. Deprecations: • The `-->' operator was renamed to `-->!', with a deprecated alias, for consistency with the new `->!' operator. • The old convenience interface for creating requests has been deprecated in favour of the new infix operators and the new query template parser. • Documented-only deprecations of `Caqti_sql_io', `Caqti_lwt_sql_io', and `Caqti_async_sql_io' have been annotated. [More details available in the documentation.] <https://paurkedal.github.io/ocaml-caqti/caqti/tweaks.html> First release of prbnmcn-dagger ═══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-prbnmcn-dagger/9311/2> Igarnier announced ────────────────── I'm proud to announce the release of version 0.0.2 of [prbnmcn-dagger]. This version adds Sequential Monte-Carlo, a.k.a. [particle filters]-based inference to the library. Here's the full changelog: • Dependency: `prbnmcn-stats.0.0.3' -> `prbnmcn-stats.0.0.4' • Add beta distribution to Gsl samplers • Refactor Cps monad • Add SMC inference • Simplify handler type, modularize effect definitions away from Cps_monad • Fix typo: bernouilli -> bernoulli (report by @nilsbecker) I also wrote the following article: [Applying Sequential Monte-Carlo to time series forecasting] It contains some use cases for the library, I hope some find it fun :) To conclude this post, and as a partial answer to @gasche 's [question] in an older thread, I believe that unlike some other inference techniques, single-shot continuations are enough to implement SMC. Without getting into the details, the implementation is very reminiscent of that of lightweight threading libraries. I look forward to experiment with a fibre-based implementation! [prbnmcn-dagger] <https://github.com/igarnier/prbnmcn-dagger> [particle filters] <https://en.wikipedia.org/wiki/Particle_filter> [Applying Sequential Monte-Carlo to time series forecasting] <http://probanomicon.xyz/blog/wind_power_forecast.html> [question] <https://discuss.ocaml.org/t/multi-shot-continuations-gone-forever/9072/5> MirageOS 4.0 ════════════ Archive: <https://discuss.ocaml.org/t/ann-mirageos-4-0/9598/1> Thomas Gazagnaire announced ─────────────────────────── *On behalf of the MirageOS team, I am delighted to announce the release of MirageOS 4.0.0!* I'd like to send special thanks to @dinosaure and @Lortex who drove that release forward for multiple years. Since the first release of 2013, MirageOS has made steady progress toward deploying a self-managed internet infrastructure. The project’s initial aim was to self-host as many services as possible aimed at empowering internet users to securely deploy infrastructure to own their data and take back control of their privacy. MirageOS can securely deploy [static website hosting] with “Let’s Encrypt” certificate provisioning and a [secure SMTPstack] with security extensions. MirageOS can also deploy decentralised communication infrastructure like [Matrix], [OpenVPN servers], and [TLS tunnels] to ensure data privacy or [DNS(SEC) servers] for better authentication. The protocol ecosystem now contains [hundreds of libraries] and services millions of daily users. Over these years, major commercial users have joined the projects. They rely on MirageOS libraries to keep their products secure. For instance, the MirageOS networking code powers [Docker Desktop’s VPNKit], which serves the traffic of millions of containers daily. [Citrix Hypervisor] uses MirageOS to interact with Xen, the hypervisor that powers most of today’s public cloud. [Nitrokey] is developing a new hardware security module based on MirageOS. [Robur] develops a unikernel orchestration system for fleets of MirageOS unikernels. [Tarides] uses MirageOS to improve the [Tezos] blockchain, and [Hyper] uses MirageOS to build sensor analytics and an automation platform for sustainable agriculture. In the coming weeks, our blog will feature in-depth technical content for the new features that MirageOS brings, as well as a tour of the existing community and commercial users of MirageOS. Please reach out if you’d like to tell us about your story. [static website hosting] <https://github.com/roburio/unipi> [secure SMTPstack] <https://github.com/mirage/ptt> [Matrix] <https://github.com/mirage/ocaml-matrix> [OpenVPN servers] <https://github.com/roburio/openvpn> [TLS tunnels] <https://github.com/roburio/tlstunnel> [DNS(SEC) servers] <https://github.com/mirage/ocaml-dns> [hundreds of libraries] <https://github.com/mirage/> [Docker Desktop’s VPNKit] <https://www.docker.com/blog/how-docker-desktop-networking-works-under-the-hood/> [Citrix Hypervisor] <https://www.citrix.com/fr-fr/products/citrix-hypervisor/> [Nitrokey] <https://www.nitrokey.com/products/nethsm> [Robur] <https://robur.io/> [Tarides] <https://tarides.com/> [Tezos] <https://tezos.com/> [Hyper] <https://hyper.ag/> Install MirageOS 4 ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The easiest way to install MirageOS 4 is by using the opam version 2.1 and `ocaml>=4.12.1`. Follow the [installation guide] for more details. ┌──── │ $ opam update │ $ opam install 'mirage>4' └──── /Note/: if you upgrade from MirageOS 3 you will need to manually clean the previous generated files (or call `mirage clean' before upgrading). You would also want to read [the full list of API changes]. You can see unikernel examples in [mirage/mirage-skeleton], [roburio/unikernels] or [tarides/unikernels]. [installation guide] <https://mirage.io/docs/install> [the full list of API changes] <https://mirage.io/docs/breaking-changes> [mirage/mirage-skeleton] <https://github.com/mirage/mirage-skeleton> [roburio/unikernels] <https://github.com/roburio/unikernels> [tarides/unikernels] <https://github.com/tarides/unikernels> About MirageOS ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ MirageOS is a library operating system that constructs unikernels for secure, high-performance, low-energy footprint applications across various hypervisor and embedded platforms. It is available as an open-source project created and maintained by the [MirageOS Core Team]. A unikernel can be customised based on the target architecture by picking the relevant MirageOS libraries and compiling them into a standalone operating system, which contains strictly the functionality necessary for the target. This minimises the unikernel’s footprint, increasing the security of the deployed operating system. The MirageOS architecture can be divided into operating system libraries, typed signatures, and a metaprogramming compiler. The operating system libraries implement various functionalities, ranging from low-level network card drivers, to full reimplementations of the TLS protocol, as well as the Git protocol to store versioned data. A set of typed signatures ensures that the OS libraries are consistent and work well in conjunction with each other. Most importantly, MirageOS is also a metaprogramming compiler that can input OCaml source code along with its dependencies, and a deployment target description in order to generate an executable unikernel, i.e., a specialised binary artefact containing only the code needed to run on the target platform. Overall, MirageOS focuses on providing a small, well-defined, typed interface with the system components of the target architecture. Read the full announcement on [mirage.io's blog]. [MirageOS Core Team] <https://github.com/orgs/mirage/teams/core/members> [mirage.io's blog] <https://mirage.io/blog/announcing-mirage-40> Anil Madhavapeddy then added ──────────────────────────── For those curious about what some of the MirageOS libraries _are_, there is a raw Yaml list over at [mirage/mirage-repositories] listing most of them. Conversion of this Yaml to HTML for the main mirage.io website would be a welcome contribution! :slight_smile: [mirage/mirage-repositories] <https://github.com/mirage/mirage-repositories/blob/main/repos.yml> OCaml 4.14.0 is released ════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-4-14-0-is-released/9600/1> octachron announced ─────────────────── The OCaml team has the pleasure of celebrating the birthday of Alexander Grothendieck by announcing the release of OCaml version 4.14.0. Some of the highlights in the 4.14.0 release are: • Integrated support for "go to definitions" in Merlin. • Standard library: new modules `In_channel' and `Out_channel', many new functions in Seq module, UTF decoding and validation support for strings and bytes. • Runtime optimisation: GC prefetching. Benchmarks show a speedup of around 20% in GC-heavy programs. • Improved error messages in particular for module-level error. • Deprecated functions and modules in preparation for OCaml 5. In particular, the Stream and Genlex modules are now deprecated. • Type variables can be explicitly introduced in value and variant constructor declarations. For instance, ┌──── │ val fold: ('acc -> 'elt -> 'acc) -> 'acc -> 'elt list -> 'acc │ type showable = Show: 'a * ('a -> string) -> showable └──── can now be written as ┌──── │ val fold: 'acc 'elt. ('acc -> 'elt -> 'acc) -> 'acc -> 'elt list -> 'acc │ type showable = Show: 'a. 'a * ('a -> string) -> showable └──── • Tail-call with up to 64 arguments are now guaranteed to be optimized for all architectures. • Experimental tail modulo cons (TMC) transformation The full list of changes can be found in the changelog below. (/editor’s note: please follow the archive link for the full changelog/) Those releases are available as OPAM switches, and as a source download here: • <https://github.com/ocaml/ocaml/archive/4.14.0.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.0.tar.gz> ocaml-in-python.0.1.0: Effortless Python bindings for OCaml modules ═══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-in-python-0-1-0-effortless-python-bindings-for-ocaml-modules/9603/1> Thierry Martinez announced ────────────────────────── I am happy to announce the first release of `ocaml-in-python': this is a Python package that exposes all OCaml modules as Python libraries, generating bindings on the fly. This can be seen as a dual of [`pyml_bindgen']: `pyml_bindgen' binds Python libraries in OCaml, while `ocaml-in-python' binds OCaml modules in Python. It is available from [GitHub] or *via* `opam': `opam install ocaml-in-python' Requirements: `OCaml' >= 4.13, `Python' >= 3.7. Once installed *via* `opam', the package should be registered in the Python environment: • either by registering the package with `pip' using the following command (requires Python >=3.8): ┌──── │ pip install --editable "`opam var ocaml-in-python:lib`" └──── • or by adding the following definition to the environment: ┌──── │ export PYTHONPATH="`opam var share`/python/:$PYTHONPATH" └──── Then, we can `import ocaml' in Python and use OCaml modules: ┌──── │ Python 3.10.0 (default, Nov 10 2021, 19:16:14) [GCC 7.5.0] on linux │ Type "help", "copyright", "credits" or "license" for more information. │ >>> import ocaml │ >>> print(ocaml.List.map((lambda x : x + 1), [1, 2, 3])) │ [2;3;4] └──── We can for instance compile an OCaml module on the fly from Python. ┌──── │ >>> m = ocaml.compile('let hello x = Printf.printf "Hello, %s!\n%!" x') │ >>> m.hello('world') │ Hello, world! └──── And we can require and use packages /via/ `findlib'. ┌──── │ >>> ocaml.require("parmap") │ >>> from ocaml import Parmap │ >>> print(Parmap.parmap( │ ... (lambda x : x + 1), Parmap.A([1, 2, 3]), ncores=2)) │ [2;3;4] └──── Details about the conversions are given in [`README.md']. Happy hacking! [`pyml_bindgen'] <https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786> [GitHub] <https://github.com/thierry-martinez/ocaml-in-python> [`README.md'] <https://github.com/thierry-martinez/ocaml-in-python/blob/main/README.md> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 40773 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 20781 bytes --] Hello Here is the latest OCaml Weekly News, for the week of March 29 to April 05, 2022. Table of Contents ───────────────── v0.15 release of Jane Street packages EmelleTV Show - 2022 Open source editor for iOS, iPadOS and macOS The mysterious pointer in the runtime closure representation Other OCaml News Old CWN v0.15 release of Jane Street packages ═════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-v0-15-release-of-jane-street-packages/9612/1> Arseniy Alekseyev announced ─────────────────────────── We are pleased to announce the v0.15 release of Jane Street packages! This release comes with 41 new packages, and a large number of fixes and enhancements. The documentation for the individual packages will soon be available on [v3.ocaml.org/packages], after some technical issues are fixed. The remainder of this e-mail highlights the main changes since the v0.14 release. [v3.ocaml.org/packages] <https://v3.ocaml.org/packages> Notable changes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Re-structuring of `Core'. ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ The most noticeable breaking change is the re-structuring of `Core'. In 0.14, `Core' is somewhat bloated and includes many modules that are barely ever used, many of which are Unix-specific. In 0.15, many of those modules moved to separate libraries, most of them to package~core_unix~, and `core' is now much smaller and no longer contains unix-specific code. The mapping between the new libraries and the old modules can be summarized by the contents of `Core_compat' library v0.14: ┌──── │ module Command_unix = Core.Command │ module Date_unix = Core.Date │ module Filename_unix = Core.Filename │ module Signal_unix = Core.Signal │ module Sys_unix = Core.Sys │ module Core_thread = Core.Thread │ module Time_unix = Core.Time │ module Time_ns_unix = Core.Time_ns │ module Core_unix = Core.Unix │ module Version_util = Core.Version_util │ │ module Interval_lib = struct │ module Interval = Core.Interval │ module Interval_intf = Core.Interval_intf │ end │ │ module Time_interface = Core.Time_common └──── Async: `Monitor.try_with' ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ `Monitor.try_with' and related functions changed the defaults for their `run' and `rest' parameters. They used to default to `~~run:~Schedule ~rest:~Log~', but now they default to `~~run:~Now ~rest:~Raise~'. Many other changes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ There are many changes and additions across 130+ existing packages, and unfortunately we don't maintain a changelog to list them all. The code for all of our packages is on our [github], and if you're interested in the details of what changed in a particular package, you can inspect the diff between branches v0.14 and v0.15. [github] <https://github.com/janestreet> New packages ╌╌╌╌╌╌╌╌╌╌╌╌ [`abstract_algebra']: A small library describing abstract algebra concepts A library describing abstract algebra concepts. Currently, it includes Commutative_group and Vector_space. [`async_rpc_websocket']: Library to serve and dispatch Async RPCs over websockets Library to serve and dispatch Async RPCs over websockets. Rpc_websocket makes it easy to serve and send Async RPCs with HTTP+Websocket underlying the transport. It also provides a mechanism to share the RPC implementations between a vanilla TCP server and a HTTP server. On the server side, the library detects when a websocket connection is established, and routes to an optionally provided vanilla HTTP handler when non-websocket traffic occurs. [`bigdecimal']: Arbitrary-precision decimal based on Zarith A high-precision representation of decimal numbers as [mantissa * 10^exponent], where the mantissa is internally a [Bigint.t] and the exponent is an [int]. [`cohttp_async_websocket']: Websocket library for use with cohttp and async Websocket library for use with cohttp and async. Cohttp_async_websocket is a full-featured server-side websocket implementation, using Async as the concurrency library, and Cohttp for HTTP negotiation. It implements a large portion of RFC6445. The library has been hardened with many applications using it for several year, in conjunction with async-js and google-chrome. [`cohttp_static_handler']: A library for easily creating a cohttp handler for static files Single page handlers are handlers that serve user specified JavaScript and css files along with a generated index page that loads those files. [`core_compat']: Compatibility for core 0.14 Compatibility wrapper to make it possible to have code compatible with both Core 0.14 and 0.15. [`env_config']: Helper library for retrieving configuration from an environment variable The Env_config library is a helper for retrieving library and program configuration from an environment variable. Its goal is to make it easy to override a configuration that is loaded from disk, computed, or embedded in a library. [`file_path']: A library for typed manipulation of UNIX-style file paths A library for typed manipulation of UNIX-style file paths. [`fuzzy_match']: A library for fuzzy string matching A library for fuzzy string matching [`fzf']: A library for running the fzf command line tool A library for running the fzf command line fuzzy matcher [`hardcaml_c']: Hardcaml C Simulation Backend A fast C-based simulation backend for Hardcaml circuits. The library transparently compiles a Hardcaml Circuit to C code, which is in turn compiled and linked into the running executable. The generated simulation object can be used like any other cyclesim simulation. [`hardcaml_circuits']: Hardcaml Circuits A small library of useful/interesting Hardcaml circuits. [`hardcaml_fixed_point']: Hardcaml fixed point arithmetic Signed and Unsigned fixed point operations, with a full complement of rounding and overflow functionality. [`hardcaml_of_verilog']: Convert Verilog to a Hardcaml design The opensource synthesis tool yosys is used to convert a verilog design to a JSON based netlist representation. This library can load the JSON netlist and build a hardcaml circuit. Code can also be generated to wrap the conversion process using Hardcaml interfaces. [`hardcaml_step_testbench']: Hardcaml Testbench Monad A monad for interacting with Hardcaml.Cyclesim based simulations. Allows multiple control threads to interact with a simulation module, all of which are synchronised to the system clock. [`hardcaml_verify']: Hardcaml Verification Tools Tools for verifying properties of Hardcaml circuits. Combinational circuits can be converted to 'conjunctive normal form' for input into SAT solvers via DIMAC files. Support for a few opensource solvers is integrated - minisat, picosat, Z3 - just ensure they are in your PATH. Circuits can also be converted to NuSMV format for advanced bounded and unbounded model checking tasks. [`hardcaml_verilator']: Hardcaml Verilator Simulation Backend Very fast verilator-based simulations of Hardcaml circuits. This library transparently compiles a verilator-based shared library, and links it back to the running executable to be used as a Cyclesim simulation. [`hardcaml_xilinx']: Hardcaml wrappers for Xilinx memory primitives The Hardcaml_xilinx library provides wrappers for Xilinx specific RAM and FIFO primitive blocks. In many cases a simulation model is provided. The `Synthesis' module implements various arithmetic and logical RTL components with Xilinx LUT primitives. [`hardcaml_xilinx_components']: Hardcaml Xilinx component definitions A tool for reading Xilinx VHDL Unisim and XPM component definitions from a Vivado installation and generating Hardcaml interfaces automatically. [`hex_encode']: Hexadecimal encoding library This library implements hexadecimal encoding and decoding [`hg_lib']: A library that wraps the Mercurial command line interface A library that wraps the Mercurial command line interface. [`int_repr']: Integers of various widths Integers of various widths. [`jsonaf']: A library for parsing, manipulating, and serializing data structured as JSON A library for parsing, manipulating, and serializing data structured as JSON. [`krb']: A library for using Kerberos for both Rpc and Tcp communication Jane Street's library for Kerberizing RPC connections so that • the server gets an authenticated principal (i.e. username) with every incoming connection, and • RPC communication may be encrypted, if necessary. [`magic-trace']: Easy Intel Processor Trace Visualizer Magic-trace makes it easy to record and visualize Intel Processor Trace data for debugging tricky performance issues. [`ocaml-embed-file']: Files contents as module constants Embed-file takes some files and generates code for an OCaml module defining string constants containing the contents of those files. [`ocaml_intrinsics']: Intrinsics Provides functions to invoke amd64 instructions (such as clz,popcnt,rdtsc,rdpmc) when available, or compatible software implementation on other targets. [`ocaml-probes']: USDT probes for OCaml: command line tool A tool for controlling user-space statically-defined tracing probes for OCaml. Experimental. [`ppx_css']: A ppx that takes in css strings and produces a module for accessing the unique names defined within A ppx that takes in css strings and produces a module for accessing the unique names defined within. [`ppx_disable_unused_warnings']: Expands [@disable_unused_warnings] into [@warning \"-20-26-32-33-34-35-36-37-38-39-60-66-67\"] Part of the Jane Street's PPX rewriters collection. [`ppx_ignore_instrumentation']: Ignore Jane Street specific instrumentation extensions Ignore Jane Street specific instrumentation extensions from internal PPXs or compiler features not yet upstreamed. [`ppx_jsonaf_conv']: [@@deriving] plugin to generate Jsonaf conversion functions Part of the Jane Street's PPX rewriters collection. [`ppx_typed_fields']: GADT-based field accessors and utilities Part of the Jane Street's PPX rewriters collection. [`ppx_type_directed_value']: Get [@@deriving]-style generation of type-directed values without writing a ppx `Ppx_type_directed_value' is a ppx that does `[@@deriving]'-style generation of type-directed values based on user-provided modules. The user-provided modules tell `ppx_type_directed_value' how to compose type-directed values (for example, combine type-directed values of the fields of a record to form a type-directed value for the record itself). This allows a wide variety of PPXs such as `ppx_sexp_conv', `ppx_compare', `ppx_enumerate', etc. to be implemented with `ppx_type_directed_value', but with some runtime cost. This PPX currently supports deriving type-directed values for records, ordinary & polymorphic variants and tuples. It also supports custom user-defined attributes on record and variant fields. [`profunctor']: A library providing a signature for simple profunctors and traversal of a record This is a very small library which provides a signature for profunctor types and operations which can be used to traverse a record with them based on record_builder and the `ppx_fields' syntax extension. [`redis-async']: Redis client for Async applications A client library for Redis versions 6 and higher. Provides a strongly-typed API with transparent (de)serialization for application-defined types. Supports client tracking and internally uses the RESP3 protocol. [`sexp_diff']: Code for computing the diff of two sexps The code behind the [diff] subcommand of the Jane Street's [sexp] command line tool. [`sexp_grammar']: Sexp grammar helpers Helpers for manipulating [Sexplib.Sexp_grammar] values. [`sexp_string_quickcheck']: Quickcheck helpers for strings parsing to sexps This library provides quickcheck generators, helpers, and shrinkers for quickcheck-based tests that wish to exercise the concrete syntax of sexps, including escape sequences and comments. [`tracing']: Tracing library Utilities for creating and parsing traces in Fuchsia Trace Format. [`username_kernel']: An identifier for a user A string representation for a user, typically a UNIX username [`abstract_algebra'] <https://github.com/janestreet/abstract_algebra> [`async_rpc_websocket'] <https://github.com/janestreet/async_rpc_websocket> [`bigdecimal'] <https://github.com/janestreet/bigdecimal> [`cohttp_async_websocket'] <https://github.com/janestreet/cohttp_async_websocket> [`cohttp_static_handler'] <https://github.com/janestreet/cohttp_static_handler> [`core_compat'] <https://github.com/janestreet/core_compat> [`env_config'] <https://github.com/janestreet/env_config> [`file_path'] <https://github.com/janestreet/file_path> [`fuzzy_match'] <https://github.com/janestreet/fuzzy_match> [`fzf'] <https://github.com/janestreet/fzf> [`hardcaml_c'] <https://github.com/janestreet/hardcaml_c> [`hardcaml_circuits'] <https://github.com/janestreet/hardcaml_circuits> [`hardcaml_fixed_point'] <https://github.com/janestreet/hardcaml_fixed_point> [`hardcaml_of_verilog'] <https://github.com/janestreet/hardcaml_of_verilog> [`hardcaml_step_testbench'] <https://github.com/janestreet/hardcaml_step_testbench> [`hardcaml_verify'] <https://github.com/janestreet/hardcaml_verify> [`hardcaml_verilator'] <https://github.com/janestreet/hardcaml_verilator> [`hardcaml_xilinx'] <https://github.com/janestreet/hardcaml_xilinx> [`hardcaml_xilinx_components'] <https://github.com/janestreet/hardcaml_xilinx_components> [`hex_encode'] <https://github.com/janestreet/hex_encode> [`hg_lib'] <https://github.com/janestreet/hg_lib> [`int_repr'] <https://github.com/janestreet/int_repr> [`jsonaf'] <https://github.com/janestreet/jsonaf> [`krb'] <https://github.com/janestreet/krb> [`magic-trace'] <https://github.com/janestreet/magic-trace> [`ocaml-embed-file'] <https://github.com/janestreet/ocaml-embed-file> [`ocaml_intrinsics'] <https://github.com/janestreet/ocaml_intrinsics> [`ocaml-probes'] <https://github.com/janestreet/ocaml-probes> [`ppx_css'] <https://github.com/janestreet/ppx_css> [`ppx_disable_unused_warnings'] <https://github.com/janestreet/ppx_disable_unused_warnings> [`ppx_ignore_instrumentation'] <https://github.com/janestreet/ppx_ignore_instrumentation> [`ppx_jsonaf_conv'] <https://github.com/janestreet/ppx_jsonaf_conv> [`ppx_typed_fields'] <https://github.com/janestreet/ppx_typed_fields> [`ppx_type_directed_value'] <https://github.com/janestreet/ppx_type_directed_value> [`profunctor'] <https://github.com/janestreet/profunctor> [`redis-async'] <https://github.com/janestreet/redis-async> [`sexp_diff'] <https://github.com/janestreet/sexp_diff> [`sexp_grammar'] <https://github.com/janestreet/sexp_grammar> [`sexp_string_quickcheck'] <https://github.com/janestreet/sexp_string_quickcheck> [`tracing'] <https://github.com/janestreet/tracing> [`username_kernel'] <https://github.com/janestreet/username_kernel> EmelleTV Show - 2022 ════════════════════ Archive: <https://discuss.ocaml.org/t/emelletv-show-2022/9613/1> David Sancho announced ────────────────────── I'm creating a post as a header from this season of *EmelleTV* in 2020. Will use this post to share announcements, new shows, gather feedback and invite you to watch and follow [https://www.twitch.tv/emelletv]! For the ones who doesn't know us, It's a streaming show that will happen once per month and will try to interview and talk casually about OCaml, Reason, ReScript and their communities. Inviting interesting engineers and ask silly questions about literally anything. If can't attend live, we publish the VOD in youtube under [https://www.youtube.com/channel/UCvVVfCa7-nzSuCdMKXnNJNQ]. You can re-watch some of the 2021 interviews, they were a ton of fun for me. It's made by myself and @fakenickels. Feel free to share any feedback, propose any guest or make fun of us ^^ [https://www.twitch.tv/emelletv] <https://www.twitch.tv/emelletv> [https://www.youtube.com/channel/UCvVVfCa7-nzSuCdMKXnNJNQ] <https://www.youtube.com/channel/UCvVVfCa7-nzSuCdMKXnNJNQ> Open source editor for iOS, iPadOS and macOS ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/open-source-editor-for-ios-ipados-and-macos/7624/21> Nathan Fallet announced ─────────────────────── Just released the app on the Play Store for Android: [Play Store] Feel free to give your feedback as well. I tried to make it like the iOS/macOS version. For now, the only missing feature is syntax highlighting, but I'm working on it (I still have a few bugs with it) [Play Store] <https://play.google.com/store/apps/details?id=me.nathanfallet.ocaml> The mysterious pointer in the runtime closure representation ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/the-mysterious-pointer-in-the-runtime-closure-representation/9560/7> Deep in this thread, Yue Li Picasso announced ───────────────────────────────────────────── Thanks for your replies @silene @zozozo ! Due to project interest I need to understand the runtime value representation. Now I released a little library for displaying runtime values in textual form: [OInspect]. [OInspect] <https://github.com/YueLiPicasso/OInspect> Other OCaml News ════════════════ From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [MirageOS 4 Released!] • [PhD Position at CEA LIST - LSL] • [All your metrics belong to influx] • [Secure Virtual Messages in a Bottle with SCoP] • [Research internships in our Tools and Compilers group] [OCaml Planet] <http://ocaml.org/community/planet/> [MirageOS 4 Released!] <https://tarides.com/blog/2022-03-29-mirageos-4-released> [PhD Position at CEA LIST - LSL] <http://frama-c.com/jobs/2022-03-28-machine-learning-for-improving-formal-verification-of-code.html> [All your metrics belong to influx] <https://hannes.nqsb.io/Posts/Monitoring> [Secure Virtual Messages in a Bottle with SCoP] <https://tarides.com/blog/2022-03-08-secure-virtual-messages-in-a-bottle-with-scop> [Research internships in our Tools and Compilers group] <https://blog.janestreet.com/research-internships-tnc/> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 33080 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 14034 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 05 to 12, 2022. Table of Contents ───────────────── LexiFi is hiring! Développeur principal à plein temps d'Alt-Ergo chez OCamlPro Using an external JavaScript file in js_of_ocaml diskuvbox: small set of cross-platform CLI tools Old CWN LexiFi is hiring! ═════════════════ Archive: <https://discuss.ocaml.org/t/job-fulltime-internship-paris-lexifi-is-hiring/9648/1> Alain Frisch announced ────────────────────── 📢 [LexiFi] is hiring! ✔️ Software Engineer (full-time): <https://lnkd.in/evhkxTg> ✔️ Software Development Internship: <https://lnkd.in/gb-bdDA9> LexiFi is a software editor, based in Paris. We have been happily using OCaml 🐪 for more than 20 years in our entire software stack, from backend components to UI (web & native) front-end, and we contribute back to the OCaml community (check out our blog post : <https://www.lexifi.com/blog/ocaml/ocaml-open-source/>) Don't hesitate to contact me directly if you want to learn more about the positions before applying! [LexiFi] <https://www.lexifi.com> Développeur principal à plein temps d'Alt-Ergo chez OCamlPro ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-fulltime-paris-developpeur-principal-a-plein-temps-dalt-ergo-chez-ocamlpro/9660/1> Fabrice Le Fessant announced ──────────────────────────── Alt-Ergo est l'un des solveurs SMT les plus efficaces pour la vérification formelle de code. Il est ainsi utilisé derrière des ateliers tels que Why3, Frama-C et Spark. Initialement développé par Sylvain Conchon au LRI, il est aujourd'hui maintenu par OCamlPro, grâce aux financements du Club Alt-Ergo (AdaCore, Trust-in-Soft, Thalès, MERCE, CEA List), à des contrats bilatéraux d'évolution et à des projets collaboratifs. OCamlPro souhaite aujourd'hui recruter un développeur principal à temps plein pour Alt-Ergo, pour compléter son équipe méthodes formelles et accélérer l'évolution d'Alt-Ergo. Disposant d'une expérience dans les méthodes formelles, ses missions seront : • de découvrir le projet Alt-Ergo et tous ses composants (prouveur, interface graphique, etc.) et d'en comprendre le fonctionnement à travers l'exploration du code et la lecture d'articles scientifiques; • d'élaborer la roadmap de maintenance évolutive d'Alt-Ergo, en collaboration avec les membres du Club Alt-Ergo, et de proposer des améliorations qui pourront être financées au travers de contrats bilatéraux ou de projets collaboratifs; • de participer avec l'équipe à la maintenance corrective d'Alt-Ergo et de fournir du support aux membres du Club Alt-Ergo; • de participer à l'encadrement de stages et de thèses CIFRE autour d'Alt-Ergo et des solveurs SMT en général; • de suivre l'actualité des solveurs SMTs et des travaux scientifiques connexes, et de maintenir des collaborations avec les experts académiques du domaine; Intégré au sein de l'équipe Méthodes Formelles d'OCamlPro, il bénéficiera de leur expérience et leur fera bénéficier de son expertise croissante dans l'utilisation d'Alt-Ergo. Outre la maintenance d'Alt-Ergo, l'équipe Méthodes Formelles d'OCamlPro participe à diverses activités: • Développement d'outils open-source pour les méthodes formelles, tels que Dolmen, Matla, etc. • Expertises sur WhyML, TLA, Coq, et autres langages de spécification et de vérification; • Certification de logiciels pour les Critères Communs (EAL6 et plus) • Spécification et vérification formelle de smart contracts (Solidity, etc.) Les bureaux d'OCamlPro sont dans le 14ème arrondissement de Paris (Alésia). L'entreprise est connue pour son équipe sympathique, son excellence technique, sa productivité, ses valeurs et son éthique. Si ce poste vous intéresse, n'hésitez pas à envoyer votre CV à: contact@ocamlpro.com Pour plus d'informations sur OCamlPro: <https://www.ocamlpro.com/> Pour plus d'informations sur Alt-Ergo: <https://alt-ergo.ocamlpro.com/> Pour plus d'informations sur le Club Alt-Ergo: <https://www.ocamlpro.com/club-alt-ergo> Using an external JavaScript file in js_of_ocaml ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/using-an-external-javascript-file-in-js-of-ocaml/9661/1> John Whitington asked ───────────────────── I am a beginner at both Javascript and `js_of_ocaml', so I may be mixing up all sorts of mistakes and misconceptions here. I have compiled up an existing project, my command line PDF tools, using `js_of_ocaml', and all is well: ┌──── │ $ node cpdf.js -info hello.pdf │ Encryption: Not encrypted │ Permissions: │ Linearized: false │ Version: 1.1 │ Pages: 1 └──── Like magic! But I had to comment out the parts of my code which use external C code of course - that is zlib and some encryption primitives. So now I wish to bind javascript libraries for those. I am experimenting with a simple library of my own, first, which is given on the command line to `js_of_ocaml' as `foomod.js': ┌──── │ foo = 42; └──── I can get to this global variable easily from OCaml: ┌──── │ let foo = Js.Unsafe.global##.foo └──── But now I want to do things better, and I change `foomod.js' to: ┌──── │ exports.foo = 42; └──── How can I get to that? Giving `foomod.js' on the `js_of_ocaml' command line includes the contents of `foomod.js' in some way, but does not contain the string `foomod', so I'm not sure how to get to the foomod's variables and functions. How to I access them? In the node REPL, I can simply do: ┌──── │ > foomod = require('./foomod.js'); │ { foo; 42 } │ > foomod.foo; │ 42 └──── I have read the `js_of_ocaml' help page on how to bind JS modules: <https://ocsigen.org/js_of_ocaml/latest/manual/bindings> I imagine if I could get over this hump, all the rest of the information I need will be there. Nicolás Ojeda Bär replied ───────────────────────── Not exactly what you asked, but if you just want to provide a JS version of some C primitive ┌──── │ external foo : unit -> int = "caml_foo" └──── you can do this by writing the following in your `.js' file: ┌──── │ //Provides: caml_foo │ function caml_foo() { │ return 42; │ } └──── Then `js_of_ocaml' will automatically replace calls to the external function by a call to its JS implementation. This is the same mechanism used by `js_of_ocaml' to implement its own JS version of the OCaml runtime, see eg <https://github.com/ocsigen/js_of_ocaml/blob/3850a67b1cb00cfd2ee4399cf1e2948062884b92/runtime/bigarray.js#L328-L335> diskuvbox: small set of cross-platform CLI tools ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-diskuvbox-small-set-of-cross-platform-cli-tools/9663/1> jbeckford announced ─────────────────── *TLDR*: ┌──── │ $ opam update │ $ opam install diskuvbox │ │ $ diskuvbox copy-dir --mode 755 src1/ src2/ dest/ │ $ diskuvbox copy-file --mode 400 src/a dest/b │ $ diskuvbox copy-file-into src1/a src2/b dest/ │ $ diskuvbox touch-file x/y/z │ │ $ diskuvbox find-up . _build │ Z:/source/_build │ │ $ diskuvbox tree --max-depth 2 --encoding=UTF-8 . │ . │ ├── CHANGES.md │ ├── README.md │ ├── _build/ │ │ ├── default/ │ │ ├── install/ │ │ └── log └──── *Problem*: When writing cram tests, Dune rules and Opam build steps, often we default to using GNU binaries (`/usr/bin/*') available on Linux (ex. `/usr/bin/cp -R'). Unfortunately these commands rarely work on Windows, and as a consequence Windows OCaml developers are forced to maintain Cygwin or MSYS2 installations to get GNU tooling. *Solution*: Provide some of the same functionality for Windows and macOS that the GNU binaries in `/usr/bin/*' do in Linux. `diskuvbox' is a single binary that today provides an analog for a very small number of binaries that I have needed in the Diskuv Windows OCaml distribution. It is liberally licensed under Apache v2.0. *With your PRs it could emulate much more!* `diskuvbox' has CI testing for Windows, macOS and Linux. Usage and help are available in the diskuvbox README: <https://github.com/diskuv/diskuvbox#diskuv-box> *`diskuvbox' also has a OCaml library, but consider the API unstable until version 1.0.* Alternatives: • There are some shell scripting tools like [shexp] and [feather] that give you POSIX pipes in OCaml-friendly syntax. I feel these complement Diskuv Box. • Dune exposes `(copy)' to copy a file in Dune rules; theoretically more operations could be added. Internally `diskuvbox' is a wrapper on the excellent [bos - Basic OS interaction] library. [shexp] <https://github.com/janestreet/shexp> [feather] <https://github.com/charlesetc/feather> [bos - Basic OS interaction] <https://erratique.ch/software/bos/doc/Bos/index.html> Acknowledgements ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The first implementations of Diskuv Box were implemented with the assistance of the [OCaml Software Foundation (OCSF)], a sub-foundation of the [INRIA Foundation]. Two OCaml libraries ([bos] and [cmdliner]) are essential to Diskuv Box; these libraries were created by [Daniel Bünzli] (@dbuenzli) . [OCaml Software Foundation (OCSF)] <http://ocaml-sf.org> [INRIA Foundation] <https://www.inria.fr> [bos] <https://erratique.ch/software/bos> [cmdliner] <https://erratique.ch/software/cmdliner> [Daniel Bünzli] <https://erratique.ch/profile> Examples ╌╌╌╌╌╌╌╌ The following are examples that have been condensed from the [diskuvbox README.md] … [diskuvbox README.md] <https://github.com/diskuv/diskuvbox#diskuv-box> Using in Dune cram tests ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┌──── │ $ install -d a/b/c/d/e/f │ $ install -d a/b2/c2/d2/e2/f2 │ $ install -d a/b2/c3/d3/e3/f3 │ $ install -d a/b2/c3/d4/e4/f4 │ $ install -d a/b2/c3/d4/e5/f5 │ $ install -d a/b2/c3/d4/e5/f6 │ $ touch a/b/x │ $ touch a/b/c/y │ $ touch a/b/c/d/z │ │ $ diskuvbox tree a --max-depth 10 --encoding UTF-8 │ a │ ├── b/ │ │ ├── c/ │ │ │ ├── d/ │ │ │ │ ├── e/ │ │ │ │ │ └── f/ │ │ │ │ └── z │ │ │ └── y │ │ └── x │ └── b2/ │ ├── c2/ │ │ └── d2/ │ │ └── e2/ │ │ └── f2/ │ └── c3/ │ ├── d3/ │ │ └── e3/ │ │ └── f3/ │ └── d4/ │ ├── e4/ │ │ └── f4/ │ └── e5/ │ ├── f5/ │ └── f6/ └──── Using in Opam `build' steps ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┌──── │ build: [ │ ["diskuvbox" "copy-file-into" "assets/icon.png" "assets/public.gpg" "%{_:share}%"] │ ] └──── Using in Dune rules ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┌──── │ (rule │ (targets diskuvbox.corrected.ml diskuvbox.corrected.mli) │ (deps │ (:license %{project_root}/etc/license-header.txt) │ (:conf %{project_root}/etc/headache.conf)) │ (action │ (progn │ (run diskuvbox copy-file -m 644 diskuvbox.ml diskuvbox.corrected.ml) │ (run diskuvbox copy-file -m 644 diskuvbox.mli diskuvbox.corrected.mli) │ (run headache -h %{license} -c %{conf} %{targets}) │ (run ocamlformat --inplace --disable-conf-files --enable-outside-detected-project %{targets})))) └──── 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 25501 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 9483 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 12 to 19, 2022. Table of Contents ───────────────── Lwt informal user survey pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications Creating a library for use from JS with js_of_ocaml ocaml-lsp-server 1.11.0 OCaml summer school in Spain, call for industry speakers Dune 3.1.0 Old CWN Lwt informal user survey ════════════════════════ Archive: <https://discuss.ocaml.org/t/lwt-informal-user-survey/9666/1> Raphaël Proust announced ──────────────────────── In order to make some decisions relating to the maintenance of Lwt, I'd like to know a little bit more about how the library is used in the wild. Do not hesitate to respond to the poll and/or as a message in this thread, or even to contact me via other means in case discuss is not your jam. /Editor’s note: please follow the link above to reply to the survey./ pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications ════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-pyml-bindgen-a-cli-app-to-generate-python-bindings-directly-from-ocaml-value-specifications/8786/7> Continuing this thread, Ryan Moore announced ──────────────────────────────────────────── I wrote a [blog post] providing an introduction to `pyml_bindgen'. It gives an intro in a slightly different style as compared to the [docs] and the [examples], and includes some of the latest features I've been working on. [blog post] <https://www.tenderisthebyte.com/blog/2022/04/12/ocaml-python-bindgen/> [docs] <https://mooreryan.github.io/ocaml_python_bindgen/> [examples] <https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples> Creating a library for use from JS with js_of_ocaml ═══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/creating-a-library-for-use-from-js-with-js-of-ocaml/9523/5> Deep in this thread, threepwood said ──────────────────────────────────── Cautionary note for anyone reading this in the future: dynamic imports are asynchronous, and initializing the jsoo runtime takes some milliseconds, so that if you just do: ┌──── │ import("ocaml/export.bc.js"); │ var x = mylib.myfunction(); └──── the second line will fail as `mylib' is not defined yet (at least this is what I think is happening). You need to guarantee the module is done initializing in some way or other. Kim Nguyễn then said ──────────────────── `import' should return a promise of the loaded module. So you can just `await' for it (if your current context allows you to write `await') or just : ┌──── │ import("ocaml/export.bc.js").then ((_) => { │ │ mylib.myfunction(); │ │ }); └──── ocaml-lsp-server 1.11.0 ═══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-11-0/9677/1> Rudi Grinberg announced ─────────────────────── On behalf of the ocamllsp team, I'm excited to announce the availability of version 1.11.0. This release is an important milestone for the project because it introduces integration with our favorite build system. When you run dune in watch mode, you will now be able to see build errors in the diagnostics panel of your editor. It's all rather experimental for now, so your feedback and bug reports are appreciated. As usual, the full change log is below. Happy hacking. *1.11.0* Features ╌╌╌╌╌╌╌╌ • Add support for dune in watch mode. The lsp server will now display build errors in the diagnostics and offer promotion code actions. • Re-introduce ocamlformat-rpc (#599, fixes #495) Fixes ╌╌╌╌╌ • Fix workspace symbols that could have a wrong path in some cases ([#675]) [#675] <https://github.com/ocaml/ocaml-lsp/pull/671> OCaml summer school in Spain, call for industry speakers ════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-summer-school-in-spain-call-for-industry-speakers/9685/1> Roberto Blanco announced ──────────────────────── Dear all, Ricardo Rodríguez and I are organizing an introductory OCaml course as part of the annual summer school of the University of Zaragoza in Spain. (This is the oldest summer university in the country, nearing its centennial anniversary!). The country's computing programs are quite excellent, although we have found them to generally not pay serious attention to modern functional programming. Our goal is to use OCaml to begin to address this dearth. In addition to the regular academic program we are planning a satellite event open to the general public. This is meant to introduce the OCaml ecosystem to a wider audience of students and academics, as well as professionals. As part of this, we would like to hold a round table discussion of industrial OCaml users to demonstrate the width and depth of practical uses of the language. There will be time for participants to present their work in more detail, if they wish to do so. If you may be interested in participating or have any questions, feel free to write to me here or send email to either of us. The course is currently in its planning stages; it is scheduled to take place in early to mid July, in all likelihood in the city of Zaragoza and in hybrid format. The OCaml Software Foundation is backing the initiative and we thank them for their generous support. Updated information about the course will be available on its website: <https://webdiis.unizar.es/evpf/> Dune 3.1.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-1-0/9690/1> Rudi Grinberg announced ─────────────────────── On behalf of the dune team, I'm pleased to announce version 3.1.0. This release contains some small, but interesting features, and some important quality of life bug fixes. I encourage everyone to upgrade as soon as possible. Happy Hacking. *3.1.0 (15/04/2022)* • Add `sourcehut' as an option for defining project sources in dune-project files. For example, `(source (sourcehut user/repo))'. (#5564, @rgrinberg) • Add `dune coq top' command for running a Coq toplevel (#5457, @rlepigre) • Fix dune exec dumping database in wrong directory (#5544, @bobot) • Always output absolute paths for locations in RPC reported diagnostics (#5539, @rgrinberg) • Add `(deps <deps>)' in ctype field (#5346, @bobot) • Add `(include <file>)' constructor to dependency specifications. This can be used to introduce dynamic dependencies (#5442, @anmonteiro) • Ensure that `dune describe' computes a transitively closed set of libraries (#5395, @esope) • Add direct dependencies to $ dune describe output (#5412, @esope) • Show auto-detected concurrency on Windows too (#5502, @MisterDA) • Fix operations that remove folders with absolute path. This happens when using esy (#5507, @EduardoRFS) • Dune will not fail if some directories are non-empty when uninstalling. (#5543, fixes #5542, @nojb) • `coqdep' now depends only on the filesystem layout of the .v files, and not on their contents (#5547, helps with #5100, @ejgallego) • The mdx stanza 0.2 can now be used with `(implicit_transitive_deps false)' (#5558, fixes #5499, @emillon) • Fix missing parenthesis in printing of corresponding terminal command for `(with-outputs-to )' (#5551, fixes #5546, @Alizter) 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 20212 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 9882 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 19 to 26, 2022. Table of Contents ───────────────── Multicore OCaml: March 2022 OUPS meetup may 2022 (french only) JFLA 2022: Call for Participation (in French) Old CWN Multicore OCaml: March 2022 ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/multicore-ocaml-march-2022/9692/1> Anil Madhavapeddy announced ─────────────────────────── Welcome to the March 2022 [Multicore OCaml] monthly report! This update along with the [previous updates] have been compiled by me, @ctk21, @kayceesrk and @shakthimaan. We have continued steadily towards making a stable OCaml 5.0 release, as you can see from the long list of fixes later – thank you for all your contributions! Platform configurations that were formerly supported in the 4.x branches for OpenBSD, FreeBSD, and NetBSD have now been re-enabled. ARM64 support (for macOS, Linux and the BSDs) is stable in trunk, and ARM CFI integration has been merged as a follow-up to facilitate debugging and profiling. Notably, this also includes [memory model tests for ARMv8 and Power ports]. The Windows mingw64 port is also working again in trunk. An [effects tutorial] has also been contributed to the OCaml manual; feedback continues to be welcome even after it's merged in. As you experiment with effects, please do continue to post to this forum with questions or comments about your learnings. The Sandmark benchmark project has added bytecode analysis to address any performance regressions. We have also been working on obtaining measurements for the compilation data points. The current-bench pipeline production deployments has significant UI changes, and now has alert notifications for the benchmark runs. As always, the Multicore OCaml open and completed tasks are listed first, which are then followed by the ecosystem tooling projects. The Sandmark, sandmark-nightly, and current-bench project updates are finally presented for your reference. /Editor’s note: please find the full changelog following the archive link above./ [Multicore OCaml] <https://github.com/ocaml-multicore/ocaml-multicore> [previous updates] <https://discuss.ocaml.org/tag/multicore-monthly> [memory model tests for ARMv8 and Power ports] <https://github.com/ocaml/ocaml/pull/11004> [effects tutorial] <https://github.com/ocaml/ocaml/pull/11093> OUPS meetup may 2022 (french only) ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/oups-meetup-may-2022-french-only/9715/1> zapashcanon announced ───────────────────── Le prochain OUPS aura lieu le *jeudi 12 mai* 2022. Le rendez-vous est fixé à *19h* en *salle 15-16 101* , *4 place Jussieu* , 75005 Paris. *L'inscription est obligatoire* pour pouvoir accéder au meetup ! Votre nom complet doit être disponible. L'inscription s'effectue sur [meetup]. Toutes les informations sont disponibles sur [le site du oups]. J'aimerais aussi signaler que les slides et vidéos des exposés passés [sont maintenant disponibles] ! :partying_face: *Programme* [meetup] <https://www.meetup.com/fr-FR/ocaml-paris> [le site du oups] <https://oups.frama.io> [sont maintenant disponibles] <https://oups.frama.io/past.html> Gospel & Ortac - Clément Pascutto ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Gospel is a behavioural specification language for OCaml program. It provides developers with a non-invasive and easy-to-use syntax to annotate their module interfaces with formal contracts that describe type invariants, mutability, function pre-conditions and post-conditions, effects, exceptions, and [much more]! ortac: OCaml Runtime Assertion Checking. [much more] <https://ocaml-gospel.github.io/gospel/> MirageOS 4 - Romain Calascibetta ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ MirageOS 4 vient de sortir récemment et c'est l'occasion de (re)présenter ce projet permettant de construire des unikernels. Nous y présenterons les nouvelles features et possibilités et nous ferons une introspection de 3 ans de travail de l'équipe core. Tezt: OCaml Tezos Test Framework - Romain Bardou ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Tezt is a test framework for OCaml. It is well suited for unit and regression tests and particularly shines for integration tests, i.e. tests that launch external processes. It was made with a focus on user experience. It allows you to easily select tests from the command-line and provides pretty logs. It also can run tests in parallel, automatically split the set of tests into several well-balanced batches to be run in parellel CI jobs, produce JUnit outputs, and more. It has been in use at Nomadic for the last 2 years and is thus quite battle-tested. JFLA 2022: Call for Participation (in French) ═════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-04/msg00008.html> Timothy Bourke announced ──────────────────────── [ This message is intentionally written in French. It is a call for participation for the "Francophone Days on Functional Languages" to be held, finally and fingers crossed, at the end of June. Some of the articles are written in English. They are available online: <https://hal.inria.fr/JFLA2022/> ] *Merci de faire circuler : premier appel à participation* JFLA'2022 (<http://jfla.inria.fr/jfla2022.html>) Journées Francophones des Langages Applicatifs Saint-Médard-d'Excideuil - du 28 juin au 1er juillet 2022 Les inscriptions aux JFLA 2022 - en présence ! - sont désormais ouvertes : <https://www.azur-colloque.fr/DR04/inscription/preinscription/203/fr> Ces journées réunissent concepteurs, utilisateurs et théoriciens ; elles ont pour ambition de couvrir les domaines des langages applicatifs, de la preuve formelle, de la vérification de programmes, et des objets mathématiques qui sous-tendent ces outils. Ces domaines doivent être pris au sens large : nous souhaitons promouvoir les ponts entre les différentes thématiques. L'inscription est un forfait qui comprend notamment l'hébergement en pension complète sur le site des journées : • participant·e plein tarif, chambre simple : 660 euros • étudiant·e orateur·ice, en chambre double : 0 euro Nous espérons que vous serez nombreux à participer à ces journées. Inscrivez-vous dès que possible ! En particulier, les étudiant·es orateur·ices sont invité·es à s'inscrire, même s'ils ne paient pas grâce à nos sponsors. Vous pouvez d'ores et déjà vous inscrire au salon de discussion framateam afin d'échanger ensemble : <https://framateam.org/signup_user_complete/?id=gnbebtncubnbpe96ok9kam8t9y> Tout le programme est à retrouver ici : <http://jfla.inria.fr/jfla2022.html> Dates importantes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • 17 juin 2022 : date limite d'inscription aux journées • 28 juin au 1er juillet 2022 : journées Cours invités ╌╌╌╌╌╌╌╌╌╌╌╌╌ • Delphine Demange (IRISA, Université de Rennes 1) "Si2-FIP: Programmation Fonctionnelle en Licence 1 avec Scala" • Denis Mérigoux (Inria) "Rust pour le formaliste impatient" Exposé invité ╌╌╌╌╌╌╌╌╌╌╌╌╌ • Matthias Puech (INA GRM) Titre à venir - avec une surprise ! Articles acceptés ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ L'ensemble des articles acceptés est disponible sous forme d'une collection HAL : <https://hal.inria.fr/JFLA2022> Comité de programme ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Chantal Keller LMF, Université Paris-Saclay (Présidente) • Timothy Bourke Inria, ÉNS de Paris (Vice-président) • Sandrine Blazy Irisa, Université Rennes 1 • Frédéric Bour Tarides - Inria • Guillaume Bury OcamlPro • Stefania Dumbrava Samovar, ENSIIE, Télécom Sud Paris • Diane Gallois-Wong Nomadic Labs • Adrien Guatto IRIF, Université de Paris • David Janin LaBRI, Université de Bordeaux • Marie Kerjean LIPN, Université Paris 13 • Luc Pellissier LACL, Université Paris-Est Créteil • Mário Pereira NOVA-LINCS, Universidade Nova de Lisboa • Alix Trieu Aarhus University • Yannick Zakowski LIP, Inria, ÉNS de Lyon 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 20509 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 15706 bytes --] Hello Here is the latest OCaml Weekly News, for the week of April 26 to May 03, 2022. Table of Contents ───────────────── ATD now supports TypeScript pp_loc 2.0 Windows-friendly OCaml 4.12 distribution - Diskuv OCaml 0.1.0 V3.ocaml.org: we are live! Remaking an Old Game in OCaml Old CWN ATD now supports TypeScript ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/atd-now-supports-typescript/9735/1> Martin Jambon announced ─────────────────────── [ATD] is a language for specifying typed interfaces for communicating across programming languages. It turns concrete type definitions ("schema") into code for each language. This code can read and write JSON safely, relieving the user of worrying about the structure of the JSON data. Starting from version 2.5.0, ATD provides `atdts', a single executable that turns a file `foo.atd' into `foo.ts'. See the [tutorial] for an introduction. The programming languages targeted by ATD are now: • Java • OCaml • Python + mypy • ReScript (BuckleScript) • Scala • TypeScript For an expert overview of the features that are currently supported, check out the test data: • [ATD input] • [TypeScript output] See also the [announcement for atdpy] that we made a month ago. [ATD] <https://github.com/ahrefs/atd> [tutorial] <https://atd.readthedocs.io/en/latest/atdts.html#tutorials> [ATD input] <https://github.com/ahrefs/atd/blob/master/atdts/test/atd-input/everything.atd> [TypeScript output] <https://github.com/ahrefs/atd/blob/master/atdts/test/ts-expected/everything.ts> [announcement for atdpy] <https://discuss.ocaml.org/t/atdpy-derive-safe-json-interfaces-for-python/9544> pp_loc 2.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-pp-loc-2-0/9741/1> Armael announced ──────────────── Do you know how OCaml now displays errors by quoting back part of the source, highlighting the faulty part? For instance, with a single-line error location: ┌──── │ File "foo.ml", line 1, characters 12-14: │ 1 | let foo x = yy + 1;; │ ^^ └──── or a multi-line location: ┌──── │ File "bar.ml", lines 3-5, characters 10-10: │ 3 | ..........function │ 4 | | A -> 0 │ 5 | | B -> 1 └──── Do you have your own language/configuration file/… parser or typechecker, that could benefit from nice, user-friendly error messages? The [pp_loc] library provides an easy-to-use implementation of the same source-quoting mechanism that is used in the OCaml compiler. It provides a single function `pp' which will display the relevant part of the input given the location(s) of the error. ┌──── │ val pp : │ ?max_lines:int -> │ input:Input.t -> │ Format.formatter -> │ loc list -> │ unit └──── (As one can see from the signature, `pp' also supports displaying several locations at once on the same source snippet, for multi-location errors.) The full [documentation is available online], and the library is available on opam (`opam install pp_loc'). This new version, thanks to the contribution of @c-cube, makes the `loc' type more flexible. It should now be easy to create source locations that can be passed to `pp', however you represent them in your parser (be it as (line,column) pairs, offsets, or any combination of those…). For more details, see the [Pp_loc.Position] module. I am completely open to more PRs or ideas for improving the library further, and displaying source locations in even nicer ways! Happy error-message printing! [pp_loc] <https://github.com/Armael/pp_loc> [documentation is available online] <https://armael.github.io/pp_loc/pp_loc/Pp_loc/index.html> [Pp_loc.Position] <https://armael.github.io/pp_loc/pp_loc/Pp_loc/Position/index.html> Windows-friendly OCaml 4.12 distribution - Diskuv OCaml 0.1.0 ═════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-windows-friendly-ocaml-4-12-distribution-diskuv-ocaml-0-1-0/8358/18> jbeckford announced ─────────────────── A single `setup-*.exe' executable is now all that is necessary to install the Diskuv OCaml distribution on 64-bit Windows! Today you can use a prerelease of v0.4.0 which is available at <https://github.com/diskuv/dkml-installer-ocaml/releases/download/v0.4.0-prerel11/setup-diskuv-ocaml-windows_x86_64-0.4.0.exe> The prerelease: • is for *experienced Windows users only* because the prerelease is not signed! You will have to fight with your browser, operating system and anti-virus software to run the setup executable • is *not reproducible*. Because many Diskuv packages have not yet made it into Opam, the builds need several `opam pin' of unstable branches. • has not been incorporated into the <https://diskuv.gitlab.io/diskuv-ocaml> documentation site. But the [Beyond Basics] documentation should still be accurate. Once those items above are addressed, a real (non-prerelease) 0.4.0 will be announced. Existing Diskuv OCaml users: Your existing Opam switches should be unaffected by the upgrade. But please make sure you can recreate your Opam switches (ie. use a `.opam' file) if something goes wrong. Release notes, including details of the migration to the Apache 2.0 license, are at available at [https://github.com/diskuv/dkml-installer-ocaml/releases/tag/v0.4.0-prerel11] [Beyond Basics] <https://diskuv.gitlab.io/diskuv-ocaml/doc/BeyondBasics.html#beyondbasics> [https://github.com/diskuv/dkml-installer-ocaml/releases/tag/v0.4.0-prerel11] <https://github.com/diskuv/dkml-installer-ocaml/releases/tag/v0.4.0-prerel11> V3.ocaml.org: we are live! ══════════════════════════ Archive: <https://discuss.ocaml.org/t/v3-ocaml-org-we-are-live/9747/1> Thibaut Mattio announced ──────────────────────── I am thrilled to announce that <https://ocaml.org/> now serves version 3 of the site! Here's an overview of the major features in this new version: • [Central OCaml package documentation], which contains the documentation of every version of every OCaml packages. • [OCaml job board], which lists job opportunities from the community. • [A syndicated blog], which links to blog articles from the community and offers original blog posts. • [OCaml success stories] which explore how major OCaml industrial users solved real-world challenges using OCaml. • [Resources for learning OCaml], which aggregates resources and tutorials to learn OCaml. • [An interactive OCaml playground] to try OCaml code directly in the browser. Version 2 remains accessible at <https://v2.ocaml.org/>, and older URLs to ocaml.org will be redirected to the v2 URL from now on. Similarly, v3.ocaml.org URLs will continue to work. Community feedback was instrumental and has been driving the direction of the project since day one. For instance, having a centralized package documentation site; or facilitating the hiring of OCaml developers and finding OCaml jobs were major concerns that were highlighted in the last [OCaml Survey]. They were what prompted us to work on the documentation site and the job board respectively. We've also listened to the community feedback we received along the way, and in particular, here's an overview of everything we've been doing to address the feedback we received after our last Discuss post: <https://hackmd.io/IniIM_p3Qs2UB74cuKK7UQ>. Given how critical your input is to drive the project, I am deeply grateful to every one who took the time to share insights, suggestions and bug reports. Some of the suggestions will need more work and couldn't happen before launch, but we've listened to every one and will keep working on improving OCaml.org to address pain points of the community. Thank you, and keep the feedback coming! We're also starting to see a lot of contributions from external contributors. OCaml.org is open source, and contributions from anyone are extremely welcome! Never hesitate to open a PR if you see something you'd like to improve! You can read our [Contributing Guide] to learn how to contribute. [Central OCaml package documentation] <https://ocaml.org/packages> [OCaml job board] <https://ocaml.org/opportunities> [A syndicated blog] <https://ocaml.org/blog> [OCaml success stories] <https://ocaml.org/success-stories> [Resources for learning OCaml] <https://ocaml.org/learn> [An interactive OCaml playground] <https://ocaml.org/play> [OCaml Survey] <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624> [Contributing Guide] <https://github.com/ocaml/ocaml.org/blob/main/CONTRIBUTING.md> Ecosystem Contributions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ As the storefront of the OCaml ecosystem, we couldn't develop the next version of OCaml.org without contributing back! As a result, we've published several packages on opam that we're using for OCaml.org: • [dream-accept]: Accept headers parsing for Dream • [dream-encoding]: Encoding primitives for Dream. • [hilite]: Generate HTML ready for syntax-highlighting with CSS by parsing markdown documents. Other packages that are yet to be released are: • [code-mirror]: The code-mirror bindings • [js_top_worker]: An OCaml toplevel designed to run in a web worker We've also made contributions downstream: • odoc: [Support for HTML fragments in odoc] • river: [API changes and capability to fetch metadata from RSS post links] A huge thank you to the community for your constant effort in making OCaml such a great language to work with! In particular, here are some amazing community projects we are building upon: [Dream], [Brr] and [Omd] and [many more] [dream-accept] <https://github.com/tmattio/dream-accept> [dream-encoding] <https://github.com/tmattio/dream-encoding> [hilite] <https://github.com/patricoferris/hilite> [code-mirror] <https://github.com/patricoferris/jsoo-code-mirror/tree/static> [js_top_worker] <https://github.com/jonludlam/js_top_worker> [Support for HTML fragments in odoc] <https://github.com/ocaml/odoc/pull/842> [API changes and capability to fetch metadata from RSS post links] <https://github.com/kayceesrk/river/pull/6> [Dream] <https://aantron.github.io/dream/> [Brr] <https://github.com/dbuenzli/brr> [Omd] <https://github.com/ocaml/omd> [many more] <https://github.com/ocaml/ocaml.org/blob/main/ocamlorg.opam> What's next? ╌╌╌╌╌╌╌╌╌╌╌╌ Launching the website is the first step on our roadmap to improve OCaml’s online presence. As mentioned above, the immediate goal is to be ready for this OCaml 5.00.0 release. With this in mind, we want to focus on improving the documentation and ensuring it includes good user pathways to learn about Domains, Effects, and generally how to write concurrent programs in OCaml. In addition to the documentation, some of the other projects on our roadmap are: • Toplevels for all the packages that compile to JavaScript. • Including OCaml Weekly News in the OCaml blog. • A better search through packages, documentation, and packages' documentation. This is an exciting time! Stay tuned! Call for maintainers ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ There's a lot of ways to contribute if you'd like to help. Our [contributing guide] should be a good entry point to learn what you can do as a community contributor. We're also looking for maintainers. As we're completing the first milestone with the launch and will start working on new projects, now is a great time to get involved! If you'd like to help on the initiatives on our roadmap above (or others!), feel free to reach out to me by email at thibaut@tarides.com, or by replying to this post. [contributing guide] <https://github.com/ocaml/ocaml.org/blob/main/CONTRIBUTING.md> Acknowledgements ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ This project was a huge effort that started over a year ago, and the result of dozens of [contributors]. We want to thank every one who contributed to the site. In particular, for the groundwork on rethinking the sitemap, user flows, new content, design, and frontend and package docs, we thank Ashish Agarwal, Kanishka Azimi, Richard Davison, Patrick Ferris, Gemma Gordon, Isabella Leandersson, Thibaut Mattio and Anil Madhavapeddy. For the work on the package site infrastructure and UI, we thank Jon Ludlam, Jules Aguillon and Lucas Pluvinage. And for the work on the designs and bringing them to life on the frontend, we thank Isabella Leandersson and Asaad Mahmood. For the work on the new content and reviewing the existing one, we thank Christine Rose and Isabella Leandersson. For the contributions on the content for Ahrefs, Jane Street and LexiFi respectively, we thank Louis Roché, James Somers, Nicolás Ojeda Bär. We’d also like to thank the major funders who supported the work on revamping the website: grants from the Tezos Foundation, Jane Street and Tarides facilitated the bulk of the work. Thank you, and if anyone else wishes to help support it on an ongoing basis then donations to the OCaml Software Foundation and grants to the maintenance teams mentioned above are always welcomed. [contributors] <https://github.com/ocaml/ocaml.org/graphs/contributors> Remaking an Old Game in OCaml ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/remaking-an-old-game-in-ocaml/9760/1> Yotam Barnoy announced ────────────────────── I've starting blogging about a [side-project of mine]. Hopefully I'll find the time to write some further entries in the series, including about reverse engineering a binary with IDA. [side-project of mine] <https://justabluddyblog.wordpress.com/2022/05/01/remaking-an-old-game-in-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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 26538 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1.1: Type: text/plain, Size: 1803 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 03 to 10, 2022. Table of Contents ───────────────── Multicore OCaml: March 2022 Old CWN Multicore OCaml: March 2022 ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/multicore-ocaml-march-2022/9692/3> Deep in this threal, KC Sivaramakrishnan announced ────────────────────────────────────────────────── The benchmarks from the "Retrofitting Effect handlers to OCaml" PLDI 2022 paper (<https://arxiv.org/abs/2104.00250>) is available here: <https://github.com/prismlab/retro-concurrency/tree/master/bench>. See sections 6.2 and 6.3 in the paper. He later added ────────────── I've moved the microbenchmarks alone to a separate repo: <https://github.com/prismlab/retro-concurrency-bench>. This repo also contains instructions to run the docker container that runs the benchmarks from the paper with the custom compiler variants. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #1.2: Type: text/html, Size: 10683 bytes --] [-- Attachment #2: Type: text/plain, Size: 119 bytes --] Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'INRIA.
[-- Attachment #1: Type: text/plain, Size: 8480 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 10 to 17, 2022. Table of Contents ───────────────── Browsing OCaml source tree with VSCode/merlin? release of prbnmcn-gnuplot 0.0.3 Call for Presentations for "Teaching Functional Programming in OCaml" as part of the OCaml Workshop 2022 Old CWN Browsing OCaml source tree with VSCode/merlin? ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/browsing-ocaml-source-tree-with-vscode-merlin/9819/2> Keigo Imai explained ──────────────────── I managed to browse the OCaml source tree with VSCode with the following steps: 1. Prepare `.merlin' file (attached below) referring to the all source directories in the tree 2. Pin your ocaml-lsp-server at 1.8.3 by `opam pin ocaml-lsp-server 1.8.3' (as it is the last version that support `.merlin') 3. Clone OCaml repository and check out the same OCaml version as yours (e.g. `opam switch create 4.12.1; git checkout 4.12.1') 4. Build OCaml (./configure && make world) 5. Open the top folder of the source tree using VSCode (or restart the language server) 6. Browse the code Cheers! content of `.merlin': ┌──── │ S ./asmcomp/ │ S ./boot/menhir/ │ S ./bytecomp/ │ S ./debugger/ │ S ./driver/ │ S ./file_formats/ │ S ./lambda/ │ S ./lex/ │ S ./middle_end/ │ S ./middle_end/closure/ │ S ./middle_end/flambda/ │ S ./middle_end/flambda/base_types/ │ S ./ocamldoc/ │ S ./ocamltest/ │ S ./otherlibs/dynlink/ │ S ./otherlibs/dynlink/byte/ │ S ./otherlibs/dynlink/dynlink_compilerlibs/ │ S ./otherlibs/dynlink/native/ │ S ./otherlibs/str/ │ S ./otherlibs/systhreads/ │ S ./otherlibs/unix/ │ S ./parsing/ │ S ./stdlib/ │ S ./tools/ │ S ./tools/unlabel-patches/ │ S ./toplevel/ │ S ./toplevel/byte/ │ S ./toplevel/native/ │ S ./typing/ │ S ./utils/ │ B ./asmcomp/ │ B ./asmcomp/debug/ │ B ./boot/ │ B ./bytecomp/ │ B ./debugger/ │ B ./driver/ │ B ./file_formats/ │ B ./lambda/ │ B ./lex/ │ B ./middle_end/ │ B ./middle_end/closure/ │ B ./middle_end/flambda/ │ B ./middle_end/flambda/base_types/ │ B ./ocamldoc/ │ B ./ocamldoc/generators/ │ B ./ocamltest/ │ B ./otherlibs/bigarray/ │ B ./otherlibs/dynlink/ │ B ./otherlibs/dynlink/byte/ │ B ./otherlibs/dynlink/dynlink_compilerlibs/ │ B ./otherlibs/dynlink/native/ │ B ./otherlibs/str/ │ B ./otherlibs/systhreads/ │ B ./otherlibs/unix/ │ B ./parsing/ │ B ./stdlib/ │ B ./testsuite/tests/no-alias-deps/ │ B ./tools/ │ B ./toplevel/ │ B ./toplevel/byte/ │ B ./toplevel/native/ │ B ./typing/ │ B ./utils/ └──── release of prbnmcn-gnuplot 0.0.3 ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-prbnmcn-gnuplot-0-0-3/9840/1> Igarnier announced ────────────────── [prbnmcn-gnuplot] is a declarative wrapper on top of [gnuplot]. Version 0.0.3 was just released. The API is not entirely set in stone but it's reasonably usable, at least for up to moderately sized plots. It proceeds by constructing self-contained gnuplot scripts from declarative specifications and deferring to gnuplot for execution. Here's the [documentation]. Happy hacking! [prbnmcn-gnuplot] <https://github.com/igarnier/prbnmcn-gnuplot> [gnuplot] <http://www.gnuplot.info/> [documentation] <https://igarnier.github.io/prbnmcn-gnuplot/> Call for Presentations for "Teaching Functional Programming in OCaml" as part of the OCaml Workshop 2022 ════════════════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/call-for-presentations-for-teaching-functional-programming-in-ocaml-as-part-of-the-ocaml-workshop-2022/9847/1> Yurug announced ─────────────── Special Session / Call for Presentations for "Teaching Functional Programming in OCaml" as part of the OCaml ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Workshop 2022 • Abstract Submission: 6 June 2022 • Author Notification: 7 July 2022 • OCaml Workshop: 9 Sept 2022 The OCaml Workshop 2022, co-located with ICFP 2022, will take place the 2022-09-16 and will be held at Ljubljana, Slovenia. This year, we would like to organize a special session on "Teaching Functional Programming in OCaml". Hence, we would like to encourage and invite submissions for presentations that highlight teaching practices and innovation that highlight how OCaml is taught around the globe and the wide range of tools and strategies that have been developed to teach effectively functional programming using OCaml. In particular, we are interested in automated program evaluation / grading tools / error analysis (both type and syntax errors) for OCaml programs, tools that provide assistance in practical lessons (such as pair programming for example), Jupiter notebooks like solutions to interactively introduce programming concepts, or full-featured web platforms. We are particularly seeking contributions and experience reports of the Learn-OCaml online programming environment which has been used by the OCaml teaching community for online but also for regular in-person classes. The goal is to share experiences, exchange ideas and tools, and promote best practices. Interested researchers are invited to submit and register a description of the talk (about 2 pages long) at <https://ocaml2022.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. The OCaml workshop and this special session are informal meetings 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 us to present more diverse work and gives time for discussion. The program committee for the OCaml Workshop will decide which presentations should be delivered as posters or talks. • Simão Melo de Sousa (University of Beira Interior) • Brigitte Pientka (McGill University) • Yann Regis-Gianas (Nomadic Labs) • Xujie Si (McGill University) 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 17409 bytes --]
[-- Attachment #1: Type: text/plain, Size: 12892 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 17 to 24, 2022. Table of Contents ───────────────── ML Family Workshop 2022: Final Call for Presentations Dune 3.2.0 Hardcaml MIPS CPU Learning Project and Blog A tutorial on parallel programming in OCaml 5 Old CWN ML Family Workshop 2022: Final Call for Presentations ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ml-family-workshop-2022-final-call-for-presentations/9877/1> Benoit Montagu announced ──────────────────────── We are happy to invite submissions to the *ML Family Workshop 2022*, to be held during the ICFP conference week on Thursday, September 15th. 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. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit! Currently, the workshop is scheduled to be an in-person event. We will give to the authors of accepted abstracts the opportunity to give their talks remotely if necessary, in case they could not travel. See the detailed CFP online on the ICFP website: <https://icfp22.sigplan.org/home/mlfamilyworkshop-2022#Call-for-Presentations> Important dates ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Friday 3th June (any time zone): Abstract submission deadline • Tuesday 28th June: Author notification • Thursday 15th August: ML Family Workshop Program committee ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Kenichi Asai (Ochanomizu University) • Arthur Azevedo de Amorim (Boston University) • Dariusz Biernacki (University of Wrocław) • Stephen Dolan (Jane Street) • Kavon Farvardin (Apple) • Armaël Guéneau (Inria) • Sam Lindley (University of Edinburgh) • Guido Martínez (CIFASIS-CONICET) • Keiko Nakata (SAP Innovation Center Potsdam) • Lionel Parreaux (Hong Kong University of Science and Technology) • Matija Pretnar (University of Ljubljana) • Mike Rainey (Carnegie Mellon University) • Yann Régis-Gianas (Nomadic Labs) • KC Sivaramakrishnan (IIT Madras and Tarides) • Ningning Xie (University of Cambridge) Chair: Benoît Montagu (Inria) Submission details ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ See the online CFP for the details on the expected submission format. Submissions must be uploaded to the workshop submission website <https://ml2022.hotcrp.com/> before the submission deadline. Dune 3.2.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-2-0/9892/1> Rudi Grinberg announced ─────────────────────── On behalf of the dune team, I'm pleased to announce the availability of version 3.2.0. This release contains few new features, but is packed with bug fixes and usability improvements. In particular, I'd like to point out that we've continued to improve the user experience with the watch mode. I encourage you all to try it out if you haven't already. Happy Hacking. 3.2.0 (17-05-2022) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Fixed `dune describe workspace --with-deps' so that it correctly handles Reason files, as well as files any other dialect. (#5701, @esope) • Disable alerts when compiling code in vendored directories (#5683, @NathanReb) • Fixed `dune describe --with-deps', that crashed when some preprocessing was required in a dune file using `per_module'. (#5682, fixes #5680, @esope) • Add `$ dune describe pp' to print the preprocssed ast of sources. (#5615, fixes #4470, @cannorin) • Report dune file evaluation errors concurrently. In the same way we report build errors. (#5655, @rgrinberg) • Watch mode now default to clearing the terminal on rebuild (#5636, fixes, #5216, @rgrinberg) • The output of jobs that finished but were cancelled is now omitted. (#5631, fixes #5482, @rgrinberg) • Allows to configure all the default destination directories with `./configure' (adds `bin', `sbin', `data', `libexec'). Use `OPAM_SWITCH_PREFIX' instead of calling the `opam' binaries in `dune install'. Fix handling of multiple `libdir' in `./configure' for handling `/usr/lib/ocaml/' and `/usr/local/lib/ocaml'. In `dune install' forbid relative directories in `libdir', `docdir' and others specific directory setting because their handling was inconsistent (#5516, fixes #3978 and #5455, @bobot) • `--terminal-persistence=clear-on-rebuild' will no longer destroy scrollback on some terminals (#5646, @rgrinberg) • Add a fmt command as a shortcut of `dune build @fmt --auto-promote' (#5574, @tmattio) • Watch mode now tracks copied external files, external directories for dependencies, dune files in OCaml syntax, files used by `include' stanzas, dune-project, opam files, libraries builtin with compiler, and foreign sources (#5627, #5645, #5652, #5656, #5672, #5691, #5722, fixes #5331, @rgrinberg) • Improve metrics for cram tests. Include test names in the event and add a category for cram tests (#5626, @rgrinberg) • Allow specifying multiple licenses in project file (#5579, fixes #5574, @liyishuai) • Match `glob_files' only against files in external directories (#5614, fixes #5540, @rgrinberg) • Add pid's to chrome trace output (#5617, @rgrinberg) • Fix race when creating local cache directory (#5613, fixes #5461, @rgrinberg) • Add `not' to boolean expressions (#5610, fix #5503, @rgrinberg) • Fix relative dependencies outside the workspace (#4035, fixes #5572, @bobot) • Allow to specify `--prefix' via the environment variable `DUNE_INSTALL_PREFIX' (#5589, @vapourismo) • Dune-site.plugin: add support for `archive(native|byte, plugin)' used in the wild before findlib documented `plugin(native|byte)' in 2015 (#5518, @bobot) • Fix a bug where Dune would not correctly interpret `META' files in alternative layout (ie when the META file is named `META.$pkg'). The `Llvm' bindings were affected by this issue. (#5619, fixes #5616, @nojb) • Support `(binaries)' in `(env)' in dune-workspace files (#5560, fix #5555, @emillon) • (mdx) stanza: add support for (locks). (#5628, fixes #5489, @emillon) • (mdx) stanza: support including files in different directories using relative paths, and provide better error messages when paths are invalid (#5703, #5704, fixes #5596, @emillon) • Fix ctypes rules for external lib names which aren't valid ocaml names (#5667, fixes #5511, @Khady) Hardcaml MIPS CPU Learning Project and Blog ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088/12> Alexander (Sasha) Skvortsov announced ───────────────────────────────────── Hi everyone! Last fall, we completed our original plan for this project, rewriting the verilog MIPS CPU we had designed for a class into Hardcaml. A few weeks later, we got an invite to video-meet with the Hardcaml team to talk about our experience. They even sent us actual Arty A-7 FPGAs so we could test out our simulation on real hardware! Junior year ended up much busier than expected, and although we had gotten our code onto the FPGAs by January, we’ve only just now fully finished our project. Our blog now has 2 bonus installments: 1. [Running Hardcaml on an actual FPGA]. Here, we lit up LEDs to display the output of a hardcoded program. 2. [Hardcaml MIPS and I/O]. Here, we restructured our CPU so that programs can communicate with an external device using UART. With these changes, our full design is now a simplified but realistic processor that can run meaningful programs. Thank you very much to @andyman, @fyquah95, Ben Devlin, and the rest of the Jane Street FPGA team for creating Hardcaml, meeting with us, and answering our numerous questions throughout this process. Thank you also to @yaron_minsky and Jane Street for sending us the FPGAs to try out our code. This has been an incredibly interesting, challenging, and rewarding journey. We hope that our blog posts and sample project are useful for learning Hardcaml in the future, and welcome any questions or comments. [Running Hardcaml on an actual FPGA] <https://ceramichacker.com/blog/27-1312-running-hardcaml-on-an-actual-fpga> [Hardcaml MIPS and I/O] <https://ceramichacker.com/blog/34-1412-hardcaml-mips-and-io> A tutorial on parallel programming in OCaml 5 ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/a-tutorial-on-parallel-programming-in-ocaml-5/9896/1> KC Sivaramakrishnan announced ───────────────────────────── I ran a hands-on tutorial on the new parallel programming primitives in the upcoming OCaml 5 at the Tarides off-site last week. It covers the low-level parallelism primitives exposed by the OCaml 5 compiler as well as high-level parallel programming using `domainslib'. I hope you like it and find it useful. Please feel free to open issues if you find anything amiss. <https://github.com/kayceesrk/ocaml5-tutorial> Alain De Vos asked and Olivier Nicole replied ───────────────────────────────────────────── As it is not immediately clear for me, does it uses threads , green threads, processes , fibers ? And who is responsible for the scheduling ,the Ocaml application or the underlying operating system ? Each domain corresponds to one system thread. The scheduling between them is therefore performed by the operating system. The tutorial only covers domains, which are the way to perform /parallelism/ in OCaml 5. To use /concurrency/ (e.g. having several IO-depending operations that run concurrently on the same core), the main mechanism is effects (which at the level of the runtime system, are implemented using small stack segments called fibers), as in the [eio library]. Effects allow such libraries to provide a form a lightweight threads (aka green threads) whose scheduling is implemented in the OCaml application using effect mechanisms. [eio library] <https://github.com/ocaml-multicore/eio#design-note-capabilities> UnixJunkie then said ──────────────────── Here is a very simple tutorial on parallel programming in OCaml: use parany ! <https://github.com/UnixJunkie/parany> For OCaml 5, use the right branch of parany: <https://github.com/UnixJunkie/parany/tree/domains> Happy hacking! 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 23627 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4673 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 24 to 31, 2022. Table of Contents ───────────────── carray.0.0.1 OCaml Users and Developers Workshop 2022 Old CWN carray.0.0.1 ════════════ Archive: <https://discuss.ocaml.org/t/ann-carray-0-0-1/9938/1> Danny Willems announced ─────────────────────── I'm glad to announce the first (experimental) release of ocaml-carray, a library mocking the Array interface to work with contiguous C array. *Disclaimer*: this first version is experimental and must be used with caution. A restricted set of values are supported at the moment (custom block with no out-of-heap values). Depending on the demand, more values might be supported. Feel free to use this thread to suggest ideas, make opinions, etc. Repository <https://gitlab.com/dannywillems/ocaml-carray> License [MIT] Release [0.0.1] Documentation <https://dannywillems.gitlab.io/ocaml-carray/carray/index.html> Nomadic Labs website <https://nomadic-labs.com> Tezos ZK-rollups repository <https://gitlab.com/nomadic-labs/privacy-team> [MIT] <https://gitlab.com/dannywillems/ocaml-carray/-/blob/0.0.1/LICENSE> [0.0.1] <https://gitlab.com/dannywillems/ocaml-carray/-/tags/0.0.1> Motivation ╌╌╌╌╌╌╌╌╌╌ OCaml arrays are not always contiguous piece of memory, requiring accessing different chunks of memory when accessing individual elements. When requiring a value in memory, the CPU will fetch the RAM and load not only the particular value but a memory page (a contiguous piece of memory) and add it to its cache. The CPU will use its cache to load the values in its registers. It is not efficient with large OCaml arrays as the CPU will constantly fetch the RAM to load different memory pages in its cache. Also, when using the C FFI, the user must know the memory representation of an array and use the non user-friendly low-level interface macro `Field'. This work ╌╌╌╌╌╌╌╌╌ This library provides a polymorphic interface mocking a subset of the `Array' interface to work with contiguous piece of memory. Using the library should be as easy as adding `module Array = Carray'. A C macro `Carray_val' is also provided for developers writing bindings and requires to simply cast in the underlying C type. It has also been observed sub arrays are sometimes used for read-only operations. However, `Array.sub' allocates a fresh copy of the requested sub part. `Carray' leverages this memory cost by providing noalloc variants, like `sub_noalloc'. Performances ╌╌╌╌╌╌╌╌╌╌╌╌ The concept has been tested and used in real world applications like the polynomial library used by Nomadic Labs to implement zk-rollups. A speed up of around 50% has been observed when using contiguous arrays compared to OCaml arrays to compute NTT/FFT. Usage ╌╌╌╌╌ This library is *experimental*. Use this library with caution. The interface might change in the future. ┌──── │ opam install carray.0.0.1 └──── OCaml Users and Developers Workshop 2022 ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-users-and-developers-workshop-2022/9726/2> Continuing this thread, Matija Pretnar announced ──────────────────────────────────────────────── This is a reminder for anyone interested in contributing to OCaml Workshop 2022. The deadline has been slightly extended to Friday, June 3 (anywhere on Earth), which means you have roughly *four days left* to prepare your submissions. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 14261 bytes --]
[-- Attachment #1: Type: text/plain, Size: 23518 bytes --] Hello Here is the latest OCaml Weekly News, for the week of May 31 to June 07, 2022. Table of Contents ───────────────── carray.0.0.1 ML Family Workshop 2022: Final Call for Presentations OCaml Users and Developers Workshop 2022 dkml-c-probe.2.0.0: Cross-compiler friendly definitions for C compiling Full-Stack Web Dev in OCaml Tutorial w/ Dream, Bonsai, and GraphQL Sketch.sh now supports multiple compiler versions, starting with 4.13.1 Explicit type binding and mutual recursion findlib-1.9.4 omake-0.10.4 Old CWN carray.0.0.1 ════════════ Archive: <https://discuss.ocaml.org/t/ann-carray-0-0-1/9938/6> Deep in this threas, Fabian said ──────────────────────────────── Note that you can, to a certain degree, build your own flat structures with the `Bytes' module. Compared to bigarrays, `Bytes.t' has less indirection, a lower constant memory overhead and can be allocated on the minor heap. The contents of `Bytes.t' are not scanned by the GC, just like bigarrays. For example, a more efficient `int32 Array.t': ┌──── │ module Int32_array : sig │ type t │ val equal : t -> t -> bool │ val create : int -> t │ val length : t -> int │ val get : t -> int -> int32 │ val set : t -> int -> int32 -> unit │ val sub : t -> int -> int -> t │ val to_list : bytes -> int32 list │ end = struct │ type t = Bytes.t │ let equal = Bytes.equal │ let create len = Bytes.create (4 * len) │ let length t = Bytes.length t / 4 │ let get t i = Bytes.get_int32_le t (4 * i) │ let set t i x = Bytes.set_int32_le t (4 * i) x │ let sub t pos len = Bytes.sub t (4 * pos) (4 * len) │ let to_list t = List.init (length t) (get t) │ end └──── A more efficient `(int * int)': ┌──── │ module Point : sig │ type t │ val create : int -> int -> t │ val x : t -> int │ val y : t -> int │ end = struct │ external get_int64_unsafe : bytes -> int -> int64 = "%caml_bytes_get64u" │ external set_int64_unsafe : bytes -> int -> int64 -> unit = "%caml_bytes_set64u" │ type t = Bytes.t │ let create x y = │ let p = Bytes.create 16 in │ set_int64_unsafe p 0 (Int64.of_int x); │ set_int64_unsafe p 8 (Int64.of_int y); │ p │ let x t = Int64.to_int (get_int64_unsafe t 0) │ let y t = Int64.to_int (get_int64_unsafe t 8) │ end └──── (making a more efficient `(int * int) Array.t' is left as an exercise to the reader) The downside compared to bigarrays is that it doesn't support `sub' without copying. Also, bytes can be moved by the GC (during minor GCs or compaction), and therefore you cannot release the runtime lock when passing them to C. The latter point is less relevant with the multicore extensions, especially since there is no compactor yet. There is some related discussion on the eio repository: <https://github.com/ocaml-multicore/eio/issues/140> ML Family Workshop 2022: Final Call for Presentations ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ml-family-workshop-2022-final-call-for-presentations/9877/2> Benoit Montagu announced ──────────────────────── ML Family Workshop 2022: DEADLINE EXTENSION ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ To increase your chances of submitting your work to the ML workshop, *the submission deadline is extended by a week*. The new deadline is Friday 10th June (AoE). A quick reminder: • The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. • The work load as an author is low: submissions are only 3 pages long (excluding references) • YOU have the power to make the ML workshop a success! • You have one more full week to submit to <https://ml2022.hotcrp.com/> (please register your submission early!) • All the details are here: <https://icfp22.sigplan.org/home/mlfamilyworkshop-2022#Call-for-Presentations> • The ML workshop is colocated with ICFP 2022 <https://icfp22.sigplan.org/> OCaml Users and Developers Workshop 2022 ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-users-and-developers-workshop-2022/9726/4> Matija Pretnar announced ──────────────────────── To offer additional opportunities to contribute to the OCaml workshop, and to align with the [ML family workshop], to which you are also cordially invited, the submission deadline has been extended by a week to *Friday, June 10* (anywhere on Earth). [ML family workshop] <https://icfp22.sigplan.org/home/mlfamilyworkshop-2022#Call-for-Presentations> dkml-c-probe.2.0.0: Cross-compiler friendly definitions for C compiling ═══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-dkml-c-probe-2-0-0-cross-compiler-friendly-definitions-for-c-compiling/9950/1> jbeckford announced ─────────────────── Summary: dkml-c-probe is a new package for maintainers who compile or link C code. Install it with `opam install dkml-c-probe'. Full docs are at [https://github.com/diskuv/dkml-c-probe#readme] [https://github.com/diskuv/dkml-c-probe#readme] <https://github.com/diskuv/dkml-c-probe#readme> Problem ╌╌╌╌╌╌╌ You are creating an OCaml package that has foreign C code. Perhaps you need special C headers or libraries when you are targeting Apple users, or perhaps you need to execute custom OCaml code for Android users. More generally you need a way to determine whether your OCaml or C code is compiling for a Linux AMD/Intel 64-bit, Android ARM 32-bit, or any other ABI target. Solution ╌╌╌╌╌╌╌╌ A user of your OCaml package may, for example, be on a 64-bit AMD/Intel Linux machine using a 32-bit OCaml system compiled with `gcc -m32'; additionally they have a 32-bit Android ARM cross-compiler toolchain. `dkml-c-probe' will tell you the target operating system is `Linux' and the target ABI is `Linux_x86' except when the cross-compiler toolchain is invoked. With the cross-compiler toolchain `dkml-c-probe' will tell you the target operating system is `Android' and the target ABI is `Android_arm32v7a'. How it works ╌╌╌╌╌╌╌╌╌╌╌╌ `dkml-c-probe' uses C preprocessor definitions (ex. `#if TARGET_CPU_X86_64', `#if __ANDROID__', etc.) to determine which ABI the C compiler (ex. `ocamlopt -config | grep native_c_compiler') is targeting. This isn't a new idea. The pattern is used in Esy and Mirage code as well. `dkml-c-probe' just codifies the pattern for use in your own code. Usage ╌╌╌╌╌ In OCaml code you can use the /versioned/ module: ┌──── │ module V2 : │ sig │ type t_os = Android | IOS | Linux | OSX | Windows │ type t_abi = │ Android_arm64v8a │ | Android_arm32v7a │ | Android_x86 │ | Android_x86_64 │ | Darwin_arm64 │ | Darwin_x86_64 │ | Linux_arm64 │ | Linux_arm32v6 │ | Linux_arm32v7 │ | Linux_x86_64 │ | Linux_x86 │ | Windows_x86_64 │ | Windows_x86 │ | Windows_arm64 │ | Windows_arm32 │ val get_os : (t_os, Rresult.R.msg) result Lazy.t │ val get_abi : (t_abi, Rresult.R.msg) result Lazy.t │ val get_abi_name : (string, Rresult.R.msg) result Lazy.t │ end └──── In C code you can use the [provided `dkml_compiler_probe.h' header] from within Dune or Opam. Here is a snippet that handles part of the Linux introspection: ┌──── │ #elif __linux__ │ # if __ANDROID__ │ # ... │ # else │ # define DKML_OS_NAME "Linux" │ # define DKML_OS_Linux │ # if __aarch64__ │ # define DKML_ABI "linux_arm64" │ # define DKML_ABI_linux_arm64 │ # elif __arm__ │ # if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) || │ defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) || defined(__ARM_ARCH_6ZK__) || │ defined(__ARM_ARCH_6T2__) │ # define DKML_ABI "linux_arm32v6" │ # define DKML_ABI_linux_arm32v6 │ # elif defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) || │ defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7S__) │ # define DKML_ABI "linux_arm32v7" │ # define DKML_ABI_linux_arm32v7 │ # endif /* __ARM_ARCH_6__ || ..., __ARM_ARCH_7__ || ... */ │ # elif __x86_64__ │ # define DKML_ABI "linux_x86_64" │ # define DKML_ABI_linux_x86_64 │ # elif __i386__ │ # define DKML_ABI "linux_x86" │ # define DKML_ABI_linux_x86 │ # elif defined(__ppc64__) || defined(__PPC64__) │ # define DKML_ABI "linux_ppc64" │ # define DKML_ABI_linux_ppc64 │ # elif __s390x__ │ # define DKML_ABI "linux_s390x" │ # define DKML_ABI_linux_s390x │ # endif /* __aarch64__, __arm__, __x86_64__, __i386__, __ppc64__ || __PPC64__, │ __s390x__ */ └──── [provided `dkml_compiler_probe.h' header] <https://github.com/diskuv/dkml-c-probe#c-header> Versioning and Contributing ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Whenever a new ABI is added, it goes into a new version (ex. `module V3'). Your existing code that uses `module V2' will be unaffected. But each new ABI needs to have its own maintainer because I don't have access to every hardware platform on the planet! For example, PowerPC (`ppc64') and Linux on IBM Z (`s390x') are supported in the C Header but not the OCaml module because there are no PowerPC and S390x maintainers. Please consider contributing, especially if you want others to have an easier compilation story for your favorite hardware platform. Full-Stack Web Dev in OCaml Tutorial w/ Dream, Bonsai, and GraphQL ══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/full-stack-web-dev-in-ocaml-tutorial-w-dream-bonsai-and-graphql/9963/1> Alexander (Sasha) Skvortsov announced ───────────────────────────────────── Hi everyone! I’ve written a tutorial blog series about full-stack web development in OCaml, and wanted to share it here. Last semester, I took Penn State's [CMPSC 431W], where our final project was to build a database-driven web application. Since I'm fairly familiar with web programming through my work on [Flarum] and past internships/side projects, I decided to use this opportunity to explore the OCaml web development ecosystem. I used [Dream] for the backend, and [Bonsai] for the frontend. While working on this project, I realized two things: • OCaml is very underrated for web development. In addition to all the language’s great features and safety guarantees, the ecosystem is pretty good! Dream near-perfectly coincides with my vision of backend webdev, and Bonsai has a great balance of flexibility/elegance and safety. • I couldn’t find realistic but accessible full-stack web projects in OCaml available for reference. I found [tutorials] for [bits] and [pieces], but nothing that connected all the dots. I really enjoyed writing an article series on [hardware design with OCaml], so I decided to do so for web development as well. In total, I wrote 7 articles that walk through my project’s: 1. [Full-Stack WebDev in OCaml Intro]. This includes some background on the project, and instructions for accessing the [live demo]. 2. [Backend WebDev w/ Dream and Caqti]. 3. [Building GraphQL APIs with Dream] 4. [Setting up Bonsai]. 5. [Understanding Bonsai]. I actually wrote the first draft of this before I decided to do a blog, while trying to, well, understand Bonsai. It goes over some underlying concepts (SPAs, Frontend State Management, Algebraic Effects, Monads), as well as Bonsai’s core design. 6. [Using GraphQL in Bonsai]. 7. [Routing in Bonsai and Project Conclusion]. Additionally, the [project’s README] has a comprehensive overview of the tech stack, folder structure, and usage instructions. It also includes some reflections on design decisions and my experience working with these libraries. I had a lot of fun writing these, and I hope they’re useful to anyone considering OCaml for web development. Would be happy to answer any questions or comments. [CMPSC 431W] <https://bulletins.psu.edu/university-course-descriptions/undergraduate/cmpsc/#:~:text=CMPSC%20431W%3A%20Database%20Management%20Systems> [Flarum] <https://flarum.org/> [Dream] <https://aantron.github.io/dream/> [Bonsai] <https://github.com/janestreet/bonsai> [tutorials] <https://github.com/paurkedal/ocaml-caqti> [bits] <https://jsthomas.github.io/ocaml-dream-api.html> [pieces] <https://github.com/janestreet/bonsai/blob/master/docs/getting_started/counters.mdx> [hardware design with OCaml] <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088> [Full-Stack WebDev in OCaml Intro] <https://ceramichacker.com/blog/26-1x-full-stack-webdev-in-ocaml-intro> [live demo] <https://cmpsc431.ceramichacker.com/> [Backend WebDev w/ Dream and Caqti] <https://ceramichacker.com/blog/28-2x-backend-webdev-w-dream-and-caqti> [Building GraphQL APIs with Dream] <https://ceramichacker.com/blog/29-3x-building-graphql-apis-with-dream> [Setting up Bonsai] <https://ceramichacker.com/blog/30-4x-setting-up-bonsai> [Understanding Bonsai] <https://ceramichacker.com/blog/31-5x-understanding-bonsai> [Using GraphQL in Bonsai] <https://ceramichacker.com/blog/32-6x-using-graphql-in-bonsai> [Routing in Bonsai and Project Conclusion] <https://ceramichacker.com/blog/33-77-routing-in-bonsai-and-project-conclusion> [project’s README] <https://github.com/askvortsov1/nittany_market> Alexander (Sasha) Skvortsov later added ─────────────────────────────────────── Also, forgot to mention this originally, but I recommend accessing the demo with one of the emails from [this file] or [this file] (all passwords are still [here]), as those users can also demo create/update functionalities. [this file] <https://github.com/askvortsov1/nittany_market/blob/main/data/Local_Vendors.csv> [this file] <https://github.com/askvortsov1/nittany_market/blob/main/data/Sellers.csv> [here] <https://github.com/askvortsov1/nittany_market/blob/main/data/Users.csv> Daniel Bünzli replied ───────────────────── People who are looking for more lightweight alternatives – and want to do web programming without bothering too much about front end insanity can have a look at [hc] (yes indeed: sending HTML over `fetch', web programming excels at running in circles). The front JavaScript for that [CRUD webapp] comes out at 132Ko uncompressed without even trying to tweak anything. [hc] <https://erratique.ch/software/hc> [CRUD webapp] <https://github.com/dbuenzli/hyperbib> Sketch.sh now supports multiple compiler versions, starting with 4.13.1 ═══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-sketch-sh-now-supports-multiple-compiler-versions-starting-with-4-13-1/9971/1> Javier Chávarri announced ───────────────────────── The interactive OCaml sketchbook [sketch.sh] has now support to store, edit and run sketches in different versions of the OCaml compiler. [sketch.sh] <https://sketch.sh/> Support for 4.13 ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Storing and running sketches using the compiler version 4.13.1 is now possible, this functionality has been added to the already existing support for version 4.06.1. The Reason parser and formatting tool refmt were also updated to a more recent version that supports 4.13.1. Here you can see a sketch showcasing the monadic let syntax, using the example from the official OCaml docs: [ZipSeq - Sketch.sh]. [ZipSeq - Sketch.sh] <https://sketch.sh/s/8cnNChTTq6IoGeFQarbvN2/> Existing sketches and forks ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Previously existing sketches remain in 4.06.1, while newly created sketches will be on 4.13.1. For now, the only way to "migrate" a sketch to the newer version of the compiler is by copying its content and pasting it in a new sketch. Forked sketches inherit the compiler version of the forked sketch. Future plans ╌╌╌╌╌╌╌╌╌╌╌╌ In the future, there are plans to support version 4.14.0 of the compiler, and we are considering adding a way so that the version of the compiler can be chosen for a given sketch. We are also working on migrating the editor UI codebase to a more recent version of ReasonReact, and use JSX3 instead of JSX2. Feature requests and bugs ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Please [let us know] in case you have a feature request, or if you encounter any issues or bugs. Also, don't hesitate to reach out via DM or any other means if you would like to contribute or participate in the project in some way. Thanks to [Ahrefs] for supporting an Open Source Day initiative, which allowed to allocate time to work on this improvement for sketch.sh, and for providing the infrastructure to run the sketch.sh service for the community. Thanks as well to the authors and maintainers of the OCaml compiler, js_of_ocaml, and ReScript, that sketch.sh relies upon. [let us know] <https://github.com/Sketch-sh/sketch-sh/issues/new> [Ahrefs] <https://ahrefs.com/> Explicit type binding and mutual recursion ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/explicit-type-binding-and-mutual-recursion/9973/3> Deep in this thread, octachron explained ──────────────────────────────────────── For most use cases, if you want an explicit annotation for recursive function, it will be much simpler to use the `type a. ...' form: ┌──── │ let rec foo: type a. a -> a = fun x -> x │ and bar: type a. a -> a = fun x -> foo x └──── This form is a shortcut for both adding an explicit universal quantified and and a corresponding locally abstract type (in other words ~let f : 'a . …. = fun (type a) -> … ~). The root issue with ┌──── │ let rec f (type a) (x:a) = f x └──── is that the locally abstract type `a' is introduced after `f'. Moreover, without an explicit type annotation, a recursive function like `f' is monomorphic in its body and a monorphic function cannot be called on a type that was defined after the function. In other words, the issue is that in term of type scopes, the function `f' is equivalent to ┌──── │ let f = ref Fun.id │ type t = A │ let x = !f A └──── which also fails with ┌──── │ Error: This expression has type t but an expression was expected of type 'a │ The type constructor t would escape its scope └──── This is why the second solution proposed by @Gopiandcode works. Indeed, in ┌──── │ let foo, bar = fun (type a) -> │ let rec foo (x: a) : a = x │ and bar (x: a) : a = foo x in │ foo, bar └──── the type `a' is defined before the recursive functions `foo' and `bar', thus `foo a' does not break any scope constraint. findlib-1.9.4 ═════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00004.html> Gerd Stolpmann announced ──────────────────────── findlib-1.9.4 is out. It mainly includes a change in the configuration script needed for OCaml-4-14. For manual, download, manuals, etc. see here: <http://projects.camlcity.org/projects/findlib.html> An updated OPAM package will follow soon. omake-0.10.4 ════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00005.html> Gerd Stolpmann announced ──────────────────────── I just released omake-0.10.4, the build utility. This finally includes the fix for Apple Silicon, but also a couple of small changes (roughly everything since PR#100 to PR#146 on GitHub). For docs and the download link see <http://projects.camlcity.org/projects/omake.html>. opam is underway. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 46496 bytes --]
[-- Attachment #1: Type: text/plain, Size: 22418 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 07 to 14, 2022. Table of Contents ───────────────── Lwt informal user survey Tutorial: Full-Stack Web Dev in OCaml w/ Dream, Bonsai, and GraphQL dkml-c-probe: Cross-compiler friendly definitions for C compiling Htmx/hc web development approach Engineer and postdoc positions in France (various labs) to work on a proof assistant for crypto protocols Yojson 2.0.0 opentelemetry 0.2 omake-0.10.5 findlib-1.9.5 Old CWN Lwt informal user survey ════════════════════════ Archive: <https://discuss.ocaml.org/t/lwt-informal-user-survey/9666/3> Continuing this thread, Raphaël Proust said ─────────────────────────────────────────── Thanks to everyone who took the time to answer the polls above. I've now closed them. The first pull-request to come out of this poll is [<https://github.com/ocsigen/lwt/pull/947>](removing support for OCaml<=4.07). This was the cutoff in the poll. It removes a lot of `#if' preprocessing statements and a few workarounds to stay compatible with old Stdlib interfaces. Thanks to @hannes for contributing most of the commits on this pull-request. If support for OCaml<=4.07 is important to you, please participate in the pull-request's discussion or on this thread. Stay tuned for more. (But also be patient.) Tutorial: Full-Stack Web Dev in OCaml w/ Dream, Bonsai, and GraphQL ═══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/tutorial-full-stack-web-dev-in-ocaml-w-dream-bonsai-and-graphql/9963/20> Continuing this thread, jerben asked and Daniel Bünzli replied ────────────────────────────────────────────────────────────── Very interesting, did you write somewhere about how it compares to htmx? Not really. As far as I can remember I liked the ideas but found their execution to be a bit lacking, sometimes ad-hoc in their attribute DSL, focusing more on the show off to convince single page application proponents of the approach than on a clear conceptual model (which `hc' tries to detail in the manual [here]). Two other things that come to mind are: 1. AFAIR their examples relied a lot on unique `id' attributes for targeting request results. Unless you find a principled and automated way to generate these that's not compositional and brittle. In `hc' I [extended the CSS selector syntax] to allow to address your ancestors (peace be upon them). That's more compositional but now you become sensitive to structural changes in your markup – pick your poison[^1]. 2. I'm no longer sure about that, i.e. don't take my word for it, but I think their DSL allowed to spread the definition of an interaction among many elements which made it more difficult to understand what is happening. In `hc' all attributes defining the effects of an interaction are always located on a single element, the element that performs the request. Finally when things go wrong I prefer to have to understand [700 lines of ml] rather than [2800 lines of JavaScript] (note that they likely have better legacy browser support and more functionality). In any case there's a long list of todos in `hc' and it likely needs one or two more design rounds before getting to something decent – if that's even remotely possible on the web. Dang it @dbuenzli one day you’ll run out of letters and need to come up with an actual name for your libraries. Mind you I tried to use three letters once, but the whole experience turned out to be [extremely unpleasant] :–) [^1]: Using unique ids reifed in an OCaml EDSL could be a better idea. [here] <https://erratique.ch/software/hc/doc/manual.html#request> [extended the CSS selector syntax] <https://erratique.ch/software/hc/doc/manual.html#selector> [700 lines of ml] <https://github.com/dbuenzli/hc/blob/master/src/hc_page.ml> [2800 lines of JavaScript] <https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js> [extremely unpleasant] <https://github.com/dbuenzli/rel/commit/f95b6bad02a8080eb64f8d0123cd63d40b528e33> dkml-c-probe: Cross-compiler friendly definitions for C compiling ═════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-dkml-c-probe-cross-compiler-friendly-definitions-for-c-compiling/9950/8> jbeckford announced ─────────────────── V3 is available. Its `C_abi' module has some big enhancements: • cleaner API (thanks @mseri!) • recognizes the BSD family: OpenBSD, FreeBSD, NetBSD and DragonFly on x86_64 hardware • integration testing now includes OpenBSD, FreeBSD and one cross-compiling toolchain (macOS x86_64 host that targets arm64) V3 also has a new module `C_conf' which occupies the same problem space as `findlib / ocamlfind' and `pkg-config': • Unlike `findlib' which is a specification+tool for 3rd party OCaml libraries, `C_conf' is a specification+tool for foreign C libraries • Unlike `pkg-config' which is a specification+tool for system (host ABI) C libraries, `C_conf' is a specification+tool for the multiple ABIs that are present when you cross-compile OCaml or C code • Unlike `pkg-config' which is designed for Unix, `C_conf' is designed for Windows and Unix where paths may have spaces, backslashes and colons • For now the specification is based on environment variables. If it proves useful the specification can be extended. Examples and doc links for V3 are available at [https://github.com/diskuv/dkml-c-probe#dkml-c-probe] [https://github.com/diskuv/dkml-c-probe#dkml-c-probe] <https://github.com/diskuv/dkml-c-probe#dkml-c-probe> Marcello Seri asked and jbeckford replied ───────────────────────────────────────── Thanks a lot for the update! Can you say a bit more about how `C_conf' works? C_conf has a detailed problem statement and spec at <https://diskuv.github.io/dkml-c-probe/dkml-c-probe/Dkml_c_probe/C_conf/index.html> (which is linked to on the dkml-c-probe README). I probably shouldn't regurgitate the doc here, so I'll take a few key pieces from the doc and then post some things here that I didn't put on that doc page … 1. Here is my configuration for locating the "gmp" library on my Apple Silicon host machine that cross-compiles to x86_64: ┌──── │ CP_GMP_CC_DEFAULT = -IZ:/build/darwin_arm64/vcpkg_installed/arm64-osx/include │ CP_GMP_CC_DEFAULT_DARWIN_X86_64 = -IZ:/build/darwin_x86_64/vcpkg_installed/x64-osx/include │ CP_GMP_LINK_DEFAULT = -LZ:/build/darwin_arm64/vcpkg_installed/arm64-osx/lib;-lgmp │ CP_GMP_LINK_DEFAULT_DARWIN_X86_64 = -LZ:/build/darwin_x86_64/vcpkg_installed/x64-osx/lib;-lgmp └──── • The other direction may be more interesting, since the free GitHub Actions only supports x86_64. The scenario of taking a macOS x86_64 GitHub host and cross-compiling to Apple Silicon is [implemented and partially tested]. 2. I am using a C package manager (vcpkg) to give me cross-compiled libraries and the flags for the target ABI (in this case darwin_x86_64 is the target ABI). In general it doesn't matter where you get your target ABI compatible libraries from. Example: When I'm cross-compiling to Android on a Windows x86_64 host, the Android Studio environment gives me some libraries for an Android Emulator (host ABI) and also prebuilt libraries for 4 Android device ABIs: ┌──── │ Directory: C:\Users\xxx\AppData\Local\Android\Sdk\ndk\23.1.7779620\prebuilt │ │ Mode LastWriteTime Length Name │ ---- ------------- ------ ---- │ d----- 10/20/2021 8:27 PM android-arm │ d----- 10/20/2021 8:27 PM android-arm64 │ d----- 10/20/2021 8:27 PM android-x86 │ d----- 10/20/2021 8:26 PM android-x86_64 │ d----- 10/20/2021 8:27 PM windows-x86_64 └──── 3. The `CP_clibrary_CC_DEFAULT_abi' configuration relies on `abi' (the ocamlfind toolchain name) being standardized. The `gmp' library, for example, is used by many OCaml packages; I wanted one configuration for `gmp', not one configuration for each `(gmp, OCaml package)' combination. In fact, getting a consistent `abi' naming was one of my motivations for releasing `dkml-c-probe'. I don't think the prior art got this right … the very stale [opam-cross-android] project uses [`abi = "android"'] which is insufficient to differentiate the 5+ sets of libraries available in Android Studio. 4. The "gmp" (etc.) configuration is done once in a familiar syntax (`-L, -I, -l'). However the `C_conf' library will parse and print the configuration in the appropriate C compiler syntax. When the MSVC compiler is used you get MSVC style linking: ┌──── │ [ │ "-LIBPATH:Z:/build/darwin_x86_64/vcpkg_installed/x64-osx/lib"; │ "gmp.lib" │ ] └──── MSVC and GCC conventions are supported today in `C_conf'. 5. A real example of using `C_conf' is in my customization of [zarith library]. It checks `C_conf' first to see whether the user has the host/target ABI configuration; if it doesn't it falls back to pkg-config. The trend of using `pkg-config' in OCaml packages makes both native Windows and cross-compilation difficult. At the moment *we unintentionally shoot ourselves in the foot* because [Dune documentation encourages `pkg-config'] for understandable reasons. I hope `dkml-c-probe' can break that trend. [implemented and partially tested] <https://github.com/diskuv/dkml-c-probe/blob/2c1e90b4eea119348d6dae37d64949041ef9eaeb/.github/workflows/test.yml#L299-L379> [opam-cross-android] <https://github.com/ocaml-cross/opam-cross-android> [`abi = "android"'] <https://github.com/ocaml-cross/opam-cross-android#porting-packages> [zarith library] <https://github.com/jonahbeckford/Zarith/blob/a1bf6d55cd3c4b91dee0afb2309ef11271e9729b/discover.ml> [Dune documentation encourages `pkg-config'] <https://dune.readthedocs.io/en/stable/dune-libs.html#configurator-1> Htmx/hc web development approach ════════════════════════════════ Archive: <https://discuss.ocaml.org/t/htmx-hc-web-development-approach/9993/11> Vladimir Keleshev announced asked ───────────────────────────────── @cemerick, @yawaramin, @dbuenzli, and others who've used htmx/hc with OCaml back-end: what is your experience with templating? It seems that htmx/hc puts high requirements on a flexible HTML templating/DSL. What did you choose and is it working out for you? Daniel Bünzli replied ───────────────────── I'm using OCaml and an absolutely [trivial HTML generation library]. If you want to see a real world example head to the `*_html.{ml,mli}' files in [this directory] (more on the structure found there [here]) Works quite well for me but I'd say the problem is not really templating it's rather non-brittle URL management. For that I use [this module] which while I'm not entirely convinced by it yet, allows me to type them and avoid the stringly unchecked dependendencies so characteristic of the web development world. [trivial HTML generation library] <https://erratique.ch/software/webs/doc/Webs_html/index.html> [this directory] <https://github.com/dbuenzli/hyperbib/tree/master/src/service> [here] <https://github.com/dbuenzli/hyperbib/blob/master/DEVEL.md#cli-tool-and-backend> [this module] <https://erratique.ch/software/webs/doc/Webs_kit/Kurl/index.html> Chas Emerick also replied ───────────────────────── Yeah, you're right on that point. I'm using tyxml for 99% of my HTML generation, specifically its jsx ppx. I am judicious about keeping the main logics of the project in OCaml proper; `.re' files exist exclusively to hold markup. The end result is a _very_ pleasant environment IMO. In the end, I dearly wish there was a way to get actual HTML syntax into `.ml' files (I am no fan of reason syntax outside of jsx, and I suspect the sorta-legacy jsx toolchain leftover from reasonml will end up being a tech risk over time), but as things stand, it's the best option I've found. Yawar Amin also replied ─────────────────────── I'm just using Dream's 'built-in' templating, 'Embedded ML (.eml)', it works reasonably well–each template or partial is just a function that you define to take some arguments and return some markup. It even auto-escapes to prevent injection attacks. E.g., ┌──── │ let card name = │ <div class="card"><%s name %></div> └──── There are a couple of tricks to be aware of with the EML syntax but in general it works well. Simon Cruanes also replied ────────────────────────── For the little webdev I do (internal tools mostly for myself), I've also been using server side html generation, with my own `wheels' tools and a bit of htmx. Here's an excerpt from a personal project, with my own httpd and html combinators; it adds a root to handle `/thy/<some string>': ┌──── │ let h_thy (self:state) : unit = │ H.add_route_handler self.server │ H.Route.(exact "thy" @/ string_urlencoded @/ return) @@ fun thy_name req -> │ let@ () = top_wrap_ req in │ let thy = Idx.find_thy self.st.idx thy_name in │ let res = │ let open Html in │ [ │ div[cls "container"][ │ h3[][txtf "Theory %s" thy_name]; │ Thy_file.to_html thy; │ div [ │ "hx-trigger", "load"; │ "hx-get", (spf "/eval/%s" @@ H.Util.percent_encode thy_name); │ "hx-swap", "innerHtml"] [ │ span[cls "htmx-indicator"; A.id "ind"][ │ txt "[evaluating…]"; │ ] │ ]; │ ] │ ] │ in │ reply_page ~title:(spf "theory %s" thy_name) req res └──── Engineer and postdoc positions in France (various labs) to work on a proof assistant for crypto protocols ═════════════════════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/engineer-and-postdoc-positions-in-france-various-labs-to-work-on-a-proof-assistant-for-crypto-protocols/9999/1> David Baelde announced ────────────────────── We are looking for engineers and postdocs to work on Squirrel, a proof assistant dedicated to proving cryptographic protocols. We have a broad range of projects in mind, ranging from pure OCaml development to involved protocol formalizations, with several theoretical questions in between. If you'd like to work on some of these aspects for one or more years, please get in touch with us! More details can be found here: <https://squirrel-prover.github.io/positions.pdf> Yojson 2.0.0 ════════════ Archive: <https://discuss.ocaml.org/t/ann-yojson-2-0-0/10003/1> Marek Kubica announced ────────────────────── This Friday, it is my pleasure to announce the release of Yojson 2.0.0. You can get it [in your local OPAM repository]. Key highlights include: • Fewer dependencies: Given Yojson is a common dependency we cut down on its dependencies so you have to install less and have less transitive dependencies • `Seq' interface: Since OCaml 4.14 deprecates `Stream' and 5.0 removes it, this was a good time to change to this interface • `Buffer' interface: coming along with #1, we changed Yojson to use `Buffer' wherever it was using `Biniou' types before Thanks to everybody involved in this release! If Yojson sounds like an interesting project for you to contribute, [join us]. Full changelog follows: [in your local OPAM repository] <https://opam.ocaml.org/packages/yojson/> [join us] <https://github.com/ocaml-community/yojson> 2.0.0 ╌╌╌╌╌ *2022-06-02* Removed ┄┄┄┄┄┄┄ • Removed dependency on easy-format and removed `pretty_format' from `Yojson', `Yojson.Basic', `Yojson.Safe' and `Yojson.Raw'. (@c-cube, #90) • Removed dependency on `biniou', simplifying the chain of dependencies. This changes some APIs: ‣ `Bi_outbuf.t' in signatures is replaced with `Buffer.t' ‣ `to_outbuf' becomes `to_buffer' and `stream_to_outbuf' becomes `stream_to_buffer' (@Leonidas, #74, and @gasche, #132) • Removed `yojson-biniou' library • Removed deprecated `json' type aliasing type `t' which has been available since 1.6.0 (@Leonidas, #100). • Removed `json_max' type (@Leonidas, #103) • Removed constraint that the "root" value being rendered (via either `pretty_print' or `to_string') must be an object or array. (@cemerick, #121) • Removed `validate_json' as it only made sense if the type was called `json'. (@Leonidas, #137) Add ┄┄┄ • Add an opam package `yojson-bench' to deal with benchmarks dependency (@tmcgilchrist, #117) • Add a benchmark to judge the respective performance of providing a buffer vs letting Yojson create an internal (#134, @Leonidas) • Add an optional `suf' keyword argument was added to functions that write serialized JSON, thus allowing NDJSON output. Most functions default to not adding any suffix except for `to_file' (#124, @panglesd) and functions writing sequences of values where the default is `\n' (#135, @Leonidas) Change ┄┄┄┄┄┄ • The `stream_from_*' and `stream_to_*' functions now use a `Seq.t' instead of a `Stream.t', and they are renamed into `seq_from_*' and `seq_to_*' (@gasche, #131). Fix ┄┄┄ • Avoid copying unnecessarily large amounts of strings when parsing (#85, #108, @Leonidas) • Fix `stream_to_file' (#133, @tcoopman and @gasche) opentelemetry 0.2 ═════════════════ Archive: <https://discuss.ocaml.org/t/ann-opentelemetry-0-2/10005/1> Simon Cruanes announced ─────────────────────── It is my pleasure to announce the release of [ocaml-opentelemetry] 0.2. This library provides a core instrumentation library, as well as exporters, for the [opentelemetry] standard for observability; it encompasses distributed tracing, metrics, and (more recently) log export. A lot of tools are compatible with opentelemetry these days, including Grafana, DataDog, jaeger, etc. This is still very early days for ocaml-opentelemetry, feedback and contributions are welcome. [ocaml-opentelemetry] <https://github.com/imandra-ai/ocaml-opentelemetry> [opentelemetry] <https://opentelemetry.io/> omake-0.10.5 ════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00012.html> Gerd Stolpmann announced ──────────────────────── I just released omake-0.10.5, the build utility, which fixes the broken installation of version 0.10.4 from last week. For docs and the download link see <http://projects.camlcity.org/projects/omake.html>. opam is underway. findlib-1.9.5 ═════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2022-06/msg00012.html> Gerd Stolpmann announced ──────────────────────── findlib-1.9.5 is out, fixing some scripting errors in the version 1.9.4 from last week. For manual, download, manuals, etc. see here: <http://projects.camlcity.org/projects/findlib.html> An updated OPAM package will follow soon. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 36894 bytes --]
[-- Attachment #1: Type: text/plain, Size: 17329 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 14 to 21, 2022. Table of Contents ───────────────── OBazl Toolsuite - tools for building OCaml with Bazel Job offer: 3 years compiler engineer at the French tax authority OCaml 5.0, zeroth alpha release Tezt, a framework for all your tests OCaml Stdlib, Containers, Batteries, Base and F# core functions comparisons Dune 3.3.0 Old CWN OBazl Toolsuite - tools for building OCaml with Bazel ═════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/obazl-toolsuite-tools-for-building-ocaml-with-bazel/10021/1> Gregg Reynolds announced ──────────────────────── Version 2 of OBazl, a Bazel ruleset for building OCaml code, will soon be available. I'm letting you know early because I'll be giving a presentation about the OBazl Toolsuite for the [Bazel Exchange] conference next Wed, 22 June, at 3:00 pm UDT (10:00 am CDT). It's a virtual conference so you can tune in from anywhere. The talk will focus on some of the quirks of the OCaml build discipline and how I addressed them for the OBazl ruleset. The tools are usable now, they're just not yet properly documented and packaged, and in a few places there's a little more work to be done on the code. Nonetheless there is quite a bit of documentation (CAVEAT: some of it is outdated), with more on the way soon, and there are lots of demos available. So if you're interested in using Bazel to build your OCaml code I welcome you to take a look: [The OBazl Book] Twitter handle is @obazldev Discord: [https://discord.gg/PHSAW5DUva] [Bazel Exchange] <https://skillsmatter.com/conferences/13682-bazel-exchange> [The OBazl Book] <https://obazl.github.io/docs_obazl/> [https://discord.gg/PHSAW5DUva] <https://discord.gg/PHSAW5DUva> Gregg Reynolds lated added ────────────────────────── PS. The conference organizers have provided this discount token: BAZEL-GR-20 It should be good for 20% off, registration is at [https://events.skillsmatter.com/bazelx2022] [https://events.skillsmatter.com/bazelx2022] <https://events.skillsmatter.com/bazelx2022> Job offer: 3 years compiler engineer at the French tax authority ════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-offer-3-years-compiler-engineer-at-the-french-tax-authority/10023/1> Denis Merigoux announced ──────────────────────── [En français parce que c'est une offre d'emploi dans l'administration] Bonjour à toutes et à tous, Vous aimez la programmation fonctionnelle et les compilateurs ? Vous en avez marre des offres d'emploi dans la blockchain ? Ça tombe bien, j'ai ce qu'il vous faut ! Il y a deux ans, j'ai lancé un grand projet de modernisation du calcul informatique de calcul de l'impôt sur le revenu à la Direction Générale des Finances Publiques (DGFiP), en partenariat avec Inria: <https://www.inria.fr/fr/mlang-modernisation-calcul-impot-revenu>. Le logiciel au cœur de ce projet de modernisation est Mlang, un compilateur écrit en OCaml pour un couple de langages dédiés utilisés par la DGFiP pour encoder le calcul de l'impôt sur le revenu. Depuis deux ans, la DGFiP travaille à intégrer Mlang à l'infrastructure officielle de calcul de l'impôt sur le revenu pour remplacer des systèmes vieillissants. C'est donc un projet à très fort impact (80M€ par d'impôts par an), et proche de la R&D (OCaml, libre, innovation) ! Depuis un an, la DGFiP emploie la société OCamlPro sur le projet mais souhaite maintenant ré-internaliser ses compétences pour garder la souveraineté numérique sur son infrastructure de calcul. C'est là que cette offre d'emploi entre en jeu ! En effet la DGFiP vient d'ouvrir un poste en CDD de 3 ans pour un.e expert.e en compilation ! Les détails : • Bureaux à Noisy-le-Grand (+ jusqu'à 3 jours télétravail/semaine) • Salaire: À négocier selon expérience mais similaire à "Inspecteur des finances publiques". Selon le site du ministère de l'économie ça débuterait à 3k€ net/mois. • Tâches: Maintenance, évolution de Mlang et travaux annexes Et pour l'heureux.se recruté.e, la cerise sur le gâteau sera de pouvoir collaborer avec moi et l'équipe Prosecco d'Inria (ainsi que Raphaël Monat, ) :) Attention cependant : il faudra s'attendre à devoir également aider l'équipe de la DGFiP sur d'autres chantiers en fonction des priorités. De même, l'objectif est de partager la compétence en compilation au sein de la DGFiP, donc les profils évangélisateurs de la programmation fonctionnelle sont les bienvenus ! Pour référence, voici l'offre officielle complète: <https://merigoux.ovh/assets/OffreDGFiP.pdf>. S'il vous plaît, pas d'autocensure à cause de ce qui est marqué dans ce PDF! Si vous avez un doute contactez-moi par retour de mail. Deadline pour les candidatures: 9 juillet. Prise de poste inconnue, sûrement aux alentours du 1er septembre mais j'imagine que c'est négociable. Denis Merigoux later added ────────────────────────── Si vous êtes intéressé.e, envoyez votre CV et lettre de motivation à bureau.si-part-rh@dgfip.finances.gouv.fr et bureau.rh-mobilite-carriere-a-recrutementchoix@dgfip.finances.gouv.fr. OCaml 5.0, zeroth alpha release ═══════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-5-0-zeroth-alpha-release/10026/1> octachron announced ─────────────────── Five months after the initial merge of the multicore branch into the mainline OCaml and three months after the release of OCaml 4.14.0, OCaml 5.0.0 is starting to take shape. I am thus happy to announce an exceptional zeroth alpha release of OCaml 5.0.0 (see below for the installation instructions). This alpha release is expected to be rougher than an usual alpha release, due to the full rewrite of the OCaml runtime. In particular, the bytecode debugger will only be available in the next alpha release. Similarly, there will be some changes to the internal C runtime API and to the files installed by the compiler package in the next alpha release. Moreover, this zeroth alpha release is the occasion to remind everyone that OCaml 5.0 itself is expected to be a more experimental release than usual. Notably, the native compiler will only be available on the ARM64 and x86-64 architectures in this 5.0 release. Nevertheless, this zeroth alpha version is already stable enough for fellow hackers eager to join us in our early bug hunting and opam ecosystem fixing fun, or to venture in the new era of parallelism and (experimental) effects. You can follow the progresses in stabilising the opam ecosystem on <https://github.com/ocaml/opam-repository/issues/21526> A brief summary is that at least dune, merlin, ppxlib, utop, ocamlfind, and ocamlbuild work (potentially by using patches from the alpha opam repository). If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> In particular, any sequential OCaml 4 library or program should be valid in OCaml 5 (except for deprecated modules and functions). Please don't hesitate to report any compatibility bugs! If you are interested by the ongoing list of bug fixes, the updated change log for OCaml 5.0.0 is available at: <https://github.com/ocaml/ocaml/blob/5.0/Changes> Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― The base compiler can be installed as an opam switch with the following commands on opam 2.1: ┌──── │ opam update │ opam switch create 5.0.0~alpha0 └──── For previous version of opam, the switch creation command line is slightly more verbose: ┌──── │ opam update │ opam switch create 5.0.0~alpha0 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> ocaml-variants.5.0.0~alpha0+options <option_list> └──── where `<option_list>' is a comma separated list of `ocaml-option-*' packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 5.0.0~alpha0+flambda+nffa ocaml-variants.5.0.0~alpha0+options ocaml-option-flambda │ ocaml-option-no-flat-float-array └──── The command line above is slightly more complicated for an opam version anterior to opam 2.1: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.5.0.0~alpha0+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── In both cases, all available options can be listed with `opam search ocaml-option'. If you want to test this version, it is strongly advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git └──── This alpha repository contains various fixes in the process of being upstreamed. The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/5.0.0-alpha0.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-5.0/ocaml-5.0.0~alpha0.tar.gz> Daniel Bünzli asked and octachron replied ───────────────────────────────────────── Does this mean we get [global warming] again ? Indeed! I should have mentioned that point! The normal development process can restart on the compiler development branch. I will also try to slowly go through the backlog of frozen PRs once the alpha releases settle down. [global warming] <https://discuss.ocaml.org/t/the-road-to-ocaml-5-0/8584#the-sequential-glaciation-3> Tezt, a framework for all your tests ════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-tezt-a-framework-for-all-your-tests/10038/1> rbardou announced ───────────────── Tezt (pronounced [/tɛzti/]) is a test framework for OCaml that has been developed and used at Nomadic Labs to test [Octez], an OCaml implementation of the Tezos blockchain. It has become quite mature and we feel it would benefit the OCaml community at large, so we are releasing it publicly as a standalone product. Tezt is well-suited for unit tests, integration tests, and regression tests in particular. It was designed with a focus on user experience, with colourful logs, various ways to select the tests to run from the command-line, and more. It integrates well into CI pipelines. And it cleans up after itself, deleting temporary files and killing external processes. Unless you tell it not to, of course. For a more in-depth tour of Tezt, see [our latest blog post entry]. Tezt is available on opam: ┌──── │ opam install tezt └──── Have a look at the [API documentation] and the [source code]. [/tɛzti/] <http://ipa-reader.xyz/?text=t%C9%9Bzti> [Octez] <https://research-development.nomadic-labs.com/announcing-octez.html> [our latest blog post entry] <https://research-development.nomadic-labs.com/announcing-tezt.html> [API documentation] <https://tezos.gitlab.io/api/odoc/_html/tezt/Tezt/index.html> [source code] <https://gitlab.com/tezos/tezos/-/tree/master/tezt/lib> OCaml Stdlib, Containers, Batteries, Base and F# core functions comparisons ═══════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-stdlib-containers-batteries-base-and-f-core-functions-comparisons/10041/1> Jp R announced ────────────── <https://github.com/Fourchaux/OCaml-Stdlib_Containers_Batteries_Base-and-FSharp--core-functions-comparisons> Comparisons (names/signatures) of the core functions used in: • OCaml Stdlib (v4.41.0) • Containers (v3.8) • Batteries (v3.5.1) • Base (v0.15.0) • F# (v6.0) as a bonus Note: F# provides an Array.Parallel module with some functions (choose, collect, init, iter, iteri, map, mapi, partition) which could be good candidates for OCaml 5.0.0… Dune 3.3.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-3-0/10048/1> Etienne Millon announced ──────────────────────── On behalf of the dune team, I’m pleased to announce the release of version 3.3.0. This is the first version that supports the upcoming OCaml 5.0. It also improves safety by sandboxing more rules and enabling more warnings, and there's a bunch of new features on the coq side too. Full changelog follows. Note that as usual, dune works hard not to break existing packages. So even if it mentions that rules require precise dependencies, for example, this new safety net is only enabled for project that use `(lang dune 3.3)'. Happy hacking. 3.3.0 (17-06-2022) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Sandbox preprocessing, lint, and dialect rules by default. All these rules now require precise dependency specifications (#5807, @rgrinberg) • Allow list expansion in the `pps' specification for preprocessing (#5820, @Firobe) • Add warnings 67-69 to dune's default set of warnings. These are warnings of the form "unused X.." (#5844, @rgrinberg) • Introduce project "composition" for coq theories. Coq theories in separate projects can now refer to each other when in the same workspace (#5784, @Alizter, @rgrinberg) • Fix hint message for `data_only_dirs' that wrongly mentions the unknown constructor `data_only' (#5803, @lambdaxdotx) • Fix creating sandbox directory trees by getting rid of buggy memoization (#5794, @rgrinberg, @snowleopard) • Handle directory dependencies in sandboxed rules. Previously, the parents of these directory dependencies weren't created. (#5754, @rgrinberg) • Set the exit code to 130 when dune is terminated with a signal (#5769, fixes #5757) • Support new locations of unix, str, dynlink in OCaml >= 5.0 (#5582, @dra27) • The `coq.theory' stanza now produces rules for running `coqdoc'. Given a theory named `mytheory', the directory targets `mytheory.html/' and `mytheory.tex/' or additionally the aliases `@doc' and `@doc-latex' will build the HTML and LaTeX documentation repsectively. (#5695, fixes #3760, @Alizter) • Coq theories marked as `(boot)' cannot depend on other theories (#5867, @ejgallego) • Ignore `bigarray' in `(libraries)' with OCaml >= 5.0. (#5526, fixes #5494, @moyodiallo) • Start with :standard when building the ctypes generated foreign stubs so that we include important compiler flags, such as -fPIC (#5816, fixes #5809). 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 28465 bytes --]
[-- Attachment #1: Type: text/plain, Size: 9063 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 21 to 28, 2022. The mailing list mode of discuss.ocaml.org seems to have been down for a few days, so I had to manually scrape the messages. My apologies if I missed any. Table of Contents ───────────────── An amusing use of first-class modules: reading from plaintext and compressed files Lwt.5.6.0 (and other Lwt packages) Old CWN An amusing use of first-class modules: reading from plaintext and compressed files ══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/an-amusing-use-of-first-class-modules-reading-from-plaintext-and-compressed-files/10073> Chet_Murthy explained ───────────────────── I was recently trying to write a thing in Rust, and having problems, so I wrote the same thing in OCaml, just to make sure that it was doable. I thought I’d post about it, b/c maybe it’s an example of what we’ll find more tractable, once we have modular implicits. The problem: I have both compressed and plaintext files, and I want to run a function over the uncompressed contents. I’d like a combinator that I can apply to the filename and the function, that will do the work of opening the file, calling the function, closing the file, etc. This isn’t so hard. 1. define a type of READER (and two instances for plaintext and gzipped). This is the equivalent of Rust’s “io::BufRead”. ┌──── │ module type READER = │ sig │ type in_channel │ val open_in : string -> in_channel │ val input_char : in_channel -> char │ val close_in : in_channel -> unit │ end │ let stdreader = (module Stdlib : READER) ;; │ let gzreader = (module Gzip : READER) ;; └──── 2. then define a type of “in channel user” (“ICUSER”) and the generic version of it ┌──── │ module type ICUSER = sig │ type in_channel │ val use_ic : in_channel -> unit │ end │ module type GENERIC_ICUSER = functor (R : READER) -> (ICUSER with type in_channel = R.in_channel) └──── 3. then define our function that takes a generic in_channel, and uses it – “Cat” ┌──── │ module Cat(R : READER) : ICUSER with type in_channel = R.in_channel = struct │ type in_channel = R.in_channel │ let use_ic ic = │ let rec rerec () = │ match R.input_char ic with │ c -> print_char c ; rerec () │ | exception End_of_file -> () │ in rerec () │ end └──── 4. And then write our “with_input_file” function, that takes a filename, the function from #3, and applies it to either a normal in_channel, or one produced from a gzip-reader. ┌──── │ let with_input_file fname (module R : GENERIC_ICUSER) = │ let (module M : READER) = │ if Fpath.(fname |> v |> has_ext "gz") then │ gzreader │ else stdreader in │ let open M in │ let ic = M.open_in fname in │ let module C = R(M) in │ try let rv = C.use_ic ic in close_in ic ; rv │ with e -> close_in ic ; raise e └──── And now we can use it: ┌──── │ with_input_file "/etc/passwd" (module Cat) ;; │ with_input_file "foo.gz" (module Cat) ;; └──── Easy-peasy. I don’t remember enough about the modular implicits proposal to remember if this can be cast in the supported language there, so I suppose I should get some version of that code (or the newer versions from others) up-and-running, and see if this can be made to work. hyphenrf asked and Chet_Murthy replied ────────────────────────────────────── can’t we get rid of the `GENERIC_ICUSER' requirement and just ask for functions that take a packed module of type `READER' by that I mean the signature of `with_input_file' becomes `string -> ((module READER) -> 'a) -> 'a' It’s a good question, and as a newbie user of first-class modules, I don’t know the typing rules well enough to answer. But I did try: ┌──── │ let with_input_file' fname f = │ let (module M : READER) = │ if Fpath.(fname |> v |> has_ext "gz") then │ gzreader │ else stdreader in │ let open M in │ let ic = M.open_in fname in │ f (module M : READER) ic └──── and got ┌──── │ File "ioabs.ml", line 96, characters 24-26: │ 96 | f (module M : READER) ic │ ^^ │ Error: This expression has type M.in_channel │ but an expression was expected of type 'a │ The type constructor M.in_channel would escape its scope └──── ETA: I remember in the modular implicits paper, that there was a lot of wrappering code in structs (that didn’t start off in structs). I wonder if that’s evidence that you really do have to “push up” code to the module level in order to make it work. octachron then said ─────────────────── You don’t need modular implicits to simplify your code. Your packed module type is equivalent to: ┌──── │ type channel = { input_char: unit -> char; close_in: unit -> unit } │ type channel_generator = string -> channel └──── We could go fancy and manifest the type with an existential ┌──── │ type 'a channel = │ { open_fn: string -> 'a; input_char: 'a -> char; close_in: 'a -> unit } │ type chan = Any: 'a channel -> chan └──── but this has mainly the advantage to illustrate the fact that you are never using the non-existentially qualified `'a channel' which means that in the current version of your code, modular (explicits or) implicits is not a good fit: we are not selecting a module to provide functions for a type, we have an object (aka an existentially qualified record) with some hidden inner type that we never need to know. c-cube later said ───────────────── I think it’s kind of counter-productive to want a `in_channel' type at all. This is what I’ve been doing, more and more: ┌──── │ module type INPUT = sig │ val read_char : unit -> char │ val read : bytes -> int -> int -> int │ val close : unit -> unit │ end │ │ type input = (module INPUT) │ │ let open_file (filename:string) : input = │ let ic = open_in filename in │ (module struct │ let read_char() = input_char ic │ let read = input ic │ let close() = close_in ic │ end) │ │ │ let do_sth (module IN:INPUT) = │ IC.read_char (); │ IC.read … └──── This behaves like classic objects in other languages and there’s no complicated typing going on (what with each implementation having its own channel type). Lwt.5.6.0 (and other Lwt packages) ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-6-0-and-other-lwt-packages/10077> raphael-proust announced ──────────────────────── It is a real pleasure to announce the release of Lwt version 5.6.0 as well as Lwt-domain.0.2.0, Lwt-ppx.2.1.0 and Lwt-react.1.2.0. With this release Lwt is now compatible with OCaml version 5. <https://github.com/ocsigen/lwt/releases/tag/5.6.0> Thank you to the many contributors for the fixes, the improvements, and the OCaml5 compatibility! Check out the changelog for full details on each contribution. 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 27825 bytes --]
[-- Attachment #1: Type: text/plain, Size: 17974 bytes --] Hello Here is the latest OCaml Weekly News, for the week of June 28 to July 05, 2022. Table of Contents ───────────────── An amusing use of first-class modules: reading from plaintext and compressed files TLS signature with opam:tls Open Source tooling engineer at Jane Street Dune how to define custom build task Lwt.5.6.0 (and other Lwt packages) Windows-friendly OCaml 4.12 distribution - Diskuv OCaml 0.1.0 OCamlFormat Web Configurator Release of optiml-transport Old CWN An amusing use of first-class modules: reading from plaintext and compressed files ══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/an-amusing-use-of-first-class-modules-reading-from-plaintext-and-compressed-files/10073/9> Continuing this thread, Maëlan asked and Simon Cruanes replied ────────────────────────────────────────────────────────────── You got me curious: what’s the reason for using a first-class module here instead of a record or an object? Of course! • compared to records, I find first-class modules to be a lot more convenient for this use case. I still use records for _data_, but a record-of-function is often less convenient. For example, modules allow you to use `include', they directly handle down-casting as a way to hide internal state (whereas for modules you need to close over values created before the record); module types are structural, so I don't need to worry about disambiguation, whereas records need more care there. In terms of performance both seem exactly the same, from my toy benchmarks. • compared to objects, first-class modules are a bit less convenient (no runtime-free cast, no true inheritance/mixin), but LSP and other tools are fragile. In addition, invoking an object method seems to be roughly twice as slow as a record/module field access — I suppose it's because the latter is just an access via offset. That's on a micro benchmark so in reality it might be worse. TLS signature with opam:tls ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/tls-signature-with-opam-tls/9399/10> Marcus Rohrmoser announced ────────────────────────── just implemented key generation <https://codeberg.org/mro/seppo/src/branch/develop/lib/as2.ml#L95> Open Source tooling engineer at Jane Street ═══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-open-source-tooling-engineer-at-jane-street/10083/1> Yaron Minsky announced ────────────────────── We're looking to hire someone to join our build-systems team with a focus on open-source tooling. We currently release almost a million lines of code of our internal libraries and tools, including things like Sexplib, Base, Core, Async, Incremental, Bonsai, Hardcaml, memtrace-viewer, and patdiff. We have internal tooling for moving code from our internal repositories to Github and for publishing to opam, and for ferrying information back from Github to our internal tools, so that developers can more easily and promptly respond to PRs and issues coming from the outside. We want to make open-sourcing our code better and faster, so it's easier for us to work with outside contributors, and improvements can get out to the community more quickly. Your work would be to make our releases delightfully easy and reliable! I wrote a bit more about it here: <https://twitter.com/yminsky/status/1536766031313739776?s=20&t=sCyUlHGHO1y3znBh4pl0Xw> If you're interested, go ahead and make an [ordinary application] to our software engineering role, and mention that you're interested in "open-source tooling". We're happy to hire for this role in both London and New York. [ordinary application] <https://www.janestreet.com/join-jane-street/apply/> Dune how to define custom build task ════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/dune-how-to-define-custom-build-task/10092/1> cnmade explained ──────────────── dune has very powerful extensions, but the documentation doesn't tell you directly. Today I'll share a specific example of how we can make dune do many things with a dune configuration. For example • Publish compiled documents to our documentation server • Sending email notifications to email groups • Sending SMS notifications to administrators • Build a document and open a browser to preview the document page Let's start with an example, we create a dune file in the root directory of our project, which you may not have originally, you have to create a new one, we enter the following ┌──── │ ; now we tell you how to define a custom rule │ ; rule start with (rule ) │ (rule │ ; (alias is point the command name , so you can run this rule by call dune build @docopen │ (alias docopen) │ ; following line is very important, it tell dune do not cache this build command, so it will running every call │ without any cache │ (deps (universe)) │ ; action (system to told system run command by `sh` in your Linux/MacOS, windows user may running cmd.exe │ ; cd ../.. is change the base directory of the running command ,or the default directory will be _build/default │ (action (system "cd ../.. && pwd && dune build @doc && open _build/default/_doc/_html/index.html" )) │ ) │ ; end of one piece of rule │ │ ; and we define more and more rule as we want │ (rule │ (alias whoami) │ (deps (universe)) │ (action (system "uname -a;whoami")) │ ) └──── In this example, we define two rules, the rules are the tasks that dune can recognize, in dune, it is called rules Because it is a custom build command, we use alias to take a unique and non-repeating alias. The first build command is to build the document and open the browser preview. Our alias is docopen Then deps we add universe to tell dune that you don't want to cache and give me a new build every time. If you don't add this line, dune will only give you one build, and then because of the cache, you won't be able to execute it later. action following by system here, action is the command to start, system means to use the system shell (windows is cmd, linux macos is sh) to give you the execution of the code you specify. You can see the first we are first change the directory to the project root directory [because the default directory is _build/default], and then we perform the build document generation, and then open open the generated html page. The first build command is this, if you want to perform the first build task, you can type `dune build @docopen' Then our second build command, relatively simple, with reference to the first, we can add a lot of build commands we want to add inside this dune configuration file. We just need to specify different alias aliases for them, no duplication. The official documentation also specifies some other available commands, I won't go into them one by one. Since I prefer to use shell scripts, I really only need the system to execute my shell scripts for me. Lwt.5.6.0 (and other Lwt packages) ══════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-lwt-5-6-0-and-other-lwt-packages/10077/2> Raphaël Proust announced ──────────────────────── Lwt 5.6.1 ╌╌╌╌╌╌╌╌╌ Version 5.6.1 of the Lwt package has been released. This version contains a fix for a bug introduced in 5.6.0 whereby devnull file descriptor would be closed during some uses of `Lwt_process'. <https://github.com/ocsigen/lwt/releases/tag/5.6.1> Windows-friendly OCaml 4.12 distribution - Diskuv OCaml 0.1.0 ═════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-windows-friendly-ocaml-4-12-distribution-diskuv-ocaml-0-1-0/8358/21> jbeckford announced ─────────────────── The 0.4.0 release of Diskuv OCaml for Windows users is available! It is usable enough that I've let my school-age kids (elementary through high school) install it and go through some tutorials. <https://github.com/diskuv/dkml-installer-ocaml#readme> The links to the documentation are available from the above link as well. Here are the one-time inconveniences if you install this release: 1. The built-in antivirus Windows Defender treats newly signed binaries like spam. There needs to be enough people who "Report this file as safe" before the binaries are trusted. /If you do nothing but mark it safe or install it on Windows, you are helping others!/ 2. The installer will automatically install the Visual Studio compiler if needed. But Visual Studio sometimes requires a reboot. The instructions will tell you if you need the reboot. 3. The Visual Studio Code OCaml plugin defaults to expecting a legacy `ocamlenv' program on Windows. You have to search for `ocamlenv' in Visual Studio Code Settings and disable it. This should have a fix, but not in time for this release. Windows parity with Unix ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ 1. `opam' commands like `opam install' should work without any wrappers. But you should create new switches with `opam dkml init' (see `--help' for options). 2. `dune' commands like `dune build' should work without any wrappers. The only hiccup is that aliases like `dune build @runtest' need to be escaped in PowerShell like: ┌──── │ dune build `@runtest └──── 3. You have partial support if your home directory has spaces, since it is very common on Windows to have your username be `FirstName LastName'. So far I've configured/patched most things to work with spaces, but there could be common packages that were missed, and only NTFS drives work. 4. OCaml 4.12.1. I'd like to upgrade to 4.13 or 4.14, but having support for Visual Studio Code debugging with [4.12-only ocamlearlybird] is more important, especially for traditional Windows users. 5. Dune 2.9.3. I've bundled in support in 2.9.3 for fswatch/inotify so that `dune build --watch' works on Windows. Nothing is blocking an upgrade to 3.x except time (ie. not now) and a reason. 6. Opam 2.1.2 plus some PRs that are pending the not-yet-released version 2.2. 7. Git performance on Windows just sucks. It is like someone designed it for a Linux kernel 🤨. Apparently [Git FSMonitor in 2.37.0] can be enabled to speed things up, but I don't have real-world experience with it because it was just released yesterday. 8. MSYS2, which can be accessed with `with-dkml bash', now uses the CLANG64 variant. There are thousands of up-to-date third-party libraries available and, unlike MinGW, they are ABI compatible with the dominant Windows compiler (MSVC). And if you are interested there is an [ocamlverse Help Wanted] to add the CLANG64 compiler as an alternative to the Administrator-requiring, reboot-needing MSVC compiler. Thanks to OCaml Software Foundation for sponsoring this! 0.4.x will be the last minor versions of the "preview". I'll be shifting to closing out any show-stopping bugs, and updating the various Windows onboarding guides for OCaml to officially include Diskuv OCaml. [4.12-only ocamlearlybird] <https://github.com/hackwaly/ocamlearlybird/issues/38> [Git FSMonitor in 2.37.0] <https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/> [ocamlverse Help Wanted] <https://ocamlverse.github.io/content/help_wanted.html> OCamlFormat Web Configurator ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-web-configurator/10103/1> Louis Roché announced ───────────────────── It is my pleasure to share with you the [ocamlformat configurator] as a web page. Ocamlformat is a great tool that really makes editing code a more pleasant experience. It has a bunch of different built in profiles and many additional options to fine tune how the code should look like. While I would encourage most people and new projects to use one of the default profiles, the many options are helpful when transitioning an existing codebase. Unfortunately it is not super easy to figure out which options to use and how to combine them. There are [58 parameters]! I've spent a long time trying different combinations by changing an option in my .ocamlformat, running `dune build @fmt`, checking the code, going back to the first step… It is a tedious work. So I decided to make a simple web interface with all of the options available and a faster feedback loop. <https://global.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/2/24e891e9e1400d4a47debf9e34b3ea414bebf418_2_1380x826.jpeg> Thanks to js_of_ocaml the task was not too complicated. Ocamlformat can be compiled to javascript, there is nothing special to do. Which means everything can be done in the browser, the code won't leak to anyone, there is no need to maintain a server, and the result will be guaranteed to be identical as a formatting with the cli tool. The configuration can be set through text (just put the content of your `.ocamlformat` in the text box) and through a bunch of dropdown. They will be combined together. The dropdown takes precedence over the textual configuration if an option is set in both. The project has been started as part of the "open source day" at Ahrefs (we try to dedicate some time to open source projects that we use internally). It is still in its infancy. Please pardon the terrible style, I am not a web developer and didn't have time to make it look nicer yet. There are some annoying things to fix (no feedback when the code is invalid and can't be formatted), and many improvements to come (a way to download the configuration for example). But I think that it is already working well enough to be used by others. You can find the configurator at <https://ahrefs.github.io/ocamlformat/> The source code is on github at <https://github.com/ahrefs/ocamlformat/tree/ahrefs/web-ui/bin/web-ui> If you like ocaml and want to look for a job, we have some [positions available] [ocamlformat configurator] <https://ahrefs.github.io/ocamlformat/> [58 parameters] <https://raw.githubusercontent.com/ocaml-ppx/ocamlformat/main/ocamlformat-help.txt> [positions available] <https://ahrefs.com/jobs> Release of optiml-transport ═══════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-optiml-transport/10128/1> Igarnier announced ────────────────── Hi! [optiml-transport] was just released on opam. This library binds C++ primitives to solve the [optimal transportation](<https://en.wikipedia.org/wiki/Transportation_theory_(mathematics)>) problem between finite weighted point clouds (i.e. finite measures). Concretely, this allows to lift any [metric] on a base space to a metric on finitely supported probability measures over that base space. (In fact, the library works with cost functions more general than that satisfying the metric axioms.) The library also outputs an optimal coupling between any two such measures. Optimal transportation has many applications in statistics, graphics, optimization, etc. The library consists in bindings to <https://github.com/nbonneel/network_simplex> [optiml-transport] <https://github.com/igarnier/optiml-transport> [metric] <https://en.wikipedia.org/wiki/Metric_space> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 29182 bytes --]
[-- Attachment #1: Type: text/plain, Size: 17052 bytes --] Hello Here is the latest OCaml Weekly News, for the week of July 05 to 12, 2022. Table of Contents ───────────────── Dune how to define custom build task Timedesc 0.8.0 - modern date time handling containers 3.9 OBazl 2.0.0-alpha-1 (Building OCaml SW with Bazel) QCheck 0.19 Opam-cross-windows now supports OCaml 4.14.0! Other OCaml News Old CWN Dune how to define custom build task ════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/dune-how-to-define-custom-build-task/10092/1> cnmade explained ──────────────── dune has very powerful extensions, but the documentation doesn't tell you directly. Today I'll share a specific example of how we can make dune do many things with a dune configuration. For example • Publish compiled documents to our documentation server • Sending email notifications to email groups • Sending SMS notifications to administrators • Build a document and open a browser to preview the document page Let's start with an example, we create a dune file in the root directory of our project, which you may not have originally, you have to create a new one, we enter the following ┌──── │ ; now we tell you how to define a custom rule │ ; rule start with (rule ) │ (rule │ ; (alias is point the command name , so you can run this rule by call dune build @docopen │ (alias docopen) │ ; following line is very important, it tell dune do not cache this build command, so it will running every call │ without any cache │ (deps (universe)) │ ; action (system to told system run command by `sh` in your Linux/MacOS, windows user may running cmd.exe │ ; cd ../.. is change the base directory of the running command ,or the default directory will be _build/default │ (action (system "cd ../.. && pwd && dune build @doc && open _build/default/_doc/_html/index.html" )) │ ) │ ; end of one piece of rule │ │ ; and we define more and more rule as we want │ (rule │ (alias whoami) │ (deps (universe)) │ (action (system "uname -a;whoami")) │ ) └──── In this example, we define two rules, the rules are the tasks that dune can recognize, in dune, it is called rules Because it is a custom build command, we use alias to take a unique and non-repeating alias. The first build command is to build the document and open the browser preview. Our alias is docopen Then deps we add universe to tell dune that you don't want to cache and give me a new build every time. If you don't add this line, dune will only give you one build, and then because of the cache, you won't be able to execute it later. action following by system here, action is the command to start, system means to use the system shell (windows is cmd, linux macos is sh) to give you the execution of the code you specify. You can see the first we are first change the directory to the project root directory [because the default directory is _build/default], and then we perform the build document generation, and then open open the generated html page. The first build command is this, if you want to perform the first build task, you can type `dune build @docopen' Then our second build command, relatively simple, with reference to the first, we can add a lot of build commands we want to add inside this dune configuration file. We just need to specify different alias aliases for them, no duplication. The official documentation also specifies some other available commands, I won't go into them one by one. Since I prefer to use shell scripts, I really only need the system to execute my shell scripts for me. Timedesc 0.8.0 - modern date time handling ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-timedesc-0-8-0-modern-date-time-handling/10138/1> Darren announced ──────────────── I'm pleased to announce the release of Timedesc 0.8.0. Timedesc is a very comprehensive date time handling library with good support of time zone. [Homepage] [Homepage] <https://github.com/daypack-dev/timere> Features ╌╌╌╌╌╌╌╌ • Timestamp and date time handling with platform independent time zone support • Subset of the IANA time zone database is built into this library • Supports Gregorian calendar date, ISO week date, and ISO ordinal date • Supports nanosecond precision • ISO8601 parsing and RFC3339 printing Main changes since 0.6.0 ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Significantly reduced size of time zone database by using a custom compression scheme • Many thanks to @glennsl for the proposed scheme at issue [#46] • This yields reduction of roughly 82% for same date period. The exact range of years included has been tuned slightly as well and I've lost track of the exact size after compilation. • Significantly reduced the number of dependencies, and moved JS, JSON code into separate packages • Removed dependencies: `fmt', `containers', `oseq' • Introduced `sexplib' dependency for sexp handling consequently as previously containers `CCSexp' was used • Moved JSON code into `timedesc-json' package along with Yojson dependency • Moved `tzlocal' and `tzdb' stuff into their own separate packages (`timedesc-tzlocal' and `timedesc-tzdb' respectively) • Moved JS tzlocal backend into `timedesc-tzlocal-js' (along with JS specific dependencies) [#46] <https://github.com/daypack-dev/timere/issues/46> Quality of life changes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Updated string conversion functions based on pretty printers which raise `Date_time_cannot_deduce_offset_from_utc' to raise the exception instead of returning `None' • This simplifies the handling as return type is now simply just `string' • And for serious stuff users are expected to use only unambiguous date times anyway, which would not trigger this exception • Added ISO8601 printing facilities to `Timestamp' module for consistency • They are just aliases to the RFC3339 printers containers 3.9 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-containers-3-9/10140/1> Simon Cruanes announced ─────────────────────── I'm happy to announce that containers 3.9 has just been released. Containers is a lightweight, modular extension of the stdlib that tries to remains compatible with it. Containers is starting to sprout some serialization primitives: it now has codecs for Bencode and CBOR. This release also contains a revamp of the testlib system (bye qtest) and the use of ocamlformat, for potential contributors who enjoy that. Containers should also be compatible with OCaml 5.0. OBazl 2.0.0-alpha-1 (Building OCaml SW with Bazel) ══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/obazl-2-0-0-alpha-1-building-ocaml-sw-with-bazel/10142/1> Gregg Reynolds announced ──────────────────────── I've tagged alpha versions of OBazl [rules_ocaml] and [tools_opam]. The best way to start exploring is via [demos_obazl], which contains over 100 mostly simple demo/test programs, many of which are commented. Three simple commands get you configured and then `bazel test test' runs all the tests. Tested on MacOS 12.4 and Ubuntu 20. Documentation is still in progress but there is useful info at [The OBazl Book]. Lot's of things to say about this version but I'll stick to one point of interest. The four basic OCaml compilers are modeled by Bazel's platforms and toolchains mechanisms. Two of the compilers are actually cross-compilers (e.g. `ocamlc.opt' runs on the system arch but targets the OCaml vm), so to pick a compiler you tell OBazl which buildhost and targethost platforms you want. I've predefined configurations in [.bazelrc]; for example: ┌──── │ build:bcnc --host_platform=@opam//tc/host/build:bc │ build:bcnc --platforms=@opam//tc/host/target:nc └──── which means to select the `ocamlopt.byte' (cross-)compiler, pass `--config=bcnc'. Kinda cool IMHO. Maybe overkill for the basic compilers, but the mechanism is essential to support remote builds, custom compiler implementations and genuine cross-compilers. Feedback welcome. [rules_ocaml] <https://github.com/obazl/rules_ocaml> [tools_opam] <https://github.com/obazl/tools_opam> [demos_obazl] <https://github.com/obazl/demos_obazl/blob/main/rules_ocaml/README.adoc> [The OBazl Book] <https://obazl.github.io/docs_obazl/> [.bazelrc] <https://github.com/obazl/demos_obazl/blob/main/rules_ocaml/.bazelrc> QCheck 0.19 ═══════════ Archive: <https://discuss.ocaml.org/t/ann-qcheck-0-19/10149/1> Jan Midtgaard announced ─────────────────────── I'm happy to share the release of QCheck 0.19 - a library for property-based testing in OCaml in the style of Haskell's QuickCheck. • GitHub repo: <https://github.com/c-cube/qcheck> • Documentation: <https://c-cube.github.io/qcheck/0.19/> The 0.19 release brings a range of new features and improvements detailed below and combines the effort of several individual contributors. It is now available on opam. Release notes: • new features and feature extensions • add optional `debug_shrink' parameters in alcotest interface and expose default `debug_shrinking_choices' in test runners • add missing `?handler' parameter to `Test.check_cell_exn' • add an option `retries' parameter to `Test.make' et al. for checking a property repeatedly while shrinking. This can be useful when testing non-deterministic code. • add `tup2' to `tup9' for generators • add `Test.make_neg' for negative property-based tests, that are expected not to satisfy the tested property. • add environment variable `QCHECK_LONG_FACTOR' similar to `QCHECK_COUNT' • rename `Gen.opt' to `Gen.option' but keep the old binding for compatibility. • shrinker changes • recursive `list' shrinker with better complexity • `string' shrinker reuses improved `list' shrinker and adds `char' shrinking • function shrinker now shrinks default entry first and benefits from `list' shrinker improvements • replacing the linear-time `char' shrinker with a faster one reusing the bisecting `int' shrinker algorithm • add `Shrink.char_numeral' and `Shrink.char_printable' • add shrinking for `char arbitrary~s ~char', `printable_char', and `numeral_char' • bug fixes • fix function generation affecting reproducability • fix distribution of `QCheck2.printable' which would omit certain characters • use `Float.equal' for comparing `float~s in the ~Observable' module underlying function generators. • documentation updates: • clarify upper bound inclusion in `Gen.int_bound' and `Gen.int_range' • clarify `printable_char' and `Gen.printable' distributions • add missing `string_gen_of_size' and `small_printable_string' documentation • document `QCheck_alcotest.to_alcotest' • fix documented size distribution for `arbitrary' generators `string_gen', `string', `printable_string', `numeral_string', `list', and `array' • fix exception documentation for `check_result', `check_cell_exn', and `check_exn' • fix documentation for the distribution of `Gen.printable' and `printable_char' • fix documentation for the shrinking behaviour of `QCheck2.printable' • internal and test suite changes • add additional expect and unit tests and refactor expect test suite • add a shrinker performance benchmark • remove `--no-buffer' option on `dune runtest' to avoid garbling the test output • make test suite run on 32-bit architectures Opam-cross-windows now supports OCaml 4.14.0! ═════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/opam-cross-windows-now-supports-ocaml-4-14-0/10159/1> Romain Beauxis announced ──────────────────────── Bit of a late announcement but the `opam-cross-windows' project now supports the OCaml compiler version `4.14.0': <https://github.com/ocaml-cross/opam-cross-windows> The `opam-cross-windows' project is part of an initiative started by @whitequark to provide cross-compilation support to existing `opam' packages. This allows users to compile binaries for windows but also android and ios on a linux or macos host. Support for packages is a on best-effort basis and is always looking for more contributors. Adding a package can be a little tricky at times but, if your package uses `dune', the cross-compilation support there is pretty wonderful and makes it pretty easy to add cross-compiled packages. Other OCaml News ════════════════ >From the ocaml.org blog ─────────────────────── Here are links from many OCaml blogs aggregated at [the ocaml.org blog]. • [The Magic of Merlin] • [Thales Cyber@Station F Selection] • [Team Tarides Visits a 17th Century Chateau] • [Functional Conf 2022] • [OCaml 5 Alpha Release] • [Adding Merkle Proofs to Tezos] • [OCaml Matrix: A Virtual World] • [Tarides Sponsors 12th Annual Journées Franciliennes] • [OCaml.org Reboot: User-Centric Design & Content] • [Lightning Fast with Irmin: Tezos Storage is 6x faster with 1000 TPS surpassed] • [Tarides Partners with 50inTech!] • [What's New in MirageOS 4!] [the ocaml.org blog] <https://ocaml.org/blog/> [The Magic of Merlin] <https://tarides.com/blog/2022-07-05-the-magic-of-merlin> [Thales Cyber@Station F Selection] <https://tarides.com/blog/2022-06-28-thales-cyber-station-f-selection> [Team Tarides Visits a 17th Century Chateau] <https://tarides.com/blog/2022-06-23-team-tarides-visits-a-17th-century-chateau> [Functional Conf 2022] <https://tarides.com/blog/2022-06-21-functional-conf-2022> [OCaml 5 Alpha Release] <https://tarides.com/blog/2022-06-15-ocaml-5-alpha-release> [Adding Merkle Proofs to Tezos] <https://tarides.com/blog/2022-06-13-adding-merkle-proofs-to-tezos> [OCaml Matrix: A Virtual World] <https://tarides.com/blog/2022-06-09-ocaml-matrix-a-virtual-world> [Tarides Sponsors 12th Annual Journées Franciliennes] <https://tarides.com/blog/2022-06-02-tarides-sponsors-12th-annual-journ-e-francilienne> [OCaml.org Reboot: User-Centric Design & Content] <https://tarides.com/blog/2022-05-02-ocaml-org-reboot-user-centric-design-content> [Lightning Fast with Irmin: Tezos Storage is 6x faster with 1000 TPS surpassed] <https://tarides.com/blog/2022-04-26-lightning-fast-with-irmin-tezos-storage-is-6x-faster-with-1000-tps-surpassed> [Tarides Partners with 50inTech!] <https://tarides.com/blog/2022-04-19-tarides-partners-with-50intech> [What's New in MirageOS 4!] <https://tarides.com/blog/2022-04-14-what-s-new-in-mirageos-4> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 28556 bytes --]
[-- Attachment #1: Type: text/plain, Size: 18095 bytes --] Hello Here is the latest OCaml Weekly News, for the week of July 12 to 19, 2022. Table of Contents ───────────────── Gopcaml-mode and Gopcaml-mode merlin (0.0.6) - Phoenix release (Support for OCaml 4.14.0!) Sandmark Nightly - Benchmarking as a Service OCamlFormat Web Configurator Jane Street is Hiring Front End Engineers BAP 2.5.0 Release Why I used OCaml to developed a utility to download Jira items Liquidsoap 2.1.0 Vim now highlights types, feedback welcome Other OCaml News Old CWN Gopcaml-mode and Gopcaml-mode merlin (0.0.6) - Phoenix release (Support for OCaml 4.14.0!) ══════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-gopcaml-mode-and-gopcaml-mode-merlin-0-0-6-phoenix-release-support-for-ocaml-4-14-0/10164/1> Kiran Gopinathan announced ────────────────────────── Like the *phoenix*, /Gopcaml-mode/ *rises* again from the ashes!… …this time with support for OCaml 4.14.0 and OCaml 4.13.0 (by popular demand) See the [original release post ] for detailed instructions on how you can install it. [original release post ] <https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310> Screenshots (if you haven't seen them before) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ <https://global.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/abc1ff0b5dbbefe2beb150f2c09148cb5472ece2.gif> <https://global.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1d43e0f42cc17a30053ee4c71460e70e4061f711.gif> Video ╌╌╌╌╌ <https://www.youtube.com/watch?v=KipRuiLXYEo> What's next? ╌╌╌╌╌╌╌╌╌╌╌╌ • Support for OCaml 5.0 • Better ergonomics for piping (i.e `_ |> _') • … you decide! (feature requests/pull requests welcome!) Sandmark Nightly - Benchmarking as a Service ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-sandmark-nightly-benchmarking-as-a-service/10174/1> Shakthi Kannan announced ──────────────────────── Tarides is happy to announce Sandmark Nightly benchmarking as a service. tl;dr OCaml compiler developers can now point development branches at the service and get sequential and parallel benchmark results at <https://sandmark.tarides.com>. [Sandmark] is a collection of sequential and parallel OCaml benchmarks, its dependencies, and the scripts to run the benchmarks and collect the results. Sandmark was developed for the Multicore OCaml project in order to (a) ensure that OCaml 5 (with multicore support) does not introduce regressions for sequential programs compared to sequential OCaml 4 and (b) OCaml 5 programs scale well with multiple cores. In order to reduce the noise and get actionable results, Sandmark is typically run on [tuned machines]. This makes it harder for OCaml developers to use Sandmark for development who may not have tuned machines with a large number of cores. To address this, we introduce Sandmark Nightly service which runs the sequential and parallel benchmarks for a set of compiler /variants/ (branch/commit/PR + compiler & runtime options) on two tuned machines: • Turing (28 cores, Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz, 64 GB RAM) • Navajo (128 cores, AMD EPYC 7551 32-Core Processor, 504 GB RAM) OCaml developers can request their development branches to be added to the nightly runs by adding it to [sandmark-nightly-config]. The results will appear the following day at <https://sandmark.tarides.com>. Here is an illustration of sequential benchmark results from the service: <https://i.imgur.com/Mn7VZky.png> You should first specify the `number of variants' that you want for comparison, and then select either the `navajo' or `turing' hostnames. The dates for which benchmark results are available are then listed in the `date' column. If there are more than one result on a given day, then the specific variant name, SHA1 commit and date are displayed together for selection. You need to choose one of the variants as a baseline for comparison. In the following graph, the `5.1.0+trunk+sequential_20220712_920fb8e' build on the `navajo' server has been chosen as the baseline, and you can see the normalized time (seconds) comparison for the various Sandmark benchmarks for both `5.1.0+trunk+sequential_20220713_c759890' and `5.1.0+trunk+sequential_20220714_606abe8' variants. We observe that the `matrix_multiplication' and `soli' benchmark have become 5% slower as compared to the July 12, 2022 nightly run. <https://i.imgur.com/7b0yS0h.png> Similarly, the normalized MaxRSS (KB) graph for the same baseline and variants chosen for comparison is illustrated below: <https://i.imgur.com/SfMbEiu.png> The `mandelbrot6' and `fannkuchredux' benchmarks have increased the MaxRSS (KB) by 3% as compared to the baseline variant, whereas, the metric has significantly improved for the `lexifi-g2pp' and `sequence_cps' benchmarks. The parallel benchmark speedup results are also available from the Sandmark nightly runs. <https://i.imgur.com/uKFDXCv.png> <https://i.imgur.com/24BGXVZ.png> We observe from the speedup graph that there is not much difference between `5.1.0+trunk+parallel_20220714_606abe8' and the `5.1.0+trunk+decouple_20220706_eb7a38d' developer branch results. The x-axis in the graph represents the number of domains, while the y-axis corresponds to the speedup. The number in the parenthesis against each benchmark refers to the corresponding running time of the sequential benchmark. These comparison results are useful to observe any performance regressions over time. It is recommended to use the `turing' machine results for the parallel benchmarks as it is tuned. If you would like to use Sandmark nightly for OCaml compiler development, please do ping us for access to the [sandmark-nightly-config] repository so that you may add your own compiler variants. [Sandmark] <https://github.com/ocaml-bench/sandmark> [tuned machines] <https://github.com/ocaml-bench/ocaml_bench_scripts#notes-on-hardware-and-os-settings-for-linux-benchmarking> [sandmark-nightly-config] <https://github.com/ocaml-bench/sandmark-nightly-config> OCamlFormat Web Configurator ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-web-configurator/10103/6> Louis Roché announced ───────────────────── Thanks to [Pomba Magar] we now have a code editor with highlighting. It hopefully should also solve the lack of monospace font on safari. <https://global.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/96fb3536409c5553926228f097812d5b63bd6db8_2_1380x798.jpeg> [Pomba Magar] <https://github.com/pjmp> Jane Street is Hiring Front End Engineers ═════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/jane-street-is-hiring-front-end-engineers/10183/1> Matt Russell announced ────────────────────── Jane Street is looking to hire Front End Engineers that want to design and build our next-generation of browser-based tools for operating our trading infrastructure (in OCaml). We’re building tools for expert users, and want to maintain a high UX bar while building tools that are powerful and flexible, so it’s a challenging domain. Ron Minsky wrote a bit more about the role here: <https://twitter.com/yminsky/status/1541605410691596289?s=20&t=yyrhGx7TnNwPIwdZoArpGw> And you can find a link to the job descriptions and the application page here: • NYC: [Front End Software Engineer: Experienced: Jane Street] • LDN: [Front End Software Engineer: Experienced: Jane Street] [Front End Software Engineer: Experienced: Jane Street] <https://www.janestreet.com/join-jane-street/position/6184529002/> [Front End Software Engineer: Experienced: Jane Street] <https://www.janestreet.com/join-jane-street/position/6236002002/> BAP 2.5.0 Release ═════════════════ Archive: <https://discuss.ocaml.org/t/ann-bap-2-5-0-release/10185/1> Ivan Gotovchits announced ───────────────────────── We are proud to announce the 2.5.0 release of the Carnegie Mellon University Binary Analysis Platform (CMU BAP). This is one of the biggest releases of BAP with lots of new [features and bug fixes]. In this release, we significantly improved BAP performance (in some use cases by a factor of three) and reduced memory consumption (up to a factor of two). In addition, we devised a new method for representing floating-point operations that is scalable and efficient and now we enable floating-point lifters for all x86 binaries with little to no extra overhead. The floating-point support for other targets is coming! We also rewrote the ABI specifications and now support dozens of different ABI. The new ABIs support calling conventions for structures and floating-point values and the `bap-c` library was significantly expanded with lots of new functions and types to describe C types and C object layouts. You can install bap with ┌──── │ opam install bap.2.5.0 └──── Do not forget to `opam update' before that. [features and bug fixes] <https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.5.0> Why I used OCaml to developed a utility to download Jira items ══════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/why-i-used-ocaml-to-developed-a-utility-to-download-jira-items/10186/1> Willem Hoek announced ───────────────────── Not a technical post – but my notes on why I decided to used OCaml to develop a small utility that download Jira items to SQLite [https://whoek.com/b/jira-to-sqlite-with-scrumdog] The Hacker News comments here [https://news.ycombinator.com/item?id=32109461] [https://whoek.com/b/jira-to-sqlite-with-scrumdog] <https://whoek.com/b/jira-to-sqlite-with-scrumdog> [https://news.ycombinator.com/item?id=32109461] <https://news.ycombinator.com/item?id=32109461> Liquidsoap 2.1.0 ════════════════ Archive: <https://discuss.ocaml.org/t/ann-liquidsoap-2-1-0/10192/1> Romain Beauxis announced ──────────────────────── Liquidsoap `2.1.0' was just released, some `10 months after the initial release of the ~2.0.x' release cycle! The release is available here: <https://github.com/savonet/liquidsoap/releases/tag/v2.1.0> and should be coming through `opam' pretty soon. 🤔 What is liquidsoap? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Liquidsoap is a statically-typed, type-inferred, functional scripting language equipped with specialized operators to build audio and video stream automation. The liquidsoap language offers all the flexibility and expressivity of a fully featured programming language to help build your media streams. Using liquidsoap, one can very quickly stand up a media streaming platform that can rotate files from playlists, accept live DJ input, mux audio and video, encode (or not!) and send the resulting data to youtube, icecast, HLS and more.. :white_check_mark: Why liquidsoap? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ While there are many tools that offer competing features, the real difference with liquidsoap is its scripting language. Setting up tools using configuration files is often easier and more straight forward, however, when it comes to the finer details, such as inserting jingles between shows, defining crossfades between tracks and more, potentially, each project has its own set of expectations, and this is where liquidsoap becomes really useful! :zap:️ What's new in Liquidsoap 2.1.0? :zap: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Lots of things have been brewing since the `2.0.0' release. This new release branch is intended to bring up some of the breaking changes that were introduced while we keep working on more exciting future changes that we have on our [roadmap] Some noticeable changes include: [roadmap] <https://github.com/savonet/liquidsoap/blob/main/ROADMAP.md> Improved JSON parsing ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ You should now be able to do: ┌──── │ let json.parse ({ │ foo, │ bla, │ gni │ } : { │ foo: string, │ bla: float, │ gni: bool │ }) = '{ "foo": "aabbcc", "bla": 3.14, "gni": true }' └──── For any one who has ever tried to parse json in their liquidsoap scripts, this is gonna be a game changer. We have a detailed article [here] [here] <https://www.liquidsoap.info/doc-dev/json.html> Regular expressions are now first-class entities. ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ This should be familiar to anyone used to working with Javascript's regular expression. So, now, instead of doing: ┌──── │ string.match(pattern="\\d+", s) └──── You will now do: ┌──── │ r/\d+/.test(s) └──── There's a detailed description of this new feature [here]. [here] <https://www.liquidsoap.info/doc-dev/language.html#regular_expressions> Vim now highlights types, feedback welcome ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/vim-now-highlights-types-feedback-welcome/10198/1> Maëlan announced ──────────────── [A patch] just made its way to [the community-maintained Vim files for OCaml] (not propagated to the [official Vim distribution], yet), that tries to highlight types. IMHO the patch is large and hacky so you may want to try it cautiously, and *feedback would be appreciated*. :-) The former behavior was to highlight identifiers that happened to be the name of a builtin type (such as `int' or `list'), regardless of where they appeared. Now, in principle, all type expressions can be highlighted, and be so only when in a type context. By default, only builtin types are highlighted, but you can unleash the full power of the new linter: ┌──── │ " put this in ~/.vim/after/syntax/ocaml.vim for instance: │ hi link ocamlTypeConstr Type │ hi link ocamlTypeBuiltin Type │ hi link ocamlTypeVar Type │ hi link ocamlTypeAnyVar Type └──── or fancier (if you like excess :rainbow:): ┌──── │ " 112 = light green (the color of the “Type“ hl group with my theme) │ hi ocamlTypeConstr ctermfg=112 │ hi ocamlTypeBuiltin ctermfg=112 cterm=bold │ hi ocamlTypeVar ctermfg=112 cterm=italic │ hi ocamlTypeAnyVar ctermfg=112 cterm=bold └──── Even if you don’t care about highlighting types, allowing the linter to discriminate between types and exceptions has some tangential benefits. [A patch] <https://github.com/ocaml/vim-ocaml/pull/76> [the community-maintained Vim files for OCaml] <https://github.com/ocaml/vim-ocaml> [official Vim distribution] <https://github.com/vim/vim/tree/master/runtime> Other OCaml News ════════════════ From the ocaml.org blog ─────────────────────── Here are links from many OCaml blogs aggregated at [the ocaml.org blog]. • [Faster Incremental Builds with Dune 3] [the ocaml.org blog] <https://ocaml.org/blog/> [Faster Incremental Builds with Dune 3] <https://tarides.com/blog/2022-07-12-faster-incremental-builds-with-dune-3> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 30718 bytes --]
[-- Attachment #1: Type: text/plain, Size: 20463 bytes --] Hello Here is the latest OCaml Weekly News, for the week of July 19 to 26, 2022. Table of Contents ───────────────── Help w. my first GADT : unwrapping Sqlite3.Data.t DocuLib 3.1.2 and MetaDB 1.0.2 now on OPAM dune 3.4.0 OCaml 5.0, first normal alpha release Other OCaml News Old CWN Help w. my first GADT : unwrapping Sqlite3.Data.t ═════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/help-w-my-first-gadt-unwrapping-sqlite3-data-t/10202/1> Philippe Strauss asked ────────────────────── I would like to convert sqlite3-ocaml returns from Sqlite3.Data.t array to plain ocaml types in a tuple. I guess unwrapping the Data.t can be done using a GADT, here's my very very first attempt: ┌──── │ (* simulate Sqlite3.Data.t *) │ │ type t = │ | NONE │ | NULL │ | INT of int64 │ | FLOAT of float │ | TEXT of string │ | BLOB of string ;; │ │ (* a simple GADT to unwrap Sqlite3.Data.t *) │ │ type _ dbval = │ | INT : int64 -> int64 dbval │ | FLOAT : float -> float dbval │ | TEXT : string -> string dbval │ | BLOB : string -> string dbval │ | NONE | NULL ;; │ │ let unwrap_data : type a. a dbval -> a = fun dbval -> │ match dbval with │ | INT x -> x │ | FLOAT x -> x │ | TEXT str -> str │ | BLOB str -> str ;; │ │ let tuple_of_array4 (arr: t array) = │ assert (Array.length arr = 4) ; │ (unwrap_data arr.(0), unwrap_data arr.(1), unwrap_data arr.(2), unwrap_data arr.(3)) ;; └──── Compilation fails with this typing error: ┌──── │ File "database.ml", line 233, characters 17-24: │ 233 | (unwrap_data arr.(0), unwrap_data arr.(1), unwrap_data arr.(2), unwrap_data arr.(3)) ;; │ ^^^^^^^ │ Error: This expression has type t but an expression was expected of type │ 'a dbval └──── What am I doing wrong? I need to make type t compatible with type 'a dbval. Thanks in advance. octachron replied ───────────────── You cannot make the type `t' and `'a dbval' compatible, there are different types. A very important point to keep in mind with GADTs is that one cannot create type-level information from dynamical values. In other words, there are no functions of type ~ x : t -> f(x) dbval~that will infer the type of its return from the value of its argument in OCaml. Thus the type of the final result must come from your code source rather than from the dynamical data. For instance, you can define constructor from the type `t' to the right `dbval' type: ┌──── │ exception Type_error │ │ let int: t -> _ dbval = function │ | INT x -> INT x │ | _ -> raise Type_error │ │ let float: t -> _ dbval = function │ | FLOAT x -> FLOAT x │ | _ -> raise Type_error └──── Then if you know the type of the tuple, you can write it as: ┌──── │ let tuple_of_array4 (arr: t array) = │ assert (Array.length arr = 4) ; │ int arr.(0), int arr.(1), int arr.(2), int arr.(3) └──── or possibly as ┌──── │ let int4 = int, int, int, int │ let tuple (a,b,c,d) arr = │ assert (Array.length arr = 4) ; │ a arr.(0), b arr.(1), c arr.(2), d arr.(3) └──── There are more complex alternatives based on type witness, that allow to implement a form of static matching over the dynamical type of data, but the core idea that the types are always present in the source code in some way is the same. Philippe Strauss then said ────────────────────────── Oh I didn't noticed it would be dynamical typing! I'm too used to ppx (and previously camlp4) written db abstraction layer! I'm simply replacing sqlexpr by plain sqlite3-ocaml in some existing code of mine. sqlexpr quick doco: <https://github.com/mfp/ocaml-sqlexpr> But I can live with a Data.t array! Yawar Amin then added ───────────────────── Everybody has their favourite way of wrapping SQLite. Here's mine (no PPX): <https://github.com/yawaramin/ocaml_sql_query> It has a little data translation layer to convert from `Data.t' array to the desired return type. DocuLib 3.1.2 and MetaDB 1.0.2 now on OPAM ══════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/doculib-3-1-2-and-metadb-1-0-2-now-on-opam/10204/1> nguermond announced ─────────────────── I'm pleased to announce the release of `doculib' and `metadb', now available on OPAM. *DocuLib* is a GUI for document management, particularly for all the textbooks and articles you've accumulated but know you'll never read :thinking:. The idea of DocuLib is to keep track of metadata of files stored across multiple libraries on your file system in such a way that you can move, reorganize, or rename a file without losing your metadata. You can additionally lookup metadata on `openlibrary.org' or `semanticscholar.org'. DocuLib will also warn about missing and duplicate files. Stored metadata presently includes author, title, year, tags, and DOI/ISBN. <https://global.discourse-cdn.com/standard11/uploads/ocaml/original/2X/f/fa064cd32bce6e52722d30047d8e0ef21fa09684.png> For more screenshots and details: <https://github.com/nguermond/doculib> *Metadb* is the JSON database for manipulating file metadata underlying DocuLib, in hopes that it may be useful somewhere else. Data is stored in the following way: ┌──── │ path/to/library │ |- .metadata │ |- ./foo.txt.json │ |- ./blah/bar.pdf.json │ |- ./foobar.pdf.json │ |- ./foo.txt │ |- ./blah/bar.pdf │ |- ./foobar.pdf └──── For documentation: <https://github.com/nguermond/metadb> dune 3.4.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-4-0/10211/1> Etienne Millon announced ──────────────────────── On behalf of the dune team, I’m pleased to announce the release of version 3.4.0. Bug fixes, a couple new features, better hints and error messages - I won't restate what's in the changelog below. Thanks to everyone involved in this release! • Make `dune describe' correctly handle overlapping implementations for virtual libraries (#5971, fixes #5747, @esope) • Building the `@check' alias should make sure the libraries and executables don't have dependency cycles (#5892, @rgrinberg) • [ctypes] Add support for the `errno' parameter using the `errno_policy' field in the ctypes settings. (#5827, @droyo) • Fix `dune coq top' when it is invoked on files from a subdirectory of the directory containing the associated stanza (#5784, fixes #5552, @ejgallego, @rlepigre, @Alizter) • Fix hint when an invalid module name is found. (#5922, fixes #5273, @emillon) • The `(cat)' action now supports several files. (#5928, fixes #5795, @emillon) • Dune no longer uses shimmed `META' files for OCaml 5.x, solely using the ones installed by the compiler. (#5916, @dra27) • Fix handling of the `(deps)' field in `(test)' stanzas when there is an `.expected' file. (#5952, #5951, fixes #5950, @emillon) • Ignore insignificant filesystem events. This stops RPC in watch mode from flashing errors on insignificant file system events such as changes in the `.git/' directory. (#5953, @rgrinberg) • Fix parsing more error messages emitted by the OCaml compiler. In particular, messages where the excerpt line number started with a blank character were skipped. (#5981, @rgrinberg) • env stanza: warn if some rules are ignored because they appear after a wildcard rule. (#5898, fixes #5886, @emillon) • On Windows, XDG_CACHE_HOME is taken to be the `FOLDERID_InternetCache' if unset, and XDG_CONFIG_HOME and XDG_DATA_HOME are both taken to be `FOLDERID_LocalAppData' if unset. (#5943, fixes #5808, @nojb) Etienne Millon then added ───────────────────────── This broke 32-bit cygwin installations, so 3.4.1 was released with a fix. OCaml 5.0, first normal alpha release ═════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-5-0-first-normal-alpha-release/10216/1> octachron announced ─────────────────── The stabilisation of OCaml 5.0 has been progressing well during the last month. We have thus released a first normal alpha release of OCaml 5.0.0 to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions). You can follow the progress in stabilising the opam ecosystem on <https://github.com/ocaml/opam-repository/issues/21526> If you find any bugs, please report them here: <https://github.com/ocaml/ocaml/issues> Compared to the zeroth alpha release, this alpha release restores the support for the bytecode debugger, and integrates a change of type in the FFI API that might trigger some warnings in FFI code. We also have a change in the installed files: the compiler distributes now its own META files rather than relying on either findlib or dune to provide those files. This should simplify the tasks of both tools in future version. Note there are still some changes expected in the Effect module before the next candidate release. Generally, both the Effect and Domain modules are still experimental and might change API even during the beta releases. If you are interested by the ongoing list of bug fixes, the updated change log for OCaml 5.0.0 is available at: <https://github.com/ocaml/ocaml/blob/5.0/Changes> A short summary of the changes since the zeroth alpha release is also available below. Installation instructions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The base compiler can be installed as an opam switch with the following commands on opam 2.1: ┌──── │ opam update │ opam switch create 5.0.0~alpha1 └──── For previous version of opam, the switch creation command line is slightly more verbose: ┌──── │ opam update │ opam switch create 5.0.0~alpha1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── If you want to test this version, it is strongly advised to install the alpha opam repository <https://github.com/kit-ty-kate/opam-alpha-repository> with ┌──── │ opam repo add alpha git+https://github.com/kit-ty-kate/opam-alpha-repository.git └──── You can check that the alpha repository has been correctly installed with ┌──── │ $ opam repo │ │ <><> Repository configuration for switch 5.0.0~alpha1 <><><><><><><><><><><><><> │ 1 alpha git+https://github.com/kit-ty-kate/opam-alpha-repository.git │ 2 default https://opam.ocaml.org └──── This alpha repository contains various fixes in the process of being upstreamed which vastly increases the number of opam packages currently compatible with OCaml 5.0.0 . If you want to tweak the configuration of the compiler, you can switch to the option variant with: ┌──── │ opam update │ opam switch create <switch_name> ocaml-variants.5.0.0~alpha1+options <option_list> └──── where `option_list' is a comma separated list of `ocaml-option-*' packages. For instance, for a flambda and no-flat-float-array switch: ┌──── │ opam switch create 5.0.0~alpha1+flambda+nffa ocaml-variants.5.0.0~alpha1+options ocaml-option-flambda │ ocaml-option-no-flat-float-array └──── The command line above is slightly more complicated for opam version anterior to 2.1: ┌──── │ opam update │ opam switch create <switch_name> --packages=ocaml-variants.5.0.0~alpha1+options,<option_list> │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git └──── In both cases, all available options can be listed with `opam search ocaml-option'. The source code for the alpha is also available at these addresses: • <https://github.com/ocaml/ocaml/archive/5.0.0-alpha1.tar.gz> • <https://caml.inria.fr/pub/distrib/ocaml-5.0/ocaml-5.0.0~alpha1.tar.gz> Changes since the zeroth alpha release: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Runtime system: ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#11400]: Runtime events counters fixes Fixes mismatch between OCaml and C APIs, removes events from 4.x that are not present in the 5.0 GC and adds some missing probes. (Sadiq Jaffer, review by Gabriel Scherer, Florian Angeletti) • [#11368]: Runtime events buffer size OCAMLRUNPARAMS fix The runtime events buffer size can now be set via the 'e' OCAMLRUNPARAM. This is previously mistakenly enabled/disabled tracing instead. (Sadiq Jaffer, review by KC Sivaramakrishnan, David Allsopp, Damien Doligez) • [#11304]: Fix data race on Windows file descriptors (Olivier Nicole and Xavier Leroy, review by Xavier Leroy, David Allsopp, and Sadiq Jaffer) • *breaking change* [#11337]: pass 'flags' metadata to root scanners, to optimize stack scanning in the bytecode interpreter. Changes the interface of user-provided root-scanning hooks. (Gabriel Scherer, review by Xavier Leroy, Guillaume Munch-Maccagnoni, Sadiq Jaffer and Tom Kelly) • [#11144]: Restore frame-pointers support for amd64 (Fabrice Buoro, review by Frederic Bour and KC Sivaramakrishnan) • *breaking change* [#11255]: in the C interface, `&Field(v, i)' now has type `volatile value *' instead of `value *' in OCaml 4. This makes the memory model for mixed OCaml/C code better defined, but can cause warnings or type errors in user C code. (KC Sivaramakrishnan, review by Xavier Leroy, Gabriel Scherer and Guillaume Munch-Maccagnoni, additional discussions with Stephen Dolan and Luc Maranget) [#11400] <https://github.com/ocaml/ocaml/issues/11400> [#11368] <https://github.com/ocaml/ocaml/issues/11368> [#11304] <https://github.com/ocaml/ocaml/issues/11304> [#11337] <https://github.com/ocaml/ocaml/issues/11337> [#11144] <https://github.com/ocaml/ocaml/issues/11144> [#11255] <https://github.com/ocaml/ocaml/issues/11255> Standard library: ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#10867], +[#11345]: Remove deprecated values: …, the infix operator (.[ ]<-). (Nicolás Ojeda Bär, review by Damien Doligez) • [#11309], [#11424], [#11427]: Add Domain.recommended_domain_count. (Christiano Haesbaert, Konstantin Belousov, review by David Allsopp, KC Sivaramakrishnan, Gabriel Scherer, Nicolas Ojeda Bar) [#10867] <https://github.com/ocaml/ocaml/issues/10867> [#11345] <https://github.com/ocaml/ocaml/issues/11345> [#11309] <https://github.com/ocaml/ocaml/issues/11309> [#11424] <https://github.com/ocaml/ocaml/issues/11424> [#11427] <https://github.com/ocaml/ocaml/issues/11427> Tools: ┄┄┄┄┄┄ • [#11065]: Port the bytecode debugger to 5.0, adding support for effect handlers. (Damien Doligez and fabbing, review by fabbing and Xavier Leroy) • [#11382]: OCamlmktop use a new initialization module "OCamlmktop_init" to preserve backward-compatibility with user-module provided modules that install toplevel printers. (Florian Angeletti, review by Gabriel Scherer and David Allsopp) [#11065] <https://github.com/ocaml/ocaml/issues/11065> [#11382] <https://github.com/ocaml/ocaml/issues/11382> Installation: ┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#11007], [#11399]: META files for the stdlib, compiler-libs and other libraries (unix, dynlink, str, runtime_events, threads, ocamldoc) are now installed along with the compiler. (David Allsopp, Florian Angeletti, Nicolás Ojeda Bär and Sébastien Hinderer, review by Daniel Bünzli, Kate Deplaix, Anil Madhavapeddy and Gabriel Scherer) [#11007] <https://github.com/ocaml/ocaml/issues/11007> [#11399] <https://github.com/ocaml/ocaml/issues/11399> Bug fixes: ┄┄┄┄┄┄┄┄┄┄ • [#10768], [#11340]: Fix typechecking regression when combining first class modules and GADTs. (Jacques Garrigue, report by François Thiré, review by Matthew Ryan) • [#10790]: don't drop variance and injectivity annotations when pretty printing `with' constraints (for example, `with type +!'a t = ...'). (Florian Angeletti, report by Luke Maurer, review by Matthew Ryan and Gabriel Scherer) • [#11289], [#11405]: fix some leaks on systhread termination (Fabrice Buoro, Enguerrand Decorne, Gabriel Scherer, review by Xavier Leroy and Florian Angeletti, report by Romain Beauxis) • [#11314], [#11416]: fix non-informative error message for module inclusion (Florian Angeletti, report by Thierry Martinez, review by Gabriel Scherer) • [#11358], [#11379]: Refactor the initialization of bytecode threading, This avoids a "dangling pointer" warning of GCC 12.1. (Xavier Leroy, report by Armaël Guéneau, review by Gabriel Scherer) • [#11387], module type with constraints no longer crash the compiler in presence of both shadowing warnings and the `-bin-annot' compiler flag. (Florian Angeletti, report by Christophe Raffalli, review by Gabriel Scherer) [#10768] <https://github.com/ocaml/ocaml/issues/10768> [#11340] <https://github.com/ocaml/ocaml/issues/11340> [#10790] <https://github.com/ocaml/ocaml/issues/10790> [#11289] <https://github.com/ocaml/ocaml/issues/11289> [#11405] <https://github.com/ocaml/ocaml/issues/11405> [#11314] <https://github.com/ocaml/ocaml/issues/11314> [#11416] <https://github.com/ocaml/ocaml/issues/11416> [#11358] <https://github.com/ocaml/ocaml/issues/11358> [#11379] <https://github.com/ocaml/ocaml/issues/11379> [#11387] <https://github.com/ocaml/ocaml/issues/11387> Other OCaml News ════════════════ From the ocaml.org blog ─────────────────────── Here are links from many OCaml blogs aggregated at [the ocaml.org blog]. • [Tarides is on the Wavestone Radar!] [the ocaml.org blog] <https://ocaml.org/blog/> [Tarides is on the Wavestone Radar!] <https://tarides.com/blog/2022-07-19-tarides-is-on-the-wavestone-radar> 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] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 36788 bytes --]