[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- 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 --]