caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alan Schmitt <alan.schmitt@polytechnique.org>
To: "lwn" <lwn@lwn.net>, "cwn"  <cwn@lists.idyll.org>, caml-list@inria.fr
Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
Date: Tue, 25 May 2021 09:30:14 +0200	[thread overview]
Message-ID: <87sg2bgtix.fsf@m4x.org> (raw)

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

             reply	other threads:[~2021-05-25  7:30 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  7:30 Alan Schmitt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-07-26 17:54 Alan Schmitt
2022-07-19  8:58 Alan Schmitt
2022-07-12  7:59 Alan Schmitt
2022-07-05  7:42 Alan Schmitt
2022-06-28  7:37 Alan Schmitt
2022-06-21  8:06 Alan Schmitt
2022-06-14  9:29 Alan Schmitt
2022-06-07 10:15 Alan Schmitt
2022-05-31 12:29 Alan Schmitt
2022-05-24  8:04 Alan Schmitt
2022-05-17  7:12 Alan Schmitt
2022-05-10 12:30 Alan Schmitt
2022-05-03  9:11 Alan Schmitt
2022-04-26  6:44 Alan Schmitt
2022-04-19  5:34 Alan Schmitt
2022-04-12  8:10 Alan Schmitt
2022-04-05 11:50 Alan Schmitt
2022-03-29  7:42 Alan Schmitt
2022-03-22 13:01 Alan Schmitt
2022-03-15  9:59 Alan Schmitt
2022-03-01 13:54 Alan Schmitt
2022-02-22 12:43 Alan Schmitt
2022-02-08 13:16 Alan Schmitt
2022-02-01 13:00 Alan Schmitt
2022-01-25 12:44 Alan Schmitt
2022-01-11  8:20 Alan Schmitt
2022-01-04  7:56 Alan Schmitt
2021-12-28  8:59 Alan Schmitt
2021-12-21  9:11 Alan Schmitt
2021-12-14 11:02 Alan Schmitt
2021-11-30 10:51 Alan Schmitt
2021-11-16  8:41 Alan Schmitt
2021-11-09 10:08 Alan Schmitt
2021-11-02  8:50 Alan Schmitt
2021-10-19  8:23 Alan Schmitt
2021-09-28  6:37 Alan Schmitt
2021-09-21  9:09 Alan Schmitt
2021-09-07 13:23 Alan Schmitt
2021-08-24 13:44 Alan Schmitt
2021-08-17  6:24 Alan Schmitt
2021-08-10 16:47 Alan Schmitt
2021-07-27  8:54 Alan Schmitt
2021-07-20 12:58 Alan Schmitt
2021-07-06 12:33 Alan Schmitt
2021-06-29 12:24 Alan Schmitt
2021-06-22  9:04 Alan Schmitt
2021-06-01  9:23 Alan Schmitt
2021-05-11 14:47 Alan Schmitt
2021-05-04  8:57 Alan Schmitt
2021-04-27 14:26 Alan Schmitt
2021-04-20  9:07 Alan Schmitt
2021-04-06  9:42 Alan Schmitt
2021-03-30 14:55 Alan Schmitt
2021-03-23  9:05 Alan Schmitt
2021-03-16 10:31 Alan Schmitt
2021-03-09 10:58 Alan Schmitt
2021-02-23  9:51 Alan Schmitt
2021-02-16 13:53 Alan Schmitt
2021-02-02 13:56 Alan Schmitt
2021-01-26 13:25 Alan Schmitt
2021-01-19 14:28 Alan Schmitt
2021-01-12  9:47 Alan Schmitt
2021-01-05 11:22 Alan Schmitt
2020-12-29  9:59 Alan Schmitt
2020-12-22  8:48 Alan Schmitt
2020-12-15  9:51 Alan Schmitt
2020-12-01  8:54 Alan Schmitt
2020-11-03 15:15 Alan Schmitt
2020-10-27  8:43 Alan Schmitt
2020-10-20  8:15 Alan Schmitt
2020-10-06  7:22 Alan Schmitt
2020-09-29  7:02 Alan Schmitt
2020-09-22  7:27 Alan Schmitt
2020-09-08 13:11 Alan Schmitt
2020-09-01  7:55 Alan Schmitt
2020-08-18  7:25 Alan Schmitt
2020-07-28 16:57 Alan Schmitt
2020-07-21 14:42 Alan Schmitt
2020-07-14  9:54 Alan Schmitt
2020-07-07 10:04 Alan Schmitt
2020-06-30  7:00 Alan Schmitt
2020-06-16  8:36 Alan Schmitt
2020-06-09  8:28 Alan Schmitt
2020-05-19  9:52 Alan Schmitt
2020-05-12  7:45 Alan Schmitt
2020-05-05  7:45 Alan Schmitt
2020-04-28 12:44 Alan Schmitt
2020-04-21  8:58 Alan Schmitt
2020-04-14  7:28 Alan Schmitt
2020-04-07  7:51 Alan Schmitt
2020-03-31  9:54 Alan Schmitt
2020-03-24  9:31 Alan Schmitt
2020-03-17 11:04 Alan Schmitt
2020-03-10 14:28 Alan Schmitt
2020-03-03  8:00 Alan Schmitt
2020-02-25  8:51 Alan Schmitt
2020-02-18  8:18 Alan Schmitt
2020-02-04  8:47 Alan Schmitt
2020-01-28 10:53 Alan Schmitt
2020-01-21 14:08 Alan Schmitt
2020-01-14 14:16 Alan Schmitt
2020-01-07 13:43 Alan Schmitt
2019-12-31  9:18 Alan Schmitt
2019-12-17  8:52 Alan Schmitt
2019-12-10  8:21 Alan Schmitt
2019-12-03 15:42 Alan Schmitt
2019-11-26  8:33 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-05  6:55 Alan Schmitt
2019-10-15  7:28 Alan Schmitt
2019-09-03  7:35 Alan Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg2bgtix.fsf@m4x.org \
    --to=alan.schmitt@polytechnique.org \
    --cc=caml-list@inria.fr \
    --cc=cwn@lists.idyll.org \
    --cc=lwn@lwn.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).