* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-10-24 9:17 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-10-24 9:17 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 74124 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-04-15 9:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-04-15 9:51 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 17552 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 08 to 15,
2025.
Table of Contents
─────────────────
Semgrep is hiring OCaml developers to help develop our supply chain security product!
Subprocess: a library for launching and communicating with Unix commands
cudajit: Bindings to the `cuda' and `nvrtc' libraries
qcheck-lin and qcheck-stm 0.2
Call for Volunteers to Help Maintain the Opam-Repository
Dune package management update
Ocsigen public meeting
Looking for Maintainers / Moderators for the OCaml Cookbook
SCGI library for OCaml and eio
Other OCaml News
Old CWN
Semgrep is hiring OCaml developers to help develop our supply chain security product!
═════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/semgrep-is-hiring-ocaml-developers-to-help-develop-our-supply-chain-security-product/16464/1>
Aaron Acosta announced
──────────────────────
Semgrep is an application security company focused on detecting and
remediating vulnerabilities. The static analysis engine is primarily
written in OCaml. We're looking for a senior or staff software
engineer to help us enhance our third-party vulnerability detection
capabilities. The ideal candidate has owned a critical tool, has
worked on an OCaml project, has experience leading development teams
and mentoring, and has some experience with supply chain security.
If this sounds interesting to you, see our job posting at
[Senior/Staff Program Analysis Engineer, Supply Chain]! Let me know if
you have any questions!
[Senior/Staff Program Analysis Engineer, Supply Chain]
<https://job-boards.greenhouse.io/semgrep/jobs/4672858007>
Subprocess: a library for launching and communicating with Unix commands
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-subprocess-a-library-for-launching-and-communicating-with-unix-commands/16467/1>
Aaron Christianson announced
────────────────────────────
_An OCaml library with *[documentation]!?*_
Yes. I realize it's unorthodox, but I thought I'd give it a shot.
I began my programming journey a bit later than most, and I began it
with Bash. Over the years I've grown apart from Bash and even written
some semi-popular [anti-Bash propaganda].
However, while I'm not particularly a fan of shell programming
languages, I've maintained a long-term interest in the types of
automation tasks which the shell lends itself to, and I have a soft
spot in my heart for languages which make this type of programming a
priority—languages such as AWK, Perl and Ruby.
Since learning OCaml, I always felt that it could be a good language
for these kinds of jobs with its light syntax, extensive Unix
interface and great regex libraries (I'm talking about `Re' and
friends, not `Str').
However, I always felt the provided interfaces for working with
processes were… not quite what I was looking for. `Sys.command'
(combined with `Filename.quote_command', of course) is OK for what it
does, but it doesn't do much. The more extensive set of process
handling commands in the Unix library make just about anything
possible, but they don't _feel good_ to me.
So I set out to create a library for working with Unix commands which
feels right to me. Subprocess focuses on *safety* and *ease of use*—in
that order. I hope someone besides myself will feel the same about it.
Note that this is the first release (and my first public OCaml
library) and I welcome feedback and criticism.
• Github: <https://github.com/ninjaaron/ocaml-subprocess>
• Opam: <https://ocaml.org/p/subprocess/latest>
• Odoc docs:
<https://ninjaaron.github.io/ocaml-subprocess/subprocess/index.html>
[documentation]
<https://ninjaaron.github.io/ocaml-subprocess/subprocess/index.html>
[anti-Bash propaganda]
<https://github.com/ninjaaron/replacing-bash-scripting-with-python>
cudajit: Bindings to the `cuda' and `nvrtc' libraries
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cudajit-bindings-to-the-cuda-and-nvrtc-libraries/15010/3>
Lukasz Stafiniak announced
──────────────────────────
cudajit 0.7.0 is now available in the opam repository. It is now split
into separate libraries covering NVRTC bindings and CUDA bindings, so
that `Nvrtc' doesn't need CUDA drivers to run.
Version 0.7.0 brings full native Windows compatibility.
Version 0.6.0 improves memory safety and debuggability.
cudajit.0.7.0 can be used with OCANNL neural_nets_lib.0.5.2 also in
the opam repository. Enjoy!
qcheck-lin and qcheck-stm 0.2
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm-0-2/12301/6>
Jan Midtgaard announced
───────────────────────
Version 0.8 of `qcheck-lin', `qcheck-stm', and
`qcheck-multicoretests-util' was just merged on the opam repository:
<https://github.com/ocaml-multicore/multicoretests/releases/tag/0.8>
The 0.8 release improves the error finding ability of the `Lin_thread'
and `STM_thread' modes:
• [#540]: Significantly increase the probability of context switching
in `Lin_thread' and `STM_thread' by utilizing `Gc.Memprof'
callbacks. Avoid on 5.0-5.2 without `Gc.Memprof' support.
• [#546]: Speed up `Lin''s default `string' and `bytes' shrinkers.
• [#547]: Add `Util.Pp.{cst4,cst5}'
Happy testing! :smiley:
[#540] <https://github.com/ocaml-multicore/multicoretests/pull/540>
[#546] <https://github.com/ocaml-multicore/multicoretests/pull/546>
[#547] <https://github.com/ocaml-multicore/multicoretests/pull/547>
Call for Volunteers to Help Maintain the Opam-Repository
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/call-for-volunteers-to-help-maintain-the-opam-repository/16476/1>
Shon announced
──────────────
*The opam-repository needs your help! :camel::heart:*
*tl;dr*: Want to grow your OCaml connections and expertise while
supporting a pillar of the ecosystem? Then join us as an
opam-repository maintainer by commenting on the issue [Volunteer to
Maintain the opam Repository :raised_hand_with_fingers_splayed:]!
The [opam-repository] is the official store of package descriptions
for the extended OCaml ecosystem. It serves more than 4400 packages
thru the `opam' package manager and index, and it is approaching 200
new packages and releases per month. The `opam' system is unique among
widely used programming language packaging systems in offering the
following:
• It supports [system dependencies] to abstract over the packaging
complexities of most commonly used platforms.
• It is tested by an [extensive CI matrix] to ensure packages are
working, installable, and interoperable.
• It is [curated] to cultivate an ecosystem of high quality, useful
packages.
This all takes a lot of work and it presents a wide field of
interesting socio-technical problems and exciting opportunities.
Here are two of the projects we've tackled recently:
• Organizing and executing the archiving initiative, led by @hannes,
and presented in ["Pushing the opam-repository into a sustainable
repository"]
• Work to [Improve the CI systems and maintain the infrastructure]
*The [opam-repository maintainers] needs the help of curious and
motivated volunteers, like you!*
[Volunteer to Maintain the opam Repository
:raised_hand_with_fingers_splayed:]
<https://github.com/ocaml/opam-repository/issues/27740>
[opam-repository] <https://github.com/ocaml/opam-repository>
[system dependencies]
<https://opam.ocaml.org/doc/Manual.html#opamfield-depexts>
[extensive CI matrix]
<https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md>
[curated]
<https://github.com/ocaml/opam-repository/tree/master/governance/policies>
["Pushing the opam-repository into a sustainable repository"]
<https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html>
[Improve the CI systems and maintain the infrastructure]
<https://ocaml.org/changelog/2024-10-02-updates>
[opam-repository maintainers]
<https://github.com/ocaml/opam-repository/tree/master/governance>
Opportunities
╌╌╌╌╌╌╌╌╌╌╌╌╌
This is a great opportunity for newer and seasoned members of the
OCaml community to serve a critical function and make a big impact on
the sustainability and health of our growing ecosystem:
• Connect with and support contributors from across the ecosystem.
• Contribute to a large, long-running open source project.
• Learn from an experienced group of caring and committed maintainers.
• Learn advanced techniques in packaging management, in a variety of
build systems, and in every niche of the extended OCaml ecosystem.
• Help to evolve the tooling, infrastructure, and processes that
enable our distributed community to share programs!
Next steps
╌╌╌╌╌╌╌╌╌╌
• Ask any questions in this thread, or by contacting one of the
[active maintainers] directly.
• Volunteer by commenting on the issue [Volunteer to Maintain the opam
Repository :raised_hand_with_fingers_splayed:].
• We will arrange for an orientation session for all interested
maintainer!
We look forward to working with you!
– The Opam Repository Maintainers
[Volunteer to Maintain the opam Repository
:raised_hand_with_fingers_splayed:]
<https://github.com/ocaml/opam-repository/issues/27740>
Dune package management update
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dune-package-management-update/16477/1>
Marek Kubica announced
──────────────────────
Hi fellow camel-wranglers,
It has been a bit quiet with updates lately with regards to the Dune
package management feature, but it doesn't mean that the work has
stalled. We're still continuing and got to a point where the code is
mature enough to test it on all packages in OPAM-repository.
Some of you might be aware of [OPAM-health-check]: a tool/service that
monitors how much of the OPAM ecosystem can be built successfully. We
extended it to build packages with Dune.
It's a bit of a longer read, with all the explanations and thoughts
that went into this, but I am sure it'll be interesting for you what
challenges we had, what progress happened in the last few months and
most importantly, where we currently are:
<https://tarides.com/blog/2025-04-11-expanding-dune-package-management-to-the-rest-of-the-ecosystem/>
We're of course not done yet. So expect more update posts as we try to
get as many projects working as possible in the future. If you have
questions, ideas, suggestions, feel free to drop in in this thread :-)
Thanks go out to my coworkers involved in this effort (@gridbugs
@maiste @art-w @ElectreAAS @shym @mtelvers).
[OPAM-health-check] <https://github.com/ocurrent/opam-health-check/>
Ocsigen public meeting
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocsigen-public-meeting/16408/3>
Continuing this thread, Vincent Balat announced
───────────────────────────────────────────────
Thank you for the attendance! This was a very dense meeting :) The
minutes of the meeting are available [here]
[here]
<https://docs.google.com/document/d/11oLeQs3whCj1BLztVmlr4tVA3G1xKl50ZewdN0CrHMI/edit?tab=t.0>
Looking for Maintainers / Moderators for the OCaml Cookbook
═══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/looking-for-maintainers-moderators-for-the-ocaml-cookbook/16497/1>
Sabine Schmaltz announced
─────────────────────────
Hi everyone,
after we added the [OCaml Cookbook on OCaml.org], we got into a
position where we
1. had contributions sitting around for a while because we did not
have the capacity to review and moderate these additions, and
2. felt we do not have a good enough understanding of the ecosystem in
general to assess whether the chosen libraries are reasonable, or
whether there's other options that need to be mentioned.
To make the cookbook really useful, we need to build a better process
around maintaining it and adding to it.
I propose:
1. We appoint a handful of moderators / maintainers for the OCaml
Cookbook, drawing from volunteers.
2. I create a Telegram group to stay in contact with you all to ask
for help on cookbook PRs. (This could a group focused precisely on
the OCaml Cookbook.)
So, if you're up for helping with the cookbook, have any questions, or
other remarks, please reach out to sabine@tarides.com, or reply here!
:orange_heart:
[OCaml Cookbook on OCaml.org] <https://ocaml.org/cookbook>
SCGI library for OCaml and eio
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/scgi-library-for-ocaml-and-eio/16498/1>
Marc Coquand announced
──────────────────────
Hey everyone!
To learn a bit of networking and eio, I wrote an [scgi library with
eio support]. It aims to just implement the scgi protocol and a few
helpers for writing HTTP responses. It's still very new, and I am
looking for feedback on the interface and implementation before I
publish it to opam.
Here's a simple ping/pong example to get started:
┌────
│ open Scgi_eio
│
│ let handler (request : Request.t) =
│ match Request.path request with
│ | ["ping"] ->
│ Http_response.body_string `Ok "pong"
│ | _ ->
│ Http_response.body_status `Not_found
│
│ let () : unit =
│ let port = 3000 in
│ Eio_main.run
│ @@ fun env ->
│ let addr = `Tcp (Eio.Net.Ipaddr.V4.loopback, port) in
│ let net = Eio.Stdenv.net env in
│ Eio.Switch.run
│ @@ fun sw ->
│ let conn = Eio.Net.listen net ~sw ~reuse_addr:true ~backlog:5 addr in
│ Eio.traceln "Listening to connections on port %s" (string_of_int port) ;
│ Eio.Net.run_server conn
│ (Scgi_eio.http_server ~settings:Scgi_eio.default_settings handler)
│ ~on_error:(Eio.traceln "Error handling connection: %a" Fmt.exn)
└────
[scgi library with eio support] <https://git.sr.ht/~marcc/scgi-eio>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Expanding Dune Package Management to the Rest of the Ecosystem]
• [DNSvizor - run your own DHCP and DNS MirageOS unikernel - gets some
testing]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Expanding Dune Package Management to the Rest of the Ecosystem]
<https://tarides.com/blog/2025-04-11-expanding-dune-package-management-to-the-rest-of-the-ecosystem>
[DNSvizor - run your own DHCP and DNS MirageOS unikernel - gets some
testing] <https://blog.robur.coop/articles/dnsvizor02.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30370 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-04-08 13:14 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-04-08 13:14 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 27918 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 01 to 08,
2025.
Please note that some entries were posted on April 1st.
Table of Contents
─────────────────
Ocsigen public meeting
Roguetype
Ppx_untype: An end to type errors in OCaml
Second of Two Lessons on Polymorphic Variants: Practical Usecases
Caqti 2.2.4 Release and Plans
update for the magick-core-7
gegl-0.4 _
Dune 3.18
QCheck 0.24
checked_oint v0.5.0: Safe integer arithmetic for OCaml
Outreachy December 2024 Round
OUPS meetup april 2025
Other OCaml News
Old CWN
Ocsigen public meeting
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocsigen-public-meeting/16408/1>
William Caldwell announced
──────────────────────────
Hi all!
The Ocsigen team is organising a public meeting in which we'll be
discussing the migration from Lwt to effect-based concurrency, updates
about work in progress (wasm_of_ocaml, Ocsigen-i18n, …).
We welcome user suggestions & questions, please join us Monday the
14th of April at 1pm (France/GMT+2) at the following link:
<https://meet.google.com/zdm-krfj-rcw>
Roguetype
═════════
Archive: <https://discuss.ocaml.org/t/ann-roguetype/16409/1>
octachron announced
───────────────────
Have you ever felt pained by the lack of GADTs and high-arity functors
when playing games? Have you ever wondered if you could play games
without being weighted by a runtime evaluation?
Then fear no longer, because in this day it is my pleasure to announce
the first release of [Roguetype], the first ever roguelike written in
the OCaml type system:
• Test your mettle against the OCaml typechecker and the 8 levels of
`roguetype'.
• Explore functors, mountains, and forests to discover hidden paths.
• Vanquish goblins and dragon(s), upgrade your equipment, while being
sure that your travel is well-typed by construction.
• And maybe, at the end of your adventure, you shall prove that the
victory type is inhabited
[Roguetype] <https://github.com/Octachron/roguetype.git>
Ppx_untype: An end to type errors in OCaml
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-untype-an-end-to-type-errors-in-ocaml/16410/1>
Paul-Elliot announced
─────────────────────
Hello dear people reading this!
Today, I am overly excited to announce one of the greatest and
simplest tool, that will fix the biggest of all OCaml flaws.
Consider Javascript:
┌────
│ $ node
│ Welcome to Node.js v22.14.0.
│ Type ".help" for more information.
│ > 1 + 3.5
│ 4.5
└────
Simple and elegant, don't we all agree?
Now, the same with OCaml:
┌────
│ $ ocaml
│ OCaml version 5.3.0
│ Enter #help;; for help.
│ # 1 + 3.5 ;;
│ Error: The constant 3.5 has type float but an expression was expected of type
│ int
└────
What does this even mean?
The PPX that I lovingly share with you all is `ppx_untype'. It finally
fully removes the OCaml type system that has plagued it since its
inception.
The PPX can be used very simply. Add it to your opam switch:
┌────
│ $ opam pin add ppx_untype https://github.com/panglesd/ppx_untype.git\#main
└────
and then add it to your `dune' (or other build system) file:
┌────
│ (...
│ (preprocess (pps ppx_untype))
│ ...)
└────
And you can now enjoy OCaml!
┌────
│ $ cat bin.main.ml
│ let () = print_float (1 + 3.5)
│ $ dune exec bin/main.exe
│ 3.47922429887e-310
└────
Pros:
╌╌╌╌╌
• All programs that was working before, still works.
• Blazingly fast!
• Finally integers and floats can be added.
• All warnings are also removed.
Cons:
╌╌╌╌╌
• None (apart from some unexpected behaviour at runtime)
Second of Two Lessons on Polymorphic Variants: Practical Usecases
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/second-of-two-lessons-on-polymorphic-variants-practical-usecases/16416/1>
Jakub Svec announced
────────────────────
This is the second of two lessons on polymorphic variants I've been
drafting for potential inclusion in the Lessons section of OCaml.org.
You can find the draft second lesson [here]. I appreciate any feedback
you may have.
The OCaml.org discussion of the first lesson can be found [here].
The goal of the first lesson was to introduce the foundational
knowledge for how polymorphic variants work (row polymorphism,
structural typing, upper bounds, lower bounds, …), their benefits and
drawbacks, how they relate to "ordinary" variants, their notation
(`\~', `>', `<', `#', …), and their behavior during type refinement.
I am grateful to everyone that provided feedback on the first
lesson. I incorporated most of the feedback into the lesson already,
but it is not yet complete. I've held off finalizing the first lesson
until this second lesson receives feedback, since there may be
significant structural changes to the first lesson depending on the
feedback received on this second part.
The objective of this second lesson is to demonstrate practical
usecases for polymorphic variants. Presently, it demonstrates seven
practical usecases of polymorphic variants, along with "ordinary"
variant equivalents for comparison.
The seven usecases were sourced from:
• Jacques Garrigue's [1998 paper]
• [This discussion] board on OCaml.org
Please consider this a rough draft. It does not include an
indroduction and conclusion, and every example has minimal narrative
supporting it.
The goal is to solicit feedback on the *selected examples*, the
*structure of the examples*, and to solicit *additional examples* if
these are insufficient.
If you have experience with specific usecases for polymorphic variants
that you feel would do a better job demonstrating specific usecases or
that demonstrate features not presented here, please let me know. If
you can supply a concise example with a quick overview I would be
grateful. If that does not work with your schedule, I can formulate an
example from a description and perhaps a github link if available.
For example, none of the usecases demonstrate explicit coercions. That
may be a useful example to include, however this was not mentioned in
the source material and am unsure how commonly it is employed by OCaml
developers.
Once this document's examples are locked down, I will consider the
following:
• Which lesson should be introduced first (demonstrations or
foundations)?
• Should the examples in this lesson be extracted into .ml files for
readers to clone like in some other lessons on the site?
• Should the two lessons be merged?
• Is the length excessive?
• Can any content be removed or extracted into a standalone lesson?
Once that is resolved, I will do a final pass on the lesson(s) and
make another request for feedback.
Once again, I want to express my gratitude to everyone willing to work
through these draft lessons, as well to those willing to provide
feedback.
Example Usecases:
• Monomorphic Usecases
• Overloaded Tags
• Compose with Result
• Transitioning from Ordinary to Polymorphic Variants in an API
• Polymorphic Variants with Phantom Types
• Functional Reactive Programming with Polymorphic Variants
• Encoding HTML in Hierarchical Structures
[here] <https://hackmd.io/@wqo57Le0RIyZVlb8qdJ8PA/ryPD_7961x>
[here]
<https://discuss.ocaml.org/t/new-lesson-on-polymorphic-variants/16390/11>
[1998 paper]
<https://caml.inria.fr/pub/papers/garrigue-polymorphic_variants-ml98.pdf>
[This discussion]
<https://discuss.ocaml.org/t/is-there-any-kind-of-guidline-about-when-to-use-polymorphic-variants/11006/14>
Caqti 2.2.4 Release and Plans
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-caqti-2-2-4-release-and-plans/16419/1>
"Petter A. Urkedal announced
────────────────────────────
The Release
╌╌╌╌╌╌╌╌╌╌╌
I am pleased to announce the release of [Caqti] 2.2.4, after stumbling
through a few minor releases starting at 2.2.0. These are the
combined release notes since the previous OPAM release, omitting
intermediate regressions:
[Caqti] <https://github.com/paurkedal/ocaml-caqti>
◊ Improvements
• The sqlite3 driver now supports the refined error causes
(`Caqti_error.cause') for integrity constraint violations.
• There is now experimental support for Miou ([#117] by Calascibetta
Romain).
• Make the pool implementation shared-memory safe.
• The new library `caqti.template' provides a preview of a interface
for creating and working with request templates, with a few new
features and, I think, a tidier design. This is not yet suitable
for production code, since it will change before the final version.
Feedback is welcome.
[#117] <https://github.com/paurkedal/ocaml-caqti/pull/117>
◊ Fixes
• Fixed a memory leak in the fall-back implementation of the
`populate' connection method which affects all except the postgresql
drivers.
◊ Deprecations
• `Caqti_request.query_id' is deprecated and will be removed.
• Constructors of `Caqti_type.t' are now fully private and will be
moved away and likely defined differently in the next major release.
◊ Dependency Updates
• Prepare for upcoming mirage ([#124] by Hannes Mehnert).
[#124] <https://github.com/paurkedal/ocaml-caqti/pull/124>
Upcoming Work on `caqti.template'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
As mentioned, this library is experimental for now, yet it contains
the real implementation of request templates, while the stable API is
a backwards compatible wrapper. I already have plans for revising the
new API both due to hard requirements and feedback about usability and
preferences, esp. for the most commonly used part of the API.
◊ Dynamic Prepare Policy and Parametric Types
One thing I am excited about with the `caqti.template' library is the
support for prepared queries for dynamically generated request
templates.
To motivate this, note that each prepared query retains resources on
both the server side and locally, both associated with an open
database connection, which can be long-lived. So, if the application
generates queries based on e.g. search expressions like `(author:Plato
or author:Socrates) and topic:epistemology', which cannot be prepared
statically due to the boolean algebra over search terms, then users of
the current API must use one-shot (non-prepared) queries to avoid
unbounded retention of resources over time. The new API provides a
so-called dynamic prepare policy, which uses an LRU cache of prepared
queries internally to limit the resource usage while providing a
heuristic for re-using common prepared queries.
There is, however, a missing piece in order for this to be practically
efficient. Type descriptors like `Caqti_type.t2', `Caqti_type.t3',
etc. which represent parametrically polymorphic types, are currently
generative with respect to the equality used by the LRU cache, meaning
that the type expression would need to be lifted out of the function
which generates the request template in order to avoid consistent
cache-misses.
My plan is first to make a major release which moves the concrete type
representation away from the public modules, and then revise it to
properly encode parametric types. Apart from changing the
constructors, this involves adding an extra phantom type parameter,
but the parameter will be universally qualified in the type exposed to
the public API, so I expect to retain backwards compatibility for
typical usage.
◊ The Main Request Template API and Bring-Your-Own-Paint
For most use cases, it is sufficient to be able to construct request
templates, which consists of type descriptors and a possibly
dialect-dependent query template. Everything needed for this is
bundled into the module `Caqti_template.Create'. I may have developed
a bit colourblindness after walking around this bikeshed, so let me
show you how the current stable API looks like, how the current
iteration of the new API looks like.
Here is a request template using the stable API:
┌────
│ let select_owner =
│ let open Caqti_request.Infix in
│ let open Caqti_type.Std in
│ (string ->? string)
│ "SELECT owner FROM bikereg WHERE frameno = ?"
└────
In the current iteration of the new API, this looks like:
┌────
│ let select_owner =
│ let open Caqti_template.Create in
│ static T.(string -->? string)
│ "SELECT owner FROM bikereg WHERE frameno = ?"
└────
What changed?
• There is now only a single `open'. That can only be good.
• The type descriptors have been moved under a `T' sub-module. This
isn't strictly necessary, but I though it was tidier, esp. since
there are clashing names (like `int') under a parallel `Q'
sub-module which is used for dynamically generated query templates.
• The arrow was previously the main function, while in the new API it
only constructs the type and multiplicity representation
(`Caqti_template.Request_type.t').
• Instead, the main function now indicates the policy for whether to
use a prepared query and, if so, the life-time of the request
template. The options are `direct', `static', and `dynamic' (as
explained above).
The latter adds verbosity, but I think it is good to be explicit about
static life-time, since using it for generated request templates would
typically lead to a resource leakage.
It's getting late, so I will not write about dynamic and
dialect-dependent request templates, but in the current revision, they
are constructed with a "general" version of the above functions,
`direct_gen', `static_gen', and `dynamic_gen' which takes a function
receiving a dialect descriptor and returns a `Caqti_template.Query.t'
instead of a string. The stable API used combinator operators for
this.
update for the magick-core-7
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-update-for-the-magick-core-7/16422/1>
Florent Monnier announced
─────────────────────────
An update to use the magick-core-7 is available there:
[https://github.com/fccm2/mgk-gen2]
If you still want to use the magick-core-6, the previous head is kept
here: [https://github.com/fccm2/mgk-gen]
The updated version was tested with the magick-core version
`7.1.1-44', if you want to compile it, you need about `256M' space
left on device.
[https://github.com/fccm2/mgk-gen2] <https://github.com/fccm2/mgk-gen2>
[https://github.com/fccm2/mgk-gen] <https://github.com/fccm2/mgk-gen>
gegl-0.4 _
══════════
Archive: <https://discuss.ocaml.org/t/ann-gegl-0-4/16424/1>
Florent Monnier announced
─────────────────────────
You can now access `gegl-0.4', from your favorite scripting language,
and play with its nodes, with: [https://github.com/fccm2/gegl-ocaml] /
([api-doc])
[https://github.com/fccm2/gegl-ocaml]
<https://github.com/fccm2/gegl-ocaml>
[api-doc] <http://decapode314.free.fr/ocaml/gegl/docs/0.01/Gegl.html>
Dune 3.18
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-18/16428/1>
Etienne Marais announced
────────────────────────
On the behalf of the dune team, I'm glad to announce the release of
dune `3.18.0' :partying_face:
This release contains changes to support the new
`x-maintenance-intent' field by default. It also contains some changes
regarding the cache, about how it handles file permissions. It
introduces a new `(format-dune-file ...)' stanza with the intention to
formalize the `dune format-dune-file' command as an inside
rule. Finally, it includes various bug fixes for Dune.
If you encounter a problem with this release, you can report it on the
[ocaml/dune] repository.
[ocaml/dune] <https://github.com/ocaml/dune/issues>
Changelog
╌╌╌╌╌╌╌╌╌
◊ Fixed
• Support HaikuOS: don't call `execve' since it's not allowed if other
pthreads have been created. The fact that Haiku can't call `execve'
from other threads than the principal thread of a process (a team in
haiku jargon), is a discrepancy to POSIX and hence there is a [bug
about it]. (@Sylvain78, #10953)
• Fix flag ordering in generated Merlin configurations (#11503,
@voodoos, fixes ocaml/merlin#1900, reported by @vouillon)
[bug about it] <https://dev.haiku-os.org/ticket/18665>
◊ Added
• Add `(format-dune-file <src> <dst>)' action. It provides an
alternative to the `dune format-dune-file' command. (#11166, @nojb)
• Allow the `--prefix' flag when configuring dune with `ocaml
configure.ml'. This allows to set the prefix just like `$ dune
install --prefix'. (#11172, @rgrinberg)
• Allow arguments starting with `+' in preprocessing definitions
(starting with `(lang dune 3.18)'). (@amonteiro, #11234)
• Support for opam `(maintenance_intent ...)' in dune-project
(#11274, @art-w)
• Validate opam `maintenance_intent' (#11308, @art-w)
• Support `not' in package dependencies constraints (#11404, @art-w,
reported by @hannesm)
◊ Changed
• Warn when failing to discover root due to reads failing. The
previous behavior was to abort. (@KoviRobi, #11173)
• Use shorter path for inline-tests artifacts. (@hhugo, #11307)
• Allow dash in `dune init' project name (#11402, @art-w, reported by
@saroupille)
• On Windows, under heavy load, file delete operations can sometimes
fail due to AV programs, etc. Guard against it by retrying the
operation up to 30x with a 1s waiting gap (#11437, fixes #11425,
@MSoegtropIMC)
• Cache: we now only store the executable permission bit for files
(#11541, fixes #11533, @ElectreAAS)
• Display negative error codes on Windows in hex which is the more
customary way to display `NTSTATUS' codes (#11504, @MisterDA)
QCheck 0.24
═══════════
Archive: <https://discuss.ocaml.org/t/ann-qcheck-0-24/16198/2>
Jan Midtgaard announced
───────────────────────
FYI, QCheck 0.25 is now available from the opam repository :smiley:
<https://github.com/c-cube/qcheck/releases/>
The 0.25 release contains a combination of all-round fixes,
documentation, and polishing:
• Restore `Test.make''s `max_fail' parameter which was accidentally
broken in 0.18
• Adjust `stats' computation of average and standard deviation to
limit precision loss, print both using scientific notation, and
workaround MinGW float printing to also pass expect tests
• Fix dune snippets missing a language specifier in README.adoc
causing `asciidoc' to error
• Add a note to `QCheck{,2.Gen}.small_int_corners' and
`QCheck{,2}.Gen.graft_corners' about internal state, and fix a range
of documentation reference warnings
• Reorganize and polish the `README', rewrite it to use `qcheck-core',
and add a `QCheck2' integrated shrinking example
• Document `QCHECK_MSG_INTERVAL' introduced in 0.20
• Add `QCheck{,2}.Gen.map{4,5}' combinators
The accompanying `ppx_deriving_qcheck.0.7' release offers:
• Support `ppxlib.0.36.0' based on the OCaml 5.2 AST
Thanks to @Pat-Lafon and @patricoferris for contributing PRs! 🎉
Happy testing! :smiley: :keyboard:
checked_oint v0.5.0: Safe integer arithmetic for OCaml
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-checked-oint-v0-5-0-safe-integer-arithmetic-for-ocaml/16450/1>
hirrolot announced
──────────────────
I would like to announce [`checked_oint'] v0.5.0, which provides
checked integer arithmetic for OCaml. We support both signed and
unsigned integers of 8, 16, 32, 64, and 128 bits. Unlike other
libraries, `checked_oint' either returns an option or raises an
exception when the result of an arithmetic operation cannot be
represented in a desired integer type.
In addition, it contains abstractions for manipulating arbitrary
integers and integer types in a generic and type-safe manner, which I
find tremendously useful for compiler/interpreter implementations.
Usage example:
┌────
│ open Checked_oint
│
│ let () =
│ let x = U8.of_int_exn 50 in
│ let y = U8.of_int_exn 70 in
│ assert (U8.equal (U8.add_exn x y) (U8.of_int_exn 120));
│ assert (Option.is_none (U8.mul x y))
└────
The release v0.5.0 introduced crucial functionality for converting
between any two integer types in a safe manner – see [`S.of_generic']
and [`S.of_generic_exn'].
[`checked_oint'] <https://github.com/hirrolot/checked_oint>
[`S.of_generic']
<https://hirrolot.github.io/checked_oint/checked_oint/Checked_oint/module-type-S/index.html#val-of_generic>
[`S.of_generic_exn']
<https://hirrolot.github.io/checked_oint/checked_oint/Checked_oint/module-type-S/index.html#val-of_generic_exn>
Outreachy December 2024 Round
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-december-2024-round/15223/3>
Patrick Ferris announced
────────────────────────
With the [June 2025 round] about to begin, it is time to celebrate the
awesome work @abdulaziz.alkurd has been doing on [ocaml-api-watch]
mentored by @NathanReb and @panglesd!
Please join us on [date=2025-04-15 time=10:00:00 timezone="UTC"] for
the community zoom call where we will get to hear about all of the
progress that has been made.
Hope to see you there. I'll post a link to the video call closer to
the time. For those that can't make it, the meeting will be recorded
and uploaded to watch.ocaml.org :two_hump_camel:
[June 2025 round]
<https://discuss.ocaml.org/t/outreachy-june-2025/16154>
[ocaml-api-watch] <https://github.com/ocaml-semver/ocaml-api-watch>
OUPS meetup april 2025
══════════════════════
Archive: <https://discuss.ocaml.org/t/oups-meetup-april-2025/16453/1>
zapashcanon announced
─────────────────────
CAUTION: the time has been changed from 7pm to 6:30pm and it will be
at ENS Ulm instead of Jussieu
The next OUPS meetup will take place on *Thursday, 24th of April*
2025. It will start at *6:30pm* at the *45 rue d'Ulm* in Paris. It
will be in the in the *Salle des résistants* (first floor in the
"couloir du carré").
Please, *[register on meetup ]* as soon as possible to let us know how
many pizza we should order.
For more details, you may check the [OUPS’ website ].
This time we’ll have the following talks:
*A translation of OCaml programs from Gospel to Viper – Charlène Gros*
Presentation of a translation of OCaml programs specified
in Gospel into Viper, an intermediate verification
language supporting separation logic.
The practical goal is to add a new backend to Cameleer to
verify OCaml programs that manipulate the heap. The
logical specification of such OCaml programs is described
in the Gospel language, and we detail the extensions made
to support separation logic in Viper.
*Posca: an experimental social network based on Matrix, written in
OCaml with melange – Pierre de Lacroix*
TBA
After the talks there will be some pizzas offered by the [OCaml
Software Foundation] and later on we’ll move to a pub nearby as usual.
[register on meetup ]
<https://www.meetup.com/fr-FR/ocaml-paris/events/307176170>
[OUPS’ website ] <https://oups.frama.io>
[OCaml Software Foundation] <https://ocaml-sf.org>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [What's new with Mollymawk?]
• [Learning OCaml: Module Aliases]
• [Learning OCaml: Parsing Data with Scanf]
• [Learning OCaml: Regular Expressions]
• [Making OCaml Safe for Performance Engineering]
• [OCaml in Space: SpaceOS is on a Satellite!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[What's new with Mollymawk?]
<https://blog.robur.coop/articles/mollymawk-first-milestone.html>
[Learning OCaml: Module Aliases]
<https://batsov.com/articles/2025/04/06/learning-ocaml-module-aliases/>
[Learning OCaml: Parsing Data with Scanf]
<https://batsov.com/articles/2025/04/06/learning-ocaml-parsing-data-with-scanf/>
[Learning OCaml: Regular Expressions]
<https://batsov.com/articles/2025/04/04/learning-ocaml-regular-expressions/>
[Making OCaml Safe for Performance Engineering]
<https://www.youtube.com/watch/g3qd4zpm1LA?version=3>
[OCaml in Space: SpaceOS is on a Satellite!]
<https://tarides.com/blog/2025-04-03-ocaml-in-space-spaceos-is-on-a-satellite>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 43823 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-04-01 9:12 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-04-01 9:12 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 13447 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 25 to April
01, 2025.
Table of Contents
─────────────────
MlFront_ZipFile - High-level API for zip files
MlFront_Cache - Transient caches + slowly varying data
New lesson on polymorphic variants
The OBazl Toolsuite 3.0.0.beta.1
Dune dev meeting
Other OCaml News
Old CWN
MlFront_ZipFile - High-level API for zip files
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mlfront-zipfile-high-level-api-for-zip-files/16380/1>
jbeckford announced
───────────────────
I am happy to announce that `MlFront_ZipFile.2.3.0', a package that
can do basic zip/unzip operations on a zip file, was released
today. It is available on opam with `opam update' and `opam install
MlFront_ZipFile'.
There are other opam packages for zip files, and often those are more
appropriate. `MlFront_ZipFile' is different because:
• It is very high-level. I wanted an API to unzip and zip, with a
simple observer API for unzipping so I could attach @CraigFe's
excellent [`progress'] bar library.
• It can unzip 4GB files in a 32-bit OCaml runtime.
• It has a permissive license.
• It is not thread-safe (except unzipping).
• It fully embeds the C code. That means it works on Windows and
should work under cross-compilation without needing a
non-portable/non-reproducible `pkg-config' installation.
• It has a binary `mlfront-zip' which can do glob-based exclusions (a
feature not present in the typical InfoZip `/usr/bin/zip' that comes
with Unix or PowerShell `Compress-Archive' on Windows). macOS,
Windows and Linux have prebuilt binaries.
Here are the relevant links:
• Docs:
[https://dkml.gitlab.io/build-tools/MlFront/MlFront_ZipFile/MlFront_ZipFile/index.html]
• `mlfront-zip' binaries:
[https://gitlab.com/dkml/build-tools/MlFront/-/releases/2.3.0-8]
• homepage: <https://gitlab.com/dkml/build-tools/MlFront>
Sidenote: The docs won't be available on ocaml.org. Use the doc links
above until I figure out a technical solution (very low-priority).
[`progress']
<https://github.com/craigfe/progress?tab=readme-ov-file#progress>
[https://dkml.gitlab.io/build-tools/MlFront/MlFront_ZipFile/MlFront_ZipFile/index.html]
<https://dkml.gitlab.io/build-tools/MlFront/MlFront_ZipFile/MlFront_ZipFile/index.html>
[https://gitlab.com/dkml/build-tools/MlFront/-/releases/2.3.0-8]
<https://gitlab.com/dkml/build-tools/MlFront/-/releases/2.3.0-8>
MlFront_Cache - Transient caches + slowly varying data
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mlfront-cache-transient-caches-slowly-varying-data/16381/1>
jbeckford announced
───────────────────
I am happy to announce that `MlFront_Cache.2.3.0', a framework for
transient caches and slowly varying data, was released today. It is
available on opam with `opam update' and `opam install MlFront_Cache'.
MlFront_Cache lets you cache files and directories, all backed in a
local sqlite3 database. It is a bit esoteric. I use it for:
1. Transient caches when downloading zip files.
2. Immutable installs for DkCoder. A related use case is covered in
detail in the docs as "Downloading datasets".
Treat this as an alpha release with a somewhat unstable API. In
particular, I haven't implemented cache eviction yet.
Here are the relevant links:
• Docs:
[https://dkml.gitlab.io/build-tools/MlFront/MlFront_Cache/MlFront_Cache/index.html]
• homepage: <https://gitlab.com/dkml/build-tools/MlFront>
Sidenote: The docs won't be available on ocaml.org. Use the doc links
above until I figure out a technical solution (very low-priority).
[https://dkml.gitlab.io/build-tools/MlFront/MlFront_Cache/MlFront_Cache/index.html]
<https://dkml.gitlab.io/build-tools/MlFront/MlFront_Cache/MlFront_Cache/index.html>
New lesson on polymorphic variants
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/new-lesson-on-polymorphic-variants/16390/1>
Jakub Svec announced
────────────────────
Hello,
I wrote a new lesson on polymorphic variants.
You can find it [here].
I appreciate any feedback you may have. I expect that if there is
interest in including a lesson on polymorphic variants that there will
likely be several rounds of refinement.
Sources:
• <https://blog.shaynefletcher.org/2017/03/polymorphic-variants-subtyping-and.html>
• <https://discuss.ocaml.org/t/new-draft-tutorial-on-polymorphic-variants/13485>
• <https://discuss.ocaml.org/t/is-there-any-kind-of-guidline-about-when-to-use-polymorphic-variants/11006>
• <https://blog.klipse.tech/ocaml/2018/03/16/ocaml-polymorphic-types.html>
This lesson is about 800 lines long (about 1100 with line length
limited to 85 columns). This makes this lesson on the longer side when
compared to other lessons on OCaml.org. Therefore, this is the first
of 2 lessons on polymorphic variants.
This lesson (lesson 1) introduces the concepts behind polymorphic
variants (such as row polymorphism and structural typing), then
discusses common syntactic structures of polymorphic variants. It
teaches these concepts in a bottom-up direction. It is my subjective
belief (held lightly) that introducing polymorphic variants in a
top-down direction leads to more complexity and confusion.
Lesson 2, which is forthcoming, introduces common usecases for
polymorphic variants through real-world examples.
Any feedback a reviewer is willing to provide is greatly
appreciated. The author is particularly interested in ensuring
accuracy and validity of examples and consistency in the language with
OCaml.org's other materials, but all feedback is welcome.
[here] <https://hackmd.io/@wqo57Le0RIyZVlb8qdJ8PA/HJchCEX6ye/edit>
The OBazl Toolsuite 3.0.0.beta.1
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-the-obazl-toolsuite-3-0-0-beta-1/16407/1>
Gregg Reynolds announced
────────────────────────
The OBazl Toolsuite 3.0.0.beta.1 is now available.
The OBazl Toolsuite is a collection of rules & tools that support
OCaml development using [Bazel]. To get started:
┌────
│ $ git clone https://github.com/obazl/demo_hello.git
│ $ cd demo_hello
│ $ bazel run bin:greetings
└────
See [The OBazl Book] for more guidance.
Tested on MacOS and Linux (Ubuntu).
This version contains many improvements:
• Improved toolchain support. Select a compiler by passing
e.g. `--tc=ocamlc'.
• Seamless opam dependencies. The previous version required a
preprocessing step (running `bazel run @coswitch'); this is no
longer necessary.
• Fine-grained dependencies. Depend directly on any module, whether it
is in a library or not, and whether it is namespaced (~~wrapped'')
or not.
• Context-sensitive archiving. Archives are for distribution; internal
dependencies do not need them. The `ocaml_library' rule will only
construct an archive on demand. By default, an internal dependency
on an `ocaml_library' target will not request archiving. This can be
overridden.
• Several examples of OBazl extensions: rules_ppx, rules_cppo,
rules_ctypes, rules_menhir. These demonstrate the relative ease
with which tools can be integrated into the Bazel environment.
• A new tool, `bazel run @obazl//new' that generates a project from a
template.
• Direct support for the tools in the standard SDK (ocamldebug,
ocamlobjinfo, etc.) and for a subset of the OCaml Platform
tools. For example:
‣ `$ bazel run @opam -- list'
‣ `$ bazel run @ocaml'
‣ `$ bazel run @utop'
‣ `$ bazel run @dbg --@dbg//pgm=src:greetings'
OBazl ensures that these commands will be invoked under the correct
switch, with correct paths (CAML_LD_LIBRARY_PATH etc.), insulated
from environment variables.
Other tools are invoked by passing an option to an ordinary build
command. For example:
• `$ bazel build lib/hello:Hello --modinfo' # runs ocamlobjinfo on the
.cmo/.cmx output
• `$ bazel build lib/hello:Hello --siginfo' # runs ocamlobjinfo on the
.cmi output
• `$ bazel build lib/hello:libFoo --archinfo' # runs ocamlobjinfo on
the .cma/.cmxa output
• `$ bazel build lib/hello:Hello --gensig' # runs `ocamlopt -i' on the
.ml file to generate inteface code.
The documentation at [The OBazl Book] has been updated. It remains
far from complete but it should be useful. In particular the [OBazl
Guide] and the [`rules_ocaml' Reference Manual].
What's missing?
• Support for opam publishing. I have successfully published an OBazl
(Bazel) project to an opam switch, and used it in a dune-only
project, but the code is still under development so I don't have a
demo.
• Support for `odoc', `ocamlformat', and linting. Currently under
development.
• Windows support. The code is designed for portability but it will
probably be a while before I can get to Windows.
• Automatic generation of BUILD.bazel files. I have a tool for this
but it is outdated. Bringing it up-to-date is a high priority.
Support:
• [discord]
• [@obazl.bsky.social]
Cheers!
Gregg
[Bazel] <https://bazel.build/>
[The OBazl Book] <https://obazl.github.io/docs_obazl/>
[OBazl Guide] <https://obazl.github.io/docs_obazl/obazl>
[`rules_ocaml' Reference Manual]
<https://obazl.github.io/docs_obazl/rules-ocaml/reference/>
[discord] <https://discord.gg/wZCSq2nq6y>
[@obazl.bsky.social] <https://bsky.app/profile/obazl.bsky.social>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/27>
Etienne Marais announced
────────────────────────
Hello :waving_hand: The next Dune Dev Meeting will be on *Wednesday,
April, 2nd at 9:00 CET*. This is going to be a one-hour-long meeting.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers :+1:
The agenda is available on the [meeting dedicated page]. Feel free to
add more items in it.
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [dune wiki on GitHub]
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-04-02>
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/u/0/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319@group.calendar.google.com>
[dune wiki on GitHub] <https://github.com/ocaml/dune/wiki>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Why F#?]
• [ FOSDEM 2025: Report from the Friendly Functional Languages BOF
Room]
• [Pushing the opam-repository into a sustainable repository]
• [μTCP, Miou and unikernels]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Why F#?] <https://batsov.com/articles/2025/03/30/why-fsharp/>
[ FOSDEM 2025: Report from the Friendly Functional Languages BOF Room]
<https://tarides.com/blog/2025-03-28-fosdem-2025-report-from-the-friendly-functional-languages-bof-room>
[Pushing the opam-repository into a sustainable repository]
<https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html>
[μTCP, Miou and unikernels]
<https://blog.robur.coop/articles/utcp_and_effects.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 24218 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-03-25 8:06 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-03-25 8:06 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 27060 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 18 to 25,
2025.
Table of Contents
─────────────────
Ocsigen migrating to effect-based concurrency
Slipshow!
Odoc 3.0 released!
4th editor tooling dev-meeting: 28th of March
The Call for Papers for FUNARCH2025 is open!
Proposal for the replacement of Set and Map in the stdlib
A tool to reverse debug OCaml (and other binaries) runs
Feedback request: New lesson on `Lazy'
OCaml Workshop 2025 at ICFP/SPLASH - announcement and call for proposals
Old CWN
Ocsigen migrating to effect-based concurrency
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocsigen-migrating-to-effect-based-concurrency/16327/1>
Vincent Balat announced
───────────────────────
We're delighted to announce that the [Ocsigen] project has just
launched one of its most ambitious changes: moving from Lwt to
effects-based concurrency.
If this experiment goes well, it will be another step towards
simplifying Web development in OCaml, by eliminating the need for
monads.
Of course we will try to make this transition as smooth as possible,
by providing a compatibility interface for application developers, and
tools to help Web and mobile developers to do the transition
themselves if they want to. These tools will be released in order to
help other projects to do the transition and avoid incompatibilities
between OCaml libraries as much as possible.
This work was made possible thanks to the support of the [NGI Zero
Core fund] through the [Nlnet foundation], and is perfomed by
[Tarides].
Read the [full announcement] by Tarides.
[Ocsigen] <https://ocsigen.org>
[NGI Zero Core fund] <https://nlnet.nl/thema/NGIZeroCore.html>
[Nlnet foundation] <https://nlnet.nl>
[Tarides] <https://tarides.com>
[full announcement]
<https://tarides.com/blog/2025-03-13-we-re-moving-ocsigen-from-lwt-to-eio/>
Slipshow!
═════════
Archive: <https://discuss.ocaml.org/t/ann-slipshow/16337/1>
Paul-Elliot announced
─────────────────────
Dear reader,
I am _absolutely thrilled_ to announce the release of slipshow `0.1.1'
on this forum! As you have all noticed, that is a _huge_ leap from the
previous version, `0.0.34'. (What can have motivated this?)
Recall that [Slipshow] is a tool to prepare presentation support, that
is based on scripted scrolling and zooming (instead of slides).
I'll use this single thread to announce all future versions of
slipshow, to avoid polluting the global namespace, as it makes sense
to keep this forum centered around OCaml, and this tool has nothing to
do with OCaml …
… well, almost nothing to do with OCaml, since in this version the
engine has been fully rewritten in OCaml (hence the bold new version)
and works much better! Making it a full OCaml project. Thanks, OCaml
developers of open source libraries and language!
To upgrade it, you can do:
┌────
│ $ opam update
│ $ opam upgrade slipshow
└────
What? Some people don't have it installed already? For those, it will
be:
┌────
│ $ opam update
│ $ opam install slipshow
└────
Now comes the moment you are all waiting for: the list of new
features!
*TLDR*:
• Engine rewritten in OCaml
• Fewer bugs when navigating back
• Stronger foundation (eg, for subslips)
• Custom scripts requires minor adjustments
• Breaking change in subslip HTML
• Drawing now in SVG
• No more zoom issues
• Erasing works "per-stroke"
• Revamped table of content
• Now based on title structure rather than subslips
• New `--markdown-output' flag for converting to GFM
• Parser bugfixes
• License change: Now GPLv3 (previously MIT)
• npm distribution discontinued.
• Special thanks to NLNet for their [sponsorship]!
Dear readers,
I am thrilled to announce the 0.1 release of Slipshow, the slip-based
presentation tool!
This is a _major_ minor release. While versions `0.0.1' to `0.0.33'
have served well to experiment, this release marks a fresh start,
aimed at being a solid foundation for a project with a clear
direction. A huge thank you to NLNet for [sponsoring] this milestone!
So, what is new? Quite a lot, the main change being that the engine
has been _fully rewritten_.
[Slipshow] <https://github.com/panglesd/slipshow>
[sponsorship] <https://nlnet.nl/project/Slipshow/>
[sponsoring] <https://nlnet.nl/project/Slipshow/>
The engine
╌╌╌╌╌╌╌╌╌╌
Started as a single file javascript project, the old engine evolved
presentation by presentation – leading to numerous bugs, maintenance
challenge or extensibility issue. (In other word, I did all I could
not to touch it despite all the bugs)
This release introduces a complete rewrite of the engine in OCaml,
with new design choices that improve reliability and
expandability. Let's go over the key benefits and breaking changes.
◊ Navigating Forward… and Backward
One of the greatest weakness of the old engine was handling backward
navigation. Since it started as a simple "script scheduler", going
back wasn't straightforward. The workaround involved taking a snapshot
of… everything (the DOM, the state, …), to be able to go back in time.
This had many bugs, in animations (such as the "focus" action), and in
its iteraction with other features (such as drawing).
So, what is new in this engine? The engine now records an undo
function for each step of the presentation. While this may not sound
much, it is a ton better in terms of development. It's a much stronger
foundation to build new features from. It's also much more efficient
for long presentations.
In most cases, your old presentations will work without modification
in the new engine. However, there is one case where it needs
modification: when you include the execution of a custom script in
your presentation. In this case, you need to return the function undo
to undo the executed step: see the [documentation]! (This is not ideal
and better solutions are being experimented)
[documentation]
<https://slipshow.readthedocs.io/en/stable/syntax.html#custom-scripts>
◊ Writing
Previously, live annotations used the excellent [atrament]
library. While great in many cases, its bitmap-based approach caused
blurriness when zooming.
This release introduces a custom SVG-based annotation system, which
eliminates zoom issues. Another change: erasing now works
stroke-by-stroke instead of pixel-by-pixel.
[atrament] <https://github.com/jakubfiala/atrament>
◊ Table of content
The old table of contents was based on the slip structure, which
didn’t work well for presentations that primarily used a single slip
(as is often the case with compiled presentations).
The new sidebar-style table of contents is now generated from headers,
making it more intuitive and aligned with the presentation’s
structure—resulting in a much smoother navigation experience!
◊ Breaking change: Subslips
The HTML structure for subslips has evolved, in particuler to avoid
having to provide the scale of your subslips.
Support for subslip in the new engine is not mature and will be
announced in the next release, but bear in mind that if your
presentation relies on them, you might want to wait a bit before
migrating to the new engine!
Compiler
╌╌╌╌╌╌╌╌
While this release focuses on the engine, the compiler has also seen
improvements, including bug fixes (particularly in the parser) and a
new feature:
◊ `--markdown-output' for markdown exports
If you want to print your presentation or host it as a static webpage,
the default format can be cluttered with annotations. The new
`--markdown-output' flag lets you generate a clean, GitHub Flavored
Markdown (GFM) file without annotations.
Other
╌╌╌╌╌
A small but maybe important note: the license has changed, the project
has transitioned from MIT to GPLv3, aligning better with its values.
Conclusion
╌╌╌╌╌╌╌╌╌╌
Looking forward to your bug reports!
Christian Lindig asked and Paul-Elliot replied
──────────────────────────────────────────────
Could you link to a demo presentation done with this tool?
Sure!
[Here] is a presentation of the tool itself, in French. The source
file for it is [here].
[Here] is a math presentation using more features (made using a
previous version of the engine, which had more features and more
bugs).
[Here] is the historical first presentation made in Slipshow (made
with the worst version of the engine).
(I include presentations made with old versions of the engine to give
an idea of what you can do, as the new engine is very new I don't have
many examples using it, and it has some breaking changes which makes
porting old presentations using too many features hard to port!)
[Here] <https://choum.net/panglesd/slides/campus_du_libre.html>
[here]
<https://github.com/panglesd/slipshow/blob/main/example/campus-du-libre/slipshow.md>
[Here] <https://choum.net/panglesd/slides/WDCM-2021-slips/wdcm-ada.html>
[Here] <http://choum.net/panglesd/slides/slides-js/slides.html>
Daniel Bünzli added
───────────────────
[Here] is a non-dogfooded one.
[Here] <https://def.lakaban.net/research/2024-LRGrep-presentation/>
Odoc 3.0 released!
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-odoc-3-0-released/16339/1>
Jon Ludlam announced
────────────────────
On behalf of the Odoc development team, I’m delighted to announce the
release of Odoc 3! This is a big big release with loads of new
features and bug fixes, and I encourage everyone to install it and
have a play!
For an overview of the new features see our [beta release
announcement]. tl;dr:
┌────
│ $ opam install odoc-driver # will install odoc 3
│ $ odoc_driver odoc odoc-parser odoc-driver odoc-md sherlodoc --remap
└────
and point your browser at `_html/index.html'. This example shows
odoc_driver creating the docs for the 5 packages specified and
remapping links to other packages (see [here] for an explanation)
If you try the above command, you'll note something interesting, and
hopefully this will encourage you to run `odoc_driver' on your own
packages before you release them, as then you'll be able to avoid
slightly embarrassing post-release fixes like [this one] 😬
Here are the changes from the beta release:
[beta release announcement]
<https://discuss.ocaml.org/t/ann-odoc-3-beta-release/16043/10>
[here]
<https://ocaml.github.io/odoc/odoc-driver/index.html#remapping-dependencies>
[this one] <https://github.com/ocaml/odoc/pull/1333>
Added
╌╌╌╌╌
• <https://github.com/ocaml/odoc/pull/1297>
• <https://github.com/ocaml/odoc/pull/1314>
• <https://github.com/ocaml/odoc/pull/1326>
Changed
╌╌╌╌╌╌╌
• <https://github.com/ocaml/odoc/pull/1304>
• <https://github.com/ocaml/odoc/pull/1304>
• <https://github.com/ocaml/odoc/pull/1319>
• <https://github.com/ocaml/odoc/pull/1323>
• <https://github.com/ocaml/odoc/pull/1317>
• <https://github.com/ocaml/odoc/pull/1325>
Fixed
╌╌╌╌╌
• <https://github.com/ocaml/odoc/pull/1304>
• <https://github.com/ocaml/odoc/pull/1313>
• <https://github.com/ocaml/odoc/pull/1312>
• <https://github.com/ocaml/odoc/pull/1311>
• <https://github.com/ocaml/odoc/pull/1304>
• <https://github.com/ocaml/odoc/pull/1309>
• <https://github.com/ocaml/odoc/pull/1306>
• <https://github.com/ocaml/odoc/pull/1310>
4th editor tooling dev-meeting: 28th of March
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-4th-editor-tooling-dev-meeting-28th-of-march/16346/1>
PizieDust announced
───────────────────
Hi everyone, join us for the next *Editor Public Dev-Meeting* on
*March 28th*! This session will feature a talk from *Xavier (@xvw)* on
the latest *Emacs functionalities* integrated with *OCaml LSP server*.
:clipboard: Meeting agenda:
• A tour-de-table to allow the participants that wish to do so to
present themselves and mention issues / prs they are interested in.
• Talk from Xavier and Q&A
• Discuss issues and pull requests that were tagged in advance or
mentioned during the tour-de-table.
• 🔹 *What’s new in Emacs for OCaml development?*
• 🔹 *How the latest LSP improvements enhance the experience?*
• 🔹 *Live demo and discussion on upcoming features*
• 📅 *Date:* March 28th
• 🕐 *Time:* 4PM CET
• 📍 *Location:* [https://meet.google.com/wrv-dovu-ypb]
This is a great opportunity to learn about the latest improvements and
share feedback with the community. Looking forward to seeing you
there! 🚀
Previous meeting notes are available in [Merlin’s repository wiki]
<https://calendar.app.google/zPx5ZQ47C4dwq3437>
[https://meet.google.com/wrv-dovu-ypb]
<https://www.google.com/url?q=https://meet.google.com/wrv-dovu-ypb&sa=D&source=calendar&usd=2&usg=AOvVaw1Q_YkS03VGKSyfyxCBSq7F>
[Merlin’s repository wiki]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
The Call for Papers for FUNARCH2025 is open!
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/the-call-for-papers-for-funarch2025-is-open/16350/1>
Jeffrey Young announced
───────────────────────
Hello everyone,
This year I am chairing the Functional Architecture workshop colocated
with ICFP and SPLASH.
I'm happy to announce that the Call for Papers for FUNARCH2025 is open
- *deadline is June 16th*! Send us research papers, experience
reports, architectural pearls, or submit to the open category! The
[idea] behind the workshop is to cross pollinate the software
architecture and functional programming discourse, and to share
techniques for constructing large long-lived systems in a functional
language.
See [FUNARCH2025 - ICFP/SPLASH] for more information. You may also
browse previous year's submissions [here] and [here].
See you in Singapore!
[idea] <https://functional-architecture.org/>
[FUNARCH2025 - ICFP/SPLASH]
<https://conf.researchr.org/home/icfp-splash-2025/funarch-2025#FUNARCH-2025-Call-for-Papers>
[here] <https://functional-architecture.org/events/funarch-2024/>
[here] <https://functional-architecture.org/events/funarch-2023/>
Proposal for the replacement of Set and Map in the stdlib
═════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/proposal-for-the-replacement-of-set-and-map-in-the-stdlib/16361/1>
Christophe Raffalli announced
─────────────────────────────
Hello,
While working on AVL for teaching I found an alternative to the AVL
that seems overall better than the current ocaml implementation. The
code is available here:
[https://github.com/craff/ocaml-avl/tree/master]. The Readme.md
contains the inequality needed to prove correctness and termination of
the balancing function "join".
The idea is to replace the constraint
┌────
│ |height left_son - height right_son| <= 2
└────
By
┌────
│ size left_son <= 2 * size right_son + 1
│ size right_son <= 2 * size left_son + 1
└────
We see 3 advantages:
• O(1) cardinal of set or map
• slightly simpler code or at least not more complicated (see below)
• seems faster in many cases (not always and strangely depends on
compilation options). Use `dune exec ./test.exe' for some simple
tests.
Before submitting a PR, I think it call be a good idea to call for
comments here.
Cheers, Christophe
[https://github.com/craff/ocaml-avl/tree/master]
<https://github.com/craff/ocaml-avl/tree/master>
A tool to reverse debug OCaml (and other binaries) runs
═══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-a-tool-to-reverse-debug-ocaml-and-other-binaries-runs/16366/1>
Sid Kshatriya announced
───────────────────────
I'd like to announce a debugging tool I've built ! It's called
*_Software Counters mode_ `rr'* .
It is available at <https://github.com/sidkshatriya/rr.soft>
Many of you may have already heard of a debugger called [`rr'] – it
allows you to record and replay programs on Linux. It is extremely
useful for instance to debug issues with garbage collection or other
low level issues in natively compiled OCaml programs. Once you capture
a bug during the record phase, that bug can be replayed any number of
times during replay.
One major limitation of `rr' is that it requires access to CPU
Hardware Performance counters which is usually not available in cloud
VMs or containers.
*_Software Counters mode_ `rr' is a modification of the `rr' debugger
that lifts this limitation – access to CPU Hardware Performance
counters is not required*. This means you can run `rr' in many more
configurations.
I've been able to successfully record/replay the whole OCaml compiler
test suite using _Software Counters_ mode `rr' (Except for a single
ocaml test called `pr2195' which exhausts the file descriptors).
*I've also written a blog post* about record/replay debugging
generally and _Software Counters mode_ in particular. Please see
[here].
[`rr'] <https://github.com/rr-debugger/rr.git>
[here]
<https://github.com/sidkshatriya/me/blob/master/008-rr-everywhere.md>
Feedback request: New lesson on `Lazy'
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/feedback-request-new-lesson-on-lazy/16372/1>
Jakub Svec announced
────────────────────
Hello,
I created a lesson on the `Lazy' module that I'd like to propose for
the language tutorials section of ocaml.org.
You can find the draft on [HackMD]
Please suggest anything you would like, I'm happy to make several
rounds of improvement.
[HackMD] <https://hackmd.io/@wqo57Le0RIyZVlb8qdJ8PA/B1UhnlL2yl>
Lesson implementation decisions:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This lesson is focused on beginners.
The first draft of this lesson is 345 lines, which is on the shorter
side compared to other lessons.
The surface area of the `Lazy' module is small, so I took the
opportunity to supplement the lesson with a thorough explanation of
evaluation strategies. This is supplemental, however, and can be
shortened or removed based on your preferences.
Without the supplemental section, the lesson is only 200 lines long.
OCaml Workshop 2025 at ICFP/SPLASH - announcement and call for proposals
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cfp-ocaml-workshop-2025-at-icfp-splash-announcement-and-call-for-proposals/16373/1>
Kiran Gopinathan announced
──────────────────────────
Hihi everyone!!!
This year, the [ICFP] (International conference on Functional
Programming) Programming Languages conferences will be held in
Singapore (colocated with [SPLASH] in fact!):
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/9/92022b69038715b7dd16ecd9e417b50acbc53dc1_2_1380x552.jpeg>
Continuing this community's annual tradition from 2012, we will be
hosting the OCaml workshop after the ICFP conference, on the *17th
October 2025 (Friday)*. The workshop is intended to cover all
different kinds of aspects of the OCaml programming language as well
as the OCaml ecosystem and its community, such as scientific and/or
research-oriented, engineering and/or user-oriented, as well as social
and/or community-oriented.
[ICFP] <https://icfp25.sigplan.org>
[SPLASH] <https://2025.splashcon.org>
Call for talk proposals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The [call for talk proposals] for the workshop is now open!
[call for talk proposals]
<https://conf.researchr.org/home/icfp-splash-2025/ocaml-2025>
◊ Dates
Here are the important dates:
• Talk proposal submission deadline: *July 3rd (Thursday)*
• Author notification: *August 7th (Thursday)*
• Workshop: *October 17th (Friday)*
◊ Submissions
Submissions are typically around 2 pages long (flexible), describing
the motivations of the work and what the presentation would be about.
We encourage everyone who might be interested in giving a talk to
submit a proposal! We truly mean everyone, and also have strongly
anyone in mind who belongs to a group that’s traditionally
underrepresented at OCaml workshops, e.g. due to your gender(s) or
non-gender, where you’re from or based or whatever other kinds of
characteristics you might have. You should all be able to find all
information you’ll need to submit a proposal on the official [call for
talk proposals]. However, if you have any question, don’t hesitate to
ask us.
[call for talk proposals]
<https://conf.researchr.org/home/icfp-splash-2025/ocaml-2025#Call-for-Presentations>
◊ Quota on accepted talks per affiliation
Following the approach from last year which worked well, this year
again we will try to enforce a quota of a maximum of four talks given
by speakers with the same company/university/institute affiliation. In
order to guarantee a coverage of a diverse range of topics and
perspectives, we’ll experiment with the same affiliation quota again.
Do not hesitate to submit your talk proposal in any case: quotas, if
needed, will be taken into account by the PC after reviewing all
submissions, so there’s no reason to self-select upfront.
About the workshop itself
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
So far, we’ve only covered the talk proposals and formalities. The
exciting part will be the workshop itself! The OCaml workshop is going
to be a whole-day event and, similarly to previous years, it’s likely
going to have four sessions of about four talks each. It’s a fairly
informal and interactive environment, where people engage in all kinds
of conversations about OCaml during the breaks and after the workshop.
◊ Hybrid attendance and cost for speakers
We’re aiming to make the workshop hybrid with the same streaming
modalities as last year, meaning that *talks as well as participation
can be either in-person or remote*, and *remote attendance will be
free*. To promote a good atmosphere, communication and engagement, we
prefer to have most talks in-person, but remote talks will be most
welcome as well.
There may be opportunities for speakers who would not have funding
otherwise (via their employer or university) to attend, although we
are still in the process of confirming this. (Please keep an eye on
this post, which will be updated once we get confirmation!)
We will do our best to provide the best workshop experience possible
for remote participants, within the constraints of the hybrid
format. While attending in-person does come with advantages, it also
comes with an environmental cost, and we strongly support
transitioning to a less plane-intensive organization for conferences
and community events :deciduous_tree: .
◊ Related events
The day before the OCaml workshop, i.e. Oct 16th (Thursday), is the
day of the [ML workshop], with focus on more theoretical aspects of
OCaml and the whole family of ML languages in general. The ML workshop
and tends to be very interesting for OCaml lovers as well.
That aside, this year, I believe, is the first year that both the ICFP
and SPLASH programming languages conferences are going to be
co-located, so this is an exciting opportunity to experience the whole
breadth of two of the top-ranked PL conferences over the span of a
week! What a time to be alive!
We’re looking forward to the the talk submissions and to the workshop!
Let us know if you have any questions. @Gopiandcode & @yasunariw
[ML workshop]
<https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 41848 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-03-18 10:18 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-03-18 10:18 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 13431 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 11 to 18,
2025.
Table of Contents
─────────────────
Upgrading Semgrep from OCaml 4 to OCaml 5 + dynamic_gc utility
Open source OCaml algotrading with longleaf 1.0.0
Neocaml - a TreeSitter-powered Emacs package for OCaml programming
Senior Software Engineer at Bloomberg. New York
Upcoming Cmdliner 2.0 changes that need your attention
Dune dev meeting
New release of Monolith (20250314)
dream_middleware_ext v0.1.0
Learn Programming with OCaml (new book)
Other OCaml News
Old CWN
Upgrading Semgrep from OCaml 4 to OCaml 5 + dynamic_gc utility
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upgrading-semgrep-from-ocaml-4-to-ocaml-5-dynamic-gc-utility/16256/1>
Nat Mote announced
──────────────────
I've written up my experience [upgrading Semgrep to OCaml 5]. The main
barrier we faced was increased memory consumption, but I was able to
tune the garbage collector to address this problem. We have also
open-sourced the [utility I wrote] to adjust the `space_overhead' GC
parameter based on heap size. We are looking forward to taking
advantage of all the great new features in OCaml 5!
[upgrading Semgrep to OCaml 5]
<https://semgrep.dev/blog/2025/upgrading-semgrep-from-ocaml-4-to-ocaml-5/>
[utility I wrote] <https://github.com/semgrep/dynamic-gc>
Open source OCaml algotrading with longleaf 1.0.0
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/open-source-ocaml-algotrading-with-longleaf-1-0-0/16264/1>
adventure announced
───────────────────
Recently, I have been working on a project called [longleaf] for
algorithmic trading of US stocks with OCaml. The project has reached
a point where it may be interesting to others, so I thought I would
share it here and write a simple README, although there could be a lot
more documentation. I would be curious to hear if anyone has any
ideas for this! If you try to use it or have any feedback or
questions, feel free to leave a post here, make a github issue, or
make a github discussion.
In a nutshell, the idea is that strategies are functors that are
instantiated with a "backend" for backtesting, live, or paper trading.
That way, whether you are testing your strategy or running it live, it
is exactly the same strategy other than how the execution of orders is
handled. In order to use it, you will need to set up some accounts
and there are likely bugs. Of course, if you use this program with
real money and something bad happens, it is entirely your
responsibility!
[github]
[longleaf] <https://github.com/hesterjeng/longleaf>
[github] <https://github.com/hesterjeng/longleaf>
Neocaml - a TreeSitter-powered Emacs package for OCaml programming
══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/neocaml-a-treesitter-powered-emacs-package-for-ocaml-programming/16268/1>
Bozhidar Batsov announced
─────────────────────────
In a different topics I wrote about about my recent work on neocaml,
and I thought it might be a good idea to post something separately as
well. Check out the project's GitHub [repo] and the short [blog post].
Contributions and feedback are most welcome, and I hope `neocaml' will
be useful to some of you either a tool or as a source of inspiration.
[repo] <https://github.com/bbatsov/neocaml>
[blog post]
<https://batsov.com/articles/2025/03/14/neocaml-a-new-emacs-package-for-ocaml-programming/>
Senior Software Engineer at Bloomberg. New York
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/senior-software-engineer-at-bloomberg-new-york/16271/1>
Maxim Grankin announced
───────────────────────
Hi everyone! 👋
Bloomberg is looking for a full-time Senior Software Engineer in New
York:
• Gain experience applying functional programming to real production
financial systems
• Use OCaml to develop a robust template system to assist users in
creating a wide range of financial instruments across various asset
classes
• Help shape the strategy for growth of OCaml at Bloomberg by
contributing to the various OCaml infrastructure projects across the
company
• Opportunity to learn some of the financial domain that's at the core
of the extensive derivative functionality
Please see more details and/or apply at [(Senior Software Engineer -
Functional Programming)].
Feel free to reach out to me directly by email
(mgrankin@bloomberg.net) if you have any questions. Thank you!
[(Senior Software Engineer - Functional Programming)]
<https://bloomberg.avature.net/careers/JobDetail?jobId=10730&qtvc=272d0d0846f74b19dc66d7fdc29cec05a0ad67e646ae6c1e1cb94f5ae1c9c4c2#>
Upcoming Cmdliner 2.0 changes that need your attention
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upcoming-cmdliner-2-0-changes-that-need-your-attention/16211/2>
Continuing this thread, Daniel Bünzli announced
───────────────────────────────────────────────
Other [changes] you may want to pay attention to is that cmdliner 2.0
will:
1. Remove deprecated identifiers.
2. Make the [`Arg.conv'] type abstract[^1].
If you happen to be walking around your `cmdliner' usage or making a
new cli these days, pay particular attention to 2. as the concrete
type has been deprecated since 2017 but sadly it was never possible to
make it a visible deprecation (OCaml compiler help us! :man_bowing:).
Note that both 1. and 2. can be resolved now by using cmdliner.1.3.0,
there are a few [instructions here]. It's no guaranteed, but if you
are on `opam' I may have filed an issue in your issue tracker
:waving_hand:.
P.S. I think there's not a single occurence where I did not eventually
regret making a public type concrete.
[^1]: So that completion behaviours can be defined at that level;
aswell as the documentation metavariable which you could specify with
`Arg.conv' constructors for ages but would simply be dropped to return
the concrete pair.
[changes] <https://github.com/dbuenzli/cmdliner/issues/206>
[`Arg.conv']
<https://erratique.ch/software/cmdliner/doc/Cmdliner/Arg/index.html#type-conv>
[instructions here] <https://github.com/dbuenzli/cmdliner/issues/206>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/26>
Etienne Marais announced
────────────────────────
Hi! The next Dune Dev Meeting will be on *Wednesday, March, 19th at
16:00 CET*. This is going to be a one-hour-long meeting.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers :+1:
The agenda is available on the [meeting dedicated page]. Feel free to
add more items in it.
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [dune wiki on GitHub]
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-03-19>
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/u/0/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319@group.calendar.google.com>
[dune wiki on GitHub] <https://github.com/ocaml/dune/wiki>
New release of Monolith (20250314)
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-monolith-20250314/16303/1>
François Pottier announced
──────────────────────────
I am pleased to announce a new "Pi Day" release of Monolith.
Monolith is an OCaml library that helps perform black-box testing of
OCaml libraries, either via purely random testing, or via grey-box
fuzzing.
This new release adds new command-line options to the executable
program that Monolith produces by default. Furthermore, it extends
Monolith's API with a new function, `run', so the user can invoke
Monolith's engine as part of their own application, without letting
Monolith parse the command line. These improvements make it easier to
use a Monolith-based test as part of a continuous integration (CI)
system. Thanks to Gabriel Scherer for suggesting these improvements.
┌────
│ opam update
│ opam install monolith.20250314
└────
Happy testing!
dream_middleware_ext v0.1.0
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-middleware-ext-v0-1-0/16306/1>
Geoffrey Borough announced
──────────────────────────
A collection of middleware utilities for Dream framework, Initial
release v0.1.0
Currently supporting the following functionalities:
CORS: Cross-Origin Resource Sharing
Delay: simulates delayed request
Rate Limiter: supports Fixed Window and Token Bucket algorithms
Traffic Filter: supports IP, header and cookie based traffic filters
• Project page: <https://github.com/axons-talent/dream_middleware_ext>
• Documentation:
<https://axons-talent.github.io/dream_middleware_ext/dream_middleware_ext>
Learn Programming with OCaml (new book)
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/learn-programming-with-ocaml-new-book/16111/13>
Continuing this thread, Jean Christophe Filliatre announced
───────────────────────────────────────────────────────────
[A preliminary EPUB version of the book] is now available. Feedback is
most welcome (preferably by [submitting an issue here]).
Big thanks to @Chet_Murthy who spent weeks working this out from our
LaTeX sources.
[A preliminary EPUB version of the book]
<https://usr.lmf.cnrs.fr/lpo/lpo.epub>
[submitting an issue here]
<https://github.com/backtracking/learn-programming-with-ocaml/issues>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [OCaml’s Standard Library (`Stdlib')]
• [neocaml: a new Emacs package for OCaml programming]
• [We're Moving Ocsigen from Lwt to Eio!]
• [Finding Signal in the Noise with In Young Cho]
[the ocaml.org blog] <https://ocaml.org/blog/>
[OCaml’s Standard Library (`Stdlib')]
<https://batsov.com/articles/2025/03/14/ocaml-s-standard-library/>
[neocaml: a new Emacs package for OCaml programming]
<https://batsov.com/articles/2025/03/14/neocaml-a-new-emacs-package-for-ocaml-programming/>
[We're Moving Ocsigen from Lwt to Eio!]
<https://tarides.com/blog/2025-03-13-we-re-moving-ocsigen-from-lwt-to-eio>
[Finding Signal in the Noise with In Young Cho]
<https://signals-threads.simplecast.com/episodes/finding-signal-in-the-noise-with-in-young-cho-qBmfD9v_>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 23920 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-03-11 15:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-03-11 15:00 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 19905 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 04 to 11,
2025.
Table of Contents
─────────────────
OCaml projects utilizing Category theory
Docker base images and OCaml-CI support for OCaml < 4.08
ocamlmig, a tool to rewrite ocaml code, and complement `[@@deprecated]'
Ortac 0.6.0 improve bug reporting
Dune Developer Preview Updates
ppxlib.0.36.0
I created an OCaml grammar for ANTLR4 (Earley parser compatible)
Melange 5.0
Other OCaml News
Old CWN
OCaml projects utilizing Category theory
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-projects-utilizing-category-theory/16206/5>
Deep in this thread, Dmitrii Kovanikov announced
────────────────────────────────────────────────
I started writing [a series of articles about Pragmatic Category
Theory] in OCaml, and there's a repository with examples:
• <https://github.com/chshersh/pragmatic-category-theory>
If you're interested in a complete project, I made *CCL: Categorical
Configuration Language* which leverages multiple Category Theory
concepts:
• [The Most Elegant Configuration Language by @chshersh]
I'm currently working on a [GitHub TUI] project in OCaml but the usage
of CT concepts is not that crazy there. For now, I only use Semigroup
and Monoids (which some people don't even consider part of CT but just
Abstract Algebra).
[a series of articles about Pragmatic Category Theory]
<https://chshersh.com/blog/2024-07-30-pragmatic-category-theory-part-01.html>
[The Most Elegant Configuration Language by @chshersh]
<https://chshersh.com/blog/2025-01-06-the-most-elegant-configuration-language.html>
[GitHub TUI] <https://github.com/chshersh/github-tui>
Docker base images and OCaml-CI support for OCaml < 4.08
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/docker-base-images-and-ocaml-ci-support-for-ocaml-4-08/16229/1>
Mark Elvers announced
─────────────────────
The [opam repository archival] process has set the minimum supported
OCaml version to 4.08 _for opam repository_. It logically follows
that opam-repo-ci should only test against OCaml >= 4.08.
The purpose of this post is to get a sense of whether the rest of the
OCaml infrastructure should also adopt the same lower bound. The
current lower bound is 4.02.
Specific examples include OCaml-CI. Individual projects can already
opt out of testing on older platforms by adding a lower bound in the
opam file.
Docker base images are built for all versions of OCaml used in the CI
systems. These images are published weekly on Docker Hub. We know
that these images are also used by the community, but the pull counter
is not broken down by individual tag. Potentially only the latest
OCaml versions are being used.
Users impacted by packages which have been archived from opam
repository can easily restore the packages by adding the archive
repository to the opam switch. This only needs to be done once.
Users can build their own Docker base images, but they would need to
be rebuilt periodically to keep them up to date.
Would removing testing on < 4.08 in OCaml CI or removing the Docker
base images < 4.08 impact you?
[opam repository archival]
<https://discuss.ocaml.org/t/opam-repository-archival-phase-2-ocaml-4-08-is-the-lower-bound/15965>
ocamlmig, a tool to rewrite ocaml code, and complement `[@@deprecated]'
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocamlmig-a-tool-to-rewrite-ocaml-code-and-complement-deprecated/16090/10>
v-gb announced
──────────────
Hi,
I released a new version of ocamlmig in opam, whose main change is to
avoid reformatting everything in codebases that don't use
ocamlformat. Instead, only subexpressions touched by a rewrite are
reformatted. It also requalifies identifier in more places to
preserve their meaning (e.g. when replacing `string_of_int' by
`Int.to_string', there might be an `Int' module in scope that's not
`Stdlib.Int'. In such case, ocamlmig would more often replace
`string_of_int' by `Stdlib.Int.to_string').
Separately, I've thought about the recent addition of let+ operators
in Cmdliner, and how one might migrate from the use of `$' to
them. Concretetely, given:
┌────
│ let bistro () (`Dry_run dry_run) (`Package_names pkg_names) ... = the code
│ open Cmdliner
│ let term = Term.(const bistro $ Cli.setup $ Cli.dry_run $ ...)
└────
you'd want to have instead:
┌────
│ open Cmdliner
│ let term =
│ Term.(Syntax.(
│ let+ () = Cli.setup
│ and+ (`Dry_run dry_run) = Cli.dry_run
│ and+ (`Package_names pkg_names) = ...
│ ...
│ in
│ the code))
└────
ocamlmig can now transform code this way, at the tip of the ocamlmig
repo (not the last release). You can see it [in the second commit in
this branch] (and further mechanical cleanups in the commits with "…"
bubbles), but to explain a bit:
┌────
│ let bistro () (`Dry_run dry_run) (`Package_names pkg_names) ... = the code
│ open Cmdliner
│ let term = Term.(const bistro $ Cli.setup $ Cli.dry_run $ ...)
└────
is first turned into:
┌────
│ open Cmdliner
│ let term = Term.(const (fun () (`Dry_run dry_run) (`Package_names pkg_names) ... -> the code)
│ $ Cli.setup $ Cli.dry_run $ ...)
└────
which is then turned into the final code:
┌────
│ open Cmdliner
│ let term =
│ Term.(Syntax.(
│ let+ () = Cli.setup
│ and+ (`Dry_run dry_run) = Cli.dry_run
│ and+ (`Package_names pkg_names) = ...
│ ...
│ in
│ the code))
└────
The first step is done using `ocamlmig replace -w -e 'const [%move_def
__f] /// const __f''. In short, what this does is anytime it sees
`const some-identifier', it tries to inline the definition of the
identifier. In details, the left side of the `///' specifies the code
to search for, and the right side what to replace it with. `const ...'
searches for literally `const' applied to one argument. `[%move_def
__f]' is trickier: it matches identifiers that are let-bound somewhere
in the current file, removes said let binding, and recursively matches
the right hand side of the binding against `__f'. Variables that start
with two underscores name a term for use in the replacement
expression.
The second step is done with:
┌────
│ ocamlmig replace -w \
│ -e 'const (fun __p1 __p2 __p3 -> __body) $ __e1 $ __e2 $ __e3
│ /// let open Syntax in let+ __p1 = __e1 and+ __p2 = __e2 and+ __p3 = __e3 in __body'
└────
This is longer, but given the previous explanation, it's hopefully
fairly clear what this does. The only twist is that ocamlmig
generalizes this search/replace for three elements into an n-ary
version (implicitly, although perhaps it should be explicit).
And that's it. So this is the full command that I used:
┌────
│ ocamlmig replace -w \
│ -e 'const [%move_def __f] /// const __f' \
│ -e 'const (fun __p1 __p2 __p3 -> __body) $ __e1 $ __e2 $ __e3
│ /// let open Syntax in let+ __p1 = __e1 and+ __p2 = __e2 and+ __p3 = __e3 in __body'
└────
which seems pretty reasonable considering the rewrite is somewhat
sophisticated.
In general, mechanizing a change can reduce the chance of accidentally
modifying something, but in this specific case, ocamlmig also detects
shadowing when moving code with `[%move_def]'. Shadowing would likely
cause type errors or tests errors, but if it didn't, it'd be quite
hard to catch during code review.
Finally, if you want to try this out on your code, I'll note that
`ocamlmig replace' is in flux, and that while the commands above work,
obvious variations of them may not.
[in the second commit in this branch]
<https://github.com/tarides/dune-release/pull/503/commits>
Ortac 0.6.0 improve bug reporting
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ortac-0-6-0-improve-bug-reporting/16232/1>
Nicolas Osborne announced
─────────────────────────
Hi everyone!
We - at Tarides - are very pleased to announce the release of the
Ortac-0.6.0 packages for specification-driven testing!
Ortac/QCheck-STM is a test generator based on the [QCheck-STM]
model-based testing framework and the [Gospel] specification language
for OCaml.
In addition to generating QCheck-STM tests based on the Gospel
specifications, `Ortac/QCheck-STM' computes and display a bug report
in case of test failure.
This report contains the piece of Gospel specification that has been
violated, a runnable scenario to reproduce the bug and the expected
returned value (if there is enough information in the specification to
compute it).
This release improves the reporting in two ways.
First, the way we need to formulate the description of the expected
returned value has been made more flexible (and fixed). The main
limitation was about functions returning a boolean. Because of the
coercion mechanism, Gospel often transforms equalities involving a
boolean into a double implication. For example: `b = Sequence.mem
t.contents a' is transformed into `b = true <-> Sequence.mem
t.contents a'. (For the curious, this is because `Sequence.mem'
returns a `prop', not a `bool', and we don't have equality on
`prop'). `Ortac/QCheck-STM' now explores more patterns, including the
double implication one, to try to find a suitable description of the
returned value to use in the bug report.
Secondly, and more importantly, the Gospel specification language
supports partial functions (`Sequence.hd' is *not* defined on the
empty sequence for example). When we translate calls to such function
to OCaml, we raise an exception when the call is out of the function's
domain. Now, that exception was captured by QCheck at runtime, making
the test a failure as expected. But the Ortac runtime was then stopped
before being able to build and send the bug report to QCheck for
display to the user. That was sad, so I've fixed it. We can now make
use of Gospel partial functions when writing specifications and enjoy
the bug report computed by `Ortac/QCheck-STM'!
You can install Ortac/QCheck-STM via opam (we also advise installing
and using Ortac/Dune):
┌────
│ $ opam install ortac-qcheck-stm ortac-dune
└────
You'll find more information in [Ortac/QCheck-STM documentation] and
in The [Ortac/Dune readme].
If you have any questions, please don't hesitate to ping me :-)
Next release should be about making Ortac/QCheck-STM generate tests of
a library in a parallel context (this is, after all, one of the
*raison d'être* of the fantastic QCheck-STM test framework!).
Happy testing!
[QCheck-STM] <https://github.com/ocaml-multicore/multicoretests>
[Gospel] <https://github.com/ocaml-gospel/gospel>
[Ortac/QCheck-STM documentation]
<https://ocaml-gospel.github.io/ortac/ortac-qcheck-stm/index.html>
[Ortac/Dune readme]
<https://github.com/ocaml-gospel/ortac/tree/main/plugins/dune-rules#dune-rules-plugin-for-ortac>
Dune Developer Preview Updates
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160/57>
Leandro Ostera announced
────────────────────────
Hello everyone! :waving_hand: Hope you had a great end of 2024 and
your 2025 is starting well too :D
We've been hard at work at Tarides to improve the Dune Developer
Preview, and we'd love to learn more about what your adoption hurdles
have been, so here's a very short form you can fill to let us know
what's up.
Happy hacking! :two_hump_camel:
<https://forms.gle/piaw12XBYUeaCmg56>
ppxlib.0.36.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-ppxlib-0-36-0/16241/1>
Patrick Ferris announced
────────────────────────
The ppxlib team is happy to announce the release of `ppxlib.0.36.0'!
A full account of the changes can be found [on the 0.36.0 release].
[on the 0.36.0 release]
<https://github.com/ocaml-ppx/ppxlib/releases/tag/0.36.0>
OCaml 5.2 Internal AST
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The main change in this release is that the internal AST used in
ppxlib is now the same as OCaml 5.2's AST. Previously it was
4.14.0. The internal AST dictates what features your ppx can and
cannot generate. To avoid confusion, this does _not_ mean ppxlib only
supports OCaml 5.2 and greater. Ppxlib still supports compilers
starting at 4.08.0.
*The bump to 5.2 has caused a lot of reverse dependencies to break* as
the 5.2 AST represents functions differently ([see the Syntactic
Function Arity RFC]). Many patches have already been sent to users of
ppxlib in the past few months, but quite a few still remain.
:warning: Ppx authors are advised to read [the wiki entry for
upgrading to ppxlib.0.36.0]. :warning:
Please do not hesitate to reach out if you need any help upgrading to
`ppxlib.0.36.0'.
[see the Syntactic Function Arity RFC]
<https://github.com/ocaml/RFCs/pull/32>
[the wiki entry for upgrading to ppxlib.0.36.0]
<https://github.com/ocaml-ppx/ppxlib/wiki/Upgrading-to-ppxlib-0.36.0>
Other Changes
╌╌╌╌╌╌╌╌╌╌╌╌╌
• Change `Location.none' to match the compiler's `Location.none' as of
OCaml 4.08.
• New ways to create context free rules using floating expansions –
see [#560] for the details.
• Add a `-raise-embedded-errors' flag to the driver. Setting this flag
raises the first `ocaml.error' embedded in the final AST.
• Export `Ast_pattern.fail' making it easier to write new
pattern-matchers.
• Improvements to `Ast_traverse.sexp_of' to be more concise.
Do read the changes entry/release for all of the acknowledgments –
thank you to everyone who contributed to this release of ppxlib! A
special thanks from me to @NathanReb who has been a massive help
getting this work over the line.
Thank you to Tarides and Jane Street for funding my time on this
release of ppxlib.
[#560] <https://github.com/ocaml-ppx/ppxlib/pull/560>
I created an OCaml grammar for ANTLR4 (Earley parser compatible)
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/i-created-an-ocaml-grammar-for-antlr4-earley-parser-compatible/16246/1>
ao wang announced
─────────────────
Hi everyone,
I’ve created an ANTLR4 grammar for OCaml that supports Earley parsing.
Feel free to use it, and any feedback or contributions are welcome!
GitHub Repository:
<https://github.com/WangAo0311/Antlr4-ocaml-earley-parser-grammar>
Melange 5.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-melange-5-0/16247/1>
Antonio Nuno Monteiro announced
───────────────────────────────
Dear OCaml users,
I'm proud to announce the release of Melange 5.0
Melange is a backend for the OCaml compiler that emits
JavaScript. This release features improvements across a few areas,
mostly targeting OCaml 5.3 support and JavaScript expressivity:
• OCaml version support: we’re releasing Melange 5 with full support
across a few OCaml versions: 4.14, 5.1, 5.2 and the recently
released 5.3
‣ Melange uses a versioning scheme similar to Merlin’s: releases are
suffixed with the OCaml version they support, e.g. 5.0.1-414,
5.0.1-53, etc.
• We're introducing build system-aware, type-safe support for
JavaScript's [dynamic import], allowing to code split
Melange-generated JavaScript bundles without sacrificing
type-safety.
• Melange can now express [discriminated unions], a JavaScript pattern
that
The [release announcement] blog post covers the changes in a lot more
detail. Please give it a read.
I'm excited to count on the support of our financial sponsors [Ahrefs]
and the [OCaml Software Foundation], without which this release would
not have been possible.
[dynamic import]
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>
[discriminated unions]
<https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#discriminated-unions>
[release announcement]
<https://melange.re/blog/posts/announcing-melange-5>
[Ahrefs] <https://ahrefs.com/jobs>
[OCaml Software Foundation] <https://ocaml-sf.org/>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [OpenAI and structured outputs from OCaml]
• [Feature Parity Series: Statmemprof Returns!]
• [Announcing Melange 5]
• [Learning OCaml: Functions without Parameters]
[the ocaml.org blog] <https://ocaml.org/blog/>
[OpenAI and structured outputs from OCaml]
<https://tech.ahrefs.com/openai-and-structured-outputs-from-ocaml-b198fcf701ca?source=rss----303662d88bae--ocaml>
[Feature Parity Series: Statmemprof Returns!]
<https://tarides.com/blog/2025-03-06-feature-parity-series-statmemprof-returns>
[Announcing Melange 5]
<https://melange.re/blog/posts/announcing-melange-5>
[Learning OCaml: Functions without Parameters]
<https://batsov.com/articles/2025/03/02/learning-ocaml-functions-without-parameters/>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 34934 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-03-04 14:01 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-03-04 14:01 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 34056 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 25 to
March 04, 2025.
Table of Contents
─────────────────
Bytecode debugging in OCaml 5.3
Zanuda – OCaml linter experiment
QCheck 0.24
Bogue, the OCaml GUI
Opam repository archival - next phase
Upcoming Cmdliner 2.0 changes that need your attention
OCaml Editors Plugins Survey
Dune dev meeting
Platform Newsletter: September - December 2024
Other OCaml News
Old CWN
Bytecode debugging in OCaml 5.3
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bytecode-debugging-in-ocaml-5-3/16177/7>
Continuing this thread, Henry Till said
───────────────────────────────────────
Probably worth sharing here:
• [gdb.py]
• [gdb_ocamlrun.py]
• [lldb.py]
• [Getting Started with GDB on OCaml]
[gdb.py]
<https://github.com/ocaml/ocaml/blob/f08e8a1ad48013dbdefc0e5415c2bf48a6881de8/tools/gdb.py>
[gdb_ocamlrun.py]
<https://github.com/ocaml/ocaml/blob/f08e8a1ad48013dbdefc0e5415c2bf48a6881de8/tools/gdb_ocamlrun.py>
[lldb.py]
<https://github.com/ocaml/ocaml/blob/f08e8a1ad48013dbdefc0e5415c2bf48a6881de8/tools/lldb.py>
[Getting Started with GDB on OCaml]
<https://kcsrk.info/ocaml/gdb/2024/01/20/gdb-ocaml/>
Chet Murthy also said
─────────────────────
For those who (like me) have always been perplexed when they try to
use ocamldebug, b/c it just doesn't seem to work like gdb or perl's
debugger, or any other debugger I've tried, this video was immensely
helpful.
<https://www.youtube.com/watch?v=DGvJk14sfi8&t=724s>
Specifically, I learned that at the beginning of the program, to set a
breakpoint in the main program file, I need to do something like (for
a file "extract_environments.ml", and line 79):
┌────
│ break @extract_environments 79
└────
That was blocking me FOREVER, b/c holy cow there's a ton of
initialization, and I just didn't know how to run thru all that and
get to the first meaningful line of my main program.
Now I do. I can move forward from here with ocamldebug. Finally!
Zanuda – OCaml linter experiment
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-zanuda-ocaml-linter-experiment/11784/2>
Kakadu announced
────────────────
I'm using this linter for teaching for two years, and I'm very happy
that I implemented it. Student's code is much less annoying to read
:slight_smile:
Release 1.1.0
╌╌╌╌╌╌╌╌╌╌╌╌╌
• #22: Add 'reviewer' tool to report lint's a Github review.
• #13: Discourage matching a tuple using 'match' expression with
single branch
┌────
│ match x with (a,b) -> ...
└────
• #18: Warn about unneeded mutually recursive types
• #23: Implement a trial version of the Fix module for auto-correction
of lints. It produces a diff that could be applied later. Dune
support is lacking
• Add command line switch '-skip-level-allow <bool>' to enable/disable
lints with level=Allow. False has higher priority than per-lint
command line switch (for example, `-no-string_concat')
• #28: Warn about too many nested `if' expressions.
• #32: Warn about constructor names that hide default constructor
names
• #35: Detect manual implementations of List.map/fold functions
• #50: Propose eta reduction when available
• #51: Warn about pattern matching on boolean values
• #53: Warn about `"%s"' in formatted strings
• #54: Detection of unused public declarations in .mli file.
• #56: Simplify lint about missing license. We look for required
doc-comments anywhere in the file, not only in the beginning.
• #60: Skip some checks for some source files (configured via
'.zanuda' config file).
• #15: Split 'string_concat' lint to check separately patterns 'a^b^c'
(level=Allow) and 'List.fold_left (^)' (level=Warn).
QCheck 0.24
═══════════
Archive: <https://discuss.ocaml.org/t/ann-qcheck-0-24/16198/1>
Jan Midtgaard announced
───────────────────────
I'm happy to announce the 0.24 release of `qcheck', `qcheck-core',
`qcheck-alcotest', and `qcheck-ounit', along with a 0.6 release of
`ppx_deriving_qcheck' :tada:
`QCheck' is a library for randomized property-based testing, inspired
by Haskell's seminal QuickCheck library. The 0.24 release contains a
range of improvements to the integrated shrinking of `QCheck2',
initially introduced in the 0.18 release. As a consequence, its
shrinking algorithms should act more predictably, reduce faster, and
report smaller counterexamples. In essence, the 0.24 release is what
we hoped 0.18 would be. The release also adds missing `result',
`int32', and `int64' combinators, as well as more documentation.
If you've previously given `QCheck2''s integrated shrinking a spin, I
encourage you to try it again with the patched 0.24 release. For new
users, the 0.24 release is also a good candidate to check out!
:smiley: Please share any problems you encounter on the `qcheck' repo:
<https://github.com/c-cube/qcheck>
Full change log:
• [qcheck-alcotest] Add an optional `speed_level' parameter to
`to_alcotest'
• Adjust the `QCheck2.Gen.list' shrinker to produce minimal
counterexamples at size 3 too
• Replace the `QCheck2' OCaml 4 `Random.State.split' hack with a
faster one
• Improve the `QCheck2.Gen.list' shrinker heuristic and utilize the
improved shrinker in other `QCheck2'
`{list,array,bytes,string,function}*' shrinkers
• Use `split' and `copy' in `Random.State' underlying `QCheck2' to
avoid non-deterministic shrinking behaviour
• Add missing documentation strings for
`QCheck.{Print,Iter,Shrink,Gen}' and `QCheck2.Gen'.
• Add `result' combinators to `QCheck',
`QCheck.{Gen,Print,Shrink,Observable}', and
`QCheck2.{Gen,Print,Observable}'.
• Add missing combinators `QCheck{,2}.Print.int{32,64}',
`QCheck.Gen.int{32,64}', `QCheck{,2}.Observable.int{32,64}', and
deprecate `QCheck.Gen.{ui32,ui64}'
• Document `dune' usage in README
Happy testing! :smiley: :keyboard:
Bogue, the OCaml GUI
════════════════════
Archive: <https://discuss.ocaml.org/t/ann-bogue-the-ocaml-gui/9099/63>
sanette announced
─────────────────
Dear all,
I’m happy to announce a new version of [Bogue], version 20250224, now
availble on `opam'.
The main novelty is a brand new *File dialog*. It will open a new
window (or popup) which will let the user navigate the file system and
select one or more files or directories.
This corresponds to the new [File] module.
You might also be interested in the [Monitor] submodule, which
implements a *file monitoring* API based on `fswatch' (if available)
or `Unix.stat'.
If you are curious, here is a graphical summary of the current
functionalities of Bogue's file dialog (I hope that more will be added
soon; I'm open to suggestions)
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/b/b6efbe5eb40237db0fc4b5f036b1637a79de7875.png>
PS: @Sachindra_Ragul, yes we did it finally ;) better late than never
[Bogue] <https://github.com/sanette/bogue>
[File] <http://sanette.github.io/bogue/Bogue.File.html>
[Monitor] <http://sanette.github.io/bogue/Bogue.File.Monitor.html>
Opam repository archival - next phase
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-archival-next-phase/16203/1>
Hannes Mehnert announced
────────────────────────
Dear everyone,
sorry for the silence – the phase 3 of the opam repository archival
(taking the x-maintenance-intent into account) has to be delayed by
(tentatively) one month. The reason is that our tooling is not ready -
the task, given an opam repository and maintenance-intent on packages,
which can be safely archived, is harder than it seems:
• we've to take compiler versions into account
• there may be a package X in version 1 and 2, both supporting OCaml
4.08, but depend on package Y (where X.1 depends on Y >= 1, and X.2
depends on Y >= 2) – now Y.1 could support OCaml 4.08, and Y.2 only
OCaml 4.12 – so it is not safe to archive X.1 (since on OCaml 4.08
there won't be any X installable). And this may be deeply nested in
the dependency chain
It is useful if you mark your packages with `x-maintenance-intent' (as
mentioned in
<https://discuss.ocaml.org/t/opam-repository-archive-clarification-of-the-opam-fields>).
We'll let you know once we have tooling in place to cope with the task
described above (development is happening here:
<https://github.com/hannesm/maintenance-intent-filter>).
Upcoming Cmdliner 2.0 changes that need your attention
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upcoming-cmdliner-2-0-changes-that-need-your-attention/16211/1>
Daniel Bünzli announced
───────────────────────
If you are a user of `cmdliner' note that cmdliner 2.0 – in exchange
for auto-completion support – will remove the ability to specify
command and options names by unambiguous prefixes according to [this
plan of action].
If you are horrified by it please chime in on the issue.
[this plan of action] <https://github.com/dbuenzli/cmdliner/issues/200>
OCaml Editors Plugins Survey
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-editors-plugins-survey/16216/1>
PizieDust announced
───────────────────
Hello, we are conducting a short survey to better understand how you
use the different editor plugins available for OCaml. Please take a
few minutes (ideally 5) to fill out the form.
<https://docs.google.com/forms/d/e/1FAIpQLSfGGFZBiw4PF7L0yt2DBX8443G5_7aFL5v6wvo6p5MwL-DW8Q/viewform?usp=pp_url&entry.454013858=Discuss>
Thank you :) :camel:
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/25>
Etienne Marais announced
────────────────────────
Hi everyone :camel:
The next Dune Dev Meeting will be on *Wednesday, March, 5th at 9:00
CET*. This is going to be a one-hour-long meeting.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers :smile:
The agenda is available on the [meeting dedicated page]. Feel free to
add more items in it.
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with informations and previous notes: [dune wiki on github]
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-03-05>
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/u/0/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319@group.calendar.google.com>
[dune wiki on github] <https://github.com/ocaml/dune/wiki>
Platform Newsletter: September - December 2024
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/platform-newsletter-september-december-2024/16221/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the thirteenth edition of the OCaml Platform newsletter!
In this September-December 2024 edition, we are excited to bring you
the latest on the OCaml Platform, continuing our tradition of
highlighting recent developments as seen in [previous editions]. To
understand the direction we're headed, especially regarding
development workflows and user experience improvements, check out our
[roadmap].
*Highlights:*
• *Dune Enables Cache By Default, Adds WebAssembly Support* The latest
Dune releases mark significant progress in build performance and
language support. Version 3.17.0 enables the Dune cache by default
for known-safe operations, improving build times for common
tasks. The addition of Wasm_of_ocaml support opens new possibilities
for OCaml projects targeting the web or other WebAssembly
runtimes. In addition, Dune now supports adding Codeberg and GitLab
repositories via the `(source)' stanza.
• *opam 2.3.0* As announced with opam 2.2, opam releases are now
time-based with a cadence of 6 months. Opam 2.3 has been released
last November. It contains a major breaking change regarding
extra-files handling: extra-files are now ignored when they are not
present in the opam file. Previously they were silently added. This
release adds also some new commands like `opam list --latest-only'
or `opam install foo --verbose-on bar', among other fixes and
enhancements.
• *Improved Editor Workflows with OCaml-LSP and Merlin* A major
milestone for project-wide features has been reached with the
release of OCaml 5.3: LSP's renaming feature now [_renames symbols
in the entire project_] if the index is built. Additionally,all of
the classic merlin-server commands are now available as LSP custom
requests: this enabled the addition of [many new features to the
Visual Studio Code plugin]. Finally a brand new Emacs mode, based on
LSP and the new custom queries is [now available on Melpa].
• *Performance and Security Enhancements* Recent updates across the
platform focus on performance and reliability. Dune optimized its
handling of .cmxs files, while opam implemented stricter git
submodule error checking. OCaml-LSP resolved file descriptor leaks,
contributing to a more stable development environment.
*Feature Guides & Announcements:*
• [Installing Developer Tools with Dune]
• [Shell Completions in Dune Developer Preview]
• [OCaml Infrastructure: Enhancing Platform Support and User
Experience]
• [Call for Feedback]
*Releases:*
• [OCaml-LSP 1.20.1]
• [opam-publish 2.5.0]
• [Merlin 5.3-502 for OCaml 5.2 and 4.18-414 for OCaml 4.14]
• [Dune 3.17.1]
• [OCamlformat 0.27.0]
• [Dune 3.17.0]
• [opam 2.3.0]
• [Dune 3.16.1]
• [Merlin 5.2.1-502 for OCaml 5.2 and 4.17.1 for OCaml 5.1 and 4.14]
[previous editions] <https://discuss.ocaml.org/tag/platform-newsletter>
[roadmap] <https://ocaml.org/docs/platform-roadmap>
[_renames symbols in the entire project_]
<https://discuss.ocaml.org/t/ann-merlin-and-ocaml-lsp-support-experimental-project-wide-renaming/16008>
[many new features to the Visual Studio Code plugin]
<https://tarides.com/blog/2025-02-28-full-blown-productivity-in-vscode-with-ocaml/>
[now available on Melpa] <https://melpa.org/#/ocaml-eglot>
[Installing Developer Tools with Dune]
<https://ocaml.org/changelog/2024-11-15-installing-developer-tools-with-dune>
[Shell Completions in Dune Developer Preview]
<https://ocaml.org/changelog/2024-10-29-shell-completions-in-dune-developer-preview>
[OCaml Infrastructure: Enhancing Platform Support and User Experience]
<https://ocaml.org/changelog/2024-10-02-updates>
[Call for Feedback]
<https://ocaml.org/changelog/2024-09-25-call-for-feedback>
[OCaml-LSP 1.20.1]
<https://ocaml.org/changelog/2024-12-23-ocaml-lsp-1.20.1>
[opam-publish 2.5.0]
<https://github.com/ocaml-opam/opam-publish/releases/tag/2.5.0>
[Merlin 5.3-502 for OCaml 5.2 and 4.18-414 for OCaml 4.14]
<https://ocaml.org/changelog/2024-12-23-merlin-5.3.502-and-4.18.414>
[Dune 3.17.1] <https://ocaml.org/changelog/2024-12-18-dune.3.17.1>
[OCamlformat 0.27.0]
<https://ocaml.org/changelog/2024-12-02-ocamlformat-0.27.0>
[Dune 3.17.0] <https://ocaml.org/changelog/2024-11-27-dune.3.17.0>
[opam 2.3.0] <https://ocaml.org/changelog/2024-11-13-opam-2-3-0>
[Dune 3.16.1] <https://ocaml.org/changelog/2024-10-30-dune.3.16.1>
[Merlin 5.2.1-502 for OCaml 5.2 and 4.17.1 for OCaml 5.1 and 4.14]
<https://ocaml.org/changelog/2024-09-27-merlin-5.2.1>
*Dune*
╌╌╌╌╌╌
*Roadmap:* [Develop / (W4) Build a Project]
[Dune 3.17 was released] with significant improvements to package
management. Key features include binary distribution support, better
error messages for missing packages, and Windows support without
requiring OPAM.
The [Dune Developer Preview website] now provides editor setup
instructions and package management tutorials.
Dune's package management features [were tested across hundreds of
packages] in the opam repository, and a coverage tool was developed to
track build success rates. For local development, Dune added support
for building dependencies via `@pkg-install', caching for package
builds, and automated binary builds of development tools. The system
supports both monorepo and polyrepo workflows, with options for
installing individual dependencies or complete development
environments.
The addition of [Wasm_of_ocaml support in Dune] opens new
possibilities for OCaml projects targeting the web or other
WebAssembly runtimes.
*Activities:*
• Updated preview website with editor setup instructions at
<https://preview.dune.build> and published binary installer
providing prebuilt Dune binaries
• [Enable dune cache by default]
• [Added wasm_of_ocaml support]
• Added support for [Codeberg] and [GitLab organizations] in the
`(source)' stanza
• [Added support for `-H' compiler flag] enabling better semantics for
`(implicit_transitive_deps false)'
*Maintained by:* Rudi Grinberg (@rgrinberg, Jane Street), Nicolás
Ojeda Bär (@nojb, LexiFi), Marek Kubica (@Leonidas-from-XIV,
Tarides), Etienne Millon (@emillon, Tarides), Stephen Sherratt
(@gridbugs, Tarides), Antonio Nuno Monteiro (@anmonteiro)
[Develop / (W4) Build a Project]
<https://ocaml.org/docs/platform-roadmap#w4-build-a-project>
[Dune 3.17 was released]
<https://discuss.ocaml.org/t/ann-dune-3-17/15770>
[Dune Developer Preview website] <https://preview.dune.build>
[were tested across hundreds of packages] <https://dune.check.ci.dev/>
[Wasm_of_ocaml support in Dune]
<https://github.com/ocaml/dune/pull/11093>
[Enable dune cache by default]
<https://github.com/ocaml/dune/pull/10710>
[Added wasm_of_ocaml support] <https://github.com/ocaml/dune/pull/11093>
[Codeberg] <https://github.com/ocaml/dune/pull/10904>
[GitLab organizations] <https://github.com/ocaml/dune/pull/10766>
[Added support for `-H' compiler flag]
<https://github.com/ocaml/dune/pull/10644>
*Editor Tools*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Roadmap:* [Edit / (W19) Navigate Code], [Edit / (W20) Refactor Code]
Developer tooling received substantial upgrades during the end of last
year and the beginning 2025. A major milestone for project-wide
features has been reached with the release of OCaml 5.3: LSP's
renaming feature now [_renames symbols in the entire project_] if the
index is built. Additionally, all of the classic merlin-server
commands are now available as LSP custom requests: this enabled the
addition of [many new features to the Visual Studio Code plugin] and
the creation of a brand new Emacs mode, based on LSP, [now available
on Melpa].
These features bring OCaml editor support closer to modern IDE
capabilities, with implementations available across multiple editors.
[Edit / (W19) Navigate Code]
<https://ocaml.org/tools/platform-roadmap#w19-navigate-code>
[Edit / (W20) Refactor Code]
<https://ocaml.org/tools/platform-roadmap#w20-refactor-code>
[_renames symbols in the entire project_]
<https://discuss.ocaml.org/t/ann-merlin-and-ocaml-lsp-support-experimental-project-wide-renaming/16008>
[many new features to the Visual Studio Code plugin]
<https://tarides.com/blog/2025-02-28-full-blown-productivity-in-vscode-with-ocaml/>
[now available on Melpa] <https://melpa.org/#/ocaml-eglot>
◊ Merlin and OCaml LSP Server
Support for project wide renaming, search-by-type, and
ocaml-lsp-server now exposes all Merlin features via LSP custom
queries.
*Notable Activity*
• OCaml 5.3 support ([merlin#1850])
• Project-wide renaming is now available. ([ocaml-lsp#1431] and
[merlin#1877])
• A new option to mute hover responses has been added for better
integration with alternative hover providers ([ocaml-lsp#1416])
• New type-based search support similar to Hoogle ([ocaml-lsp#1369]
and [merlin#1828])
*Bug Fixes*
• Fixed completion range issues with polymorphic variants
([ocaml-lsp#1427])
• Fixed various issues with jump code actions and added customization
options ([ocaml-lsp#1376])
• Various fixes and improvements have been made to signature help and
inlay hints
[merlin#1850] <https://github.com/ocaml/merlin/pull/1850>
[ocaml-lsp#1431] <https://github.com/ocaml/ocaml-lsp/pull/1431>
[merlin#1877] <https://github.com/ocaml/merlin/pull/1877>
[ocaml-lsp#1416] <https://github.com/ocaml/ocaml-lsp/pull/1416>
[ocaml-lsp#1369] <https://github.com/ocaml/ocaml-lsp/pull/1369>
[merlin#1828] <https://github.com/ocaml/merlin/pull/1828>
[ocaml-lsp#1427] <https://github.com/ocaml/ocaml-lsp/issues/1427>
[ocaml-lsp#1376] <https://github.com/ocaml/ocaml-lsp/pull/1376>
◊ Visual Studio Code plugin
Added support for most of the Merlin features historically availbale
to Emacs and Vim users, via the new LSP custom requests.
*Notable Activity*
• Improved typed-of-selection feature, with ability to grow or shrink
the selection and increase verbosity ([#1675]).
• Improved jump navigation ([#1654]), search-by-type ([#1626])
• Improved typed holes navigation ([#1666]).git push –set-upstream
origin publish_platform_newsletter_q4_24
• New search-by-type command ([#1626]).
*OCaml LSP Server maintained by:* Ulysse Gérard (@voodoos, Tarides),
Xavier Van de Woestyne (@xvw, Tarides), Rudi Grinberg (@rgrinberg,
Jane Street)
*Merlin maintained by:* Ulysse Gérard (@voodoos, Tarides), Xavier Van
de Woestyne (@xvw, Tarides)
[#1675] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/1675>
[#1654] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/1654>
[#1626] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/1626>
[#1666] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/1666>
◊ Emacs support
A brand new Emacs plugin based on the Eglot LSP client is now ready
for daily usage: <https://github.com/tarides/ocaml-eglot>.
*Documentation Tools*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Roadmap:* [Share / (W25) Generate Documentation]
[Share / (W25) Generate Documentation]
<https://ocaml.org/tools/platform-roadmap#w25-generate-documentation>
◊ Odoc
*Maintained by:* Jon Ludlam (@jonludlam, Tarides), Daniel Bünzli
(@dbuenzli), Jules Aguillon (@julow, Tarides), Paul-Elliot Anglès
d'Auriac (@panglesd, Tarides), Emile Trotignon (@EmileTrotignon,
Tarides, then Ahrefs)
There is now a [beta release for odoc 3] that you can try out and give
feedback on!
During the quarter, odoc has been making steady progress toward its
3.0 release with several notable improvements:
• *Enhanced Navigation*: The sidebar and breadcrumbs navigation has
been unified and improved ([#1251]), making the documentation
hierarchy more consistent and flexible. This allows better
organization of modules, pages, and source files in the
documentation.
• *Documentation Features*: New features have been added to Odoc 3
([#1264]), including:
• Support for images with embedded assets
• Cross-package linking (linking to modules from external libraries)
• *Search Integration*: Sherlodoc, the search functionality, has been
merged into the main odoc codebase ([#1263]), ensuring better
maintenance and synchronized releases.
*Notable Activity*
• [Odoc 3 Beta Release]
[beta release for odoc 3]
<https://discuss.ocaml.org/t/ann-odoc-3-beta-release/16043>
[#1251] <https://github.com/ocaml/odoc/pull/1251>
[#1264] <https://github.com/ocaml/odoc/pull/1264>
[#1263] <https://github.com/ocaml/odoc/pull/1263>
[Odoc 3 Beta Release]
<https://discuss.ocaml.org/t/ann-odoc-3-beta-release/16043>
◊ Mdx upgraded to OCaml 5.3
*Maintained by:* Marek Kubica (@Leonidas-from-XIV, Tarides), Thomas
Gazagnaire (@samoht, Tarides)
With OCaml 5.3, some compiler error messages changed, so MDX was
updated to use a more expressive tag system to choose which version of
the compiler can run which code block. This effort uncovered a bug in
the current handling of skipped blocks for `mli' files, which was
fixed.
*Notable Activity*
• OCaml 5.3 support ([#457]), ensuring the tool remains compatible
with the latest OCaml releases.
• Fixed error handling for skipped blocks in `mli' files ([#462])
• Improved syntax highlighting ([#461])
• Added support for multiple version labels ([#458]), improving the
ability to test code across different OCaml versions.
[#457] <https://github.com/realworldocaml/mdx/pull/457>
[#462] <https://github.com/realworldocaml/mdx/pull/462>
[#461] <https://github.com/realworldocaml/mdx/pull/461>
[#458] <https://github.com/realworldocaml/mdx/pull/458>
*Package Management*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Opam
[Opam 2.3.0 was released in November]. We are now working towards the
2.4 release, with some new sub commands (`admin', `source', `switch',
etc.), fixes (pinning, switch, software heritage fallback, UI) and
enhancements.
*Notable Activity*
• Add several checksum, `extra-files' and `extra-source' lints -
[#5561]
• Add options `opam source --require-checksums' and `--no-checksums'
to harmonise with `opam install' - [#5563]
• Add the current VCS revision information to `opam pin list' -
[#6274] - fix [#5533]
• Make opamfile parsing more robust for future changes - [#6199] - fix
[#6188]
• Fix `opam switch remove <dir>' failure when it is a linked switch -
[#6276] - fix [#6275]
• Fix `opam switch list-available' when given several arguments -
[#6318]
• Correctly handle `pkg.version' pattern in `opam switch
list-available' - [#6186] - fix [#6152]
• Fix sandbox for NixOS [#6333], and `DUNE_CACHE_ROOT' environment
variabale usage - [#6326]
• Add `opam admin compare-versions' to ease version comparison for
sanity checks [#6197] and fix `opam admin check' in the presence of
some undefined variables - [#6331] - fix [#6329]
• When loading a repository, don’t automatically populate
`extra-files:' field with found files in `files/' - [#5564]
• Update and fix Software Heritage fallback - [#6036] - fix [#5721]
• Warn if a repository to remove doesn’t exist - [#5014] - fix [#5012]
• Silently mark packages requiring an unsupported version of opam as
unavailable - [#5665] - fix [#5631]
• Display switch invariant with the same syntax that it is written in
file (no pretty printing) - [#5619] - fix [#5491]
• Fix output display regarding terminal size [#6244] - fix [#6243]
• Change default answer display - [#6289] - fix [#6288]
• Add a warning when setting a variable with `opam var' if an option
is shadowed - [#4904] - fix [#4730]
• Improve the error message when a directory is not available while
fetching using rsync - [#6027]
• Fix `install.exe' search path on Windows - [#6190]
• Add `ALTLinux' support for external dependencies - [#6207]
• Make `uname' information more robust accros ditributions - [#6127]
*Maintained by:* Raja Boujbel (@rjbou - OCamlPro), Kate Deplaix
(@kit-ty-kate, Ahrefs), David Allsopp (@dra27, Tarides)
[Opam 2.3.0 was released in November]
<https://ocaml.org/changelog/2024-11-13-opam-2-3-0>
[#5561] <https://github.com/ocaml/opam/issues/5561>
[#5563] <https://github.com/ocaml/opam/issues/5563>
[#6274] <https://github.com/ocaml/opam/issues/6274>
[#5533] <https://github.com/ocaml/opam/issues/5533>
[#6199] <https://github.com/ocaml/opam/issues/6199>
[#6188] <https://github.com/ocaml/opam/issues/6188>
[#6276] <https://github.com/ocaml/opam/issues/6276>
[#6275] <https://github.com/ocaml/opam/issues/6275>
[#6318] <https://github.com/ocaml/opam/issues/6318>
[#6186] <https://github.com/ocaml/opam/issues/6186>
[#6152] <https://github.com/ocaml/opam/issues/6152>
[#6333] <https://github.com/ocaml/opam/issues/6333>
[#6326] <https://github.com/ocaml/opam/issues/6326>
[#6197] <https://github.com/ocaml/opam/issues/6197>
[#6331] <https://github.com/ocaml/opam/issues/6331>
[#6329] <https://github.com/ocaml/opam/issues/6329>
[#5564] <https://github.com/ocaml/opam/issues/5564>
[#6036] <https://github.com/ocaml/opam/issues/6036>
[#5721] <https://github.com/ocaml/opam/issues/5721>
[#5014] <https://github.com/ocaml/opam/issues/5014>
[#5012] <https://github.com/ocaml/opam/issues/5012>
[#5665] <https://github.com/ocaml/opam/issues/5665>
[#5631] <https://github.com/ocaml/opam/issues/5631>
[#5619] <https://github.com/ocaml/opam/issues/5619>
[#5491] <https://github.com/ocaml/opam/issues/5491>
[#6244] <https://github.com/ocaml/opam/issues/6244>
[#6243] <https://github.com/ocaml/opam/issues/6243>
[#6289] <https://github.com/ocaml/opam/issues/6289>
[#6288] <https://github.com/ocaml/opam/issues/6288>
[#4904] <https://github.com/ocaml/opam/issues/4904>
[#4730] <https://github.com/ocaml/opam/issues/4730>
[#6027] <https://github.com/ocaml/opam/issues/6027>
[#6190] <https://github.com/ocaml/opam/issues/6190>
[#6207] <https://github.com/ocaml/opam/issues/6207>
[#6127] <https://github.com/ocaml/opam/issues/6127>
◊ Dune-release
*Roadmap:* [Share / (W26) Package Publication]
Dune-release has been improved to better handle publishing packages
from custom repositories and private Git repositories.
*Notable Activity*
• Support for overwriting the dev-repo field when creating GitHub
tags/releases ([#494]), which a useful for private projects
*Maintained by:* Thomas Gazagnaire (@samoht, Tarides), Etienne Millon
(@emillon, Tarides), Marek Kubica (@Leonidas-from-XIV, Tarides)
[Share / (W26) Package Publication]
<https://ocaml.org/tools/platform-roadmap#w26-package-publication>
[#494] <https://github.com/tarides/dune-release/pull/494>
◊ Opam-publish
*Notable Activity*
• Integration of Opam CI Lint functionality into `opam-publish'
([#166], [#165]) to validate packages before submission
• A new `--pre-release' argument added to handle pre-release packages
correctly ([#164])
*Maintained by:* Raja Boujbel (@rjbou - OCamlPro), Kate Deplaix
(@kit-ty-kate, Ahrefs)
[#166] <https://github.com/ocaml-opam/opam-publish/pull/166>
[#165] <https://github.com/ocaml-opam/opam-publish/issues/165>
[#164] <https://github.com/ocaml-opam/opam-publish/pull/164>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Full blown productivity in VSCode with OCaml]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Full blown productivity in VSCode with OCaml]
<https://tarides.com/blog/2025-02-28-full-blown-productivity-in-vscode-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 47588 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-02-25 10:36 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-02-25 10:36 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 25836 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 18 to 25,
2025.
Table of Contents
─────────────────
Early work experimenting with zig as a cross-compiler for OCaml
Dune dev meeting
Outreachy June 2025
Js_of_ocaml 6.0.1 / Wasm_of_ocaml
Bytecode debugging in OCaml 5.3
New F* release on opam (2025.02.17)
Other OCaml News
Old CWN
Early work experimenting with zig as a cross-compiler for OCaml
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/early-work-experimenting-with-zig-as-a-cross-compiler-for-ocaml/16151/1>
Chris Armstrong announced
─────────────────────────
This is some early work [using zig as a cross-compiler] for building
OCaml cross-compilation systems:
[opam-cross-lambda]
*Status*: It is currently severely untested but the aim is to be able
to cross-compile to Linux from Windows/Mac/Linux for aarch64 and
x86_64 CPU architectures simply by adding an opam repository, and
without the need for nix.
*Why:* The novel aspect is zig, which allows you to cross-compile C
code without needing to install or set up a cross-compilation sysroot
i.e. glibc, gcc, binutils, kernel headers etc. as zig packages much
of the needed headers and symbol information internally.
*Next steps:* start importing packages (including those with native
binaries) into the opam repository overlay, validate them in CI/CD
This approach has led me down some rabbit-holes with a bunch of
learning - some interesting points:
• zig uses clang internally, so its effectively testing clang
compatibility with OCaml's autoconf + Makefile assumptions about the
C compiler
• targeting windows isn't possible with this setup at this time,
because flexdll hardcodes mingw binary names
(e.g. x86_64-w64-mingw32-gcc) in its Makefile and the flexlink
binary (it assumes these exist because targeting mingw32 is always a
cross-compilation, even on Windows). It also depends on binutils'
windres, which zig does not provide a wrapper for.
• targeting macos x is untested
• as you can see in the CI/CD scripts, setting the ZIG cache directory
environment variables is crucial for MacOS because of opam's
sandboxing (zig builds its cache in the user's home directory, which
is outside the default sandbox)
• although ocamlfind and dune have some cross-compilation support with
"toolchains", there are gaps and undocumented assumption
• opam doesn't really support cross-compilation environments well -
packages often don't require much change, but you do need to create
a `<package>-cross-<cross-name>' version of every single package -
this could be a lot more straightforward and less work with a more
cohesive platform strategy for cross-compilation
*Alternatives*: I'm aware of alternatives in the ecosystem (and indeed
have benefitted from):
• [ocaml nix overlays] - these offer a far better tested and
reproducible cross-compilation environment, mostly for systems that
can run nix
• [opam-cross-windows] - lots of little nuggets of build-time
information found in here
[using zig as a cross-compiler]
<https://ruoyusun.com/2022/02/27/zig-cc.html>
[opam-cross-lambda]
<https://github.com/chris-armstrong/opam-cross-lambda>
[ocaml nix overlays] <https://github.com/nix-ocaml/nix-overlays>
[opam-cross-windows]
<https://github.com/ocaml-cross/opam-cross-windows/tree/main/packages>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/24>
Continuing this thread, art-w announced
───────────────────────────────────────
Thanks everyone for joining! The meetings notes are here:
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-02-19>
Outreachy June 2025
═══════════════════
Archive: <https://discuss.ocaml.org/t/outreachy-june-2025/16154/1>
Patrick Ferris announced
────────────────────────
Hi everyone!
Once again, the OCaml community has signed up to Outreachy (see [past]
[posts])!
[past] <https://discuss.ocaml.org/t/outreachy-summer-2023/11159>
[posts]
<https://discuss.ocaml.org/t/outreachy-december-2024-round/15223>
What is Outreachy?
──────────────────
Outreachy is a paid, remote internship program. Outreachy promotes
diversity in open source and open science. Our internships are for
people who face under-representation, and discrimination or systemic
bias in the technology industry of their country.
The current round is still ongoing with an intern making great
progress on [ocaml-api-watch] with @NathanReb and @panglesd.
[ocaml-api-watch] <https://github.com/ocaml-semver/ocaml-api-watch>
Important Dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
For this next round, the important dates are as follows (these are
always subject to some change):
• Feb 26 - Community sign up deadline :white_check_mark:
• Mar 7 - [Mentor project description deadline]
• Mar 10 to Apr 8 - Contribution period
• Jun 2 to Aug 29 - Internship period
Our next deadline is for mentors to sign up to the OCaml community
with a project idea. Please do consider being an Outreachy mentor. If
you have any questions or ideas you can always reach out to me
directly. If you need a refresher of past projects, there's a
dedicated page on the OCaml website: <https://ocaml.org/outreachy>.
The OCaml community is currently able to financially support Outreachy
internships thanks to the generous support of [Tarides] and
[Janestreet].
Thanks! :camel:
[Mentor project description deadline]
<https://www.outreachy.org/communities/cfp/ocaml/>
[Tarides] <https://tarides.com>
[Janestreet] <https://www.janestreet.com>
Js_of_ocaml 6.0.1 / Wasm_of_ocaml
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-js-of-ocaml-6-0-1-wasm-of-ocaml/16160/1>
Jérôme Vouillon announced
─────────────────────────
I’m pleased to announce the joint release of js_of_ocaml 6.0.1 and
wasm_of_ocaml.
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.
[Wasm_of_ocaml] is a compiler from OCaml bytecode to WebAssembly. It
is highly compatible with Js_of_ocaml, so you can compile your
programs with wasm_of_ocaml instead of js_of_ocaml and experience
overall better performance. It is [supported by Dune 3.17], making the
switch very easy.
Most significant changes in js_of_ocaml:
• The conversion between Javascript numbers and OCaml floats is now
explicit, using functions `Js.float' and `Js.to_float' (this is
necessary for wasm_of_ocaml which does not use the same
representation for JS numbers and OCaml floats)
• `Dom_html' has been modernized, removing some no longer relevant
`Js.optdef' type annotations
• Effects:
‣ add an optional feature of "dynamic switching" between CPS and
direct style, resulting in better performance when no effect
handler is installed
‣ make resuming a continuation more efficient
See the [Changelog] for other changes.
[Wasm_of_ocaml]
<https://opam.ocaml.org/packages/wasm_of_ocaml-compiler/>
[supported by Dune 3.17]
<https://dune.readthedocs.io/en/stable/wasmoo.html>
[Changelog]
<https://github.com/ocsigen/js_of_ocaml/blob/master/CHANGES.md>
Olivier Nicole then added
─────────────────────────
Regarding wasm_of_ocaml, Tarides also just posted [a blog post] with
some more details about its recent developments, and what kind of
performance gains have been observed with it.
I want to insist that building your project to Wasm can be as simple
as enabling the `wasm' mode in dune. To quote the documentation page
cited by Jérôme:
┌────
│ (executable (name foo) (modes wasm))
└────
And then request the .wasm.js target:
┌────
│ $ dune build ./foo.bc.wasm.js
│ $ node _build/default/foo.bc.wasm.js
│ hello from wasm
└────
[a blog post]
<https://tarides.com/blog/2025-02-19-the-first-wasm-of-ocaml-release-is-out/>
Bytecode debugging in OCaml 5.3
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bytecode-debugging-in-ocaml-5-3/16177/1>
gasche announced
────────────────
Today I conducted a small experiment of using a debugger on a small
OCaml program (built using `dune'). The program is not written by me,
does non-trivial things, and is written in such a way that my usual
approaches to understand what is going on would require more work than
I want to pour in it.
I took notes on this experience, in the hope that it could be of
interest to others – maybe I'm doing things wrong and people will let
me know, maybe this can help identify potential tooling improvements.
Disclaimer: I am a complete beginner as far as running OCaml debuggers
goes. (I have used `ocamldebug' and `gdb' irregularly in the past,
never heaily, and long forgotten how to use them.)
TL;DR:
╌╌╌╌╌╌
Bytecode debugging with OCaml 5.3 and dune:
• works fine in Emacs/Tuareg, as it did in the past
• works okay in vscode using ocamlearlybird
• could be improved with a bit more targeted work, some of it probably
easy (and some of it hard)
If I understand correctly, no one is specifically working on this
right now. Let me take this occasion to thank the people who
contributed to all these tools (Tuareg, ocamldebug, ocamlearlybird,
vscode+ocaml integration, dune, etc.).
Why a debugger?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I am looking at an OCaml program that I did not write, and does
interesting and complex things. I would like to build my understanding
of how it works by observing the flow of values in some parts of the
program, on concrete examples of interest.
I am unfamiliar with debuggers and tried other things first:
1. I considered modifying the code to print the values it encouters at
runtime. But the program does not define pretty-printers for its
values, and writing them is cumbersome. (I could probably use
`deriving' to produce debuggers more easily.)
2. My next move is usually `dune utop': instead of running the
program, I can call its library functions via the toplevel on small
examples. But this particular program is only a binary, it was not
split as a library and a binary, and splitting it would be
non-trivial.
When "printf debugging" and "play in the toplevel" are not immediately
within reach, it may be time to try a debugger. They should let us
stop at a given point in the program, print values, and move around in
the execution trace to better understand what is going on.
Running a debugger in general
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
To run a debugger on OCaml programs, one has to choose between a
bytecode debugger, `ocamldebug', and native debuggers such as `gdb'
and `lldb'.
Native debuggers are not OCaml-specific and likely to be better
documented, have more integrated tooling etc., but they are more
low-level and don't know as much about OCaml programs; in particular
they're not so good at printing values.
On the other hand `ocamldebug' can print OCaml values, and it is a
time-travel debugger that supports going backward in time; but it
relies on running the bytecode executable that is probably 10x slower
than the native executable. It is also probably worse when debugging
cross-language programs, for example using the FFI.
I would not try `ocamldebug' to debug performance-sensitive programs,
programs in production, and in particular to debug anything resembling
a segmentation fault. But it should offer a nice experience for
pure-OCaml programs during their development.
The Coq/Rocq maintainers have long been using `ocamldebug' to
understand their software, a large OCaml program with tricky bugs and
non-trivial performance requirements. They rely on specific tooling to
make it nicer – autoloaded scripts, customized pretty-printers. So
there is evidence that `ocamldebug' can work well when integrated
inside a project development workflow. (Here the program I want to
debug has /not/ had any such written, so it will be more barebones.)
Getting a bytecode executable from Dune
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Before going any further, you need to ask `dune' to generate bytecode
executables, by adding
┌────
│ (modes byte exe)
└────
to the `executable' stanza. Then you run `dune build', and when
invoking the debugger you will need to manually pass the path to the
bytecode program, for example `_build/default/bin/main.bc'.
IDE integration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Running `ocamldebug' directly is doable but not great. Just like it's
nice when IDEs let you jump to the location of a compilation error,
you really want the debugger to show you "where" it is in the program
execution by showing you a program point in your programming
editor. (`ocamldebug' will print the source line where it is at, so
it's not too bad, but still noticeably less pleasant, and typing
movement commands one by one gets old fast.)
I considered two approaches to running a bytecode debugger for OCaml
programs:
• run `ocamldebug' from Emacs/Tuareg
• run `ocamlearlybird' from VsCode
◊ ocamlearlybird in vscode
I first decided to use ocamlearlybird from vscode.
I opened vscode (which is not my usual editor) and tried to use `Run >
start debugging' directly… and it didn't work well. You need to
configure things manually, and the vscode interface did not tell me
that, it would show nothing and appear not to work as expected but
without much help.
The better way to configure vscode+earlybird is to… read the
documentation first. I recommend:
1. Read the [vscode-ocaml-platform README.md] about how to setup
things.
2. then read the [ocamlearlybird README] (which also links to the
README above), in particular watch the short demo, to know what to
expect when the interface works. The README documents the field of
the `launch.json' file that you have to write to describe how to
invoke the debugger, and this is helpful.
After reading this, I knew how to tweak the `launch.json' file so that
the debugger would pass command-line arguments to the program, and it
started working correctly.
Unfortunately `ocamlearlybird' does not current support time-travel
([issue]), so it is only possible to stop at breakpoints and move
forward in time, while I was expecting to run until a failure and then
go backward in time, as I usually do with `ocamldebug'. At this point
I decided to go back to my familiar Emacs.
[vscode-ocaml-platform README.md]
<https://github.com/ocamllabs/vscode-ocaml-platform#debugging-ocaml-programs-experimental>
[ocamlearlybird README]
<https://github.com/hackwaly/ocamlearlybird?tab=readme-ov-file>
[issue] <https://github.com/hackwaly/ocamlearlybird/issues/78>
◊ Points to improve
When trying to "run the debugger" without having configured a
specific bytecode program, the vscode UI appears to work but does
nothing. For example it is possible to add breakpoints, etc., and
then clicking "run" does nothing that I can see.
I wish there was clearer feedback when things are not setup and
there is no chance that it will work. This would also be a good time
to point me to the online documentation – from within the IDE – so
that the process is more discoverable.
◊ ocamldebug in Emacs
At this point I had already set things up to build a bytecode
executable in Dune, so things were easy: `M-x ocamldebug' and there
you go. There is [documentation in the user manual], which was
probably written more than a decade ago, and it mostly reads just fine
today.
(Note: some of the documented keybindings do not work: `C-c C-k' is
documented as stepping back in the manual, but it is not supported by
Tuareg ([issue]).)
Moving around program execution is fun, printing values works okay –
the next step for convenience would be to install custom printers to
get nice output.
[documentation in the user manual]
<https://ocaml.org/manual/5.3/debugger.html>
[issue] <https://github.com/ocaml/tuareg/pull/227>
◊ Points to improve
1. Emacs jumps to source code to follow the program execution in the
debugger; but on every movement in the execution trace it asks me
again whether I want `src/foo.ml' instead of
`_build/default/src/foo.ml', and this is annoying. (Sometimes I
did not observe this behavior, not sure why.)
2. Dune includes various wrapping/mangling of module names that show
up in the `ocamldebug' printing, and can be annoying at time. For
example some module names show up as `Dune__exe.Foo', and I would
prefer to see just `Foo'. I think it should be possible to
hard-code some more de-Dune-mangling logic in the debugger's
pretty-printer, and ideally we could even make them
user-configurable or dune-configurable a bit.
3. If I print an AST from an execution point that does not have
`open Ast' in its typing environment, the AST is printed like
`Dune__exe.Ast.Let (Dune__exe.Ast.Var "x", ...)'. It would be
nice to omit the `Dunne__exe' part, but ideally I should also be
able to tell the debugger: "let's open `Ast' locally from now on
when you print values", so that it prints in a more readable way
by default.
Vincent Laviron replied
───────────────────────
Nice post, thanks !
A few things I would like to add:
• Time travelling is possible for the native debuggers with `rr'. At
some point it was Linux-only, it might still be the case, but it's
/very/ nice to use. I have on some occasions debugged bytecode
programs by using `rr' on it, and with the appropriate gdb/lldb
macros to print OCaml values it can be useful (but mostly for
debugging the C parts; for problems purely on the OCaml side
`ocamldebug' is still better suited). I use it regularly for native
debugging and it's very convenient (it can even help with debugging
eisenbugs in parallel programs ! Just run `rr record ./my_program'
several times until the bug triggers, and then `rr replay' will
always replay the same run, including thread interleavings,
consistently reproducing the bug).
• I have tried time travelling with `ocamldebug' in the past and I
have hit some serious issues: limited history means that you cannot
go very far in the past, and the way it works (by setting
checkpoints and replaying from the checkpoint to the required
instruction) means that you can often see weird artifacts due to C
calls being replayed each time you step back, sometimes breaking the
program completely. I'm curious to know if this is just bad luck (or
me doing weird things), or if you had similar issues too.
• The `Dune__exe' stuff is, I believe, `dune''s misguided attempt to
shield users from potential conflicts between files linked in the
executable and modules with the same name present in non-wrapped
libraries required as dependencies. I suspect that `(wrapped false)'
or something like that in the section of the dune file corresponding
to the executable will get rid of it.
Tim McGilchrist also replied
────────────────────────────
It is possible to use `ocamlearlybird' with `dap-mode' in Emacs
[link]. The setup uses the same json config file as VSCode. I'm
putting my effort into DAP support since that gets cross editor
support and I can switch between LLDB/ocamlearlybird.
For Emacs the two main options for DAP support are:
‣ dap-mode, which ties into lsp-mode and follows that style of
things. Uses JSON configuration based off VSCode configuration. The
UI elements depend on lsp-mode, so it's a heavier setup and might
not play as well with eglot.
‣ dape, standalone DAP mode with a more minimal approach. I didn't get
it working satisfactorily but it seems closer to eglot in philosophy
<https://github.com/svaante/dape>
For both I see the challenges are:
1. Setting up DAP itself reliably and with less fuss. It could be
smoother and better documented.
2. Setting up dune builds to generate the right artifacts. Having a
direct LSP code action to run a debugger against a particular
executable like Rust does would be ideal.
3. Bugs in ocamlearlybird and lack of maintainer time.
It's interesting to hear about users of bytecode debugging, I thought
there wouldn't be many people using that.
[link]
<https://lambdafoo.com/posts/2024-03-25-ocaml-debugging-with-emacs.html>
Nicolas Ojeda Bar also replied
──────────────────────────────
For example some module names show up as `Dune__exe.Foo',
and I would prefer to see just `Foo'.
This is controlled by `(wrapped_executables <bool>)' in
`dune-project':
<https://dune.readthedocs.io/en/latest/reference/dune-project/wrapped_executables.html>
New F* release on opam (2025.02.17)
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-f-release-on-opam-2025-02-17/16179/1>
Chandradeep Dey announced
─────────────────────────
Hello! It is my pleasure to announce that F* is once again available
on opam for direct installation after a long time. This probably does
not mean much to regular users, as there were regular releases on
GitHub for some time now. However, the opam release offers a
convenient alternative by eliminating the need to separately set up
OCaml to compile extracted OCaml code.
From the [website] - F* is a general-purpose proof-oriented
programming language, supporting both purely functional and effectful
programming. It combines the expressive power of dependent types with
proof automation based on SMT solving and tactic-based interactive
theorem proving.
The biggest new thing worth mentioning is perhaps the Pulse DSL for
programming with concurrent separation logic. A tutorial is available
in the F* book, Proof-oriented Programming in F*. A comprehensive
overview of various projects that have utilized F* over the years can
also be found on the website.
Feel free to join the [Zulip forum] for discussions with the
developers, researchers, and casual users. Happy writing provably
correct programs!
[website] <https://fstar-lang.org/>
[Zulip forum] <https://fstar.zulipchat.com/>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [How I fixed Slipshow's worst flaw using OCaml and a monad]
• [The First Wasm_of_ocaml Release is Out!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[How I fixed Slipshow's worst flaw using OCaml and a monad]
<https://choum.net/panglesd/undo-monad/#step2torevisit>
[The First Wasm_of_ocaml Release is Out!]
<https://tarides.com/blog/2025-02-19-the-first-wasm-of-ocaml-release-is-out>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 38002 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-02-18 14:33 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-02-18 14:33 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 11076 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 11 to 18,
2025.
Table of Contents
─────────────────
Learn Programming with OCaml (new book)
Ocsigen's 2024 recap
OCaml GADTs for Authentication Tokens
OCaml language committe launched
Dune dev meeting
Asking For Community Feedback on the OCaml Platform Communications
Old CWN
Learn Programming with OCaml (new book)
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/learn-programming-with-ocaml-new-book/16111/1>
Jean Christophe Filliatre announced
───────────────────────────────────
Dear OCaml community,
A long time ago, Sylvain and I wrote a French book on [learning
programming with OCaml]. Recently, the OCaml Software Foundation
funded its translation to English. The book is available here:
[Learn Programming with OCaml]
Many thanks to [Urmila] for a translation of high quality.
The book is available as a PDF file, under the [CC-BY-SA license]. The
source code for the various programs contained in the book are
available for download, under the same license.
The book is structured in two parts. The first part is a
tutorial-like introduction to OCaml through 14 small programs,
covering many aspects of the language. The second part focuses on
fundamental algorithmic concepts, with data structures and algorithms
implemented in OCaml. This is also a nice way to learn a language!
The book does not cover all aspects of OCaml. It is ideally
complemented by [other books on OCaml].
[learning programming with OCaml]
<https://usr.lmf.cnrs.fr/programmer-avec-ocaml/>
[Learn Programming with OCaml] <https://usr.lmf.cnrs.fr/lpo/>
[Urmila] <https://www.aropefastenedbetween.fr/>
[CC-BY-SA license]
<https://creativecommons.org/licenses/by-sa/4.0/deed.en>
[other books on OCaml] <https://ocaml.org/books>
Ocsigen's 2024 recap
════════════════════
Archive: <https://discuss.ocaml.org/t/ocsigens-2024-recap/16117/1>
William Caldwell announced
──────────────────────────
Hi all!
2024 was a busy year for the Ocsigen ecosystem, in case you missed any
of it, here are the important highlights:
wasm_of_ocaml has been merged in its parent project js_of_ocaml,
making your Ocsigen projects that much closer to being served as WASM
instead of JavaScript. In the meantime you can build your own WASM by
using wasm_of_ocaml to get a taste of the future.
Major work has been undertaken on Ocsigen:
• Ocsigen Server 6
• Eliom 11
• Ocsigen Start 7
Ocsigen server no longer needs a configuration file to start your
project, you can instead start Ocsigen server in your project and
handle the configuration yourself. If you're eager to
`Ocsigen_server.start ...' you can learn more in the following
announcements:
• [ocsigen server 6]
• [Eliom 11 and Osigen Start 7]
Ready for 2025? We certainly are! Our efforts to make the Ocsigen
ecosystem more modular are ongoing: next on the list is ocsigen-i18n,
making easier to pick and choose what bits of Ocsigen you want to
include in your project, and allowing to use it for any OCaml
application. The biggest evolution of the Ocsigen project is underway
& soon to be announced, and that's not even including wasm\_of\_ocaml.
Also keep an eye out for our public meeting announcements in which we
discuss our current tasks, ask for public feedback, and answer
whatever Ocsigen related questions you might have.
[ocsigen server 6]
<https://discuss.ocaml.org/t/ann-ocsigen-server-6-0-0/15265>
[Eliom 11 and Osigen Start 7]
<https://discuss.ocaml.org/t/ann-eliom-11-and-ocsigen-start-7/15487>
OCaml GADTs for Authentication Tokens
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-ocaml-gadts-for-authentication-tokens/16128/1>
Maxim Grankin announced
───────────────────────
Hi everyone! 👋
My name is Max, I've been using OCaml for a while during my years at
Bloomberg and at some moment decided to dig a little bit into GADTs. I
found couple of use cases for them and decided to write down one in
detail:
• [OCaml GADTs for Authentication Tokens]
I hope it would help newcomers to find application for GADTs in their
projects.
Huge thanks to @chshersh for reviewing this blog post!
Enjoy and let me know what you think in the comments!
[OCaml GADTs for Authentication Tokens]
<https://dev.to/maxim092001/ocaml-gadts-for-authentication-tokens-57be>
OCaml language committe launched
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-language-committe-launched/16129/1>
octachron announced
───────────────────
It is my pleasure to announce the launch of the OCaml language
committee. This committee is intended as collegial instance with the
aim to facilitate discussions and consensus making about the evolution
of the OCaml language and its standard library.
Over the years, it has become a common shared grievance among both
maintainers and contributors to the OCaml language that, sometimes,
the review process for changes grinds to a halt, either because
consensus is elusive or because no one feels empowered enough to take
a decision single-handed.
In order to reduce the number of those instances of decision
paralysis, the OCaml maintainers have decided to experiment with an
OCaml language committee: [a subgroup of the OCaml community]
organised to discuss evolution of the OCaml language in a timely
fashion.
In practice, if someone feels that a contribution (a Pull Request,
issue, Request For Comment) might be stuck or might benefit from a
wider discussion, they may ask the committee to take the contribution
under consideration by mentioning it to the committee chair (which is
currently me, aka @Octachron on github).
Then the committee will deliberate on this contribution both on the
[archived] public mailing list `ocaml-language-committee@inria.fr' for
internal committee discussion [^1] and possibly on the relevant
community channels ([ocaml/ocaml] or [here on discuss]). At the end of
this collegial discussion, the committee will publish a consultative
decision on the matter. We expect that having such a collegial
consultative decision would be enough to unblock most situations.
For more details, the intended working of the committee is described
at <https://github.com/ocaml/RFCs/blob/master/Committee.md> .
Happy hacking, Florian Angeletti for the OCaml Language Committee
[^1]: Anyone is welcome to subscribe to the mailing list to attend to
the discussions, but please do not flood the mailing list so that we
can keep it fully open.
[a subgroup of the OCaml community]
<https://github.com/ocaml/RFCs/blob/master/Committee.md#who-is-the-committee>
[archived] <https://sympa.inria.fr/sympa/arc/ocaml-language-committee>
[ocaml/ocaml] <https://github.com/ocaml/ocaml/>
[here on discuss] <https://discuss.ocaml.org>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/23>
art-w announced
───────────────
Hello! The next Dune Dev Meeting will be on *Wednesday, February, 19th
at 4pm CET* for an hour long discussion.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers.
The agenda is available on the [meeting dedicated page]. Feel free to
add more items in it.
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with informations and previous notes: [dune wiki on github]
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-02-19>
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/u/0/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319@group.calendar.google.com>
[dune wiki on github] <https://github.com/ocaml/dune/wiki>
Asking For Community Feedback on the OCaml Platform Communications
══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/asking-for-community-feedback-on-the-ocaml-platform-communications/16142/1>
Sabine Schmaltz announced
─────────────────────────
Hi all,
I'm looking for feedback on the OCaml Platform communications,
especially the Platform Newsletter and the [OCaml.org] Changelog.
For this, I have prepared a Google form survey (you can send me your
responses by email if you prefer):
<https://docs.google.com/forms/d/e/1FAIpQLSctTt-WtWEU9heJixGAcAxeUxZhPeX0ioTnaPk6VKTwYHHs9A/viewform>
The survey aims to improve both the *process* and the *usefulness* of
the *OCaml Platform communications* and to help me create a handbook
that gives a clear picture of all our developer-focused communication
channels, as well as how the *new Developer Advocate role* at Tarides
can support the maintainers in these communications.
A major aim of this effort is to *adapt the process* around the
communications to minimize the amount of friction imposed on engineers
and to maximize the *usefulness to the readers*.
Thanks for your help!
[OCaml.org] <http://ocaml.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 21238 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-02-11 7:17 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-02-11 7:17 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 7051 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 04 to 11,
2025.
Table of Contents
─────────────────
ocamlmig, a tool to rewrite ocaml code, and complement `[@@deprecated]'
Mopsa 1.1 – Modular Open Platform for Static Analysis
Other OCaml News
Old CWN
ocamlmig, a tool to rewrite ocaml code, and complement `[@@deprecated]'
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocamlmig-a-tool-to-rewrite-ocaml-code-and-complement-deprecated/16090/1>
v-gb announced
──────────────
Hi,
I'm glad to announce ocamlmig, a command line tool for rewriting ocaml
source code with access to scope and type information.
As the simplest example of what it's intended for, let's say an
opam-installed library A provides this interface:
┌────
│ val new_name : int -> int
│
│ val old_name : int -> int
│ [@@migrate { repl = Rel.new_name }]
└────
and your repository contains a file b.ml:
┌────
│ let _ = A.old_name 1
└────
then you could run:
┌────
│ $ git diff b.ml
│ $ ocamlmig migrate -w
│ $ git diff b.ml
│ -let _ = A.old_name 1
│ +let _ = A.new_name 1
└────
Obviously, it's not limited to renames.
When I meant by "complement `[@@deprecated]'" is that instead of
providing a textual description `[@@deprecated "please use this thing
instead" ]' , you get to provide an executable description. The goal
is to reduce the friction when the interface of a library evolves. If
people get in the habit of running this regularly (after every `opam
upgrade~/~dune pkg lock', say), then it could also be a way to get
users to switch to new interfaces without having to deprecate the old
interfaces immediately.
Additionally, using that and a couple of other builtin transformations
like removing ~open~s, you can execute some refactorings, without
learning anything like ppxlib or the ocaml ast, for instance:
• [Renaming operators] (not easy with sed or the like, because the
operators change precedence)
• [Switching code using both Stdlib and Core to mostly Core]
If that piqued your interest, here is more information about [what
ocamlmig does], and [using it].
This is decidedly work in progress, many things are not fully
implemented, and it needs a lot of polish, but the existing
functionality as is should still be interesting.
[Renaming operators]
<https://github.com/v-gb/Gillian/commit/e15ac20a5fac0849dae51523d1b73f1612f976e5>
[Switching code using both Stdlib and Core to mostly Core]
<https://github.com/v-gb/ortografe/commit/b0b6a0c323edb67c03ae938d122e73b4f6a8affc>
[what ocamlmig does]
<https://github.com/v-gb/ocamlmig/blob/main/doc/what.md>
[using it] <https://github.com/v-gb/ocamlmig/blob/main/doc/using.md>
Mopsa 1.1 – Modular Open Platform for Static Analysis
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mopsa-1-1-modular-open-platform-for-static-analysis/16095/1>
Raphaël Monat announced
───────────────────────
Dear all,
On behalf of all its developers, I am glad to announce the release of
[Mopsa v1.1]! You can just `opam install mopsa' .
*What is Mopsa?* Mopsa stands for Modular and Open Platform for Static
Analysis. It aims at easing the development and use of static
analyzers. More specifically, Mopsa is a generic framework for
building sound static analyzer based on the theory of abstract
interpretation. Mopsa is independent of language and abstraction
choices. Developers are free to add arbitrary abstractions (numeric,
pointer, memory, etc.) and syntax iterators for new languages. Mopsa
encourages the development of independent abstractions which can
cooperate or be combined to improve precision.
*v1.1 changes.* This new version brings several expressivity,
precision and interface improvements, notably:
• [Trace and state partitioning]. ⚠️ introduces [breaking changes] in
the API of domains.
• [Suggestions to trigger automatic testcase reduction whenever Mopsa
crashes]
• * As a side-effect, Mopsa is able to generate preprocessed files
from make targets using option `-c-preprocess-and-exit=file.i',
which might be useful for other users too! This has been
experimented on our coreutils benchmarks, and can also be used to
generate the preprocessed files used in the [Software-Verification
Benchmarks].
• Bash completion support, thanks to [arg-complete] developped by
[Simmo Saan].
[Here is the detailed changelog].
[Mopsa v1.1] <https://gitlab.com/mopsa/mopsa-analyzer/>
[Trace and state partitioning]
<https://mopsa.gitlab.io/mopsa-analyzer/user-manual/options/general.html#partitioning>
[breaking changes]
<https://gitlab.com/mopsa/mopsa-analyzer/-/merge_requests/130#breaking-changes>
[Suggestions to trigger automatic testcase reduction whenever Mopsa
crashes]
<https://mopsa.gitlab.io/mopsa-analyzer/user-manual/debugging/automated-testcase-reduction.html>
[Software-Verification Benchmarks]
<https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks#programs>
[arg-complete] <https://opam.ocaml.org/packages/arg-complete/>
[Simmo Saan] <http://sim642.eu/>
[Here is the detailed changelog]
<https://gitlab.com/mopsa/mopsa-analyzer/-/blob/fb3fa9bdf9a225f041c8d03dfa248991f92c674d/CHANGELOG.md>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [MirageOS on OCaml 5!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[MirageOS on OCaml 5!]
<https://tarides.com/blog/2025-02-06-mirageos-on-ocaml-5>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 16543 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-02-04 12:05 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-02-04 12:05 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 12485 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 28 to
February 04, 2025.
Table of Contents
─────────────────
Opam repository archive - clarification of the opam fields
Chúc mừng năm mới Ất Tỵ 2025!
Rewriting Slipshow in OCaml: The undo-able monad
Announcing climate.0.4.0
15th MirageOS retreat May 13th - 20th
Dune dev meeting
Other OCaml News
Old CWN
Opam repository archive - clarification of the opam fields
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-archive-clarification-of-the-opam-fields/16050/1>
Hannes Mehnert announced
────────────────────────
Dear everyone,
we had further discussions about the semantics of
`x-maintenance-intent', and hope to clarify in this post. Also, we
adapted the policy which is in the opam-repository git repository:
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md>
x-maintenance-intent
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We've had some further discussions on Phase 3 and the semantics of the
`x-maintenance-intent' field.
◊ Goal
Our aim is to be not disruptive for the common OCaml programmer or
user. The opam-repository supports (from February 1st on) OCaml 4.08
and greater. This means that if you install OCaml 4.08 you should be
able to install all the packages that have ever been released with
4.08 support.
The revised semantics of "(latest)" is "the latest version of this
package, so that every supported OCaml version will have an
installation candidate".
◊ Example
Let me give you an example, consider the package "basic" which
exists in three versions:
• basic.1.0.0 with the dependency "ocaml" {>= "4.05" & < "5"}
• basic.1.0.1 with the dependency "ocaml" {>= "4.08" & < "5"}
• basic.2.0.0 with the dependency "ocaml" {>= "4.14" & < "5"}
Here, if the `x-maintenance-intent: [ "(latest)" ]' is present, we
will only (try to) archive basic.1.0.0 – since 1.0.1 is needed for
OCaml 4.08 .. 4.13.
◊ Default value
The default value of `x-maintenance-intent' will for now be `"(any)"'
- so all versions are kept. In the future, we may change this default
to `"(latest)"', but will announce this ahead of the change with
plenty of time.
This default value is agreed on by the non-disruptive agreement to
cause the least trouble.
x-maintained
╌╌╌╌╌╌╌╌╌╌╌╌
In addition to the `x-maintenance-intent' - which covers the semantics
of all versions of an opam package, we support another field,
`x-maintained: BOOL'. This is an overwrite for a specific opam package
version, and allows to declare whether it is maintained or not.
It is useful in the setting where you've lots of pre-releases that are
no longer maintained and you like to state this without writing a
global intent for the opam package (e.g. for the OCaml compiler
packages, the alpha, beta, and rc versions). Here, `x-maintained:
false' is a nice setting. NB: earlier we proposed `flags: deprecated'
- but we stay away from the flags, since there may be packages that
are deprecated but still maintained (opam prints a warning if you
install a package with the deprecated flag).
If you have a private project and depend on a specific version of an
opam package, you can as well PR the `x-maintained: true' field for
that opam file (please specify when, who, and why). This will ensure
that this opam file stays in the opam repository.
Phase 3
╌╌╌╌╌╌╌
In Phase 3, we will consider all packages marked with
`x-maintenance-intent' (the versions not matching the intent) and
`x-maintained: false' to be archived.
We plan to ensure that (a) all supported OCaml versions will retain an
installation candidate (b) all reverse dependencies will still be
installable. As a note, if you have an availability condition (some
version will only work on some OS), we won't take that into
consideration – you will need to specify the `x-maintenance-intent' to
cover your versions.
Our plan is to publish the list of packages to be archived by February
15th on this discourse. It is likely we'll have candidate lists PRed
to the [opam-repository-archive] earlier. We have lots of ideas and
plans for CI systems to give feedback which opam versions are falling
into the maintenance intent when you open a PR to the opam-repository
(but we're not there yet).
[opam-repository-archive]
<https://github.com/ocaml/opam-repository-archive>
Future
╌╌╌╌╌╌
As noted above, the default value of `x-maintenance-intent' may change
in time. If this is decided, we will announce this with plenty of time
before.
Also, at some point in the future we will bump the OCaml lower bound
(from February 1st it is 4.08).
Action
╌╌╌╌╌╌
For the smooth shrinking of the opam-repository, please don't hesitate
to fill in your x-maintenance-intent (especially "(none)" and
"(latest)" are fine and safe choices).
If you want to contribute more, the opam-repository needs help for
triaging and merging PRs - why not become a maintainer? See the old
but still valid ['call for new opam-repository maintainers'] if you're
interested.
['call for new opam-repository maintainers']
<https://discuss.ocaml.org/t/call-for-new-opam-repository-maintainers/12041>
Chúc mừng năm mới Ất Tỵ 2025!
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/chuc-m-ng-nam-m-i-t-t-2025/16055/1>
sanette announced
─────────────────
Happy Vietnamese (and Chinese too) New Year!
It's the year of the snake, no its has nothing to do with `python',
but why not play [Snóke] ;)
Happy OCaml snaky year to all
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/7/724ead058962d131571f612fa8939f1847758c7e_2_1146x1000.png>
[Snóke] <https://github.com/sanette/snoke>
Rewriting Slipshow in OCaml: The undo-able monad
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-rewriting-slipshow-in-ocaml-the-undo-able-monad/16069/1>
Paul-Elliot announced
─────────────────────
Hello OCamlers,
I have recently rewritten [Slipshow]'s engine from JavaScript to
OCaml. It turns out this rewriting was very satisfying, and many
niceties came out of it. I have written a blog post about a
specifically interesting one: the use of custom `let' operators with
the "undo-able" monad. I hope you enjoy the read!
The blog post: [How I fixed Slipshow's worst flaw using OCaml and a
monad].
[Slipshow] <https://github.com/panglesd/slipshow/>
[How I fixed Slipshow's worst flaw using OCaml and a monad]
<https://choum.net/panglesd/undo-monad/>
Announcing climate.0.4.0
════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-climate-0-4-0/16084/1>
Steve Sherratt announced
────────────────────────
[Climate] is a declarative command-line parser for OCaml. This release
is mostly focused on improving `--help' messages and allowing the
colours of help messages to be configured.
[Climate] <https://github.com/gridbugs/climate>
Added
╌╌╌╌╌
• Allow help messages colours to be configured ([#7])
• Proof of concept of manpage generation (disabled in release as it's
very incomplete) ([#11])
[#7] <https://github.com/gridbugs/climate/pull/7>
[#11] <https://github.com/gridbugs/climate/pull/11>
Changed
╌╌╌╌╌╌╌
• Changed default help message colour scheme to be more colour-blind
readable
and more visible on light and dark terminals ([#7])
• Changed description of `--help' argument.
[#7] <https://github.com/gridbugs/climate/pull/7>
Fixes
╌╌╌╌╌
• Remove superfluous style reset escape sequences ([#7])
• Don't apply formatting to trailing spaces in argument names in help
messages ([#8])
• Print a readable error when the argument spec is invalid ([#10])
[#7] <https://github.com/gridbugs/climate/pull/7>
[#8] <https://github.com/gridbugs/climate/pull/8>
[#10] <https://github.com/gridbugs/climate/pull/10>
15th MirageOS retreat May 13th - 20th
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-15th-mirageos-retreat-may-13th-20th/16085/1>
Hannes Mehnert announced
────────────────────────
Dear everybody,
we'll have another MirageOS retreat in May 2025 (13th - 20th). Happy
to see lots of old and new faces there.
Please jump to <https://retreat.mirageos.org> for further details, and
sign up and spread the word :)
Don't hesitate to ask questions in this topic.
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/22>
Etienne Marais announced
────────────────────────
Hi Dune enthusiasts :smile:,
We will hold the regular Dune Dev Meeting on **Wednesday, February,
5th at 9:00** CET. As usual, the session will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers!
:ok_hand:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-02-05>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
• Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [How we accidentally built a better build system for OCaml]
• [Tarides: 2024 in Review]
[the ocaml.org blog] <https://ocaml.org/blog/>
[How we accidentally built a better build system for OCaml]
<https://blog.janestreet.com/how-we-accidentally-built-a-better-build-system-for-ocaml-index/>
[Tarides: 2024 in Review]
<https://tarides.com/blog/2025-01-20-tarides-2024-in-review>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 24660 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-01-28 13:24 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-01-28 13:24 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 33038 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 21 to 28,
2025.
Table of Contents
─────────────────
Google Summer of Code
Merlin and OCaml-LSP support experimental project-wide renaming
qcheck-lin and qcheck-stm 0.2
Dune 3.17
Odoc 3 Beta Release
2024 at OCamlPro
Old CWN
Google Summer of Code
═════════════════════
Archive: <https://discuss.ocaml.org/t/google-summer-of-code/3196/12>
Anton Kochkov announced
───────────────────────
Hi everyone! If you plan to apply this year for the Google Summer of
Code, it starts on January 27 and ends on Februrary 11:
<https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html>
Merlin and OCaml-LSP support experimental project-wide renaming
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-merlin-and-ocaml-lsp-support-experimental-project-wide-renaming/16008/1>
vds announced
─────────────
I am delighted to announce that the latest releases of Merlin
(`5.4.1-503') and OCaml-LSP (`1.22.0') for OCaml 5.3 provide
experimental support for _project-wide_ renaming of symbols.
Users of [vscode-ocaml-platform], [ocaml-eglot] or any generic LSP
client can experiment with the new feature right now via the standard
`Rename' feature of their favorite editors. (This is not enabled in
the standard Emacs and Vim modes yet.)
All project-wide features require [the indexer] to be installed and an
up-to date index built with `dune build @ocaml-index --watch' (we only
ship rules for Dune, but the indexer itself is agnostic).
This is a complex feature in an experimental state, please report any
issue you might encounter to [Merlin's issue tracker].
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/a/a1bf8be427da9f11d2e65717eb0100778eec9ac3.gif>
*Complete changelog*
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform/>
[ocaml-eglot]
<https://discuss.ocaml.org/t/ann-release-of-ocaml-eglot-1-0-0/15978>
[the indexer] <https://ocaml.org/p/ocaml-index/latest>
[Merlin's issue tracker] <https://github.com/ocaml/merlin/issues>
merlin 5.4.1
╌╌╌╌╌╌╌╌╌╌╌╌
⁃ merlin binary
• Support for OCaml 5.3
• Use new 5.3 features to improve locate behavior in some
cases. Merlin no longer confuses uids from interfaces and
implementations. (#1857)
• Perform less merges in the indexer (#1881)
• Add initial support for project-wide renaming: occurrences can now
return all usages of all related definitions. (#1877)
⁃ ocaml-index
• Bump magic number after index file format change (#1886)
⁃ vim plugin
• Added support for search-by-type (#1846) This is exposed through
the existing `:MerlinSearch' command, that switches between
search-by-type and polarity search depending on the first
character of the query.
Ocaml-LSP 1.22.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Enable experimental project-wide renaming of identifiers (#1431)
qcheck-lin and qcheck-stm 0.2
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm-0-2/12301/5>
Jan Midtgaard announced
───────────────────────
Version 0.7 of `qcheck-lin', `qcheck-stm', and
`qcheck-multicoretests-util' is now available on the opam repository:
<https://github.com/ocaml-multicore/multicoretests/releases/tag/0.7>
This release contains two contributions from @polytypic, incl. an
`STM' feature to help testing of ~cmd~s that may raise an effect:
• [#509]: Change/Fix to use a symmetric barrier to synchronize domains
• [#511]: Introduce extended specs to allow wrapping command sequences
• [#517]: Add `Lin' combinators `seq_small', `array_small', and
`list_small'
Happy testing! :smiley:
[#509] <https://github.com/ocaml-multicore/multicoretests/pull/509>
[#511] <https://github.com/ocaml-multicore/multicoretests/pull/511>
[#517] <https://github.com/ocaml-multicore/multicoretests/pull/517>
Dune 3.17
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-17/15770/5>
Etienne Marais announced
────────────────────────
The Dune team is releasing Dune `3.17.2'! :wrench:
This patch release includes some bug fixes. It mostly brings some
fixes for Melange and Wasm_of_ocaml. It also fixes a bug that prevents
the experimental feature, package management, to build with
`ocaml.5.3.0'.
If you encounter a problem with this release, you can report it on the
[ocaml/dune] repository.
[ocaml/dune] <https://github.com/ocaml/dune/issues>
Changelog
╌╌╌╌╌╌╌╌╌
◊ Fixed
• Fix a crash in the Melange rules that would prevent compiling public
library implementations of virtual libraries. (@amonteiro, #11248)
• Pass `melange.emit''s `compile_flags' to the JS emission
phase. (@amonteiro, #11252)
• Disallow private implementations of public virtual libs in `melange'
mode. (@amonteiro, #11253)
• Wasm_of_ocaml: fix the execution of tests in a sandbox. (#11304,
@vouillon)
Odoc 3 Beta Release
═══════════════════
Archive: <https://discuss.ocaml.org/t/ann-odoc-3-beta-release/16043/1>
Jon Ludlam announced
────────────────────
On behalf of the odoc team, I'm thrilled the announce the release of
odoc 3.0.0 beta 1!
This release has been cooking for a long time - it's been more than a
year since odoc 2.4 landed, and a huge amount of work has gone into
this. Thanks to the many others who contributed, either by code or by
comments: @juloo, @panglesd, @EmileTrotignon, @gpetiot, @trefis,
@sabine, @dbuenzli, @yawaramin, and more.
With this release we're including a driver that knows how to use all
of the exciting new features of odoc. This driver has been used to
create the [docs site for the various odoc tools].
Here are a selected set of features:
• :droplet: Rendered source! Jump from any item in the documentation
straight to its rendered source; no matter how much of OCaml's
complex module system you are using.
• :mag: Search by type! Our detective sherlodoc will find your lost
value given its type.
• :warning: Convenient warnings! Warnings are now clearly visible and
useful, no longer buried among your dependencies’ warnings.
• :arrow_heading_up: Self host your documentation, but [link to
ocaml.org] for your dependencies.
• :100: More sidebars! Odoc 3 features a [global sidebar], allowing
you to discover the most hidden corner of underground documentation.
• :exploding_head: Image support! This cutting-edge feature now allows
you to [add images] to your documentation. Video and audio come for
free.
• :spider_web: [Fully cross-package links]! The OCaml docs are now a
true spider web. Prepare to catch bugs, and eat them.
• :cop: Hierarchical documentation pages! We use a modular
language. We don't want a flat namespace for pages.
• :building_construction: The build dependencies are friendlier with
incremental build systems, allowing better shared build caches.
• :heart: Quality of life improvements! Many improvements have been
piling up since we started odoc 3. For instance: `Add clock emoji
before @since tag (@yawaramin, #1089)'!
More explanation of these features is available at the odoc site,
where we have documentation [for authors], for [users of
`odoc_driver'], a [cheatsheet], and [differences from ocamldoc].
[docs site for the various odoc tools] <https://ocaml.github.io/odoc/>
[link to ocaml.org]
<https://ocaml.github.io/odoc/odoc-driver/#remapping-dependencies>
[global sidebar]
<https://ocaml.github.io/odoc/odoc/odoc_for_authors.html#page-tags>
[add images]
<https://ocaml.github.io/odoc/odoc/odoc_for_authors.html#media>
[Fully cross-package links]
<https://ocaml.github.io/odoc/odoc/odoc_for_authors.html#links_and_references>
[for authors] <https://ocaml.github.io/odoc/odoc/odoc_for_authors.html>
[users of `odoc_driver']
<https://ocaml.github.io/odoc/odoc-driver/index.html>
[cheatsheet] <https://ocaml.github.io/odoc/odoc/cheatsheet.html>
[differences from ocamldoc]
<https://ocaml.github.io/odoc/odoc/ocamldoc_differences.html>
How can you help?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We need your feedback, both as authors and as users of documentation!
Try things out using the new driver:
┌────
│ $ opam install odoc-driver # don't forget to ~opam update~
│ $ odoc_driver <package list> # For instance: ~$ odoc_driver brr odoc~
│ $ $YOUR_BROWSER _html/index.html
└────
Many of those features' implementations are not set in stone, but
first versions. Please leave comments, either in this thread or as
issues in the repository.
So, navigate already written documentation, and update your own docs
to use the new features!
2024 at OCamlPro
════════════════
Archive: <https://discuss.ocaml.org/t/2024-at-ocamlpro/16046/1>
OCamlPro announced
──────────────────
*2024 at OCamlPro*
At OCamlPro, we like to solve issues that have an impact in the real
world, so we focus most of our efforts on projects that our customers
bring from their domains. We often like to work in the shadows,
focusing on the hardest tasks. Fabrice, OCamlPro’s founder, used to
say that we are the Commandos of OCaml (and now of Rust too), a team
of highly skilled professionals jumping into the most demanding
projects. That ability was illustrated several times in the past, from
the birth of Opam, the development of the Flambda compilers for Jane
Street, the design and development of the Tezos prototype and ICO
platform, to the adventurous extension of the GnuCOBOL open-source
compiler for French DGFiP, even the port of Flow and Hack to Windows
for Meta. Of course, we are always happy to be entrusted with more
common projects and tasks also, building a team and training the
talents required to master all tasks, from the simplest to the hardest
ones. And the hardest ones are often hidden in the middle of the
simplest ones, too.
The OCaml language is the greatest tool at hand to fulfil our
missions, and we try to contribute back to the OCaml ecosystem when
possible. We are always attracted to issues met by OCaml industrial
users, as it gives us the opportunity to directly work for the OCaml
community. Would you be having such issues, do not hesitate to contact
us and discuss what we can do for you!
The beginning of a new year is always a good time to look back at the
previous year, and see what we have achieved with OCaml, and sometimes
for OCaml, in 2024.
Contributions to the OCaml ecosystem
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Sharing Knowledge
In 2024, we made efforts to dedicate more time to write blog posts to
share our knowledge on the OCaml tools we work on, so that OCaml
developers can use this knowledge in their daily tasks. We wrote a
series of articles on mastering Opam from the ground up ( [Opam 101:
The First Steps], [Opam 102: Pinning Packages]), on the internals of
the Flambda2 compiler ( [Behind the Scenes of the OCaml Optimising
Compiler Flambda2: Introduction and Roadmap], [Flambda2 Ep. 2:
Loopifying Tail-Recursive Functions], [Flambda2 Ep. 3: Speculative
Inlining] ) and one on OCaml backtraces ( [OCaml Backtraces on
Uncaught Exceptions] ). More are coming!
Of course, if you are not patient enough to wait for our next
articles, you may register for one of [our trainings] , we have [OCaml
Beginner] , [OCaml Expert] , [Mastering Opam] , [OCaml Code
Optimization] and we can build new ones on demand. To be honest, in
2024, we received many more requests for our sessions on Rust
(Beginner, Expert and Embedded) than for OCaml, but more for OCaml
ones than for COBOL ones 🙂
[Opam 101: The First Steps]
<https://ocamlpro.com/fr/blog/2024_01_23_opam_101_the_first_steps>
[Opam 102: Pinning Packages]
<https://ocamlpro.com/fr/blog/2024_03_25_opam_102_pinning_packages>
[Behind the Scenes of the OCaml Optimising Compiler Flambda2:
Introduction and Roadmap]
<https://ocamlpro.com/fr/blog/2024_03_18_the_flambda2_snippets_0>
[Flambda2 Ep. 2: Loopifying Tail-Recursive Functions]
<https://ocamlpro.com/fr/blog/2024_05_07_the_flambda2_snippets_2>
[Flambda2 Ep. 3: Speculative Inlining]
<https://ocamlpro.com/fr/blog/2024_08_09_the_flambda2_snippets_3>
[OCaml Backtraces on Uncaught Exceptions]
<https://ocamlpro.com/fr/blog/2024_04_25_ocaml_backtraces_on_uncaught_exceptions>
[our trainings] <https://training.ocamlpro.com>
[OCaml Beginner]
<https://training.ocamlpro.com/en/formation-ocaml-debutant-2022.html>
[OCaml Expert]
<https://training.ocamlpro.com/en/formation-ocaml-expert-2022.html>
[Mastering Opam]
<https://training.ocamlpro.com/en/formation-mastering-opam-2022.html>
[OCaml Code Optimization]
<https://training.ocamlpro.com/en/formation-ocaml-optimisation-2022.html>
◊ Opam, Maintenance and Evolution
Since we created Opam in 2012, we have always had at least one full
time engineer in the Opam team, to maintain it, add new features and
review contributions by other members. This was made possible thanks
to a partnership with Jane Street, and, since 2024, to a partnership
with Tarides.
In 2024, opam had two major releases, [opam 2.3.0 release!] and [opam
2.2.0 release!] . The most ground-breaking change is the *official
native support for Windows*, with access to either mingw-w64 gcc
compilers or Visual Studio MSVC compilers with automatic
detection. This native support is tremendous news for OCaml adoption
in general, and it was built thanks to a lot of work from all the
community, especially on the opam-repository and packages. An
interesting next step to consider for OCaml on Windows would be to
have a single OCaml toolchain for all Windows compilers, using an
integrated assembler for x86/x64 with elf/coff support, something that
we had implemented and tested in OcpWin a long time ago.
Among many fixes and updates, there is the addition of opam tree
<package> to get a nice display of the dependencies of an installed
package, `opam pin –recursive' to look deeper into sub-directories
when searching for opam files and many more small improvements. Check
the blog posts for more details !
[opam 2.3.0 release!]
<https://ocamlpro.com/fr/blog/2024_11_13_opam_2_3_0_releases>
[opam 2.2.0 release!]
<https://ocamlpro.com/fr/blog/2024_07_01_opam_2_2_0_releases>
◊ Work on the OCaml Compiler
We have had a long partnership with Jane Street to improve the
performance of the code generated by the OCaml compiler. The first
outcome of this work was the Flambda backend, which was merged into
OCaml 4.03 in 2016. Since then, we have started a new backend,
[Flambda2] , that is included in the Jane Street OCaml compiler.
In 2024, our team focused its efforts on several new optimizations,
like match in match (simplify pattern-matching appearing in another
pattern-matching after inlining), unbox free vars of closures
(shortcut chains of pointers stored in closures) or the reaper (do not
allocate unused fields of blocks). Such optimizations are often much
more complex than you would think, as guaranteeing that they can be
applied safely is not obvious, requiring escape analysis and other
checks. We were also very active at helping the compiler team at Jane
Street by reviewing their code and adapting our backend to their
needs. If you are interested in this subject, read our blog series on
the topic that was mentioned earlier.
In 2024, we also had an intern working on *modular explicits*, an
extension of OCaml first-class modules with module-dependent
functions, functions taking first-class modules as arguments. This
work can be seen as a first step towards modular implicits, and was
presented [at the OCaml workshop] with Didier Rémy. The [main
pull-request] is still under review, while other smaller ones have
already been merged, leading to interesting extensions inside the
compiler such as new forms of dependent types.
[Flambda2] <https://github.com/ocaml-flambda/flambda-backend>
[at the OCaml workshop]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/1/On-the-design-and-implementation-of-Modular-Explicits>
[main pull-request] <https://github.com/ocaml/ocaml/pull/13275>
◊ Optimizing Geneweb, a Webserver for Genealogy
Last year, we also started working on [Geneweb], a webserver in OCaml
that is used to store family trees by genealogists. Geneweb is a very
old piece of OCaml, initially written around 1996 by Daniel De
Rauglaudre at Inria. It is used both by [Geneanet] , a genealogy
company recently acquired by Ancestry, and the [Roglo association], a
French association that administrates a single family tree of more
than 10 million persons. One of the issues faced by the Roglo
association was that their branch of the software had diverged from
the official one maintained by Geneanet, as Roglo had to use specific
features on their branch to cope with the huge size of their unique
family tree. We helped them by optimizing the official branch, so that
it could host the tree while providing the same latencies for requests
as before. It required optimizing the representation of stored data
(both in OCaml and on disk), how it was accessed through system calls,
and a good understanding of the complex algorithms used by Geneweb,
typically to traverse family members using various relationships.
[Geneweb] <https://github.com/geneweb/geneweb>
[Geneanet] <https://en.geneanet.org/legal/geneanet/>
[Roglo association] <https://asso.roglo.eu/page/350795-accueil>
Contributions to other languages
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Compiling to Wasm and Wasm Symbolic Execution
Since 2021, OCamlPro has actively contributed to the W3C's efforts on
bringing a dedicated Garbage Collector to WebAssembly - an essential
feature that has now become reality with the increased use of Wasm
(See [How Prime Video updates its app for more than 8,000 device
types] or [Introducing the Disney+ Application Development Kit (ADK)]
).
Our work ensured the official [WasmGC proposal] remained fully
compatible with the needs of OCaml. Crucial to this success was
[Wasocaml], our Flambda-based backend targeting WebAssembly, which
helped drive the proposal's release and subsequent implementation in
2023 across all major browsers.
One of our biggest contributors to this work, Léo Andrès [defended his
PhD at the end of 2024]. The topic was about compiling OCaml to Wasm
but also about another [tool named Owi], developed in close
collaboration with the University of Lisboa. Originally developed as a
"Wasm Swissknife", Owi has evolved into a multi-core, multi-solver,
cross-language symbolic engine. Its capabilities include:
• automated, sound, and partially-correct bug-finding (amounting to a
proof);
• solver-aided programming (think of Rosette for Rocket, but for any
language);
• efficient test-case generation.
Looking ahead, we are excited to combine Wasocaml and Owi, aiming to
*perform symbolic execution of OCaml* programs, and even those with
substantial C components! We've already applied these techniques
successfully to Rust, uncovering a subtle bug in the [Rust standard
library]. If you want to know more about it, have a look at our
[journal article].
Some of this work was funded by NGI/NLnet.
[How Prime Video updates its app for more than 8,000 device types]
<https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types>
[Introducing the Disney+ Application Development Kit (ADK)]
<https://medium.com/disney-streaming/introducing-the-disney-application-development-kit-adk-ad85ca139073>
[WasmGC proposal] <https://github.com/WebAssembly/gc>
[Wasocaml] <https://github.com/OCamlPro/wasocaml>
[defended his PhD at the end of 2024] <https://theses.fr/s340615>
[tool named Owi] <https://github.com/OCamlPro/owi>
[Rust standard library]
<https://github.com/rust-lang/rust/pull/129321>
[journal article] <https://arxiv.org/pdf/2412.06391>
◊ From Niagara to Kopek, a foot in the Cinema industry
2024 was also a new adventure in entrepreneurship for OCamlPro. In
2023, we [won a grant] from the CNC, the French Center for the Cinema
industry, to work with Antoine Devulder and Denis Mérigoux on the
design of a *DSL for movie producers*. Indeed, distributing earnings
is one of the most complex tasks that a producer must do after a movie
is released, mostly because of the complexity of contracts. So we
designed a DSL, initially called Niagara, that is close enough to
contracts to be simple to write, and automatically computes the exact
distribution of earnings during the entire life of the movie.
In 2024, we decided to create the [Kopek company] with Antoine and
Denis, to commercialize this product. The DSL itself is hidden behind
a no-code interface that makes all interactions with the software easy
and intuitive for producers, and the tool can deal with complex
contracts that no other software on the market can deal with. For
French speakers, the tool was recently [presented at a CNC event] .
[won a grant]
<https://www.cnc.fr/professionnels/actualites/resultats-de-lappel-a-projets---transparence-de-la-remontee-de-recettes-dans-le-secteur-cinema-et-audiovisuel_1931182>
[Kopek company] <https://kopek.fr>
[presented at a CNC event]
<https://www.youtube.com/watch?v=6Q3Y7SNTDmg>
◊ SuperBOL, a powerful LSP for COBOL and Visual Studio Code
For a few years now, OCamlPro has been [involved in the COBOL
ecosystem], mostly to help the French tax administration to deal with
the migration of COBOL code from legacy systems (GCOS mainframes from
the 80s) to Cloud-based platforms. Most of our work was to extend the
[free open-source GnuCOBOL compiler] for the needs of the
application. Moreover, we spent some time creating an *OCaml framework
for COBOL* to better understand this programming language. We released
a large part of this work as an open-source extension for Visual
Studio Code called [SuperBOL Studio OSS]. Backed by our powerful LSP
server, this extension empowers its users with all the features that
developers expect from a modern editor for editing and navigating
COBOL code.
In 2024, we improved the parser to support a larger part of the COBOL
language, we added a powerful indentor of code, powerful code
completion features derived directly from the COBOL grammar (using the
recently added features in Menhir), as well as various ways to display
the control-flow graph of programs ; the latter being particularly
useful when your job is to navigate and modify code written many
decades ago. We built an entire CI/CD system for SuperBOL that
automatically releases cross-compiled, statically linked binaries for
Linux, Windows and MacOS.
[involved in the COBOL ecosystem] <https://superbol.eu>
[free open-source GnuCOBOL compiler]
<https://gnucobol.sourceforge.io/>
[SuperBOL Studio OSS]
<https://github.com/OCamlPro/superbol-studio-oss>
◊ Mlang used at the DGFiP
We have also been involved for some time now in the adaptation of the
[Mlang compiler] to replace the deprecated tooling of the DGFiP
(French Public Finances Directorate) to compute the French Income Tax.
2024 was an important milestone for the project, as Mlang was used for
the *first time in production*. It means that we were able to compute
the exact same results, with comparable performance. Moreover, as the
former compiler used to suffer from overflows that require manual
inspections and re-evaluations, the new compiler already provides
benefits for DGFiP. We are now involved in improving Mlang to handle
multi-year computations, something that used to be performed using
hardly maintainable boilerplate in C, and in improving the general
environment around the compiler, with CI/CD and code-navigation tools.
[Mlang compiler] <https://github.com/MLanguage/mlang>
Formal methods
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ The Alt-Ergo SMT Solver
OCamlPro has been developing the [Alt-Ergo SMT solver] since
2011. Alt-Ergo is usually used behind code verification frameworks
such as [Why3] , [Frama-C] , [TIS Analyzer] or [Adacore Spark] , we
maintain a close relationship with its industrial users through the
[Alt-Ergo Users’ Club] who have access to the most recent features
ahead of time. Current members are [Adacore] , [Trust in Soft] ,
[Thales] , [MERCE] and [CEA List] .
In 2024, we released a brand new version, [Alt-Ergo 2.6] . The
highlights are a better support for bit-vectors, model generation for
algebraic data types, optimization of (maximize) and (minimize), FPA
support, and many other features and bug fixes. Part of this work was
also funded by the [Decysif collaborative project] where we try to
improve Alt-Ergo for use with the [Creusot Rust Verifier] .
[Alt-Ergo SMT solver] <https://alt-ergo.ocamlpro.com/>
[Why3] <https://www.why3.org/>
[Frama-C] <https://frama-c.com/>
[TIS Analyzer] <https://www.trust-in-soft.com/trustinsoft-analyzer>
[Adacore Spark] <https://www.adacore.com/about-spark>
[Alt-Ergo Users’ Club] <https://alt-ergo.ocamlpro.com/#club>
[Adacore] <https://www.adacore.com/>
[Trust in Soft] <https://www.trust-in-soft.com/>
[Thales]
<https://www.thalesgroup.com/fr/global/innovation/recherche-technologie>
[MERCE] <https://www.mitsubishielectric-rce.eu/>
[CEA List] <https://list.cea.fr/fr/>
[Alt-Ergo 2.6]
<https://ocamlpro.com/blog/2024_09_01_alt_ergo_2_6_0_released/>
[Decysif collaborative project] <https://decysif.fr/fr/>
[Creusot Rust Verifier] <https://github.com/creusot-rs/creusot>
◊ EAL6+ Certification
In 2024, we have again been involved in a high level software
certification process ([Common Criteria EAL6+] ) where we successfully
proved our capacity to formalize security policies on low level code
for very important customers, using the Coq proof assistant.
[Common Criteria EAL6+] <https://commoncriteriaportal.org/index.cfm>
◊ Taming Test Generators for C with SeaCoral
Writing unit tests is a very good practice, particularly when using a
weakly-typed language like C. Yet, it is also a cumbersome task,
especially when the goal is to reach 100% coverage of the
code. Fortunately, part of this task can be automated by test
generation tools, based on fuzzing, symbolic execution, and other code
analysis techniques. Each of these techniques has its own strengths
and weaknesses (in terms of performance, number of generated tests, or
targeted coverage criteria), so much so that it often becomes
necessary to combine them in order to achieve good results on
realistic source code. Moreover, these tools are often hard to
understand and configure properly for a project.
In 2024, following previous experimentations (see [“An Efficient
Black-Box Support of Advanced Coverage Criteria for Klee”] ), we
started working on Seacoral, a tool that *automates the generation of
unit tests for C*. Seacoral relies on a unified definition of coverage
criteria that is based on the notion of coverage labels, and is able
to leverage the abilities of many existing test generation techniques
by carefully orchestrating the tools to achieve high coverage with as
few tests as possible. Seacoral leverages FramaC/LTest
<https://www.frama-c.com/fc-plugins/ltest.html> to automatically
annotate the code with coverage labels. It currently supports
[libfuzzer] , [Klee], and [CBMC] . Seacoral can also detect
unreachable code using [LUncov], and reports potential runtime errors.
[“An Efficient Black-Box Support of Advanced Coverage Criteria for
Klee”] <https://dl.acm.org/doi/abs/10.1145/3555776.3577713>
[libfuzzer] <https://llvm.org/docs/LibFuzzer.html>
[Klee] <https://klee-se.org/>
[CBMC] <https://www.cprover.org/cbmc/>
[LUncov] <https://git.frama-c.com/pub/ltest/luncov>
A long time ago
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you have never heard of OCamlPro, here are a few examples of
projects that we contributed to the OCaml ecosystem, since the
creation of OCamlPro in 2011.
• `opam' (*): probably the most powerful package manager in terms of
constraints optimization, thanks to the work on CUDF by Roberto Di
Cosmo's team. Now the official package manager of OCaml.
• `flambda1' and `flambda2' (*): a backend for the native compiler
with multiple additionnal optimization passes. Flambda1 was merged
into the official OCaml compiler, while Flambda2 is integrated in
the Jane Street OCaml compiler.
• `ocp-indent' (*): a tool to automatically indent OCaml code in
editors, with modes for Emacs, Vi, Vscode, etc. with per-project
configuration. A must-use for collaborative edition instead of
ocamlformat.
• `ocp-index' (*): a tool to lookup types and definitions in an OCaml
project, with modes for Emacs, Vi, etc. based on cmt files.
• `ocp-memprof': the most powerful memory profiler for OCaml to ever
exist. With almost no impact on runtime performance, it was able to
dump compressed memory dumps of the OCaml heap with full type
information.
• `ocp-build' : the first composable build tool for OCaml before dune,
it was able to build any OCaml project with full parallelism. It
supported additional languages to build cross-language projects.
• `ocp-win' : a full OCaml distribution for Windows, coming with a
simple graphical installer. Its compiler could be configured to
target any Windows C toolchain, such as MinGW, MSVC or Cygwin, and
environment, such as Msys, Cygwin and Windows shells, thanks to the
use of an integrated x86/64 and elf/coff assembler in OCaml.
(*) thanks to funding by Jane Street
Your Project, our Expertise
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you're looking to leverage the power and flexibility of OCaml for
your projects, we’d love to collaborate with you. At OCamlPro, we
bring years of expertise, innovation, and a deep commitment to
enhancing the OCaml ecosystem. Whether you need support with custom
development, performance optimization, tooling, or anything in
between, we are here to help.
Let's build something great together—reach out to us today to discuss
your project!
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 44528 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-01-21 15:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-01-21 15:47 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 78581 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 14 to 21,
2025.
Table of Contents
─────────────────
OCaml Software Foundation: January 2025 update
ppxlib.034.0
Release of Carton 1.0.0 and Cachet
Opam repository archival, phase 2 - OCaml 4.08 is the lower bound
Ocaml-posix 2.1.0 released!
Release of ocaml-eglot 1.0.0
Semgrep is hiring to help scale their static analysis engine
Dune dev meeting
Tarides: 2024 in Review
Other OCaml News
Old CWN
OCaml Software Foundation: January 2025 update
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-software-foundation-january-2025-update/15951/1>
gasche announced
────────────────
Happy new year!
This is an update on recent works of the [OCaml Software Foundation],
covering our 2024 actions – the previous update was in [January 2024].
The OCaml Software Foundation is a non-profit foundation ([earlier
thread]) that receives funding from [our industrial sponsors] each
year, and tries its best to spend it to support and strengthen the
OCaml ecosystem and community.
The funding volume we receive each year is around 200K€. (For
comparison: this is the yearly cost of one experienced full-time
software engineer in many parts of the world.) We do not fund people
full-time for long periods. Most actions receive from 3K€ to 20K€.
The work to prepare and execute actions is mostly done by the (unpaid)
[Executive Committee]. It is currently formed by Nicolás Ojeda Bär,
Damien Doligez, Xavier Leroy, Kim Nguyễn, Virgile Prevosto and myself,
with administrative personnel provided by [INRIA] and general
assistance by Alan Schmitt.
Our current sponsors (thanks!) are [ahrefs], [Jane Street], [Tezos],
[Bloomberg], [Lexifi], [SimCorp], [MERCE] and [Tarides]. (If your
company would like to join as a sponsor, please [get in
touch]. Unfortunately, we still cannot efficiently process small
donations, so we are not calling for individual donations.)
Feel free to use this thread for questions/suggestions :-)
[OCaml Software Foundation] <http://ocaml-sf.org/>
[January 2024]
<https://discuss.ocaml.org/t/ocaml-software-foundation-january-2024-update/13828>
[earlier thread]
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476>
[our industrial sponsors] <http://ocaml-sf.org/#sponsors>
[Executive Committee] <http://ocaml-sf.org/about-us/>
[INRIA]
<https://en.wikipedia.org/wiki/French_Institute_for_Research_in_Computer_Science_and_Automation>
[ahrefs] <https://ahrefs.com/>
[Jane Street] <https://janestreet.com/>
[Tezos] <https://tezos.com/>
[Bloomberg] <https://bloomberg.com/>
[Lexifi] <https://lexifi.com/>
[SimCorp] <https://simcorp.com/>
[MERCE] <https://www.mitsubishielectric-rce.eu/>
[Tarides] <https://tarides.com/>
[get in touch] <http://ocaml-sf.org/becoming-a-sponsor/>
Recent actions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Education and outreach
We funded a new edition of the Spanish [summer school] on functional
programming in OCaml, organized in Saragossa by Ricardo Rodriguez and
Roberto Blanco.
We continued funding the OCaml meetups in Paris and Toulouse,
France. In 2024, a [new meetup] started in Chennai, India (first
[discuss thread]), which we are delighted to support as well.
We are sponsoring the [JFLA 2025], a functional programming conference
in France, and an [OCaml Bridge Workshop] at Functional Conf 2025, a
large Asian conference on functional programming.
[summer school] <https://webdiis.unizar.es/evpf/index.html>
[new meetup] <https://www.meetup.com/chennai-ocaml-meetup/>
[discuss thread]
<https://discuss.ocaml.org/t/chennai-ocaml-meetup-june-2024/14695>
[JFLA 2025] <https://jfla.inria.fr/jfla2025.html>
[OCaml Bridge Workshop]
<https://confengine.com/conferences/functional-conf-2025/proposal/21057/ocaml-bridge-workshop>
◊ Research
The OCaml Software Foundation is typically not involved in funding
research, focusing on actions that have an immediate impact on the
language and its community. Nevertheless, in 2023 we funded one year
of post-doctoral work for Takafumi Saikawa in relation to his
maintenance work on the type-checker of OCaml. In 2024 we funded one
year of research engineer for the [Salto] project, building a static
analyzer for OCaml, and one year of PhD grant for [Alistair O'Brien]
in Cambridge (complementing other funding sources for a full PhD),
continuing his [impressive work] on constraint-based type inference
for OCaml.
[Salto] <https://salto.gitlabpages.inria.fr/>
[Alistair O'Brien] <https://github.com/johnyob>
[impressive work] <https://github.com/johnyob/dromedary/>
◊ Ecosystem
◊ Infrastructure
As in previous years, we fund the work of Kate Deplaix to check that
the OCaml ecosystem is compatible with upcoming compiler releases;
in 2024 Kate worked on OCaml 5.2 and 5.3.
We are trying our best to support the work of opam-repository
maintainers, through individual funding grants for the active
maintainers. This year, on the suggestion of the repository
maintainers, we are also funding the work of [Robur] to migrate
unmaintained packages to a separate archive ([discuss thread 1],
[thread 2]).
[Robur] <https://robur.coop/>
[discuss thread 1]
<https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository/15713>
[thread 2]
<https://discuss.ocaml.org/t/opam-repository-archival-phase-1-unavailable-packages/15797/2>
◊ Tools
In 2024 we have funded one month of maintenance of the `opam' client
by Raja Boujbel and her colleagues.
We renewed our partial support for the work of Antonio Monteiro on
[Melange]. For more Melange news, see for example the announcement
of [Melange 4].
[Melange] <https://melange.re/v4.0.0/>
[Melange 4] <https://melange.re/blog/posts/melange-4-is-here>
◊ Libraries
We keep supporting the work of Petter Urkedal on the [Caqti]
library, the main database connection library in the OCaml
community.
The [Owl] library for scientific computing has been [restructuring]
in 2024, with its two maintainers moving to permanent jobs demanding
their time and therefore less available. The OCaml Software
Foundation is providing a small grant to help the maintainers
transition to a different contribution model and/or preserve a part
of their maintenance activity, as they think is best.
We have been funding documentation work by John Whitington to
collect or create usage examples of important OCaml libraries, prior
to their upstreaming in the documentation of each project. See his
[ocaml-nursery] repository.
We support the contributions of Daniel Bünzli to the OCaml
ecosystem. This year, Daniel used this support to fund the
development of
• [jsont], a new library for declarative JSON data manipulation
• [bytesrw], a library of composable byte stream readers and writes,
with support for various compression and hashing algorithms
• [support] for Unicode 16.0 in his Unicode libraries
Finally, we have been funding Nathan Rebours to take an active part
in the maintenance of the ppxlib project, see his [ppxlib
maintenance summary].
[Caqti] <https://github.com/paurkedal/ocaml-caqti/>
[Owl] <https://github.com/owlbarn/owl>
[restructuring]
<https://discuss.ocaml.org/t/owl-project-restructured/14226>
[ocaml-nursery] <https://github.com/johnwhitington/ocaml-nursery>
[jsont]
<https://discuss.ocaml.org/t/ann-jsont-0-1-0-declarative-json-data-manipulation-for-ocaml/15702>
[bytesrw]
<https://discuss.ocaml.org/t/ann-bytesrw-0-1-0-composable-byte-stream-readers-and-writers/15696>
[support]
<https://discuss.ocaml.org/t/ann-unicode-16-0-0-update-for-uucd-uucp-uunf-and-uuseg/15270>
[ppxlib maintenance summary]
<https://discuss.ocaml.org/t/ppxlib-maintenance-summary/14458>
ppxlib.034.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-ppxlib-034-0/15952/1>
Nathan Rebours announced
────────────────────────
We're happy to announce that we just released ppxlib.0.34.0.
The full patch notes are available on the release page [over here].
The main features are OCaml 5.3 compatibility, new AST pretty-printing
utilities and the ppxlib-tools package, support for `[@@deriving ...]'
on class types and the addition of missing `Pprintast' entry points.
[over here] <https://github.com/ocaml-ppx/ppxlib/releases/tag/0.34.0>
Changes summary
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ 5.3 compatibility
ppxlib.0.34.0 is the first official ppxlib release that's compatible
with the new 5.3 compiler.
The ppxlib driver now also comes with a `-keywords' CLI option,
similar to the compiler's that allow you to compile and preprocess
with the 5.3 compiler code that uses `effect' as an identifier. This
is pretty niche but it's there should you need it.
Please note that means you can use ppx-es with a 5.3 compiler but not
that ppx-es can consume/produce 5.3 language features. We're currently
working on a fix allowing you to use the effect syntax in files that
require preprocessing as it's not possible with 0.34.0. The fix should
be released in the next few days as 0.34.1.
◊ AST pretty-printing
We added a new `Pp_ast' module that allows you to pretty print AST
fragments.
The only way ppxlib would print ASTs before were as S-expressions. In
practice we found that it was not always helpful and wanted a more
readable and human friendly way of displaying the AST.
The default output of those printer is a simplified version of the AST
to keep things clear and avoid cluttering the output with information
that is not always useful. For example, if you run
`Ppxlib.Pp_ast.Default.expression' on the AST for `x + 2', you'll get
the following:
┌────
│ Pexp_apply
│ ( Pexp_ident (Lident "+")
│ , [ ( Nolabel, Pexp_ident (Lident "x"))
│ ; ( Nolabel, Pexp_constant (Pconst_integer ( "2", None)))
│ ]
│ )
└────
The alert reader will note that there are no locations or attributes
and that the `expression' record layer is omitted here.
You can of course configure the printer to display more information if
you need to.
We've been using these new printers internally to debug migration code
and they have been a huge help so we hope they will make working with
ppxlib easier for you too.
In addition to this new module, we also added a command line utility
called `ppxlib-pp-ast' to pretty print ASTs from source files, source
code fragments or even marshalled AST files. It is very similar to the
old `ppx_tools''s `dumpast'.
Note that it will print ppxlib's internal AST after it's been migrated
from the installed compiler's version. This is something that we could
not simply achieve with OCaml's own `-dparsetree'.
This should be a useful tool for debugging ppx related bugs or
learning about the AST and we hope ppx authors and users will like it.
◊ Other changes
As mentioned above, we also added some missing `Pprintast~¹ entries
such as ~binding', `longident' and `payload'.
It is now possible to use `[@@deriving ...]' on class type
declarations and therefore to write derivers for class types.
¹: /To the confused readers:/ `Pprintast' /is entirely different from/
`Pp_ast' /mentioned above as it prints the source code corresponding
to a given AST./
Plans for the next release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Internal AST bump to 5.2
Our next release will bump our internal AST to 5.2. It is a pretty big
change because 5.2 changed how functions were represented in the AST
and this impacts *A LOT* of ppx-es.
@patricoferris has been working very hard on this over the past few
months to minimize the amount of breakage and to send patches upstream
where that was not possible to get the rest of the ecosystem ready for
the bump.
We wanted to first release the 5.3 compatibility but now that's out of
the way we're able to focus on the bump again.
@patricoferris will create a dedicated thread shortly to explain a bit
what's been going on and what to expect from this release.
◊ Drop support for OCaml < 4.08
It is time for us to drop support for very old compilers. Keeping
support for OCaml 4.07 and before requires maintenances of quite heavy
compatibility layers and prevents us from using some language features
in ppxlib's source code while providing little to no benefits since
the vast majority of users already upgraded to much more recent
compilers.
If you're still relying on those older compilers and the newest
ppxlib, please reach out, either here or via a ppxlib issue.
Special thanks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We wanted to thank our external contributors for this release: @hhugo,
@nojb and @dra27 for their help on the 5.3 compat and @mattiasdrp for
bringing the `Pprintast' module up to speed.
Special thanks as well to @pedrobslisboa who started integrating their
excellent [ppx-by-example] into ppxlib's documentation.
Finally, I'd also like to thank the OCaml Software Foundation who's
been funding all my work on ppxlib and made this release possible!
Happy preprocessing to you all!
[ppx-by-example] <https://github.com/pedrobslisboa/ppx-by-example>
Release of Carton 1.0.0 and Cachet
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-release-of-carton-1-0-0-and-cachet/15953/1>
Calascibetta Romain announced
─────────────────────────────
I'm delighted to announce the release of [Carton 1.0.0] and [Cachet]
(which will be released soon into `opam-repository').
Carton is a reimplementation of the Git PACK format. A PACK file is
what you can find in your `.git/objects/pack' in your favourite Git
repository. It contains mainly all your Git objects. This format
provides a good compression ratio and the ability to extract objects
almost directly. It can be seen as a read-only key-value database — in
effect, modifying Git objects is impossible.
This project is built around the OCaml implementation of Git that we
have. But the PACK format is also interesting in its own right and
outside the Git concepts.
The PACK format offers double compression. A zlib compression
(proposed by [decompress]) as well as a compression between objects in
the form of a binary patch (proposed by [duff]).
So, if the "words" appear quite frequently (like the words used in a
programming language — if, else, then, etc.), the second level of
compression becomes very interesting where an object (such as a file)
is simply a succession of patches with other objects.
[Carton 1.0.0] <https://github.com/robur-coop/carton>
[Cachet] <https://github.com/robur-coop/cachet>
[decompress] <https://github.com/mirage/decompress>
[duff] <https://github.com/mirage/duff>
Cachet, a library for `mmap' syscall
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Carton and the PACK format very often use syscall `mmap'. The point is
to be able to take advantage of the kernel cache system to read a PACK
file. The kernel can read a file in advance when reading a page via
`mmap'. Basically, the kernel anticipates that you might want to get
the next page after the one you requested.
However, in the case of Carton, it is sometimes necessary to ‘go
back’, particularly for patched objects whose source is often
upstream.
Cachet is an intermediate layer for `mmap' that caches previously
obtained pages. In this way, we take advantage of both the kernel for
subsequent pages and our library for previous pages.
Let's take a concrete example. Carton can analyse a PACK file as `git
verify-pack' does. Let's make a comparison with and without Cachet.
┌────
│ +--------------+-------------+----------------+-----------------+
│ | | with cachet | without cachet | git verify-pack |
│ +--------------+-------------+----------------+-----------------+
│ | time | 17.8s | 41.8s | 9.3s |
│ +--------------+-------------+----------------+-----------------+
│ | cache misses | 936M | 1933M | 246M |
│ +--------------+-------------+----------------+-----------------+
└────
As you can see, using Cachet improves Carton's execution time. We're
still not as competitive as git-verify-pack, but we're getting close!
Cachet offers to cache previously loaded pages. Its cache system is
very basic and is just a small array whose size is a power of
two. Next, we simply reuse the OCaml hash function — in this respect,
it may be worth testing another hash function.
◊ Cachet & schedulers
Like most of our projects, Cachet is independent of schedulers. There
is therefore a variant with [Lwt] and a variant with [Miou]. However,
we need to clarify a behaviour related to the use of Cachet. Reading a
file, whether with `read(3)' or `mmap(3P)', does not block, but it can
take some time.
As we have already experienced and explained [here], it may be
necessary to explain to the scheduler whether it is appropriate to do
something else after such a syscall. In the case of Lwt, it might be a
good idea to insert `Lwt.pause' just after our syscall so that Lwt
gives another service the opportunity to run despite the time taken
trying to read from a file. However, particularly for Lwt, this means
closing Cachet in the hell of the monad (in other words, there is no
way to escape it) because of this possible `Lwt.pause' (which returns
`unit Lwt.t').
The composition of Cachet with Lwt is therefore quite different from
what we've been able to experiment with. One of [our other articles]
suggests not using functors (too much), and although we can in fact
abstract `Lwt.t' from `unit Lwt.t' (and even reduce it such that `type
'a t = 'a') with the [HKP] trick, we opted for composition by hand.
The problem relates to Lwt (and Async) and doesn't apply to Miou when
it's possible to raise effects. However, from such a composition, a
choice has been made to give Lwt the opportunity to do something else
after `mmap'. We could, in other types of applications, make another
choice on this precise question.
[Lwt] <https://github.com/ocsigen/lwt>
[Miou] <https://github.com/robur-coop/miou>
[here] <https://blog.robur.coop/articles/lwt_pause.html>
[our other articles]
<https://blog.robur.coop/articles/tar-release.html>
[HKP]
<https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-kinded-polymorphism.pdf>
Carton
╌╌╌╌╌╌
Carton is a library that was originally developed for ocaml-git. It
was internal to the project but we considered that the PACK format's
field of application could be wider than that of Git. We decided to
extract the project from `ocaml-git' and make it a library in its own
right. Carton's objective remains fairly rudimentary. It consists of:
• extract objects from a PACK file (whether or not these objects are
Git objects)
• generate an `*.idx' file from a PACK file in order to have quick
access to the objects
• verifying a PACK file such as `git verify-pack' does
• and finally generate a PACK file from a list of objects
Carton is a library and a tool that you can now use on your Git
repositories. Here are a few examples of how to use `carton'. We'll
start by cloning a repository to test Carton and go to the folder
containing the PACK file.
┌────
│ $ opam install carton.1.0.0
│ $ git clone https://github.com/ocaml/ocaml
│ $ cd ocaml/.git/objects/pack/
└────
Carton can check a PACK file. Verifying means extracting all the
objects in the file from memory and calculating their hash. This
command is similar to `git verify-pack'.
┌────
│ $ carton verify pack-*.pack
└────
Carton can extract a specific object (commit, tree or blob) from a
PACK file using its associated `*.idx' file and the object identifier
(the hash of the commit, for example).
┌────
│ $ carton get pack-*.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2
└────
Instead of extracting objects from a PACK file into memory, you can
also extract them as files using `explode'.
┌────
│ $ mkdir loose
│ $ carton explode 'loose/%s/%s' pack-*.pack > entries.pack
└────
Finally, Carton can create a new PACK file from a list of objects
stored in files with make. It can also generate the `*.idx' file
associated with the new PACK file. As we've just re-packaged the
objects in the repository, we should find the same objects.
┌────
│ $ carton make -n $(cat entries.pack | wc -l) -e entries.pack new.pack
│ $ carton index new.pack
│ $ carton get new.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2
└────
Please note that the above actions, applied to `ocaml/ocaml', may take
some time due to the history of this project.
In the example above, we can see the extraction of a Git object, the
extraction of all the objects in a PACK file and the creation of a new
PACK file based on all the extracted objects.
As you can see, creating a PACK file can take a long time. However,
the advantage of the PACK file lies particularly in obtaining the
objects and in the rate of compression of the PACK file:
┌────
│ +--------+-------------+----------+-------+--------------+
│ | | pack-*.pack | new.pack | loose | loose.tar.gz |
│ +--------+-------------+----------+-------+--------------+
│ | size | 355M | 648M | 8.3G | 1.8G |
│ +--------+-------------+----------+-------+--------------+
└────
The PACK file is primarily designed to provide access to objects
according to their identifiers. This access must be as fast as
possible, even if the object is first compressed with decompress and
can be compressed in the form of a patch with duff. Here are a few
metrics to give you an idea.
┌────
│ +--------------+-------------+----------+---------+
│ | | pack-*.pack | new.pack | loose |
│ +--------------+-------------+----------+---------+
│ | git cat-file | ~ 0.01s | N/A | N/A |
│ +--------------+-------------+----------+---------+
│ | carton get | ~ 0.20s | ~ 0.30s | |
│ +--------------+-------------+----------+---------+
│ | cat | N/A | N/A | 0.0006s |
│ +--------------+-------------+----------+---------+
└────
What's important to note is the ability to have random access to
objects simply by having the associated `*.idx' file, the production
of which is quite efficient. This is not or hardly the case for
compression formats such as GZip. And that's the whole point of PACK
files, with an indexing method for almost immediate access to objects
according to their identifiers and offering a very good compression
ratio.
*NOTE*: Carton does not compress the repository as well as Git. The
main reason is that Git has some heuristics relating to Git objects
that Carton does not implement - because Carton wishes to be
independent of Git concepts. These heuristics apply in particular to
the order in which we want to pack objects. In addition, Git prepares
the ground so that the antecedents of a blob object (which is a file
in your repository), for example, are the old versions of that same
blob (and therefore the old versions of your file).
In this context, the patch algorithm implemented by [duff] applies
very well and gives very good results.
For more details on these heuristics, you can read [this discussion]
that serves as documentation.
[duff] <https://github.com/mirage/duff>
[this discussion]
<https://github.com/git/git/blob/master/Documentation/technical/pack-heuristics.txt>
◊ Carton & parallelism
As always, our libraries are independent of schedulers. There is a
version of Carton with Lwt and a version with Miou.
Some of the tasks Carton performs, such as indexing, are highly
parallelizable. In this case, the new derivation of Carton with Miou
exists to take advantage of the latter's domain pool.
It was also quite easy to parallelize the work on `carton index' and
`carton verify'. Here are some other metrics which, thanks to OCaml 5
and Miou, bring us closer to Git performance:
┌────
│ $ hyperfine \
│ -n git \
│ "git verify-pack pack-03a3a824757ff4c225874557c36d44eefe3d7918.idx" \
│ -n carton \
│ "carton verify pack-03a3a824757ff4c225874557c36d44eefe3d7918.pack -q --threads 4"
│ Benchmark 1: git
│ Time (mean ± σ): 329.2 ms ± 0.9 ms [User: 384.2 ms, System: 27.8 ms]
│ Range (min … max): 327.7 ms … 330.9 ms 10 runs
│
│ Benchmark 2: carton
│ Time (mean ± σ): 712.1 ms ± 10.9 ms [User: 1111.8 ms, System: 1112.6 ms]
│ Range (min … max): 695.4 ms … 726.8 ms 10 runs
│
│ Summary
│ git ran
│ 2.16 ± 0.03 times faster than carton
└────
*NOTE*: it may come as a surprise that Carton is 2 times slower than
Git for analysing a PACK file, but it should be noted that almost the
entire Carton implementation is in OCaml! At this stage, the idea is
more to give you an idea, but we literally find ourselves comparing a
Bugatti with a [Citroën 2CV].
[Citroën 2CV] <https://www.youtube.com/watch?v=Pkhibs9n7tE>
◊ Carton & Emails
Finally, this in-depth rewrite of Carton allows us to take advantage
of the PACK format for storing our emails.
In fact, we are experimenting with and developing an email solution
within our cooperative, and email archiving is one of our
objectives. Based on our experience of implementing Git, we thought
that the PACK format could be a very interesting format for archiving
emails.
It combines two features, rapid access to emails and compression by
patches, which are very interesting when it comes to handling
emails. Finally, it also corresponds more or less to the way we use
email:
• we don't want to delete them (more often than not, we want to keep
them _ad vitam aeternam_)
• and we don't modify them
It therefore corresponds to a sort of read-only database. For more
details on this aspect of Carton and the results of our experiments, I
suggest you read our [recent article on our cooperative's blog].
[recent article on our cooperative's blog]
<https://blog.robur.coop/articles/2025-01-07-carton-and-cachet.html>
Opam repository archival, phase 2 - OCaml 4.08 is the lower bound
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-arcival-phase-2-ocaml-4-08-is-the-lower-bound/15965/1>
Hannes Mehnert announced
────────────────────────
It is my pleasure to announce below the list of opam packages that
will move to the opam-repository-archive on February 1st 2025. In
total there are 5855 opam files scheduled for being moved within 1218
unique packages. This decreases the size of the opam-repository by
roughly 20%.
/Editor note: please follow the post link for the other articles with
whole list./
This list contains all packages that are not compatible with OCaml >=
4.08, and packages that after archiving those are not installable due
to missing dependencies. The "not installable" list has been generated
by [archive-opam], and this may of course contain bugs.
A smaller list contains a re-run of phase 1 (packages that are
available: false) - where the availability was added between Dec 15th
and now.
If you find a package in the list and you’d like to retain it in the
opam-repository, there are some options:
• (a) you can install it on your system (`opam install'): this means
there’s a bug in the archive-opam utility, please provide the
package name and version in the [opam-repository-archive Phase 2
PR], together with your opam version, OCaml version, and operating
system;
• (b) it is not installable: please figure out the reasoning (the
“Reasoning” may help you to find the root issue), and try to fix it
yourself - if you’re unable to fix the root cause, please also
comment in the [opam-repository-archive Phase 2 PR] with the package
name and version.
If you’ve any questions, please don’t hesitate to ask here or on
GitHub or via another communication channel.
You can help further on the archiving process:
• as mentioned in the last announcement please add the
`x-maintenance-intent' to your packages (a good choice for a lot of
packages is `x-maintenance-intent: [("latest")]' if you’re
maintaining the latest version only) - this will be considered in
Phase 3 (March 1st 2025);
• if you are the author or maintainer of a package that is no longer
useful or maintained, you can as well mark your opam files in the
opam-repository with `x-maintenance-intent: [("none")]' (this will
be taken into account in Phase 3 - March 1st 2025);
• if you flagged your preliminary releases with `flags:
avoid-version', and they can now be removed (e.g. since a stable
version has been released), please open a pull request to replace
the `avoid-version' with `deprecated'.
Please note that the next Phase will be announced on February 15th
with all packages where the `x-maintenance-intent' does not match, and
which do not have any reverse dependencies - archiving is scheduled
for March 1st.
To keep track of the announcements, please look at the
[opam-repository tag].
A big thanks to the OCaml Software Foundation for funding the
opam-repository archival project.
[archive-opam] <https://github.com/hannesm/archive-opam>
[opam-repository-archive Phase 2 PR]
<https://github.com/ocaml/opam-repository-archive/pull/6>
[opam-repository tag] <https://discuss.ocaml.org/tag/opam-repository>
Ocaml-posix 2.1.0 released!
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-posix-2-1-0-released/15974/1>
Romain Beauxis announced
────────────────────────
Hi all!
Version `2.1.0' of `ocaml-posix' has been released!
• Repo: <https://github.com/savonet/ocaml-posix>
• API doc: [ocaml-posix]
While it was long overdue, this version only include minor changes,
along with the addition of `posix-math2'.
These packages are intended to provide a consistent, extensive set of
bindings for the various POSIX APIs to be used with [ocaml-ctypes]
when building bindings to C libraries that require the use of these
APIs.
While working on OCaml projects, it is common to have to interface
with APIs derived from the POSIX specifications, `getaddrinfo',
`uname' etc.
The core OCaml library provides their own version of these APIs but:
• They only cover parts of it
• They wrap some native types such as `socketaddr' into custom, opaque
OCaml types, making it impossible to re-use, for instance when using
a C library API requiring a POSIX `sockaddr'.
Thus, having a large, consistent set of bindings for these APIs that
reflect the actual C types, structures and etc greatly improves the
usability of the language and ecosystem as a whole by making it
possible to interface it with a large set of C libraries in a reusable
way.
The project has been mostly stable for a couple of years (and so have
the POSIX standards), but could use some more hands if there is more
need in the community to extend the set of POSIX APIs supported by the
language.
[ocaml-posix] <https://www.liquidsoap.info/ocaml-posix/>
[ocaml-ctypes] <https://github.com/yallop/ocaml-ctypes>
Release of ocaml-eglot 1.0.0
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-release-of-ocaml-eglot-1-0-0/15978/1>
Xavier Van de Woestyne announced
────────────────────────────────
Hi everyone!
We (at [Tarides]) are _particularly pleased_ to announce the first
release of [OCaml-eglot], An overlay on [Eglot] (the _built-in_ [LSP]
client for Emacs) for editing OCaml!
• [Github repository]
• [Package on MELPA]
• [Features list]
• [Installation procedure]
• [Comparison table with Merlin]
[Tarides] <https://tarides.com/>
[OCaml-eglot] <https://github.com/tarides/ocaml-eglot>
[Eglot] <https://www.gnu.org/software/emacs/manual/html_node/eglot/>
[LSP] <https://microsoft.github.io/language-server-protocol/>
[Github repository] <https://github.com/tarides/ocaml-eglot>
[Package on MELPA] <https://melpa.org/#/ocaml-eglot>
[Features list]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#features>
[Installation procedure]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#installation>
[Comparison table with Merlin]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#comparison-of-merlin-and-ocaml-eglot-commands>
More precisely
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Typically, developers who use Emacs (`43.7%' in 2022, [according to
the OCaml User Survey]) use a major mode (such as the venerable
[caml-mode], or [tuareg]) and [Merlin] to provide IDE services. In
2016, Microsoft has released LSP, a generic protocol for interacting
with editors which, at first, was only used by Visual Studio Code,
but, since 2020, has really become the norm. De-facto, following the
LSP standard gives very good _default_ (completion, jump to
definition, …). OCaml has excellent LSP ([ocaml-lsp-server]) support,
which is used in particular by the [OCaml platform for Visual Studio
Code].
With the aim of reducing maintenance for all possible editors, going
LSP seems to be a good direction. A pertinent choice, especially since
the major historical editors (such as Vim and Emacs) offer, in their
recent versions, LSP clients _out of the box_. However, in the same
way that the OCaml client for VSCode integrates *OCaml-specific*
features, it was necessary to support these features on the Emacs side
(and in the future, Vim) to compete with Merlin, which is the goal of
`ocaml-eglot', to *provide a tailored development experience for OCaml
code editing*!
[according to the OCaml User Survey]
<https://ocaml-sf.org/docs/2022/ocaml-user-survey-2022.pdf>
[caml-mode] <https://github.com/ocaml/caml-mode>
[tuareg] <https://github.com/ocaml/tuareg>
[Merlin] <https://github.com/ocaml/merlin>
[ocaml-lsp-server] <https://ocaml.org/p/ocaml-lsp-server/latest>
[OCaml platform for Visual Studio Code]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>
User feedback and future development
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We've just released the first version of OCaml-eglot, and, much like
the various editor-related projects (Merlin, Vscode-ocaml-platform,
Merlin for Emacs, Merlin for Vim), *we're more than open to community
collaboration, user feedback*, in order to provide the best possible
user experience!
_Happy Hacking_!
Semgrep is hiring to help scale their static analysis engine
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-remote-semgrep-is-hiring-to-help-scale-their-static-analysis-engine/15982/1>
Emma Jin announced
──────────────────
Semgrep is an application security company focused on detecting and
remediating vulnerabilities. The static analysis engine is primarily
written in OCaml. We're looking for a software engineer to help us
support scanning larger repositories and add many more users. The
ideal candidate has owned a critical tool, worked on an OCaml project,
and is interested in static analysis.
If this sounds interesting to you, see our job posting at
<https://job-boards.greenhouse.io/semgrep/jobs/4589941007>! Let me
know if you have any questions!
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/21>
Etienne Marais announced
────────────────────────
Hi Dune enthusiasts :camel:,
We will hold the regular Dune Dev Meeting on *Wednesday, January, 22nd
at 16:00* CET. As usual, the session will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers!
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-01-22>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [GitHub Wiki]
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Tarides: 2024 in Review
═══════════════════════
Archive: <https://discuss.ocaml.org/t/tarides-2024-in-review/15990/1>
Thomas Gazagnaire announced
───────────────────────────
At [Tarides], we believe in making OCaml a mainstream programming
language by improving its tooling and integration with other
successful ecosystems. In 2024, we focused our efforts on initiatives
to advance this vision by addressing key technical challenges and
engaging with the community to build a stronger foundation for OCaml’s
growth. This report details our work, the rationale behind our
choices, and the impact achieved. We are very interested in getting
your feedback: [please get in touch] (or respond to this thread!) if
you believe we are going in the right direction.
/__TL;DR__ – In 2024, Tarides focused on removing adoption friction
with better documentation and tools; and on improving adoption via the
integration with three key thriving ecosystems: multicore programming,
web development, and Windows support. Updates to [ocaml.org] improved
onboarding and documentation, while the [Dune Developer Preview]
simplified workflows with integrated package management. Merlin added
support for [project-wide reference support] and [odoc 3], which is
about to be released. OCaml 5.3 marked the first stable multicore
release, and `js_of_ocaml' achieved up to 8x performance boosts in
real-world commercial applications thanks to added support for
WebAssembly. On Windows, opam 2.2 brought full compatibility and CI
testing to all Tier 1 platforms on `opam-repository', slowly moving
community packages towards reliable and better support for
Windows. Tarides’ community support included organising the first [FUN
OCaml conference], many local meetups, and two rounds of Outreachy
internships./
[Tarides] <https://tarides.com>
[please get in touch] <https://tarides.com/contact/>
[ocaml.org] <http://ocaml.org>
[Dune Developer Preview] <https://preview.dune.build/>
[project-wide reference support]
<https://tarides.com/blog/2024-08-28-project-wide-occurrences-a-new-navigation-feature-for-ocaml-5-2-users/>
[odoc 3] <https://discuss.ocaml.org/t/odoc-3-0-planning/14360>
[FUN OCaml conference] <https://fun-ocaml.com/>
Better Tools: Toward a 1-Click Installation of OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Our primary effort in 2024 was to continue delivering on the [OCaml
Platform roadmap] published last year. We focused on making it easier
to get started with OCaml by removing friction in the installation and
onboarding process. Our priorities were guided by the latest [OCSF
User Survey], direct user interviews, and [feedback] gathered from the
OCaml community. Updates from Tarides and other OCaml Platform
maintainers were regularly shared in the [OCaml Platform Newsletter].
[OCaml Platform roadmap] <https://ocaml.org/tools/platform-roadmap>
[OCSF User Survey]
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2023/13469>
[feedback] <https://discuss.ocaml.org/tag/user-feedback>
[OCaml Platform Newsletter]
<https://discuss.ocaml.org/tag/platform-newsletter>
◊ OCaml.org
OCaml.org is the main entry point for new users of OCaml. Tarides
engineers are key members of the OCaml.org team. Using
[privacy-preserving analytics], the team tracked visitor behaviour to
identify key areas for improvement. This led to a redesign of the
[installation page], simplifying the setup process, and a revamp of
the [guided tour of OCaml] to better introduce the language. Both
pages saw significant traffic increases compared to 2023, with the
installation page recording 69k visits, the tour reaching 65k visits
and a very encouraging total number of visits increasing by +33%
between Q3 and Q4 2024
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/1/137aea463013b31666bcade145a0067f2c1d6b82.png>
Efforts to improve user experience included a satisfaction survey
where 75% of respondents rated their experience positively, compared
to 17% for the previous version of the site. User testing sessions
with 21 participants provided further actionable insights, and these
findings informed updates to the platform. The redesign of OCaml.org
community sections was completed using this feedback. It introduced
several new features: a new [Community landing page], an [academic
institutions page] with course listings, and an [industrial users
showcase]. The team also implemented an automated [event announcement]
system to inform the community of ongoing activities.
Progress and updates were regularly shared through the [OCaml.org
newsletters], keeping the community informed about
developments. Looking ahead, the team will continue refining the
platform by addressing feedback, expanding resources, and monitoring
impact through analytics to support both new and experienced OCaml
users. Lastly, the infrastructure they build is starting to be used by
other communities: [Rocq] just announced their brand new website,
built using the same codebase as ocaml.org!
[privacy-preserving analytics] <https://plausible.ci.dev/ocaml.org>
[installation page] <https://ocaml.org/install>
[guided tour of OCaml] <https://ocaml.org/docs/tour-of-ocaml>
[Community landing page] <https://ocaml.org/community>
[academic institutions page] <https://ocaml.org/academic-users>
[industrial users showcase] <https://ocaml.org/industrial-users>
[event announcement] <https://ocaml.org/events>
[OCaml.org newsletters]
<https://discuss.ocaml.org/tag/ocamlorg-newsletter>
[Rocq] <https://rocq-prover.org/>
◊ Dune as the Default Frontend of the OCaml Platform
One of the main goals of the OCaml Platform is to make it easier for
users—especially newcomers—to adopt OCaml and build projects with
minimal friction. A critical step toward this goal is having a single
CLI to serve as the frontend for the entire OCaml development
experience (codenamed [Bob] in the past). This year, we made
significant progress in that direction with the release of the [Dune
Developer Preview].
Setting up an OCaml project currently requires multiple tools: `opam'
for package management, `dune' for builds, and additional
installations for tools like OCamlFormat or Odoc. While powerful, this
fragmented workflow can make onboarding daunting for new users. The
Dune Developer Preview consolidates these steps under a single CLI,
making OCaml more approachable. With this preview, setting up and
building a project is as simple as:
1. `dune pkg lock' to lock the dependencies.
2. `dune build' to fetch the dependencies and compile the project.
This effort is also driving broader ecosystem improvements. The
current OCaml compiler relies on fixed installation paths, making it
difficult to cache and reuse across environments, so it cannot be
shared efficiently between projects. To address this, we are working
on making the compiler relocatable ([ongoing work]). This change will
enable compiler caching, which means faster project startup times and
fewer rebuilds in CI. As part of this effort, we also [maintain]
patches to core OCaml projects to make them relocatable – and we
worked with upstream to merge (like [for ocamlfind]). Tarides
engineers also continued to maintain Dune and other key Platform
projects, ensuring stability and progress. This included organising
and participating in regular development meetings (for [Dune], [opam],
[Merlin], [ppxlib], etc.) to prioritise community needs and align
efforts across tools like Dune and opam to avoid overlapping
functionality.
The Dune Developer Preview is an iterative experiment. Early user
feedback has been promising (the Preview’s NPS went from +9 in Q3 2024
to +27 in Q4 2024), and future updates will refine the experience
further. We aim to ensure that experimental features in the Preview
are upstreamed into stable releases once thoroughly tested. For
instance, the package management feature is already in Dune 3.17. We
will announce and document it more widely when we believe it is mature
enough for broader adoption.
[Bob] <https://speakerdeck.com/avsm/ocaml-platform-2017?slide=34>
[Dune Developer Preview] <https://preview.dune.build/>
[ongoing work] <https://hackmd.io/@dra27/ry56XtKii>
[maintain]
<https://github.com/ocaml-dune/opam-overlays/tree/main/packages>
[for ocamlfind] <https://github.com/ocaml/ocamlfind/pull/72>
[Dune] <https://discuss.ocaml.org/tag/dev-meetings>
[opam] <https://github.com/ocaml/opam/wiki/2024-Developer-Meetings>
[Merlin]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
[ppxlib] <https://github.com/ocaml-ppx/ppxlib/wiki#dev-meetings>
◊ Editors
In 2024, Tarides focused on improving editor integration to lower
barriers for new OCaml developers and enhance the experience for
existing users. Editors are the primary way developers interact with
programming languages, making seamless integration essential for
adoption. With more than [73% of developers using Visual Studio Code
(VS Code)], VS Code is particularly important to support, especially
for new developers and those transitioning to OCaml. As part of this
effort, Tarides wrote and maintained the [official VS Code plugin for
OCaml,] prioritising feature development for this editor. We also
support other popular editors like Emacs and Vim—used by many Tarides
engineers—on a best-effort basis. Improvements to [OCaml-LSP] and
[Merlin], both maintained by Tarides, benefit all supported editors,
ensuring a consistent and productive development experience.
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/9/9b63754a94bc853f608e630dd9908097570a33ac.png>
While several plugins for OCaml exist ([OCaml and Reason IDE]–128k
installs, [Hackwaly]–90k installs), our [OCaml VS Code plugin] –now
with over 208k downloads– is a key entry point for developers adopting
OCaml in 2024. This year, we added integration with the Dune Developer
Preview, allowing users to leverage Dune's package management and
tooling directly from the editor. Features such as real-time
diagnostics, autocompletion, and the ability to fetch dependencies and
build projects without leaving VS Code simplify development and make
OCaml more accessible for newcomers.
The standout update in 2024 was the addition of [project-wide
reference support], a long-requested feature from the OCaml community
and a top priority for commercial developers. This feature allows
users to locate all occurrences of a term across an entire codebase,
making navigation and refactoring significantly easier—especially in
large projects. Delivering this feature required coordinated updates
across the ecosystem, including changes to the OCaml compiler, Merlin,
OCaml LSP, Dune, and related tools. The impact is clear: faster
navigation, reduced cognitive overhead, and more efficient workflows
when working with complex projects.
Additional improvements included support for new Language Server
Protocol features, such as `signature_help' and `inlay_hint', which
enhance code readability and provide more contextual
information. These updates enabled the introduction of new commands,
such as the "Destruct" command. This [little-known but powerful
feature] automatically expands a variable into a pattern-matching
expression corresponding to its inferred type, streamlining tasks that
would otherwise be tedious.
<https://tarides.com/blog/images/2024-05-21.merlin-destruct/merlin-destruct-1~kHA8_iC67tU-2us0hsjbhQ.gif>
[73% of developers using Visual Studio Code (VS Code)]
<https://survey.stackoverflow.co/2024/technology#1-integrated-development-environment>
[official VS Code plugin for OCaml,]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>
[OCaml-LSP] <https://github.com/ocaml/ocaml-lsp>
[Merlin] <https://github.com/ocaml/merlin>
[OCaml and Reason IDE]
<https://marketplace.visualstudio.com/items?itemName=freebroccolo.reasonml>
[Hackwaly]
<https://marketplace.visualstudio.com/items?itemName=hackwaly.ocaml>
[OCaml VS Code plugin]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>
[project-wide reference support]
<https://tarides.com/blog/2024-08-28-project-wide-occurrences-a-new-navigation-feature-for-ocaml-5-2-users/>
[little-known but powerful feature]
<https://tarides.com/blog/2024-05-29-effective-ml-through-merlin-s-destruct-command/>
◊ Documentation
Documentation was identified as the number one pain point in the
latest [OCSF survey]. It is a critical step in the OCaml developer
journey, particularly after setting up the language and
editor. Tarides prioritised improving `odoc' to make it easier for
developers to find information, learn the language, and navigate the
ecosystem effectively. High-quality documentation and tools to help
developers get "unstuck" are essential to reducing friction and
ensuring a smooth adoption experience.
Tarides is the primary contributor and maintainer of [`odoc'], OCaml’s
main documentation tool. In preparation for the [odoc 3 release], our
team introduced two significant updates. First, the [`odoc' Search
Engine] was integrated, allowing developers to search directly within
OCaml documentation via the [Learn page]. Second, the [`odoc'
Cheatsheet] provides a concise reference for creating and consuming
OCaml documentation. We would like to believe that these updates,
deployed on ocaml.org, were the main cause of a **45% increase in
package documentation usage** on [https://ocaml.org/pkg/] in Q4 2024!
<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/a/a974b30576399d84e1b26936b4b31bdf364e76db.png>
Another area where developers often get stuck is debugging programs
that don’t work as expected. Alongside reading documentation, live
debuggers are crucial for understanding program issues. Tarides worked
to improve native debugging for OCaml, focusing on macOS, where LLDB
is the only supported debugger. Key progress included a [name mangling
fix] to improve symbol resolution, restoring ARM64 backtraces, and
introducing Python shims for code sharing between LLDB and GDB.
OCaml’s error messages remain a common pain point, particularly for
syntax errors. Unlike [Rust’s error index], OCaml does not (yet!) have
a centralised repository of error explanations. Instead, we are
focused on making error messages more self-explanatory. This requires
developing new tools, such as [`lrgrep'], a domain-specific language
for analysing grammars built with Menhir. `lrgrep' enables concise
definitions of error cases, making it possible to identify and address
specific patterns in the parser more effectively. This provides a
practical way to improve error messages without requiring changes to
the compiler. In December 2024, @let-def successfully defended his PhD
(a collaboration between Inria and Tarides) on this topic, so expect
upstreaming work to start soon.
[OCSF survey]
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2023/13469>
[`odoc'] <https://github.com/ocaml/odoc>
[odoc 3 release] <https://discuss.ocaml.org/t/odoc-3-0-planning/14360>
[`odoc' Search Engine]
<https://tarides.com/blog/2024-02-28-two-major-improvements-in-odoc-introducing-search-engine-integration/>
[Learn page] <https://ocaml.org/docs>
[`odoc' Cheatsheet]
<https://tarides.com/blog/2024-09-17-introducing-the-odoc-cheatsheet-your-handy-guide-to-ocaml-documentation/>
[https://ocaml.org/pkg/] <https://ocaml.org/pkg/>
[name mangling fix] <https://github.com/ocaml/ocull/pull/13050>
[Rust’s error index]
<https://doc.rust-lang.org/error_codes/error-index.html>
[`lrgrep'] <https://github.com/let-def/lrgrep>
◊ OCaml Package Ecosystem
The last piece of friction we aimed to remove in 2024 was ensuring
that users wouldn’t encounter errors when installing a package from
the community. This required catching issues early—before packages are
accepted into `opam-repository' and made available to the broader
ecosystem. To achieve this, Tarides has built and maintained extensive
CI infrastructure, developed tools to empower contributors, and guided
package authors to uphold the high quality of the OCaml package
ecosystem.
In 2024, Tarides’ CI infrastructure supported the OCaml community at
scale, handling approximately **20 million jobs on 68 machines
covering 5 hardware architectures**. This infrastructure continuously
tested packages to ensure compatibility across a variety of platforms
and configurations, including OCaml’s Tier 1 platforms: x86, ARM,
RISC-V, s390x, and Power. It played a critical role during major
events, such as new OCaml releases, by validating the ecosystem’s
readiness and catching regressions before they impacted
users. Additionally, this infrastructure supported daily submissions
to `opam-repository', enabling contributors to identify and resolve
issues early, reducing downstream problems. To improve transparency
and accessibility, we introduced a CI pipeline that automates
configuration updates, ensuring seamless deployments and allowing
external contributors to propose and apply changes independently.
In addition to maintaining the infrastructure, Tarides developed and
maintained the CI framework running on top of it. A major focus in
2024 was making CI checks available as standalone CLI tools
distributed via `opam'. These tools enable package authors to run
checks locally, empowering them to catch issues before submitting
their packages to `opam-repository'. This approach reduces reliance on
central infrastructure and allows developers to work more
efficiently. The CLI tools are also compatible with GitHub Actions,
allowing contributors to integrate tests into their own workflows. To
complement these efforts, we enhanced `opam-repo-ci', which remains an
essential safety net for packages entering the repository. Integration
tests for linting and reverse dependencies were introduced, enabling
more robust regression detection and improving the reliability of the
ecosystem.
To uphold the high standards of the OCaml ecosystem, every package
submission to `opam-repository' is reviewed and validated to ensure it
meets quality criteria. This gatekeeping process minimises errors
users might encounter when installing community packages, enhancing
trust in the ecosystem. In 2024, Tarides continued to be actively
[involved] in maintaining the repository, ensuring its smooth
operation. We also worked to guide new package authors by updating the
[contributing guide] and creating a detailed [wiki] with actionable
instructions for adding and maintaining packages. These resources were
[announced on Discuss] to reach the community and simplify the process
for new contributors, improving the overall quality of submissions.
[involved]
<https://github.com/ocaml/opam-repository/blob/master/governance/README.md#maintenance>
[contributing guide]
<https://github.com/ocaml/opam-repository/blob/master/CONTRIBUTING.md>
[wiki] <https://github.com/ocaml/opam-repository/wiki>
[announced on Discuss]
<https://discuss.ocaml.org/t/opam-repository-updated-documentation-retirement-and-call-for-maintainers/14325>
Playing Better with the Larger Ecosystem
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Concurrent & Parallel Programming in OCaml
_"Shared-memory multiprocessors have never really 'taken
off', at least in the general public. For large parallel
computations, clusters (distributed-memory systems) are
the norm. For desktop use, monoprocessors are plenty
fast."_ – [Xavier Leroy, November 2002]
Twenty+ years after this statement, processors are multicore by
default, and OCaml has adapted to this reality. Thanks to the combined
efforts of the OCaml Labs and Tarides team, the OCaml 5.x series
introduced multicore support after [a decade of research and
experimentation.] While this was a landmark achievement, the path to
making multicore OCaml stable, performant, and user-friendly has
required significant collaboration and continued work. In 2024,
Tarides remained focused on meeting the needs of the broader community
and commercial users.
OCaml 5.3 (released last week) was an important milestone in this
journey. With companies such as [Routine], [Hyper], and [Asemio]
adopting OCaml 5.x, and advanced experimentation ongoing at Jane
Street, Tezos, Semgrep, and others, OCaml 5.3 is increasingly seen as
the first “stable” release of the multicore series. While some
[performance issues] remain in specific parts of the runtime, we are
working closely with the community to address them in OCaml
5.4. Tarides contributed extensively to the [5.2] and [5.3] releases
by directly contributing to **nearly two-thirds of the merged pull
requests**. Since Multicore OCaml was incorporated upstream in 2023,
we have been continuously involved in the compiler and language
evolution in collaboration with Inria and the broader OCaml ecosystem.
Developing correct concurrent and parallel software is inherently
challenging, and this applies as much to the runtime as to
applications built on it. In 2024, we focused on advanced testing
tools to help identify and address subtle issues in OCaml’s runtime
and libraries. The [property-based test suite] reached maturity this
year, uncovering over 40 critical issues, with 28 resolved by Tarides
engineers. Trusted to detect subtle bugs, such as [issues with
orphaned ephemerons], the suite has become an integral part of OCaml’s
development workflow. Importantly, it is accessible to contributors
without deep expertise in multicore programming, ensuring any changes
in the compiler or the runtime do not introduce subtle concurrency
bugs.
<https://tarides.com/blog/images/false-alarms-plot-errors-only.png>
Another critical effort was extending ThreadSanitizer (TSAN) support
to most Tier 1 platforms and [applying it extensively to find and fix
data races in the runtime]. This work has improved the safety and
reliability of OCaml’s multicore features and is now part of the
standard testing process, further ensuring the robustness of the
runtime.
Beyond testing, we also worked to enhance library support for
multicore programming. The release of the [Saturn library] introduced
lock-free data structures tailored for OCaml 5.x. To validate these
structures, we developed [DSCheck], a static analyser for verifying
lock-free algorithms. These tools, along with Saturn itself, provide
developers with reliable building blocks for scalable multicore
applications.
Another promising development in 2024 was the introduction of the
[Picos] framework. Picos aims to provide a low-level foundation for
concurrency, simplifying interoperability between libraries like Eio,
Moonpool, Miou, Riot, Affect, etc. Picos offers a simple,
unopinionated, and safe abstraction layer for concurrency. We believe
it can potentially standardise concurrency patterns in OCaml, but we
are not there yet. Discussions are underway to integrate parts of
Picos into higher-level libraries and, eventually, the standard
library. We still have a long way to go, and getting feedback from
people who actively tried it in production settings would be very
helpful!
[Xavier Leroy, November 2002]
<https://sympa.inria.fr/sympa/arc/caml-list/2002-11/msg00274.html>
[a decade of research and experimentation.]
<https://tarides.com/blog/2023-03-02-the-journey-to-ocaml-multicore-bringing-big-ideas-to-life/>
[Routine] <https://routine.co/>
[Hyper] <https://hyper.systems>
[Asemio]
<https://tarides.com/blog/2024-09-19-eio-from-a-user-s-perspective-an-interview-with-simon-grondin/>
[performance issues] <https://github.com/ocaml/ocaml/issues/13733>
[5.2]
<https://tarides.com/blog/2024-05-15-the-ocaml-5-2-release-features-and-fixes/>
[5.3]
<https://tarides.com/blog/2025-01-09-ocaml-5-3-features-and-fixes/>
[property-based test suite]
<https://github.com/ocaml-multicore/multicoretests>
[issues with orphaned ephemerons]
<https://github.com/ocaml/ocaml/pull/13580#issuecomment-2478454501>
[applying it extensively to find and fix data races in the runtime]
<https://tarides.com/blog/2024-08-21-how-tsan-makes-ocaml-better-data-races-caught-and-fixed/>
[Saturn library]
<https://tarides.com/blog/2024-12-11-saturn-1-0-data-structures-for-ocaml-multicore/>
[DSCheck]
<https://tarides.com/blog/2024-04-10-multicore-testing-tools-dscheck-pt-2/>
[Picos] <https://ocaml-multicore.github.io/picos/doc/picos/index.html>
◊ Web
Web development remains one of the most visible and impactful domains
for programming languages; [JavaScript, HTML, and CSS are the most
popular technologies] in 2024. For OCaml to grow, it must integrate
well with this ecosystem. Fortunately, the OCaml community has already
built a solid foundation for web development!
On the frontend side, in 2024, Tarides focused on strengthening key
tools like [`js_of_ocaml'] by expanding its support for WebAssembly
(Wasm). `js_of_ocaml' (JSOO) has long been the backbone of OCaml’s web
ecosystem, enabling developers to compile OCaml bytecode into
JavaScript. This year, we [merged Wasm support back into JSOO],
unifying the toolchain and simplifying adoption for developers. The
performance gain of Wasm has been very impressive so far:
CPU-intensive applications in commercial settings have seen **2x to 8x
speedups** using Wasm compared to traditional JSOO. We also worked on
better support for effect handlers in `js_of_ocaml' to ensure
applications built with OCaml 5 can run as fast in the browser as they
used to with OCaml 4.
On the backend side, Tarides maintained and contributed to Dream, a
lightweight and flexible web framework. Dream powers projects like
[our own website] and the [MirageOS website], where we maintain a fork
to make Dream and MirageOS work well together. Additionally, in 2024,
we enhanced `cohttp', adding [proxy support] to address modern HTTP
requirements.
While Tarides focused on JSOO, `wasm_of_ocaml', Dream, and Cohttp, the
broader community made significant strides elsewhere. Tools like
Melange offer an alternative for compiling OCaml to JavaScript, and
frameworks like Ocsigen, which integrates backend and frontend
programming, continue to push the boundaries of what’s possible with
OCaml on the web. Notably, Tarides will build on this momentum in 2025
through a [grant] to improve direct-style programming for Ocsigen.
[JavaScript, HTML, and CSS are the most popular technologies]
<https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language>
[`js_of_ocaml'] <https://github.com/ocsigen/js_of_ocaml>
[merged Wasm support back into JSOO]
<https://github.com/ocsigen/js_of_ocaml/pull/1494>
[our own website] <https://tarides.com/>
[MirageOS website] <https://mirageos.org>
[proxy support] <https://github.com/mirage/ocaml-cohttp/pull/847>
[grant] <https://nlnet.nl/project/OCAML-directstyle/>
◊ Windows
Windows is the most widely used operating system, making first-class
support for it critical to OCaml’s growth. In 2024, **31% of visitors
to [ocaml.org]** accessed the site from Windows, yet the platform’s
support historically lagged behind Linux and macOS. This gap created
barriers for both newcomers and commercial users. We saw these
challenges firsthand, with Outreachy interns struggling to get started
due to tooling issues, and commercial users reporting difficulties
with workflow reliability and compilation speed.
To address these pain points, Tarides, in collaboration with the OCaml
community, launched the [Windows Working Group]. A key milestone that
our team contributed to was the release this year of **opam 2.2**,
three years after its predecessor. This release made the upstream
`opam-repository' fully compatible with Windows for the first time,
removing the need for a separate repository and providing Windows
developers access to the same ecosystem as Linux and macOS users. The
impact has been clear: feedback on the updated installation workflow
has been overwhelmingly positive, with developers reporting that it
"just works." The [install page] for Windows is now significantly
shorter and simpler!
In the OCaml 5.3 release, Tarides restored the MSVC Windows port,
ensuring native compatibility and improving performance for Windows
users. To further support the ecosystem, Tarides added Windows
machines to the opam infrastructure, enabling automated testing for
Windows compatibility on every new package submitted to opam. This has
already started to improve package support, with ongoing fixes from
Tarides and the community. The results are publicly visible at
[windows.check.ci.dev], which we run on our infrastructure, providing
transparency and a way to track progress on the status of our
ecosystem. While package support is not yet on par with other
platforms, we believe that the foundations laid in 2024—simplified
installation, improved tooling, and continuous package
testing—represent a significant step forward.
[ocaml.org] <https://ocaml.org>
[Windows Working Group]
<https://tarides.com/blog/2024-05-22-launching-the-first-class-windows-project/>
[install page] <https://ocaml.org/install>
[windows.check.ci.dev] <https://windows.check.ci.dev/>
Community Engagement and Outreach
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In 2024, Tarides contributed to building a stronger OCaml community
through events, internships, and support for foundational
projects. The creation of [FUN OCaml 2024] in Berlin was the first
dedicated OCaml-only event for a long time (similar to how the OCaml
Workshop was separated from ICFP in the past). Over 75 participants
joined for two days of talks, workshops, and hacking, and the event
has already reached [5k+ views on YouTube]. Tarides also co-chaired
the OCaml Workshop at [ICFP 2024] in Milan, bringing together
contributors from academia, industry, and open-source
communities. These events brought together two different kinds of
OCaml developers (with some overlap), bringing an interesting energy
to our community.
To expand local community involvement, Tarides organised OCaml hacking
meetups in [Manila] and [Chennai]. To make it easier for others to
host similar events, we curated a list of interesting hacking issues
from past [Cambridge sessions], now available on [GitHub].
As part of the Outreachy program, Tarides supported two rounds of
internships in 2024, with results published on [Discuss] and
[watch.ocaml.org]. These internships not only provided great
contributions to our ecosystem but also brought fresh insights into
the challenges faced by new users. For example, interns identified key
areas where documentation and tooling could be improved, directly
informing future updates.
Tarides also maintained its commitment to funding critical open-source
projects and maintainers. We continued funding [Robur] for their
maintenance work on MirageOS (most of those libraries are used by many
–including us– even in non-MirageOS context) and [Daniel Bünzli],
whose libraries like `cmdliner' are essential for some of our
development.
Finally, Tarides extended sponsorships to non-OCaml-specific events,
including [JFLA], [BobConf], [FSTTCS], and [Terminal Feud] (which
garnered over 100k views). These events expanded OCaml’s visibility to
new audiences and contexts, introducing the language to a broader
technical community that –we hope– will discover OCaml and enjoy using
it as much as we do.
[FUN OCaml 2024] <https://fun-ocaml.com/>
[5k+ views on YouTube]
<https://www.youtube.com/channel/UC3TI-fmhJ_g3_n9fHaXGZKA>
[ICFP 2024] <https://icfp24.sigplan.org/>
[Manila]
<https://discuss.ocaml.org/t/announcing-ocaml-manila-meetups/14300>
[Chennai]
<https://discuss.ocaml.org/t/chennai-ocaml-meetup-october-2024/15417>
[Cambridge sessions]
<https://tarides.com/blog/2023-03-22-compiler-hacking-in-cambridge-is-back/>
[GitHub] <https://github.com/tarides/compiler-hacking/wiki>
[Discuss] <https://discuss.ocaml.org/tag/outreachy>
[watch.ocaml.org] <https://watch.ocaml.org>
[Robur] <https://blog.robur.coop/articles/finances.html>
[Daniel Bünzli] <https://github.com/sponsors/dbuenzli>
[JFLA] <https://jfla.inria.fr/jfla2024.html>
[BobConf] <https://bobkonf.de/2025/en/>
[FSTTCS] <https://www.fsttcs.org.in/>
[Terminal Feud] <https://www.youtube.com/watch?v=fMy0XhFdLAE>
What’s Next?
╌╌╌╌╌╌╌╌╌╌╌╌
As we begin 2025, Tarides remains committed to making OCaml a
mainstream language. Our focus this year is to position OCaml as a
robust choice for mission-critical applications by enhancing developer
experience, ecosystem integration, and readiness for high-assurance
use cases.
We aim to build on the Dune Developer Preview to further improve
usability across all platforms, with a particular emphasis on Windows,
to make OCaml more accessible to a broader range of
developers. Simultaneously, we will ensure OCaml is ready for critical
applications in industries where reliability, performance, and
security are essential. Projects like [SpaceOS] showcase the potential
of memory- and type-safe languages for safety-critical systems. Built
on MirageOS and OCaml’s unique properties, SpaceOS is part of the
EU-funded [Orchide] project and aims to set a new standard for edge
computing in space. Additionally, SpaceOS is being launched in the US
through our spin-off [Parsimoni]. However, these needs are not limited
to Space: both the [EU Cyber Resilience Act] and the [US cybersecurity
initiatives] highlight the growing demand for type-safe,
high-assurance software to address compliance and security challenges
in sensitive domains. Tarides believes that OCaml has a decisive role
to play here in 2025!
I’d like to personally thank our sponsors and customers, especially
Jane Street, for their unwavering support over the years, and to
[Dennis Dang], our single recurring GitHub sponsor. Finally, to every
member of Tarides who worked so hard in 2024 to make all of this
happen: thank you. I’m truly lucky to be sailing with you on this
journey!
/We are looking for [sponsors on GitHub], are happy to [collaborate on
innovative projects] involving OCaml or MirageOS and offer [commercial
services] for open-source projects – including long-term support,
development of new tools, or assistance with porting projects to OCaml
5 or Windows./
[SpaceOS]
<https://tarides.com/blog/2023-07-31-ocaml-in-space-welcome-spaceos/>
[Orchide] <https://orchide.pages.upb.ro/>
[Parsimoni] <https://parsimoni.co>
[EU Cyber Resilience Act]
<https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act>
[US cybersecurity initiatives]
<https://tarides.com/blog/2024-03-07-a-time-for-change-our-response-to-the-white-house-cybersecurity-press-release/>
[Dennis Dang] <https://github.com/dangdennis>
[sponsors on GitHub] <https://github.com/sponsors/tarides>
[collaborate on innovative projects] <https://tarides.com/innovation/>
[commercial services] <https://tarides.com/services/>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Using `clang-cl' With OCaml 5]
• [Florian’s compiler weekly, 13 January 2025]
• [OCaml 5.3: Features and Fixes!]
• [Git, Carton and emails]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Using `clang-cl' With OCaml 5]
<https://tarides.com/blog/2025-01-15-using-clang-cl-with-ocaml-5>
[Florian’s compiler weekly, 13 January 2025]
<https://gallium.inria.fr/blog/florian-cw-2025-01-13>
[OCaml 5.3: Features and Fixes!]
<https://tarides.com/blog/2025-01-09-ocaml-5-3-features-and-fixes>
[Git, Carton and emails]
<https://blog.robur.coop/articles/2025-01-07-carton-and-cachet.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 92594 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-01-14 8:20 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-01-14 8:20 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 21614 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 07 to 14,
2025.
Table of Contents
─────────────────
On concurrency models
OCaml 5.3.0 released
dream-html and pure-html 3.9.5
Building an OCaml cross compiler with OCaml 5.3
Ppx deriving decoders
Ortac 0.5.0 testing higher order functions
Other OCaml News
Old CWN
On concurrency models
═════════════════════
Archive: <https://discuss.ocaml.org/t/on-concurrency-models/15899/24>
Deep in this thread, Calascibetta Romain announced
──────────────────────────────────────────────────
For those interested, we've spent some time writing [a book] on how to
use Miou and asynchronous programming with Miou — basically, it
introduces Miou's design. In addition, resources that may be of
interest are:
• [a retrospective] of a handheld scheduler implementation compared to
what Miou offers
• [a manifesto] that says the same thing as what I said above
A next release of Miou is in preparation and additions to this ‘little
book’ will be made. In particular, there will be an explanation of how
we implemented [happy-eyeballs], which remains a good example.
[a book] <https://robur-coop.github.io/miou/introduction.html>
[a retrospective] <https://robur-coop.github.io/miou/retrospective.html>
[a manifesto] <https://robur-coop.github.io/miou/manifesto.html>
[happy-eyeballs] <https://github.com/robur-coop/happy-eyeballs>
OCaml 5.3.0 released
════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-5-3-0-released/15916/1>
octachron announced
───────────────────
We have the pleasure of announcing the release of OCaml version
5.3.0. dedicated to the memory of John William Mauchly and Paul
Verlaine on the anniversary of their death.
De la musique avant toute chose,
Et pour cela préfère l’Impair
(Music first and foremost of all!
Choose your measure of odd not even)
Some of the highlights in OCaml 5.3.0 are:
• Syntax for deep effect handlers
There is now a dedicated syntax for installing deep effect handler
┌────
│ match f () with
│ | x -> x
│ | effect Random_float, k -> Effect.Deep.continue k (Random.float 1.0)
└────
This new syntax adds a new `effect' keyword, which may break
existing code. To improve backward compatibility, this new keyword
can be disabled with the new `-keywords' flags if needed for
backward compatibility.
• Restored MSVC port
It is now possible to use the MSVC toolchain on Windows, restoring
the last missing port from OCaml 4 (except for the native compiler
support for 32-bit architectures which is not planned)
• Re-introduced statistical memory profiling (statmemprof)
The submodule `Gc.memprof' is restored with a slightly different
API. This submodule can be used to monitor memory allocation
statistics inside a program. In OCaml 5, each domain can be
monitored independently while child domains inherit the parent
domain profiling profile (if there is one active).
• utf-8 encoded Unicode source files and modest support of Unicode
identifiers
┌────
│ type saison = Hiver | Été | Printemps | Automne
└────
The OCaml lexer has been extended to support a modest subset of
Unicode characters in identifiers. This is mostly intended for
pedagogical use. This extended support requires source files to be
utf-8 encoded Unicode text.
• More space-efficient implementation of Dynarray
The internal implementation of `Dynarray' now uses an unboxed
representation which avoids the need of storing items wrapped in a
`Some x' block and thus save some spaces and indirections.
• Improved metadata on the pairs of declarations and definitions for
merlin.
The metadata stored inside cmt files has been improved to better
distinguish the provenance of identifiers (previous versions could
confuse an interface and implementation identifier). Similarly, the
metadata now tracks more precisely the association between
declarations and definitions. For instance, in
┌────
│ module X = struct let x = 0 end
│ module M: sig
│ val x: int
│ end = struct
│ let x = 1
│ include X
│ end
└────
Merlin can now determine that the definition of the `M.x' value lies
inside the module `X'.
And a lot of incremental changes:
• Around 20 new functions in the standard library (in the `Domain',
`Dynarray', `Format', `List', `Queue', `Sys', and `Uchar' modules).
• Many fixes and improvements in the runtime
• Improved error messages for first-class modules, functors, labelled
arguments, and type clashes.
• Numerous bug fixes
Please report any unexpected behaviours on the [OCaml issue tracker].
The full list of changes can be found in the changelog below.
/editor note: please visit
<https://discuss.ocaml.org/t/ocaml-5-3-0-released/15916> for the
changelog/
Happy hacking, Florian Angeletti for the OCaml team.
[OCaml issue tracker] <https://github.com/ocaml/ocaml/issues>
dream-html and pure-html 3.9.5
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-9-5/15917/1>
Yawar Amin announced
────────────────────
Happy to announce that dream-html and pure-html 3.9.5 are now
available on opam. This is a significant release with three main new
things:
1. Type-safe paths and routing
2. Support for static asset caching
3. HTML improvements
Type-safe paths and routing
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Allows defining paths as values that can be handled by a router and
_also_ rendered by the HTML markup generator, so that the actual
routed paths are in sync with the rendered paths in the
application. These paths use OCaml's built-in format strings rather
than a new DSL: eg `/orders/%s/versions/%d'. This makes it possible to
extract type-safe values from path segments and pass them to the
handler; render markup with guaranteed correct paths; and refactor the
app's paths without having to hunt for hard-coded strings.
See [the docs] for details.
[the docs]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/#type-safe-routing>
Static assets support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Automates the handling of static assets in the application so that
they can easily be served by the router with an immutable cache policy
and their paths can be rendered in markup with a content-based
revision hash, for easy cache-busting.
Added a new CLI tool `dreamwork' which helps with scaffolding this
static assets setup. The intention is to use it for more scaffolding
tasks in the future–stay tuned.
See [the docs] for details, and [this screen recording] for a short
demo.
[the docs]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/#dreamwork>
[this screen recording]
<https://x.com/yawaramin/status/1873091198380065132>
HTML improvements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Thanks to [RezwanArefin01] for prettifying the generated HTML. It is
now formatted and much easier to read. See the [snapshots] for some
examples.
Lastly, added `HTML.as_' which is the [as attribute].
Enjoy!
[RezwanArefin01] <https://github.com/RezwanArefin01>
[snapshots]
<https://github.com/yawaramin/dream-html/blob/e2a66cc199a28fd3d4a5440a124c90f578b8ae90/test/pure_html_test.expected.txt>
[as attribute]
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#as>
Building an OCaml cross compiler with OCaml 5.3
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/building-an-ocaml-cross-compiler-with-ocaml-5-3/15918/1>
shym announced
──────────────
A cross compiler is a compiler that runs on some _host_ machine, for
instance one running Linux on a 64-bit ARM processor, and generates
code for a different _target_ machine, for instance one running
Windows with a 64-bit x86 processor. Building OCaml cross compilers
used to be quite tricky and hackish but many incremental changes to
the build system over the last years have improved radically the
situation. So much so that, with the most recent changes ([1], [2]) in
the development branch of the compiler, it should be possible to build
many cross compilers without extra changes :crossed_fingers:
This is all well and good, you might say, but you would rather play
with the brand new [5.3] instead of a development branch! So I’ve
backported the necessary changes to 5.3.
[1] <https://github.com/ocaml/ocaml/pull/13526>
[2] <https://github.com/ocaml/ocaml/pull/13674>
[5.3] <https://discuss.ocaml.org/t/ocaml-5-3-0-released/15916>
How to build and use a OCaml 5.3 cross compiler
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
To make it easy to test, I’ve written an example OPAM file that can be
customised to suit your goal. It takes the example of building a cross
compiler to 64-bit x86 Windows MinGW, in particular because that
always reveals unexpected issues :-)
1. Start by creating a 5.3.0 OPAM switch if you haven’t already.
2. Choose the target you want to create a cross compiler for and find
its [target triplet]. The GCC C cross compilers and the GNU cross
binutils use target triplets as prefixes for the commands, so an
easy way to find your triplet is to install the tools. So:
3. Install the C cross compiler and toolchain for your target. Many
Linux distributions package some cross compilers. For instance,
the [CI tests for cross compilers] installs on Ubuntu:
• the `gcc-mingw-w64-x86-64' package (which depends on the
matching binutils) to cross compile to 64-bit x86 Windows MinGW;
in that case, that target machine is identified by the
`x86_64-w64-mingw32' triplet, so it calls `configure' with the
argument `--target=x86_64-w64-mingw32',
• the `gcc-aarch64-linux-gnu' package to cross compile to 64-bit
arm Linux; in that case, the target machine is identified by the
`aarch64-linux-gnu' triplet.
4. Create a new OPAM package interactively for instance by choosing
the name of the package (`ocaml-xyz' or even `ocaml-cross-xyz' are
good choices I’d say; my [example] uses `ocaml-cross-windows', for
instance) and run:
┌────
│ opam pin add --edit ocaml-cross-xyz -
└────
This will open an editor so that you can fill in the instructions
on how to build your cross compiler. Use my [example] to get you
started. In particular you’ll want to configure the `--target'
parameter with the triplet for your target (that could be the only
change!). If your toolchain and C compiler use that triplet as a
prefix for all the commands, `configure' will find them
automatically. Otherwise you’ll need to explicitly set them, by
adding arguments such as `CC=...' to `configure'. The [CI tests
for cross compilers] contains such an example to cross compile to
Android where `CC', `AR', `PARTIALLD', `RANLIB' and `STRIP' are
explicitly set… In other words, I suggest to experiment first with
an example with automatic configuration!
You should now have a cross compiler! Let’s use it on a simple sanity
check `test.ml':
┌────
│ (* Is the proper (target) OS identified? *)
│ let _ =
│ Printf.printf "Version: %s\nOS: %s\nUnix: %b\nWin: %b\nCygwin: %b\n"
│ Sys.ocaml_version Sys.os_type Sys.unix Sys.win32 Sys.cygwin
│
│ (* Do the compiler libs work? *)
│ (* The interface for [Arch] is not the same across processor architectures, the
│ following assumes your target is 64-bit x86 *)
│ let _ =
│ Printf.printf "allow_unaligned_access = %b\n" Arch.allow_unaligned_access;
│ Printf.printf "win64 = %b\n" Arch.win64
└────
The package `ocaml-cross-xyz' will install an `ocamlfind' toolchain
called `xyz'. So we can compile `test.ml' thus:
┌────
│ ocamlfind -toolchain xyz opt -package compiler-libs.optcomp -linkpkg test.ml -verbose
└────
where `-verbose' let you check what is actually being run. If your
target is Windows MinGW (so cross compiling from some unix), you
probably need an extra step before this compilation can go through:
the tool `flexlink.exe' which is used to link the final Windows binary
has been built as part of the package but `ocamlopt' will expect to
find a command `flexlink' (note in particular the absence of `.exe')
so I suggest to `ln -s' the `flexlink' binary somewhere in your
`PATH'. For instance, it could be:
┌────
│ ln -s "$(opam show --list-files ocaml-cross-xyz | grep flexlink.opt.exe)" ~/bin/flexlink
└────
and then you will be able to run the `ocamlfind -toolchain ...'
command to compile your program.
[target triplet]
<https://www.gnu.org/software/autoconf/manual/autoconf-2.71/html_node/Specifying-Target-Triplets.html>
[CI tests for cross compilers]
<https://github.com/ocaml/ocaml/blob/trunk/.github/workflows/build-cross.yml>
[example]
<https://gist.github.com/shym/44da1daaefe11c74e6c4363b14ae7ee0#file-ocaml-cross-windows-opam>
Gotchas and details
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
1. Beware that having a `flexlink' command in `PATH' breaks OCaml
(5.3 and before)’s `configure' if you’re not on Windows; this will
be fixed in 5.4.
2. The [example] OPAM package contains SHA256 sums for `.patch' files
generated on the fly from the corresponding commits but they might
change without notice (to add an extra digit to the SHA1 they
contain, for instance). If you notice that, ping me so that I can
update the SHA256 sums in the gist.
3. The [example] OPAM package pulls the official OCaml 5.3.0 archive
along with two patches:
• the first one is a large commit that squashes all the commits
that I backported from upstream,
• the second one is a small commit that adds the generation of the
`ocamlfind' toolchain configuration.
You can find the detailed backport on my [`5.3+ocross'] branch and
its [comparison] with the official release. The squashed commit
lives on its [own branch].
[example]
<https://gist.github.com/shym/44da1daaefe11c74e6c4363b14ae7ee0#file-ocaml-cross-windows-opam>
[`5.3+ocross'] <https://github.com/shym/ocaml/tree/5.3+ocross/>
[comparison]
<https://github.com/ocaml/ocaml/compare/5.3.0...shym:ocaml:5.3+ocross>
[own branch] <https://github.com/shym/ocaml/tree/5.3.0+ocross-squashed/>
Ppx deriving decoders
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-deriving-decoders/15921/1>
Ben Bellick announced
─────────────────────
A little late but wanted to share a package I have released!
For those familiar with the excellent [ocaml-decoders] package, I have
written [ppx_deriving_decoders] to automatically generate the
corresponding decoders (and encoders) based off of type definitions.
In my view, this gives the best of both worlds in terms of:
1. automatically generating (e.g. JSON) serialization and
deserialization based off of a type definition, and
2. having a readable and expressive language for handwriting encoders
and decoders when necessary by using combinators.
The instructions in the README demonstrate how you can use the
generated decoder as a base point from which to hand tweak and get
your own custom decoder.
Please let me know if you find it useful or have any feedback. Thanks!
[ocaml-decoders] <https://github.com/mattjbray/ocaml-decoders>
[ppx_deriving_decoders]
<http://github.com/benbellick/ppx_deriving_decoders>
Ortac 0.5.0 testing higher order functions
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ortac-0-5-0-testing-higher-order-functions/15945/1>
Nicolas Osborne announced
─────────────────────────
Hi everyone!
I'm very pleased to announce the release of the Ortac-0.5.0 packages
for specification-driven testing!
Ortac/QCheck-STM is a test generator based on the [QCheck-STM]
model-based testing framework and the [Gospel] specification language
for OCaml.
This new release brings three new features.
In the effort to increase the coverage of the generated tests and
thanks to Jan Midtgaard, we now support testing higher order
functions. Thanks Jan!
It is also now possible to test a module exposed as a sub-module by
Dune, specifying the module's prefix in a CLI optional argument. A
feature that we've been asked to add.
And to test an actual sub-module defined inside an OCaml file,
specifying the sub-module in a CLI optional argument as well.
Ortac/Dune generates the Dune boilerplate for you. It has been updated
to support the two new optional arguments.
You can install those packages via opam:
┌────
│ $ opam install ortac-qcheck-stm ortac-dune
└────
Then you write some Gospel specifications in your library's interface
file `foo.mli':
┌────
│ type 'a t
│ (*@ mutable model contents : 'a sequence *)
│
│ val make : int -> 'a -> 'a t
│ (*@ t = make i a
│ ensures t.contents = Sequence.init i (fun _ -> a) *)
│
│ val for_all : ('a -> bool) -> 'a t -> bool
│ (*@ b = for_all p t
│ ensures b = Sequence.fold_left (fun acc a -> acc && p a) true t.contents *)
└────
Then a simple configuration file `foo_config.ml':
┌────
│ type sut = char t
│
│ let init_sut = make 42 'a'
└────
And you can generate some specification-driven model-based tests for
your library just by running:
┌────
│ $ ortac qcheck-stm foo.mli foo_config.ml
└────
If you want to integrate the generation and the running of the tests
to your dune setup (which is highly recommended), just add the
following stanza to your dune file in your test directory:
┌────
│ (rule
│ (alias runtest)
│ (mode promote)
│ (action
│ (with-stdout-to
│ dune.inc
│ (run ortac dune qcheck-stm foo.mli))))
│
│ (include dune.inc)
└────
You'll find more information in the [Ortac/QCheck-STM documentation],
the [Ortac/Dune README] and the [`examples' folder]. I'm also happy to
answer questions.
Happy testing!
[QCheck-STM] <https://github.com/ocaml-multicore/multicoretests>
[Gospel] <https://github.com/ocaml-gospel/gospel>
[Ortac/QCheck-STM documentation]
<https://ocaml-gospel.github.io/ortac/ortac-qcheck-stm/index.html>
[Ortac/Dune README]
<https://github.com/ocaml-gospel/ortac/blob/main/plugins/dune-rules/README.md>
[`examples' folder]
<https://github.com/ocaml-gospel/ortac/tree/main/examples>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The Most Elegant Configuration Language]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The Most Elegant Configuration Language]
<https://chshersh.com/blog/2025-01-06-the-most-elegant-configuration-language.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 37089 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2025-01-07 17:26 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2025-01-07 17:26 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 13769 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 31, 2024
to January 07, 2025.
Table of Contents
─────────────────
Playing with Windows on ARM64
Opam repository archival, Phase 1: unavailable packages
CCL: Categorical Configuration Language
Dune dev meeting
"Cram tests: a hidden gem of dune" and "Snapshot tests for your own ppx"
Other OCaml News
Old CWN
Playing with Windows on ARM64
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/playing-with-windows-on-arm64/15875/1>
David Allsopp announced
───────────────────────
Following on from the teaser in
<https://discuss.ocaml.org/t/arm-windows-installation-as-of-today/15697/4>,
if you're lucky enough to have an ARM64 Windows machine, it's just
about possible to get a few opam packages installed and working it!
You'll need Visual Studio 2022 (Community) with the following
packages:
• `MSVC v143 - VS 2022 C++ ARM64/ARM64EC build tools (Latest)'
• `MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)'
• `C++/CLI support for v143 build tools (Latest)'
• `C++ Clang Compiler for Windows (18.1.8)'
_That's not a typo_: you need Clang _and_ *both* the x64/x86 and ARM64
MSVC packages
Install Git for Windows as normal (`winget install Git.Git', etc.) and
[Cygwin] (adding the `make' and `patch' packages - no compilers or
libraries needed, it's just to get the shell).
Clone [my opam fork] and check out branch [windows-on-arm64]. From a
Cygwin bash terminal, `cd' to that clone and run `make cold'. After a
little while, that should leave an ARM64 `opam.exe' in the current
directory which should be copied to a location which you then add to
`PATH'.
From Cmd/PowerShell, you can now run:
┌────
│ PS > opam init --bare
│ PS > opam switch create --empty windows-on-arm64
│ PS > opam pin add --yes ocaml-variants git+https://github.com/dra27/ocaml.git#windows-on-arm64
└────
Dune needs a trivial pin (which I think may be more to do with a
recent Windows SDK issue, than arm64-specific):
┌────
│ PS > opam pin add dune git+https://github.com/dra27/dune.git#windows-on-arm64
└────
Unfortunately, it's not quite enough to get opam's dependencies
installing through opam (`dose3' failed for me, which is odd because
it works with `make cold' and `topkg' was freezing, although that's
less surprising). But it's kinda cool how much is working
straightaway, and it certainly looks like we'll have native Windows
ARM64 support at some point in the future, therefore!
Aside from the usual "packages which don't work properly" issue,
there're two glaring problems:
1. It should be possible to install the x86 / x64 compilers, but at
present this doesn't work because the opam compiler packages need
further tweaking[^1]
2. Only Clang-pretending-to-be-`cl' is supported at the moment - I
can't see any reason that Clang-pretending-to-be-`gcc' shouldn't be
doable, but as we don't presently support that for x64 either (and
it necessarily needs MSYS2, rather than Cygwin), I haven't
disappeared down that rabbit hole yet[^2]
:warning: I have no timeline for upstreaming any of this, but it's all
publicly pushed and welcome to anyone to extend to a mergeable state!
[^1]: I'll likely get to that at some point soon, as that unblocks
general use of OCaml on Windows ARM64 machines, even if not _native_
ARM64 use. However, it exceeds "fun messing around over Christmas and
New Year"!
[^2]: See 1…
[Cygwin] <https://cygwin.com>
[my opam fork] <https://github.com/dra27/opam.git>
[windows-on-arm64]
<https://github.com/dra27/opam/commits/windows-on-arm64>
Opam repository archival, Phase 1: unavailable packages
═══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-archival-phase-1-unavailable-packages/15797/7>
Continuing this thread, Hannes Mehnert announced
────────────────────────────────────────────────
It's done. It's done. It's done.
Happy new year!
We just merged the removal of the above mentioned uninstallable
packages from opam-repository. In case you want to get these old opam
files, please use:
┌────
│ opam repository add opam-archive https://github.com/ocaml/opam-repository-archive.git
└────
Each of the opam files now include the two additional fields: (a) a
x-reason-for-archival and (b) an
x-opam-repository-commit-hash-at-time-of-archiving (as described in
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process>).
We also pushed the tag '2025-01-before-archiving-phase1' to the main
opam-repository.
Statistics of opam files and unique packages
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
date (January 1st) opam files unique packages
─────────────────────────────────────────────────
phase1 28863 4805
2025 33033 4973
2024 29942 4572
2023 25983 4126
2022 21418 3647
2021 16632 3156
2020 12998 2554
2019 10236 2192
2018 8110 1878
2017 5966 1458
2016 4308 1086
2015 3081 823
2014 1856 593
2013 485 486
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This shows that the amount of opam files are now back to mid-2023,
while in the unique packages we're in mid-2024.
Next steps
╌╌╌╌╌╌╌╌╌╌
Next steps and call to action:
• by January 15th we'll have a list of packages that require OCaml <
4.08 (plus those packages that were marked unavailable between
December 15th and January 15th)
• please mark your packages with [`x-maintenance-intent'] or `flags:
deprecated'
On February 15th we will propose a list of packages that are
deprecated or do not fall into the `x-maintenance-intent' - but only
if there's no reverse dependency that requires them: if the package
"cohttp" is marked with `x-maintenance-intent: "(latest)"', and some
other package "bar" requires a specific cohttp version ('depends:
"cohttp" {= "1.2.3"}'), the "cohttp.1.2.3" will be kept (to avoid
making "bar" uninstallable).
We plan to have tooling ready that allows to spot which packages would
be beneficial to have a `x-maintenance-intent' or `flags: deprecated'
(i.e. which ones would allow to archive more packages).
What is the difference between `flags: deprecated' and
`x-maintenance-intent'? Please use `flags: deprecated' if either
specific versions or an entire package should be archived. Please use
`x-maintenance-intent' for packages that are actively developed.
If you have any further questions, please don't hesitate to ask.
[`x-maintenance-intent']
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process>
CCL: Categorical Configuration Language
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ccl-categorical-configuration-language/15901/1>
Dmitrii Kovanikov announced
───────────────────────────
Hi everyone :wave:
For the last month, I've been working on a hobby project, shaping
years of my ideas into the implementation of minimalistic config
language *ccl: Categorical Configuration Language*.
You can read the motivation and a tutorial in my latest article:
• [chshersh.com: The Most Elegant Configuration Language]
I implemented CCL in OCaml using `angstrom'. The source code is here:
• <https://github.com/chshersh/ccl>
[chshersh.com: The Most Elegant Configuration Language]
<https://chshersh.com/blog/2025-01-06-the-most-elegant-configuration-language.html>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/20>
Etienne Marais announced
────────────────────────
Hi :wave:
We will hold our first Dune dev meeting of 2025 (Happy New Year
:partying_face:) on *Wednesday, January, 8th at 9:00* CET. As usual,
the session will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize between the Dune developers !
:camel:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-01-08>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
• Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
"Cram tests: a hidden gem of dune" and "Snapshot tests for your own ppx"
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cram-tests-a-hidden-gem-of-dune-and-snapshot-tests-for-your-own-ppx/15910/1>
David Sancho announced
──────────────────────
Hi, I wrote 2 blog posts about cram tests and It's a good idea to
share them together.
Cram tests: a hidden gem of dune
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I'm a strong advocate of unit tests, I can confidently say that it has
saved me from introducing regressions countless times. Today I want to
share one of the hidden gems of OCaml and their testing story with
dune, cram tests.
<https://sancho.dev/blog/cram-tests-a-hidden-gem-of-dune>
Snapshot tests for your own ppx
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
When building preprocessor extensions (ppx) in OCaml, testing is
crucial. You want to ensure your ppx works correctly and continues to
work as you make changes. After experimenting with different
approaches, I've found that cram tests fit well for the task.
<https://sancho.dev/blog/snapshot-tests-for-your-own-ppx>
Let me know what you think, and if there's a need for more :smiley:
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [What Happened in 2024?]
• [Build A CLI in OCaml with the Cmdliner Library]
[the ocaml.org blog] <https://ocaml.org/blog/>
[What Happened in 2024?]
<https://soap.coffee/~lthms/posts/December2024.html>
[Build A CLI in OCaml with the Cmdliner Library]
<https://debajyatidey.hashnode.dev/build-a-cli-in-ocaml-with-the-cmdliner-library>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 25042 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-12-31 8:03 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-12-31 8:03 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 7810 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 24 to 31,
2024.
Table of Contents
─────────────────
Using Property-Based Testing to Test OCaml 5
First release of elm_playground
First release of flatunionfind
Serving This Article from RAM with Dream for Fun and No Real Benefit
Other OCaml News
Old CWN
Using Property-Based Testing to Test OCaml 5
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-using-property-based-testing-to-test-ocaml-5/14550/2>
Jan Midtgaard announced
───────────────────────
I've written up part 2 on our effort to utilize property-based testing
to stress test the OCaml 5 run time system. Happy Christmas reading!
🎄🎅 🎁 😄
<https://tarides.com/blog/2024-12-23-multicore-property-based-tests-for-ocaml-5-challenges-and-lessons-learned/>
First release of elm_playground
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-elm-playground/15838/1>
Yoann Padioleau announced
─────────────────────────
It is my pleasure to announce the first release of `elm_playground',
an OCaml package that allows you to easily create /pictures/,
/animations/, and even /video games/ in a portable way using an API
that really simplifies how to view the computer and its devices (the
screen, keyboard, and mouse). The library offers a native backend to
run the games from a terminal and a web backend to run the games in
your browser.
This is a port of the excellent Elm playground package
<https://github.com/evancz/elm-playground> to OCaml.
You can install it via OPAM via `opam install elm_playground'.
Here are a few examples of code using the library.
First a "picture" app:
┌────
│ (* from https://elm-lang.org/examples/picture *)
│ open Playground
│
│ let app =
│ picture [
│ rectangle brown 40. 200.
│ |> move_down 80.;
│ circle green 100.
│ |> move_up 100.;
│ ]
│
│ let main = Playground_platform.run_app app
└────
<https://global.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/7/76fc1990fe116911097764df986f64fed41c28a4_2_470x500.png>
Then an "animation" app:
┌────
│ (* from https://elm-lang.org/examples/animation *)
│ open Playground
│
│ let view time = [
│ octagon darkGray 36.
│ |> move_left 100.
│ |> rotate (spin 3. time);
│ octagon darkGray 36.
│ |> move_right 100.
│ |> rotate (spin 3. time);
│ rectangle red 300. 80.
│ |> move_up (wave 50. 54. 2. time)
│ |> rotate (zigzag (-. 2.) 2. 8. time);
│ ]
│
│ let app =
│ animation view
│
│ let main = Playground_platform.run_app app
└────
<https://global.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/e/e91563cbb6a0863570bbb19b057f5e8dae7164bf_2_470x500.png>
And finally a "game" app:
┌────
│ (* from https://elm-lang.org/examples/mouse *)
│ open Playground
│
│ let view _computer (x, y) = [
│ square blue 40.
│ |> move x y
│ ]
│
│ let update computer (x, y) =
│ (x +. to_x computer.keyboard, y +. to_y computer.keyboard)
│
│ let app =
│ game view update (0., 0.)
│
│ let main = Playground_platform.run_app app
└────
<https://global.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/2/24e8ffe672cda66c6a49e02013347cda0640f771_2_470x500.png>
Note that you can write more complex games. For example here is a
screenshot of a toy tetris app:
<https://global.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/4ded1d55c9994935c5ec3786ae549ba3a71b8eb6.png>
For more information, follow the README at
<https://github.com/aryx/ocaml-elm-playground>
And merry christmas!
First release of flatunionfind
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-flatunionfind/15847/1>
François Pottier announced
──────────────────────────
I am pleased to announce the first release of `flatunionfind', a small
library that offers a union-find data structure, stored inside a
vector.
This library is an alternative to my existing library `unionFind', and
could be faster or slower, depending on your use case.
┌────
│ opam update
│ opam install flatunionfind
└────
For more information, see the [documentation].
Happy unions and finds, FP.
[documentation]
<https://cambium.inria.fr/~fpottier/flatunionfind/doc/flatunionfind/>
Serving This Article from RAM with Dream for Fun and No Real Benefit
════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/serving-this-article-from-ram-with-dream-for-fun-and-no-real-benefit/15856/1>
Thomas Letan announced
──────────────────────
I’ve been playing with my website lately, more precisely on how the
contents is delivered to the readers. Before, it was merely a boring,
static website delivered by Nginx; now it’s a Dream-powered HTTP
server with all the pages in-memory.
[I’ve written about this fun, little project], and you may find the
article interesting. It covers several topis: fun experiments with the
Dream library, HTTP arcane one cannot ignore if they want to implement
a browser-friendly server, and even some Docker because why not!
Happy holidays everyone!
[I’ve written about this fun, little project]
<https://soap.coffee/~lthms/posts/DreamWebsite.html>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Serving This Article from RAM with Dream for Fun and No Real
Benefit]
• [Multicore Property-Based Tests for OCaml 5: Challenges and Lessons
Learned]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Serving This Article from RAM with Dream for Fun and No Real Benefit]
<https://soap.coffee/~lthms/posts/DreamWebsite.html>
[Multicore Property-Based Tests for OCaml 5: Challenges and Lessons
Learned]
<https://tarides.com/blog/2024-12-23-multicore-property-based-tests-for-ocaml-5-challenges-and-lessons-learned>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 20364 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-12-24 8:55 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-12-24 8:55 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 21280 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 17 to 24,
2024.
Table of Contents
─────────────────
dream-html and pure-html
Dune 3.17
First release candidate of OCaml 5.3.0
Pragmatic Category Theory | Part 3: Associativity
ocaml-stk, xtmpl, stog, ocaml-css, ocaml-ldp, higlo and chamo
MirageOS on OCaml 5
Dune dev meeting
Other OCaml News
Old CWN
dream-html and pure-html
════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/14808/6>
Yawar Amin announced
────────────────────
[ANN] dream-html 3.8.0
Happy to announce some added power to the form decoding
functionality. Three main things:
1. Added [Dream_html.form] and [query] helper functions to wrap
extracting the data directly from the Dream request and decoding it
correspondingly from the body or query.
2. Added the (monadic) chaining operator [Dream_html.Form.( let* )]
and [ok] and [error] helpers to allow sophisticated sequential
decoding where decoding of some fields depend on others.
3. Added optional parameters to constrain [typed decoding] of values
eg `int ~min:0' will succeed the decode if the value is an integer
_and_ at least 0. Also added [unix_tm] type decoder to decode
timestamps into `Unix.tm' structs (not timezone-aware).
The last [example] on the page shows a fairly sophisticated form
decoder which requires an `id' field and _one or more of_ the fields
`days', `weeks', `months', and `years', and fails if at least one is
not provided.
Enjoy :slight_smile:
[Dream_html.form]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/#val-form>
[query]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/#val-query>
[Dream_html.Form.( let* )]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#val-let*>
[ok]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#val-ok>
[error]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#val-error>
[typed decoding]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#basic-type-decoders>
[unix_tm]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#val-unix_tm>
[example]
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html#examples>
Dune 3.17
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-17/15770/4>
Etienne Marais announced
────────────────────────
The Dune team is happy to announce the release of Dune `3.17.1'!
:camel:
This patch release includes some bug fixes. To reduce computing time,
it does not build `.cmxs' files anymore when the `(no_dynlink)' stanza
is used. This change also corrects the semantic of the `(no_dynlink)'
stanza which was building `.cmxs' files even if it did not install
them. Now, it does not build nor install them.
If you encounter a problem with this release, you can report it on the
[ocaml/dune] repository.
[ocaml/dune] <https://github.com/ocaml/dune/issues>
Changelog
╌╌╌╌╌╌╌╌╌
◊ Fixed
• When a library declares `(no_dynlink)', then the `.cmxs' file for it
is no longer built. (#11176, @nojb)
• Fix bug that could result in corrupted file copies by Dune, for
example when using the `copy_files#' stanza or the `copy#'
action. (@nojb, #11194, fixes #11193)
• Remove useless error message when running `$ dune subst' in empty
projects. (@rgrinberg, #11204, fixes #11200)
First release candidate of OCaml 5.3.0
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-release-candidate-of-ocaml-5-3-0/15815/1>
octachron announced
───────────────────
The release of OCaml 5.3.0 is imminent.
As a final step, we are publishing a release candidate to check that
everything is in order before the release in the upcoming week(s).
If you find any bugs, please report them on [OCaml's issue tracker].
Compared to the second beta, this release candidate contains a
regression fix in the type system (some type expressions were not
generalized when they ought to be), one fix for the new check for
dependency order at link time, and a manual update.
The full change log for OCaml 5.3.0 is available [on GitHub]. A short
summary of the changes since the second beta release is also available
below.
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.3/Changes>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands on opam 2.1 and later:
┌────
│ opam update
│ opam switch create 5.3.0~rc1
└────
The source code for the release candidate is also directly available
on:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.3.0-rc1.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.3/ocaml-5.3.0~rc1.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.3.0~rc1+options <option_list>
└────
where `<option_list>' is a space-separated list of `ocaml-option-*'
packages. For instance, for a `flambda' and `no-flat-float-array'
switch:
┌────
│ opam switch create 5.3.0~rc1+flambda+nffa ocaml-variants.5.3.0~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Changes since the second beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Type system
• [#13690]: some type expressions were incorrectly not generalized
(because they were assigned to the wrong level pool)
[#13690] <https://github.com/ocaml/ocaml/issues/13690>
◊ Documentation
• [#13666]: Rewrite parts of the example code around nested lists in
Chapter 6 (Polymorphism and its limitations -> Polymorphic
recursion) giving the "depth" function [in the
non-polymorphically-recursive part of the example] a much more
sensible behavior; also fix a typo and some formatting. (Frank
Steffahn, review by Florian Angeletti)
[#13666] <https://github.com/ocaml/ocaml/issues/13666>
◊ Compiler user-interface and warnings:
• [#12084], +[#13669], +[#13673]: Check link order when creating
archive and when using ocamlopt.
[#12084] <https://github.com/ocaml/ocaml/issues/12084>
[#13669] <https://github.com/ocaml/ocaml/issues/13669>
[#13673] <https://github.com/ocaml/ocaml/issues/13673>
Pragmatic Category Theory | Part 3: Associativity
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/pragmatic-category-theory-part-3-associativity/15819/1>
Dmitrii Kovanikov announced
───────────────────────────
Hi everyone! :wave:
I've finished writing the third part of my *Pragmatic Category Theory*
series (some code examples are in OCaml):
• [Part 3: Associativity]
Previous discussion:
• <https://discuss.ocaml.org/t/new-part-pragmatic-category-theory-part-2-published/15056>
P.S. I would've edited the previous topic instead of creating a new
one but looks like I haven't touched it for a while, so I can't edit
the title and the body anymore.
[Part 3: Associativity]
<https://chshersh.com/blog/2024-12-20-pragmatic-category-theory-part-03.html>
ocaml-stk, xtmpl, stog, ocaml-css, ocaml-ldp, higlo and chamo
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-stk-xtmpl-stog-ocaml-css-ocaml-ldp-higlo-and-chamo/15820/1>
Zoggy announced
───────────────
Hello,
I made new releases for some libraries and tools. All are available in
opam.
[OCaml-stk] 0.4.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
OCaml-stk is a library to build graphical user interfaces, based on
SDL2. This release includes two new widgets:
• a [layers] widget, allowing to display widgets in… layers,
• a xmlview widget (in [stk_xml] package), allowing to display XML
(and so XHTML) documents, handling CSS for styling and layout. The
programmer can customize which widgets are created for each XML
node, and add event handlers on each node. See the "xmlview" example
included in sources.
This new release also comes with an [inspection window] for easier
debugging.
Complete list of changes is [here].
[OCaml-stk] <https://zoggy.frama.io/ocaml-stk/>
[layers]
<https://zoggy.frama.io/ocaml-stk/refdoc/stk/Stk/Layers/class-layers/index.html>
[stk_xml] <https://zoggy.frama.io/ocaml-stk/refdoc/stk_xml/index.html>
[inspection window] <https://zoggy.frama.io/ocaml-stk/doc-inspect.html>
[here] <https://zoggy.frama.io/ocaml-stk/posts/release-0.4.0.html>
[Xtmpl] 1.0.0
╌╌╌╌╌╌╌╌╌╌╌╌╌
Xtmpl is a library to build, read and parse XML document. It provides
a [rewriting engine] and [templating facilities]. This new release
includes a big refactoring, using functors. This creates some
incompatibilities with prior versions. See [here] for changes.
[Xtmpl] <https://www.good-eris.net/xtmpl/>
[rewriting engine]
<https://www.good-eris.net/xtmpl/refdoc/xtmpl/Xtmpl/Rewrite/index.html>
[templating facilities] <https://www.good-eris.net/xtmpl/doc.html>
[here] <https://www.good-eris.net/xtmpl/posts/release-1.0.0.html>
[Stog] 1.1.0
╌╌╌╌╌╌╌╌╌╌╌╌
Stog is a static web site compiler. It is able to handle blog posts as
well as regular pages or any XML document in general. This release
upgrades to Xtmpl 1.1.0 and includes small fixes (see [here] for
details).
[Stog] <https://www.good-eris.net/>
[here] <https://www.good-eris.net/stog/posts/release-1.1.0.html>
[OCaml-css] 0.3.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
OCaml-css is an OCaml library to parse and print CSS. It can also
expand namespaces and perform computations on property values. Parser
can be extended by defining additional properties.
This release includes various parsing fixes and adds new CSS
properties: `border-collapse', `border-spacing', and `opacity'. The
complete list of changes is [here].
[OCaml-css] <https://zoggy.frama.io/ocaml-css/>
[here] <https://framagit.org/zoggy/ocaml-css/-/blob/master/Changes>
[OCaml-ldp] 0.4.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This is a library to build [LDP] (Linked Data Platform) and [SOLID]
applications, runnable either in standalone program (using packages
`ldp_tls' or `ldp_curl') or in the browser (using package `ldp_js'
with js_of_ocaml).
This release includes only one fix in [`Ldp.Http'] module: when
following redirection, resolve IRI in Location field of response
against original IRI.
[OCaml-ldp] <https://zoggy.frama.io/ocaml-ldp/>
[LDP] <http://www.w3.org/TR/ldp/>
[SOLID] <https://solidproject.org/>
[`Ldp.Http']
<https://zoggy.frama.io/ocaml-ldp/refdoc/ldp/Ldp/Http/module-type-Http/index.html>
[Higlo] 0.10.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Higlo is an OCaml library for syntax highlighting. This release adds a
simple commonmark lexer.
[Higlo] <https://zoggy.frama.io/higlo/>
[Chamo] 4.2.0
╌╌╌╌╌╌╌╌╌╌╌╌╌
Chamo is a source code editor, even if it can be used to edit any text
file. A system of "views" allows to edit some kinds of files in
specific views. It's like an Emacs where Lisp is replaced by OCaml, as
it can be extended and customized in OCaml.
This release is just an upgrade to Stk 0.4.0 and Xtmpl 1.0.0.
[Chamo] <https://zoggy.frama.io/chamo/>
MirageOS on OCaml 5
═══════════════════
Archive: <https://discuss.ocaml.org/t/mirageos-on-ocaml-5/15822/1>
shym announced
──────────────
On behalf of all the numerous developers involved, it’s my pleasure to
announce that the MirageOS ecosystem has seen the long-running work to
port to OCaml 5 come to fruition: `ocaml-solo5' v1.0 is now using
OCaml 5.2.1!
What is `ocaml-solo5'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`ocaml-solo5' is an OCaml cross compiler for producing Solo5
unikernels. Solo5 is the basis for MirageOS unikernels when they are
not compiled as programs to run on a regular OS.
`ocaml-solo5' responds to specific unikernel constraints. In
particular it provides a placeholder for the standard C library that
is complete enough that we can build the OCaml runtime without a full
POSIX system to support it. That OCaml runtime can then be linked
statically to OCaml programs in order to produce unikernels.
These constraints require us to keep track of developments of the
OCaml compiler and particularly of its runtime. The major changes
coming with OCaml 5 have required quite a lot of work (over 1 year) to
bring our cross compiler up-to-date.
It should be noted that `ocaml-solo5' is restricted to a single domain
but it makes it possible to use the effects introduced with OCaml 5.
MirageOS & OCaml 5
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The long road to bring Mirage on OCaml 5 started with adding support
for Thread-Local Storage (TLS) in Solo5. Even if Solo5 doesn’t support
the creation of threads, the OCaml 5 runtime stores domain-specific
data, including for the first domain, in TLS. The main work was done
in [solo5#546] and [solo5#542] with fixes in [solo5#551] and
[solo5#554]. It was released with [Solo5 v0.8.0].
This foundational work on Solo5 unblocked the port of the compiler
_per se_. As the OCaml runtime changed substantially between OCaml 4.x
and 5.x, this required many changes in the minimal library, called
`nolibc', that provides simple implementations and stubs for the part
of the libc interface the runtime uses. In particular, the memory
management of the runtime is very different from OCaml 4.x (which is
natural, due to the multicore support): it uses the `mmap~/~munmap'
functions instead of `malloc~/~free'. `mmap' is a very versatile
interface, tightly tied to the virtual memory. Providing adequate
(correct but still simple) implementations of `mmap~/~munmap' in the
context of Solo5, _i.e._ without virtualisation of the memory,
required a careful review of how the interface is actually used in the
runtime.
Besides that work on `nolibc', building an OCaml compiler targeting
Solo5 also requires a few patches to the compiler build system. As
much work has been happening upstream to fix issues in building a
cross compiler, this was taken as an opportunity to write clean
patches in order to contribute them upstream and simplify the future
of OCaml/Solo5 (along with other cross-compiler projects).
All this work has been combined in [ocaml-solo5#134], which built on
and completed [ocaml-solo5#122], [ocaml-solo5#124] and
[ocaml-solo5#129]. It was released in [ocaml-solo5 v1.0.0].
Now we are eager to learn how it behaves in your applications! Note in
particular that, as already mentioned, the garbage collector is
completely different from the one in OCaml 4. For example, the [Mirage
website] currently runs the two versions, one on OCaml 4 and one on
OCaml 5 with traffic being alternatively routed to one or the other,
to monitor their behaviours. First experiments show that we must tweak
the `space_overhead' parameter to have the OCaml 5 unikernel use the
same amount of memory than the OCaml 4 one, at the price of some
compute time. This generally means that you might have to experiment a
bit if you run within very constrained memory limits.
[solo5#546] <https://github.com/Solo5/solo5/pull/546>
[solo5#542] <https://github.com/Solo5/solo5/pull/542>
[solo5#551] <https://github.com/Solo5/solo5/pull/551>
[solo5#554] <https://github.com/Solo5/solo5/pull/554>
[Solo5 v0.8.0]
<https://github.com/Solo5/solo5/blob/master/CHANGES.md#v080-2023-04-25>
[ocaml-solo5#134] <https://github.com/mirage/ocaml-solo5/pull/134>
[ocaml-solo5#122] <https://github.com/mirage/ocaml-solo5/pull/122>
[ocaml-solo5#124] <https://github.com/mirage/ocaml-solo5/pull/124>
[ocaml-solo5#129] <https://github.com/mirage/ocaml-solo5/pull/129>
[ocaml-solo5 v1.0.0]
<https://github.com/mirage/ocaml-solo5/blob/main/CHANGES.md#v100-2024-12-04>
[Mirage website] <https://mirage.io/>
How to give it a spin
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
To try the new OCaml 5, first create an OPAM switch [with OCaml
5.2.1]. Then, follow the standard procedure (see how to [install it]
and how to [build an hello-world unikernel]). After installing
`ocaml-solo5', you can check with `opam list ocaml-solo5' that it
installed the version `1.x' of the package.
[with OCaml 5.2.1]
<https://discuss.ocaml.org/t/ocaml-5-2-1-released/15634>
[install it] <https://mirage.io/docs/install>
[build an hello-world unikernel] <https://mirage.io/docs/hello-world>
People involved
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Many people got involved at some point or another, either with code or
comments, to that community effort (hopefully not forgetting anyone,
in `sort' order):
• Adam Steen
• Adrian-Ken Rueegsegger
• Christiano Haesbaert
• Fabrice Buoro
• Hannes Mehnert
• Kate
• Pierre Alain
• Romain Calascibetta
• Samuel Hym
• Sébastien Hinderer
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/19>
Etienne Marais announced
────────────────────────
Hi camelers! :camel: The next Dune meeting is supposed to be on
Wednesday, December, 25th, but since it is Christmas Day (a bank
holiday for various countries), the meeting is cancelled. Next one
will be on the January, 8th, 2025 :fireworks:
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Pragmatic Category Theory | Part 3: Associativity]
• [Learn OCaml the Easy Way - Including the Hard Bits]
• [MetAcsl v0.8 for Frama-C 30.0 Zinc]
• [Saturn 1.0: Data structures for OCaml Multicore]
• [Frama-Clang v0.0.17 for Frama-C 30.0~ Zinc]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Pragmatic Category Theory | Part 3: Associativity]
<https://chshersh.com/blog/2024-12-20-pragmatic-category-theory-part-03.html>
[Learn OCaml the Easy Way - Including the Hard Bits]
<https://tarides.com/blog/2024-12-18-learn-ocaml-the-easy-way-including-the-hard-bits>
[MetAcsl v0.8 for Frama-C 30.0 Zinc]
<https://frama-c.com/fc-plugins/metacsl.html>
[Saturn 1.0: Data structures for OCaml Multicore]
<https://tarides.com/blog/2024-12-11-saturn-1-0-data-structures-for-ocaml-multicore>
[Frama-Clang v0.0.17 for Frama-C 30.0~ Zinc]
<https://frama-c.com/fc-plugins/frama-clang.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 34090 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-12-17 13:05 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-12-17 13:05 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 13330 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 10 to 17,
2024.
Table of Contents
─────────────────
Opam repository archival, Phase 1: unavailable packages
Proposed Package Archiving Policy for the opam Repository
QCheck 0.23
OCaml's Code of Conduct team - rotation of one team member
qcheck-lin and qcheck-stm 0.2
Old CWN
Opam repository archival, Phase 1: unavailable packages
═══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-archival-phase-1-unavailable-packages/15797/1>
Hannes Mehnert announced
────────────────────────
It is my pleasure to announce below the list of opam packages that
will move to the opam-repository-archive on January 1st 2025. In total
there are 4170 opam files scheduled for being moved within 561 unique
packages. This decreases the size of the opam-repository by roughly
12.7%.
This list contains all packages (a) marked as "available: false"
(which may have various reasons: security issue, source unavailable, …
- best to look into the "git log" for the specific package for the
reason), and (b) packages which cannot be installed due to missing
dependencies (with the packages mentioned in (a) being removed).
The second list of packages (b) has been automatically generated by
the [archive-opam] utility - developed purely for the opam-repository
archival project, and this utility may have bugs.
So, if you find a package in the list and you'd like to retain it in
the opam-repository, there are some options:
• (a) you can install it on your system (opam install <pkg>): this
means there's a bug in the archive-opam utility, please provide the
package name and version in the [opam-repository-archive Phase 1
PR], together with your opam version, OCaml version, and operating
system;
• (b) it is not installable: please figure out the reasoning (the
"Reasoning" may help you to find the root issue), and try to fix it
yourself - if you're unable to fix the root cause, please also
comment in the [opam-repository-archive Phase 1 PR] with the package
name and version.
If you've any questions, please don't hesitate to ask here or on
GitHub or via another communication channel.
You can help further on the archiving process:
• as mentioned in the [last announcement] please add the
[`x-maintenance-intent'] to your packages (a good choice for a lot
of packages is `x-maintenance-intent: [("latest")]' if you're
maintaining the latest version only) - this will be considered in
Phase 3 (March 1st 2025);
• if you are the author or maintainer of a package that is no longer
useful or maintained, you can as well mark your opam files in the
opam-repository with `flags: deprecated' (this will be taken into
account in Phase 3 - March 1st 2025);
• if you flagged your preliminary releases with `flags:
avoid-version', and they can now be removed (e.g. since a stable
version has been released), please open a pull request to replace
the `avoid-version' with `deprecated'.
Please note that the next Phase will be announced on January 15th with
all packages that are only installable with OCaml < 4.08 - archiving
is scheduled for February 1st.
To keep track of the announcements, please look at the
[opam-repository] tag.
You can reproduce these lists by running `opam-archive --unavailable
--dry-run --later-installable --pkg-all' using opam-archive at
666a3b3886acfbcf82a7d73134247ccaa605510a and opam-repository at
de786e28dbea73843ad5e5f0290a4e81fba39370.
A big thanks to the [OCaml Software Foundation] for funding the
opam-repository archival project.
[archive-opam] <https://github.com/hannesm/archive-opam>
[opam-repository-archive Phase 1 PR]
<https://github.com/ocaml/opam-repository-archive/pull/3>
[last announcement]
<https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository/15713#p-67031-call-to-action-4>
[`x-maintenance-intent']
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process>
[opam-repository] <https://discuss.ocaml.org/tag/opam-repository>
[OCaml Software Foundation] <https://ocaml-sf.org>
Packages scheduled for archiving (pkg-name: pkg-version[, pkg-version]*)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
/editor note/ Please find this long list in the post itself:
<https://discuss.ocaml.org/t/opam-repository-archival-phase-1-unavailable-packages/15797>
Proposed Package Archiving Policy for the opam Repository
═════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository/15713/6>
Continuing this thread, Hannes Mehnert announced
────────────────────────────────────────────────
Hey,
just a quick update on the proposed roadmap. The changes are we don't
do `avoid-version' / `deprecated' flag cleanups in Phase 1. Instead,
we plan to remove packages with `deprecated' flag in Phase 3. Packages
with flag `avoid-version' will stay in opam-repository, but we reach
out to maintainers and authors whether their intention is to mark
these packages as deprecated (e.g. for alpha / beta releases and
release candidates).
Please find the updated roadmap below:
• December 1st 2024: announcement of this proposal
• December 15th 2024: announcement of the packages affected by Phase 1
(uninstallable packages (“available: false”, “opam admin check
–installability -i”)
• January 1st 2025: Phase 1 cutting point: packages are moved to
opam-repository-archive
• January 15th 2025: announcement of the packages affected by Phase 2
(OCaml lower bound 4.08)
• February 1st 2025: Phase 2 cutting point: packages are moved to
opam-repository-archive
• February 15th 2025: initial spring cleaning, announcement of
packages (based on maintenance-intent), and `flags: deprecated'
• March 1st 2025: spring cleaning cutting point: packages are moved to
opam-repository-archive
• Every quarter: repeat Phase 3
• Every year: reconsider Phase 2 with an increased OCaml lower bound
QCheck 0.23
═══════════
Archive: <https://discuss.ocaml.org/t/ann-qcheck-0-23/15790/1>
Jan Midtgaard announced
───────────────────────
I'm happy to announce the 0.23 release of `qcheck-core', `qcheck',
`qcheck-alcotest', and `qcheck-ounit', along with a 0.5 release of
`ppx_deriving_qcheck' :tada:
The biggest user-visible change is the addition of a [qcheck-core
overview documentation page] as well as clean-ups to the two module
pages to provide a better overview of the different available
features:
• [QCheck]
• [QCheck2]
In more detail the 0.23 release has made the following changes:
• Quote and escape in `Print.string' and `Print.char' in the `QCheck'
module, mirroring the `QCheck2.Print' module's behaviour. Also quote
and escape `Print.bytes' in both `QCheck' and `QCheck2'.
• Clean-up `QCheck' and `QCheck2' documentation pages
• Add `exponential' generator to `QCheck', `QCheck.Gen', and
`QCheck2.Gen'
• Add `Shrink.bool' and use it in `QCheck.bool'
• Remove unread `fun_gen' field from `QCheck2''s `fun_repr_tbl' type
thereby silencing a compiler warning
The `ppx_deriving_qcheck' 0.5 release contains a fix to derive
generators for mutually recursive data types involving records, thanks
to a contribution from @Kakadu
Happy testing! :smiley:
[qcheck-core overview documentation page]
<https://c-cube.github.io/qcheck/0.23/qcheck-core/index.html>
[QCheck]
<https://c-cube.github.io/qcheck/0.23/qcheck-core/QCheck/index.html>
[QCheck2]
<https://c-cube.github.io/qcheck/0.23/qcheck-core/QCheck2/index.html>
OCaml's Code of Conduct team - rotation of one team member
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocamls-code-of-conduct-team-rotation-of-one-team-member/15791/1>
Sonja Heinze announced
──────────────────────
A bit over two years ago, the OCaml community wrote and adopted a
[code of conduct] and put together a code of conduct team. The code of
conduct team is there for anyone in the community whenever they have
concerns about behavior that falls within the scope of the code of
conduct. It's currently made up of @c-cube, @Khady, @mseri, @rjbou
myself.
When putting together the code of conduct team, we mentioned that we'd
rotate the team from time to time to keep it dynamic. We're now
rotating one team member: I'm leaving the team and @shonfeder is
joining. Thanks a lot, @shonfeder, for taking on this responsibility!
Let's also use this opportunity to explain how the Code of Conduct
team operates: We generally do not step in on our own initiative, but
only when asked. That's to avoid having five community members acting
as a kind of "overarching community police". That said, we will step
in without being asked in extreme cases, but this has not happened so
far. We do moderate and/or act when people reach out to us. That does
happen from time to time.
By the way, you can adopt the Code of Conduct yourself on your OCaml
GitHub/GitLab repos by creating a `CODE_OF_CONDUCT.md`, containing the
[CODE_OF_CONDUCT_TEMPLATE] - full instructions [here]. So far, it is
already adopted on this discuss forum, the caml-list@inria.fr mailing
list, the OCaml IRC, [OCaml discord], physical events like OCaml
Workshop, and [these repositories]. Absolutely everyone is welcome to
adopt it on their OCaml repository as well. Adopting it doesn't have a
practical effect in a big majority of cases, but it always makes
contributors, particularly newcomers, feel more welcome.
Have a nice weekend everyone! Best, @pitag on behalf of the whole
Code of Conduct team
[code of conduct]
<https://github.com/ocaml/code-of-conduct/blob/main/CODE_OF_CONDUCT.md>
[CODE_OF_CONDUCT_TEMPLATE]
<https://github.com/ocaml/code-of-conduct/blob/main/CODE_OF_CONDUCT_TEMPLATE.md>
[here]
<https://github.com/ocaml/code-of-conduct?tab=readme-ov-file#adopting-this-code-of-conduct>
[OCaml discord] <https://discord.com/invite/cCYQbqN>
[these repositories]
<https://github.com/ocaml/code-of-conduct/blob/main/list-of-adopters.md>
qcheck-lin and qcheck-stm 0.2
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm-0-2/12301/4>
Jan Midtgaard announced
───────────────────────
I just rolled a 0.5 release of `qcheck-lin', `qcheck-stm', and
`qcheck-multicoretests-util':
<https://github.com/ocaml-multicore/multicoretests/releases/tag/0.5>
The biggest news in the 0.5 release is the addition of
`Util.Pp.pp_fun_' for printing function values generated with
QCheck.To ensure quoted and escaped output for chars and strings, this
required bumping the `qcheck-core' lower bound to the freshly released
`qcheck-core.0.23'. This in turn, enabled a couple of other clean-ups:
• #492: Also use the new, upstreamed `Gen.exponential' combinator in
STM
• #491: Require `qcheck.0.23', simplify show functions by utilizing
it, and update expect outputs accordingly
• #486: Add `Util.Pp.pp_fun_' printer for generated `QCheck.fun_'
functions
Happy testing and happy holidays! :smiley: :christmas_tree:
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 23548 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-12-10 13:48 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-12-10 13:48 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 23227 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 03 to 10,
2024.
Table of Contents
─────────────────
Release of cppo 1.8.0
New releases of Merlin and OCaml-LSP
New release of baby
Release of Saturn 1.0
Dune dev meeting
Dune 3.17
Spec and interface to declare dependencies in an OCaml script
Other OCaml News
Old CWN
Release of cppo 1.8.0
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-release-of-cppo-1-8-0/15749/1>
François Pottier announced
──────────────────────────
I am pleased to announce a new release of `cppo' (1.8.0) with one new
feature and one bug fix:
⁃ A scope, delimited by `#scope ... #endscope', limits the effect of
`#define', `#def ... #enddef', and `#undef'.
⁃ The command `cppo -version', which used to print a blank line, has
been fixed.
For more details, please see the [documentation].
[documentation] <https://github.com/ocaml-community/cppo/>
New releases of Merlin and OCaml-LSP
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-releases-of-merlin-and-ocaml-lsp/15752/1>
vds announced
─────────────
I am pleased to announce new releases of Merlin (`5.3-502' and
`4.18-414') and OCaml-LSP (`1.20.1' and `1.20.1-4.14').
The Merlin releases bundle a handful of fixes while the LSP releases
focus on adding more custom queries. These custom queries will enable
tailored LSP clients to provide the same rich OCaml editing features
as the one provided by the original Merlin modes for Emacs and Vim.
Latest releases of `vscode-ocaml-platform' already provide two new
commands: `Construct' and `Jump' that respectively provide a better UI
to fill typed holes with values and jump to specific parent
nodes. Search by type/polarity and a command to get the type of
growing and shrinking selections will also be available in the future.
<https://global.discourse-cdn.com/flex020/uploads/ocaml/original/2X/c/c07de3130c92cb1601215531c75ecc0545a97b4d.gif>
Merlin changelog
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ merlin 5.3
⁃ merlin binary
• Respect the `EXCLUDE_QUERY_DIR' configuration directive when
looking for cmt files (#1854)
• Fix occurrences bug in which relative paths in index files are
resolved against the PWD rather than the SOURCE_ROOT (#1855)
• Fix exception in polarity search (#1858 fixes #1113)
• Fix jump to `fun' targets not working (#1863, fixes #1862)
• Fix type-enclosing results instability. This reverts some overly
aggressive deduplication that should be done on the client
side. (#1864)
• Fix occurrences not working when the definition comes from a
hidden source file (#1865)
OCaml-LSP changelog
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ 1.20.1
◊ Features
• Add custom
[~ocamllsp/typeSearch~](/ocaml-lsp-server/docs/ocamllsp/typeSearch-spec.md)
request (#1369)
• Make MerlinJump code action configurable (#1376)
• Add custom
[~ocamllsp/jump~](/ocaml-lsp-server/docs/ocamllsp/merlinJump-spec.md)
request (#1374)
◊ Fixes
• Fix fd leak in running external processes for preprocessing
(#1349)
• Fix prefix parsing for completion of object methods (#1363, fixes
#1358)
• Remove some duplicates in the `selectionRange' answers (#1368)
• Deactivate the `jump' code actions by default. Clients can enable
them with the `merlinJumpCodeActions' configuration
option. Alternatively a custom request is provided for ad hoc use
of the feature. (#1411)
New release of baby
═══════════════════
Archive: <https://discuss.ocaml.org/t/new-release-of-baby/15754/1>
François Pottier announced
──────────────────────────
It is my pleasure to announce the second release of `baby'.
┌────
│ opam update
│ opam install baby.20241204
└────
`baby' is an OCaml library that offers persistent sets and maps based
on balanced binary search trees. It offers replacements for OCaml's
`Set' and `Map' modules.
Height-balanced and weight-balanced binary search trees are offered
out of the box. Furthermore, to advanced users, the library offers a
lightweight way of implementing other balancing strategies.
[Documentation] is available online.
The changes in this release are as follows:
• The library now offers both sets and maps. The modules `Baby.H.Set'
and `Baby.W.Set' continue to exist, and are compatible with OCaml's
`Set' library. The modules `Baby.H.Map' and `Baby.W.Map' appear, and
are compatible with OCaml's `Map' library. Furthermore, the functors
`Baby.H.Make' and `Baby.W.Make' appear. These functors produce a
module that contains sets, maps, and two conversion functions
between sets and maps, namely `domain' and `lift'.
• Documentation: in the signature `OrderedType', clarify the
specification of the function `compare'; this function decides a
total preorder `≤'.
• Documentation: in the preamble, clarify that, most of the time, we
assume that `≤' is a total order; if an operation must be understood
in the more general case where `≤' is a total preorder, then this is
explicitly indicated.
• Documentation: update the documentation of `find' and `find_opt' in
accordance with the previous point.
• A number of incompatible changes have been made; see [the change
log] for details.
[Documentation] <https://cambium.inria.fr/~fpottier/baby/doc/baby/>
[the change log] <https://github.com/fpottier/baby/blob/main/CHANGES.md>
Release of Saturn 1.0
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-release-of-saturn-1-0/15763/1>
Carine Morel announced
──────────────────────
I am thrilled to announce the release of [Saturn] 1.0!
Saturn is a collection of concurrent-safe data structures designed for
OCaml 5. These structures have been:
• thoroughly tested with amazing tools like [STM] (see this [blog
post]) and [DScheck],
• benchmarked for performance,
• optimized for efficiency,
• and even verified in some cases!
If you're curious about the motivation behind Saturn and the
challenges it addresses, you can read more [here].
[Saturn] <https://github.com/ocaml-multicore/saturn>
[STM] <https://github.com/ocaml-multicore/multicoretests>
[blog post]
<https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5/>
[DScheck] <https://github.com/ocaml-multicore/dscheck>
[here]
<https://github.com/ocaml-multicore/saturn/blob/main/doc/motivation.md>
What Can You Do with Saturn?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Saturn provides a variety of data structures, including queues,
stacks, hash tables, and more. All of these structures are
**lock-free**, **linearizable**, and specifically designed to take
full advantage of OCaml 5’s multicore capabilities.
◊ Portable Data Structures
Lock-freedom is a progress property that guarantees system-wide
progress. This is a powerful and desirable feature, though it comes at
the cost of some overhead. However, it offers a significant advantage:
lock-free data structures avoid the need for scheduler-specific
blocking mechanisms, making them compatible with any scheduler, such
as [Eio] or [Domainslib].
[Eio] <https://github.com/ocaml-multicore/eio>
[Domainslib] <https://github.com/ocaml-multicore/domainslib>
◊ Restrictions
Saturn’s data structures are not composable, meaning you cannot
combine them (e.g., use `Saturn.Queue' inside `Saturn.Htbl') while
preserving properties like lock-freedom and linearizability.
They are also not extensible outside of Saturn without losing these
properties. For instance, `Saturn.Queue' does not include a `length'
function because implementing one would introduce significant overhead
(see `Saturn.Bounded_queue' for an example of this
tradeoff). Attempting to add this functionality, such as by wrapping
the queue:
┌────
│ type 'a t = {size: int Atomic.t; queue : 'a Saturn.Queue.t}
└────
would result in a structure that either loses lock-freedom or is no
longer linearizable.
If you need composable lock-free data structures, consider exploring
[kcas_data].
[kcas_data]
<https://ocaml-multicore.github.io/kcas/doc/kcas_data/Kcas_data/index.html>
Call to Action
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• *Try It Out*: Give Saturn a try in your projects and let us know how
it works for you. If you encounter any bugs or issues, please
report them on our [GitHub repository].
• *Share Your Use Case*: Are you already using Saturn? Let us know in
the comments what you're building with it!
• *Contribute*: We’d love to have more contributors. Whether it’s
implementing new features, improving documentation, or suggesting
enhancements, your contributions are welcome!
• *Help Shape the Future*: What would you like to see in Saturn? Is
there a missing data structure you need? Share your thoughts to
help us build a roadmap for future development.
*Thank you for your support!*
[GitHub repository] <https://github.com/ocaml-multicore/saturn>
Talks and Resources
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you want to learn more about Saturn, I gave a talk at the 2024
OCaml Workshop—check out the short [paper] and the [talk].
To dive deeper into concurrent-safe data structures, I highly
recommend having a look at [The Art of Multiprocessor Programming],
which explores the differences in design between lock-based and
lock-free data structures.
[paper]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/12/Saturn-a-library-of-verified-concurrent-data-structures-for-OCaml-5>
[talk] <https://youtu.be/OuQqblCxJ2Y?t=24398>
[The Art of Multiprocessor Programming]
<https://www.researchgate.net/publication/213876653_The_Art_of_Multiprocessor_Programming>
Commercial Support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you’re interested in incorporating Saturn into your commercial
applications, Tarides offers professional development and support
services. Feel free to contact us for more details.
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/18>
Etienne Marais announced
────────────────────────
Hi Dune enthusiasts! :smile:
We will hold our regular Dune dev meeting on *Wednesday, December,
11th at 9:00* CET. As usual, the session will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers !
:camel:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-12-11>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
• Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Dune 3.17
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-17/15770/1>
Etienne Marais announced
────────────────────────
The Dune team is happy to announce the release of Dune `3.17.0'!
:tada:
Among the list of changes, this minor release enables the Dune cache
by default for known-safe operations, adds out-of-the-box support for
`Wasm_of_ocaml', adds support for the~-H~ compiler flag introduced in
OCaml 5.2, allows specifying code hosting services like Codeberg or
GitLab organisations, and gives the possibility to run individual
tests with `dune runtest'.
If you encounter a problem with this release, you can report it on the
[ocaml/dune] repository.
[ocaml/dune] <https://github.com/ocaml/dune/issues>
Changelog
╌╌╌╌╌╌╌╌╌
◊ Added
• Make Merlin/OCaml-LSP aware of "hidden" dependencies used by
`(implicit_transitive_deps false)' via the `-H' compiler
flag. (#10535, @voodoos)
• Add support for the -H flag (introduced in OCaml compiler 5.2) in
dune (requires lang versions 3.17). This adaptation gives the
correct semantics for `(implicit_transitive_deps false)'. (#10644,
fixes #9333, ocsigen/tyxml#274, #2733, #4963, @MA0100)
• Add support for specifying Gitlab organization repositories in
`source' stanzas (#10766, fixes #6723, @H-ANSEN)
• New option to control jsoo sourcemap generation in env and
executable stanza (#10777, fixes #10673, @hhugo)
• One can now control jsoo compilation_mode inside an executable
stanza (#10777, fixes #10673, @hhugo)
• Add support for specifying default values of the `authors',
`maintainers', and `license' stanzas of the `dune-project' file via
the dune config file. Default values are set using the
`(project_defaults)' stanza (#10835, @H-ANSEN)
• Add names to source tree events in performance traces (#10884,
@jchavarri)
• Add `codeberg' as an option for defining project sources in
dune-project files. For example, `(source (codeberg
user/repo))'. (#10904, @nlordell)
• `dune runtest' can now run individual tests with `dune runtest
mytest.t' (#11041, @Alizter).
• Wasm_of_ocaml support (#11093, @vouillon)
• Add a `coqdep_flags' field to the `coq' field of the `env' stanza,
and to the `coq.theory' stanza, allowing to configure `coqdep'
flags. (#11094, @rlepigre)
◊ Fixed
• Show the context name for errors happening in non-default contexts.
(#10414, fixes #10378, @jchavarri)
• Correctly declare dependencies of indexes so that they are rebuilt
when needed. (#10623, @voodoos)
• Don't depend on coq-stdlib being installed when expanding variables
of the `coq.version' family (#10631, fixes #10629, @gares)
• Error out if no files are found when using `copy_files'. (#10649,
@jchavarri)
• Re_export dune-section private library in the dune-site library
stanza, in order to avoid failure when generating and building sites
modules with implicit_transitive_deps = false. (#10650, fixes #9661,
@MA0100)
• Expect test fixes: support multiple modes and fix dependencies when
there is a custom runner (#10671, @vouillon)
• In a `(library)' stanza with `(extra_objects)' and
`(foreign_stubs)', avoid double linking the extra object files in
the final executable. (#10783, fixes #10785, @nojb)
• Map `(re_export)' library dependencies to the `exports' field in
`META' files, and vice-versa. This field was proposed in to
<https://discuss.ocaml.org/t/proposal-a-new-exports-field-in-findlib-meta-files/13947>.
The field is included in Dune-generated `META' files only when the
Dune lang version is >= 3.17. (#10831, fixes #10830, @nojb)
• Fix staged pps preprocessors on Windows (which were not working at
all previously) (#10869, fixes #10867, @nojb)
• Fix `dune describe' when an executable is disabled with
`enabled_if'. (#10881, fixes #10779, @moyodiallo)
• Fix an issue where C stubs would be rebuilt whenever the stderr of
Dune was redirected. (#10883, fixes #10882, @nojb)
• Fix the URL opened by the command `dune ocaml doc'. (#10897,
@gridbugs)
• Fix the file referred to in the error/warning message displayed due
to the dune configuration version not supporting a particular
configuration stanza in use. (#10923, @H-ANSEN)
• Fix `enabled_if' when it uses `env' variable. (#10936, fixes #10905,
@moyodiallo)
• Fix exec -w for relative paths with –root argument (#10982,
@gridbugs)
• Do not ignore the `(locks ..)' field in the `test' and `tests'
stanza (#11081, @rgrinberg)
• Tolerate files without extension when generating merlin rules.
(#11128, @anmonteiro)
◊ Changed
• Remove all remnants of the experimental
`patch-back-source-tree'. (#10771, @rgrinberg)
• Change the preset value for author and maintainer fields in the
`dune-project' file to encourage including emails. (#10848,
@punchagan)
• Tweak the preset value for tags in the `dune-project' file to hint
at topics not having a special meaning. (#10849, @punchagan)
• Change some colors to improve readability in light-mode terminals
(#10890, @gridbugs)
• Forward the linkall flag to jsoo in whole program compilation as
well (#10935, @hhugo)
• Configurator uses `pkgconf' as pkg-config implementation when
available and forwards it the `target' of `ocamlc -config'. (#10937,
@pirbo)
• Enable Dune cache by default. Add a new Dune cache setting
`enabled-except-user-rules', which enables the Dune cache, but
excludes user-written rules from it. This is a conservative choice
that can avoid breaking rules whose dependencies are not correctly
specified. This is the current default. (#10944, #10710, @nojb,
@ElectreAAS)
• Do not add `dune' dependency in `dune-project' when creating
projects with `dune init proj'. The Dune dependency is implicitely
added when generating opam files (#11129, @Leonidas-from-XIV)
Spec and interface to declare dependencies in an OCaml script
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/spec-and-interface-to-declare-dependencies-in-an-ocaml-script/15772/1>
jbeckford announced
───────────────────
This is the fourth article in the MlFront series. If you are
interested in scripting frameworks that can download source code and
bytecode, and inter-operate while doing so, please read:
[https://diskuv.com/mlfront/overview-4/]
[https://diskuv.com/mlfront/overview-4/]
<https://diskuv.com/mlfront/overview-4/>
TLDR
╌╌╌╌
/(Critical, verbatim snippets from article)/
I have an old opam package [DkSDKFFIOCaml_Std] that is a low-level
bridge between OCaml and other programming languages. It can be
extraordinarily difficult to build, so I made it a mix of pure OCaml
source code and prebuilt library downloads. Today I'll describe how
embedded OCaml dependencies like the following /simplifies the build
process/:
┌────
│ module _ = DkSDKFFI_OCaml
│ (** The bridge between OCaml and other programming languages.
│
│ {[ `v1 [
│ `sec [ `scheme "dkcoder" ];
│ `blib ["https://gitlab.com/api/v4/projects/62703194/packages/generic/@DKML_TARGET_ABI@/2.1.4/@DKML_TARGET_ABI@-4.14.2-DkSDKFFI_OCaml-2.1.4-none.blib.zip"];
│ `clib ["https://gitlab.com/api/v4/projects/62703194/packages/generic/@DKML_TARGET_ABI@/2.1.4/@DKML_TARGET_ABI@-4.14.2-DkSDKFFI_OCaml-2.1.4-none.clib.zip"]
│ ] ]} *)
│
│ (* And use what you imported ... *)
│ let () =
│ ignore (DkSDKFFI_OCaml.Com.create_c ())
└────
—
One set of designs I created are the `MlFront_Archive' package
formats:
1. `*.blib.zip' - This is the bytecode archive. It is a zip file
containing `.cma', `.cmi' and some other critical metadata.
2. `*.clib.zip' - This is the C library archive. It is a zip file
containing `.so' or `.dylib' or `.dll' shared libraries, and also
the corresponding static libraries.
The important concept is that `*.blib.zip' and `*.clib.zip' for OCaml
are analogous to `*.jar' files for Java. The design is available at:
• Format of packages:
<https://gitlab.com/diskuv/registries/public-packages#generic-registry-layout>
• Binaries to unpack the packages:
<https://gitlab.com/dkml/build-tools/MlFront_Archive/-/releases>
—
The remote specification design is in the `MlFront_Config' library:
• code: <https://gitlab.com/dkml/build-tools/MlFront#mlfront>
• odoc:
<https://dkml.gitlab.io/build-tools/MlFront/MlFront_Config/MlFront_Config/RemoteSpec/index.html>
[DkSDKFFIOCaml_Std] <https://ocaml.org/p/DkSDKFFIOCaml_Std/latest>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Release of Frama-C 30.0 (Zinc)]
• [Irmin on MirageOS: Under-the-Hood With Notafs]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Release of Frama-C 30.0 (Zinc)]
<https://frama-c.com/fc-versions/zinc.html>
[Irmin on MirageOS: Under-the-Hood With Notafs]
<https://tarides.com/blog/2024-12-04-irmin-on-mirageos-under-the-hood-with-notafs>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 39206 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-12-03 14:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-12-03 14:44 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 44579 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 26 to
December 03, 2024.
Table of Contents
─────────────────
Good example of handwritten Lexer + Recursive Descent Parser?
Boulder Dash in OCaml
Js_of_ocaml 5.9.0
Liquidsoap 2.3.0
Bytesrw 0.1.0 – Composable byte stream readers and writers
dream-html and pure-html 3.5.2
Second beta release of OCaml 5.3.0
New release of Monolith
Jsont 0.1.0 – Declarative JSON data manipulation for OCaml
Tiny educational concurrent I/O and promises library
Eliom 11.1: Towards Web Assembly support
Areas and Adversaries
MariaDB 1.2.0
Proposed Package Archiving Policy for the opam Repository
capnp-rpc 2.0
Other OCaml News
Old CWN
Good example of handwritten Lexer + Recursive Descent Parser?
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/good-example-of-handwritten-lexer-recursive-descent-parser/15672/1>
Axel Baudot asked
─────────────────
I am looking for an idiomatic implementation of a Lexer + Recursive
Descent Parser not making use of ocamllex, ocamlyacc or menhir. The
kind you would write during the first chapters of Crafting
Interpreters [0][1] in OCaml.
This Markdown parser [2] by @dbuenzli is a great example of what I am
looking for. I'd be happy if you can recommend similar resources.
There are many OCaml repos for Lox interpreters but it's hard to
assess quality. And the readme often says "I am doing this to learn
OCaml", which doesn't inspire confidence.
As a broader note, it would be nice to have (community vetted) OCaml
translations of well-known learning material using mainstream
languages. But I'll raise the topic in another thread later.
Thanks in advance.
• [0] <https://craftinginterpreters.com/scanning.html>
• [1] <https://craftinginterpreters.com/parsing-expressions.html>
• [2]
<https://github.com/dbuenzli/cmarkit/blob/af8930c307957a546ea833bbdabda94a2fa60b4b/src/cmarkit.ml#L879>
Mikhail replied
───────────────
You might be interested in the book [Compiling to Assembly from
Scratch]. There is a [port to OCaml]. It suggests the use of [parser
combinators].
Parser combinators is the same manual recursive descent method, but in
a functional way. You can either use [an existing library] or you
[can write your own].
[Compiling to Assembly from Scratch]
<https://keleshev.com/compiling-to-assembly-from-scratch/>
[port to OCaml]
<https://github.com/keleshev/compiling-to-assembly-from-scratch/tree/main/contrib/ocaml>
[parser combinators] <https://en.wikipedia.org/wiki/Parser_combinator>
[an existing library] <https://github.com/inhabitedtype/angstrom>
[can write your own] <https://www.youtube.com/watch?v=Y5IIXUBXvLs>
Anton Bachin also replied
─────────────────────────
odoc's parser is half of what you're asking for. It uses ocamllex for
the lexical scan, because it's very simple and convenient to do it
that way, but the syntax is then analyzed by a hand-written [recursive
descent parser], in large part because /that's/ easier for the doc
language.
An example of a non-ocamllex and non-ocamlyacc parser is Markup.ml
([tokenizer], [parser]). But this isn't a traditional recursive
descent parser. Rather, it's a pretty huge hand-written state machine
in continuation-passing style, almost completely implementing the
corresponding huge state machine specified in HTML5. But it's the kind
of code that fits well the topics of an impure FP class, especially
since it has mutable cells for its continuations, that it uses to
mimic effects.
[recursive descent parser]
<https://github.com/ocaml/odoc/blob/822d266232fccdffbd4922434c81c45ab6d583f4/src/parser/syntax.ml>
[tokenizer]
<https://github.com/aantron/markup.ml/blob/d686cce6bac6ff46a49b28ed0d957ffa1e37fda5/src/html_tokenizer.ml#L390>
[parser]
<https://github.com/aantron/markup.ml/blob/d686cce6bac6ff46a49b28ed0d957ffa1e37fda5/src/html_parser.ml#L1386>
Boulder Dash in OCaml
═════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2024-11/msg00023.html>
Continuing this thread, Andreas Rossberg announced
──────────────────────────────────────────────────
Couldn’t let it rest, so I’m (already) announcing version 2 of it —
now a much improved, practically feature-complete reimplementation of
both Boulder Dash 1 & 2.
Version 2 was an excuse for me to mess around with the OCaml bindings
to popular graphics engines, and as a result, it now comes with 3
backends to choose from:
1. the homely bare OCaml Graphics library
(<https://github.com/ocaml/graphics>),
2. the TSDL binding to the SDL2 API
(<https://github.com/dbuenzli/tsdl>),
3. the binding to the Raylib engine
(<https://github.com/tjammer/raylib-ocaml>).
The list is in order of increasingly better user experience, for the
price of a potentially harder build experience. In theory, all
versions should run on Windows, Mac, and Linux, though I was too lazy
to test all combinations, and I (or my opam) had trouble installing
some of the dependencies on some of the systems.
Features:
• Faithful original physics, graphics, animations, sound, and music
• Authentic scrolling mechanics combined with dynamic resizing
• All 40 levels and 5 difficulties of Boulder Dash 1 & 2
• Pause-and-go mode for relaxed playing
Relative to the previous release, version 2 adds the following
niceties:
• Support for SDL and Raylib engines, which allow all of the following
• Original sound effects and music
• Original level color schemes
• Full screen mode
• Faster graphics
• Dynamic graphics scaling adjustment
• Gamepad/joystick support as well as more precise keyboard controls
• Boulder Dash 2 levels and decoder
Almost looks like a real game now. One from the 80s anyways. :)
Js_of_ocaml 5.9.0
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-js-of-ocaml-5-9-0/15674/1>
Hhugo announced
───────────────
I’m pleased to announce the release of js_of_ocaml 5.9.0. It should
soon be available in opam.
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.
Most significant changes:
• Support for OCaml 5.3
• Speedup sourcemap generation and improve sourcemap accuracy.
• Prepare the merge of the wasm_of_ocaml fork back into the
js_of_ocaml repo.
• JS backtraces are really expansive. They now need to be explicitly
requested with `OCAMLRUNPARM=b=1'. This speeds up programs linked
with libraries enabling backtraces programmatically using
`Printexc.record_backtrace true'.
See the [Changelog ] for other changes.
[Changelog ]
<https://github.com/ocsigen/js_of_ocaml/blob/master/CHANGES.md>
Liquidsoap 2.3.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-liquidsoap-2-3-0/15677/1>
Romain Beauxis announced
────────────────────────
We are stoked to announce the `2.3.0' release of liquidsoap, a
general-purpose scripting language written in OCaml with specialized
operators to build media streams.
The release is available on github:
<https://github.com/savonet/liquidsoap/releases/tag/v2.3.0>
During this release cycle, we have rewritten huge chunk of the
application's internal, including a new media streaming abstraction
and clock system.
As an OCaml application, liquidsoap's scope and complexity has greatly
expanded in the next years.
Some of the most challenging areas for us at this point are memory
usage (and, incidentally, CPU usage).
Although OCaml's garbage collection is a very powerful tool, in the
context of very short lived streaming cycles (typically `0.02s') with
potentially quite large memory allocations (typically video images),
controlling the timing of memory allocations and release is becoming
more and more critical.
We are also aware of the work done by Jane St on adding a `local' call
stack. This could be an avenue to explore as well but:
1. Some of our content has to be stored in the long-term heap
2. We want to work with an official OCaml compiler for obvious
long-term maintenance concerns.
Nonetheless, we are thrilled to be part of a community whose array of
tools (building, packaging, debugging, etc) and libraries has expanded
so well along with a vibrant compiler development team.
In the future, we wish to explore more of the new OCaml concurrency
features. This might require that we revisit the way we handle
short-term memory first.
Bytesrw 0.1.0 – Composable byte stream readers and writers
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bytesrw-0-1-0-composable-byte-stream-readers-and-writers/15696/1>
Daniel Bünzli announced
───────────────────────
It's my pleasure to announce the first release of the `bytesrw'
library:
Bytesrw extends the OCaml `Bytes' module with composable,
memory efficient, byte stream readers and writers
compatible with effect-based concurrency.
Except for byte slice life-times, these abstractions
intentionally separate away ressource management and the
specifics of reading and writing bytes.
Bytesrw distributed under the ISC license. It has no
dependencies.
Optional support for compressed and hashed bytes depend,
at your wish, on the C [`zlib'], [`libzstd'], [`blake3'],
[`libmd'], [`xxhash'] and libraries.
The only reason I was longing for OCaml algebraic effects was so that
I could avoid using them: when you write codecs on byte streams it
should not be a concern where your bytes are coming from or headed
to. The `bytesrw' library provides structures to abstract
this. Additionally it establishes a buffer ownership discipline that
enables byte streams to (de)compose while remaining memory efficient.
I do not expect the library to change much and it has been used. But
it's new and practice may call for adjustments. Do not hesitate to get
in touch if you run into problems or see obvious defects or
improvements. I do expect the library will add more convenience
(e.g. for processing lines and UTF) and more optional stream formats
over time.
• Homepage: <https://erratique.ch/software/bytesrw>
• Docs: <https://erratique.ch/software/bytesrw/doc> or `odig doc
bytesrw'
• Install: `opam install bytesrw conf-zlib conf-zstd conf-libblake3
conf-libmd conf-xxhash' ([opam PR])
This first release was made possible thanks to a grant from the [OCaml
Software Foundation]. I also thank my [donors] for their support.
[`zlib'] <https://zlib.net>
[`libzstd'] <http://zstd.net>
[`blake3'] <https://blake3.io>
[`libmd'] <https://www.hadrons.org/software/libmd/>
[`xxhash'] <https://xxhash.com/>
[opam PR] <https://github.com/ocaml/opam-repository/pull/26990>
[OCaml Software Foundation] <https://ocaml-sf.org/>
[donors] <https://github.com/sponsors/dbuenzli>
dream-html and pure-html 3.5.2
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/14808/5>
Yawar Amin announced
────────────────────
[ANN] dream-html 3.7.0
Happy to announce the addition of a helper module for typed form
decoding functionality. See the docs here:
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Form/index.html>
An example:
┌────
│ type user = { name : string; age : int option }
│
│ open Dream_html.Form
│
│ let user_form =
│ let+ name = required string "name"
│ and+ age = optional int "age" in
│ { name; age }
│
│ let dream_form = ["age", "42"; "name", "Bob"]
│ let user_result = validate user_form dream_form
│ (* => Ok { name = "Bob"; age = Some 42 } *)
│
│ let error_result = validate user_form ["age", "none"]
│ (* => Error [("age", "error.expected.int"); ("name", "error.required")] *)
└────
Astute readers may observe that this provides some convenience
functionality beyond what Dream itself offers; to validate the above
form and get a _complete_ set of field validation errors using only
Dream you would do something like:
┌────
│ let user_result = match dream_form with
│ | ["age", age; "name", name] ->
│ (match int_of_string age with
│ | age -> Ok { name; age = Some age }
│ | exception Failure _ -> Error ["age", "error.expected.int"])
│ | ["name", name] -> Ok { name; age = None }
│ | ["age", age] ->
│ (match int_of_string age with
│ | age -> Error ["name", "error.required"]
│ | exception Failure _ -> Error ["age", "error.expected.int"; "name", "error.required"])
│ | _ -> Error ["name", "error.required"]
└────
And this is a form with only two fields. You can imagine how
convoluted the logic would be for more complex forms. Of course, you
might just decide to use `List.assoc_opt' and build up the validation
errors, but even that can get tricky. So if you are making heavy use
of HTML forms, a helper module that takes care of all these validation
details can be very useful. Enjoy!
Second beta release of OCaml 5.3.0
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/second-beta-release-of-ocaml-5-3-0/15700/1>
octachron announced
───────────────────
One month after the release of the first beta for OCaml 5.3.0, we are
releasing a second and hopefully last beta release for OCaml 5.3.0 .
The most notable changes for this second beta are probably a handful
of type system bugfixes. In particular, those fixes revert a change of
behaviour in the first beta when pattern matching GADTs with
non-injective type parameters.
We also have a C++ header compatibility fix and the restoration of
some configuration variable in Makefiles for the sake of backward
compatibility.
Overall, the release is converging and we are expecting to have a
first release candidate around the middle of December. The progresses
on stabilising the ecosystem are tracked on the [opam readiness for
5.3.0 meta-issue].
Meanwhile, the second beta release of OCaml 5.3.0 is here to help you
update your software and libraries ahead of the release (see below for
the installation instructions).
The full release is expected before the end of December.
If you find any bugs, please report them on [OCaml's issue tracker].
If you are interested in full list of features and bug fixes of the
new OCaml version, the updated change log for OCaml 5.3.0 is available
[on GitHub].
Happy hacking, Florian Angeletti for the OCaml team.
[opam readiness for 5.3.0 meta-issue]
<https://github.com/ocaml/opam-repository/issues/26596>
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.3/Changes>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands on opam 2.1 and later:
┌────
│ opam update
│ opam switch create 5.3.0~beta2
└────
The source code for the beta is also available at these addresses:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.3.0-beta2.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.3/ocaml-5.3.0~beta2.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.3.0~beta2+options <option_list>
└────
where `option_list' is a space separated list of `ocaml-option-*'
packages. For instance, for a flambda and no-flat-float-array switch:
┌────
│ opam switch create 5.3.0~beta2+flambda+nffa ocaml-variants.5.3.0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Changes Since The First Beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Type system fixes
• [#13501]: Regression on mutually recursive types caused by [#12180].
Resuscitate Typedecl.update_type. (Jacques Garrigue and Takafumi
Saikawa, review by Florian Angeletti, Richard Eisenberg and Gabriel
Scherer)
• [#13495], [#13514]: Fix typechecker crash while typing objects
(Jacques Garrigue, report by Nicolás Ojeda Bär, review by Nicolas
Ojeda Bär, Gabriel Scherer, Stephen Dolan, Florian Angeletti)
• [#13598]: Falsely triggered warning 56 [unreachable-case] This was
caused by unproper protection of the retyping function. (Jacques
Garrigue, report by Tõivo Leedjärv, review by Florian Angeletti)
[#13501] <https://github.com/ocaml/ocaml/issues/13501>
[#12180] <https://github.com/ocaml/ocaml/issues/12180>
[#13495] <https://github.com/ocaml/ocaml/issues/13495>
[#13514] <https://github.com/ocaml/ocaml/issues/13514>
[#13598] <https://github.com/ocaml/ocaml/issues/13598>
◊ Configuration fixes
• (*breaking change*) [#12578], [#12589], [#13322], +[#13519]: Use
configured CFLAGS and CPPFLAGS /only/ during the build of the
compiler itself. Do not use them when compiling third-party C
sources through the compiler. Flags for compiling third-party C
sources can still be specified at configure time in the
COMPILER_{BYTECODE,NATIVE}_{CFLAGS,CPPFLAGS} configuration
variables. (Sébastien Hinderer, report by William Hu, review by
David Allsopp)
[#12578] <https://github.com/ocaml/ocaml/issues/12578>
[#12589] <https://github.com/ocaml/ocaml/issues/12589>
[#13322] <https://github.com/ocaml/ocaml/issues/13322>
[#13519] <https://github.com/ocaml/ocaml/issues/13519>
◊ C++ header compatibility
• [#13541], [#13591]: Fix headers for C++ inclusion. (Antonin Décimo,
review by Nick Barnes, report by Kate Deplaix)
[#13541] <https://github.com/ocaml/ocaml/issues/13541>
[#13591] <https://github.com/ocaml/ocaml/issues/13591>
◊ Compiler library bug fix
• [#13603], [#13604]: fix source printing in the presence of the
escaped raw identifier `\#mod'. (Florian Angeletti, report by Chris
Casinghino, review by Gabriel Scherer)
[#13603] <https://github.com/ocaml/ocaml/issues/13603>
[#13604] <https://github.com/ocaml/ocaml/issues/13604>
New release of Monolith
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-monolith/15701/1>
François Pottier announced
──────────────────────────
I am pleased to announce a new release of [Monolith], a library that
helps perform strong automated testing of OCaml libraries.
┌────
│ opam update
│ opam install monolith.20241126
└────
The changes are as follows:
• The documentation of the specification combinators has been
re-organized in sections and subsections. Finding the desired
combinator should now be easier.
• The new combinator `naive_array' offers limited support for arrays.
• The new combinator `naive_seq' offers limited support for sequences
(that is, for the type constructor `Seq.t').
• The new combinator `pair' is a synonym for `( *** )'.
• The new combinator `triple' offers support for triples.
• The new combinator `either' offers support for the type constructor
`Either.t'.
• The new combinators `iter', `foldr', `foldl', `iteri', `foldri',
`foldli' offer support for iteration functions.
• An unintentional and undocumented limitation has been fixed: so far,
uses of the combinator `map_into' would work only at the root of the
specification or in the right-hand side of an arrow `^>'. It should
now be possible to use `map_into' under other combinators that
expect a deconstructible specification, such as `^!>' (in the
right-hand side), `( *** )', `option', `result', `list', etc. This
improvement affects not only `map_into', but also a number of other
combinators that are defined in terms of `map_into'.
• Monolith now requires OCaml 4.12 or later.
• In `Makefile.monolith',
⁃ the default switch is changed from 4.11.1 to 4.14.2; this can be
overridden by defining `SWITCH';
⁃ `make test' automatically disables the MacOS crash reporter;
⁃ the use of `ulimit -s' is abandoned.
[Monolith]
<https://cambium.inria.fr/~fpottier/monolith/doc/monolith/Monolith/>
Jsont 0.1.0 – Declarative JSON data manipulation for OCaml
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-jsont-0-1-0-declarative-json-data-manipulation-for-ocaml/15702/1>
Daniel Bünzli announced
───────────────────────
It's my pleasure to announce the first release of the jsont libary:
Jsont is an OCaml library for declarative JSON data
manipulation. It provides:
• Combinators for describing JSON data using the OCaml
values of your choice. The descriptions can be used by
generic functions to decode, encode, query and update
JSON data without having to construct a generic JSON
representation.
• A JSON codec with optional text location tracking and
layout preservation. The codec is compatible with
effect-based concurrency.
The descriptions are independent from the codec and can be
used by third-party processors or codecs.
Jsont is distributed under the ISC license. It has no
dependencies. The codec is optional and depends on the
[`bytesrw'] library. The JavaScript support is optional
and depends on the [`brr'] library.
The library has been used in practice but it's new so a few
adjustments may be needed and more convenience combinators added.
The library also enables quite a few things that I did not have the
time to explore like schema description generation from descriptions,
quasi-streaming JSON transformations, description generation from
dynamic type representations, etc. Lots of this can be done outside
the core library, do not hesitate to get in touch if you use the
library and find interesting applications or pesking limitations.
• Homepage: <https://erratique.ch/software/jsont>
• Docs: <https://erratique.ch/software/jsont/doc> (or `odig doc
jsont')
• Install: `opam install jsont bytesrw'
This first release was made possible thanks to a grant from the [OCaml
Software Foundation]. I also thank my [donors] for their support.
Best,
Daniel
P.S. I think that the technique used by the library, which I dubbed
/finally tagged/ is interesting in itself. You can read a paper about
it [here] along with a smaller, self-contained, implementation of what
the library does.
[`bytesrw'] <https://erratique.ch/software/bytesrw>
[`brr'] <https://erratique.ch/software/brr>
[OCaml Software Foundation] <https://ocaml-sf.org/>
[donors] <https://github.com/sponsors/dbuenzli>
[here] <https://github.com/dbuenzli/jsont/tree/main/paper>
Tiny educational concurrent I/O and promises library
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tiny-educational-concurrent-i-o-and-promises-library/15703/1>
Mikhail announced
─────────────────
I like [Lwt]. It's a fantastic library, but how does it work? I spent
a few days studying its source code.
Finally, inspired by the implementation of [Lwt] and [the CS3110
chapter, 8.7. Promises]. I wrote a maximally stupid [*tiny-async-lib*]
library.
Maybe you may be interested in this naive implementation.
[Lwt] <https://github.com/ocsigen/lwt>
[the CS3110 chapter, 8.7. Promises]
<https://cs3110.github.io/textbook/chapters/ds/promises.html>
[*tiny-async-lib*] <https://github.com/dx3mod/tiny-async-lib>
Examples of use
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ let () =
│ Engine.run main begin
│ let* () = Io.(write_all stdout) "Hi! What's your name? " in
│ let* name = Io.(read_line stdin) in
│ Io.(write_all stdout) ("Hello, " ^ name ^ "!\n")
│ end
└────
┌────
│ let read_and_print_file filename =
│ Io.(read_file filename >>= write_all stdout)
│
│ let _ =
│ Engine.run begin
│ let filenames = [ (* ... *) ] in
│
│ filenames
│ |> List.map read_and_print_file
│ |> Promise.join
│ end
└────
Implementation details
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The first key abstraction of the whole library is, of course,
Promise. [Promise] is an abstraction for synchronizing program
execution in concurrent evaluations. In simple terms, it's an
abstraction over callbacks. Promises allows us to build (monadic)
sequence evaluations inside of non-sequence evaluations.
┌────
│ (* promise.ml *)
│
│ type 'a t = { mutable state: 'a state }
│
│ and 'a state =
│ | Fulfilled of 'a
│ | Rejected of exn
│ | Pending of 'a callback list
│
│ and 'a callback = 'a state -> unit
└────
Promises are represented as a mutable record with three possible
states: fulfilled (contains a value), rejected (contains an
exception), and pending (contains callbacks).
Callbacks are functions that are called when a promise is resolved.
So when we `bind', if the promise is in pending state, we add a
callback that calls the following monadic sequence when the promise is
resolved.
┌────
│ (* io.ml *)
│
│ let sleep delay =
│ let p, r = Promise.make () in
│
│ Engine.(on_timer instance) delay (fun handler ->
│ Engine.stop_handler handler;
│ Promise.fulfill r ());
│
│ p
└────
The second key abstraction is an [asynchronous I/O] engine that polls
I/O events and dispatches them to handlers. Original Lwt has few
engines (like based libev, select, poll), but I hardcoded a
[select](<https://en.wikipedia.org/wiki/Select_(Unix)>)-based engine
inspired by `Lwt_engine.select_based'.
The typical async engine in internals has an event loop. At each
iteration of the event loop, the engine polls for new events and calls
handlers to handle them.
┌────
│ (* engine.ml *)
│
│ let iter engine =
│ (* ... *)
│
│ let readable_fds, writable_fds, _ =
│ Unix.select readable_fds writable_fds [] timeout
│ in
│
│ engine.sleepers <- restart_sleepers now engine.sleepers;
│
│ invoke_io_handlers engine.wait_readable readable_fds;
│ invoke_io_handlers engine.wait_writable writable_fds
└────
How to execute I/O promise? It's not a big deal.
┌────
│ (* engine.ml *)
│
│ let rec run promise =
│ match Promise.state promise with
│ | Fulfilled value -> value
│ | Rejected exc -> raise exc
│ | Pending _ ->
│ iter instance;
│ run promise
└────
We just need to loop the event loop until the promis is resolved.
It's just a toy! I'm not an expert in such things, so the library is
very naive and tries to mimic Lwt. But I think it's a good
demonstration.
Repository <https://github.com/dx3mod/tiny-async-lib>
Thank you for your attention!
[Promise] <https://en.wikipedia.org/wiki/Futures_and_promises>
[asynchronous I/O] <https://en.wikipedia.org/wiki/Asynchronous_I/O>
Eliom 11.1: Towards Web Assembly support
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/eliom-11-1-towards-web-assembly-support/15704/1>
Vincent Balat announced
───────────────────────
Eliom 11.1 has been released recently. This minor release brings
compatibility with Web Assembly and the upcoming version of
js_of_ocaml. Ocsigen Toolkit and Ocsigen Start have been updated as
well.
Stay tuned for further announcements concerning client-server Web and
mobile apps in Ocaml with Web Assembly!
Links:
• [Ocsigen]
• [Eliom]
• [Documentation]
• [Github]
[Ocsigen] <https://ocsigen.org>
[Eliom] <https://ocsigen.org/eliom>
[Documentation] <https://ocsigen.org/tuto/latest/manual/basics>
[Github] <https://github.com/ocsigen/eliom>
Areas and Adversaries
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-areas-and-adversaries/15706/1>
Raphaël Proust announced
────────────────────────
I figured people might be bored of [British pub names] by now so I did
another thing: [a generator for titles of table-top role-playing
games].
┌────
│ $ opam install areas-and-adversaries
│ ...
│ $ areas-and-adversaries
│ Woods & Wizards
└────
The code is on Gitlab:
<https://gitlab.com/raphael-proust/areas-and-adversaries>
It was a good excuse to experiment with non-dune build systems (to
scope things out). I went for a plain Makefile in the end which works
well.
I also wanted to figure out a better way to embed data in an
executable. I ended up wondering about moving as much of the
processing as possible into the build phase. What I ended up with is a
small program which prints a compilation unit (`.ml') which has mostly
array literals. Still have some open questions on that, any input
welcome:
• Should I have used meta-ocaml to print the code? The `data/munch.ml'
would probably be more readable, but the build probably less.
• How could I generate this kind of processed-data code for
data-structures which don't have a literal (maps, sets, hash tables,
etc.)? How can I minimise the initialisation cost of the program for
such situations?
[British pub names]
<https://discuss.ocaml.org/t/ann-queenshead-a-british-pub-name-generator/13124>
[a generator for titles of table-top role-playing games]
<https://raphael-proust.gitlab.io/code/areas-and-adversaries.html>
MariaDB 1.2.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-mariadb-1-2-0/15709/1>
Petter A. Urkedal announced
───────────────────────────
I'm please to announce a new release of the [mariadb] package, which
provides client bindings for MariaDB and MySQL. See the full release
notes below.
This is also to announce that I have taken over maintenance of the
project. Currently I am the sole maintainer (and I usually use
PostgreSQL for my own deployments), so if someone has the time en
interest to contribute, let me know. The main focus from my side is
to keep the project up to date and stable, rather than making major
changes.
Release notes:
• Added `Stmt.start_txn' (#59 by Corentin Leruth).
• Added `Res.insert_id' as binding for `mysql_stmt_insert_id' (#58 by
Corentin Leruth).
• Updated to support recent OCaml versions (#45 by @kit-ty-kate).
• Fixed too-early retrieval of statement metadata (#41 by Albert
Peschar).
• Fixed decoding bug for the integer type (#54 by Raman Varabets,
tested by #61 by Corentin Leruth).
• Fixed a memory leaks related to result metadata (#39 by Albert
Peschar).
• The build system is now dune and dune-configurator (#52 by Petter A.
Urkedal) and some of the examples have been converted to a test
suite (#60 by Petter A. Urkedal).
• The project has been transferred to ocaml-community with Petter A.
Urkedal as the new maintainer.
[mariadb] <https://github.com/ocaml-community/ocaml-mariadb>
Proposed Package Archiving Policy for the opam Repository
═════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository/15713/1>
Hannes Mehnert announced
────────────────────────
It is my please to announce the proposed package archiving policy in
the name of the opam-repository maintainers.
Context
╌╌╌╌╌╌╌
The opam repository differs from nearly all other
programming-language-centric package repositories in that it is
manually curated by volunteer maintainers and protected by a robust
continuous integration system that (generally) ensures published
packages work as expected across a [large matrix of supported
platforms].
Over the past few years the repository has kept growing steadily, when
not accelerating, and this has started raising questions about the
size, weight and sustainability of the repository and its
processes. Last year, [Hannes Mehnert] requested comments on a
[proposed initiative] to improve the sustainability and quality of the
opam package repository on the long term.
[large matrix of supported platforms]
<https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md>
[Hannes Mehnert] <https://github.com/hannesm>
[proposed initiative]
<https://github.com/ocaml/opam-repository/issues/23789>
Problem
╌╌╌╌╌╌╌
The problem, in a nutshell, is that the `opam-repository' will keep
steadily growing, using an increasing and substantial amount of space
and inodes. Every opam user needs to invest a large amount of
computational resources for the solver, every time they want to
install or update a package. Additionally, a large amount of
computational resources are spent in the continuous integration
process and yet a lot of the packages have become stale or
uninstallable.
Solution
╌╌╌╌╌╌╌╌
[After much deliberation], the discussion converged on a solution:
introduce a package archiving policy and supporting processes, to
periodically identify and prune unmaintained and broken packages from
the repository. This will improve the performance of the opam solvers,
of the opam-repo CI, and most importantly improve the quality of the
package repository, while keeping a sort of immutability of the
repository content and preserving the usability of historical packages
for the users that want or need them.
The opam repository maintainers propose a [policy].
The currently empty [repository archive] has been created, waiting for
packages to be moved.
[After much deliberation]
<https://github.com/ocaml/opam-repository/issues/23789>
[policy]
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md>
[repository archive] <https://github.com/ocaml/opam-repository-archive>
Call to action
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you maintain packages in the opam-repository, you can help by
defining your maintanence intent: add a new field
`x-maintenance-intent' to your opam file(s) (the most recent release
of your package is sufficient - please also put this field in your git
repository so it will be part of future releases). The value is
defined in [the policy].
[the policy]
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process>
Roadmap
╌╌╌╌╌╌╌
All announcements will be on discuss.ocaml.org with the
opam-repository tag. If you like to follow these announcements, keep
your eyes at [the opam-repository tag].
• December 1st 2024: announcement of this proposal
• December 15th 2024: announcement of the packages affected by Phase 1
(uninstallable packages ("available: false", "flags: avoid-version"
or "deprecated", "opam admin check –installable", does not compile –
opam health check <https://check.ci.ocaml.org/>)
• January 1st 2025: Phase 1 cutting point: packages are moved to
opam-repository-archive
• January 15th 2025: announcement of the packages affected by Phase 2
(OCaml lower bound 4.08)
• February 1st 2025: Phase 2 cutting point: packages are moved to
opam-repository-archive
• February 15th 2025: initial spring cleaning, announcement of
packages (based on maintenance-intent)
• March 1st 2025: spring cleaning cutting point: packages are moved to
opam-repository-archive
• Every quarter: repeat Phase 3
• Every year: reconsider Phase 2 with an increased OCaml lower bound
We now invite members of the OCaml community who may not follow the
ocaml-repository issues to review our plans and submit comments,
questions, or suggestions.
Thank you in advance for your support!
[the opam-repository tag]
<https://discuss.ocaml.org/tag/opam-repository>
References
╌╌╌╌╌╌╌╌╌╌
• [Opam repository archive]
• [Proposed policy]
• [Plan of action]
• [Issue and discussion]
• [Previous announcement]
[Opam repository archive]
<https://github.com/ocaml/opam-repository-archive>
[Proposed policy]
<https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md>
[Plan of action]
<https://github.com/ocaml/opam-repository/wiki/Package-Archiving:-Plan>
[Issue and discussion]
<https://github.com/ocaml/opam-repository/issues/23789>
[Previous announcement]
<https://discuss.ocaml.org/t/discussions-on-the-future-of-the-opam-repository/13898>
Acknowledgment
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Thanks to the following individuals for valuable input and
contributions to the planning process (sorry in case we forgot you):
• Marcello Seri
• Shon Feder
• Thomas Gazagnaire
• kit-ty-kate
• Weng Shiwei 翁士伟
• Marcus Rohrmoser
• Reynir Björnsson
• Stephen Sherratt
• Simon Cruanes
• Marek Kubica
• Raphaël Proust
• Romain Beauxis
• Yawar Amin
• Anil Madhavapeddy
• Boning D.
• Mathieu Barbin
• Hannes Mehnert
capnp-rpc 2.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-capnp-rpc-2-0/15739/1>
Thomas Leonard announced
────────────────────────
I'm pleased to announce the release of [capnp-rpc 2.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.
The main change in this version is the switch from Lwt to Eio for
concurrency. The echo benchmark is about 40% faster than before. This
isn't because Eio is actually that much faster than Lwt, but more
because it has better profiling support so spotting problems was
easier. See <https://roscidus.com/blog/blog/2024/07/22/performance/>
for an example:
<https://roscidus.com/blog/images/perf/capnp-eio-slow-zoom1-debug.png>
There is a `capnp-rpc-lwt' compatibility package that provides the old
Lwt API using the new Eio version, allowing libraries using the old
API to be used in applications using the new code, without having to
update everything at once.
To migrate to the new version (checking everything still works after
each step):
1. First, update to capnp-rpc 1.2.4 (this ensures you are using the
newer mirage-crypto API, to get that migration out of the way
first).
2. Switch your application (that sets up the networking) to
capnp-rpc-unix 2.0.
3. Migrate client and server code away from capnp-rpc-lwt when
convenient.
For more detailed instructions, see [the changelog].
Here's an example of the changes needed in the solver-service project:
• [Update to capnp-rpc-unix 2.0]
• [Remove Capnp_rpc_lwt]
[capnp-rpc 2.0] <https://github.com/mirage/capnp-rpc/releases/tag/v2.0>
[documentation and tutorial]
<https://github.com/mirage/capnp-rpc/blob/master/README.md>
[the changelog]
<https://github.com/mirage/capnp-rpc/blob/master/CHANGES.md#v20>
[Update to capnp-rpc-unix 2.0]
<https://github.com/talex5/solver-service/commit/a4af17b5ea44e94579fc0ca01fd0c618a5182df4>
[Remove Capnp_rpc_lwt]
<https://github.com/talex5/solver-service/commit/74431efd36f4474236401f0556fad80de22b1b42>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Irmin on MirageOS: Introducing the Notafs File System]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Irmin on MirageOS: Introducing the Notafs File System]
<https://tarides.com/blog/2024-11-27-irmin-on-mirageos-introducing-the-notafs-file-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 68222 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-11-26 8:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-11-26 8:30 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 29192 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 19 to 26,
2024.
Table of Contents
─────────────────
OCaml 5.2.1 released
smaws preview release, an AWS SDK for OCaml using eio
ppx_deriving_ezjsonm
FUN OCaml now has a YouTube Channel
Terrateam's open source Ocaml repository
OUPS december 2024
Dune dev meeting
Other OCaml News
Old CWN
OCaml 5.2.1 released
════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-5-2-1-released/15634/1>
octachron announced
───────────────────
We have the pleasure of announcing the release of OCaml 5.2.1,
dedicated to the memory of Niels Bohr and Paul Éluard on the
anniversary of their deaths.
OCaml 5.2.1 is a collection of safe but import runtime time bug fixes
backported from the 5.3 branch of OCaml to improve the stability of
the 5.2 runtime while waiting for the upcoming release of OCaml 5.3.0.
The full list of bug fixes is available below for more details.
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 5.2.1
└────
The source code for the release is also directly available on:
• [GitHub]
• [Inria archive]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.1.tar.gz>
[Inria archive]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.1.tar.gz>
Bug Fixes In OCaml 5.2.1 (18 November 2024)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Runtime System:
• [#13207]: Be sure to reload the register caching the exception
handler in `caml_c_call' and `caml_c_call_stack_args', as its value
may have been changed if the OCaml stack is expanded during a
callback. (Miod Vallat, report by Vesa Karvonen, review by Gabriel
Scherer and Xavier Leroy)
• [#13252]: Rework register assignment in the interpreter code on m68k
on Linux, due to the %a5 register being used by GLIBC. (Miod
Vallat, report by Stéphane Glondu, review by Gabriel Scherer and
Xavier Leroy)
• [#13268]: Fix a call to test in `configure.ac' that was causing
errors when LDFLAGS contains several words. (Stéphane Glondu,
review by Miod Vallat)
• [#13234], [#13267]: Open runtime events file in read-write mode on
ARMel (ARMv5) systems due to atomic operations limitations on that
platform. (Stéphane Glondu, review by Miod Vallat and Vincent
Laviron)
• [#13188]: fix races in the FFI code coming from the use of
`Int_val(...)' on rooted values inside blocking questions / without
the runtime lock. (Calling `Int_val(...)' on non-rooted immediates
is fine, but any access to rooted values must be done outside
blocking sections / with the runtime lock.) (Etienne Millon, review
by Gabriel Scherer, Jan Midtgaard, Olivier Nicole)
• [#13318]: Fix regression in GC alarms, and fix them for Flambda.
(Guillaume Munch-Maccagnoni, report by Benjamin Monate, review by
Vincent Laviron and Gabriel Scherer)
• [#13140]: POWER back-end: fix issue with call to
`caml_call_realloc_stack' from a DLL (Xavier Leroy, review by Miod
Vallat)
• [#13370]: Fix a low-probability crash when calling `Gc.counters'.
(Demi Marie Obenour, review by Gabriel Scherer)
• [#13402], [#13512], [#13549], [#13553]: Revise bytecode
implementation of callbacks so that it no longer produces dangling
registered bytecode fragments. (Xavier Leroy, report by Jan
Midtgaard, analysis by Stephen Dolan, review by Miod Vallat)
• [#13502]: Fix misindexing related to `Gc.finalise_last' that could
prevent finalisers from being run. (Nick Roberts, review by Mark
Shinwell)
• [#13520]: Fix compilation of native-code version of
systhreads. Bytecode fields were being included in the thread
descriptors. (David Allsopp, review by Sébastien Hinderer and Miod
Vallat)
[#13207] <https://github.com/ocaml/ocaml/issues/13207>
[#13252] <https://github.com/ocaml/ocaml/issues/13252>
[#13268] <https://github.com/ocaml/ocaml/issues/13268>
[#13234] <https://github.com/ocaml/ocaml/issues/13234>
[#13267] <https://github.com/ocaml/ocaml/issues/13267>
[#13188] <https://github.com/ocaml/ocaml/issues/13188>
[#13318] <https://github.com/ocaml/ocaml/issues/13318>
[#13140] <https://github.com/ocaml/ocaml/issues/13140>
[#13370] <https://github.com/ocaml/ocaml/issues/13370>
[#13402] <https://github.com/ocaml/ocaml/issues/13402>
[#13512] <https://github.com/ocaml/ocaml/issues/13512>
[#13549] <https://github.com/ocaml/ocaml/issues/13549>
[#13553] <https://github.com/ocaml/ocaml/issues/13553>
[#13502] <https://github.com/ocaml/ocaml/issues/13502>
[#13520] <https://github.com/ocaml/ocaml/issues/13520>
smaws preview release, an AWS SDK for OCaml using eio
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-smaws-preview-release-an-aws-sdk-for-ocaml-using-eio/15635/1>
Chris Armstrong announced
─────────────────────────
I'm pleased to announce the first preview release for the [smaws]
library (`0.1~preview1').
*[smaws]* provides AWS bindings for OCaml using the modern [eio]
library for effects-based concurrency handling.
[smaws] <https://github.com/chris-armstrong/smaws>
[eio] <https://github.com/ocaml-multicore/eio>
Links
╌╌╌╌╌
• [Installation and Usage instructions]
• [Examples]
[Installation and Usage instructions]
<https://chris-armstrong.github.io/smaws/smaws-clients/>
[Examples]
<https://github.com/chris-armstrong/smaws/tree/main/awssdklib_examples>
Whats in this release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release includes SDKs for some AWS services and is intended to
demonstrate its API.
It is not production ready, lacking important features such as full
API documentation EC2/ECS instance metadata authentication, retry and
timeout handling, etc. It also needs support for the other internal
AWS API types to extend coverage across most AWS services.
Motivation
╌╌╌╌╌╌╌╌╌╌
I wanted to build an AWS SDK using modern effects-based
concurrency. I've built similar bindings for ReScript and ReasonML in
the past (some of the code is in fact ported across) but this is the
first OCaml-native bindings I've created.
Unlike similar projects in the OCaml ecosystem, it uses the newer
Smithy definitions to generate its bindings instead of the Python
botocore definitions. These should be better supported by AWS in the
future with richer API definitions.
What's next
╌╌╌╌╌╌╌╌╌╌╌
My next task is to finish off API documentation generation, and then
expand support for all the authentication methods and other API types
that will allow this to be used with most AWS services.
ppx_deriving_ezjsonm
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-deriving-ezjsonm/15637/1>
Patrick Ferris announced
────────────────────────
I'm happy to announce the release of `ppx_deriving_ezjsonm' (based off
of [ppx_deriving_yaml]). The two libraries share a common definition
of a "`value'" which made the reuse of the existing deriver possible
for a simple JSON deriver.
┌────
│ opam update
│ opam install ppx_deriving_ezjsonm
└────
The [documentation is online].
This library may come in handy when your dependency cone already
includes `ezjsonm'. If that is not the case, you would probably have
better luck in the `yojson' ecosystem of tools.
Happy JSON-ing :camel:
[ppx_deriving_yaml]
<https://github.com/patricoferris/ppx_deriving_yaml/>
[documentation is online]
<https://patricoferris.github.io/ppx_deriving_yaml/ppx_deriving_ezjsonm/index.html>
FUN OCaml now has a YouTube Channel
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/fun-ocaml-now-has-a-youtube-channel/15639/1>
Sabine Schmaltz announced
─────────────────────────
I just created a YouTube channel for FUN OCaml. :sparkles: :camel:
The talk recordings from the conference in Berlin on September 16 +
17, 2024 are now available for viewing!
<https://www.youtube.com/@FUNOCaml/featured>
If you can, commenting, liking, or subscribing helps us to make these
videos more visible and easier to find on YouTube, so big thanks for
everyone who helps us with this! :orange_heart: :camel:
For people who avoid YouTube: The videos will also be made available
on watch.ocaml.org.
Terrateam's open source Ocaml repository
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/terrateams-open-source-ocaml-repository/15645/1>
Malcolm announced
─────────────────
A few years ago my friend and I started a company called [Terrateam],
which does infrastructure orchestration on GitHub. Being that I am an
Ocamler and we are a lean company, we chose to use Ocaml as our
primary language. We recently went open source and I'm posting the
link here to contribute an example of an actual company using Ocaml.
A real repository.
The code can be found [here].
There a few things to note about the repo:
1. It's a mono repo, so while many of the libraries in there are
generic, they are not really individually consumable as is.
2. We have our own concurrency framework (more on that below).
3. We use our own build library (pds, which is in opam).
4. The code is in flux all the time so things change rapidly.
Why did we build our own concurrency framework?
Disclaimer: Yet another concurrency framework? Yep! Do I expect
anyone to use it? Nope, and that's ok. It is designed for our needs.
It's meant to be maintainable by one person. It's not meant to
compete with Lwt or Async for mind share. If it grows, great, if it
doesn't, I'm happy still.
Our concurrency framework is called "Asynchronous Building Blocks"
(Abb). It started over a decade ago when I was frustrated with a few
things:
1. I wanted kqueue support in Async, but (at the time) Async required
modifying a handful of repos to support it and it just wasn't
obvious how.
2. Lwt supported kqueue, but for no good reason, I just didn't like
Lwt. Part of it was how failure worked in Lwt and other part is
just it didn't fit my aesthetic. That isn't a ding against Lwt,
just personal preference.
3. I wanted as much of it to be implemented in Ocaml as possible. As
it stands now, the only C code is `libkqueue' which is a little
shim to to allow kqueue code to run on Linux, otherwise everything
is in Ocaml.
4. I didn't like how neither Async nor Lwt really supported
cancelling operations. I wanted that to be part of the framework,
not an ad-hoc feature per library. Coming from Erlang, cancelling
is really important to me and part of how I think about writing
concurrent software. I was bummed that (last I looked) Eio
explicitly rejected cancelling.
5. I also wanted a little experiment of "what if the concurrency
library exposed a syscall interface like an OS?" So a lot of the
interface is meant to look low-level (I don't think this idea
really panned out or made Abb meaningfully different).
6. I also just like having my own frameworks.
Add a dash of naivete, "how hard can it be to build a concurrency
framework?", I started my own. First commit was Mar 9, 2013.
Much of the concurrency monad is based on an unreleased library called
`Fut' by @dbuenzli
Over time, Abb matured to where I could use it in my personal
projects. And by the time we decided to make Terrateam, I felt it was
good enough for production. And it's been running production traffic
for a few years now.
One, unexpected, benefit of Lwt and Async existing in the community is
that adding a third one isn't that hard. Almost all libraries that
want to be used support both, and that usually means that they have a
generic interface. Cohttp and Dns are examples. So I could use
existing libraries for things I didn't want to or don't feel I could
reasonably implement myself.
I've also used Abb as a foundation my web framework called Brtl
(pronounced Brutal) which is both a backend framework build on Cohttp
and a frontend framework built on Brr. It really doesn't do anything
fancy, like Dream, it's pretty low level and focused on being simple.
The good:
1. It works! At least, for me.
2. Given that I wrote very single line of code, debugging and bug
fixing (which is less and less) is very easy. I also have a really
great mental model of how it works.
3. I like that I can just cancel a whole graph of async work if it's
no longer needed.
4. The future's library works in FreeBSD, Linux, and JavaScript.
5. The test coverage is pretty darn high. This is because it's a
pretty intricate thing to implement so I had to implement a lot of
tests to stay sane.
The bad:
1. Performance is not anything special. I don't think this is a
fundamental flaw, it's just that it is as fast as I need it to be
right now.
2. Some of the API is a awkward if you don't know the system. Or
names are long, like `Abb_future_combinators'.
3. The multi-target build story kind of sucks. I think that might be
a bigger issue with the pds build system but for now in the web
framework you have to use `Abb_js' rather than `Abb' for
everything.
4. There are definitely some corners cut in, especially around file
IO, but that's OK, we don't do much file IO.
5. Explicitly takes advantage in that everything runs in a single
thread. So implicitly going multi-threaded would probably break
things.
Future work:
There really isn't a lot of future work. For the most part: Abb is
done. Or should I say the interface is done. Yes, it will need
updates to fight bit rot, but there isn't much more for it to do. It
runs your code concurrently, the end.
However, as Ocaml5 becomes more of a thing, it will need to take
advantage of that. I haven't really thought about how to do it. One
item I have in my to-do list is to evaluate if Picos could be a base
layer for Abb. Abb is a layered approach so really you only need to
implement the `Abb_intf.S' interface and everything above that should
Just Work (given single threaded semantics). I think any future work
to support multi core will probably need an explicit "this crosses a
thread boundary" API. Abb will get there, eventually, but right now
it doesn't need to.
Effects will obviously have a big impact, I have no idea what that'll
do for Abb. I hope I can transition it slowly to supporting effects
but I don't want to look at effects until it's in the type system.
Some, perhaps, libraries of interest in the repo:
1. [Abb_scheduler_kqueue] - The most used scheduler. It implements
the [Abb_intf] interface.
2. [Abb_scheduler_select] - A simpler select-based scheduler. This is
meant to be used any place kqueue is not supported and also as
demo.
3. [Pgsql_io] - An implementation of the PostgreSQL protocol.
4. [Githubc2] - An automatically generated GitHub REST library
generated from their JSON Schema. This actually has no Abb
dependency, just implements the API serializing/deserializing.
5. [OpenAPI CLI] - This generates a library (see Githubc2) from an
OpenAPI spec. It is, absolutely, a bit of a rats nest, but it
works. We chose to do code-gen for this because I didn't want to
be blocked when compiling based on different compiler versions as
we're using `Ast_helper'. Ocaml, the code, is more stable than
Ocaml, the compiler API.
There is a bunch of other stuff in there. If you decide to poke
around and have any questions, feel free to ask. I can promise: not
every decision in there is well thought out or coherent.
[Terrateam] <https://terrateam.io>
[here] <https://github.com/terrateamio/terrateam>
[Abb_scheduler_kqueue]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_scheduler_kqueue>
[Abb_intf]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_intf>
[Abb_scheduler_select]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_scheduler_select>
[Pgsql_io]
<https://github.com/terrateamio/terrateam/tree/main/code/src/pgsql_io>
[Githubc2]
<https://github.com/terrateamio/terrateam/tree/main/code/src/githubc2>
[OpenAPI CLI]
<https://github.com/terrateamio/terrateam/tree/main/code/src/openapi_cli>
OUPS december 2024
══════════════════
Archive: <https://discuss.ocaml.org/t/oups-december-2024/15654/1>
zapashcanon announced
─────────────────────
CAUTION: the time has been changed from 7pm to 6:30pm
The next OUPS meetup will take place on *Thursday, 12th of December*
2024. It will start at *6:30pm* at the *4 place Jussieu* in Paris. It
will be in the in the *Esclangon building* (amphi Astier).
Please, *[register on meetup ]* as soon as possible to let us know how
many pizza we should order.
For more details, you may check the [OUPS’ website ].
This time we'll have the following talks:
*Snapshottable Stores – Clément Allain & Gabriel Scherer (@gasche)*
We say that an imperative data structure is *snapshottable* or
*supports snapshots* if we can efficiently capture its current state,
and restore a previously captured state to become the current state
again. This is useful, for example, to implement backtracking search
processes that update the data structure during search.
Inspired by a data structure proposed in 1978 by Baker, we present a
*snapshottable store*, a bag of mutable references that supports
snapshots. Instead of capturing and restoring an array, we can capture
an arbitrary set of references (of any type) and restore all of them
at once. This snapshottable store can be used as a building block to
support snapshots for arbitrary data structures, by simply replacing
all mutable references in the data structure by our store
references. We present use-cases of a snapshottable store when
implementing type-checkers and automated theorem provers.
Our implementation is designed to provide a very low overhead over
normal references, in the common case where the capture/restore
operations are infrequent. Read and write in store references are
essentially as fast as in plain references in most situations, thanks
to a key optimisation we call *record elision*. In comparison, the
common approach of replacing references by integer indices into a
persistent map incurs a logarithmic overhead on reads and writes, and
sophisticated algorithms typically impose much larger constant
factors.
The implementation, which is inspired by Baker's and the OCaml
implementation of persistent arrays by Conchon and Filliâtre, is both
fairly short and very hard to understand: it relies on shared mutable
state in subtle ways. We provide a mechanized proof of correctness of
its core using the Iris framework for the Coq proof assistant.
[/details]
*Safe, expressive and efficient programming of FPGAs circuits – Loïc
Sylvestre*
FPGAs (Field-Programmable Gate Arrays) are reconfigurable digital
circuits: their behavior can be customized by logic synthesis of
specification at the so-called register transfer level (RT level), in
hardware description languages such as VHDL or Verilog. FPGAs are well
suited to implement reactive systems, directly as synchronous circuits
interacting with the external environment via I/O pins – the logic
synthesizer ensuring that timing constraints are met, given the FPGA
clock frequency. FPGAs are also used to implement hardware
accelerators ; however, RT-level descriptions of transformational
systems (or “computations”) – with latencies of several clock cycles –
are difficult to debug, maintain and manually optimize. High-Level
Synthesis (HLS) offers a simpler way of expressing computations, using
a programming language compiled at the RT level. The advantage of this
approach is to keep the implementation details hidden from the
programmer, leaving the compiler responsible for scheduling
computations over time. However, this leads to a loss of control over
temporal behavior and therefore safety and efficiency for the circuits
generated. As embedded systems, especially those based on FPGAs, need
to perform more and more computations, while interacting with their
environment, this thesis proposes a programming model to combine
hardware description (data-flow oriented) and general-purpose parallel
computation (control-flow oriented) using a synchronous approach. This
programming model forms the basis for the design and implementation of
Eclat, a functional-imperative, parallel and synchronous programming
language, compiled to VHDL. Eclat is sufficiently precise to describe
synchronous circuits at the RT level. It facilitates the programming
of hardware accelerators, with a clear and predictable temporal
semantics by which to exploit time-space trade-offs. Any Eclat program
is reactive, with a mechanism for embedding computations within
programs and thereby mix computation and interaction. Eclat also
offers shared memory (in the form of RAM blocks), with deterministic
concurrency. It is used to develop programming abstractions such as
algorithmic skeletons and virtual machine implementations for
high-level languages. This addresses, at various levels, the need to
run general-purpose algorithms within FPGA-based reactive embedded
applications.
After the talks there will be some pizzas offered by the [OCaml
Software Foundation] and later on we’ll move to a pub nearby as usual.
[register on meetup ]
<https://www.meetup.com/fr-FR/ocaml-paris/events/304726885>
[OUPS’ website ] <https://oups.frama.io>
[OCaml Software Foundation] <https://ocaml-sf.org>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/17>
Etienne Marais announced
────────────────────────
Hi camelers! :camel: We will hold our regular Dune dev meeting on
Wednesday, November, 27th at 16:00 CET. As usual, the session will be
one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers
:ok_hand:
:calendar: *Agenda*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the [meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-11-27>
:computer: *Links*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [GitHub Wiki]
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Universal React in OCaml - David Sancho Moreno - FUN OCaml 2024]
• [Using odoc to Write Documentation - Paul-Elliot Anglès d'Auriac -
FUN OCaml 2024]
• [How the Multicore Garbage Collector works - Sudha Parimala - FUN
OCaml 2024]
• [MirageOS - Developing Operating Systems in OCaml - Hannes Mehnert -
FUN OCaml 2024]
• [The Story Behind the Fastest Image Comparison Library - Dmitriy
Kovalenko - FUN OCaml 2024]
• [Easy GADTs by Repeating Yourself - Eduardo Rafael - FUN OCaml 2024]
• [Maybe OCaml Was the Friends We Made Along the Way - Dillon Mulroy -
FUN OCaml 2024]
• [OCANNL, the `neural_nets_lib` - Lukasz Stafiniak - FUN OCaml 2024]
• [Learning OCaml with Tiny Code Xmas - Michael Dales - FUN OCaml
2024]
• [Let Signals in OCaml - Rizo Isrof - FUN OCaml 2024]
• [A 'Melange' of Tooling Coming Together - Antonio Monteiro - FUN
OCaml 2024]
• [Building Incremental and Reproducible Data Pipelines - Patrick
Ferris - FUN OCaml 2024]
• [The Future of Dune - Leandro Ostera - FUN OCaml 2024]
• [Advanced Code Navigation in OCaml-LSP]
• [opam 2.3.0 release!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Universal React in OCaml - David Sancho Moreno - FUN OCaml 2024]
<https://www.youtube.com/watch/Oy3lZl2kE-0?version=3>
[Using odoc to Write Documentation - Paul-Elliot Anglès d'Auriac - FUN
OCaml 2024] <https://www.youtube.com/watch/Qzf_ZB1TKLQ?version=3>
[How the Multicore Garbage Collector works - Sudha Parimala - FUN OCaml
2024] <https://www.youtube.com/watch/fgdB_9DcJj4?version=3>
[MirageOS - Developing Operating Systems in OCaml - Hannes Mehnert - FUN
OCaml 2024] <https://www.youtube.com/watch/g7Kl5mRDCDo?version=3>
[The Story Behind the Fastest Image Comparison Library - Dmitriy
Kovalenko - FUN OCaml 2024]
<https://www.youtube.com/watch/hTAvAKolWd8?version=3>
[Easy GADTs by Repeating Yourself - Eduardo Rafael - FUN OCaml 2024]
<https://www.youtube.com/watch/-XYO_ILJG2M?version=3>
[Maybe OCaml Was the Friends We Made Along the Way - Dillon Mulroy - FUN
OCaml 2024] <https://www.youtube.com/watch/1HlIHPa38gY?version=3>
[OCANNL, the `neural_nets_lib` - Lukasz Stafiniak - FUN OCaml 2024]
<https://www.youtube.com/watch/1J2XyHLb2J0?version=3>
[Learning OCaml with Tiny Code Xmas - Michael Dales - FUN OCaml 2024]
<https://www.youtube.com/watch/2ZswyN4aP2o?version=3>
[Let Signals in OCaml - Rizo Isrof - FUN OCaml 2024]
<https://www.youtube.com/watch/34bceAuSRXE?version=3>
[A 'Melange' of Tooling Coming Together - Antonio Monteiro - FUN OCaml
2024] <https://www.youtube.com/watch/3oCXT-ycHHs?version=3>
[Building Incremental and Reproducible Data Pipelines - Patrick Ferris -
FUN OCaml 2024] <https://www.youtube.com/watch/6mxx2j1jmhE?version=3>
[The Future of Dune - Leandro Ostera - FUN OCaml 2024]
<https://www.youtube.com/watch/7_bv3EvQANY?version=3>
[Advanced Code Navigation in OCaml-LSP]
<https://tarides.com/blog/2024-11-20-advanced-code-navigation-in-ocaml-lsp>
[opam 2.3.0 release!]
<https://ocamlpro.com/blog/2024_11_13_opam_2_3_0_releases>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 39744 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-11-19 6:52 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-11-19 6:52 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 23757 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 12 to 19,
2024.
Table of Contents
─────────────────
Boulder Dash in OCaml
Jane Street OCaml extensions – now with developer tooling!
opam 2.3.0 is out!
Installing Developer Tools with Dune
Dune Developer Preview Updates
First release of cmdlang
findlib-1.9.8
Testo 0.1.0 - a new testing framework for OCaml
Other OCaml News
Old CWN
Boulder Dash in OCaml
═════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2024-11/msg00007.html>
Andreas Rossberg announced
──────────────────────────
Boulder Dash(*) was my favourite computer game in the 8-bit era, first
released on the Atari 400/800 in 1984. Though I never owned an 8-bit
machine myself, I had friends that I annoyed enough to let me play it
on theirs.
As a homage to its 40th anniversary, I put together a fairly faithful
clone of the original game, implemented in just a few 100 lines of
bare OCaml, with nothing but the homely Graphics library. It should
run on Windows, Mac, and Linux, though I was too lazy to test the
latter.
Features:
• Faithful original physics, graphics, and animations
• Authentic scrolling mechanics combined with dynamic window resizing
• All 20 levels, including intermissions, and 5 difficulties
• Pause-and-go mode for relaxed playing
It is open-source here:
<https://github.com/rossberg/boulder-dash>
Enjoy!
/Andreas
(*) <https://en.wikipedia.org/wiki/Boulder_Dash_(video_game)> "Boulder
Dash" is a trademark of BBG Entertainment
Jane Street OCaml extensions – now with developer tooling!
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-jane-street-ocaml-extensions-now-with-developer-tooling/15597/1>
Diana Kalinichenko announced
────────────────────────────
Hi everyone! We've just released a new version of our compiler
extensions, complete with all our packages and support for developer
tooling, including ocamlformat, merlin and ocaml-lsp-server. Get the
install instructions at our [GitHub], and enjoy the experience in your
favorite editor like VSCode, Emacs or Vim.
More documentation coming soon :slight_smile:. Stay tuned for future
releases!
[GitHub]
<https://github.com/janestreet/opam-repository/tree/with-extensions>
opam 2.3.0 is out!
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-3-0-is-out/15609/1>
Kate announced
──────────────
Hi everyone,
As mentioned in [our talk at the OCaml Workshop 2024], we decided to
switch to a time-based release cycle (every 6 months), starting with
opam 2.3.
As promised, we are happy to announce the final release of opam 2.3.0.
[our talk at the OCaml Workshop 2024]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/10/Opam-2-2-and-beyond>
What’s new?
╌╌╌╌╌╌╌╌╌╌╌
• When loading a repository, *opam now ignores files in packages’
files/ directories which aren’t listed in the extra-files field* of
the opam file. :warning: If you maintain an opam repository, please
read our [blog post] to make sure your repository stays compatible.
• *Packages requiring an unsupported version of opam are now marked
unavailable*, instead of causing a repository error. This means an
opam repository can now allow smoother upgrade in the future
• *opam list –latests-only*: a new option to list only the latest
versions of packages
• *–verbose-on*: a new option to enable verbose output for specified
package names.
• *opam switch import –deps-only*: a new option to install only the
dependencies of the root packages listed in the opam switch export
file
• *opam switch list-available* no longer displays compilers flagged
with `avoid-version~/~deprecated' unless `--all' is given, meaning
that pre-release or unreleased OCaml packages no longer appear to
be the latest version
• *The builtin-0install solver was improved* and should now be capable
of being your default solver instead of `builtin-mccs+glpk'. If you
wish to give it a try, simply calling `opam option
solver=builtin-0install' (call `opam option solver=' restores the
default)
• Most of the *unhelpful conflict messages were fixed* :flashlight:
• *Fix the internal cache of installed packages*, which was storing
the wrong version of the opam file after a build failure. ([#6213])
Various performance and other improvements were made and bugs were
fixed.
:open_book: You can read our [blog post] for more information about
these changes and more, and for even more details you can take a look
at the [release note] or the [changelog].
[blog post] <https://opam.ocaml.org/blog/opam-2-3-0/>
[#6213] <https://github.com/ocaml/opam/pull/6213>
[release note] <https://github.com/ocaml/opam/releases/tag/2.3.0>
[changelog] <https://github.com/ocaml/opam/blob/2.3.0/CHANGES>
Try it!
╌╌╌╌╌╌╌
The upgrade instructions are unchanged:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh)"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) }"
└────
Please report any issues to the [bug-tracker].
[bug-tracker] <https://github.com/ocaml/opam/issues>
Installing Developer Tools with Dune
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/installing-developer-tools-with-dune/15612/1>
Steve Sherratt announced
────────────────────────
Dune can install and run developer tools in the context of a
project. This feature is available in the [Dune Developer Preview] and
in the upcoming release of Dune 3.17. As with all of Dune's package
management features, consider this feature to be unstable as its UI
and semantics may change without notice.
The currently supported tools are `ocamllsp' and `ocamlformat'. Dune
has a new command `dune tools exec <TOOL> -- [ARGS]...' which
downloads and installs the given tool, and then runs it with the given
arguments (note the `--' which separates arguments to `dune' from
arguments to the tool). Tools are installed locally to the project, in
its `_build' directory, which makes it easy to use different versions
of a tool in different projects. An unfortunate consequence of
installing tools into `_build' is that for the time being all tools
are uninstalled whenever `dune clean' is run.
Let's see it in action:
┌────
│ $ dune tools exec ocamlformat -- --version
│ Solution for dev-tools.locks/ocamlformat:
│ - ocamlformat.0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl
│ Building ocamlformat.0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl
│ Running 'ocamlformat --version'
│ 0.26.2
└────
[Dune Developer Preview] <https://preview.dune.build/>
Precompiled Binaries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Note that in the example above, Dune's package solver chose to install
version
`0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl'
of `ocamlformat'. This packages comes from a new [repository of binary
packages] containing pre-built executables for a select few Opam
packages. Dune will search this repository in addition to the default
repositories when solving packages for tools only (if a project has
`ocamlformat' in its dependencies, the binary repository won't be
searched while solving the project's dependencies).
The goal of the binary repository is to reduce the time it takes to
get started working on a new project. Without it, Dune would need to
build `ocamlformat' from source along with all of its dependencies,
which can take several minutes.
For now only a small number of package versions are contained in the
binary repository. To demonstrate, here's what happens if we run `dune
tools exec ocamlformat' in a project with `version=0.26.1' in its
`.ocamlformat' file:
┌────
│ $ dune tools exec ocamlformat -- --version
│ Solution for dev-tools.locks/ocamlformat:
│ - astring.0.8.5
│ - base.v0.17.1
│ - base-bytes.base
│ - base-unix.base
│ - camlp-streams.5.0.1
│ - cmdliner.1.3.0
│ ...
│ - ocamlformat.0.26.1
│ ...
│ Building base-unix.base
│ Building ocaml-base-compiler.5.1.1
│ Building ocaml-config.3
│ Building ocaml.5.1.1
│ Building seq.base
│ Building cmdliner.1.3.0
│ ...
│ Building ocamlformat.0.26.1
│ Running 'ocamlformat --version'
│ 0.26.1
└────
Dune parses `.ocamlformat' to determine which version of `ocamlformat'
to install, and `0.26.1' is not in the binary repo so it needed to be
built from source.
If your project requires a version of a package not available in the
binary repository, or you're on an operating system or architecture
for which no binary version of a package exists, the package will be
built from source instead. Currently the binary repository contains
binaries of `ocamlformat.0.26.2', `ocaml-lsp-server.1.18.0' and
`ocaml-lsp-server.1.19.0' for `x86_64-unknown-linux-musl',
`x86_64-apple-darwin' and `aarch64-apple-darwin'.
Note that Linux binaries are statically linked with muslc so they
should work on all distros regardless of dynamic linker.
[repository of binary packages]
<https://github.com/ocaml-dune/ocaml-binary-packages>
Running `ocamllsp'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The program `ocamllsp' from the package `ocaml-lsp-server' analyzes
OCaml code and sends information to text editors using the [Language
Server Protocol]. The tool is crucial to OCaml's editor integration
and it has a couple of quirks that are worth mentioning here.
TL;DR: Install Dune with the install script on the [Developer Preview
page] and you'll get an [`ocamllsp' shell script] that will install
and run the correct version of `ocamllsp' for your project.
Firstly the `ocamllsp' executable can only analyze code that has been
compiled with the same version of the OCaml compiler as was used to
compile the `ocamllsp' executable itself. Different versions of the
`ocaml-lsp-server' package are incompatible with some versions of the
OCaml compiler (e.g. `ocaml-lsp-server.1.19.0' must be built with at
least `5.2.0' of the compiler). This means that when Dune is choosing
which version of `ocaml-lsp-server' to install it needs to know which
version of the compiler your project is using. This is only known
after the project has been locked (by running `dune pkg lock'), so
Dune will refuse to install `ocamllsp' in a project that doesn't have
a lock directory or for a project that doesn't depend on the OCaml
compiler.
┌────
│ $ dune tools exec ocamllsp
│ Error: Unable to load the lockdir for the default build context.
│ Hint: Try running 'dune pkg lock'
└────
The `ocaml-lsp-server' packages in the [binary repository] contain
metadata to ensure that the `ocamllsp' executable that gets installed
was built with the same version of the compiler as your project. For
example the `ocaml-lsp-server' package built with `ocaml.5.2.0'
contains this line:
┌────
│ conflicts: "ocaml" {!= "5.2.0"}
└────
This prevents it from being chosen if the project depends on any
version of the compiler other than `5.2.0'.
Another quirk is that `ocamllsp' will try to invoke the binaries
`ocamlformat' and `ocamlformat-rpc', both found in the `ocamlformat'
package. The `ocaml-lsp-server' package doesn't depend on
`ocamlformat' as the specific version of `ocamlformat' needed by a
project is implied by the project's `.ocamlformat' file, which package
managers don't consider when solving dependencies. This means that in
general (whether using Dune or Opam for package management) it's up to
the user to make sure that the correct version of `ocamlformat' is
installed in order to use the formatting features of `ocamllsp'.
Otherwise expect this error in your editor:
┌────
│ Unable to find 'ocamlformat-rpc' binary. Types on hover may not be well-formatted. You need to install either 'ocamlformat' of version > 0.21.0 or, otherwise, 'ocamlformat-rpc' package.
└────
Even if `ocamllsp' and `ocamlformat' are both installed by Dune, if
you run `dune tools exec ocamllsp' you will find that `ocamllsp' still
can't find the `ocamlformat' or `ocamlformat-rpc' executables. This is
because unlike Opam, Dune does not install tools into your `$PATH',
and for the sake of simplicity, the `dune tools exec <TOOL>' command
does not modify the environment of the tool it launches. This can be
fixed by adding
`_build/_private/default/.dev-tool/ocamlformat/ocamlformat/target/bin'
(the directory containing `ocamlformat' and `ocamlformat-rpc' when
`ocamlformat' is installed by dune) to the start of your `$PATH'
variable before running `dune tools exec ocamllsp'. For example
starting `ocamllsp' with the following shell script:
┌────
│ OCAMLFORMAT_TARGET="_build/_private/default/.dev-tool/ocamlformat/ocamlformat/target"
│
│ if [ ! -f $OCAMLFORMAT_TARGET/cookie ]; then
│ # Make sure that the ocamlformat dev tool is installed as it's needed by
│ # ocamllsp. There's currently no command that just installs ocamlformat so
│ # we need to run it and ignore the result.
│ dune tools exec ocamlformat -- --help > /dev/null
│ fi
│
│ # Add ocamlformat to the environment in which ocamllsp runs so ocamllsp can invoke ocamlformat.
│ export PATH="$PWD/$OCAMLFORMAT_TARGET/bin:$PATH"
│
│ # Build and run ocamllsp.
│ dune tools exec ocamllsp -- "$@"
└────
Of course, it's rare to manually start `ocamllsp' directly from your
terminal. It's normally launched by text editors. It would be
impractical to configure your text editor to modify `$PATH' and run a
custom command to start `ocamllsp' via Dune, and doing so would make
it impossible to edit any project that _doesn't_ use Dune for package
management. Instead, the Dune Developer Preview ships with [a shell
script] which installs `ocamlformat' and adds its `bin' directory to
`$PATH' before launching `dune tools exec ocamllsp'. The script is
simply named `ocamllsp', and the Dune Developer Preview install script
adds it to `~/.dune/bin' which should already be in your `$PATH' if
you're using the Developer Preview. The `ocamllsp' script also
attempts to fall back to an Opam-managed installation of `ocamllsp' if
it doesn't detect a Dune lockdir so the same script should work for
non-Dune projects. Because the script is named the same as the
`ocamllsp' executable, most editors don't require special
configuration to run it. See the "Editor Configuration" section of the
[Dune Developer Preview page] for more information about setting up
your editor.
Some parts of the `ocamllsp' shell script may eventually make their
way into Dune itself, but for the time being the shell script is the
recommended way to launch `ocamllsp' for users of the Dune Developer
Preview. The net result is that as long as your project has a
lockfile, the first time you edit some OCaml code in the project Dune
will download and run the appropriate version of `ocamllsp'.
[Language Server Protocol]
<https://microsoft.github.io/language-server-protocol/>
[Developer Preview page] <https://preview.dune.build/>
[`ocamllsp' shell script]
<https://github.com/ocaml-dune/binary-distribution/blob/main/tool-wrappers/ocamllsp>
[binary repository]
<https://github.com/ocaml-dune/ocaml-binary-packages>
[a shell script]
<https://github.com/ocaml-dune/binary-distribution/blob/main/tool-wrappers/ocamllsp>
[Dune Developer Preview page] <https://preview.dune.build/>
Dune Developer Preview Updates
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160/52>
Steve Sherratt announced
────────────────────────
A new version of the [vscode-ocaml-platform] was just released which
fixes a few issues with ocamllsp. You'll probably have to update your
install of the Dune Developer Preview (just rerun the command on [this
page]). You'll need to configure a custom sandbox for vscode by
putting this in your `settings.json' file as otherwise the plugin
assumes you're using `opam' to launch `ocamllsp':
┌────
│ {
│ "ocaml.sandbox": {
│ "kind": "custom",
│ "template": "$prog $args"
│ }
│ }
└────
[vscode-ocaml-platform]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>
[this page] <https://preview.dune.build/>
First release of cmdlang
════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-release-of-cmdlang/15616/1>
Mathieu Barbin announced
────────────────────────
Hi everyone!
A little while ago, I [posted] about [cmdlang], a library for creating
command-line parsers in OCaml.
Today, I am happy to give you an update on this project with the
announcement of an initial release of cmdlang packages to the
opam-repository.
These are very early days for this project. I have started using the
`cmdlang+cmdliner' combination in personal projects, and plan to
experiment with `climate' in the near future. Please feel free to
engage in issues/discussions, etc.
The most recent addition on the project is the development of an
evaluation engine based on `stdlib/arg'.
I'd also like to highlight some examples from the project's
tests. Developing these characterization tests was a fun way to learn
more about the different CLI libraries and their differences:
• Short, long and prefix [flag names].
• Various syntaxes for [named arguments] (`-pVALUE', `-p=VALUE', `-p
VALUE').
• Handling of [negative integers] as named arguments.
If you have ideas for more cases to add (entertaining or otherwise),
I'd love to integrate them into the test suite. Thanks!
Below, you'll find details of the released packages. Happy command
parsing!
*cmdlang* the user facing library to build the commands. It has no
dependencies
*cmdlang-to-cmdliner* translate cmdlang commands to cmdliner
*cmdlang-to-climate* translate cmdlang commands to the newly released
climate (compatibility checked with 0.1.0 & 0.2.0)
*cmdlang-stdlib-runner* an execution engine implemented on top of
stdlib.arg
Thank you to @mseri and the opam-repository maintainers for their
help.
[posted]
<https://discuss.ocaml.org/t/cmdlang-yet-another-cli-library-well-not-really/15258>
[cmdlang] <https://github.com/mbarbin/cmdlang>
[flag names]
<https://github.com/mbarbin/cmdlang/blob/main/test/expect/test__flag.ml>
[named arguments]
<https://github.com/mbarbin/cmdlang/blob/main/test/expect/test__named.ml>
[negative integers]
<https://github.com/mbarbin/cmdlang/blob/main/test/expect/test__negative_int_args.ml>
findlib-1.9.8
═════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2024-11/msg00014.html>
Gerd Stolpmann announced
────────────────────────
Hi list,
findlib-1.9.8 is out, fixing a few issues that slipped into 1.9.7.
For manual, download, manuals, etc. see here:
<http://projects.camlcity.org/projects/findlib.html>
An updated OPAM package will follow soon.
Testo 0.1.0 - a new testing framework for OCaml
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-testo-0-1-0-a-new-testing-framework-for-ocaml/15624/1>
Martin Jambon announced
───────────────────────
On this 86th anniversary of the first synthesis of LSD by Albert
Hofmann, it is my pleasure to announce [Testo], a new testing library
for OCaml.
It borrows a lot of ideas from Alcotest and is similar in spirit but
adds a few key features that seemed too difficult to incorporate into
Alcotest. For a gentle introduction, check out our
[tutorial]. Important features include:
• support for many options when creating a test of type `Testo.t';
• capturing stdout or stderr output for comparison against the
expected output aka snapshots;
• reviewing and approving tests without re-running them;
• support for nested categories while keeping the test suite as a flat
list;
• parallel execution using multiprocessing.
This is the first official release of Testo and its interface is
likely to change in minor ways until we release version 1.0.0. We've
been using it internally at Semgrep for about a year and it's been
working well for us.
Happy testing!
[Testo] <https://github.com/semgrep/testo>
[tutorial] <https://semgrep.github.io/testo/tutorial/>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The New Conference on the Block: What is FUN OCaml?]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The New Conference on the Block: What is FUN OCaml?]
<https://tarides.com/blog/2024-11-13-the-new-conference-on-the-block-what-is-fun-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 36936 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-11-12 15:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-11-12 15:00 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 18584 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 05 to 12,
2024.
Table of Contents
─────────────────
Picos — Interoperable effects based concurrency
findlib-1.9.7
First release candidate for OCaml 5.2.1
mirage-swapfs
Dune dev meeting
Other OCaml News
Old CWN
Picos — Interoperable effects based concurrency
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-picos-interoperable-effects-based-concurrency/14507/3>
polytypic announced
───────────────────
I'm happy to announce that Picos version 0.6.0 has been released!
Picos is a systems programming interface between effects
based schedulers and concurrent abstractions.
A lot of work has been done on Picos since previous announcements.
You might start on the new minimalist landing page for [Picos], which,
among other things, allows you to access the documentation of all the
released Picos versions.
Also, in case you missed it, a recording of the talk
[Picos — Interoperable effects based concurrency]
can be found [here].
We also held a workshop on concurrency and parallelism at [Fun
OCaml]. You might enjoy trying out [the exercise we developed for the
workshop].
As, for reasons of dependencies, Picos now comes in no less than [8
packages] and multiple libraries, here is a summary of the packages
and the libraries inside each package:
• [`picos'] — Picos — Interoperable effects based concurrency
• [`picos'] — A systems programming interface between effects based
schedulers and concurrent abstractions
• [`picos.domain'] — Minimalistic domain API available both on OCaml
5 and on OCaml 4
• [`picos.thread'] — Minimalistic thread API available with or
without threads.posix
• [`picos_mux'] — Sample schedulers for Picos
• [`picos_mux.fifo'] — Basic single-threaded effects based Picos
compatible scheduler for OCaml 5
• [`picos_mux.multififo'] — Basic multi-threaded effects based Picos
compatible scheduler for OCaml 5
• [`picos_mux.random'] — Randomized multi-threaded effects based
Picos compatible scheduler for OCaml 5
• [`picos_mux.thread'] — Basic Thread based Picos compatible
scheduler for OCaml 4
• [`picos_std'] — Sample libraries for Picos
• [`picos_std.finally'] — Syntax for avoiding resource leaks for
Picos
• [`picos_std.awaitable'] — Basic futex-like awaitable atomic
location for Picos
• [`picos_std.event'] — Basic event abstraction for Picos
• [`picos_std.structured'] — Basic structured concurrency primitives
for Picos
• [`picos_std.sync'] — Basic communication and synchronization
primitives for Picos
• [`picos_io'] — Asynchronous IO system for Picos
• [`picos_io'] — Basic IO facilities based on OCaml standard
libraries for Picos
• [`picos_io.select'] — Basic Unix.select based IO event loop for
Picos
• [`picos_io.fd'] — Externally reference counted file descriptors
• [`picos_io_cohttp'] — Cohttp running on Picos IO
• [`picos_io_cohttp'] — Minimalistic Cohttp implementation using
Picos_io for Picos
• [`picos_lwt'] — Lwt interface for Picos
• [`picos_lwt'] — Direct style Picos compatible interface to Lwt for
OCaml 5
• [`picos_lwt.unix'] — Direct style Picos compatible interface to
Lwt with Lwt_unix for OCaml 5
• [`picos_aux'] — Auxiliary libraries for Picos
• [`picos_aux.htbl'] — Lock-free hash table
• [`picos_aux.mpmcq'] — Lock-free multi-producer, multi-consumer
queue
• [`picos_aux.mpscq'] — Lock-free multi-producer, single-consumer
queue
• [`picos_aux.rc'] — External reference counting tables for
disposable resources
• [`picos_meta'] — Integration tests for Picos packages
In addition to the above, [Moonpool] now uses Picos underneath.
And, I almost forgot, there is a ready to be merged [PR for Kcas to
change it to use Picos]. You should be able to try it with an opam
[pin-depends].
[Picos] <https://ocaml-multicore.github.io/picos/>
[Picos — Interoperable effects based concurrency]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/5/Picos-Interoperable-effects-based-concurrency>
[here] <https://youtu.be/OuQqblCxJ2Y?t=20115>
[Fun OCaml] <https://fun-ocaml.com/>
[the exercise we developed for the workshop]
<https://github.com/ocaml-multicore/fun-ocaml-workshop>
[8 packages] <https://ocaml-multicore.github.io/picos/0.6.0/>
[`picos']
<https://ocaml-multicore.github.io/picos/0.6.0/picos/index.html>
[`picos']
<https://ocaml-multicore.github.io/picos/0.6.0/picos/Picos/index.html>
[`picos.domain']
<https://ocaml-multicore.github.io/picos/0.6.0/picos/Picos_domain/index.html>
[`picos.thread']
<https://ocaml-multicore.github.io/picos/0.6.0/picos/Picos_thread/index.html>
[`picos_mux']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_mux/index.html>
[`picos_mux.fifo']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_mux/Picos_mux_fifo/index.html>
[`picos_mux.multififo']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_mux/Picos_mux_multififo/index.html>
[`picos_mux.random']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_mux/Picos_mux_random/index.html>
[`picos_mux.thread']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_mux/Picos_mux_thread/index.html>
[`picos_std']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/index.html>
[`picos_std.finally']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/Picos_std_finally/index.html>
[`picos_std.awaitable']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/Picos_std_awaitable/index.html>
[`picos_std.event']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/Picos_std_event/index.html>
[`picos_std.structured']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/Picos_std_structured/index.html>
[`picos_std.sync']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_std/Picos_std_sync/index.html>
[`picos_io']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io/index.html>
[`picos_io']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io/Picos_io/index.html>
[`picos_io.select']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io/Picos_io_select/index.html>
[`picos_io.fd']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io/Picos_io_fd/index.html>
[`picos_io_cohttp']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io_cohttp/index.html>
[`picos_io_cohttp']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_io_cohttp/Picos_io_cohttp/index.html>
[`picos_lwt']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_lwt/index.html>
[`picos_lwt']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_lwt/Picos_lwt/index.html>
[`picos_lwt.unix']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_lwt/Picos_lwt_unix/index.html>
[`picos_aux']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_aux/index.html>
[`picos_aux.htbl']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_aux/Picos_aux_htbl/index.html>
[`picos_aux.mpmcq']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_aux/Picos_aux_mpmcq/index.html>
[`picos_aux.mpscq']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_aux/Picos_aux_mpscq/index.html>
[`picos_aux.rc']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_aux/Picos_aux_rc/index.html>
[`picos_meta']
<https://ocaml-multicore.github.io/picos/0.6.0/picos_meta/index.html>
[Moonpool] <https://github.com/c-cube/moonpool>
[PR for Kcas to change it to use Picos]
<https://github.com/ocaml-multicore/kcas/pull/204>
[pin-depends]
<https://opam.ocaml.org/doc/Manual.html#opamfield-pin-depends>
findlib-1.9.7
═════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2024-11/msg00004.html>
Gerd Stolpmann announced
────────────────────────
findlib-1.9.7 is out. This is mostly a bugfix release. There is now
also some support for relocability (driven by environment variables),
contributed by Marek Kubica.
For manual, download, manuals, etc. see here:
<http://projects.camlcity.org/projects/findlib.html>
An updated OPAM package will follow soon.
First release candidate for OCaml 5.2.1
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-release-candidate-for-ocaml-5-2-1/15578/1>
octachron announced
───────────────────
The release of OCaml version 5.2.1 is imminent.
OCaml 5.2.1 is a collection of safe but import runtime time bug fixes
backported from the 5.3 branch of OCaml. The full list of bug fixes is
available below.
In order to ensure that the future release works as expected, we are
planning to test a release candidate during the upcoming week.
If you find any bugs, please report them here on [GitHub].
[GitHub] <https://github.com/ocaml/ocaml/issues>
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.2.1~rc1
└────
The source code for the release candidate is available on
• [GitHub]
• [Inria archives]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.1-rc1.tar.gz>
[Inria archives]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.1~rc1.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.2.1~rc1+options <option_list>
└────
where `<option_list>` is a space-separated list of `ocaml-option-*`
packages. For instance, for a `flambda` and `no-flat-float-array`
switch:
┌────
│ opam switch create 5.2.1~rc1+flambda+nffa ocaml-variants.5.2.1~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option`.
*Changes Since OCaml 5.2.0*
Runtime System:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#13207]: Be sure to reload the register caching the exception
handler in caml_c_call and caml_c_call_stack_args, as its value may
have been changed if the OCaml stack is expanded during a callback.
(Miod Vallat, report by Vesa Karvonen, review by Gabriel Scherer and
Xavier Leroy)
• [#13252]: Rework register assignment in the interpreter code on m68k
on Linux, due to the %a5 register being used by Glibc. (Miod
Vallat, report by Stéphane Glondu, review by Gabriel Scherer and
Xavier Leroy)
• [#13268]: Fix a call to test in configure.ac that was causing errors
when LDFLAGS contains several words. (Stéphane Glondu, review by
Miod Vallat)
• [#13234], [#13267]: Open runtime events file in read-write mode on
armel (armv5) systems due to atomic operations limitations on that
platform. (Stéphane Glondu, review by Miod Vallat and Vincent
Laviron)
• [#13188]: fix races in the FFI code coming from the use of
Int_val(…) on rooted values inside blocking questions / without the
runtime lock. (Calling Int_val(…) on non-rooted immediates is fine,
but any access to rooted values must be done outside blocking
sections / with the runtime lock.) (Etienne Millon, review by
Gabriel Scherer, Jan Midtgaard, Olivier Nicole)
• [#13318]: Fix regression in GC alarms, and fix them for flambda.
(Guillaume Munch-Maccagnoni, report by Benjamin Monate, review by
Vincent Laviron and Gabriel Scherer)
• [#13140]: POWER back-end: fix issue with call to
`caml_call_realloc_stack` from a DLL (Xavier Leroy, review by Miod
Vallat)
• [#13370]: Fix a low-probability crash when calling Gc.counters.
(Demi Marie Obenour, review by Gabriel Scherer)
• [#13402], [#13512], [#13549], [#13553]: Revise bytecode
implementation of callbacks so that it no longer produces dangling
registered bytecode fragments. (Xavier Leroy, report by Jan
Midtgaard, analysis by Stephen Dolan, review by Miod Vallat)
• [#13502]: Fix misindexing related to `Gc.finalise_last` that could
prevent finalisers from being run. (Nick Roberts, review by Mark
Shinwell)
• [#13520]: Fix compilation of native-code version of
systhreads. Bytecode fields were being included in the thread
descriptors. (David Allsopp, review by Sébastien Hinderer and Miod
Vallat)
[#13207] <https://github.com/ocaml/ocaml/issues/13207>
[#13252] <https://github.com/ocaml/ocaml/issues/13252>
[#13268] <https://github.com/ocaml/ocaml/issues/13268>
[#13234] <https://github.com/ocaml/ocaml/issues/13234>
[#13267] <https://github.com/ocaml/ocaml/issues/13267>
[#13188] <https://github.com/ocaml/ocaml/issues/13188>
[#13318] <https://github.com/ocaml/ocaml/issues/13318>
[#13140] <https://github.com/ocaml/ocaml/issues/13140>
[#13370] <https://github.com/ocaml/ocaml/issues/13370>
[#13402] <https://github.com/ocaml/ocaml/issues/13402>
[#13512] <https://github.com/ocaml/ocaml/issues/13512>
[#13549] <https://github.com/ocaml/ocaml/issues/13549>
[#13553] <https://github.com/ocaml/ocaml/issues/13553>
[#13502] <https://github.com/ocaml/ocaml/issues/13502>
[#13520] <https://github.com/ocaml/ocaml/issues/13520>
mirage-swapfs
═════════════
Archive: <https://discuss.ocaml.org/t/ann-mirage-swapfs/15583/1>
Reynir Björnsson announced
──────────────────────────
I am pleased to announce the first release of [mirage-swapfs] (swapfs
on opam). It is an experimental library to use a mirage block device
for ephemeral, append-only, anonymous "files". It was developed for
use cases such as in [opam-mirror] where opam package source archives
are downloaded. The files are first downloaded to "swap" and if the
download succeeds and the checksum is as expected the data is then
copied over to the tar filesystem.
Internally it uses a weak pointer array (`Weak.t') to map "block"
offsets to handles. The idea is the garbage collector can help us free
up "blocks" if the user forgets to explicitly free the handle. A
"block" is (configurable, see `blocking_factor') multiple of sectors
in order to reduce bookkeeping overhead. With a sector size of 512
bytes the default is 1 MiB per block.
See also the documentation
<https://robur-coop.github.io/mirage-swapfs/doc/swapfs/index.html>
I would be interested to hear about other ideas or approaches.
[mirage-swapfs] <https://github.com/robur-coop/mirage-swapfs>
[opam-mirror] <https://git.robur.coop/robur/opam-mirror/>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/16>
Etienne Marais announced
────────────────────────
We will hold our regular Dune dev meeting tomorrow, on Wednesday,
November, 13th at *9:00* CET. :warning: Note that the session has been
moved *one hour earlier*. As usual, the session will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers
!:smile:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the [meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-11-13>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
• Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Beta release of Frama-C 30.0~beta (Zinc)]
• [Making OCaml Mainstream: Support Our Open Source Work on GitHub]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Beta release of Frama-C 30.0~beta (Zinc)]
<https://frama-c.com/fc-versions/zinc.html>
[Making OCaml Mainstream: Support Our Open Source Work on GitHub]
<https://tarides.com/blog/2024-11-06-making-ocaml-mainstream-support-our-open-source-work-on-github>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 29302 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-11-05 13:22 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-11-05 13:22 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 15679 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 29 to
November 05, 2024.
Table of Contents
─────────────────
GPTar 1.0.0
opam 2.3.0~rc1
Call for Contributions: BOB 2025 (Berlin, March 14 - Deadline Nov 15)
First beta release for OCaml 5.3.0
dune 3.16
Other OCaml News
Old CWN
GPTar 1.0.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-gptar-1-0-0/15527/1>
Reynir Björnsson announced
──────────────────────────
I am pleased to announce [GPTar] 1.0.0!
GPTar is a small library to create a /tartition table/, that is, a tar
archive that also contains a valid GUID partition table (GPT).
It exploits the fact that the important areas of a protective MBR in
GPT and a tar header are mostly disjoint. The tar header fits almost
exactly in the boot strap code of a master boot record (MBR) with the
last 54 bytes of the tar header overlapping with the partition table
of the (protective) MBR. Thakfully, those are the 54 last bytes of the
155 byte long NUL terminated "filename prefix" of the tar header. So
as long as we put a NUL byte before the partition table tar will
happily ignore the partition table data.
To further hide the actual GPT header & partition table from tar
utilities the first tar header uses the GNU volume header extension
with the GPT header & partition table as the "file contents". This
makes GNU tar list the volume header but when extracting files the
volume header is skipped. For *released* versions of bsdtar this
unfortunately results in a "bad archive" error - however, the as-yet
unreleased libarchive/bsdtar fixes this "bug" and allows for this
abuse of volume headers (see the "update" blog post).
For more in depth details you may be interested in reading the
following two blog articles:
• <https://blog.robur.coop/articles/gptar.html>
• <https://blog.robur.coop/articles/gptar-update.html>
[GPTar] <https://github.com/reynir/gptar>
Why!?
╌╌╌╌╌
Great question. At [Robur] we developed an [opam-mirror] unikernel
that acts as an opam repository and package source archive cache
similar to <https://opam.ocaml.org/>. There we use tar as a filesystem
for the package source archive cache. Later, we started using the end
of the block device to cache data such as git state and computed
package source archive checksums.
The neat feature is we could use regular old bsdtar or GNU tar in the
host system to inspect the tar filesystem data. The downside was the
lack of a partition table using offsets provided by boot arguments for
where to find the cached data. With GPTar we can have both! Inspect
the tar filesystem data while being more robust with a partition
table.
Also, it was very fun to develop.
[Robur] <https://robur.coop/>
[opam-mirror] <https://git.robur.coop/robur/opam-mirror/>
opam 2.3.0~rc1
══════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-3-0-rc1/15533/1>
Kate announced
──────────────
We're happy to announce the first and hopefully only release candidate
of opam 2.3.0.
This version does not have any significant change compared to the
previous 2.3.0~beta2 release and we hope the final release to also
have no significant change. Regardless, we invite users to test this
version to make sure there isn't any regressions.
Unless a regression is spotted or another problem arises, we hope to
have the final release of 2.3.0 out on the 12th of November.
Try it!
╌╌╌╌╌╌╌
The upgrade instructions are pretty much the same:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~rc1"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~rc1"
└────
Please report any issues to [the bug-tracker].
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Call for Contributions: BOB 2025 (Berlin, March 14 - Deadline Nov 15)
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/call-for-contributions-bob-2025-berlin-march-14-deadline-nov-15/15371/2>
Later in this thread, Michael Sperber announced
───────────────────────────────────────────────
OCaml content is most welcome at BOB - send us your proposal!
First beta release for OCaml 5.3.0
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-beta-release-for-ocaml-5-3-0/15551/1>
octachron announced
───────────────────
One month and half after the release of the first alpha for OCaml
5.3.0, the release of OCaml 5.3.0 is drawing near.
The internal API of the compiler libraries has been frozen, and most
core developer tools support (or will support soon) the new version of
the compiler.
We have thus released a first beta version of OCaml 5.3.0 to help you
update your software and libraries ahead of the release (see below for
the installation instructions). More information about the whole
release process is now available in the [compiler repository].
Compared to the first alpha release, this beta contains a few runtime
or typechecker fixes, a handful of fixes for the runtime event library
and other miscellaneous fixes.
Exceptionally, this beta release also introduces a new flag
`-keywords` for the compiler. This backward compatibility flag aims to
help compiling old code that are using `effect` as a normal
identifier, now that `effect` is a keyword in the new effect handler
syntax.
The progresses on stabilising the ecosystem are tracked on the [opam
readiness for 5.3.0 meta-issue].
The full release is expected in the end of November or beginning of
December, see the [new prospective calendar] for more information.
If you find any bugs, please report them on [OCaml's issue tracker].
If you are interested in full list of features and bug fixes of the
new OCaml version, the updated change log for OCaml 5.3.0 is available
[on GitHub] and a short list of the changes since the last alpha is
available below.
[compiler repository]
<https://github.com/ocaml/ocaml/blob/trunk/release-info/introduction.md>
[opam readiness for 5.3.0 meta-issue]
<https://github.com/ocaml/opam-repository/issues/26596>
[new prospective calendar]
<https://github.com/ocaml/ocaml/blob/trunk/release-info/calendar.md>
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.3/Changes>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands on opam 2.1 and later:
┌────
│ opam update
│ opam switch create 5.3.0~beta1
└────
The source code for the beta is also available at these addresses:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.3.0-beta1.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.3/ocaml-5.3.0~beta1.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.3.0~beta1+options <option_list>
└────
where `option_list' is a space separated list of `ocaml-option-*'
packages. For instance, for a flambda and no-flat-float-array switch:
┌────
│ opam
└────
switch create 5.3.0~beta1+flambda+nffa
ocaml-variants.5.3.0~beta1+options ocaml-option-flambda
ocaml-option-no-flat-float-array
All available options can be listed with `opam search ocaml-option'.
Changes since the first alpha
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Runtime fixes
• [#13502]: Fix misindexing related to `Gc.finalise_last' that could
prevent finalisers from being run. (Nick Roberts, review by Mark
Shinwell)
• [#13402], [#13512], [#13549], [#13553]: Revise bytecode
implementation of callbacks so that it no longer produces dangling
registered bytecode fragments. (Xavier Leroy, report by Jan
Midtgaard, analysis by Stephen Dolan, review by Miod Vallat)
• [#13520]: Fix compilation of native-code version of
systhreads. Bytecode fields were being included in the thread
descriptors. (David Allsopp, review by Sébastien Hinderer and Miod
Vallat)
[#13502] <https://github.com/ocaml/ocaml/issues/13502>
[#13402] <https://github.com/ocaml/ocaml/issues/13402>
[#13512] <https://github.com/ocaml/ocaml/issues/13512>
[#13549] <https://github.com/ocaml/ocaml/issues/13549>
[#13553] <https://github.com/ocaml/ocaml/issues/13553>
[#13520] <https://github.com/ocaml/ocaml/issues/13520>
◊ Typechecker fixes
• [#13579], [#13583]: Unsoundness involving non-injective types +
gadts (Jacques Garrigue, report by @v-gb, review by Richard
Eisenberg and Florian Angeletti)
• [#13388], [#13540]: raises an error message (and not an internal
compiler error) when two local substitutions are incompatible (for
instance `module type S:=sig end type t:=(module S)') (Florian
Angeletti, report by Nailen Matschke, review by Gabriel Scherer, and
Leo White)
[#13579] <https://github.com/ocaml/ocaml/issues/13579>
[#13583] <https://github.com/ocaml/ocaml/issues/13583>
[#13388] <https://github.com/ocaml/ocaml/issues/13388>
[#13540] <https://github.com/ocaml/ocaml/issues/13540>
◊ Compiler flag
• [#13471]: add `-keywords <version?+list>' flag to define the list of
keywords recognized by the lexer, for instance `-keywords 5.2'
disable the `effect' keyword. (Florian Angeletti, review by Gabriel
Scherer)
[#13471] <https://github.com/ocaml/ocaml/issues/13471>
◊ Runtime event library fixes
• [#13419]: Fix memory bugs in runtime events system. (B. Szilvasy
and Nick Barnes, review by Miod Vallat, Nick Barnes, Tim
McGilchrist, and Gabriel Scherer)
• [#13407]: Add Runtime_events.EV_EMPTY_MINOR (Thomas Leonard)
• [#13522]: Confirm runtime events ring is still active after
callback. (KC Sivaramakrishnan, review by Sadiq Jaffer and Miod
Vallat)
• [#13529]: Do not write to event ring after going out of stw
participant set. (KC Sivaramakrishnan, review by Sadiq Jaffer)
[#13419] <https://github.com/ocaml/ocaml/issues/13419>
[#13407] <https://github.com/ocaml/ocaml/issues/13407>
[#13522] <https://github.com/ocaml/ocaml/issues/13522>
[#13529] <https://github.com/ocaml/ocaml/issues/13529>
◊ Documentation
• [#13424]: Fix `Gc.quick_stat' documentation to clarify that returned
fields `live_words', `live_blocks', `free_words', and `fragments'
are not zero. (Jan Midtgaard, review by Damien Doligez and KC
Sivaramakrishnan)
• [#13440]: Update documentation of `Gc.{control,get,set}' to reflect
fields not currently supported on OCaml 5. (Jan Midtgaard, review
by Gabriel Scherer)
• [#13469], [#13474], [#13535]: Document that [Hashtbl.create n]
creates a hash table with a default minimal size, even if [n] is
very small or negative. (Antonin Décimo, Nick Bares, report by
Nikolaus Huber and Jan Midtgaard, review by Florian Angeletti, Anil
Madhavapeddy, Gabriel Scherer, and Miod Vallat)
[#13424] <https://github.com/ocaml/ocaml/issues/13424>
[#13440] <https://github.com/ocaml/ocaml/issues/13440>
[#13469] <https://github.com/ocaml/ocaml/issues/13469>
[#13474] <https://github.com/ocaml/ocaml/issues/13474>
[#13535] <https://github.com/ocaml/ocaml/issues/13535>
◊ Standard library internal fix
• [#13543]: Remove some String-Bytes conversion from the stdlib to
behave better with js_of_ocaml (Hugo Heuzard, review by Gabriel
Scherer)
[#13543] <https://github.com/ocaml/ocaml/issues/13543>
◊ Toplevel fix
• [#13263], [#13560]: fix printing true and false in toplevel and
error messages (no more unexpected #true) (Florian Angeletti, report
by Samuel Vivien, review by Gabriel Scherer)
[#13263] <https://github.com/ocaml/ocaml/issues/13263>
[#13560] <https://github.com/ocaml/ocaml/issues/13560>
◊ Compiler internals
• [#13391], [#13551]: fix a printing bug with `-dsource' when using
raw literal inside a locally abstract type constraint (i.e. `let f:
type #for. ...') (Florian Angeletti, report by Nick Roberts, review
by Richard Eisenberg)
[#13391] <https://github.com/ocaml/ocaml/issues/13391>
[#13551] <https://github.com/ocaml/ocaml/issues/13551>
dune 3.16
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-16/14889/2>
Etienne Marais announced
────────────────────────
We have release 3.16.1. This is a minor release of Dune to correct a
bug related to the C++ compile. It comes with the following changes:
3.16.1 (2024-10-30)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Fixed
• Call the C++ compiler with `-std=c++11' when using OCaml >= 5.0
(#10962, @kit-ty-kate)
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Making Crypto Safer: Introducing the ARGOS Project]
• [Postes, télégraphes et téléphones, next steps]
• [GPTar (update)]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Making Crypto Safer: Introducing the ARGOS Project]
<https://tarides.com/blog/2024-10-30-making-crypto-safer-introducing-the-argos-project>
[Postes, télégraphes et téléphones, next steps]
<https://blog.robur.coop/articles/2024-10-29-ptt.html>
[GPTar (update)] <https://blog.robur.coop/articles/gptar-update.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 27531 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-10-29 13:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-10-29 13:30 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 11292 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 22 to 29,
2024.
Table of Contents
─────────────────
HOL Light released to OPAM
Could we add a tiny OCaml interpreter to Numworks graphical calculators?
opam 2.3.0~beta2
Editors dev-meeting #4, Thu. 31th: Search by type à la Sherlodoc 🕵️
Dune dev meeting
Shell Completions in Dune Developer Preview
Other OCaml News
Old CWN
HOL Light released to OPAM
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-hol-light-released-to-opam/15488/1>
Juneyoung Lee announced
───────────────────────
The HOL Light interactive theorem prover written by John Harrison is
released to OPAM as a package. Its first new version available on OPAM
is 3.0. It now provides `hol.sh' which is a script that will launch
an OCaml REPL that enables interactive theorem proving. Combined with
a VSCode plugin for HOL Light, this gives a nice theorem proving
experience..! For more details, please visit:
• The website: <https://hol-light.github.io/>
• The main repo: <https://github.com/jrh13/hol-light/>
Could we add a tiny OCaml interpreter to Numworks graphical calculators?
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/could-we-add-a-tiny-ocaml-interpreter-to-numworks-graphical-calculators/7652/14>
Deep in this thread, Lilian Besson announced
────────────────────────────────────────────
So after a few hours of work, we've successfully ported the OMicroB
Virtual Machine for OCaml to the Numworks calculator :tada: ! See
[this part of our discussion on GitHub], if anyone is curious.
But we're far away from being done! Indeed, I want to be able to
interpret *on the calculator* some OCaml line of code / or entire
file. I know it's probably going to be hard, if not entirely
impossible, but hey we've at least progressed a bit in this direction!
Thanks @borisd again for the suggestion! @Vertmo is helping me on
this issue, thanks to him.
[this part of our discussion on GitHub]
<https://github.com/stevenvar/OMicroB/issues/36#issuecomment-2432041168>
opam 2.3.0~beta2
════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-3-0-beta2/15496/1>
Kate announced
──────────────
We're happy to announce the second beta release of opam 2.3.0.
As we're closing on the final release of opam 2.3.0, we'd be happy for
people to test this beta and report any regression.
What's new?
╌╌╌╌╌╌╌╌╌╌╌
This release consists mostly in one regression fix compared to
2.3.0~beta1:
• Fix a regression in the detection of the current terminal size that
leads to opam output that tries to fit itself into 80 columns
regardless of the current terminal size ([#6243])
A couple of other improvements were made. :open_book: You can read
our [blog post] for more information, and for even more details you
can take a look at the [release note] or the [changelog].
[#6243] <https://github.com/ocaml/opam/issues/6243>
[blog post] <https://opam.ocaml.org/blog/opam-2-3-0-beta2/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.3.0-beta2>
[changelog] <https://github.com/ocaml/opam/blob/2.3.0-beta2/CHANGES>
Try it!
╌╌╌╌╌╌╌
The upgrade instructions are pretty much the same:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~beta2"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~beta2"
└────
Please report any issues to [the bug-tracker].
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Editors dev-meeting #4, Thu. 31th: Search by type à la Sherlodoc 🕵️
══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-editors-dev-meeting-4-thu-31th-search-by-type-a-la-sherlodoc/15507/1>
vds announced
─────────────
We are organizing the next public dev-meeting on next Thursday, the
31th of October at 5pm CEST (we have a local speaker). Whether you are
a long time maintainer, an occasional contributor, a new comer, or
simply a curious passer-by, please feel free to attend!
:sparkles: For this session, @xvw is going to present a new Merlin
feature: an alternative to polarity search that can search for values
in the environment with a syntax similar as the one of the amazing
[Sherlodoc].
<https://global.discourse-cdn.com/flex020/uploads/ocaml/original/2X/2/2616c436ecefca9526d1f8bc5d106faa90c5219a.gif>
:clipboard: Meeting agenda:
• A tour-de-table to allow the participants that wish to do so to
present themselves and mention issues / prs they are interested in.
• Talk and Q&A
• Discuss issues and pull requests that were tagged in advance or
mentioned during the tour-de-table.
We’re looking forward to meeting you!
Meeting link:
[meet.google.com/ncb-mnmp-kmk](meet.google.com/ncb-mnmp-kmk)
Previous meeting notes are available in [Merlin’s repository wiki ].
[Sherlodoc] <https://doc.sherlocode.com/>
[Merlin’s repository wiki ]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/15>
Etienne Marais announced
────────────────────────
We will hold our regular Dune dev meeting tomorrow, on *Wednesday,
October, 30th at 16:00 CET.* As usual, the session will be one hour
long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers
:speech_balloon:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-10-30>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Shell Completions in Dune Developer Preview
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/shell-completions-in-dune-developer-preview/15522/1>
Steve Sherratt announced
────────────────────────
Support for dune shell completions for bash and zsh has just landed in
the [Dune Developer Preview]!
Running the [installer] adds a snippet to your shell config
(e.g. `/.bashrc) that installs a completion handler for ~dune'. The
completion script was taken from [here], and that page has some
information about how the script was generated. Once it's installed
the completions will work any time `dune' is typed at the start of a
command, so you can still use the completions when running a version
of Dune installed with Opam or your system package manager after
installing the Dune Developer Preview.
Currently only command completions are supported. So you can run:
┌────
│ $ dune c<TAB>
│ cache clean coq
└────
…or:
┌────
│ $ dune build -<TAB>
│ --action-stderr-on-success
│ --action-stdout-on-success
│ --always-show-command-line
│ --auto-promote
│ --build-dir
│ --build-info
│ --cache
│ ...
└────
But if you run `dune build <TAB>' then it will still suggest local
files rather than build targets.
[Dune Developer Preview] <https://preview.dune.build/>
[installer] <https://preview.dune.build/#download>
[here] <https://github.com/gridbugs/dune-completion-scripts>
Try it out!
╌╌╌╌╌╌╌╌╌╌╌
Getting started is easy:
┌────
│ $ curl -fsSL https://get.dune.build/install | sh
│ $ source ~/.bashrc # or: ~source ~/.zshrc~ or just restart your shell
│ $ dune <TAB>
│ build
│ cache
│ clean
│ coq
│ describe
│ diagnostics
│ exec
│ ...
└────
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel]
• [Looking Back on our Experience at ICFP!]
• [Runtime arguments in MirageOS]
• [How has robur financially been doing since 2018?]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel]
<https://blog.robur.coop/articles/dnsvizor01.html>
[Looking Back on our Experience at ICFP!]
<https://tarides.com/blog/2024-10-23-looking-back-on-our-experience-at-icfp>
[Runtime arguments in MirageOS]
<https://blog.robur.coop/articles/arguments.html>
[How has robur financially been doing since 2018?]
<https://blog.robur.coop/articles/finances.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 22074 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-10-22 12:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-10-22 12:42 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 15141 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 15 to 22,
2024.
Table of Contents
─────────────────
opam 2.3.0~beta1
Dune dev meeting
Wildcard expansion on Windows
OCamlformat and GitHub actions
New vs. Old OCaml Academic Users Page Survey
New vs. Old OCaml Industrial Users Page
Eliom 11 and Ocsigen Start 7
Other OCaml News
Old CWN
opam 2.3.0~beta1
════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-3-0-beta1/15450/1>
Kate announced
──────────────
We're happy to announce the first beta release of opam 2.3.0.
As we're closing on the final release of opam 2.3.0, we'd be happy for
people to test this beta and report any regression.
What's new?
╌╌╌╌╌╌╌╌╌╌╌
This release consists mostly in regression fixes compared to
2.3.0~alpha1:
• Fix a regression where pinning a local source repository containing
initialized git submodules would cause a failure when fetching the
package. ([#5809])
• Fix a regression which would make opam crash on platforms such as
OpenBSD. ([#6215])
• Fix the internal cache of installed packages, which was storing the
wrong version of the opam file after a build failure. ([#6213])
• Fix a regression in lint W59 with local urls that are not
archives. ([#6218])
A couple of other improvements were made and bugs were fixed.
:open_book: You can read our [blog post] for more information about
these changes and more, and for even more details you can take a look
at the [release note] or the [changelog].
[#5809] <https://github.com/ocaml/opam/issues/5809>
[#6215] <https://github.com/ocaml/opam/issues/6215>
[#6213] <https://github.com/ocaml/opam/pull/6213>
[#6218] <https://github.com/ocaml/opam/issues/6218>
[blog post] <https://opam.ocaml.org/blog/opam-2-3-0-beta1/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.3.0-beta1>
[changelog] <https://github.com/ocaml/opam/blob/2.3.0-beta1/CHANGES>
Try it!
╌╌╌╌╌╌╌
The upgrade instructions are pretty much the same:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~beta1"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~beta1"
└────
Please report any issues to [the bug-tracker].
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/14>
Steve Sherratt announced
────────────────────────
Notes from today's dune-dev meeting are [here]
[here] <https://github.com/ocaml/dune/wiki/dev-meeting-2024-10-16>
Wildcard expansion on Windows
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/wildcard-expansion-on-windows/15461/1>
Benjamin Sigonneau announced
────────────────────────────
While implementing a small CLI tool, I ran into a somehow undocumented
feature of the Ocaml compiler: it automatically expands wildcards
before doing anything else. Which proved to be a problem.
This post serves three different goals:
• give some visibility, in case someone else run into this issue in
the future
• expose a possible workaround
• ask the community if there is a better way™ to solve this
Context
╌╌╌╌╌╌╌
My tool uses `Cmdliner' for CLI args processing, and needs to handle
basic wildcard processing for one of its options, eg. it should handle
`mytool.exe -x *.ml'.
This would get expanded to `mytool.exe -x a.ml b.ml c.ml' which
Cmdliner cannot handle. Under any common Unix shell, this is not a
problem: we just have to escape the star character with
eg. `mytool.exe -x \*.ml', have mytool handle the expansion itself and
we're all set. So far, so good.
Then came Windows. Whatever I would do, it seemed like there was no
way of preventing that wildcard to be expanded. I learned that on
Windows, the calling program was responsible for dealing with
wildcards, not the shell. After some digging, the root cause of this
behaviour was found in the ocaml runtime itself, in
[`runtime/main.c']:
┌────
│ int main_os(int argc, char_os **argv)
│ {
│ #ifdef _WIN32
│ /* Expand wildcards and diversions in command line */
│ caml_expand_command_line(&argc, &argv);
│ #endif
│
│ /* [...] */
│ }
└────
After a bit of history digging, it turns out this behaviour dates back
from the very early stages of the Ocaml compiler, see [this commit] by
Xavier Leroy from… 1996!
[`runtime/main.c']
<https://github.com/ocaml/ocaml/blob/a07799fceac25e2b2b81f3d2bab64d87ad5cec8d/runtime/main.c#L32>
[this commit]
<https://github.com/ocaml/ocaml/commit/4426de9a130b4abef0f417b3a396a3aed70528c2>
Workaround
╌╌╌╌╌╌╌╌╌╌
The `runtime/main.c' file gives a hint on how to work around this:
┌────
│ /* Main entry point (can be overridden by a user-provided main()
│ function that calls caml_main() later). */
└────
So the most elegant workaround I could find was to create a copy of
the `main.c' file inside the source tree of mytool and comment out the
call to `caml_expand_command_line'. Then it was a matter of compiling
and linking everything altogether. I use `dune' to compile
`mytool.exe', and after a lot of trial-and-error, I found out it could
handle this very easily with the `foreign_stubs' stanza:
┌────
│ (executable
│ (name mytool)
│ (foreign_stubs (language c) (names main))
│ ; ...
│ )
└────
Minimal working example
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I opened a Github repository containing a minimal project featuring a
custom entry point so that command-line arguments expansion does not
happen on Windows.
See: <https://github.com/benji-sb/ocaml-windows-argv>
Open Questions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• The root cause of this issue was introduced almost 30 years ago. How
come no one on the Internets seem to have run into a similar issue?
• Why was this behaviour introduced in the first place? I suspect it
may have make it easier to setup a Windows toolchain back then, but
that's just wild speculation.
• Is this behaviour still needed, or could we get rid of it?
• Should this be more wildly documented, and if so, where? The ocaml
compiler docs and the dune docs could probably benefit from a small
paragraph on how to override the default entry point.
OCamlformat and GitHub actions
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocamlformat-and-github-actions/15464/1>
Hannes Mehnert announced
────────────────────────
a small announcement for those using OCamlformat in their projects: if
you find the burden on external contributors very high, and always
express "please run ocamlformat on your PR" – we've been in the same
boat.
We developed a GitHub action which automatically runs OCamlformat and
pushes that on the PR. No need for contributors to remember running
OCamlformat, no need for "OCaml-CI" to fail since ocamlformat run
diverges.
If you're interested, take a look at
<https://github.com/robur-coop/mollymawk/blob/main/.github/workflows/format.yml>
– please note that we use `find . -name \*ml -maxdepth 1' – depending
on your project you may be able to run `dune bu @fmt --auto' (or need
a slightly different `find' to look deeper or also for mli files).
Happy to share this action which turned out to be tremendously useful
for some of our projects.
New vs. Old OCaml Academic Users Page Survey
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/new-vs-old-ocaml-academic-users-page-survey/15484/1>
Claire Vandenberghe announced
─────────────────────────────
We've recently *redesigned the OCaml Academic Users page* and would
love to *get your feedback* to ensure it’s as helpful as possible. You
can view both versions here:
• New page:[ ocaml.org/academic-users]
• Old page:[ staging.ocaml.org/academic-users]
As a teacher, student expert or beginner developer using OCaml, we’d
greatly appreciate your insights! Participate in the survey here:
[https://docs.google.com/forms/d/e/1FAIpQLSfc9qPR16deJ6VeVmXGXPVO4e3wZ9ZVIYiWrS4f1RZsqcXxwQ/viewform?usp=sf_link]
or we can discuss this topic below :)
Do you find the new page more useful and relevant for your academic
needs compared to the old one? If so, why?
Is there any information missing or anything you’d suggest improving
on the new page?
Your feedback is incredibly valuable to us as we work to improve the
experience for the OCaml community.
Thank you in advance!
[ ocaml.org/academic-users] <https://ocaml.org/academic-users>
[ staging.ocaml.org/academic-users]
<https://staging.ocaml.org/academic-users>
[https://docs.google.com/forms/d/e/1FAIpQLSfc9qPR16deJ6VeVmXGXPVO4e3wZ9ZVIYiWrS4f1RZsqcXxwQ/viewform?usp=sf_link]
<https://Survey>
New vs. Old OCaml Industrial Users Page
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/new-vs-old-ocaml-industrial-users-page/15485/1>
Claire Vandenberghe announced
─────────────────────────────
We've recently redesigned the *OCaml Industrial Users pages* and would
love to get *your feedback* to ensure it’s as helpful as possible. You
can view both versions here:
• New: <https://ocaml.org/industrial-users>
• Old: <https://staging.ocaml.org/industrial-users>
As an expert or beginner developer using OCaml, we’d greatly
appreciate your insights! You can also participate to the survey here:
<https://forms.gle/C7czFt36m7bx4fLt8> or we can discuss this topic
below :)
Do you find the new page more useful and relevant for industrial needs
compared to the old one? If so, why?
Is there any information missing or anything you’d suggest improving
on the new page?
Your feedback is incredibly valuable to us as we work to improve the
experience for the OCaml community.
Thank you in advance!
Eliom 11 and Ocsigen Start 7
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-eliom-11-and-ocsigen-start-7/15487/1>
Vincent Balat announced
───────────────────────
Eliom 11 and Ocsigen Start 7 have been released a few weeks ago.
These versions follow the recent release of Ocsigen Server 6 and
leverage its new configuration API to make it easier to use it as a
library, without a configuration file.
Here is an example of a simple OCaml app generating a Web page from
server side (and serving static pages from directory
`"local/var/www/mysite"'):
┌────
│ let f _ () =
│ Lwt.return
│ Eliom_content.Html.F.(html (head (title (txt "")) [])
│ (body [h1 [txt "Hello"]]))
│
│ let myservice =
│ Eliom_service.create
│ ~path:(Eliom_service.Path [])
│ ~meth:(Eliom_service.Get Eliom_parameter.any)
│ ()
│
│ let () = Eliom_registration.Html.register ~service:myservice f
│
│ let () = Ocsigen_server.start
│ [ Ocsigen_server.host
│ [ Staticmod.run ~dir:"local/var/www/mysite" ()
│ ; Eliom.run () ] ]
└────
To use it, just install Eliom and your favorite version of Ocipersist,
then create a new Dune project:
┌────
│ opam install ocsipersist-sqlite-config eliom
│ dune init project mysite
└────
Put the code above in file `bin/mysite.ml'
Update file `bin/dune':
┌────
│ (executable
│ (public_name mysite)
│ (name main)
│ (libraries
│ ocsigenserver
│ ocsigenserver.ext.staticmod
│ ocsipersist-sqlite
│ eliom.server))
└────
Build and execute:
┌────
│ dune exec mysite
└────
Open URL `http://localhost:8080/'.
Ocsigen Start's application template has been updated to support both
the use as an executable or as a library (lynked dynamically from the
server's config file).
Links:
• [Ocsigen]
• [Github]
[Ocsigen] <https://ocsigen.org/>
[Github] <https://github.com/ocsigen>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Developer education at Jane Street]
• [Dune Developer Preview: Installing The OCaml Compiler With Dune
Package Management]
• [Upcoming OCaml Events]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Developer education at Jane Street]
<https://blog.janestreet.com/developer-education-at-jane-street-index/>
[Dune Developer Preview: Installing The OCaml Compiler With Dune Package
Management]
<https://tarides.com/blog/2024-10-16-dune-developer-preview-installing-the-ocaml-compiler-with-dune-package-management>
[Upcoming OCaml Events] <https://ocaml.org/events>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 28833 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-10-15 13:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-10-15 13:31 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 14506 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 08 to 15,
2024.
Table of Contents
─────────────────
grep_cmt: structural search of OCaml code
Mutaml 0.1
ocaml-activitypub
Ortac/QCheck-STM 0.4.0 Dynamic formal verification beyond one system under test
Openbsd 1.0
Compsort - reorder files in archives for improved compression
Dune dev meeting
Other OCaml News
Old CWN
grep_cmt: structural search of OCaml code
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-poc-grep-cmt-structural-search-of-ocaml-code/15411/1>
Nicolas Ojeda Bar announced
───────────────────────────
As mentioned in a previous post:
<https://discuss.ocaml.org/t/ann-2nd-editor-tooling-dev-meeting-25th-of-july/14953/5?u=nojb>
I had promised to post back here when we had made the source code for
the "structural grep" tool that I presented, public.
This is now done:
<https://github.com/LexiFi/grep_cmt>
We added a `[POC]' marker to this post, because the code is not really
ready for public consumption (it is rough around the edges and may not
work in all circumstances). Our hope is to publicize the approach and
perhaps motivate interested hackers to take the code and develop it
further into a proper tool.
Mutaml 0.1
══════════
Archive: <https://discuss.ocaml.org/t/ann-mutaml-0-1/12639/2>
Jan Midtgaard announced
───────────────────────
I'm happy to share news of the Mutaml 0.3 release! :tada:
<https://github.com/jmid/mutaml/releases/tag/0.3>
Together with the recent 0.2 release, this brings Mutaml up to speed
with recent ppxlib releases and addresses a few issues reported by
brave, early users:
• Avoid mutations in attribute parameters #29
• Avoid polymorphic equality which is incompatible with Core #30
• Add support for ppxlib.0.28 and above #27
• Avoid triggering 2 mutations of a pattern incl. a `when'-clause
causing a redundant sub-pattern warning #22, #23
Happy testing! :smiley:
ocaml-activitypub
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-activitypub/15420/1>
Zoggy announced
───────────────
I'm glad to announce a first release of `activitypub*' packages,
implementing (well, trying to implement some flavor of) both
[server-to-server] and [client-to-server] activitypub protocols.
Documentation is available from the [web site].
The `activitypub_server' package installs [TAPS], an experimental
server, handling some common activities. Accounts hosted by this
server can at least follow and be followed by mastodon instances, and
post and receive activities (Create, Announce, Like, Undo, …).
The library of the `activitypub_client' package can be used by a
client application to post and receive activities to and from a server
(though it was only tested with TAPS). See a simple example [here].
A GUI client (based on [Stk] is installed by the `activitypub_gui'
package. It requires a client configuration file as described
[here]. You can drop IRIs/URLs of an actor in the window to open a tab
and be able to follow this actor. The GUI also allows to create and
post notes with attachments. This client is still very experimental
and will be developed more in the future.
EDIT: the package should be available soon in opam.
[server-to-server]
<https://www.w3.org/TR/activitypub/#server-to-server-interactions>
[client-to-server]
<https://www.w3.org/TR/activitypub/#client-to-server-interactions>
[web site] <https://zoggy.frama.io/activitypub/>
[TAPS] <https://zoggy.frama.io/activitypub/doc-taps.html>
[here] <https://zoggy.frama.io/activitypub/doc-client-example.html>
[Stk] <https://zoggy.frama.io/ocaml-stk/>
[here]
<https://zoggy.frama.io/activitypub//refdoc/activitypub_client/Activitypub_client/Main/index.html>
Ortac/QCheck-STM 0.4.0 Dynamic formal verification beyond one system under test
═══════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ortac-qcheck-stm-0-4-0-dynamic-formal-verification-beyond-one-system-under-test/15427/1>
Nicolas Osborne announced
─────────────────────────
I'm very pleased to announce this exciting new release of
`ortac-qcheck-stm.0.4.0'!
This new release brings some exciting new features, mostly the result
of Nikolaus Huber's contributions! Thank you Nik!
Ortac/QCheck-STM is a test generator based on the [QCheck-STM]
model-based testing framework and the [Gospel] specification language
for OCaml.
You can find the project on [this repo] and install the released
packages via `opam'.
It is also encourage to install `ortac-dune' to avoid having to write
too much dune boilerplate.
In particular, this release extend Ortac/QCheck-STM so that the
generated tests will include functions that can take multiple
System-Under-Tests as argument and/or that can return one. So now, if
we write Gospel specifications for `append'-like functions,
Ortac/QCheck-STM will include them in the generated tests!
Happy testing!
[QCheck-STM] <https://github.com/ocaml-multicore/multicoretests>
[Gospel] <https://github.com/ocaml-gospel/gospel>
[this repo] <https://github.com/ocaml-gospel/ortac>
Openbsd 1.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-openbsd-1-0/15434/1>
Sebastien Marie announced
─────────────────────────
I would like to announce a new (somehow niche) package [Openbsd],
which provides bindings for some specifics OpenBSD syscalls
[pledge(2)] and [unveil(2)].
These syscalls lets the kernel OS to know what the running processus
is expected to do, and so it is possible to restrict a processus to do
only filesystem or only network or only pure computation…
The package is designed to be installable on any platform and provides
simple method to check if `Pledge' or `Unveil' are supported. This
way, it is possible to easily write portable code using the package,
as it could be a turned on "no-operation" on Windows or Linux hosts
(or provides alternative code path for sandboxing).
• Homepage : [https://codeberg.org/semarie/ocaml-openbsd/]
• License : [ISC]
• Documented Interface : [lib/openbsd.mli]
[Openbsd] <https://ocaml.org/p/openbsd/latest>
[pledge(2)] <https://man.openbsd.org/pledge.2>
[unveil(2)] <https://man.openbsd.org/unveil.2>
[https://codeberg.org/semarie/ocaml-openbsd/]
<https://codeberg.org/semarie/ocaml-openbsd/>
[ISC] <https://en.wikipedia.org/wiki/ISC_license>
[lib/openbsd.mli]
<https://codeberg.org/semarie/ocaml-openbsd/src/tag/1.0/lib/openbsd.mli>
Examples
╌╌╌╌╌╌╌╌
┌────
│ let open Openbsd in
│ if Pledge.supported then
│ Pledge.promises "stdio rpath"
└────
┌────
│ let open Openbsd in
│ if Unveil.supported then (
│ Unveil.add "./lib" "r";
│ Unveil.add "./logs" "rwc";
│ Unveil.lock ())
└────
Compsort - reorder files in archives for improved compression
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-compsort-reorder-files-in-archives-for-improved-compression/15436/1>
adrien announced
────────────────
I'm happy to announce the first release of compsort, a tool to reorder
files in an archive for better compression. It works by grouping files
according to a distance that is computed between every file pair. You
can install it with `opam install compsort' (requires ocaml 5.2 for
parallelism).
Website with more details and examples in `README.md', plus source:
<https://gitlab.com/adrien-n/compsort/>
The goal is not new but, AFAIK, the approach is. I am very interested
in prior or related art!
Results
╌╌╌╌╌╌╌
Compsort achieves improvements that would typically require larger
compression windows and therefore more memory. The improvements are
only a few percents but in the domain of compression, a few percents
is actually a lot.
With `xz' compression, a Ubuntu initrd on my machine is reduced by
more than 11.5%, while the best achievable improvement is 12.7% (the
reordering gives 90% of the best result). Similarly, the tree of
`linux-firmware.git' can be compressed 6% better, while the best
achievable improvement is 9.4% (the reordering gives 63% of the best
result).
Visualizations
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In order to better explain what it does, I quite like the
visualizations I have so far (there will be better ones in the
future), where the value of the pixel at `(x,y)' indicates how similar
are files `x' and `y'.
Before:
<https://gitlab.com/adrien-n/compsort/-/raw/main/doc/img/bettercomp_python3-django-horizon_noop.png>
After reordering:
<https://gitlab.com/adrien-n/compsort/-/raw/main/doc/img/bettercomp_python3-django-horizon_buckets.png>
Files that are very different from others are all packed at the end
and there's also an isolated cluster of files together similar but
different from everything else. One can also see that the distinct
row and column pattern from the first picture has disappeared: it
indicated that every 15 or so files in that region were similar and
were separated by disimilar files but that they're now grouped.
While there are certainly improvements possible, results are
good. It's a case where one might wonder why results are so good
considering all the approximations that took place.
[1] Most of the algorithms/libraries I've tried to use rely on having
an actual proper distance function which I don't have
Future work
╌╌╌╌╌╌╌╌╌╌╌
I'll try to improve the distance function. Currently it does some
steps of compression algorithms to detect redundancies but maybe
reusing a compression library would give better results if it can be
made fast enough (lz4 is borderline but it has tiny dictionaries
unfortunately).
Clustering could be better as the current algorithm is very basic (it
collects files that are 90% similar, then 80% similar, then 70%, …). I
tried several algorithms but I don't have a good-enough distance
function (for instance the triangular inequality probably doesn't
hold) and results were worse.
All this will benefit from better visualizations and I'd like to have
interactive plots that can be hovered on with the mouse to get the
distance value and full file name.
Oh and code isn't always pretty as it went through a lot of
experimental stages and low-level tweaks to improve performance.
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/13>
Etienne Marais announced
────────────────────────
We will hold our regular Dune dev meeting tomorrow, on _Wednesday,
October, 16th at 10:00 CET_. As usual, the session will be one hour
long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers !
Agenda
╌╌╌╌╌╌
The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.
[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-10-16>
Links
╌╌╌╌╌
• Meeting link:[ zoom]
• Calendar event:[ google calendar]
• Wiki with information and previous notes:[ GitHub Wiki]
[ zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[ google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[ GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The Uncertain Art of Accelerating ML Models with Sylvain Gugger]
• [Dune Package Management: Revolutionising OCaml Development]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The Uncertain Art of Accelerating ML Models with Sylvain Gugger]
<https://signals-threads.simplecast.com/episodes/the-uncertain-art-of-accelerating-ml-models-with-sylvain-gugger-moYuL4Ps>
[Dune Package Management: Revolutionising OCaml Development]
<https://tarides.com/blog/2024-10-09-dune-package-management-revolutionising-ocaml-development>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26875 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-10-08 10:56 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-10-08 10:56 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 31022 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 01 to 08,
2024.
Table of Contents
─────────────────
Releases of fpath-sexplib0, fpath-base, loc, file-rewriter, sexps-rewriter and provider
Build a project without Stdlib
obatcher: Framework for building efficient concurrent services
DBLP query program and library
cudajit: Bindings to the `cuda' and `nvrtc' libraries
YOCaml, a framework for static site generator
oepub 0.1.0 : A library to parse epub files
ppx_deriving_router — type safe routing for Dream and Melange
Mica, a PPX that automates differential testing for OCaml modules
Simplified Android cross-compiler with DkML
Other OCaml News
Old CWN
Releases of fpath-sexplib0, fpath-base, loc, file-rewriter, sexps-rewriter and provider
═══════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/releases-of-fpath-sexplib0-fpath-base-loc-file-rewriter-sexps-rewriter-and-provider/15364/1>
Mathieu Barbin announced
────────────────────────
I wanted to announce the initial release of 6 utility packages to the
opam-repository. They are dependencies to some other ongoing projects
I have, perhaps some will find them useful.
These are very early days for this software. Please feel welcome to
opening issues or discussions tickets if you are inclined.
Thank you @mseri , @avsm & @shonfeder for your help in making these
libraries available!
Below you'll find short descriptions with links to the packages home
pages. Thank you!
[Fpath_sexplib0] only depends on `fpath' and `sexplib0'. It defines a
single module, `Fpath_sexplib0', which is designed to be opened to
shadow the `Fpath' module to add small helpers and a `sexp_of'
serializer to it. The package also introduces three new modules to the
scope: `Fpart', `Absolute_path' and `Relative_path' to increase
type-safety when manipulating paths that are known to be relative or
absolute.
[Fpath_base] further extends `fpath-sexplib0' and adds a dependency on
base. It is designed to be compatible with Base-style containers such
as `Map', `Set', `Hashtbl', `Hash_set'.
[Loc] is an OCaml library to manipulate code locations, which are
ranges of lexing positions from a parsed file.
[File_rewriter] is an OCaml library for applying small rewrites to
tweak or refactor your files. It provides a convenient interface to
apply surgical textual substitutions on the fly, while navigating the
contents of a file through an abstract representation containing code
locations.
[Sexps_rewriter] is a specialized version of the `file-rewriter'
library dedicated to rewriting sexp files, such as dune config files.
[Provider] is an OCaml library for creating Traits and Interfaces. It
allows you to define the functionality needed by a library without
committing to a specific implementation - in essence : dynamic
dispatch. Provider is a pattern featured in the `Eio' project
(`Eio.Resource'). I wanted to make it reusable in other projects - in
particular I am currently using it as the parametrization story of
`vcs'. This package had already been available for a little while
already but was still unannounced.
[Fpath_sexplib0] <https://github.com/mbarbin/fpath-base>
[Fpath_base] <https://github.com/mbarbin/fpath-base>
[Loc] <https://github.com/mbarbin/loc>
[File_rewriter] <https://github.com/mbarbin/file-rewriter>
[Sexps_rewriter] <https://github.com/mbarbin/file-rewriter>
[Provider] <https://github.com/mbarbin/provider>
Build a project without Stdlib
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/build-a-project-without-stdlib/15374/1>
Mikhail announced
─────────────────
I decided to experiment with compiling a project without the standard
library. Why? I don't know. But I could save ~50K. Just sharing my
note about it.
You can find an example in my [repository].
I found the `-nostdlib' and `-nopervasives' (undocumented) flags and
after a lot of trying I was able to do what I wanted. It doesn't
disable absolutely everything (lists and other types like `option' are
available).
┌────
│ (flags
│ :standard
│ -nostdlib
│ -nopervasives
│ ; add runtime
│ -cclib
│ -lasmrun
│ -ccopt
│ "-L %{ocaml_where}"
│ -ccopt
│ "-lm -ldl")
└────
┌────
│ (* stdlib.ml *)
│ external print_endline : string -> unit = "caml_print_endline" [@@noalloc]
│
│ (* main.ml *)
│ open Stdlib
│ let () = print_endline "hello from my stdlib"
└────
Hello World program:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
with Stdlib without Stdlib
─────────────────────────────────────
*size* 349K 302K
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[repository] <https://github.com/dx3mod/ocaml-without-stdlib>
obatcher: Framework for building efficient concurrent services
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-obatcher-framework-for-building-efficient-concurrent-services/15384/1>
Lee Koon Wen announced
──────────────────────
Hot on the heels of the paper [/"Concurrent Data Structures Made
Easy"/] appearing at [OOPSLA 2024] on the 24th October, I'm pleased to
announce release of *obatcher* - a _picos_ compatible library for
implementing efficient batched services in OCaml.
*obatcher* proposes a *new* way to approach the design and
implementation of concurrent services. It's key benefits are:
• Incremental optimization and parallelism of services
• Easy to control and reason about concurrency
• Retains atomic-style interface with your services while batching
happens implicitly
• Thread-safety for cheap!
Available on opam today, install with
┌────
│ opam install obatcher
└────
For more details, check out the source and README on GitHub:
[obatcher].
Feedback, contributions, and discussions are welcome!
[/"Concurrent Data Structures Made Easy"/]
<https://koonwen.github.io/assets/pdf/concurrent-structures-made-easy.pdf>
[OOPSLA 2024]
<https://2024.splashcon.org/details/splash-2024-oopsla/118/Concurrent-Data-Structures-Made-Easy>
[obatcher] <https://github.com/koonwen/obatcher>
DBLP query program and library
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dblp-query-program-and-library/15385/1>
Samuel Mimram announced
───────────────────────
I am happy to announce the first realease of [ocaml-dblp], which
provides both a program and a library to query the [DBLP]
bibliographic database. In practice, it is mostly useful for
retrieving bibtex entries with commands such as
┌────
│ dblp bibtex girard locus solum
└────
which will spit out
┌────
│ @article{DBLP:journals/mscs/Girard01,
│ author = {Jean{-}Yves Girard},
│ title = {Locus Solum: From the rules of logic to the logic of rules},
│ journal = {Math. Struct. Comput. Sci.},
│ volume = {11},
│ number = {3},
│ pages = {301--506},
│ year = {2001},
│ url = {https://doi.org/10.1017/S096012950100336X},
│ doi = {10.1017/S096012950100336X},
│ timestamp = {Wed, 01 Apr 2020 08:48:47 +0200},
│ biburl = {https://dblp.org/rec/journals/mscs/Girard01.bib},
│ bibsource = {dblp computer science bibliography, https://dblp.org}
│ }
└────
(or, even better, use `dblp bib' to directly add this at the end of
the `.bib' file in the current directory).
It might still need some polishing, feel free to reach out if you
encounter some problems.
[ocaml-dblp] <https://github.com/smimram/ocaml-dblp>
[DBLP] <https://dblp.org/>
cudajit: Bindings to the `cuda' and `nvrtc' libraries
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cudajit-bindings-to-the-cuda-and-nvrtc-libraries/15010/2>
Lukasz Stafiniak announced
──────────────────────────
cudajit 0.5.0 is now available in the opam repository. It's organized
into [modules], and it adds support for CUDA events.
[modules]
<https://lukstafi.github.io/ocaml-cudajit/cudajit/Cudajit/index.html>
YOCaml, a framework for static site generator
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-yocaml-a-framework-for-static-site-generator/15393/1>
Xavier Van de Woestyne announced
────────────────────────────────
:wave: Hello everyone! We, the YOCaml development team, are very
pleased to announce the release of [version 2], freshly merged into
[opam-repository] :champagne:!
*YOCaml is a framework for describing static site generators* (a very
small applicative build-system whose API is tailor-made for creating
web pages ) and its internal model is very similar to [Hakyll] (the
3th version), another Haskell framework. (a presentation was given to
the OCaml user Group in Paris and you can find the video, [in French,
here]).
[version 2] <https://github.com/xhtmlboi/yocaml/releases/tag/v2.0.0>
[opam-repository] <https://github.com/ocaml/opam-repository>
[Hakyll] <https://jaspervdj.be/hakyll/>
[in French, here]
<https://www.irill.org/videos/OUPS/2023-01/xavier-van-de-woestyne.html>
Changes with 1.0.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Historically, YOCaml was written very, very quickly to give examples
of slightly exotic uses of the library [Preface]. Due to its
experimental nature, the API was a bit laborious, but we did find some
users! We took advantage of the redesign to stop relying on Preface
(and yes, YOCaml was already more widely used than Preface), move to
OCaml 5.x and take advantage of _user-defined-effects_ and support
dynamic dependencies. In other words, YOCaml `2.0.0' is not at all
compatible with version 1…
[Preface] <https://github.com/xvw/preface>
Plugins and runtimes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The aim of YOCaml is to be very generic and to allow users to bring
their own dependencies, but we've taken the opportunity to release it
with several plugins and runtimes so that it can be used directly.
◊ Runtimes
A Runtime is an ‘execution context’ and generally exposes the
primitive used to execute a YOCaml program. YOCaml 2 is bundled with 3
Runtimes:
• *Yocaml_unix*: the default runtime, whose preview server is
implemented on top of the brand new [httpcats]!
• *Yocaml_eio*: a runtime iso to Unix but based on [eio] and whose
preview server is described by [cohttp_eio].
• *Yocaml_git*: a parameterised runtime for generating a site directly
in a git repository, which can be served, for example, by a
[Mirage] ([unipi]), very well documented in this [excellent
article] by @dinosaure!
[httpcats] <https://github.com/robur-coop/httpcats>
[eio] <https://github.com/ocaml-multicore/eio>
[cohttp_eio] <https://github.com/mirage/ocaml-cohttp>
[Mirage] <https://mirage.io/>
[unipi] <https://github.com/robur-coop/unipi>
[excellent article] <https://blog.osau.re/articles/blog_requiem.html>
◊ Plugins
• *Yocaml_cmarkit* provides a convenient API (via YOCaml) for
converting Markdown files to HTML via the excellent [cmarkit]
library.
• *Yocaml_omd* provides a convenient API (via YOCaml) for converting
Markdown files to HTML via the excellent [OMD] library (but we
recommend `yocaml_cmarkit').
• *yocaml_yaml* provides a convenient API (via YOCaml) for reading
Yaml via the excellent library [ocaml-yaml]
• *yocaml_otoml* provides a convenient API (for YOCaml) for reading
TOML via the excellent library [Otoml]
• *yocaml_mustache* provides a convenient API (via YOCaml) for using
[Mustache] as a template language via the excellent library
[ocaml-mustache]
• *yocaml_jingoo* provides a convenient API (via YOCaml) for using
[Jingoo] as a template language via the excellent library [jingoo]
• *yocaml_syndication* that gives tool to generate feeds
([Atom](<https://en.wikipedia.org/wiki/Atom_(web_standard)>), [RSS]
1 and 2 and [OPML]). The library is inspired by [Syndic] but does
not depend directly on it.
[cmarkit] <https://github.com/dbuenzli/cmarkit>
[OMD] <https://github.com/ocaml/omd>
[ocaml-yaml] <https://github.com/avsm/ocaml-yaml>
[Otoml] <https://github.com/dmbaturin/otoml>
[Mustache] <https://mustache.github.io/>
[ocaml-mustache] <https://github.com/rgrinberg/ocaml-mustache>
[Jingoo] <http://tategakibunko.github.io/jingoo/>
[jingoo] <https://github.com/tategakibunko/jingoo>
[RSS] <https://en.wikipedia.org/wiki/RSS>
[OPML] <https://opml.org/>
[Syndic] <https://github.com/Cumulus/Syndic>
A final word
╌╌╌╌╌╌╌╌╌╌╌╌
YOCaml 2 was mainly written by [xhtmlboi], helped by [gr-im], [mspwn]
and [dinosaure] with occasional support from [maiste]. It has already
been used experimentally in a number of small projects:
• [Ring.muhokama] a very small webring - [sources]
• [Maiste.fr] - [sources]
• [gr-im.github.io] - [sources]
You will also find extensively documented examples in the [examples]
directory.
To conclude, we find (not very objectively) that YOCaml is a lot of
fun to use, and it's very cool to make your site using as much OCaml
as possible.
Happy Hacking!
• [Yocaml on OPAM]
• [Dev repository]
[xhtmlboi] <https://github.com/xhtmlboi>
[gr-im] <https://github.com/gr-im>
[mspwn] <https://github.com/mspwn>
[dinosaure] <https://github.com/dinosaure>
[maiste] <https://github.com/maiste>
[Ring.muhokama] <https://ring.muhokama.fun>
[sources] <https://github.com/muhokama/ring>
[Maiste.fr] <https://maiste.fr>
[sources] <https://github.com/maiste/maiste.fr>
[gr-im.github.io] <https://gr-im.github.io>
[sources] <https://github.com/gr-im/site>
[examples] <https://github.com/xhtmlboi/yocaml/tree/main/examples>
[Yocaml on OPAM] <https://ocaml.org/p/yocaml/latest>
[Dev repository] <https://github.com/xhtmlboi/yocaml>
oepub 0.1.0 : A library to parse epub files
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-oepub-0-1-0-a-library-to-parse-epub-files/15394/1>
EruEri announced
────────────────
I humbly announce oepub a small library to parse epub files and to
some extend create a list of chapters from the epub archive.
You can find the repository at [Codeberg - Oepub]
[Codeberg - Oepub] <https://codeberg.org/EruEri/oepub>
ppx_deriving_router — type safe routing for Dream and Melange
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-deriving-router-type-safe-routing-for-dream-and-melange/15401/1>
Andrey Popp announced
─────────────────────
It's my pleasure to announce a new ppx for deriving [Dream] routers
based on variant type declarations, [ppx_deriving_router].
A small example. First we define routes (the signature showcases the
generated code):
┌────
│ module Pages : sig
│ ...
│
│ val href : t -> string
│ (** generate URL from the route *)
│
│ val http_method : t -> [ `DELETE | `GET | `POST | `PUT ]
│ (** HTTP method for the route *)
│
│ val handle : (t -> Dream.handler) -> Dream.handler
│ (** create a route handler *)
│ end = struct
│ open Ppx_deriving_router_runtime.Primitives
│
│ type t =
│ | Home [@GET "/"]
│ | About
│ | Hello of { name : string; repeat : int option } [@GET "/hello/:name"]
│ [@@deriving router]
│ end
└────
Then we describe how we handle each route:
┌────
│ let handle =
│ Pages.handle (fun route _req ->
│ match route with
│ | Home -> Dream.respond "Home page!"
│ | About -> Dream.respond "About page!"
│ | Hello { name; repeat } ->
│ let name =
│ match repeat with
│ | Some repeat ->
│ List.init repeat (fun _ -> name) |> String.concat ", "
│ | None -> name
│ in
│ Dream.respond (Printf.sprintf "Hello, %s" name))
│
│ let () = Dream.run ~interface:"127.0.0.1" ~port:8080 handle
└────
Using generated `Pages.href' function we can generate URLs for routes:
┌────
│ let () =
│ assert (Pages.href Home = "/");
│ assert (Pages.href About = "/about");
│ assert (Pages.href (Hello { name = "world"; repeat = None }) = "/hello/world");
│ assert (Pages.href (Hello { name = "world"; repeat = Some 3 }) = "/hello/world?repeat=3")
└────
The URL matching is done by [routes] library.
There's also support for [routes that track their response types] and
the ppx automatically derives JSON encoders and decoders for them (by
using [melange-json.ppx]).
On top of that a [separate ppx is provided] for [Melange] which allows
to construct type safe HTTP clients (route defintions are shared
between server and client).
Happy hacking!
[Dream] <https://aantron.github.io/dream/>
[ppx_deriving_router]
<https://github.com/andreypopp/ppx_deriving_router>
[routes] <https://anuragsoni.github.io/routes/>
[routes that track their response types]
<https://github.com/andreypopp/ppx_deriving_router#routes-with-typed-responses>
[melange-json.ppx]
<https://github.com/melange-community/melange-json?tab=readme-ov-file#ppx-for-melange>
[separate ppx is provided]
<https://github.com/andreypopp/ppx_deriving_router#using-with-melange>
[Melange] <https://melange.re/>
Mica, a PPX that automates differential testing for OCaml modules
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mica-a-ppx-that-automates-differential-testing-for-ocaml-modules/15406/1>
Ernest Ng announced
───────────────────
I'm delighted to announce the initial release of [Mica], a PPX deriver
that automates differential testing for a pair of OCaml modules
implementing the same signature. Users annotate module signatures with
the directive `[@@deriving mica]', and at compile-time, Mica derives
specialized [property-based testing] (PBT) code that checks if two
modules implementing the signature are observationally
equivalent. (Under the hood, Mica uses Jane Street's
[`Core.Quickcheck'] PBT library.)
Mica was presented at the OCaml Workshop '24 ([paper]) and the ICFP
'23 Student Research Competition ([poster]).
*Note*: Mica is currently a research tool and should not be used in
production code, although contributions are very welcome!
Mica is available on Opam:
┌────
│ opam update
│ opam install ppx_mica
└────
(OCaml 5.1 or newer is required.)
Docs are available [here], and a simple web app demo-ing Mica is
available [here].
[Mica] <https://github.com/ngernest/mica>
[property-based testing] <https://www.youtube.com/watch?v=qmA9qhaECcE>
[`Core.Quickcheck'] <https://blog.janestreet.com/quickcheck-for-core/>
[paper] <https://arxiv.org/abs/2408.14561>
[poster] <https://ngernest.github.io/pdfs/mica_icfp23src_poster.pdf>
[here] <https://ngernest.github.io/mica/ppx_mica/index.html>
[here] <https://ngernest.github.io/mica/demo.html>
Simplified Android cross-compiler with DkML
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-simplified-android-cross-compiler-with-dkml/15407/1>
jbeckford announced
───────────────────
DkML has had a cross-compiler for years, but I have cleaned it up so
that it is much easier to use for Android developers. It *now works
with a regular opam installation in a custom repository*. Also
included are patches to the OCaml compiler to work with Android NDK
21+ (currently Google is at NDK 27).
Try it out if you do Android development … just copy-and-paste the
instructions below … but please read the notes and cautions below. And
if you are still interested in Android development, tell me so I can
decide if I'll merge the packages into the regular opam repository.
Trimmed slightly from the [dkml-compiler Quick Start]:
• Docker container is used below for Windows and macOS users, and
because it is easy to get the Android NDK from CircleCI.
• Apple Silicon does not support 32-bit. The net effect is that Apple
Silicon users cannot cross-compile `android_arm32v7a'.
┌────
│ $ docker run -it --rm cimg/android:2024.10.1-ndk
│
│ # Install opam if you don't have it
│ ~/project$ sudo apt-get update && sudo apt-get install build-essential curl git patch rsync unzip -y
│ ~/project$ echo /usr/local/bin | sudo bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.2.1"
│
│ # Initialize opam if you haven't already. No sandboxing is needed in containers.
│ ~/project$ opam init --cli=2.1 --no-setup --bare --disable-sandboxing
│
│ # Two Android options to set. ANDROID_PLATFORM is the minimum API level ("targetSdkVersion" in the Android manifest)
│ ~/project$ opam var --cli=2.1 --global ANDROID_NDK=/home/circleci/android-sdk/ndk/27.1.12297006
│ ~/project$ opam var --cli=2.1 --global ANDROID_PLATFORM=android-34
│
│ # PICK ONE: Android arm64-v8a switch
│ ~/project$ opam switch create android34-ndk27-arm64-v8a --cli=2.1 \
│ --packages dkml-base-compiler,dkml-host-abi-linux_x86_64,dkml-target-abi-android_arm64v8a,ocamlfind,conf-dkml-cross-toolchain \
│ --repos default,diskuv-4d79e732=git+https://github.com/diskuv/diskuv-opam-repository.git#4d79e732
│
│ # PICK ONE: Android armeabi-v7a switch. You will need a 32-bit C/C++ compiler.
│ ~/project$ sudo apt-get install gcc-multilib g++-multilib -y
│ ~/project$ opam switch create android34-ndk27-armeabi-v7a --cli=2.1 \
│ --packages dkml-base-compiler,dkml-host-abi-linux_x86,dkml-target-abi-android_arm32v7a,ocamlfind,conf-dkml-cross-toolchain \
│ --repos default,diskuv-4d79e732=git+https://github.com/diskuv/diskuv-opam-repository.git#4d79e732
│
│ # PICK ONE: Android x86_64 switch
│ ~/project$ opam switch create android34-ndk27-x86_64 --cli=2.1 \
│ --packages dkml-base-compiler,dkml-host-abi-linux_x86_64,dkml-target-abi-android_x86_64,ocamlfind,conf-dkml-cross-toolchain \
│ --repos default,diskuv-4d79e732=git+https://github.com/diskuv/diskuv-opam-repository.git#4d79e732
│
│ # THEN: Get and cross-compile your source code. Here we use Dune and assume 'android34-ndk27-arm64-v8a'
│ ~/project$ opam install --cli=2.1 --switch android34-ndk27-arm64-v8a dune
│ ~/project$ git clone https://github.com/avsm/hello-world-action-ocaml hello
│ ~/project$ cd hello
│ ~/project/hello$ opam exec --cli=2.1 --switch android34-ndk27-arm64-v8a -- \
│ dune build -x android_arm64v8a world.exe
│
│ ~/project/hello$ file _build/default*/world.exe
│ _build/default.android_arm64v8a/world.exe: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, with debug_info, not stripped
│ _build/default/world.exe: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1731ad9ce0fdeff69df28af0b1217e843eabe26e, for GNU/Linux 3.2.0, with debug_info, not stripped
│
│ # You can also directly use the ocamlfind -toolchain
│
│ ~/project$ opam exec --cli=2.1 --switch android34-ndk27-arm64-v8a -- \
│ ocamlfind ocamlc -config-var native_c_compiler
│ gcc -O2 -fno-strict-aliasing -fwrapv -pthread -fPIC -D_FILE_OFFSET_BITS=64
│
│ ~/project$ opam exec --cli=2.1 --switch android34-ndk27-arm64-v8a -- \
│ ocamlfind -toolchain android_arm64v8a ocamlc -config-var native_c_compiler
│ /home/circleci/android-sdk/ndk/27.1.12297006/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android34-clang -O2 -fno-strict-aliasing -fwrapv -pthread -fPIC -D_FILE_OFFSET_BITS=64
└────
DkML supports three out of the four supported Android ABIs. The three
ABIs (all but `x86') were chosen based on [statistics for a large game
on Aug 29, 2023]:
━━━━━━━━━━━━━━━━━━━━━━
Arch Percent
──────────────────────
arm64-v8a 68.66
armeabi-v7a 30.38
x86_64 0.71
x86 0.26
━━━━━━━━━━━━━━━━━━━━━━
and also [Google's recommendation]:
*Note*: While 64-bit-only devices will grow in popularity with phones
joining Android Auto in this group, 32-bit-only devices will continue
to be important for Android Go, Android TV, and Android Wear. Please
continue supporting 32-bit ABIs; Google Play will continue serving
32-bit apps to 32-bit-only devices.
Finally, a word of *CAUTION*. The Android cross-compiler /can never/
use OCaml 5+ because [OCaml 5 will never bring back the 32-bit
instruction set]. That means if you don't want to drop a large percent
of your users or drop new Android categories over the next five (?)
years, you will have a critical dependency on DkML.
[dkml-compiler Quick Start]
<https://github.com/diskuv/dkml-compiler?tab=readme-ov-file#quick-start>
[statistics for a large game on Aug 29, 2023]
<https://github.com/android/ndk/issues/1772#issuecomment-1697831518>
[Google's recommendation]
<https://android-developers.googleblog.com/2022/10/64-bit-only-devices.html>
[OCaml 5 will never bring back the 32-bit instruction set]
<https://discuss.ocaml.org/t/32-bit-native-code-support-for-ocaml-5/12583/13?u=jbeckford>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Developer education at Jane Street]
• [Solving Puzzles in Production with Liora Friedberg]
• [MetAcsl v0.7 for Frama-C 29.0~ Copper]
• [Introducing the Dune Developer Preview: A New Era for OCaml
Development]
• [Unlock your Team’s Potential with Expert Training in OCaml,
Cybersecurity Fundamentals, Functional Programming, and More]
• [Alt-Ergo 2.6 is Out!]
• [Happy eyeballs?!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Developer education at Jane Street]
<https://blog.janestreet.com/developer-education-at-jane-street-index/>
[Solving Puzzles in Production with Liora Friedberg]
<https://signals-threads.simplecast.com/episodes/solving-puzzles-in-production-with-liora-friedberg-dk6vYnK2>
[MetAcsl v0.7 for Frama-C 29.0~ Copper]
<https://frama-c.com/fc-plugins/metacsl.html>
[Introducing the Dune Developer Preview: A New Era for OCaml
Development]
<https://tarides.com/blog/2024-10-03-introducing-the-dune-developer-preview-a-new-era-for-ocaml-development>
[Unlock your Team’s Potential with Expert Training in OCaml,
Cybersecurity Fundamentals, Functional Programming, and More]
<https://tarides.com/blog/2024-10-01-unlock-your-team-s-potential-with-expert-training-in-ocaml-cybersecurity-fundamentals-functional-programming-and-more>
[Alt-Ergo 2.6 is Out!]
<https://ocamlpro.com/blog/2024_09_01_alt_ergo_2_6_0_released>
[Happy eyeballs?!] <https://blog.osau.re/articles/happy_eyeballs.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 48034 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-10-01 13:37 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-10-01 13:37 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 24673 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 24 to
October 01, 2024.
Table of Contents
─────────────────
Dune Developer Preview Updates
Uuidm 0.9.9
first release of ppx_deriving_jsonschema
Bogue, the OCaml GUI
New release of Merlin
Releases of mirage-crypto 1.0.0, tls 1.0.0, x509 1.0.0, asn1-combinators 0.3.0, let's encrypt 1.0.0, awa 0.4.0, kdf 1.0.0, paf 0.7.0, git 3.17.0
ICFP 2023 OCaml Presentations on YouTube
Dune dev meeting
Other OCaml News
Old CWN
Dune Developer Preview Updates
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160/7>
ostera announced
────────────────
Hello folks! :wave:
Call for Feedback
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We'd like to welcome everyone to try and play with the [Dune Developer
Preview]! :tada:
This experimental nightly release of dune includes a lot of
improvements, including the much expected package management features,
and it can be installed from that website or by using the new
installation script:
┌────
│ $ curl https://dune.ci.dev/install | bash
└────
In a few seconds you should be ready to OCaml by calling `dune' – you
can watch a demo of this here: [X], [Mastodon].
Please try it out and let us know what you think :pray:
:calendar: You can book a feedback call with us [here]
:memo: You can submit feedback using [this form]
:bug: You can submit issues to Github on [ocaml/dune]
[Dune Developer Preview] <https://dune.ci.dev>
[X] <https://x.com/leostera/status/1838969568795979922>
[Mastodon] <https://mas.to/deck/@leostera/113198996085937679>
[here]
<https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ3HaJbskiCLHqLS6Oi1S3-rWYwv0hb_Iz8O9VlspuDdK5qbXYUZDpRRlWfEY1GP8KFy6XY8MFb9>
[this form]
<https://docs.google.com/forms/u/2/d/e/1FAIpQLSda-mOTHIdATTt_e9dFmNgUCy-fD55Qzr3bGGsxpfY_Ecfyxw/viewform?usp=send_form>
[ocaml/dune] <https://github.com/ocaml/dune/issues/new/choose>
Changes since last update
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The Dune shared cache has been enabled by default. We're starting off
by caching all downloads and dependencies.
We have improved support for dev tools. We're working to streamline
this but in the latest binary you can:
• Configure your LSP (in Neovim, Vim, Emacs, etc) to call `dune tools
exec ocamllsp' to get LSP support for your projects out of the box –
this may take a little bit the first time it builds the LSP for a
compiler version, but its pretty much instant afterwards.
• Call `dune fmt' to get your project formatted – remember to add an
`.ocamlformat' file if you don't have one yet. An empty one is
enough.
• Call `dune ocaml doc' to get documentation built
What's next?
╌╌╌╌╌╌╌╌╌╌╌╌
We're looking forward to streamlining the DX, working on better
dependency locks, and looking into supporting Windows.
In particular, we're considering work on a few things:
• `dune create <repo>' – to let the community create templates that
can be easily used from within dune
• `dune pkg fetch' – to prefetch packages and prepare a repository for
working in offline mode
• `dune build @deps' - to build all dependencies, useful for staged
builds in Dockerfiles
• `dune pkg add <name>' - to make adding packages straightforward
• a short-hand syntax for pins on github
• and more!
If you've got any ideas, we'd love to hear them, so please open a
feature request on Github :pray:
Other updates
╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ FunOCaml Presentation
At *FunOCaml* we had a last-minute opportunity to present the work
being done on Dune and we used it to introduce the Developer Preview
to the community, and even tested Package Management live with
suggestions from the audience (thanks @anmonteiro and Paul-Elliot for
participating!) – you can [watch it on Twitch].
[watch it on Twitch]
<https://www.twitch.tv/videos/2252408016?t=08h12m00s>
◊ New design
We're working with @Claire_Vandenberghe on redesigning the Developer
Preview website so that it'd feel like a seamless extension of
OCaml.org – in this current iteration we've made it easier to get
started and we're putting the FAQ front and center.
We'll be iterating on this design in the coming weeks until it fits
perfectly within the OCaml.org design system :art:
You can check the new website here: <https://dune.ci.dev>
◊ Upcoming Blog posts
In the near future we'll be publishing blog posts about the Developer
Preview and Package Management, which we're working on with
@professor.rose :clap:
Uuidm 0.9.9
═══════════
Archive: <https://discuss.ocaml.org/t/ann-uuidm-0-9-9/15336/1>
Daniel Bünzli announced
───────────────────────
There's a new release of [Uuidm], a library to handle universally
unique identifiers (UUIDs).
This very old module has been slightly renovated implying a few
deprecations, a [quick start] has been added to the docs and foremost
new constructors and generators were added to support the latest [RFC
9562] V7 time and random based UUID definitions; thanks to `xen-api'
folks for getting the ball rolling on this. See the [release notes]
for the details.
• Docs: [online] or `odig doc uuidm'
• Install: `opam install uuidm' ([PR])
A big thanks to my [donors].
[Uuidm] <https://erratique.ch/software/uuidm>
[quick start] <https://erratique.ch/software/uuidm/doc/#quick>
[RFC 9562] <https://www.rfc-editor.org/rfc/rfc9562>
[release notes]
<https://github.com/dbuenzli/uuidm/blob/master/CHANGES.md#v099-2024-09-26-zagreb>
[online] <https://erratique.ch/software/uuidm/doc/>
[PR] <https://github.com/ocaml/opam-repository/pull/26621>
[donors] <https://github.com/sponsors/dbuenzli>
first release of ppx_deriving_jsonschema
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-ppx-deriving-jsonschema/15320/2>
Louis Roché announced
─────────────────────
Released 0.0.2 on opam. It feels like the project is in a good shape
now.
Changes:
• support for nativeint, bytes, ref, unit
• add ~variant_as_array for compatibility with ppx_deriving_yojson
• support variant payloads
• support polymorphic variants inheritance
• fix encoding of tuples
• change encoding of variants from enum to anyOf
I'm considering making `variant_as_array' the default in 0.0.3 as it
would be more consistent with the ocaml ecosystem.
Bogue, the OCaml GUI
════════════════════
Archive: <https://discuss.ocaml.org/t/ann-bogue-the-ocaml-gui/9099/62>
sanette announced
─────────────────
I'm happy to announce a brand new version of [Bogue], version
20240928, now availble on `opam'.
Changes are mostly under the hood. We have nice improvements by @edwin
: automatic monitor vsync is now enabled by default, for smoother
animations, and most importantly *we finally align with the latest
version of `tsdl'*. It will simplify maintenance, but it also implies
that *too old versions of SDL will not work anymore*. On the other
hand we were kind of obliged to move forward, because `tsdl.0.9.8'
won't install on `ocaml 5.2'.
• if you're on Ubuntu 20.04, installing Bogue with `opam install
bogue' will by default pull `tsdl.1.1.0' in, which requires SDL >=
2.0.18, not shipped by the OS. A workaround is to explicitly require
`opam install tsdl.1.0.0' (or manually installing a newer SDL)
• if your OS ships SDL < 2.0.10 you have no other choice than manually
installing a newer [SDL] (which is not that complicated)
Happy bogue-ing!
[Bogue] <https://github.com/sanette/bogue>
[SDL] <https://github.com/libsdl-org/SDL/releases/tag/release-2.30.7>
New release of Merlin
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-merlin/15358/1>
vds announced
─────────────
I am very pleased to announce a new release of Merlin for OCaml 5.2,
5.1 and 4.14. This release brings a handful of fixes but also a
handful of of new commands:
• `signature_help' and `inlay_hint' have been upstreamed from
`ocaml-lsp-server'
• `expand_node' a command to get the ppxed-source when called on
relevant annotations
• 🕵️♀️ `search-by-type' a [sherlodoc]-inspired syntax to search for
values in the environment, that superseeds `polarity-search'.
Only `search-by-type' has an Emacs binding right now (and one for vim
on is [in the works]), we hope to have some time to work on more
client implementations in the near future.
[demo1]
[demo2]
[sherlodoc] <https://doc.sherlocode.com/>
[in the works] <https://github.com/ocaml/merlin/pull/1846>
[demo1]
<https://private-user-images.githubusercontent.com/5732466/368645764-3af5227a-c174-41ad-b493-cb4869e31db8.gif?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mjc2ODUzNzksIm5iZiI6MTcyNzY4NTA3OSwicGF0aCI6Ii81NzMyNDY2LzM2ODY0NTc2NC0zYWY1MjI3YS1jMTc0LTQxYWQtYjQ5My1jYjQ4NjllMzFkYjguZ2lmP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkzMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MzBUMDgzMTE5WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YjBhYmI0NzhjYjEwOTdkMmMwODYxY2JiNjJjZjAzNmFmMWNkN2Q5YzQ3NzIxMjI3MmMwYTFjM2ZmOGI0ZGUzMiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.xPSJX60YU1Br9zti85R5cU2N7GPglL2NNFo9Jge8tBY>
[demo2]
<https://private-user-images.githubusercontent.com/5732466/368645869-4917c6aa-d67c-4dff-a326-c33e5a8615cf.gif?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mjc2ODUzNzksIm5iZiI6MTcyNzY4NTA3OSwicGF0aCI6Ii81NzMyNDY2LzM2ODY0NTg2OS00OTE3YzZhYS1kNjdjLTRkZmYtYTMyNi1jMzNlNWE4NjE1Y2YuZ2lmP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkzMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MzBUMDgzMTE5WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MzM5NzdhNmU3M2U2MGJhMGI4OTg1MDZkYThjOGYyMTM1N2Q4NTJhMzM2NGRiMWE4MzdmZDQxOTZjNGFiNWFhYyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.028jtKfrrYwSqsJwmZn1rn2314IrijpGwPIqPOqffdc>
Complete changelog:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Fri Sep 27 12:02:42 CEST 2024
⁃ merlin binary
• A new `WRAPPING_PREFIX' configuration directive that can be used
to tell Merlin what to append to the current unit name in the
presence of wrapping (ocaml/merlin#1788)
• Add `-unboxed-types' and `-no-unboxed-types' as ocaml ignored
flags (ocaml/merlin#1795, fixes ocaml/merlin#1794)
• destruct: Refinement in the presence of optional arguments
(ocaml/merlin#1800 ocaml/merlin#1807, fixes ocaml/merlin#1770)
• Implement new expand-node command for expanding PPX annotations
(ocaml/merlin#1745)
• Implement new inlay-hints command for adding hints on a sourcetree
(ocaml/merlin#1812)
• Implement new search-by-type command for searching values by types
(ocaml/merlin#1828)
• Canonicalize paths in occurrences. This helps deduplicate the
results and show more user-friendly paths. (ocaml/merlin#1840)
• Fix dot-merlin-reader ignoring `SOURCE_ROOT' and `STDLIB'
directives (ocaml/merlin#1839, ocaml/merlin#1803)
⁃ editor modes
• vim: fix python-3.12 syntax warnings in merlin.py
(ocaml/merlin#1798)
• vim: Dead code / doc removal for previously deleted MerlinPhrase
command (ocaml/merlin#1804)
• emacs: Improve the way that result of polarity search is displayed
(ocaml/merlin#1814)
• emacs: Add `merlin-search-by-type', `merlin-search-by-polarity'
and change the behaviour of `merlin-search' to switch between
`by-type' or `by-polarity' depending on the query
(ocaml/merlin#1828)
cc @xvw @PizieDust
Releases of mirage-crypto 1.0.0, tls 1.0.0, x509 1.0.0, asn1-combinators 0.3.0, let's encrypt 1.0.0, awa 0.4.0, kdf 1.0.0, paf 0.7.0, git 3.17.0
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/releases-of-mirage-crypto-1-0-0-tls-1-0-0-x509-1-0-0-asn1-combinators-0-3-0-lets-encrypt-1-0-0-awa-0-4-0-kdf-1-0-0-paf-0-7-0-git-3-17-0/15359/1>
Hannes Mehnert announced
────────────────────────
Dear OCaml developers,
we're pleased to finally release a full stack of packages that do not
rely on Cstruct.t/Bigarray, but use string / bytes instead. This
brings us a massive performance boost (e.g. a factor of 3 in tls), and
brings a easier to comprehend API. It also makes performance tooling
work much more smoothly with our released packages. We announced this
upcoming change earlier this year
<https://discuss.ocaml.org/t/ann-mirage-crypto-0-11-3-with-more-speed-for-elliptic-curves-and-the-future-roadmap-of-mirage-crypto>
For further details, please see the specific release pages:
• [mirage-crypto 1.0.0] (also [1.0.1], and [1.1.0]) - cryptographic
operations in OCaml (symmetric ciphers, asymmetric ciphers (RSA,
DSA, DH), fortuna (a cryptographic secure pseudo random number
generator), elliptic curves (from [fiat-crypto]) – the hash
algorithms have been removed - use [digestif] instead
• [tls 1.0.0] (also [1.0.1], [1.0.2], and [1.0.3]) - a Transport layer
security implementation (HTTPS) in OCaml, supporting TLS 1.0, 1.1,
1.2, and 1.3
• [x509 1.0.0] (also [1.0.1], [1.0.2], [1.0.3], and [1.0.4]) - X509
certificates (signing requests, certificate revocation lists,
PKCS12)
• [asn1-combinators 0.3.0] (also [0.3.1] and [0.3.2]) - ASN.1 parser
combinators
• [let's encrypt 1.0.0] - a client for <https://letsencrypt.org> -
automated TLS certificate issuance
• [awa 0.4.0] - a SSH client and server implementation
• [kdf 1.0.0] - supporting different key derivation functions: hkdf
(used in TLS), PBKDF2, SCRYPT
• [paf 0.7.0] - protocol-agnostic client (http / http2)
• [git 3.17.0] - an implementation of the version control system git
<https://git-scm.com>
• [dns 9.0.0] (also [9.0.1]) - an implementation of the domain name
system
As you can envision, there was a lot of coordination and releasing
involved in preparing these API-breaking changes. The list above
likely misses various packages that have been released to support the
new mirage-crypto and tls API.
There have already been various issues reported and fixed in the
subsequent minor releases. We encourage you to upgrade your software
stack to the new release series, and report issues while you encounter
them (being it API questions, or correctness issues). Earlier releases
are not maintained anymore (due to lack of interest and lack of time),
thus if you encounter issues in earlier releases, please first update
to the most recent releases (although this may need some effort – a PR
that uses the packages heavily is
<https://github.com/robur-coop/miragevpn/pull/279>). If you're stuck
or lack time to port your code to the new API, we at robur offer
commercial support in upgrading your codebase. Reach out to us via
email: team@robur.coop.
This work has been conducted by the [robur collective]. Parts of this
work was sponsored by Tarides.
[mirage-crypto 1.0.0]
<https://github.com/mirage/mirage-crypto/releases/tag/v1.0.0>
[1.0.1] <https://github.com/mirage/mirage-crypto/releases/tag/v1.0.1>
[1.1.0] <https://github.com/mirage/mirage-crypto/releases/tag/v1.1.0>
[fiat-crypto] <https://github.com/mit-plv/fiat-crypto/>
[digestif] <https://github.com/mirage/digestif>
[tls 1.0.0] <https://github.com/mirleft/ocaml-tls/releases/tag/v1.0.0>
[1.0.1] <https://github.com/mirleft/ocaml-tls/releases/tag/v1.0.1>
[1.0.2] <https://github.com/mirleft/ocaml-tls/releases/tag/v1.0.2>
[1.0.3] <https://github.com/mirleft/ocaml-tls/releases/tag/v1.0.0>
[x509 1.0.0] <https://github.com/mirleft/ocaml-x509/releases/tag/v1.0.0>
[1.0.1] <https://github.com/mirleft/ocaml-x509/releases/tag/v1.0.1>
[1.0.2] <https://github.com/mirleft/ocaml-x509/releases/tag/v1.0.2>
[1.0.3] <https://github.com/mirleft/ocaml-x509/releases/tag/v1.0.3>
[1.0.4] <https://github.com/mirleft/ocaml-x509/releases/tag/v1.0.4>
[asn1-combinators 0.3.0]
<https://github.com/mirleft/ocaml-asn1-combinators/releases/tag/v0.3.0>
[0.3.1]
<https://github.com/mirleft/ocaml-asn1-combinators/releases/tag/v0.3.1>
[0.3.2]
<https://github.com/mirleft/ocaml-asn1-combinators/releases/tag/v0.3.2>
[let's encrypt 1.0.0]
<https://github.com/robur-coop/ocaml-letsencrypt/releases/tag/v1.0.0>
[awa 0.4.0] <https://github.com/mirage/awa-ssh/releases/tag/v0.4.0>
[kdf 1.0.0] <https://github.com/robur-coop/kdf/releases/tag/v1.0.0>
[paf 0.7.0]
<https://github.com/dinosaure/paf-le-chien/releases/tag/0.7.0>
[git 3.17.0] <https://github.com/mirage/ocaml-git/releases/tag/3.17.0>
[dns 9.0.0] <https://github.com/mirage/ocaml-dns/releases/tag/v9.0.0>
[9.0.1] <https://github.com/mirage/ocaml-dns/releases/tag/v9.0.1>
[robur collective] <https://robur.coop>
ICFP 2023 OCaml Presentations on YouTube
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-icfp-2023-ocaml-presentations-on-youtube/13554/2>
Anil Madhavapeddy announced
───────────────────────────
After a respectable pause, I've now imported these videos into the
Watch.OCaml.org instance so we have a non-YouTube mirror. They're up
on the [OCaml Workshop 2023 channel] now. Enjoy your ad-free viewing!
:slight_smile:
[OCaml Workshop 2023 channel]
<https://watch.ocaml.org/c/ocaml2023/videos?s=1>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/12>
Etienne Marais announced
────────────────────────
Hi Dune enthusiasts! :camel:
We will hold our regular Dune dev meeting tomorrow, on *Wednesday,
October, 2nd at 16:00 CET*. As usual, the session will be one hour
long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronise between the Dune developers
:smile:
:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The agenda is available on the [meeting dedicated page ]. Feel free to
ask if you want to add more items in it.
[meeting dedicated page ]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-10-02>
:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link: [zoom ]
• Calendar event: [google calendar ]
• Wiki with information and previous notes: [GitHub Wiki ]
[zoom ]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar ]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[GitHub Wiki ] <https://github.com/ocaml/dune/wiki#dev-meetings>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [[OCaML'23] Modern DSL compiler architecture in OCaml our experience
with Catala]
• [[OCaML'23] Eio 1.0 – Effects-based IO for OCaml 5]
• [[OCaML'23] Less Power for More Learning: Restricting OCaml Features
for Effective Teaching]
• [[OCaML'23] Efficient OCaml compilation with Flambda 2]
• [[OCaML'23] Buck2 for OCaml Users & Developers]
• [[OCaML'23] Parallel Sequences in Multicore OCaml]
• [[OCaML'23] Building a lock-free STM for OCaml]
• [[OCaML'23] MetaOCaml Theory and Implementation]
• [[OCaML'23] Osiris: an Iris-based program logic for OCaml]
• [[OCaML'23] State of the OCaml Platform 2023]
• [[OCaML'23] Owi: an interpreter and a toolkit for WebAssembly
written in OCaml]
• [[OCaML'23] Targeted Static Analysis for OCaml C Stubs: Eliminating
gremlins from the code]
• [Introducing Dune: The Essential Build System for OCaml Developers]
• [Summer of Internships: Projects From the OCaml Compiler Team]
[the ocaml.org blog] <https://ocaml.org/blog/>
[[OCaML'23] Modern DSL compiler architecture in OCaml our experience
with Catala] <https://watch.ocaml.org/w/7ZxKnBY2w3XCztpzbKm8YG>
[[OCaML'23] Eio 1.0 – Effects-based IO for OCaml 5]
<https://watch.ocaml.org/w/9Hxc81ac3k6GQF1fdZLx7d>
[[OCaML'23] Less Power for More Learning: Restricting OCaml Features for
Effective Teaching] <https://watch.ocaml.org/w/uABzLbyAasoKbjyRwganh4>
[[OCaML'23] Efficient OCaml compilation with Flambda 2]
<https://watch.ocaml.org/w/qGN45zFDCVGxiKRz9mKkVp>
[[OCaML'23] Buck2 for OCaml Users & Developers]
<https://watch.ocaml.org/w/cYiKFa5EbS3AqVgYzMHP5V>
[[OCaML'23] Parallel Sequences in Multicore OCaml]
<https://watch.ocaml.org/w/6K7mqY88PyDZFC2bJvs2Xe>
[[OCaML'23] Building a lock-free STM for OCaml]
<https://watch.ocaml.org/w/v3LtkXGeW5KXjziPQdzRJZ>
[[OCaML'23] MetaOCaml Theory and Implementation]
<https://watch.ocaml.org/w/rnQXcND8aaY9qUtikB9tSc>
[[OCaML'23] Osiris: an Iris-based program logic for OCaml]
<https://watch.ocaml.org/w/1Hfi9pjTo1hz1ej2WtVGCR>
[[OCaML'23] State of the OCaml Platform 2023]
<https://watch.ocaml.org/w/9GtFUSDDpmU8ZDD54A7V7e>
[[OCaML'23] Owi: an interpreter and a toolkit for WebAssembly written in
OCaml] <https://watch.ocaml.org/w/3pYGmveWpNNLH4B6TUv5ww>
[[OCaML'23] Targeted Static Analysis for OCaml C Stubs: Eliminating
gremlins from the code]
<https://watch.ocaml.org/w/sj5jf9iieZA7E1cbDbnv2j>
[Introducing Dune: The Essential Build System for OCaml Developers]
<https://tarides.com/blog/2024-09-26-introducing-dune-the-essential-build-system-for-ocaml-developers>
[Summer of Internships: Projects From the OCaml Compiler Team]
<https://tarides.com/blog/2024-09-24-summer-of-internships-projects-from-the-ocaml-compiler-team>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 36300 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-09-24 13:18 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-09-24 13:18 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 43716 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 17 to
24, 2024.
Table of Contents
─────────────────
ocaml-trace 0.8
qcheck-lin and qcheck-stm 0.2
3rd editor tooling dev-meeting: 26th of September 🧙
First release of hachis
OCaml Platform Newsletter: June-August 2024
First alpha release of OCaml 5.3.0
Ascend - Dungeon RPG for your terminal
first release of ppx_deriving_jsonschema
opam 2.3.0~alpha1
Other OCaml News
Old CWN
ocaml-trace 0.8
═══════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-trace-0-8/15298/1>
Simon Cruanes announced
───────────────────────
[ocaml-trace 0.8] was just released. It features a new trace collector
for multiprocess programs, and a new library, `trace.subscriber', for
handling events in a more modular, compositional way.
For background, `trace' is a lightweight library that can be used to
instrument your code (libraries or executable), either by hand or
using `ppx_trace', and offers a `collector' abstraction to actually
collect/handle/store/write the trace events somewhere. The overhead
when no collector is installed is low. There are also several
collectors in `trace-tef', `trace-fuchsia', and (in a separate repo)
`tracy-client'. See the [github repo] for more details.
[ocaml-trace 0.8]
<https://github.com/c-cube/ocaml-trace/releases/tag/v0.8>
[github repo] <https://github.com/c-cube/ocaml-trace/>
qcheck-lin and qcheck-stm 0.2
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm-0-2/12301/3>
Jan Midtgaard announced
───────────────────────
I'm happy to share the 0.4 release of `qcheck-lin', `qcheck-stm', and
`qcheck-multicoretests-util':
<https://github.com/ocaml-multicore/multicoretests/releases/tag/0.4>
The testing libraries are useful for testing your OCaml code for
parallelism safety:
• `qcheck-lin' offer a low effort approach, requiring little more than
type signatures of the target interface (example above)
• `qcheck-stm' offers stronger correctness guarantees by comparing the
observed behaviour to a functional model description - under both
sequential and parallel usage.
The 0.4 release brings two new "stress test" functions and also
adjusts the cmd list distribution of `STM_sequential':
• #415: Remove `--verbose' in internal `mutable_set_v5' expect test to
avoid a test failure on a slow machine
• #443: Add `Lin_domain.stress_test' as a lighter stress test, not
requiring an interleaving search.
• #462: Add `STM_domain.stress_test_par', similar to
`Lin_domain.stress_test' for STM models.
• #472: Switch `arb_cmds' to use an exponential distribution with a
mean of 10, avoiding lists of up to 10000 cmds in `STM_sequential'
(reported by @nikolaushuber).
Happy testing! :smiley:
3rd editor tooling dev-meeting: 26th of September 🧙
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-3rd-editor-tooling-dev-meeting-26th-of-september/15308/1>
vds announced
─────────────
The meeting is back! We are organizing the next one on next Thursday,
the 26th of September at 5pm CEST (sorry, still no timezone rotation,
but we probably will for the next one). Whether you are a long time
maintainer, an occasional contributor, a new comer, or simply a
curious passer-by, please feel free to attend!
:sparkles: For this session, @jchavarri is going to present [Melange],
a toolchain that compiles ocaml/reason to javascript, and its
integration in the tooling ecosystem.
:clipboard: Meeting agenda:
• A tour-de-table to allow the participants that wish to do so to
present themselves and mention issues / prs they are interested in.
• Talk and Q&A
• Discuss issues and pull requests that were tagged in advance or
mentioned during the tour-de-table.
We’re looking forward to meeting you!
Meeting link: [https://meet.google.com/nzt-owbh-yoo ]
Previous meeting notes are available in [Merlin’s repository wiki].
[Melange] <https://github.com/melange-re/melange>
[https://meet.google.com/nzt-owbh-yoo ]
<https://meet.google.com/nzt-owbh-yoo>
[Merlin’s repository wiki]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
First release of hachis
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-hachis/15309/1>
François Pottier announced
──────────────────────────
It is my pleasure to announce the first release of `hachis', a library
that offers hash sets and hash maps.
These data structures handle collisions via linear probing, a
technique that relies on linear searches within an array. All of the
data is stored within one large array (for hash sets) or two large
arrays (for hash maps). As a result, these data structures offer good
locality.
Some benchmarks suggest that `hachis' can consistently outperform the
standard library's hash maps (`Hashtbl').
To install the library, type `opam update && opam install hachis'.
For more details, see the [documentation].
[documentation] <https://cambium.inria.fr/~fpottier/hachis/doc/hachis/>
Simon Cruanes then added
────────────────────────
The code is [here] for those who are curious to see how the sausage is
done :-)
[here] <https://github.com/fpottier/hachis>
OCaml Platform Newsletter: June-August 2024
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-platform-newsletter-june-august-2024/15312/1>
Thibaut Mattio announced
────────────────────────
Welcome to the twelfth edition of the OCaml Platform newsletter!
In this June-August 2024 edition, we are excited to bring you the
latest on the OCaml Platform, continuing our tradition of highlighting
recent developments as seen in [previous editions]. To understand the
direction we're headed, especially regarding development workflows and
user experience improvements, check out our [roadmap].
*Highlights:*
• *Dune package management soon in public beta:* [Developer Preview
Program] expands with 60+ interviews, NPS soaring from +9 to +28!
Public beta coming soon with exciting features like automatic
dependency locking and dev tool management. [See it in action]!
• *Opam 2.2 is out:* [Native Windows support is here]! Seamless setup
with `opam init', `opam-repository' compatible with Windows. OCaml
on Windows is now a reality.
• *Odoc 3.0 gets close to a release:* New features like global
sidebars and media support are ready in odoc. Integration with Dune
and OCaml.org pipeline in progress - get ready to test the new
documentation experience soon! [Check out the RFCs].
• *Project-wide references is live:* Merlin 5.1 and OCaml LSP 1.18.0
bring powerful code navigation to your editor. Built on years of
compiler work, it's a game-changer for large codebases.
• *Starting to bridge the gap between Merlin and OCaml LSP:* New LSP
queries for type enclosing, documentation, and more. We’re working
towards consistent, feature-rich experience across all editors
powered by OCaml LSP.
*Releases:*
• [opam 2.2.0~beta3]
• [opam 2.2.0~rc1]
• [opam 2.2.0]
• [opam 2.2.1]
• [Dune 3.16.0]
• opam-publish 2.3.1
• [Merlin 5.1]
• [Merlin 4.16]
• [Merlin 4.15]
• [OCaml LSP 1.19.0]
• [OCaml LSP 1.18.0]
• [Ppxlib 0.33.0]
[previous editions] <https://discuss.ocaml.org/tag/platform-newsletter>
[roadmap] <https://ocaml.org/docs/platform-roadmap>
[Developer Preview Program]
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160>
[See it in action] <https://mas.to/deck/@leostera/112988841207690720>
[Native Windows support is here]
<https://discuss.ocaml.org/t/ann-opam-2-2-0-is-out/14893>
[Check out the RFCs] <https://github.com/ocaml/odoc/discussions/1097>
[opam 2.2.0~beta3]
<https://ocaml.org/changelog/2024-06-10-opam-2-2-0-beta3>
[opam 2.2.0~rc1] <https://ocaml.org/changelog/2024-06-21-opam-2-2-0-rc1>
[opam 2.2.0] <https://ocaml.org/changelog/2024-07-01-opam-2-2-0>
[opam 2.2.1] <https://ocaml.org/changelog/2024-08-22-opam-2-2-1>
[Dune 3.16.0] <https://ocaml.org/changelog/2024-06-17-dune.3.16.0>
[Merlin 5.1] <https://ocaml.org/changelog/2024-06-24-merlin-5.1>
[Merlin 4.16] <https://ocaml.org/changelog/2024-06-12-merlin-4.16>
[Merlin 4.15] <https://ocaml.org/changelog/2024-06-03-merlin-54.15>
[OCaml LSP 1.19.0]
<https://ocaml.org/changelog/2024-07-31-ocaml-lsp-1.19.0>
[OCaml LSP 1.18.0]
<https://ocaml.org/changelog/2024-07-11-ocaml-lsp-1.18.0>
[Ppxlib 0.33.0] <https://ocaml.org/changelog/2024-07-25-ppxlib-0.33.0>
*Dune Package Management ([W4])*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rgrinberg (Tarides), @Leonidas-from-XIV (Tarides),
@gridbugs (Tarides), @Alizter
*Synopsis:* Integrating package management into Dune, making it the
sole tool needed for OCaml development. This unification eliminates
installation time (just download Dune's pre-built binary), automates
external tool management (e.g., for `dune fmt' or `dune ocamllsp'),
and significantly reduces build times through caching (packages and
compiler are built only once across projects).
*Summary:*
Following our announcement of reaching the Minimal Viable Product
(MVP) stage for Dune's package management in the [last newsletter],
we've made substantial progress on our stated goals. As promised,
we've shifted our focus from prototyping to user testing and refining
the developer experience (DX).
The Developer Preview Program (see [latest update]) has expanded
significantly from its early stages. We've conducted approximately 60
developer interviews, representing a diverse cross-section of the
OCaml community. The interviewees include both newcomers and
experienced OCaml users. Notably, about 40% of participants have over
3 years of OCaml experience, while 35% are relative newcomers with
less than a year of experience. The majority come from Linux and macOS
environments, with participants representing various sectors including
tech companies, research institutions, and independent developers.
These sessions have provided crucial feedback and driven
improvements. This extensive user testing has paid off, with the Net
Promoter Score jumping from +9 to an estimated +28 - a clear sign that
the community is excited about the improvements we've made.
Key developments since the last update include:
• A nightly binary distribution of Dune with package management
enabled, which will be made available publicly in the coming weeks.
• We started work on automated handling of developer tools
(ocamlformat, ocamllsp, odoc) – users will be able run `dune fmt',
or `dune ocamllsp', and Dune will take care of installing
OCamlFormat and OCaml LSP automatically if they are not available.
• Implementation of automatic dependency locking when project’s
dependency changes – you can now run Dune in watch mode and let it
install your dependencies without any intervention after updating
your dune-project
• We’ve enabled Dune cache by default, which works with your package
dependencies. With this change, Dune will not recompile dependencies
more than once when building new projects, including the compiler!
The team has moved beyond just testing with OCaml.org and Bonsai, now
conducting broader compatibility tests across the opam
repository. Initial results show about 50% of packages can be authored
using Dune with package management, with ongoing efforts to increase
the coverage (we expect resolution of a few issues on a select few
foundational packages to significantly increase that percentage).
In line with the commitment to prepare for a first release, the team
plans to launch a public beta in the coming weeks. This marks a
significant step from our current private Developer Preview testing
with selected beta testers, to a broader community release.
Stay tuned for the upcoming announcement, and in the meantime, have a
look a the demos and some enthusiastic messages from beta testers:
• Demo on [Mastodon] or [X]
• “Just did the dune package management preview, it’s looking very
sharp” – [https://x.com/ckarmstrong/status/1830937156434747566]
• “Really looking forward to this! No more switches, no more opam,
just dune behaving like a modern package manager. Having played
around with it, it's just so so nice. The focus on DX really makes
me hopeful about OCaml's future.” –
[https://x.com/synecdokey/status/1825533523283079474]
*Activities:*
• Implemented workaround to avoid unstable compilers –
[ocaml/dune#10668]
• Added support for multiple checksums ([ocaml/dune#10624],
[ocaml/dune#10791])
• Began upstreaming the Dune toolchain feature ([ocaml/dune#10639],
[ocaml/dune#10719])
• Added implicit relock when dependencies change – [ocaml/dune#10641]
• Improved dependency solving and constraint handling
([ocaml/dune#10726])
• Added developer preview features and configuration options
([ocaml/dune#10627])
• Implemented progress indicators for package builds and lockfile
generation ([ocaml/dune#10802], [ocaml/dune#10803])
• Improved error messages and logging ([ocaml/dune#10662])
• Created extensive test suite for new package management features
([ocaml/dune#10798])
• Resolved issues with building specific packages (e.g., seq, lwt)
([ocaml/dune#10788], [ocaml/dune#10839])
• Enable cache on fetch actions for faster builds ([ocaml/dune#10850])
• Improved handling of dev tools like ocamlformat ([ocaml/dune#10647])
• Developed tools for testing package compatibility coverage on
opam-repository
[W4] <https://ocaml.org/docs/platform-roadmap#w4-build-a-project>
[last newsletter]
<https://discuss.ocaml.org/t/ocaml-platform-newsletter-march-may-2024/14765>
[latest update]
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160>
[Mastodon] <https://mas.to/deck/@leostera/112988841207690720>
[X] <https://x.com/leostera/status/1825519465527673238>
[https://x.com/ckarmstrong/status/1830937156434747566]
<https://x.com/ckarmstrong/status/1830937156434747566>
[https://x.com/synecdokey/status/1825533523283079474]
<https://x.com/synecdokey/status/1825533523283079474>
[ocaml/dune#10668] <https://github.com/ocaml/dune/pull/10668>
[ocaml/dune#10624] <https://github.com/ocaml/dune/pull/10624>
[ocaml/dune#10791] <https://github.com/ocaml/dune/pull/10791>
[ocaml/dune#10639] <https://github.com/ocaml/dune/pull/10639>
[ocaml/dune#10719] <https://github.com/ocaml/dune/pull/10719>
[ocaml/dune#10641] <https://github.com/ocaml/dune/pull/10641>
[ocaml/dune#10726] <https://github.com/ocaml/dune/pull/10726>
[ocaml/dune#10627] <https://github.com/ocaml/dune/pull/10627>
[ocaml/dune#10802] <https://github.com/ocaml/dune/pull/10802>
[ocaml/dune#10803] <https://github.com/ocaml/dune/pull/10803>
[ocaml/dune#10662] <https://github.com/ocaml/dune/pull/10662>
[ocaml/dune#10798] <https://github.com/ocaml/dune/pull/10798>
[ocaml/dune#10788] <https://github.com/ocaml/dune/issues/10788>
[ocaml/dune#10839] <https://github.com/ocaml/dune/issues/10839>
[ocaml/dune#10850] <https://github.com/ocaml/dune/pull/10850>
[ocaml/dune#10647] <https://github.com/ocaml/dune/pull/10647>
*Native Support for Windows in opam 2.2 ([W5])*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rjbou (OCamlPro), @kit-ty-kate (Ahrefs), @dra27
(Tarides), @AltGr (OCamlPro)
*Synopsis:* Releasing opam 2.2 with native Windows support to enhance
OCaml's viability on Windows, making the official `opam-repository'
usable on Windows and encouraging more Windows-friendly packages.
*Summary:*
The release of opam 2.2.0, [announced on Discuss] early July, marks a
significant milestone for the OCaml ecosystem. This version brings
native support for both the opam client and compiler packages in
`opam-repository' on Windows, opening new possibilities for OCaml
development on this platform.
opam 2.2.0 officially supports Cygwin and is compatible with
MSYS2. Windows users can now run `opam init' in their preferred
console for a guided setup, resulting in a fully functional OCaml
environment. This release represents the culmination of a [multi-year
effort] involving extensive contributions from the community.
The OCaml ecosystem is already adapting to this new capability. A [CI
check for Windows compilation] has been added to opam-repository, and
the [GitHub Action ocaml/setup-ocaml] now uses opam 2.2.0,
facilitating OCaml development on Windows in GitHub projects.
Community members are actively working to improve Windows
compatibility across the ecosystem. Notable efforts include [Hugo
Heuzard's] work on [OCamlBuild] and several other [Windows-related
PRs].
We encourage package authors to set up Windows CI for their projects
and address Windows-related issues. This collective effort will be
crucial in expanding OCaml's reach and usability on the Windows
platform.
*Activities:*
• Opam binary:
‣ Fixed issues with `opam init' on Windows – [ocaml/opam#5991],
[ocaml/opam#5992], [ocaml/opam#5993], [ocaml/opam#5994],
[ocaml/opam#5995], [ocaml/opam#5996], [ocaml/opam#5997],
[ocaml/opam#5998], [ocaml/opam#6000]
‣ Improved status display during slow operations on Windows –
[ocaml/opam#5977]
‣ Enabled opam to work with Windows usernames containing spaces –
[ocaml/opam#5457]
‣ Fixed `opam init -yn' to handle menus in the release candidate –
[ocaml/opam#6033]
‣ Updated PowerShell script for installing opam from GitHub
releases: [ocaml/opam#5906]
‣ Fixed hang issue with `setup-ocaml' and depexts –
[ocaml/opam#6046]
• Update opam-repository to be compatible with Windows:
‣ Updated `opam-repository' Windows CI –
[ocaml/opam-repository#26081], [ocaml/opam-repository#26073],
[ocaml/opam-repository#26080]
‣ Added backport of MSVC in OCaml-variants.5.2.0+msvc –
[ocaml/opam-repository#26082]
‣ Updated native Cygwin depexts – [ocaml/opam-repository#26130]
‣ Updated opam-repository with Windows-specific package information:
‣ Added Windows compiler packages ([ocaml/opam-repository#25861])
‣ Fixed issues with OCaml variants on Windows
([ocaml/opam-repository#26033])
‣ Updated and released mingw-w64-shims.0.2.0 to fix setup-ocaml
issues ([ocaml/opam-repository#26123])
• Released stable version of opam 2.2.0 with full Windows support 🎉
([announcement])
[W5] <https://ocaml.org/docs/platform-roadmap#w5-manage-dependencies>
[announced on Discuss]
<https://discuss.ocaml.org/t/ann-opam-2-2-0-is-out/14893>
[multi-year effort]
<https://github.com/ocaml/opam/issues/246#issuecomment-2166133625>
[CI check for Windows compilation]
<https://github.com/ocaml/opam-repository/pull/26069>
[GitHub Action ocaml/setup-ocaml]
<https://github.com/ocaml/setup-ocaml/releases/tag/v3.0.0>
[Hugo Heuzard's] <https://github.com/hhugo>
[OCamlBuild] <https://github.com/ocaml/opam-repository/pull/26164>
[Windows-related PRs]
<https://github.com/ocaml/opam-repository/pulls?q=is%3Apr+windows+created%3A%3E2023-06-01>
[ocaml/opam#5991] <https://github.com/ocaml/opam/pull/5991>
[ocaml/opam#5992] <https://github.com/ocaml/opam/pull/5992>
[ocaml/opam#5993] <https://github.com/ocaml/opam/pull/5993>
[ocaml/opam#5994] <https://github.com/ocaml/opam/pull/5994>
[ocaml/opam#5995] <https://github.com/ocaml/opam/pull/5995>
[ocaml/opam#5996] <https://github.com/ocaml/opam/pull/5996>
[ocaml/opam#5997] <https://github.com/ocaml/opam/pull/5997>
[ocaml/opam#5998] <https://github.com/ocaml/opam/pull/5998>
[ocaml/opam#6000] <https://github.com/ocaml/opam/pull/6000>
[ocaml/opam#5977] <https://github.com/ocaml/opam/pull/5977>
[ocaml/opam#5457] <https://github.com/ocaml/opam/pull/5457>
[ocaml/opam#6033] <https://github.com/ocaml/opam/pull/6033>
[ocaml/opam#5906] <https://github.com/ocaml/opam/pull/5906>
[ocaml/opam#6046] <https://github.com/ocaml/opam/pull/6046>
[ocaml/opam-repository#26081]
<https://github.com/ocaml/opam-repository/pull/26081>
[ocaml/opam-repository#26073]
<https://github.com/ocaml/opam-repository/pull/26073>
[ocaml/opam-repository#26080]
<https://github.com/ocaml/opam-repository/pull/26080>
[ocaml/opam-repository#26082]
<https://github.com/ocaml/opam-repository/pull/26082>
[ocaml/opam-repository#26130]
<https://github.com/ocaml/opam-repository/pull/26130>
[ocaml/opam-repository#25861]
<https://github.com/ocaml/opam-repository/pull/25861>
[ocaml/opam-repository#26033]
<https://github.com/ocaml/opam-repository/pull/26033>
[ocaml/opam-repository#26123]
<https://github.com/ocaml/opam-repository/pull/26123>
[announcement] <https://ocaml.org/changelog/2024-01-18-opam-2-2-0-beta1>
*Upgrading OCaml Package Documentation with Odoc 3.0 ([W25])*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @jonludlam (Tarides), @julow (Tarides), @panglesd
(Tarides), @EmileTrotignon (Tarides), Luke Maurer (Jane Street)
*Synopsis:* Upgrading OCaml package documentation experience with odoc
3, featuring improved navigation, cross-package referencing, media
support, and more. This upgrade aims to improve the documentation
experience both locally and on OCaml.org, encouraging higher-quality
package documentation.
*Summary:*
Following the completion and community review of the RFCs for odoc
3.0, we've made significant strides in implementing the new design and
features. Our progress over the past few months has brought us close
to a complete implementation of the odoc 3.0 feature set. As we
finalize development and approach the first release, our focus is
shifting towards integration with the rest of the ecosystem.
Key Developments in the past months include:
• Adding new options to the `odoc' CLI to begin the implementation of
the `odoc' 3 CLI
• Implementing new syntax such as path-references
• Developing the global sidebar with a TOC featuring standalone pages
and package module hierarchy
As we near completion of the core odoc 3.0 feature set, our focus is
shifting towards finalizing integration with Dune and the OCaml.org
documentation pipeline. We're excited to get all of these improvements
in your hands and get your feedback on the new documentation
experience. Stay tuned for announcements regarding testing
opportunities and the upcoming release of odoc 3.0!
*Activities:*
• Added `path-references' lookup functionality – [ocaml/odoc#1150]
• Added the `--current-package' option – [ocaml/odoc#1151]
• Fixed hierarchical pages being given wrong parent ID –
[ocaml/odoc#1148]
• Parsing of `path-references' to pages and modules
([ocaml/odoc#1142])
• Support for assets and media in documentation ([ocaml/odoc#1184])
• Implemented "Global" sidebar feature ([ocaml/odoc#1145])
• Added support for external pages and non-package documentation
([ocaml/odoc#1183])
• Improved CSS for better visual presentation ([ocaml/odoc#1159])
• Add a marshalled output for index generation ([ocaml/odoc#1084])
• Implemented Voodoo/Dune driver for improved integration
([ocaml/odoc#1168])
• Added frontmatter support to mld pages ([ocaml/odoc#1187])
• Improved breadcrumbs to show packages and libraries
([ocaml/odoc#1190])
[W25]
<https://ocaml.org/docs/platform-roadmap#w25-generate-documentation>
[ocaml/odoc#1150] <https://github.com/ocaml/odoc/pull/1150>
[ocaml/odoc#1151] <https://github.com/ocaml/odoc/pull/1151>
[ocaml/odoc#1148] <https://github.com/ocaml/odoc/pull/1148>
[ocaml/odoc#1142] <https://github.com/ocaml/odoc/pull/1142>
[ocaml/odoc#1184] <https://github.com/ocaml/odoc/pull/1184>
[ocaml/odoc#1145] <https://github.com/ocaml/odoc/pull/1145>
[ocaml/odoc#1183] <https://github.com/ocaml/odoc/pull/1183>
[ocaml/odoc#1159] <https://github.com/ocaml/odoc/pull/1159>
[ocaml/odoc#1084] <https://github.com/ocaml/odoc/pull/1084>
[ocaml/odoc#1168] <https://github.com/ocaml/odoc/pull/1168>
[ocaml/odoc#1187] <https://github.com/ocaml/odoc/pull/1187>
[ocaml/odoc#1190] <https://github.com/ocaml/odoc/pull/1190>
*Project-Wide References in OCaml Editors ([W19])*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @vds (Tarides)
*Synopsis:* Introducing project-wide reference features in Merlin and
OCaml LSP to enhance code navigation and refactoring capabilities,
bringing OCaml's editor experience in line with other modern
programming languages.
*Summary:*
As [announced] in June, Merlin project-wide references is now
available in Merlin 5.1 and the preview of OCaml LSP 1.18.0. Users of
LSP-powered editors (like VSCode with the OCaml Platform extension)
and classic Emacs and Vim plugins can now query project-wide
references of OCaml terms. This requires building the index with the
new Dune alias `@ocaml-index'.
This release represents the culmination of a multiyear effort by the
Merlin team, including extensive work on the compiler to provide the
necessary information for implementing this feature in Merlin.
We're thrilled to share this feature with the community and look
forward to your feedback.
While the feature should work well in most cases, we're aware of some
limitations. Our next steps include adding support for interface files
and module paths. Stay tuned!
*Activities:*
• Completed work on incremental occurrences indexation and related
Dune rules – [ocaml/dune#10422]
• Fixed issues with querying from interface files –
[ocaml/merlin#1779], [ocaml/merlin#1781]
• Improved behavior when cursor is on label/constructor declarations –
[ocaml/merlin#1785]
• Released `Merlin.5.1-502', `ocaml-index.1.0', and a new preview of
`ocaml-lsp-server' with project-wide occurrences support –
[ocaml/opam-repository#26114]
• Announced the release on Discuss – [Project-wide occurrences in
Merlin and LSP]
• Wrote a [wiki page] for project-wide occurrences
• Updated [the Merlin website]
• Updated the [platform changelog]
• Improved handling of label and constructor declarations
([ocaml/merlin#1785])
• Contributed compiler improvements:
• Implemented distinct unique identifiers for implementations and
interfaces ([ocaml/ocaml#13286])
• Developed a system for linking unique identifiers of declarations
([ocaml/ocaml#13308])
• Contributed to improvements in longident locations
([ocaml/ocaml#13302])
[W19] <https://ocaml.org/docs/platform-roadmap#w19-navigate-code>
[announced]
<https://discuss.ocaml.org/t/ann-project-wide-occurrences-in-merlin-and-lsp/14847>
[ocaml/dune#10422] <https://github.com/ocaml/dune/pull/10422>
[ocaml/merlin#1779] <https://github.com/ocaml/merlin/pull/1779>
[ocaml/merlin#1781] <https://github.com/ocaml/merlin/pull/1781>
[ocaml/merlin#1785] <https://github.com/ocaml/merlin/pull/1785>
[ocaml/opam-repository#26114]
<https://github.com/ocaml/opam-repository/pull/26114>
[Project-wide occurrences in Merlin and LSP]
<https://discuss.ocaml.org/t/ann-project-wide-occurrences-in-merlin-and-lsp/14847>
[wiki page]
<https://github.com/ocaml/merlin/wiki/Get-project%E2%80%90wide-occurrences>
[the Merlin website]
<https://ocaml.github.io/merlin/editor/emacs/#search-for-an-identifiers-occurrences>
[platform changelog] <https://github.com/ocaml/ocaml.org/pull/2580>
[ocaml/ocaml#13286] <https://github.com/ocaml/ocaml/pull/13286>
[ocaml/ocaml#13308] <https://github.com/ocaml/ocaml/pull/13308>
[ocaml/ocaml#13302] <https://github.com/ocaml/ocaml/pull/13302>
*Bridging the Gap Between Merlin and OCaml LSP ([W19])*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @xvw (Tarides), @vds (Tarides)
*Synopsis:* Working towards feature parity between Merlin and OCaml
LSP to provide a consistent, feature-rich development experience
across all editors, making OCaml LSP the comprehensive backend for
OCaml editor support.
*Summary:*
In June, we started work on bridging the gap between OCaml LSP and
Merlin. We've started with exposing Merlin's type-enclosing request in
OCaml LSP. The feature is now available as `ocamllsp/typeEnclosing'
and we will work on editor integration next.
As a reminder, Merlin's `type-enclosing' feature allows users to get
the type of the identifier under the cursor. It highlights the
identifier and displays its type. Users can climb the typed-tree to
display the type of larger expressions surrounding the cursor.
Since June, we’ve worked on a number of new LSP queries and code
actions, including:
• A custom `ocamllsp/getDocumentation' query to request the `odoc'
documentation
• A custom `ocamllsp/construct' query to browse and fill typed holes
(`_')
• A code-action for syntactic and semantic movement shortcuts based on
Merlin's Jump command
*Activities*
• Added custom queries for type enclosing and documentation retrieval:
‣ Type enclosing query ([ocaml/ocaml-lsp#1304])
‣ Documentation query ([ocaml/ocaml-lsp#1336])
• Created a custom construct query ([ocaml/ocaml-lsp#1348])
• Implemented semantic and syntactic movement shortcuts
([ocaml/ocaml-lsp#1364])
• Backported and released Merlin 4.16 with necessary commands
([opam-repository PR])
• Refactored usage of `Typedtree' from `ocaml-lsp' to `merlin-lib'
([ocaml/merlin#1811], [ocaml/merlin#1812])
[W19] <https://ocaml.org/docs/platform-roadmap#w19-navigate-code>
[ocaml/ocaml-lsp#1304] <https://github.com/ocaml/ocaml-lsp/pull/1304>
[ocaml/ocaml-lsp#1336] <https://github.com/ocaml/ocaml-lsp/pull/1336>
[ocaml/ocaml-lsp#1348] <https://github.com/ocaml/ocaml-lsp/pull/1348>
[ocaml/ocaml-lsp#1364] <https://github.com/ocaml/ocaml-lsp/pull/1364>
[opam-repository PR]
<https://github.com/ocaml/opam-repository/pull/26052>
[ocaml/merlin#1811] <https://github.com/ocaml/merlin/pull/1811>
[ocaml/merlin#1812] <https://github.com/ocaml/merlin/pull/1812>
First alpha release of OCaml 5.3.0
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-3-0/15315/1>
octachron announced
───────────────────
Four months after the release of OCaml 5.2.0, the set of new features
for the future version 5.3.0 of OCaml has been frozen. We are thus
happy to announce the first alpha release for OCaml 5.3.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). More information about the whole release
process is now available in the [compiler repository].
The progresses on stabilizing the ecosystem are tracked on the [opam
readiness for 5.3.0 meta-issue].
The full release is expected around November, see the [new prospective
calendar] for more information.
If you find any bugs, please report them on [OCaml's issue tracker].
If you are interested in the ongoing list of new features and bug
fixes, the updated change log for OCaml 5.3.0 is available [on
GitHub].
[compiler repository]
<https://github.com/ocaml/ocaml/blob/trunk/release-info/introduction.md>
[opam readiness for 5.3.0 meta-issue]
<https://github.com/ocaml/opam-repository/issues/26596>
[new prospective calendar]
<https://github.com/ocaml/ocaml/blob/trunk/release-info/calendar.md>
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.3/Changes>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands on opam 2.1 and later:
┌────
│ opam update
│ opam switch create 5.3.0~alpha1
└────
The source code for the alpha is also available at these addresses:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.3.0-alpha1.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.3/ocaml-5.3.0~alpha1.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.3.0~alpha1+options <option_list>
└────
where `option_list' is a space separated list of `ocaml-option-*'
packages. For instance, for a flambda and no-flat-float-array switch:
┌────
│ opam switch create 5.3.0~alpha1+flambda+nffa ocaml-variants.5.3.0~alpha1+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Ascend - Dungeon RPG for your terminal
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ascend-dungeon-rpg-for-your-terminal/15319/1>
eir announced
─────────────
Announcing the first release of *[ascend]*!
Venture into the depths to retrieve the stolen artifact, and hopefully
escape with your life… NetHack lite.
*Get it via:*
┌────
│ opam install ascend
│ ascend
└────
Rievax the Revelator is recruiting you for some "manual testing".
[ascend] <https://github.com/m-laniakea/ascend>
first release of ppx_deriving_jsonschema
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-ppx-deriving-jsonschema/15320/1>
Louis Roché announced
─────────────────────
It is my pleasure to announce the first release of
[ppx_deriving_jsonschema]. Source repo is
<https://github.com/ahrefs/ppx_deriving_jsonschema/>
This small ppx should help you generate a (hopefully valid) json
schema from an ocaml type.
Generally the derivation tries to produce a schema which looks
natural, and that would also be compatible with the existing derivers
for json out there. Basically you should be able to change the
annotation to `[@@deriving jsonschema, yojson]' (or `json' instead of
`yojson') and to read/write json values that are matching the
schema. There is a bit of tension on things like variants, which are
represented as arrays by ppx_yojson_conv and ppx_deriving_yojson, but
represented as enums by ppx_deriving_jsonschema. I plan to add a way
to switch between the two behaviors soon.
┌────
│ type address = {
│ street: string;
│ city: string;
│ zip: string;
│ } [@@deriving jsonschema]
│
│ type t = {
│ name: string;
│ age: int;
│ email: string option;
│ address: address;
│ } [@@deriving jsonschema]
│
│ let schema = Ppx_deriving_jsonschema_runtime.json_schema t_jsonschema
└────
Will be turned into this schema
┌────
│ {
│ "$schema": "https://json-schema.org/draft/2020-12/schema",
│ "type": "object",
│ "properties": {
│ "address": {
│ "type": "object",
│ "properties": {
│ "zip": { "type": "string" },
│ "city": { "type": "string" },
│ "street": { "type": "string" }
│ },
│ "required": [ "zip", "city", "street" ]
│ },
│ "email": { "type": "string" },
│ "age": { "type": "integer" },
│ "name": { "type": "string" }
│ },
│ "required": [ "address", "age", "name" ]
│ }
└────
Some more advanced functionalities are documented in the readme.
Please let me know if you see any important feature missing, if there
are bugs, or if you have ideas of improvements.
This project was originally started during a Ahrefs dojo, in parallel
to the ICFP conference in Milan, as a way to learn how to write a
ppx. I can't recommend enough
<https://github.com/pedrobslisboa/ppx-by-example> to get going.
[ppx_deriving_jsonschema]
<https://ocaml.org/p/ppx_deriving_jsonschema/latest>
opam 2.3.0~alpha1
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-3-0-alpha1/15325/1>
Kate announced
──────────────
As mentioned in [our talk at the OCaml Workshop 2024], we decided to
switch to a time-based release cycle (every 6 months), starting with
opam 2.3.
As promised, we are happy to announce the first alpha release of opam
2.3.0.
[our talk at the OCaml Workshop 2024]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/10/Opam-2-2-and-beyond>
What's new?
╌╌╌╌╌╌╌╌╌╌╌
• When loading a repository, *opam now ignores files in packages'
`files/' directories which aren't listed in the `extra-files' field*
of the opam file. :warning: If you maintain an opam repository,
please read our [blog post] to make sure your repository stays
compatible.
• *Packages requiring an unsupported version of opam are now marked
unavailable*, instead of causing a repository error. This means an
opam repository can now allow smoother upgrade in the future
• *`opam list --latests-only'*: a new option to list only the latest
versions of packages
• *`--verbose-on'*: a new option to enable verbose output for
specified package names.
• *`opam switch import --deps-only'*: a new option to install only the
dependencies of the root packages listed in the opam switch export
file
• *`opam switch list-available'* will now not display compilers
flagged with `avoid-version~/~deprecated' unless `--all' is given,
meaning that the "trunk" build of OCaml no longer appears to be the
latest version
• *The `builtin-0install' solver was improved* and should now be
capable of being your default solver instead of
`builtin-mccs+glpk'. If you wish to give it a try, simply call
`opam option solver=builtin-0install'
• Most of the *unhelpful conflict messages were fixed* :flashlight:
Various performance and other improvements were made and bugs were
fixed. :open_book: You can read our [blog post] for more information
about these changes and more, and for even more details you can take a
look at the [release note] or the [changelog].
[blog post] <https://opam.ocaml.org/blog/opam-2-3-0-alpha1/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.3.0-alpha1>
[changelog] <https://github.com/ocaml/opam/blob/2.3.0-alpha1/CHANGES>
Try it!
╌╌╌╌╌╌╌
The upgrade instructions are unchanged:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.3.0~alpha1"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/ocaml/opam/master/shell/install.ps1) } -Version 2.3.0~alpha1"
└────
Please report any issues to [the bug-tracker].
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Upcoming OCaml Events (Sep 22, 2024 and onwards)]
• [Eio From a User's Perspective: An Interview With Simon Grondin]
• [Introducing the `odoc' Cheatsheet: Your Handy Guide to OCaml
Documentation]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Upcoming OCaml Events (Sep 22, 2024 and onwards)]
<https://ocaml.org/events>
[Eio From a User's Perspective: An Interview With Simon Grondin]
<https://tarides.com/blog/2024-09-19-eio-from-a-user-s-perspective-an-interview-with-simon-grondin>
[Introducing the `odoc' Cheatsheet: Your Handy Guide to OCaml
Documentation]
<https://tarides.com/blog/2024-09-17-introducing-the-odoc-cheatsheet-your-handy-guide-to-ocaml-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 55720 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-09-17 14:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-09-17 14:02 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 17656 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 10 to
17, 2024.
Table of Contents
─────────────────
Ptime 1.2.0 – Mtime 2.1.0 – Qrc 0.2.0
Unicode 16.0.0 update for Uucd, Uucp, Uunf and Uuseg
Outreachy Demo Presentation
Live Stream to follow OCaml Workshop, ML Workshop, and other talks at ICFP
DkML 2.1.2 and opam 2.2.0
store v0.1.0
Tsdl 1.1.0
OCaml-css 0.2.0
OCaml-stk 0.2.0 and Chamo 4.1.0
DkCoder 2.1.3
Other OCaml News
Old CWN
Ptime 1.2.0 – Mtime 2.1.0 – Qrc 0.2.0
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ptime-1-2-0-mtime-2-1-0-qrc-0-2-0/15268/1>
Daniel Bünzli announced
───────────────────────
There are new releases of these packages:
• [Ptime] POSIX time for OCaml, [release notes], [docs]
• [Mtime] Monotonic time for OCaml, [release notes], [docs]
• [Qrc] QR code encoder for OCaml, [release notes], [docs]
See the individual release notes for details about the changes.
The library structure of Ptime and Mtime was changed to align it on
the mythical library convention and make it for less surprising names
(it used to make sense, it no longer does):
• The `{M,P}time_clock' modules are now in the `{p,m}time.clock'
libraries as they should be. These libraries were also made to
[export] the base `{p,m}time' library so that you can trim you
`requires' when you use the clocks.
• The libraries `{p,m}time.clock.os' are deprecated. They now simply
export `{p,m}time.clock' and warn on usage.
Best and a big thanks to my [donors]
[Ptime] <https://erratique.ch/software/ptime>
[release notes]
<https://github.com/dbuenzli/ptime/blob/master/CHANGES.md#v120-2024-09-10-zagreb>
[docs] <https://erratique.ch/software/ptime/doc>
[Mtime] <https://erratique.ch/software/mtime>
[release notes]
<https://github.com/dbuenzli/mtime/blob/master/CHANGES.md#v210-2024-09-10-zagreb>
[docs] <https://erratique.ch/software/mtime/doc>
[Qrc] <https://erratique.ch/software/qrc>
[release notes]
<https://github.com/dbuenzli/qrc/blob/master/CHANGES.md#v020-2024-09-10-zagreb>
[docs] <https://erratique.ch/software/qrc/doc>
[export]
<https://discuss.ocaml.org/t/proposal-a-new-exports-field-in-findlib-meta-files>
[donors] <https://github.com/sponsors/dbuenzli>
Unicode 16.0.0 update for Uucd, Uucp, Uunf and Uuseg
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-unicode-16-0-0-update-for-uucd-uucp-uunf-and-uuseg/15270/1>
Daniel Bünzli announced
───────────────────────
Unicode 16.0.0 was released on September 10th. It adds 5185 new
characters for a total of 154'998 characters.
If you are into retrocomputing or terminal graphics this may be your
ultimate chance to find an odd character to make an effect among the
686 new [symbols for legacy computing] that are added – I'm hearing
this may me be the last batch, the resource is finite! See the
[announcement page] for links to all the other equally interesting
additions.
If you are obsessed about deep linking into standard definitions, note
that the normative core specification becomes a proper [HTML
document]; rather than a bunch of PDF files or that 1400 pages
hard-copy I once purchased for 5.0.0 circa 2007 :–). The neat result
is that we can now precisely hyperlink to the [normative definition]
of an OCaml [`Uchar.t'] value.
Accordingly these libraries had to be updated (aggregated, boring,
release notes [here])
• [Uucd] 16.0.0 Unicode character database decoder for OCaml, [docs]
• [Uucp] 16.0.0 Unicode character properties for OCaml, [docs]
• [Uunf] 16.0.0 Unicode text normalization for OCaml, [docs]
• [Uuseg] 16.0.0 Unicode text segmentation for OCaml, [docs]
Both `Uucd' and `Uucp' are incompatible releases sinces new block and
script enumerants were added.
Other than that the minimal Unicode introduction and Unicode OCaml
tips is still [here] and remember that despite the uninformed myths
OCaml :heart: Unicode.
A big thanks for funding from the [OCaml Software Foundation] and from
my faithful [donors].
[symbols for legacy computing]
<https://www.unicode.org/charts/PDF/Unicode-16.0/U160-1CC00.pdf>
[announcement page]
<https://blog.unicode.org/2024/09/announcing-unicode-standard-version-160.html>
[HTML document]
<https://www.unicode.org/versions/Unicode16.0.0/core-spec/>
[normative definition]
<https://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-3/#G25539>
[`Uchar.t'] <https://ocaml.org/manual/5.2/api/Uchar.html#TYPEt>
[here] <https://github.com/ocaml/opam-repository/pull/26534>
[Uucd] <http://erratique.ch/software/uucd>
[docs] <http://erratique.ch/software/uucd/doc>
[Uucp] <http://erratique.ch/software/uucp>
[docs] <http://erratique.ch/software/uucp/doc>
[Uunf] <http://erratique.ch/software/uunf>
[docs] <http://erratique.ch/software/uunf/doc>
[Uuseg] <http://erratique.ch/software/uuseg>
[docs] <http://erratique.ch/software/uuseg/doc>
[here] <https://erratique.ch/software/uucp/doc/unicode.html>
[OCaml Software Foundation] <http://ocaml-sf.org/>
[donors] <https://github.com/sponsors/dbuenzli>
Outreachy Demo Presentation
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-demo-presentation/15189/4>
Patrick Ferris announced
────────────────────────
The demo presentation video is now online:
<https://watch.ocaml.org/w/peT3MdWjS1BYYMbowEJ1gv> – thank you to
everyone who joined and particularly the mentors, co-mentors and
interns!
A big thank you also to [Tarides] and [Jane Street] for providing
resources and funding to make this round possible. A reminder that
_today_ is the last day to sign up to the next round – [Outreachy
December 2024 Round]!
[Tarides] <https://tarides.com>
[Jane Street] <https://www.janestreet.com>
[Outreachy December 2024 Round]
<https://discuss.ocaml.org/t/outreachy-december-2024-round/15223>
Live Stream to follow OCaml Workshop, ML Workshop, and other talks at ICFP
══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/live-stream-to-follow-ocaml-workshop-ml-workshop-and-other-talks-at-icfp/15232/4>
jbeckford announced
───────────────────
FYI: For people like me who were on vacation or otherwise unavailable,
the several hour Live Stream is still available.
The intro to the workshop and the first OCaml talk start at
<https://www.youtube.com/live/OuQqblCxJ2Y?t=2254s>.
DkML 2.1.2 and opam 2.2.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dkml-2-1-2-and-opam-2-2-0/15187/5>
jbeckford announced
───────────────────
DkML 2.1.3 was released. The major changes are:
• Upgraded from opam 2.2.0 to opam 2.2.1.
• The ocaml/opam-repository tag was advanced to Sep 10, 2024.
• bugfix: `dk Ml.Switch init' was broken on Linux and macOS. DkML
2.1.2 had incorrectly pinned the `dkml-host-abi' and
`dkml-target-abi' of the master DkML build
machine. <https://gitlab.com/dkml/distributions/dkml/-/issues/24>
• Allow prereleases of Visual Studio; requested at
<https://gitlab.com/dkml/distributions/dkml/-/issues/23>.
Upgrading is:
┌────
│ winget remove dkml # Ignore "exit code: 4294967295"
│ winget install dkml
└────
The full release notes are at
<https://gitlab.com/dkml/distributions/dkml/-/releases/2.1.3>.
store v0.1.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-store-v0-1-0/15274/1>
Basile Clément announced
────────────────────────
I would like to announce the first release of `store' ([docs]), a
library providing a snapshottable bag of mutable references, an
efficient data-structure for back-tracking workloads.
To install it, type `opam update && opam install store'.
Store provides a simple API for capturing and restoring state as well
as easy-to-use high-level wrappers to automatically rollback changes
on failure (`tentatively') or unconditionally (`temporarily'). It
boasts almost-zero overhead when back-tracking is not used and
best-in-class performance for back-tracking use cases.
The design and implementation of Store is described in the paper
[Snapshottable stores], which was given a Distinguished Paper award at
this year's ICFP in Milan. As recognized by this award, the paper is
well-written and easy to understand; please give it a read if you are
interested in either back-tracking workloads or subtle data structure
invariants!
I also want to give a shout-out to François Pottier's Monolith, which
proved invaluable during the development of Store to find and diagnose
subtle bugs.
Store was developed through collaboration between myself (Basile
Clément) at OCamlPro and Gabriel Scherer at Inria, and the persistent
interface was formally verified by Clément Allain and Alexandre Moine
at Inria.
[docs] <https://ocaml.org/p/store/latest/doc/Store/index.html>
[Snapshottable stores] <https://doi.org/10.1145/3674637>
Tsdl 1.1.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-tsdl-1-1-0/15275/1>
Daniel Bünzli announced
───────────────────────
There's a new release of [Tsdl], thin bindings to the C [SDL
library]. See the [release notes] for details.
• Docs: [online] or `odig doc tsdl'
• Install: `opam install tsdl'
Daniel
A big thanks to my [donors].
[Tsdl] <https://erratique.ch/software/tsdl>
[SDL library] <https://www.libsdl.org/>
[release notes]
<https://github.com/dbuenzli/tsdl/blob/master/CHANGES.md#v110-2024-09-12-zagreb>
[online] <https://erratique.ch/software/tsdl/doc/>
[donors] <https://github.com/sponsors/dbuenzli>
OCaml-css 0.2.0
═══════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-css-0-2-0/15276/1>
Zoggy announced
───────────────
[OCaml-css] 0.2.0 is released and already available in opam (package
`css').
OCaml-css is a library to parse and print CSS. ([docs])
Main changes are the introduction of property spaces and partial
handling of nested rules.
Properties are now defined in [spaces]. A [Css] space is predefined,
with some CSS properties, but you can define a new space with specific
properties to use the CSS syntax for these properties in your
application. (this is what is done in the to be not yet released 0.2.0
version of [stk]).
Nested style rules are now parsed and can be [expanded]. Nested
@-rules are not handled yet.
[OCaml-css] <https://zoggy.frama.io/ocaml-css/>
[docs] <https://zoggy.frama.io/ocaml-css/refdoc/css/index.html>
[spaces]
<https://zoggy.frama.io/ocaml-css/refdoc/css/Css/P/index.html#val-mk_prop_space>
[Css]
<https://zoggy.frama.io/ocaml-css/refdoc/css/Css/P/index.html#module-Css>
[stk] <https://zoggy.frama.io/ocaml-stk/>
[expanded]
<https://zoggy.frama.io/ocaml-css/refdoc/css/Css/S/index.html#val-expand_nested>
OCaml-stk 0.2.0 and Chamo 4.1.0
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-stk-0-2-0-and-chamo-4-1-0/15288/1>
Zoggy announced
───────────────
Stk
╌╌╌
A new release of [OCaml-stk], 0.2.0, is now available in opam (package
`stk').
OCaml-stk is a Graphical User Interface library based on on [libSDL
2], through the [Tsdl] bindings.
As the library is under heavy development, this release includes [many
changes]: new widgets, better memory management, css-like theming, …
By cloning [the repository] and running `make', you can then run
`./_build/default/examples/examples.exe'. This example application
contains demonstrations of each widget with the corresponding code in
the same window.
[OCaml-stk] <https://zoggy.frama.io/ocaml-stk/>
[libSDL 2] <https://www.libsdl.org/>
[Tsdl] <https://erratique.ch/software/tsdl>
[many changes]
<https://zoggy.frama.io/ocaml-stk/posts/release-0.2.0.html#changes>
[the repository] <https://framagit.org/zoggy/ocaml-stk>
Chamo
╌╌╌╌╌
A new release of [Chamo], 4.1.0, is also available in opam (package
`chamo').
Chamo is a source code editor, even if it can be used to edit any text
file. It is based on OCaml-stk. This release contains small bug fixes
and follows changes in OCaml-stk.
[Chamo] <https://zoggy.frama.io/chamo/>
DkCoder 2.1.3
═════════════
Archive: <https://discuss.ocaml.org/t/ann-dkcoder-2-1-3/15295/1>
jbeckford announced
───────────────────
I am happy to announce another release of DkCoder - a no-install
OCaml-based scripting framework.
Major changes:
• Split out the Java-like packaging and security tools into the
MlFront project:
<https://discuss.ocaml.org/t/ann-mlfront-a-java-like-package-system-for-ocaml/15072>.
• The DkCoder and MlFront version numbers are now in sync with DkML
version numbers. However, DkCoder is **still alpha** and there is at
least one breaking change coming.
• Several third-party "Us" scripts are embedded and supported. (They
are listed at bottom of this post).
Docs: The main doc page is
<https://diskuv.com/dksdk/coder/2024-intro-scripting/>. But I don't
yet have good reference docs. The samples below have been updated and
are good ways to see what DkCoder can do (use the `V2_1' branches):
• <https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git>
• <https://gitlab.com/diskuv/samples/devops/DkSubscribeWebhook.git>
• <https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git>
There are many bug fixes and new features. The full list is at
[https://github.com/diskuv/dkcoder/blob/1.0/CHANGES.md#2132] - all the
sections from `0.4.0.1' to `2.1.3.2' (inclusive) are new.
[https://github.com/diskuv/dkcoder/blob/1.0/CHANGES.md#2132]
<https://github.com/diskuv/dkcoder/blob/1.0/CHANGES.md#2132>
New "Us" scripts
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
/These scripts can be run inside any of the sample projects above, or
used as ordinary modules in your own DkCoder project source code. Some
scripts, but not all, have a `--help' option./
┌────
│ ./dk DkFs_C99.Dir - Directory manipulation operations.
│ ./dk DkFs_C99.File - (no help) File manipulation operations.
│ ./dk DkFs_C99.Path - Path manipulation operations.
│ ./dk DkNet_Std.Browser - Browser operations.
│ ./dk DkNet_Std.Http - Download content.
│ ./dk DkDev_Std.Legal.Record - Asks for and records your acceptance of legal terms and agreements.
│ ./dk DkDev_Std.Exec - Execute a command in the DkCoder 2.1 runtime environment.
│ ./dk DkDev_Std.Export - Create an `exports` field inside dkproject.jsonc summarizing all the You libraries.
│ ./dk DkDev_Std.Jsontree - (no help) For in-place edits of JSON files.
│ ./dk DkStdRestApis_Gen.* - (no help) (unstable, not ready). OpenAPI 3 service and client generator.
└────
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Upcoming OCaml Events (Sep 15, 2024 and onwards)]
• [Feature Parity Series: Compaction is Back!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Upcoming OCaml Events (Sep 15, 2024 and onwards)]
<https://ocaml.org/events>
[Feature Parity Series: Compaction is Back!]
<https://tarides.com/blog/2024-09-11-feature-parity-series-compaction-is-back>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30268 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-09-10 13:55 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-09-10 13:55 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 29843 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 03 to
10, 2024.
Table of Contents
─────────────────
Oxidizing OCaml — an update
Toy Autograd Engine in OCaml with Apple Accelerate Backend
New release of cppo, with multi-line macros and higher-order macros
OCamlPro's contributions to the 2024 ICFP in Milan
Flambda2 Ep. 3: Speculative Inlining, by OCamlPro
Frustrating Interactions with the OCaml Ecosystem while developing a Synthesizer Library
Cmdlang - Yet Another CLI Library (well, not really)
zarr v0.1.0
Brr 0.0.7
Ocsigen Server 6.0.0
dream-html and pure-html
Advanced Code Navigation coming to OCaml-LSP
Other OCaml News
Old CWN
Oxidizing OCaml — an update
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-oxidizing-ocaml-an-update/15237/1>
Diana Kalinichenko announced
────────────────────────────
Hi everyone! Last year, we made a series of blogposts describing our
plans to introduce Rust-like type system features to OCaml (see
[here]). Now, we are sharing updates on everything we've done since
last year for ICFP 2024. Please read our [blogpost] and check out our
compiler extensions at our [GitHub]!
[here]
<https://discuss.ocaml.org/t/oxidizing-ocaml-and-a-new-opam-switch/12942>
[blogpost] <https://blog.janestreet.com/icfp-2024-index/>
[GitHub]
<https://github.com/janestreet/opam-repository/tree/with-extensions>
Toy Autograd Engine in OCaml with Apple Accelerate Backend
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/toy-autograd-engine-in-ocaml-with-apple-accelerate-backend/15239/1>
John Jewell announced
─────────────────────
I have been venturing to learn a new language and I landed on OCaml
after hearing a few interesting talks from Jane Street. I just made
public a toy autograd engine in OCaml with an Apple Accelerate backend
if anyone is interested:
<https://github.com/jewelltaylor/camlgrad>
I would really appreciate any feedback in terms of the OCaml code that
I wrote so that I can improve. If anyone is willing to quickly take a
look it would mean a lot :slight_smile:
New release of cppo, with multi-line macros and higher-order macros
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-cppo-with-multi-line-macros-and-higher-order-macros/15241/1>
François Pottier announced
──────────────────────────
It is my pleasure to announce a new release of cppo (v1.7.0) with two
new features.
⁃ The new syntax `#def ... #enddef' allows a macro definition to span
several lines, without backslashes. This syntax allows macro
definitions to be nested.
┌────
│ #def repeat_until(action,condition)
│ action;
│ while not (condition) do
│ action
│ done
│ #enddef
└────
⁃ A parameterized macro can take a parameterized macro as a parameter:
this is a higher-order macro.
┌────
│ #define TWICE(e) (e + e)
│ #define APPLY(F : [.], e) (let x = (e) in F(x))
│ let forty_two =
│ APPLY(TWICE,1+2+3+4+5+6)
└────
For more details, please see the [documentation].
[documentation]
<https://github.com/ocaml-community/cppo/?tab=readme-ov-file#multi-line-macros-and-nested-macros>
OCamlPro's contributions to the 2024 ICFP in Milan
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocamlpros-contributions-to-the-2024-icfp-in-milan/15244/1>
OCamlPro announced
──────────────────
Today, a quick head's up about our contributions to this year's
International Conference on Functional Programming which is unraveling
right now in Milan!
This year, our team presents two topics:
• ["Snapshottable Stores"]: A generic and efficient data structure for
the implementation of backtracking algorithms, used particularly in
automatic theorem provers and type checkers. This implementation in
OCaml will soon be available on opam.
• [A presentation on opam], detailing the contents of the latest major
release 2.2, which was released in July, as well as how the opam
team operates.
Be sure to checkout [the event], there are plenty of great
presentations and video replays!
Until next time, which will be sooner than later with another one of
our [Flambda2 Snippets],
Kind regards, The OCamlPro Team
["Snapshottable Stores"]
<https://icfp24.sigplan.org/details/icfp-2024-papers/14/Snapshottable-Stores>
[A presentation on opam]
<https://icfp24.sigplan.org/details/ocaml-2024-papers/10/Opam-2-2-and-beyond>
[the event]
<https://web.cvent.com/event/728be387-4e89-4930-a4e4-51f9d1d6209e/summary>
[Flambda2 Snippets]
<https://ocamlpro.com/blog/2024_03_18_the_flambda2_snippets_0/>
Flambda2 Ep. 3: Speculative Inlining, by OCamlPro
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-flambda2-ep-3-speculative-inlining-by-ocamlpro/15250/1>
OCamlPro announced
──────────────────
As promised in our [previous post] about OCamlPro's contributions to
this year's International Conference of Functional Programming, we
back again with a new entry in our [Flambda2 Snippet blog series]!
[Flambda2 Ep. 3: Speculative Inlining] covers inlining in general as
well as how our compiler handles it. We go in detail about how
`Speculative Inlining' allows more significant optimisations to take
place.
This blog entry is key for a smooth read of our next article which
will cover `Upwards and Downwards Traversals' in Flambda2.
Happy to say that it's already quite far down the release pipeline!
[previous post]
<https://discuss.ocaml.org/t/ocamlpros-contributions-to-the-2024-icfp-in-milan/15244>
[Flambda2 Snippet blog series]
<https://ocamlpro.com/blog/2024_03_18_the_flambda2_snippets_0/#listing>
[Flambda2 Ep. 3: Speculative Inlining]
<https://ocamlpro.com/blog/2024_08_09_the_flambda2_snippets_3/>
Frustrating Interactions with the OCaml Ecosystem while developing a Synthesizer Library
════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-frustrating-interactions-with-the-ocaml-ecosystem-while-developing-a-synthesizer-library/15253/1>
Steve Sherratt announced
────────────────────────
<https://www.gridbugs.org/frustrating-interactions-with-the-ocaml-ecosystem-while-developing-a-synthesizer-library/>
Last year I made a synthesizer library in OCaml and had some struggles
using Dune and Opam, and also ran into several issues with
libraries. I wrote a blog post about all the problems I encountered.
Cmdlang - Yet Another CLI Library (well, not really)
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/cmdlang-yet-another-cli-library-well-not-really/15258/1>
Mathieu Barbin announced
────────────────────────
I hope you had a nice summer! Mine took an unexpected turn when,
roughly at the same time, I wrote my first `cmdliner' subcommand and
heard about `climate' for the first time. My experience with OCaml CLI
so far had been centered around `core.command'.
When I read climate's [terminology] section and how it defines
`Terms', `Arguments', and `Parameters', something clicked. Seeing how
`climate''s API managed to make positional and named arguments fit so
nicely together, I thought: "Wow, for the first time, it seems I'll be
able to write a CLI spec on a whiteboard without referring to some
code I never seem to get right (I am looking at you, `core.command''s
anonymous arguments)."
I got quite excited and thought: "Can I switch to `climate' today?"
But reality checked: it's not on opam yet, still under construction,
I'm not sure what the community will do, etc.
Implementing my own engine for an API resembling `climate' felt like a
wasted effort, knowing about the work happening in `climate'. Still,
having a `'a Param.t', `'a Arg.t', and `'a Command.t' type that I
would get to know and love felt too good to pass up.
I stared at the `climate' types for a while, and filled with happy
thoughts about a bright CLI future, it occurred to me: can I use an
API like `climate' but compile it down to existing libraries such as
`cmdliner' or `core.command'? (and `climate' too!). I wrote down the
following types:
[terminology]
<https://github.com/gridbugs/climate?tab=readme-ov-file#terminology>
Climate
╌╌╌╌╌╌╌
┌────
│ 'a Param.t -> 'a Climate.Arg_parser.conv
│ 'a Ast.Arg.t -> 'a Climate.Arg_parser.t
│ 'a Command.t -> 'a Climate.Command.t
└────
Cmdliner
╌╌╌╌╌╌╌╌
┌────
│ 'a Param.t -> 'a Cmdliner.Arg.conv
│ 'a Arg.t -> 'a Cmdliner.Term.t
│ 'a Command.t -> 'a Cmdliner.Cmd.t
└────
core.command
╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ 'a Param.t -> 'a core.Command.Arg_type.t
│ 'a Arg.t -> 'a core.Command.Param.t
│ unit Command.t -> core.Command.t
└────
… which I interpreted as stating the following theorem:
There exists an abstraction to encode OCaml CLIs that
lives in the intersection of what's expressible in other
well established libraries.
"One EDSL to command them all," so to speak. I couldn't resist the
temptation to build actual terms for these types. That gave birth to
[cmdlang].
As a test, I switched one of my projects to `cmdlang', with `cmdliner'
as a backend. I liked the [changes] I made in the process. The 1-line
[bin/main.ml] is now the only place that specifies which backend I
want to use; the rest of the code is programmed solely against the
`cmdlang' API. This means I'll be able to easily experiment with
compiling down to `climate' in the future.
I am not against the multiplicity of solutions in general, but I tend
to feel uneasy when incompatible libraries emerge, partitioning the
ecosystem. As a community, we know too many examples of this. In this
instance, I want to call the `core.command' vs `cmdliner' situation a
… cli-vage.
I don't see my work on `cmdlang' as competing with these other
libraries. Quite the contrary, it makes it easier for me to experiment
with them without much changes while exploring the subject of CLI in
general. Also, as a library author, if you wish to expose CLI helpers
to your users, a library like `cmdlang' will give you a pleasant way
to do so, as you can express your helpers with it, knowing your users
will have the choice to translate them to the backend of their choice.
Before writing this post, I had a very pleasant chat with @gridbugs. I
want to make it clear that I do not think `cmdlang' is competing with
`climate' either. I think `climate' is a very promising library and I
believe it will, in due time, deliver auto-completion to many - this
has been a highly anticipated feature within the community. I wish to
dedicate the initial work that I did on `cmdlang' to @gridbugs due to
the impactful influence climate had on my work, and how it helped me
improve my general understanding of declarative CLI libraries.
These are very early days for `cmdlang'. There are still areas I am
fuzzy on, and I haven't really validated the whole design yet. I have
put some thoughts in this [Future Plans] page. One thing that I did
not initially include there would be to explore the feasibility of
writing a mini-compiler for `cmdlang' targeting `stdlib.arg' as a
runner. I am not sure how much you'd end up restricting `cmdlang' for
this to work. I thought that'd be a fun project to tackle at a future
point, as it would make a nice addition to the overall architecture of
the project.
I'd welcome your input to help me shape the future of `cmdlang' if you
have an interest in this project.
Thanks for reading!
[cmdlang] <https://github.com/mbarbin/cmdlang>
[changes] <https://github.com/mbarbin/bopkit/pull/14>
[bin/main.ml] <https://github.com/mbarbin/bopkit/blob/main/bin/main.ml>
[Future Plans]
<https://mbarbin.github.io/cmdlang/docs/explanation/future_plans/>
zarr v0.1.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-zarr-v0-1-0/15259/1>
zoj613 announced
────────────────
Hi everyone, I'd like to announce the first release of `zarr', an
Ocaml implementation of the [Zarr version 3 storage format
specification] for chunked & compressed multi-dimensional arrays,
designed for use in parallel computing.
<https://zarr-specs.readthedocs.io/en/latest/_images/terminology-hierarchy.excalidraw.png>
[Zarr version 3 storage format specification]
<https://zarr-specs.readthedocs.io/en/latest/v3/core/v3.0.html>
why?
╌╌╌╌
The project was mainly inspired by the lack of functional programming
language implementations of this specification as shown in this
[implementations table]. Since I have been learning OCaml these past
few months I figured I'd take on the challenge of producing the first
functional programming implementation of Zarr, and it was a great
learning experience!
[implementations table] <https://zarr.dev/implementations/>
Features
╌╌╌╌╌╌╌╌
• Supports creating n-dimensional Zarr arrays and chunking them along
any dimension.
• Compress array chunks using a variety of supported compression
codecs.
• Supports indexing operations to read/write views of a Zarr array.
• Supports storing arrays in-memory or the local filesystem. It is
also extensible, allowing users to easily create and use their own
custom storage backends. See the example implementing a [Zip file
store] for more details.
• Supports both synchronous and concurrent I/O via `Lwt' and `Eio'.
• Leverages the strong type system of Ocaml to create a type-safe API;
making it impossible to create, read or write malformed arrays.
• Supports organizing arrays into hierarchies using [Groups].
[Zip file store]
<https://github.com/zoj613/zarr-ml/blob/main/examples/inmemory_zipstore.ml>
[Groups]
<https://zarr-specs.readthedocs.io/en/latest/v3/core/v3.0.html#group>
Example
╌╌╌╌╌╌╌
Below is a demo of the library's API for creating, reading and writing
to a Zarr hierarchy.
┌────
│ open Zarr
│ open Zarr.Metadata
│ open Zarr.Node
│ open Zarr.Codecs
│ open Zarr.Indexing
│ open Zarr_sync.Storage
│ (* opens infix operators >>= and >>| for monadic bind & map *)
│ open FilesytemStore.Deferred.Infix
│
│ let store = FilesystemStore.create "testdata.zarr" in
│ let group_node = GroupNode.of_path "/some/group" in
│ FilesystemStore.create_group store group_node;
│ let array_node = ArrayNode.(group_node / "name");;
│ (* creates an array with char data type and fill value '?' *)
│ FilesystemStore.create_array
│ ~codecs:[`Transpose [|2; 0; 1|]; `Bytes BE; `Gzip L2]
│ ~shape:[|100; 100; 50|]
│ ~chunks:[|10; 15; 20|]
│ Ndarray.Char
│ '?'
│ array_node
│ store;
│ let slice = [|R [|0; 20|]; I 10; R [||]|] in
│ let x = FilesystemStore.read_array store array_node slice Ndarray.Char in
│ (* Do some computation on the array slice *)
│ let x' = Zarr.Ndarray.map (fun _ -> Random.int 256 |> Char.chr) x in
│ FilesystemStore.write_array store array_node slice x';
│ let y = FilesystemStore.read_array store array_node slice Ndarray.Char in
│ assert (Ndarray.equal x' y);
└────
Installation
╌╌╌╌╌╌╌╌╌╌╌╌
The library comes in several flavors depending on the synchronous /
asynchronous backend of choice. To install the synchronous API, use
┌────
│ $ opam install zarr-sync
└────
To install zarr with an asynchronous API powered by `Lwt' or `Eio',
use
┌────
│ $ opam install zarr-lwt
│ $ opam install zarr-eio
└────
The documentation can be found [here] and the source code [there]
I'm happy to answer any questions regarding the library and more than
welcome suggestions for improvements (especially performance!), issue
reports as well as PR's.
[here] <https://zoj613.github.io/zarr-ml/>
[there] <https://github.com/zoj613/zarr-ml>
Brr 0.0.7
═════════
Archive: <https://discuss.ocaml.org/t/ann-brr-0-0-7/15263/1>
Daniel Bünzli announced
───────────────────────
There'a new release of [Brr], an ISC licenced toolkit for programming
browsers with the `js_of_ocaml' compiler.
This release has some changes to support work being done for
`wasm_of_ocaml'; thanks to @vouillon for his patches. There are also
other small fixes and additions, consult the [release notes] for the
details and thanks to all the contributors.
A big thanks to my [donators] for supporting my work. I welcome the
(not so[^1]) new donator [Tarides].
[Home page], [Docs and manuals] or `odig doc brr'
Install: `opam install brr' ([PR])
Best,
Daniel
[^1]: Tarides has been /generously/ donating for my work from the
onset but used to do it via the [Mirage] organisation.
[Brr] <https://erratique.ch/software/brr>
[release notes]
<https://github.com/dbuenzli/brr/blob/f9f4de5c9385ceb80164c043943e3a2d65e577c3/CHANGES.md#v007-2024-09-09-zagreb>
[donators] <https://github.com/sponsors/dbuenzli>
[Tarides] <https://tarides.com/>
[Home page] <https://erratique.ch/software/brr>
[Docs and manuals] <https://erratique.ch/software/brr/doc/>
[PR] <https://github.com/ocaml/opam-repository/pull/26517>
[Mirage] <https://github.com/mirage>
Ocsigen Server 6.0.0
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocsigen-server-6-0-0/15265/1>
Vincent Balat announced
───────────────────────
We're delighted to announce a major new version of Ocsigen Server!
This version 6.0.0 focuses on the use of Ocsigen Server as a library,
without any configuration file, which is now much easier and brings
the exact same features as the executable.
*Example of use:*
To add a Web server to your OCaml program, serving static files from
directory `static`:
┌────
│ let _ = Ocsigen_server.start
│ [ Ocsigen_server.host [Staticmod.run ~dir:"static" ()]]
└────
Install:
┌────
│ opam install ocsigenserver
└────
Example of Dune file for this program:
┌────
│ (executable
│ (public_name myproject)
│ (name main)
│ (libraries
│ main
│ ocsigenserver
│ ocsigenserver.ext.staticmod))
└────
Compile with:
┌────
│ dune build
└────
Ocsigen Server can of course still be used as an executable taking its
configuration from a file. This allows for non OCaml developers to use
it and make their own configurations. It also makes it possible to
distribute a binary version of your Web applications.
Ocsigen Server is build in modular and extensible way. The default
opam packages comes with several extensions. In the example above, we
are using Staticmod for serving static files. Other extensions makes
it possible for example to configure redirections, to control the
access to some sub-directory, to use a reverse proxy, to rewrite the
request, compress the output etc.
The programming interface follows exactly the structure of the
configuration file: instructions are tried in order until one
generates a result, then some other instructions can be used to change
the result (like compressing it or adding some headers).
Here is a more complex example of configuration:
┌────
│ let _ =
│ Ocsigen_server.start
│ ~ports:[`All, 8080]
│ ~command_pipe:"local/var/run/mysite-cmd"
│ ~logdir:"local/var/log/mysite"
│ ~datadir:"local/var/data/mysite"
│ ~default_charset:(Some "utf-8")
│ [ Ocsigen_server.host
│ ~regexp:"mydomain.com"
│ [ Ocsigen_server.site ["subsite"]
│ [ Accesscontrol.(
│ if_
│ (and_
│ [ ip "122.122.122.122"
│ ; header ~name:"user-agent" ~regexp:".*FooBar.*"
│ ; method_ `POST ])
│ [forbidden] [])
│ ; Authbasic.run ~realm:"myrealm"
│ ~auth:(fun _u p -> Lwt.return (p = "toto"))
│ ()
│ ; Staticmod.run ~dir:"local/var/www/otherdir" () ]
│ ; Ocsigen_server.site ["othersubsite"]
│ [ Revproxy.run
│ ~redirection:
│ (Revproxy.create_redirection ~full_url:false ~regexp:"(.*)"
│ ~keephost:true "http://localhost:8888/\\1")
│ () ]
│ ; Redirectmod.run
│ ~redirection:
│ (Redirectmod.create_redirection ~full_url:false ~regexp:"old(.*)"
│ "new\\1")
│ ()
│ ; Staticmod.run ~dir:"local/var/www/staticdir" ()
│ ; Cors.run ~max_age:86400 ~credentials:true ~methods:[`POST; `GET; `HEAD]
│ ~exposed_headers:
│ [ "x-eliom-application"
│ ; "x-eliom-location"
│ ; "x-eliom-set-process-cookies"
│ ; "x-eliom-set-cookie-substitutes" ]
│ ()
│ ; Deflatemod.run
│ ~mode:
│ (`Only
│ [ `Type (Some "text", Some "html")
│ ; `Type (Some "text", Some "javascript")
│ ; `Type (Some "text", Some "css")
│ ; `Type (Some "application", Some "javascript")
│ ; `Type (Some "application", Some "x-javascript")
│ ; `Type (Some "application", Some "xhtml+xml")
│ ; `Type (Some "image", Some "svg+xml")
│ ; `Type (Some "application", Some "x-eliom") ])
│ () ] ]
└────
In this example, the server defines one virtual host for domain
`mydomain.com'. It will first check whether it is a request for
directory `subsite/', and if yes, will reject the request with 403
Forbidden if it is a POST request coming from user-agent `FooBar' at
IP 122.122.122.122. If not, it will ask for a password before serving
files from directory `local/var/www/otherdir'. Then we define another
subsite `othersubsite' for which the requests will be transfered to
another Web server running locally on port 8888, then rewrite the
answer location header accordingly. Then, if the page is still not
generated, the server will send a redirection if URLs starts with
"old". Otherwise, it will try to serve files from directory
`local/var/www/staticdir'. If the page has still not been found, a
`404 Not found' will be sent, otherwise, some CORS headers will be
added, and the result will be compressed before being sent.
Compile this example with the following dune file:
┌────
│ (executable
│ (public_name myserver)
│ (name main)
│ (libraries
│ ocsigenserver
│ ocsigenserver.ext.staticmod
│ ocsigenserver.ext.authbasic
│ ocsigenserver.ext.extendconfiguration
│ ocsigenserver.ext.outputfilter
│ ocsigenserver.ext.cors
│ ocsigenserver.ext.accesscontrol
│ ocsigenserver.ext.deflatemod
│ ocsigenserver.ext.redirectmod
│ ocsigenserver.ext.revproxy
│ ))
└────
Eliom and Ocsigen Start have also been updated for being used without
configuration file and will be released very soon.
dream-html and pure-html
════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/14808/4>
Yawar Amin announced
────────────────────
[ANN] dream-html & pure-html 3.6.1, 3.6.2
A double announcement:
3.6.1: when in XML rendering mode, correctly render empty-value
attributes as having an empty string value. Thanks to @jonsterling !
3.6.2: automatically switch to XML rendering mode when rendering SVG
and MathML tags inside HTML rendering mode.
Advanced Code Navigation coming to OCaml-LSP
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-advanced-code-navigation-coming-to-ocaml-lsp/15266/1>
PizieDust announced
───────────────────
Jump to Target
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Currently, the standard LSP protocol only allows for generalized code
navigation (`goto definition`, `goto declaration`, `goto
implementation`, `goto type-definition`), which is not very useful
when it comes to precise movements.
Coming to OCaml-lsp soon will be the ability to jump from one point in
your code to another based on [Merlin's Jump] command.
Implementing this functionality took a bit of thinking as we wanted a
solution that works for all supported editors (Vscode, Emacs and Vim)
without any additional specific client implementations. We used a
combination of call actions plus the LSP showDocumentRequest to move
the cursor to the interesting position.
The call actions display are contextual and will display only if it's
relevant to the code under the cursor.
Here is a demo in VSCode.
<https://global.discourse-cdn.com/business7/uploads/ocaml/original/2X/6/618bfd77db1a89256eeeaf69b6d3817dbfdd8dc0.gif>
[Merlin's Jump]
<https://github.com/ocaml/merlin/blob/main/doc/dev/PROTOCOL.md#jump--target-string--position-position>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Outreachy May 2024 Demo]
• [Frama-Clang v0.0.16 for Frama-C 29.0 Copper]
• [Easy Debugging for OCaml With LLDB]
• [Getting Specific: Announcing the Gospel and Ortac Projects]
• [Upcoming OCaml Events (Sep 2024 and onwards)]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Outreachy May 2024 Demo]
<https://watch.ocaml.org/w/peT3MdWjS1BYYMbowEJ1gv>
[Frama-Clang v0.0.16 for Frama-C 29.0 Copper]
<https://frama-c.com/html/news.html#2024-09-05>
[Easy Debugging for OCaml With LLDB]
<https://tarides.com/blog/2024-09-05-easy-debugging-for-ocaml-with-lldb>
[Getting Specific: Announcing the Gospel and Ortac Projects]
<https://tarides.com/blog/2024-09-03-getting-specific-announcing-the-gospel-and-ortac-projects>
[Upcoming OCaml Events (Sep 2024 and onwards)]
<https://ocaml.org/events>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 53773 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-09-03 8:24 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-09-03 8:24 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 11512 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 27 to
September 03, 2024.
Table of Contents
─────────────────
ppx_minidebug 2.0: verbosity levels
Ppx by example - repo to help on ppx learning
Blog Post: Simple Example where Ocaml calls a C function
Outreachy December 2024 Round
Other OCaml News
Old CWN
ppx_minidebug 2.0: verbosity levels
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-minidebug-2-0-verbosity-levels/15212/1>
Lukasz Stafiniak announced
──────────────────────────
I'm pleased to mention that [ppx_minidebug 2.0] is available now. The
README at [ppx_minidebug - GitHub] is the user manual, and the runtime
API is documented here: [ppx_minidebug.Minidebug_runtime].
Version 2.0 brings linear verbosity log levels. Both logging scopes
and individual log statements can be either: at a default (omitted)
log level, at a compile-time log level (e.g. `[%log2 "test"]' logs
`test' at level 2), or at a runtime-provided log level (e.g. `[%logN
for_level; "test"]' logs `test' at level `for_level'). When the level
to log at is omitted, it is inherited from its direct syntactic
logging scope (i.e. the log entry that the log or log entry is
syntactically in – not the log entry that the log is dynamically
attached to, if it's different). Providing a compile-time log level
will prune the generated code accordingly. See more here:
[ppx_minidebug: Using as a logging framework].
Version 1.6 brought support for local runtimes, where the runtime for
logging in a logging scope is fetched by a user-provided function. The
function can for example use domain-local storage. See more here:
[ppx_minidebug: Dealing with concurrent execution].
Happy debugging!
[ppx_minidebug 2.0] <https://github.com/lukstafi/ppx_minidebug>
[ppx_minidebug - GitHub] <https://github.com/lukstafi/ppx_minidebug>
[ppx_minidebug.Minidebug_runtime]
<https://lukstafi.github.io/ppx_minidebug/ppx_minidebug/Minidebug_runtime/index.html>
[ppx_minidebug: Using as a logging framework]
<https://github.com/lukstafi/ppx_minidebug?tab=readme-ov-file#using-as-a-logging-framework>
[ppx_minidebug: Dealing with concurrent execution]
<https://github.com/lukstafi/ppx_minidebug?tab=readme-ov-file#dealing-with-concurrent-execution>
Ppx by example - repo to help on ppx learning
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ppx-by-example-repo-to-help-on-ppx-learning/15213/1>
Pedro Braga announced
─────────────────────
Over the past few weeks, I've started my journey to learn PPX, and
during this process, I found it challenging to find examples. So, I
began creating my own examples and adding explanations for myself.
I realized that I could make my examples and explanations public
because this would push me to learn more deeply (as I’d need to
provide better and clearer explanations) and could also help anyone
else on this learning path. @davesnx also encouraged me to share my
process (maybe through a blog post in the future). So, I created this
repository: [github.com/pedrobslisboa/ppx-by-example].
The idea is to have examples and an explanation for each detail on
those. It has also a brief explanation about the subject on every
README.
I have a few notes:
• It is a wip project, which means that there are parts in
development. But sharing it is also a way to push me to improve this
project.
• As I said, I'm on the process of learning PPX, so probably I missed
or added something wrongly, so please If you notice it, share it on
the repo so I can fix.
• I am also in the process of learning OCaml. I started coding in
OCaml this year (professionally just last month), so this repository
might not have the best code. If you think it can be improved,
please let me know. :heart:
• I'm not a native English speaker or the best writer. I asked ChatGPT
to help fix some mistakes and improve cohesion, but if you notice
anything that needs to be improved, please let me know. :heart:
Besides that, any comments, help, or additions are welcome. I hope
this can be helpful :3 Thank you all!
[github.com/pedrobslisboa/ppx-by-example]
<https://github.com/pedrobslisboa/ppx-by-example>
Blog Post: Simple Example where Ocaml calls a C function
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-post-simple-example-where-ocaml-calls-a-c-function/15211/3>
Deep in this thread, Tim McGilchrist said
─────────────────────────────────────────
My favourite example at the moment is this one from [Retrofitting
Effect Handlers onto OCaml]. It shows OCaml calling C, C calling an
OCaml callback and exceptions crossing those boundaries.
┌────
│ $ cat meander.ml
└────
┌────
│ external ocaml_to_c
│ : unit -> int = "ocaml_to_c"
│ exception E1
│ exception E2
│ let c_to_ocaml () = raise E1
│ let _ = Callback.register
│ "c_to_ocaml" c_to_ocaml
│ let omain () =
│ try (* h1 *)
│ try (* h2 *) ocaml_to_c ()
│ with E2 -> 0
│ with E1 -> 42
│ let _ = assert (omain () = 42)
└────
┌────
│ $ cat meander_c.c
└────
┌────
│ #include <caml/mlvalues.h>
│ #include <caml/callback.h>
│
│ value ocaml_to_c (value unit) {
│ caml_callback(*caml_named_value
│ ("c_to_ocaml"), Val_unit);
│ return Val_int(0);
│ }
└────
Compile it with OCaml 5.2:
┌────
│ $ ocamlopt --version
│ 5.2.0
│ $ ocamlopt meander_c.c meander.ml -o meander.exe
│ $ ./meander.exe
│ $ echo $?
│ 0
└────
Bonus you can use GDB/LLDB on this to set breakpoints in both OCaml
and C.
[Retrofitting Effect Handlers onto OCaml]
<https://doi.org/10.1145/3453483.3454039>
Outreachy December 2024 Round
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-december-2024-round/15223/1>
Patrick Ferris announced
────────────────────────
With the conclusion of the previous Outreachy round (see [Outreachy
Demo Presentation]), the next round is fast approaching and the OCaml
community has signed up again to participate!
[Outreachy Demo Presentation]
<https://discuss.ocaml.org/t/outreachy-demo-presentation/15189>
The Next Round
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The *deadline for mentors to [submit a project] is [date=2024-09-11
timezone="Europe/London"]*. If people are interested in mentoring and
they maintain an open-source project, then they can reach out directly
to me and I can help scope a project, explain the contribution period
and provide as much other help as we can! Co-mentoring is also an
option for people who are interested in mentoring but do not have a
specific project – do reply to this thread if that's you!
When signing up mentors propose an open-source project where
prospective interns submit PRs during the “contribution phases” as
part of their application. Mentors will then choose an intern to work
with for 3 months. A more detailed explanation is available [on the
Outreachy mentor section ].
I'm particularly interested in *projects from some of the larger OCaml
projects* (e.g. dune, opam, ppxlib, miou, eio, cohttp, melange
etc.). I'm very happy to help with co-mentoring on any of these
projects. If you are interested and are a maintainer of a larger
project, please do reach out. Of course, smaller projects are still
very much possible.
[submit a project] <https://www.outreachy.org/communities/cfp/ocaml/>
[on the Outreachy mentor section ]
<https://www.outreachy.org/mentor/#mentor>
Funding
╌╌╌╌╌╌╌
_Funding for this upcoming Outreachy round is not yet finalised_. We
hope to have funding for three interns, I will reply to this thread
once things are confirmed which should be soon. If any company is
interested in supporting the OCaml community Outreachy initative
please do reach out to me.
I'd also like to take this moment to raise some awareness for the
current [struggles Outreachy is facing]. The OCaml community has
benefited massively from Outreachy. Both by participating directly as
a community (see <https://ocaml.org/outreachy> for some past projects)
and via the participation of other communities. I'm very grateful for
everyone who has taken part in some way, including non-mentors
engaging with the interns.
As always if you have any general questions or mentoring ideas do
comment on this thread or reach out directly.
Thanks!
[struggles Outreachy is facing]
<https://www.outreachy.org/blog/2024-08-14/outreachy-needs-your-help/>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The Biggest Functional Programming Conference of the Year: What are
we Bringing to ICFP?]
• [ICFP 2024]
• [Project-Wide Occurrences: A New Navigation Feature for OCaml 5.2
Users]
• [What the interns have wrought, 2024 edition]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The Biggest Functional Programming Conference of the Year: What are we
Bringing to ICFP?]
<https://tarides.com/blog/2024-08-30-the-biggest-functional-programming-conference-of-the-year-what-are-we-bringing-to-icfp>
[ICFP 2024] <https://blog.janestreet.com/icfp-2024-index/>
[Project-Wide Occurrences: A New Navigation Feature for OCaml 5.2 Users]
<https://tarides.com/blog/2024-08-28-project-wide-occurrences-a-new-navigation-feature-for-ocaml-5-2-users>
[What the interns have wrought, 2024 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2024-edition-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 23041 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-08-27 9:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-08-27 9:02 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 10714 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 20 to 27,
2024.
Table of Contents
─────────────────
DkML 2.1.2 and opam 2.2.0
Outreachy Demo Presentation
opam 2.2.1
Ppxlib dev meetings
First release of corosync
Other OCaml News
Old CWN
DkML 2.1.2 and opam 2.2.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dkml-2-1-2-and-opam-2-2-0/15187/1>
jbeckford announced
───────────────────
The major focus of DkML 2.1.2 is shipping it with opam 2.2 and having
/some/ coexistence between DkML and opam 2.2 on Windows. You can skip
this post if you don't develop on Windows.
TLDR: Upgrade with `winget upgrade dkml'. Use `opam-real' to use pure
opam 2.2 but only *after* installing Visual Studio 2022 (confer:
release notes); example: `opam-real switch create 5.2.0+msvc'. Use `dk
Ml.Switch init' to create DkML 4.14.2 switch. DkML has better MSVC
package support today, while pure opam 2.2 has latest OCaml 5 and is
the standard going forward; now you choose both without compromise.
Major changes:
• Uses opam 2.2.0. You can directly use unmodified opam 2.2 with
`opam-real switch create 5.2.0+msvc'. Or continue to use `dk
Ml.Switch init' (or the deprecated `dkml init') to create a DkML
4.14.2 switch which supports more native MSVC Windows packages (for
now) but does not have the latest and experimental OCaml language
features.
• Support Windows SDK 11 (10.0.22621.0) and VC 17.9 and 17.10
(14.39/4x) added to allowed list. This makes it easier to coexist
with opam 2.2 which requires Visual Studio 2022, and supports latest
GitLab CI with its preinstallation of Visual Studio 2022.
• The ocaml/opam-repository tag was advanced to Aug 15, 2024.
• You can continue to use `dkml.exe' and `with-dkml.exe' but both are
deprecated. The new (unified) executable is `dk.exe'. See
"Deprecated Commands" in the release notes.
• Once every two weeks DkML news about new versions, errata,
uninstalling, etc. will be shown on a webpage. It is triggered from
the now deprecated `dkml init', the replacement `dk Ml.Switch init'
and the `with-dkml' proxy commands, and can be disabled with `dk
Ml.News disable'. In particular, use `dk Ml.News' to show the news
if you are experiencing problems with DkML.
• The patches to the OCaml compiler are now dual-licensed with OCaml's
LGPL 2.1 exception and Apache 2.0. All other source (especially the
build scripts) for the DkML compiler is licensed solely with Apache
2.0. This is a follow-up to
<https://github.com/ocaml/ocaml/issues/13177>.
• The uninstaller/upgrader stops `opam', `dune' and other OCaml
processes since, on Windows, in-use executables can't be deleted or
updated. This feature is not foolproof yet.
• ull release notes are at
<https://gitlab.com/dkml/distributions/dkml/-/releases/2.1.2>.
Enjoy! And thanks to OCSF for supporting Windows in the last couple of
gap years.
/Bug reports: [GitHub users] or
[[<https://gitlab.com/dkml/distributions/dkml>/-/issues][GitLab
users]]./
[GitHub users] <https://github.com/diskuv/dkml-installer-ocaml/issues>
Outreachy Demo Presentation
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-demo-presentation/15189/1>
Patrick Ferris announced
────────────────────────
It is my pleasure to announce that next Friday [date=2024-08-30
time=13:00:00 timezone="Europe/London"] we will host the Outreachy
Demo presentation. We invite all of the OCaml community and beyond to
join us in celebrating the hard work of the community's three interns
who have been working on:
• [ocaml-api-watch]: _Libraries and tools to keep watch on you OCaml
lib's API changes_
• [diffcessible]: _a terminal based diff viewer with an emphasis on
being accessible_
• [ocaml-practice-exercises]: _Practice exercises for learning OCaml
supporting GitHub Codespaces, Replit, and locally with Jupyter
Notebook or directly on your machine._
We'll post the meeting link closer to the time. Hopefully see you
there! :camel:
[ocaml-api-watch] <https://github.com/NathanReb/ocaml-api-watch>
[diffcessible] <https://github.com/panglesd/diffcessible>
[ocaml-practice-exercises]
<https://github.com/divyankachaudhari/ocaml-practice-exercises>
opam 2.2.1
══════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-2-1/15192/1>
R. Boujbel announced
────────────────────
We are pleased to announce the release of opam 2.2.1.
We've fixed a couple of regressions and would like to encourage users
of opam 2.2 to upgrade:
• Fix a regression in `opam install --deps-only' where the direct
dependencies were not set as root packages
• Fix a regression when fetching git packages where the resulting git
repository could lead to unexpected outputs of git commands, by
disabling shallow clone by default except when fetching an opam
repositories
• Mitigate [curl/curl#13845] by falling back from `--write-out' to
`--fail' if exit code 43 is returned by curl. In particular, this
fixes `opam init' when run from cmd/PowerShell on Windows 11 23H2
You’ll find more information in the [release blog post ].
To upgrade, simply run for Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.2.1"
└────
from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/ocaml/opam/master/shell/install.ps1) }"
└────
[curl/curl#13845] <https://github.com/curl/curl/issues/13845>
[release blog post ] <https://opam.ocaml.org/blog/opam-2-2-1>
David Allsopp then added
────────────────────────
Windows 11 users are strongly encouraged to upgrade to opam 2.2.1 for
the mitigation for curl 8.8.0.
opam 2.2.1 is also available via `winget', with `winget upgrade
OCaml.opam'. The `OCaml.opam' winget package downloads the opam binary
from GitHub releases page (thanks to @prometheansacrifice, for
contributing the original package!), so installing via winget is
functionally equivalent to using our `install.ps1' script.
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/30>
Patrick Ferris announced
────────────────────────
This week's [meeting notes are available online].
Here's a brief TL;DR of some of the main points of discussion.
• *5.2 AST bump progress* is waiting for patches to as many ppxes as
possible and for fixes to the migration bug(s) (see next bullet
point). If ppx authors wish to try the new ppxlib they can add an
opam-overlay which also contains patches to a few existing ppxes:
┌────
│ $ opam repo add git+https://github.com/patricoferris/opam-ppxlib-repository.git
└────
• Nathan has worked on *a better AST printer* inspired by the
`ppx_tools' printer and the existing printing functionality of
ppxlib. See [this PR] for more details. This should help better
*debug AST migration bugs*. It makes good use of the AST lift class.
• With breakages happening in `Ast_helper' and `Ast_builder' it became
unclear why `Ast_helper' exists at all. There's a move to *deprecate
`Ast_helper' and promote the use of `Ast_builder' instead*. This
should help reduce maintenance costs and API breakages.
• We need to *consolidate our documentation better*. There should be a
focus on moving as much documentation to the `mld' and `mli' files
as possible.
Happy ppxing :camel: !
[meeting notes are available online]
<https://github.com/ocaml-ppx/ppxlib/wiki/dev-meeting-2024-08-20>
[this PR] <https://github.com/ocaml-ppx/ppxlib/pull/517>
First release of corosync
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-corosync/15199/1>
Vincnet Liu announced
─────────────────────
Aug 2024 - I am happy to announce the release of
<https://opam.ocaml.org/packages/corosync/>, a binding to
libcorosync. It is not (yet) a complete binding to all the APIs of
libcorosync, but the bindings to the following libraries are
implemented:
1. libcmap (in memory stats and config database)
2. libquorum and libvotequorum (query of quorum states)
3. libcfg (config reload, etc)
4. libcpg (closed process group, corosync's model of a cluster)
This project lives on <https://github.com/Vincent-lau/ocaml-corosync>,
and feel free to contact me if you have any questions!
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [MirageVPN and OpenVPN]
• [How TSan Makes OCaml Better: Data Races Caught and Fixed]
[the ocaml.org blog] <https://ocaml.org/blog/>
[MirageVPN and OpenVPN]
<https://blog.robur.coop/articles/2024-08-21-OpenVPN-and-MirageVPN.html>
[How TSan Makes OCaml Better: Data Races Caught and Fixed]
<https://tarides.com/blog/2024-08-21-how-tsan-makes-ocaml-better-data-races-caught-and-fixed>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 21646 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-08-20 9:29 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-08-20 9:29 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 15128 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 13 to 20,
2024.
Table of Contents
─────────────────
MlFront - A Java-like package system for OCaml
Rpmfile library v0.3.0 with new Eio-based reader
GitHub - meta-introspector/ocaml-libppx-import-yojson-introspector: Using libppx, ppx_import, reflect over ast using
Dune Developer Preview Updates
Ppxlib dev meetings
Pragmatic Category Theory: Part 2 published!
Dune dev meeting on 2024-08-21, 10am CEST
Other OCaml News
Old CWN
MlFront - A Java-like package system for OCaml
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mlfront-a-java-like-package-system-for-ocaml/15072/8>
jbeckford announced
───────────────────
There is now a new library `MlFront_Top' with a build tool
`mlfront-top' that will generate self-contained OCaml toplevel script
files with parallelism based on @c-cube's moonpool library:
┌────
│ .
│ ├── AcmeWidgets_Std/
│ │ ├── JobsA1.ml
│ │ └── JobsA2.ml
│ └── BobBuilder_Std/
│ └── JobsB.ml
└────
┌────
│ $ mlfront-top -o buildscript.ml
│
│ $ ocaml buildscript.ml -j 2 -native
│ legend: -> start | <- finish
│ directory create: target/
│ file create: target/AcmeWidgets_Std.ml
│ link create: AcmeWidgets_Std/JobsA1.ml -> target/AcmeWidgets_Std__JobsA1.ml
│ link create: AcmeWidgets_Std/JobsA2.ml -> target/AcmeWidgets_Std__JobsA2.ml
│ link create: BobBuilder_Std/JobsB.ml -> target/BobBuilder_Std__JobsB.ml
│ -> compile: AcmeWidgets_Std.JobsA1
│ -> compile: AcmeWidgets_Std.JobsA2
│ <- compile: AcmeWidgets_Std.JobsA1
│ <- compile: AcmeWidgets_Std.JobsA2
│ -> compile: AcmeWidgets_Std
│ <- compile: AcmeWidgets_Std
│ -> compile: BobBuilder_Std.JobsB
│ <- compile: BobBuilder_Std.JobsB
│ -> executable create: BobBuilder_Std.JobsB
│ <- executable create: BobBuilder_Std.JobsB
│ done.
│
│ $ target/BobBuilder_Std.JobsB
│ I am an A1!
│ I am an A2!
│ I am a B!
└────
It requires the `ocaml' binary and `ocamlc' or `ocamlopt'. The
complete example is at
<https://gitlab.com/dkml/build-tools/MlFront/-/blob/0.4.0-6/tests/MlFront_Top/jobs.t/run.t>.
Rpmfile library v0.3.0 with new Eio-based reader
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rpmfile-library-v0-3-0-with-new-eio-based-reader/15149/1>
Mikhail announced
─────────────────
Today I want to tell you about new version of [Rpmfile
library]. Rpmfile is a library for reading metadata from [RPM]
packages. Originally Rpmfile's parser (reader) used [Angstrom] for
parsing. And in the new release added new modern [Eio]-based reader.
Globally, the project is now split into four packages: `rpmfile',
which contains signatures and implementation-independent functions,
`rpmfile-unix' with the original Angstrom parser, and `rpmfile-eio'
(with `rpmfile-cli') written using Eio.
[Rpmfile library] <https://github.com/dx3mod/rpmfile>
[RPM] <https://en.wikipedia.org/wiki/RPM_Package_Manager>
[Angstrom] <https://github.com/inhabitedtype/angstrom>
[Eio] <https://github.com/ocaml-multicore/eio>
My experience porting to Eio
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Eio is a fantastic effect-based I/O library for a more modern age in
multicore OCaml. I think it takes the best ideas from the
ecosystem. So built-in `Buf_read' and `Buf_write' modules implement
ideas from Angstrom and Faraday libraries. Almost API one-to-one,
allowing porting via copy-paste.
But, of course, not everything is so perfect. Unlike the
`Angstrom.parse_' function, the `Buf_read.parse' function thinks I
want to read a whole stream to end of input.
A snippet of the source code:
┌────
│ let parse ?initial_size ~max_size p flow =
│ let buf = of_flow flow ?initial_size ~max_size in
│ format_errors (p <* end_of_input) buf
│ (* ^^^^^^^^^^^^^^^
│ 0_0 nice (not) *)
└────
So I had to rewrite this function myself in a form similar to
`Angstrom.Consume.Prefix'.
◊ Is it a signed or unsigned integer?
`BE.uint16' and other similar functions are *signed int* even though
they have the prefix `u' in the name for some reason.
◊ And a few other differences
• `Angstrom.advance' is `skip'
• `Angstrom.pos' is `consumed_bytes'
P.S.
╌╌╌╌
Thanks for your attention!
GitHub - meta-introspector/ocaml-libppx-import-yojson-introspector: Using libppx, ppx_import, reflect over ast using
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/github-meta-introspector-ocaml-libppx-import-yojson-introspector-using-libppx-ppx-import-reflect-over-ast-using/15151/1>
Jim Dupont announced
────────────────────
Here is a working first version (with warts) of a ppxlib to yojson
converter, am still testing it but the hello world is working, I have
tried multiple times to get this to work, and finally settled on the
import route to override the type system. code here:
<https://github.com/meta-introspector/ocaml-libppx-import-yojson-introspector>
example snippet
┌────
│ {
│ "pexp_desc": [
│ "Pexp_constant",
│ [
│ "Pconst_string",
│ "Hello, World!"
│ ]
│ ]
│ }
└────
Dune Developer Preview Updates
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dune-developer-preview-updates/15160/1>
ostera announced
────────────────
Just wanted to share some of the work the Dune has been up to lately
re: the Developer Preview we announced [here] :) – we'll be using this
thread to share more updates as things go.
As always, we hold our Dune Developer meetings in public and you're
more than welcome to subscribe to our public Calendar ([Google],
[iCal])
[here]
<https://discuss.ocaml.org/t/ocaml-platform-newsletter-march-may-2024/14765>
[Google]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com&ctz=Europe%2FStockholm>
[iCal]
<https://calendar.google.com/calendar/ical/c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com/public/basic.ics>
Getting ready for the Public Beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
As we prepare for the public beta, we're ramping up the DX interviews
and ensuring the first few users will have a fun, productive
experience with the developer preview.
:inbox_tray: If you signed up for the Dev Preview back in
May, check your inbox for a link and instructions to
schedule your DX interview with us.
Here's a sample video ([Mastodon] or [X]) where you can see me
building the Riot project on a machine that does not have OCaml
installed. It is pretty neat!
Seriously, big shoutout to the Dune team at Tarides[0] who have been
doing a phenomenal job :clap: :sparkles: :camel:
So here's what getting started with OCaml looks like today with the
Dune Developer Preview as of today (August 19 2024):
1. get `dune' from our binary distribution – we'll soon make this
public!
2. run `dune pkg lock' in your favorite project
3. run `dune build'
That's it. No need to install anything else, Dune will see that lock
file, fetch, and build all necessary dependencies.
:world_map: These are some strong step towards the [OCaml
Platform vision for 2026], that we are actively working
towards. If you have any thoughts or feedback please let
me know!
There are more improvements coming that will help remove friction to
get started and creating a delightful experience. Both of these things
we strongly believe will help onboard new users to the OCaml world.
Here's a few in the works:
• *Various DX improvements* – from new outputs to simplified
workflows, we want to make using Dune just delightful.
• *Bundled support for dev tools* (ocalmformat, odoc, lsp) – the
default toolset will be available without any extra steps! just
call `dune fmt', and it works. No need to manually install anything
else.
• *Automatic dependency locking* – when building, and even on watch
mode, Dune will lock your dependencies by default and keep the lock
up to date.
• *Cross-project Caching* – by default we'll enabled a local Dune
cache that across the system, so you never rebuild the same
dependency even across projects.
• *Signed binaries with certificates of origin* – we care deeply about
security and want to make sure that any binary we ship will be
easily verified and tracked back to its sources.
Stay tuned! :wave:
PS: here's a longer video ([Mastodon], [X]) showing you the setup for
OCaml from zero, creating a new project, and adding a dependency, all
within ~5 minutes
[0] @emillon @Leonidas @gridbugs @tmattio. Ambre Shumay, Alpha Diallo,
Etienne Marais
[Mastodon] <https://mas.to/deck/@leostera/112988841207690720>
[X] <https://x.com/leostera/status/1825519465527673238>
[OCaml Platform vision for 2026]
<https://ocaml.org/tools/platform-roadmap>
[Mastodon] <https://mas.to/deck/@leostera/112988880290815356>
[X] <https://x.com/leostera/status/1825519469759812062>
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/29>
Nathan Rebours announced
────────────────────────
This month's meeting is scheduled for tomorrow, [date=2024-08-20
time=17:00:00 timezone="Europe/London"]!
The meeting agenda thus far is to discuss the following:
• *5.2 Bump Progess*
• Auto-generate AST pattern code and labelled arguments
(e.g. `value_binding ~constraint_:none' but no positional
argument?)
• `Ast_helper.Exp.function_' deprecation
• [opam-repository overlay for 5.2 AST bump]
• *Issues in migrations*
• Bumping the AST has uncovered issues in migrating code up and down
the internal ppxlib ASTs – would be good to discuss this and also
how to mitigate this going forward.
• *Documentation*
• Great user feedback from [Ppxlib: Getting the original definition
of `typ_constr' like `type_declaration' from `core_type' of
`ptyp_constr'] which we should take onboard and work into
<https://github.com/ocaml-ppx/ppxlib/issues/324>
• *Some carry over items from last month*
• In general what is the medium term goals for ppxlib? Mostly
maintenance and bumping the AST/keeping up with compiler releases?
The meeting will be hosted on google meet here:
<https://meet.google.com/yxw-ejnu-cju>
Everyone is very welcome to join! :camel:
[opam-repository overlay for 5.2 AST bump]
<https://github.com/patricoferris/opam-ppxlib-repository>
[Ppxlib: Getting the original definition of `typ_constr' like
`type_declaration' from `core_type' of `ptyp_constr']
<https://discuss.ocaml.org/t/ppxlib-getting-the-original-definition-of-typ-constr-like-type-declaration-from-core-type-of-ptyp-constr/15110>
Pragmatic Category Theory: Part 2 published!
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/new-part-pragmatic-category-theory-part-2-published/15056/6>
Dmitrii Kovanikov announced
───────────────────────────
I just published [the second part] of my series, so I updated the
topic.
Let me know when notifications become too noisy :slight_smile:
[the second part]
<https://dev.to/chshersh/pragmatic-category-theory-part-2-composing-semigroups-87>
Dune dev meeting on 2024-08-21, 10am CEST
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dune-dev-meeting-on-2024-08-21-10am-cest/15166/1>
Steve Sherratt announced
────────────────────────
Hi! The next public dune dev meeting will be held on 2024-08-21, 10am
CEST. Please feel free to let me know any topics you'd like us to
discuss and I'll update [the meeting notes]. The zoom link for the
meeting is:
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[the meeting notes]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-08-21>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The new Tar release, a retrospective]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The new Tar release, a retrospective]
<https://blog.robur.coop/articles/tar-release.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 27121 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-08-13 13:21 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-08-13 13:21 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 5033 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 06 to 13,
2024.
Table of Contents
─────────────────
MlFront - A Java-like package system for OCaml
First release of hector
Dune dev meeting
Other OCaml News
Old CWN
MlFront - A Java-like package system for OCaml
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mlfront-a-java-like-package-system-for-ocaml/15072/4>
Continuing this thread, jbeckford announced
───────────────────────────────────────────
I've added a third post: [https://diskuv.com/mlfront/overview-3/]
In it I describe a small but useful /reference build system/ for
MlFront which can take packages like:
┌────
│ .
│ ├── AcmeWidgets_Std/
│ │ └── A.ml
│ └── BobBuilder_Std/
│ └── B.ml
└────
and produce standalone build scripts that can be committed to source
control:
┌────
│ $ mlfront-boot -native -o buildscript
│
│ $ ./buildscript.sh # .\buildscript.cmd is also created
│
│ $ target/BobBuilder_Std.B
│ I am an A!
│ I am a B!
└────
On a related note, I've begun to implement a small part of
<https://gallium.inria.fr/~scherer/namespaces/spec.pdf>. It is not
strictly required but [Namespaces.mli] will be very helpful for
upgrading existing projects to `MlFront'-style packages without
changing code. That will be for a future (not soon) post.
[https://diskuv.com/mlfront/overview-3/]
<https://diskuv.com/mlfront/overview-3/>
[Namespaces.mli]
<https://gitlab.com/dkml/build-tools/MlFront/-/blob/f1f6e6d073500febb5c9e429212c8bdaaa177c35/src/MlFront_Codept/Namespaces.mli>
First release of hector
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-hector/15099/1>
François Pottier announced
──────────────────────────
It is my pleasure to announce the first release of `hector', an OCaml
library that offers /vectors/ (also known as dynamic arrays, or
resizeable arrays).
To install it, type `opam update && opam install hector'.
`hector' offers *polymorphic vectors*, where the type of the elements
is a parameter, *monomorphic vectors*, where the type of the elements
is fixed, and *integer vectors*, a special case of monomorphic
vectors.
`hector''s vectors are *not thread-safe* and *do not include a
protection against memory leaks*. Compared with the `Dynarray' module
in OCaml's standard library, `hector''s polymorphic and monomorphic
vectors are *slightly faster*, and `hector''s integer vectors are
*significantly faster*. `hector' offers fast (but dangerous) *unsafe
access operations*, namely `unsafe_get', `unsafe_set', and
`unsafe_borrow'. For a more detailed overview, see the
[documentation].
[documentation] <https://cambium.inria.fr/~fpottier/hector/doc/hector/>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/9>
Continuing this thread, Marek Kubica announced
──────────────────────────────────────────────
Thanks for everyone who joined today! The [meeting minutes] are online
and the next meeting will be in two weeks, 21st of August at 10:00
(AM) CEST.
[meeting minutes]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-08-07>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The Guide to Software Verification with Frama-C is available]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The Guide to Software Verification with Frama-C is available]
<https://frama-c.comhttps//link.springer.com/book/10.1007/978-3-031-55608-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 14726 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-08-06 9:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-08-06 9:00 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 23865 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 30 to August
06, 2024.
Table of Contents
─────────────────
Ppxlib dev meetings
Pragmatic Category Theory
ppxlib.0.33.0
OCaml-LSP 1.19.0 for OCaml 5.2
MlFront - A packaging system for OCaml
OCaml.org Newsletter: July 2024
Other OCaml News
Old CWN
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/28>
Continuing this thread, Patrick Ferris announced
────────────────────────────────────────────────
Meeting notes are available here:
<https://github.com/ocaml-ppx/ppxlib/wiki/Dev-Meeting-2024-07-23>
Thank you to all of the participants. If anyone is interested in
adding items for the next meeting in August do ping me.
Until then happy ppx-ing :))
Pragmatic Category Theory
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/pragmatic-category-theory/15056/1>
Dmitrii Kovanikov announced
───────────────────────────
I started writing a series on *Pragmatic Category Theory for
Beginners* focusing on real-world use cases rather than theory. All
code examples are in OCaml.
The first part was just finished:
• [Part 1: Semigroup Intro]
It's just the beginning, and I have plans to describe more and provide
more examples in future parts. I also plan to make a video version as
well.
I hope you'll enjoy it!
[Part 1: Semigroup Intro]
<https://dev.to/chshersh/pragmatic-category-theory-part-1-semigroup-intro-1ign>
ppxlib.0.33.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-ppxlib-0-33-0/15061/1>
Nathan Rebours announced
────────────────────────
The Ppxlib dev team is happy to announce the release of
`ppxlib.0.33.0'.
You can find the full changelog for this release [here].
[here] <https://github.com/ocaml-ppx/ppxlib/releases/tag/0.33.0>
Warning silencing for `[@@deriving ..]' generated code
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release's main feature is a series of improvement to flags
controlling unused value/module/type warnings silencing.
The `ppxlib' driver generates warning silencing items to prevent
`[@@deriving ...]' generated code to trigger unused code
warnings. Three warnings are disabled that way:
• Warning 32: unused value
• Warning 60: unused module
• Warning 34: unused type
The first two are disabled for values and modules generated by the
deriver while the third is disabled for the types in the type
declaration to which the `[@@deriving ...]' attribute is attached.
This feature was added a long time ago to avoid manually disabling
those warnings when working with derivers that generate a set of
values and modules only to use a subset of those. Alternatively, the
unused type warning silencing was added to allow defining an alias
type only to be consumed by a deriver, e.g.:
┌────
│ type error = [`Not_found | `Invalid_arg] [@@deriving to_string]
└────
We since then believe that we should not disable warnings lightly, as
this behaviour makes it difficult to find and remove dead code. The
right approach in those situations should be to fix the PPX derivers
so that they are more configurable and can be used without triggering
such warnings.
We will start to move toward removing this feature, but since it is
still useful in some places, we had to come up with a plan to allow
transitioning out of it.
In `ppxlib.0.31.0' we added the `-unused-code-warnings' driver flag
and the `?unused_code_warnings''s `Deriving.V2.make' optional argument
to control whether to silence Warnings 32 and 60. When both are set to
`true', by the user and the deriver authors, the warnings are not
silenced.
As of `ppxlib.0.33.0', these also control the silencing of Warning 34
(unused type). `force' can now be passed to the
`-unused-code-warnings' flag in order to disable warnings silencing,
regardless of the derivers opting in.
This allows users to test whether their codebase and their set of
derivers rely on warning silencing or not and to use those results to
eliminate dead code and/or report issues upstream to the derivers they
use.
We also added a separate `-unused-type-warnings' flag that works
similarly to `-unused-code-warnings' (i.e., depends on the value of
the `?unused_code_warnings' argument), but it only controls Warning 34
silencing, as it turns out it is less likely to cause unwanted
warnings than with the other two. This will allow users to disable it
more easily, without having to deal with Warnings 32 and 60 straight
away.
We want to encourage users to try those on their codebase in order to
see the impact it has. Did you have dead code lying around that
slipped past undetected? Does this trigger unwanted warnings because
of deriver's generated code?
The plan is to give the ecosystem some time to try those features and
adapt by fixing individual derivers and flipping
`?unused_code_warnings' to true as they do. After a while, we will
swap the default value of the driver flag to `true' so that only
derivers that haven't opted in will enable warning silencing. Then as
time goes we will swap the default of the `Deriving.make' argument so
that derivers will instead have to explicitly opt out to get the
warning silencing. Finally, once we are confident the ecosystem is in
a good enough state, we will remove this feature altogether.
Other features
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`ppxlib.0.33.0' also comes with a couple of new features for PPX
authors:
• A couple new `Ast_builder' functions: `elist_tail' and `plist_tail'
that can be used to build list expressions and patterns with a
custom tail: `elist_tail [expr1; expr2] tail_expr' returns the
expression for `expr1::expr2::tail_expr'.
• `Context_free.special_function'', a new version of
`special_function' that allows passing a `Longident.t' directly
rather that relying on parsing the string argument to a
`Longident.t'.
Finally, the release includes a few bug fixes to `Longident.parse' and
`Code_path.main_module_name' and fixes the `location-check' flag so it
is not required to also pass `-check' to enable location checks. It
also fixes the 5.2 migrations locations, as we used to build nodes
with inconsistent locations when migrating `Pexp_function' nodes.
Huge thanks to our external contributors
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We would like to thank our external contributors who have been a huge
part of this release: @octachron, @vg-b, and @jchavarri, and a special
mention to @mbarbin, who has not only contributed a lot to the warning
silencing features but has been extensively testing and providing very
useful feedback on them.
And of course, as usual, we'd like to thank the OCaml Software
Foundation who has been funding my work on Ppxlib and on this release,
making all of this possible!
OCaml-LSP 1.19.0 for OCaml 5.2
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-lsp-1-19-0-for-ocaml-5-2/15071/1>
vds announced
─────────────
I am happy to announce, on behalf of the ocaml-lsp team, the release
of `ocaml-lsp-server' `1.19.0' and associated libraries. This release
primary goal is to bring official support for OCaml 5.2 🐫.
Features
╌╌╌╌╌╌╌╌
• Add custom
[~ocamllsp/getDocumentation~](/ocaml-lsp-server/docs/ocamllsp/getDocumentation-spec.md)
request (ocaml/ocaml-lsp#1336)
• Add support for OCaml 5.2 (ocaml/ocaml-lsp#1233)
Fixes
╌╌╌╌╌
• Kill unnecessary ocamlformat processes with sigterm rather than
sigint or sigkill (ocaml/ocaml-lsp#1343)
MlFront - A packaging system for OCaml
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mlfront-a-packaging-system-for-ocaml/15072/1>
jbeckford announced
───────────────────
Here are the introductory paragraphs from its overview:
`MlFront' adds a Java-like packaging system to OCaml. The
`MlFront' name is a homage to `cfront' which was tooling
that translated "C with Classes" (now known as C++) into C
code. Similarly, `MlFront'-based tools can translate OCaml
with packages into conventional OCaml. … At its most
basic core, `MlFront' gives a well-defined, consistent
meaning to a module reference like
`AcmeWidgets_Std.Activities.Manufacturing' across the
domains of:
1. OCaml source code.
2. findlib libraries.
3. opam packages.
`MlFront' is Apache 2.0 licensed and is meant to be used by build
systems (Dune, ocamlbuild, DkCoder) and package managers (opam). One
of its critical dependencies is [codept].
You can read more about `MlFront' in the following posts (with more
coming):
• [https://diskuv.com/mlfront/overview-1/]
• [https://diskuv.com/mlfront/overview-2/]
/Cross-post notice: The first article was posted at
[https://lobste.rs/s/7ghslo/overview_ocamlfront]; no comments
(:(). But I still like to get first-hand feedback on what works well
in other languages, so please chime in even if you don't feel that
OCaml is your strong suit./
[codept] <https://github.com/Octachron/codept>
[https://diskuv.com/mlfront/overview-1/]
<https://diskuv.com/mlfront/overview-1/>
[https://diskuv.com/mlfront/overview-2/]
<https://diskuv.com/mlfront/overview-2/>
[https://lobste.rs/s/7ghslo/overview_ocamlfront]
<https://lobste.rs/s/7ghslo/overview_ocamlfront>
OCaml.org Newsletter: July 2024
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-org-newsletter-july-2024/15087/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the July 2024 edition of the OCaml.org newsletter! This
update has been compiled by the OCaml.org maintainers. You can find
[previous updates] on Discuss.
Our goal is to make OCaml.org the best resource for anyone who wants
to get started and be productive in OCaml. The OCaml.org newsletter
provides an update on our progress towards that goal and an overview
of the changes we are working on.
We couldn't do it without all the amazing people who help us review,
revise, and create better OCaml documentation and work on issues. Your
participation enables us to so much more than we could just by
ourselves. Thank you!
This newsletter covers:
• *Community-Driven Development of OCaml.org*
• *Recipes for the OCaml Cookbook:* Help us make the OCaml Cookbook
really useful by contributing and reviewing recipes for common
tasks!
• *Community & Marketing Pages Rework:* Implementation work in
progress.
• *General Improvements:* As usual, we also worked on general
maintenance and improvements, so we're highlighting some of the
work that happened below.
[previous updates] <https://discuss.ocaml.org/tag/ocamlorg-newsletter>
Community-Driven Development of OCaml.org
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
After reworking most of the OCaml.org website to be more useful, more
usable, and nicer to look at, the team at Tarides that has been
working on OCaml.org is disbanding. However, OCaml.org will continue
to be maintained and extended by by the OCaml Platform and OCaml
compiler contributors, as well as by the wider OCaml community.
You can reach out to [the OCaml.org maintainers] to discuss any bigger
changes or additions you'd like to make. Contributions to improve
existing features and bug fixes are always welcome!
[the OCaml.org maintainers]
<https://github.com/ocaml/ocaml.org?tab=readme-ov-file#maintainers>
◊ Open Issues for Contributors
You can find [open issues for contributors here]!
[open issues for contributors here]
<https://github.com/ocaml/ocaml.org/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+no%3Aassignee>
Recipes for the OCaml Cookbook
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The OCaml Cookbook is a place where OCaml developers share how to
solve common tasks using packages from the ecosystem.
A recipe is a code sample and explanations on how to perform a task
using a combination of open-source libraries.
The Cookbook is live at [ocaml.org/cookbook].
Here's how you can help:
1. Help review the [open pull requests for cookbook recipes]!
2. Contribute new recipes and tasks for the cookbook!
Thank you all for the many contributions! One area where we could use
help is in reviewing and improving the suggested recipes and tasks.
*Relevant PRs and Activities:*
• (open) PR: cookbook recipes for parse-command-line-arguments
[ocaml/ocaml.org#2573] by [@richardhuxton]
• (open) PR: Cookbook Check a Webpage for Broken Links
[ocaml/ocaml.org#2581] by [@ggsmith842]
• (open) PR: cookbook: "create and await promises": Lwt, Async
[ocaml/ocaml.org#2584] by [@richardhuxton]
• (open) PR: CookBook: read-csv - basic example of reading records
from a CSV string [ocaml/ocaml.org#2589] by [@danielclarke]
• (open) PR: Cookbook: Email regex patch [ocaml/ocaml.org#2591] by
[@F-Loyer]
• Fixes and Improvements to existing recipes:
• PR: Update 00-uri.ml: missing arg [ocaml/ocaml.org#2618] by
[@ttamttam]
[ocaml.org/cookbook] <https://ocaml.org/cookbook>
[open pull requests for cookbook recipes]
<https://github.com/ocaml/ocaml.org/pulls?q=is%3Apr+is%3Aopen+label%3ACookbook>
[ocaml/ocaml.org#2573] <https://github.com/ocaml/ocaml.org/pull/2573>
[@richardhuxton] <https://github.com/richardhuxton>
[ocaml/ocaml.org#2581] <https://github.com/ocaml/ocaml.org/pull/2581>
[@ggsmith842] <https://github.com/ggsmith842>
[ocaml/ocaml.org#2584] <https://github.com/ocaml/ocaml.org/pull/2584>
[ocaml/ocaml.org#2589] <https://github.com/ocaml/ocaml.org/pull/2589>
[@danielclarke] <https://github.com/danielclarke>
[ocaml/ocaml.org#2591] <https://github.com/ocaml/ocaml.org/pull/2591>
[@F-Loyer] <https://github.com/F-Loyer>
[ocaml/ocaml.org#2618] <https://github.com/ocaml/ocaml.org/pull/2618>
[@ttamttam] <https://github.com/ttamttam>
Community & Marketing Pages Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We have [UI designs for the reworked and new pages of the community
section], and implementation is being worked on by [@oyenuga17], our
former Outreachy intern!
*Relevant PRs and Activities:*
• PR: Implement new community overview page [ocaml/ocaml.org#2605] by
[@oyenuga17]
• PR: Fix typo and case inconsistencies on community page
[ocaml/ocaml.org#2616] by [@pjlast]
• PR: Redesign OCaml Planet Page [ocaml/ocaml.org#2617] by
[@oyenuga17]
[UI designs for the reworked and new pages of the community section]
<https://www.figma.com/file/7hmoWkQP9PgLTfZCqiZMWa/OCaml-Community-Pages?type=design&node-id=637%3A4539&mode=design&t=RpQlGvOpeg1a93AZ-1>
[@oyenuga17] <https://github.com/oyenuga17>
[ocaml/ocaml.org#2605] <https://github.com/ocaml/ocaml.org/pull/2605>
[ocaml/ocaml.org#2616] <https://github.com/ocaml/ocaml.org/pull/2616>
[@pjlast] <https://github.com/pjlast>
[ocaml/ocaml.org#2617] <https://github.com/ocaml/ocaml.org/pull/2617>
General Improvements and Data Additions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Summary:*
• The selected OS is now part of the anchor tag of the URL on the
<https://ocaml.org/install> page. This allows people to link to
quick install instructions for a specific OS.
• We appreciate the contributions to the OCaml documentation!
• We're checking for backlinks to OCaml.org again with Ahrefs.
*Relevant PRs and Activities:*
• (open) PR: Build on OCaml 5 (ocamlnet -safe-string workaround)
[ocaml/ocaml.org#2609] by [@aantron]
• PR: Ahref tag [ocaml/ocaml.org#2571] by [@cuihtlauac]
• PR: Issue #2583: Added OS Anchor Tags to ocaml.org/install
[ocaml/ocaml.org#2600] by [@SisyphianLiger]
• PR: Performance: cache search index digest until ocaml-docs-ci
computes it [ocaml/ocaml.org#2620] by [@sabine]
• Documentation
• PR: Unwrapped libraries [ocaml/ocaml.org#2562] by [@cuihtlauac]
• PR: Explain folders bin, lib and _build [ocaml/ocaml.org#2568] by
[@cuihtlauac]
• PR: Use `layout opam' in `.envrc' in opam path doc
[ocaml/ocaml.org#2597] by [@smorimoto]
• PR: Use sudo in install tutorial [ocaml/ocaml.org#2558] by
[@cuihtlauac]
• PR: Add documentation about comments to Tour of Ocaml
[ocaml/ocaml.org#2613] by [@NoahTheDuke]
• PR: Fix Example referencing Type not yet Defined
[ocaml/ocaml.org#2606] by [@avlec]
• Refactor + Code health:
• PR: Open Data_intf in data.mli [ocaml/ocaml.org#2563] by
[@cuihtlauac]
• PR: Make data error file path copy-paste ready
[ocaml/ocaml.org#2567] by [@cuihtlauac]
• PR: Test ocaml/setup-ocaml v3 [ocaml/ocaml.org#2570] by
[@cuihtlauac]
• PR: Update ocaml/setup-ocaml to v3 [ocaml/ocaml.org#2565] by
[@smorimoto]
• PR: Refactoring parts from PR #2443 [ocaml/ocaml.org#2576] by
[@cuihtlauac]
• PR: Bump peter-evans/create-pull-request from 5 to 6
[ocaml/ocaml.org#2588] by [@dependabot]
• PR: Set OCaml to 4.14.2 [ocaml/ocaml.org#2587] by [@cuihtlauac]
• PR: fix: write directory instead of folder [ocaml/ocaml.org#2572]
by [@ashish0kumar]
• PR: sync debug-ci and ci [ocaml/ocaml.org#2582] by [@cuihtlauac]
• Data
• PR: changelog: dune 3.16.0 [ocaml/ocaml.org#2566] by [@emillon]
• PR: (data) add OCaml.org newsletter June 2024
[ocaml/ocaml.org#2575] by [@sabine]
• PR: Add changelog for the latest merlin releases
[ocaml/ocaml.org#2580] by [@voodoos]
• PR: Add changelog for the latest ocaml-lsp release
[ocaml/ocaml.org#2593] by [@PizieDust]
• PR: Add missing changelog for opam 2.2.0 [ocaml/ocaml.org#2598] by
[@kit-ty-kate]
• PR: Add changelog entry for ppxlib.0.33.0 release
[ocaml/ocaml.org#2615] by [@NathanReb]
[ocaml/ocaml.org#2609] <https://github.com/ocaml/ocaml.org/pull/2609>
[@aantron] <https://github.com/aantron>
[ocaml/ocaml.org#2571] <https://github.com/ocaml/ocaml.org/pull/2571>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2600] <https://github.com/ocaml/ocaml.org/pull/2600>
[@SisyphianLiger] <https://github.com/SisyphianLiger>
[ocaml/ocaml.org#2620] <https://github.com/ocaml/ocaml.org/pull/2620>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2562] <https://github.com/ocaml/ocaml.org/pull/2562>
[ocaml/ocaml.org#2568] <https://github.com/ocaml/ocaml.org/pull/2568>
[ocaml/ocaml.org#2597] <https://github.com/ocaml/ocaml.org/pull/2597>
[@smorimoto] <https://github.com/smorimoto>
[ocaml/ocaml.org#2558] <https://github.com/ocaml/ocaml.org/pull/2558>
[ocaml/ocaml.org#2613] <https://github.com/ocaml/ocaml.org/pull/2613>
[@NoahTheDuke] <https://github.com/NoahTheDuke>
[ocaml/ocaml.org#2606] <https://github.com/ocaml/ocaml.org/pull/2606>
[@avlec] <https://github.com/avlec>
[ocaml/ocaml.org#2563] <https://github.com/ocaml/ocaml.org/pull/2563>
[ocaml/ocaml.org#2567] <https://github.com/ocaml/ocaml.org/pull/2567>
[ocaml/ocaml.org#2570] <https://github.com/ocaml/ocaml.org/pull/2570>
[ocaml/ocaml.org#2565] <https://github.com/ocaml/ocaml.org/pull/2565>
[ocaml/ocaml.org#2576] <https://github.com/ocaml/ocaml.org/pull/2576>
[ocaml/ocaml.org#2588] <https://github.com/ocaml/ocaml.org/pull/2588>
[@dependabot] <https://github.com/dependabot>
[ocaml/ocaml.org#2587] <https://github.com/ocaml/ocaml.org/pull/2587>
[ocaml/ocaml.org#2572] <https://github.com/ocaml/ocaml.org/pull/2572>
[@ashish0kumar] <https://github.com/ashish0kumar>
[ocaml/ocaml.org#2582] <https://github.com/ocaml/ocaml.org/pull/2582>
[ocaml/ocaml.org#2566] <https://github.com/ocaml/ocaml.org/pull/2566>
[@emillon] <https://github.com/emillon>
[ocaml/ocaml.org#2575] <https://github.com/ocaml/ocaml.org/pull/2575>
[ocaml/ocaml.org#2580] <https://github.com/ocaml/ocaml.org/pull/2580>
[@voodoos] <https://github.com/voodoos>
[ocaml/ocaml.org#2593] <https://github.com/ocaml/ocaml.org/pull/2593>
[@PizieDust] <https://github.com/PizieDust>
[ocaml/ocaml.org#2598] <https://github.com/ocaml/ocaml.org/pull/2598>
[@kit-ty-kate] <https://github.com/kit-ty-kate>
[ocaml/ocaml.org#2615] <https://github.com/ocaml/ocaml.org/pull/2615>
[@NathanReb] <https://github.com/NathanReb>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The slides presented at Frama-C Days 2024 are available]
• [Monoculture of Insecurity: How CrowdStrike's Outage Exposes the
Risks of Unchecked Complexity in Cybersecurity]
• [Upcoming OCaml Events (Aug 2024 and onwards)]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The slides presented at Frama-C Days 2024 are available]
<https://frama-c.com/html/publications/frama-c-days-2024/index.html>
[Monoculture of Insecurity: How CrowdStrike's Outage Exposes the Risks
of Unchecked Complexity in Cybersecurity]
<https://tarides.com/blog/2024-08-01-monoculture-of-insecurity-how-crowdstrike-s-outage-exposes-the-risks-of-unchecked-complexity-in-cybersecurity>
[Upcoming OCaml Events (Aug 2024 and onwards)]
<https://ocaml.org/events>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35591 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-07-30 13:26 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-07-30 13:26 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 9970 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 23 to 30,
2024.
Table of Contents
─────────────────
.mlx syntax dialect
heml, a HEEx-inspired HTML templating ppx for OCaml
Forester 4.2
First Robotics and OCaml - Do you know any local teams?
2nd editor tooling dev-meeting: 25th of July 🧙
Other OCaml News
Old CWN
.mlx syntax dialect
═══════════════════
Archive: <https://discuss.ocaml.org/t/ann-mlx-syntax-dialect/15035/1>
Andrey Popp announced
─────────────────────
Dear OCaml community,
it is my pleasure to announce a release of [.mlx] dialect.
The .mlx dialect extends OCaml syntax with JSX expression construct,
following the example of JSX in JavaScript/ReasonML. A brief snippet:
┌────
│ let page ?(encoding="utf8") ~title ~content =
│ <html>
│ <head>
│ <meta charset=encoding />
│ <title>title</title>
│ </head>
│ <body>
│ content
│ </body>
│ </html>
│
│ let _ = <page title="Hello" content="World" />
└────
The main use case is to make it easier to describe user interfaces
with OCaml, which can range from generating HTML ([example with
Dream]) or describing interactive UIs with ReasonReact ([example]).
[.mlx] <https://github.com/ocaml-mlx/mlx>
[example with Dream]
<https://github.com/aantron/dream/blob/dc805cb46fd99001bc828cddb9de053a3dc464eb/example/w-mlx/README.md>
[example]
<https://github.com/andreypopp/melange-mlx-template/blob/main/src/ReactApp.mlx>
Installation and usage
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Install the packages from opam:
┌────
│ opam install mlx ocamlmerlin-mlx
└────
Then configure dune to use the `mlx' preprocessor:
┌────
│ (dialect
│ (name mlx)
│ (implementation
│ (extension mlx)
│ (merlin_reader mlx)
│ (preprocess
│ (run mlx-pp %{input-file}))))
└────
Now files with `.mlx' extension will be treated as OCaml modules.
The merlin/ocamllsp users will get roughly the same level of support
for `.mlx' syntax as they get for `.ml' but some additional text
editor/IDE configuration is needed to associate `.mlx' files with
merlin/ocamllsp.
For neovim users there's a plugin [ocaml-mlx/ocaml_mlx.nvim], which
does that bit of a configuration and provides highlighting for `.mlx'
files based on a tree-sitter parser.
[ocaml-mlx/ocaml_mlx.nvim] <https://github.com/ocaml-mlx/ocaml_mlx.nvim>
heml, a HEEx-inspired HTML templating ppx for OCaml
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-heml-a-heex-inspired-html-templating-ppx-for-ocaml/15037/1>
Petri-Johan Last announced
──────────────────────────
I've been working on [heml], a PPX extension that allows you to build
complex HTML templates directly in your OCaml code.
It's a direct implementation of Elixir Phoenix's HEEx templates.
The README on GitHub has an example video of what it looks like in the
editor and a bunch of example code, but here's a short snippet for
convenience:
┌────
│ (* layouts.ml *)
│ let layout ~title contents = {%heml|<!DOCTYPE html>
│ <html lang="en">
│ <head><title><%s= title %></title></head>
│ <body>
│ <%raw= contents %>
│ </body>
│ </html>|}
│
│ (* main.ml *)
│ let heading ~text = {%heml|<h1><%s= text %></h1>|}
│
│ let greet ~user = {%heml|<p>Hello, <%s= user %></p>|}
│
│ let () =
│ let title = "Hello, OCaml!" in
│ print_endline {%heml|<Layouts.layout title={title}>
│ <.heading text="Hello!" />
│
│ <%= List.iter (fun user -> %>
│ <.greet user={user} />
│ <%= ) ["Steve"; "Becca"; "John"]; %>
│
│ </Layouts.layout>|}
└────
heml differs from other templating solutions by allowing you to call
OCaml code directly in the template, which is extremely useful for
looping and conditional rendering. You can also create and call your
own components/layouts.
heml leverages the OCaml LSP for accurate in-line errors, and the
templates are parsed and compiled into a series of Buffer writes which
returns a string at runtime.
I'm still waiting for it to be released on [opam], but thought I'd
share it in the meantime in case anyone would be willing to check it
out and provide feedback :slight_smile: .
[heml] <https://github.com/pjlast/heml>
[opam] <https://github.com/ocaml/opam-repository/pull/26297>
Forester 4.2
════════════
Archive: <https://discuss.ocaml.org/t/ann-forester-4-2/15043/1>
Jon Sterling announced
──────────────────────
I am pleased to announce the release of Forester 4.2 on opam, which is
an OCaml utility to develop “Forests”, which are densely interlinked
mathematical websites / Zettelkästen similar to the [Stacks project]
or [Kerodon]. You can see the [changelog] on my own [Forest].
This release adds many new features and improvements, including:
⁃ First-class functions and lazy arguments, which can be used to
implement more ergonomic MathML macros.
⁃ A new query language, which is now expressive enough to encode the
backmatter
⁃ Improved performance of graph analysis (2x overall speedup rendering
my own forest)
To see other features and documentation of breaking changes, please
view the [Forester 4.2 Release Notes].
My thanks to @kentookura and Jinser Kafka for their contributions to
this release.
[Stacks project] <https://stacks.math.columbia.edu>
[Kerodon] <https://kerodon.net>
[changelog] <https://www.jonmsterling.com/jms-00WK.xml>
[Forest] <https://www.jonmsterling.com>
[Forester 4.2 Release Notes] <http://www.jonmsterling.com/jms-00WK.xml>
First Robotics and OCaml - Do you know any local teams?
═══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-robotics-and-ocaml-do-you-know-any-local-teams/15051/1>
jbeckford announced
───────────────────
For those who don't know, First Robotics is a competitive,
international high school league for robotics:
<https://www.firstinspires.org/robotics/frc>.
I've helped a couple students write "scouting" software partially in
OCaml and partially in Java:
<https://github.com/diskuv/scoutapps/tree/main?tab=readme-ov-file#sonic-scout-apps>
It is a very /very/ slow season for robotics teams, but if your local
high school participates now is a great time for the mentors of that
team to get ready. If you know a team that needs scouting software and
want to help spread OCaml to your local neighborhoods … please direct
message me.
2nd editor tooling dev-meeting: 25th of July 🧙
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-2nd-editor-tooling-dev-meeting-25th-of-july/14953/4>
Continuing this thread, vds announced
─────────────────────────────────────
Thanks a lot to all participants and speakers, it was a very nice and
interesting meeting !
You can find the meeting notes here:
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
With the summer (/winter) break coming for a lot of us, the next
meeting will take place in September. We will implement a
call-for-presentation and a poll to choose meeting times by then.
Don't hesitate to tell us right away if you would like to give a
presentation or if you have subjects that you would like us to take
on. (@andreypopp would you be interested in talking about melange and
how it integrates with editor tooling ?)
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Introducing tree-sitter-dune]
• [Creating the SyntaxDocumentation Command - Part 3: VSCode Platform
Extension]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Introducing tree-sitter-dune]
<http://blog.emillon.org/posts/2024-07-26-introducing-tree-sitter-dune.html>
[Creating the SyntaxDocumentation Command - Part 3: VSCode Platform
Extension]
<https://tarides.com/blog/2024-07-24-creating-the-syntaxdocumentation-command-part-3-vscode-platform-extension>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 22998 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-07-23 13:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-07-23 13:30 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 17749 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 16 to 23,
2024.
Table of Contents
─────────────────
A Tour of the Living Library – A Safer FFI
first release of rpmfile
Dune dev meeting
Fighting Mutation with Mutation in Living
A small extension of Bigarray.Genarray adding iteration, mapping and folding
cudajit: Bindings to the `cuda' and `nvrtc' libraries
Rpmfile 0.2.0 - changelog
Exploring the Docusaurus+Odoc combo
Mopsa 1.0 – Modular Open Platform for Static Analysis
OCaml 5 performance
Other OCaml News
Old CWN
A Tour of the Living Library – A Safer FFI
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-a-tour-of-the-living-library-a-safer-ffi/14981/1>
Matt Walker announced
─────────────────────
I've written a new blog post on the `living' library I announced a few
days ago. Please give it a read if you're interested in safe use of
Ctypes, or otherwise need lifetime management in OCaml.
Would love to hear your views in this thread!
<https://fizzixnerd.com/blog/2024-07-17-touring-the-living-library/>
first release of rpmfile
════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985/1>
Mikhail announced
─────────────────
I'm happy to announce the first release of [rpmfile], a small library
for reading meta information from RPM packages (version 3.0). It uses
the Angstrom combinator parser library, which allows it to perform
streaming parsing using Lwt or Async.
How to get a package summary:
┌────
│ module Rpm_reader = Rpmfile.Reader (Rpmfile.Selector.All)
│
│ let metadata = Rpm_reader.of_file_exn "hello-2.12.1-1.7.x86_64.rpm"
│
│ Rpmfile.summary metadata
│ (* - : string = "A Friendly Greeting Program" *)
└────
The default reader module can read from a string or file, but has poor
performance. It needs a selector module to select the tags to
parse. The example uses `Selector.All' to parse all tags.
I am developing this library for my pet project to create a
self-hosted RPM repository management solution.
Thank you for your attention!
[rpmfile] <https://github.com/dx3mod/rpmfile>
Dune dev meeting
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/1>
maiste announced
────────────────
We are organizing a new public Dune dev meeting on *Wednesday, July,
24th at 10am CET*. It will be one hour long.
Whether you are a maintainer, a regular contributor, a new joiner or
just curious, feel free to join! The goal of these meetings is to
provide a place to discuss the ongoing work together :smile: Below,
you can find the agenda for this meeting:
:scroll: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Quick presentation about the attendees.
• Presentation about the ongoing work in Dune.
• Questions and Answers.
• Information discussions
:chains: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [GitHub Wiki]
[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>
[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>
[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>
Fighting Mutation with Mutation in Living
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-fighting-mutation-with-mutation-in-living/15003/1>
Matt Walker announced
─────────────────────
New blog post about fixing the mistakes in the `living' library.
Please take a look if you're interested in interfacing ocaml with
external resources.
<https://fizzixnerd.com/blog/2024-07-21-fixing-living/>
In particular, I think the library comes good with its guarantees now
that
1. if every function is properly dependent, and
2. you only `unsafe_free' values that are disjoint from their
dependencies, then
you will obtain a sound program when using the Ctypes ffi, in terms of
there being no use-after-free errors.
Please let me know if you disagree!
A small extension of Bigarray.Genarray adding iteration, mapping and folding
════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-a-small-extension-of-bigarray-genarray-adding-iteration-mapping-and-folding/15005/1>
NAlec announced
───────────────
I needed a few functions which were missing in the [OCaml library :
Bigarray.Genarray], and decided to write them for my own purpose :
• Iteration on genarrays
• mapping on genarrays
• folding on genarrays
Today I believe this can be usefull for others, and may suffer a code
inspection as I am not that experienced in OCaml. I am ready to have
this piece of code evolve if it is usefull so even (and maybe first) a
feedback on the usefullness of such code is welcome.
The only alternative I was given was the famous Owl library, which was
way to heavy for my needs, and not easily usable (if not
understandable). This extension is very simple, it is its
strenght. Ultimately, it could be merged in the standard library …
maybe after some work indeed : you tell me.
There is a clean documentation I guess, hope this can help :
[GenArrayIter]
Looking forward to hearing from you all.
[OCaml library : Bigarray.Genarray]
<https://ocaml.org/manual/5.2/api/Bigarray.Genarray.html>
[GenArrayIter] <https://github.com/Heyji2/GenArrayIter>
cudajit: Bindings to the `cuda' and `nvrtc' libraries
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cudajit-bindings-to-the-cuda-and-nvrtc-libraries/15010/1>
Lukasz Stafiniak announced
──────────────────────────
Hi! I'm happy to share cudajit 0.4.0: manually-selected bindings for
Nvidia GPU programming. cudajit should soon propagate to the opam
repository. [Bindings to the `cuda' and `nvrtc' libraries with a
unified interface] [API documentation] Currently supported:
• Compiling a kernel with conversion to PTX, launching a kernel.
• Synchronous and asynchronous memory copying.
• Contexts and streams.
• (GPU) device attributes.
Currently not supported:
• Events.
• CUDA graph features.
• Cooperative kernel launch.
Let me know your needs so I can prioritize. PRs are also welcome!
[Bindings to the `cuda' and `nvrtc' libraries with a unified interface]
<https://github.com/lukstafi/ocaml-cudajit>
[API documentation]
<https://lukstafi.github.io/ocaml-cudajit/cudajit/Cudajit/index.html>
Rpmfile 0.2.0 - changelog
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985>
Mikhail announced
─────────────────
Hello again, everyone. :wave: Today I want to tell you about what has
changed in a new version of my [rpmfile] library ([previous topic])
for reading meta-information from RPM packages.Should I post this in
the forum? I'm sorry.
[rpmfile] <https://github.com/dx3mod/rpmfile>
[previous topic]
<https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985>
Changes
╌╌╌╌╌╌╌
• Fixed incorrect string parsing. I just forgot to make `advance'
after `take_till' ([commit]);
• `angstrom-unix' is used by default to read files in the `Reader'
module functions. Previously, a RPM package was read entirely into
memory;
• Optimized partial parsing of [header sections]. Reduced unnecessary
memory allocations ([commit]);
• Decoding integers (int8/int16/int32/int64) to *native int* in access
functions[^1] (like `Rpmfile.payload_size'). You can also use `get'
to get "raw" values;
• Improved compatibility with 4.0 version of RPM format by using
*native int*;
• Added a module `Selector.Base' to select only basic package info
([commit]);
• Some new access functions and output fields of the CLI utility.
[commit]
<https://github.com/dx3mod/rpmfile/commit/3b01a3436a15d497ea2e4b94611108555189ff3b>
[header sections]
<https://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/pkgformat.html#AEN26581>
[commit]
<https://github.com/dx3mod/rpmfile/commit/2121190f59fc80cfedea9043ad13b440aa60f0d0>
[commit]
<https://github.com/dx3mod/rpmfile/commit/c4baf2fcc72965936bf2dea13abd1a096826b67d>
rpmfile vs rpm -qi
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Not a real "benchmark" for parsing 1.5 GB packages.
┌────
│ $ time rpm -qi repo/*.rpm
│ Executed in 226.82 millis fish external
│ usr time 212.74 millis 1.06 millis 211.68 millis
│ sys time 13.23 millis 0.00 millis 13.23 millis
│
│ $ time rpmfile repo/*.rpm
│ Executed in 153.97 millis fish external
│ usr time 116.74 millis 0.00 millis 116.74 millis
│ sys time 30.65 millis 1.47 millis 29.18 millis
└────
Rpmfile doesn't verify signatures, which is why it is "faster".
What's next?
╌╌╌╌╌╌╌╌╌╌╌╌
This is enough for my tasks, so there probably won't be a next release
:cold_face:
To-Do: functionality to work with signatures, read payload, implement
writer module for create packages.
Thank you for your attention!
P.S. I also want to apologize for my terrible English.
[^1]: The access function gets and decodes values from a `metadata'
record.
Exploring the Docusaurus+Odoc combo
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/exploring-the-docusaurus-odoc-combo/15012/1>
Mathieu Barbin announced
────────────────────────
To OCaml & Docusaurus enthusiasts out there :camel:+ :sauropod:
Some time ago, I shared my experience using Docusaurus to document an
OCaml project, highlighting the integration between Docusaurus,
ocaml-mdx, and the dune workflow (previous post [here]).
Today I wanted to share that I've resumed this exploration in
documentation tools to try and integrate odoc-generated pages into
Docusaurus, with the aim of creating a somewhat minimal
template/example for this.
I've published my experiment here:
[https://mbarbin.github.io/doc-experiment-docusaurus/].
Integrating odoc posed challenges - I've written about the (pragmatic)
approach I took [here]. I'm linking this [odoc issue] too, for
reference about exploring more native solutions for this interop.
Have you too tried this "magic combo" of Docusaurus, Odoc, and OCaml
tools? And if so, how did you approach it? Do you have insights or
suggestions? If this sparks your curiosity, please don't hesitate to
engage with the repository.
[here]
<https://discuss.ocaml.org/t/using-docusaurus-to-document-an-ocaml-project/13359>
[https://mbarbin.github.io/doc-experiment-docusaurus/]
<https://mbarbin.github.io/doc-experiment-docusaurus/>
[here] <https://mbarbin.github.io/doc-experiment-docusaurus/docs/odoc/>
[odoc issue] <https://github.com/ocaml/odoc/issues/121>
Mopsa 1.0 – Modular Open Platform for Static Analysis
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-mopsa-1-0-modular-open-platform-for-static-analysis/15013/1>
Raphaël Monat announced
───────────────────────
On behalf of all its developers, I am glad to announce the release of
[Mopsa 1.0]! You can just `opam install mopsa'.
Mopsa stands for Modular and Open Platform for Static Analysis. It
aims at easing the development and use of static analyzers. More
specifically, Mopsa is a generic framework for building sound static
analyzer based on the theory of abstract interpretation. Mopsa is
independent of language and abstraction choices. Developers are free
to add arbitrary abstractions (numeric, pointer, memory, etc.) and
syntax iterators for new languages. Mopsa encourages the development
of independent abstractions which can cooperate or be combined to
improve precision.
Mopsa currently support the analysis of Python, C and Python+C
programs. It reports run-time errors on C programs and uncaught
exceptions on Python programs. Our benchmarks provide an illustrative
overview of what Mopsa can currently analyze. All analyses currently
provided are flow and context-sensitive (i.e, control-flow operators
are taken into account by the analysis, and functions are analyzed by
virtual inlining). The C analysis is actively developed and
maintained. The Python and Python+C analyses work on real-world
examples, but are not actively developed.
Please note that Mopsa is an academic tool under development. Feel
free to submit [issues] if you encounter any bug!
Additional resources:
• [user manual]
• [demo of our abstract debugger]
• [academic overview of Mopsa], and [in a PhD thesis]
• [coreutils benchmarks on which Mopsa can run]
[Mopsa 1.0] <https://gitlab.com/mopsa/mopsa-analyzer/>
[issues]
<https://gitlab.com/mopsa/mopsa-analyzer/-/issues/?sort=created_date&state=opened&first_page_size=50>
[user manual] <https://mopsa.gitlab.io/mopsa-analyzer/user-manual/>
[demo of our abstract debugger]
<https://rmonat.fr/talk/240606_csv/#interactive-engine-demo>
[academic overview of Mopsa]
<https://hal.sorbonne-universite.fr/hal-02890500v1/document>
[in a PhD thesis]
<https://rmonat.fr/data/pubs/2021/thesis_monat.pdf#page=61>
[coreutils benchmarks on which Mopsa can run]
<https://gitlab.com/mopsa/benchmarks/coreutils-benchmarks>
OCaml 5 performance
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-5-performance/15014/1>
Thomas Leonard announced
────────────────────────
I've been trying out some tools to investigate performance problems in
my OCaml programs and I've written up my experiences here in case
other people find it useful:
• <https://roscidus.com/blog/blog/2024/07/22/performance/>
• <https://roscidus.com/blog/blog/2024/07/22/performance-2/>
The first post examines a case of slow IO in a concurrent Eio program,
and the second looks at poor GC performance in a multicore app.
In particular, it seems that minor GC performance is very sensitive to
other work running on the machine, since any domain being late will
trigger the others to sleep, e.g.
<https://global.discourse-cdn.com/business7/uploads/ocaml/original/2X/e/e821895b934f9519f84d0e52f28057bb30274092.png>
I'd be interested to know if others can shed more light on this, or
have other profiling tools they've found useful.
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [OCaml 5 performance part 2]
• [OCaml 5 performance problems]
• [OCaml Compiler Manual HTML Generation]
[the ocaml.org blog] <https://ocaml.org/blog/>
[OCaml 5 performance part 2]
<https://roscidus.com/blog/blog/2024/07/22/performance-2/>
[OCaml 5 performance problems]
<https://roscidus.com/blog/blog/2024/07/22/performance/>
[OCaml Compiler Manual HTML Generation]
<https://tarides.com/blog/2024-07-17-ocaml-compiler-manual-html-generation>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30545 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-07-16 6:24 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-07-16 6:24 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 14917 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 09 to 16,
2024.
Table of Contents
─────────────────
OCaml FFI Sharp Edges and How to Avoid Them
Ortac 0.3.0 Dynamic formal verification made easy
dream-html and pure-html 3.5.2
The OCaml community is signed up for Outreachy!
OCaml LSP 1.18.0
2nd editor tooling dev-meeting: 25th of July 🧙
A (Possibly) Safer Interface to the Ctypes FFI
OCaml Workshop 2024 at ICFP – announcement and call for proposals
living 0.1.0
Other OCaml News
Old CWN
OCaml FFI Sharp Edges and How to Avoid Them
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-ocaml-ffi-sharp-edges-and-how-to-avoid-them/14935/1>
Matt Walker announced
─────────────────────
Wrote another blog post about my adventures in Godotcaml. Check it
out if you're interested in some details of memory management with a
Ctypes FFI. Would love to hear input to some of the questions asked
in the post, too, if you'd like!
<https://fizzixnerd.com/blog/2024-07-09-ocaml-ffi-sharp-edges-and-how-to-avoid-them/>
Ortac 0.3.0 Dynamic formal verification made easy
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ortac-0-3-0-dynamic-formal-verification-made-easy/14936/1>
Nicolas Osborne announced
─────────────────────────
I'm very pleased to announce this exciting new release of Ortac
packages!
Ortac is a set of tools for dynamic verification of Gospel formal
specifications of OCaml code.
You can find the project on [this repo] and install the released
packages via `opam'.
Released packages are:
• `ortac-core'
• `ortac-runtime'
• `ortac-runtime-qcheck-stm'
• `ortac-qcheck-stm'
• `ortac-dune'
But running: `$ opam install ortac-qcheck-stm ortac-dune' should be
enough to install what is necessary.
Apart from some fixes, this release brings three main improvements to
the Ortac/QCheck-STM mode.
The first one is about user experience. This is a two-parts
improvement as we:
1. move to a module-based configuration to reduce the number of
arguments to give `ortac qcheck-stm' while increasing the
flexibility of configuration (see [documentation] for more
information)
2. release the Ortac/Dune plugin which generates the dune rules
necessary to generate and run the tests (see [README] for usage).
With these two improvements, we believe that you have a very good
excuse for not writing tests: it is very easy to generate them!
The second improvement is related to the supported subset of Gospel,
mainly about how you can express the logical model for your OCaml
types: you don't have to limit yourself anymore to the Gospel standard
library.
Finally, some work has been put on extending the coverage of the
generated tests: functions without any SUT argument and functions
mentioning tuples are now included in the tested values.
Happy testing!
[this repo] <https://github.com/ocaml-gospel/ortac>
[documentation]
<https://ocaml-gospel.github.io/ortac/ortac-qcheck-stm/index.html>
[README]
<https://github.com/ocaml-gospel/ortac/tree/main/plugins/dune-rules>
dream-html and pure-html 3.5.2
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/14808/3>
Yawar Amin announced
────────────────────
[ANN] dream-html & pure-html 3.6.0
Hello, I am happy to announce the following changes:
• Added some htmx attributes that had been omitted. Now as far as I
can tell we have complete coverage of all core attributes,
additional attributes, and those used by core extensions.
• Add a `?header:bool' optional parameter to `to_xml' and `pp_xml'
functions to conveniently render the XML header as part of the
output.
The OCaml community is signed up for Outreachy!
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/the-ocaml-community-is-signed-up-for-outreachy/13892/19>
Siddhi Agrawal announced
────────────────────────
I am Siddhi, an Outreachy Summer 2024 intern with the OCaml
community. I am working on the [ocaml-api-watch] project which is a
tool that detects changes in the public API of a library and displays
them in a human readable, git diff-like format so that the users and
maintainers can stay on top of them. I am being mentored by
@shonfeder, @NathanReb and Odinaka Joy (I am only able to mention
people here) and it has been a great experience so far.
I have linked my [blogs] here if you would like to know more about the
project.
[ocaml-api-watch] <https://github.com/NathanReb/ocaml-api-watch>
[blogs] <https://siddhiagg.wordpress.com/>
OCaml LSP 1.18.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-1-18-0/14952/1>
PizieDust announced
───────────────────
We are happy to announce the release of [ocaml-lsp 1.18.0] !
*New Features:*
This release brings exciting new features such as improved hover
behavior with less noisy hovers on some Parsetree nodes such as
keywords, comments etc. along with support for hovering over PPX
annotations and preview the generated code. This release also have
support for some additional custom queries, folding `ifthenelse'
expressions, a new configuration option to control dune diagnostics,
improved document symbols, and fixes to a handful of issues.
Do not hesitate to report any suspicious behavior in the [issue
tracker]
[ocaml-lsp 1.18.0]
<https://github.com/ocaml/ocaml-lsp/releases/tag/1.18.0>
[issue tracker] <https://github.com/ocaml/ocaml-lsp/issues>
2nd editor tooling dev-meeting: 25th of July 🧙
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-2nd-editor-tooling-dev-meeting-25th-of-july/14953/1>
vds announced
─────────────
After the success of our [first public dev-meeting], we are organizing
the next one on the 25th of July at 5pm CEST. Whether you are a long
time maintainer, an occasional contributor, a new comer, or simply a
curious passer-by, please feel free to attend!
✨ We have two talks scheduled for this session:
• @octachron will present his work on having structured compiler
output
• @nojb will present "typed grep" an tool used at LexiFi to search by
type in the codebase.
📋 Meeting agenda:
• A tour-de-table to allow the participants that wish to do so to
present themselves and mention issues / prs they are interested in.
• Talks and Q&A
• Discuss issues and pull requests that were tagged in advance or
mentioned during the tour-de-table.
• Discuss possible alternative meeting hours.
We're looking forward to meeting you!
• Meeting link: <https://meet.google.com/zhn-giws-gnu>
• Calendar event:
<https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MzRoaTAxcXJiNmVmYzloamxjbDY3MjY1YTcgdWx5c3NlQHRhcmlkZXMuY29t&tmsrc=ulysse%40tarides.com>
• Previous meeting notes are available in [Merlin's repository wiki].
[first public dev-meeting]
<https://discuss.ocaml.org/t/ann-first-public-editor-tooling-dev-meeting/14824>
[Merlin's repository wiki]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>
A (Possibly) Safer Interface to the Ctypes FFI
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-a-possibly-safer-interface-to-the-ctypes-ffi/14954/1>
Matt Walker announced
─────────────────────
Hi there, another blog post.
This time I discuss ideas for a new interface that helps localize the
possibilities of errors when working with a Ctypes-style FFI. Comment
below if you like/hate it please!
<https://fizzixnerd.com/blog/2024-07-11-a-possibly-safer-interface-to-the-ctypes-ffi/>
OCaml Workshop 2024 at ICFP – announcement and call for proposals
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2024-at-icfp-announcement-and-call-for-proposals/14371/13>
Sonja Heinze announced
──────────────────────
The accepted talks are now public! You can find them on the [Workshop
website].
We're very happy with the expected quality and diversity of talks. To
give a bit of a taste via a few examples of talks that will be
presented:
• In the context of the *OCaml language*, _On the design and
implementation of Modular Explicits_ will present a major and
long-wanted new language feature whose PR on the compiler landed
last week.
• In the context of the *OCaml ecosystem*, _Opam 2.2 and beyond_ will
present technical details as well as struggles about the just-landed
2.2 release of your package manager.
• In the context of *day-to-day OCaml applications*, _B · o · B, a
universal & secure file-transfer software in OCaml_ will present a
real-life MirageOs application.
• In the context of *OCaml developer experience*, _Project-wide
occurrences for OCaml, a progress report_ will present a shiny new
editor feature that makes OCaml code navigation a joy.
• There will also be four talks in the landscapes of *OCaml
multi-core* (i.e. OCaml 5).
We've given the authors a few weeks to update their abstracts and
papers if they want to. At the beginning of August, the scheduled
program with updated abstracts and attached papers will be on the
website.
For those who haven't seen it yet: The registration for the workshops
and the whole conference [is open now]. There's currently an early
bird discount, which *ends on August 3rd*.
As we've mentioned already, the in-person experience of the workshop
is a very nice one, allowing everyone to interact with colleagues and
the rest of the community, to chat about the talks and OCaml in
general, hit up the speakers etc. However, if you're not able to make
it, you'll still be able to enjoy the talks: The talks will be
live-streamed, and some time later be made permanently available
online.
Really, genuinely, thanks a lot to all members of the Program
Committee for the very valuable reviews and interactions as well as to
all the authors of all submissions!
[Workshop website] <https://icfp24.sigplan.org/home/ocaml-2024#program>
[is open now] <https://icfp24.sigplan.org/attending/registration>
living 0.1.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-living-0-1-0/14964/1>
Matt Walker announced
─────────────────────
I'm pleased to announce the first pre-opam version of the `living'
library, currently available only on GitHub for testing. I have some
basic tests and a README explaining what it's for, but basically, it
prevents mistakes like
┌────
│ open Ctypes
│
│ (** Returns a pointer into the argument character string that points to the first
│ instance of the argument character. *)
│ let strchr : char ptr -> char -> char ptr =
│ Foreign.foreign "strchr" (ptr char @-> char @-> returning (ptr char))
│
│ let () =
│ let p = CArray.start (CArray.of_string "abc") in
│ let q = strchr p 'a' in
│ let () = Gc.compact () in
│ let c = !@ q in
│ if Char.(equal c 'a') then print_endline "yay!" else print_endline "boo!"
└────
above from causing you pain. If you weren't aware, the code above
will almost always print "boo!". Using `living`, you can replace it
with this code:
┌────
│ open Living
│ open Living_ctypes
│
│ let strchr : char ptr -> char -> char ptr Living_core.t =
│ let strchr_unsafe = Foreign.foreign "strchr" (ptr char @-> char @-> returning (ptr char)) in
│ fun s c -> Living_core.(strchr_unsafe s c => s)
│
│ let _ =
│ let open Living_core.Let_syntax in
│ let* p = CArray.start (CArray.of_string "abc") in
│ let* q = strchr p 'a' in
│ let () = Gc.compact () in
│ let* c = !@ q in
│ if Char.(equal c 'a') then print_endline "yay!" else print_endline "boo!"
│ Living_core.return ()
└────
and it will always print "yay!"
Edit: should probably link to it!
<https://github.com/Fizzixnerd/ocaml-living>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [From the Lab to the Trading Floor with Erin Murphy]
[the ocaml.org blog] <https://ocaml.org/blog/>
[From the Lab to the Trading Floor with Erin Murphy]
<https://signals-threads.simplecast.com/episodes/from-the-lab-to-the-trading-floor-with-erin-murphy-hD6GHMhc>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30572 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-07-09 9:19 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-07-09 9:19 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 24432 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 02 to 09,
2024.
Table of Contents
─────────────────
The Structure of Godotcaml as of Today, by Matt Walker [Fizzixnerd]
opam 2.2.0 is out!
OCaml.org Newsletter: June 2024
ocaml-libbpf: Libbpf C-bindings for OCaml
How I built the Acutis template language in OCaml
MirageOS podcast
Old CWN
The Structure of Godotcaml as of Today, by Matt Walker [Fizzixnerd]
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-the-structure-of-godotcaml-as-of-today-by-matt-walker-fizzixnerd/14892/1>
Matt Walker announced
─────────────────────
Fixed some bugs in the Godot OCaml bindings I'm working on. Here is a
blog post that could be of interest if you're looking to dive into
them, or using Ctypes in another project, or are writing Godot
bindings for another language, or just have some time to
kill. :smiley:
<https://fizzixnerd.com/blog/2024-07-02-the-structure-of-godotcaml-as-of-today/>
opam 2.2.0 is out!
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-2-0-is-out/14893/1>
Kate announced
──────────────
We’re very happy to finally announce the release of opam 2.2.0.
What’s new?
╌╌╌╌╌╌╌╌╌╌╌
• *Windows support* :window: :tada: (you can hear all about it in the
[blog post])
• `opam tree' / `opam why': new commands showing a tree view of the
given packages and their dependencies and reverse-dependencies,
respectively.
• `with-dev-setup': a new variable and argument to install the
recommend developement setup for a local project.
• `opam pin --recursive' and `--subpath' to have opam look at opam
files elsewhere than the root directory of a project.
• `opam switch -' to go back to the previous global switch (inspired
by `git switch -')
• `opam pin --current' fixes a package to its current state (disabling
pending reinstallations or removals from the repository)
• `opam pin remove --all' removes all the pinned packages from a
switch
• `opam exec --no-switch' removes the opam environment when running a
command. It is useful when you want to launch a command without opam
environment changes.
• `opam clean --untracked' removes untracked files interactively
remaining from previous packages removal.
• `opam admin add-constraint <cst> --packages pkg1,pkg2,pkg3' applies
the given constraint to a given set of packages
• `opam list --base' has been renamed into `--invariant', reflecting
the fact that since opam 2.1 the "base" packages of a switch are
instead expressed using a switch invariant
• `opam install --formula <formula>' installs a formula instead of a
list of packages. This can be useful if you would like to install
one package or another one. For example `opam install --formula
'"extlib" | "extlib-compat"'' will install either `extlib' or
`extlib-compat' depending on what's best for the current switch.
• and many other features, performance improvements and fixes
:open_book: You can read our [blog post] for more information about
these changes and a lot more.
[blog post]
<https://opam.ocaml.org/blog/opam-2-2-0/#Major-change-Windows-support>
[blog post] <https://opam.ocaml.org/blog/opam-2-2-0/>
How to upgrade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In case you plan a possible rollback, you may want to first backup
your
`~/.opam' or `$env:LOCALAPPDATA\opam' directory.
The upgrade instructions are unchanged:
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.2.0"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/ocaml/opam/master/shell/install.ps1) }"
└────
or download manually from [the Github "Releases" page] to your PATH.
You should then run:
┌────
│ opam init --reinit -ni
└────
[the Github "Releases" page]
<https://github.com/ocaml/opam/releases/tag/2.2.0>
OCaml.org Newsletter: June 2024
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-org-newsletter-june-2024/14898/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the June 2024 edition of the OCaml.org newsletter! This
update has been compiled by the OCaml.org team. You can find [previous
updates] on Discuss.
Our goal is to make OCaml.org the best resource for anyone who wants
to get started and be productive in OCaml. The OCaml.org newsletter
provides an update on our progress towards that goal and an overview
of the changes we are working on.
We couldn't do it without all the amazing people who help us review,
revise, and create better OCaml documentation and work on issues. Your
participation enables us to so much more than we could just by
ourselves. Thank you!
This newsletter covers:
• *Recipes for the OCaml Cookbook:* Help us make the OCaml Cookbook
really useful by contributing and reviewing recipes for common
tasks!
• *Community & Marketing Pages Rework:* Implementation work in
progress.
• *General Improvements:* As usual, we also worked on general
maintenance and improvements, so we're highlighting some of the
work that happened below.
[previous updates] <https://discuss.ocaml.org/tag/ocamlorg-newsletter>
Open Issues for Contributors
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
You can find [open issues for contributors here]!
[open issues for contributors here]
<https://github.com/ocaml/ocaml.org/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+no%3Aassignee>
Recipes for the OCaml Cookbook
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The OCaml Cookbook is a place where OCaml developers share how to
solve common tasks using packages from the ecosystem.
A recipe is a code sample and explanations on how to perform a task
using a combination of open-source libraries.
The Cookbook is live at [ocaml.org/cookbook].
Here's how you can help:
1. Review, then [open pull requests for cookbook recipes]!
2. Contribute new recipes and tasks for the cookbook!
*Relevant PRs and Activities:*
• (open) PR: Cookbook Extract Links From HTML [ocaml/ocaml.org#2552]
by [@ggsmith842]
• (open) PR: Cookbook Measures of Central Tendency
[ocaml/ocaml.org#2540] by [@ggsmith842]
• (open) PR: Cookbook Send a POST/PATCH Request w/ Authentication
[ocaml/ocaml.org#2534]
• PR: Cookbook Normalise Vector [ocaml/ocaml.org#2513] by
[@ggsmith842]
• PR: (docs) Cookbook "Validate an Email Address" With `re'
[ocaml/ocaml.org#2518] by [@ggsmith842]
[ocaml.org/cookbook] <https://ocaml.org/cookbook>
[open pull requests for cookbook recipes]
<https://github.com/ocaml/ocaml.org/pulls?q=is%3Apr+is%3Aopen+label%3ACookbook>
[ocaml/ocaml.org#2552] <https://github.com/ocaml/ocaml.org/pull/2552>
[@ggsmith842] <https://github.com/ggsmith842>
[ocaml/ocaml.org#2540] <https://github.com/ocaml/ocaml.org/pull/2540>
[ocaml/ocaml.org#2534] <https://github.com/ocaml/ocaml.org/pull/2534>
[ocaml/ocaml.org#2513] <https://github.com/ocaml/ocaml.org/pull/2513>
[ocaml/ocaml.org#2518] <https://github.com/ocaml/ocaml.org/pull/2518>
Community & Marketing Pages Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We have [UI designs for the reworked and new pages of the community
section], and implementation is in progress.
*Relevant PRs and Activities:*
• PR: Events feed [ocaml/ocaml.org#2495] by [@ishar19]
• (open) PR: OCaml In Numbers: A dashboard with key metrics and
statistics about the OCaml community [ocaml/ocaml.org#2514] by
[@tmattio]
• PR: Add fields professor, enrollment, and `last_check' to Academic
[ocaml/ocaml.org#2489] by [@cuihtlauac]
• PR: Fix: render full title of OCaml Cookbook recipe as HTML page
title [ocaml/ocaml.org#2560] by [@sabine]
[UI designs for the reworked and new pages of the community section]
<https://www.figma.com/file/7hmoWkQP9PgLTfZCqiZMWa/OCaml-Community-Pages?type=design&node-id=637%3A4539&mode=design&t=RpQlGvOpeg1a93AZ-1>
[ocaml/ocaml.org#2495] <https://github.com/ocaml/ocaml.org/pull/2495>
[@ishar19] <https://github.com/ishar19>
[ocaml/ocaml.org#2514] <https://github.com/ocaml/ocaml.org/pull/2514>
[@tmattio] <https://github.com/tmattio>
[ocaml/ocaml.org#2489] <https://github.com/ocaml/ocaml.org/pull/2489>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2560] <https://github.com/ocaml/ocaml.org/pull/2560>
[@sabine] <https://github.com/sabine>
General Improvements and Data Additions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Summary:*
• To reduce repetition of the module interface definitions relating to
`ood-gen' (the tool that turns the files in the `data/' folder into
OCaml modules), types have been factored out. This hopefully makes
it simpler to contribute to changes to the data models.
• Materials for some of the tutorials have been published under the
<https://github.com/ocaml-web> GitHub organisation: [“Your First
OCaml Program”], [“Modules”], [“Functors”], and [“Libraries With
Dune”].
• The OCamlFormat version used to format the project is now 0.26.2.
*Relevant PRs and Activities:*
• PR: Update code highlighting color scheme [ocaml/ocaml.org#2496] by
[@Siddhant-K-code]
• Data
• PR: (data) Add OCaml.org newsletter May 2024
[ocaml/ocaml.org#2498] by [@sabine]
• PR: Add changelog entry for Merlin `4.15-414/501'
[ocaml/ocaml.org#2473] by [@voodoos]
• PR: Add the announement for opam 2.2.0~beta3
[ocaml/ocaml.org#2509] by [@kit-ty-kate]
• PR: Add missing changelog entries [ocaml/ocaml.org#2476] by
[@tmattio]
• PR: Add changelog entry for `ppxlib.0.32.1' release
[ocaml/ocaml.org#2479] by [@NathanReb]
• PR: (data) add `odoc' dev meeting to governance
[ocaml/ocaml.org#2521] by [@sabine]
• PR: (data) Update meeting link and frequency in governance for
OCaml.org [ocaml/ocaml.org#2542] by [@sabine]
• Documentation:
• PR: Prerequisites for Libraries With Dune [ocaml/ocaml.org#2551]
by [@cuihtlauac]
• Added repositories holding materials for some of the tutorials at
<https://github.com/ocalm-web>
• PR:~ocaml-web~ repo link [ocaml/ocaml.org#2547] by [@cuihtlauac]
• PR: Prerequisites and `ocaml-web' repo link
[ocaml/ocaml.org#2544] by [@cuihtlauac]
• PR: Prerequisites and `ocaml-web' repo link
[ocaml/ocaml.org#2543] by [@cuihtlauac]
• PR: Fix typo in `0it_00_values_functions.md'
[ocaml/ocaml.org#2548] by [@boisgera]
• PR: `ocaml-web' tutorial material URLs [ocaml/ocaml.org#2550] by
[@cuihtlauac]
• PR: In "Modules" tutorial: Fix `dune' files [ocaml/ocaml.org#2535]
by [@cuihtlauac]
• PR: Fix typo in "Tour of OCaml" [ocaml/ocaml.org#2519] by
[@blackwindforce]
• PR: Clarification on pattern matching and definitions
[ocaml/ocaml.org#2500] by [@cuihtlauac]
• Refactoring / Code health:
• Factor out types on `ood-gen' tool that parses the files in the
`data/' folder:
• PR: Single data type definition for Outreachy
[ocaml/ocaml.org#2481] by [@cuihtlauac]
• PR: Single data type definition for Resource
[ocaml/ocaml.org#2533] by [@cuihtlauac]
• PR: Single data type defintion for Success_story
[ocaml/ocaml.org#2536] by [@cuihtlauac]
• PR: Single data type defintion for Tool [ocaml/ocaml.org#2538]
by [@cuihtlauac]
• PR: Single type for Tool_page [ocaml/ocaml.org#2539] by
[@cuihtlauac]
• PR: Single type for Book [ocaml/ocaml.org#2488] by [@cuihtlauac]
• PR: Single data type definition for Exercise
[ocaml/ocaml.org#2497] by [@cuihtlauac]
• PR: Single data type definitions for Planet
[ocaml/ocaml.org#2529] by [@cuihtlauac]
• PR: Single data type definition for Release
[ocaml/ocaml.org#2531] by [@cuihtlauac]
• PR: Single data type definition for Changelog
[ocaml/ocaml.org#2492] by [@cuihtlauac]
• PR: Single data type definition for Cookbook
[ocaml/ocaml.org#2490] by [@cuihtlauac]
• PR: Single data type definition for Governance
[ocaml/ocaml.org#2504] by [@cuihtlauac]
• PR: Single data type definitions for Tutorial
[ocaml/ocaml.org#2555] by [@cuihtlauac]
• PR: Single data type definition for Event [ocaml/ocaml.org#2559]
by [@cuihtlauac]
• PR: Single data type definition for Industrial_user
[ocaml/ocaml.org#2505] by [@cuihtlauac]
• PR: Single type for Is_ocaml_yet [ocaml/ocaml.org#2508] by
[@cuihtlauac]
• PR: Single type definition for Job [ocaml/ocaml.org#2516] by
[@cuihtlauac]
• PR: Single data type definition for News [ocaml/ocaml.org#2520]
by [@cuihtlauac]
• PR: Single data type defintion for opam_user
[ocaml/ocaml.org#2522] by [@cuihtlauac]
• PR: Single data type definition for Workshop
[ocaml/ocaml.org#2541] by [@cuihtlauac]
• PR: Single data type defintion for Watch [ocaml/ocaml.org#2545]
by [@cuihtlauac]
• PR: Single data type definition for Page [ocaml/ocaml.org#2524]
by [@cuihtlauac]
• PR: Single data type definition for Paper [ocaml/ocaml.org#2526]
by [@cuihtlauac]
• PR: Single data type definition for Academic_Institution
[ocaml/ocaml.org#2477] by [@cuihtlauac]
• PR: Single data type definition for Code_examples
[ocaml/ocaml.org#2501] by [@cuihtlauac]
• PR: Remove redundant data type Watch [ocaml/ocaml.org#2507] by
[@cuihtlauac]
• Increase OCamlFormat version used to format the project from
0.25.1 to 0.26.2
• PR: Bringup OCamlFormat [ocaml/ocaml.org#2482] by [@cuihtlauac]
• PR: Formatting [ocaml/ocaml.org#2484] by [@cuihtlauac]
• PR: Add information on switch pin update [ocaml/ocaml.org#2483]
by [@cuihtlauac]
• PR: Bringup OCamlFormat in CI [ocaml/ocaml.org#2485] by
[@cuihtlauac]
• PR: Add information on switch pin update, cont'd
[ocaml/ocaml.org#2486] by [@cuihtlauac]
• PR: Rename Utils `map_files' into `map_md_files'
[ocaml/ocaml.org#2515] by [@cuihtlauac]
• PR: Remove unused Video data [ocaml/ocaml.org#2506] by
[@cuihtlauac]
• PR: Remove unused `ood/video' files [ocaml/ocaml.org#2546] by
[@cuihtlauac]
[“Your First OCaml Program”]
<https://github.com/ocaml-web/ocamlorg-docs-your-first-program>
[“Modules”] <https://github.com/ocaml-web/ocamlorg-docs-modules>
[“Functors”] <https://github.com/ocaml-web/ocamlorg-docs-functors>
[“Libraries With Dune”]
<https://github.com/ocaml-web/ocamlorg-docs-libraries-dune>
[ocaml/ocaml.org#2496] <https://github.com/ocaml/ocaml.org/pull/2496>
[@Siddhant-K-code] <https://github.com/Siddhant-K-code>
[ocaml/ocaml.org#2498] <https://github.com/ocaml/ocaml.org/pull/2498>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2473] <https://github.com/ocaml/ocaml.org/pull/2473>
[@voodoos] <https://github.com/voodoos>
[ocaml/ocaml.org#2509] <https://github.com/ocaml/ocaml.org/pull/2509>
[@kit-ty-kate] <https://github.com/kit-ty-kate>
[ocaml/ocaml.org#2476] <https://github.com/ocaml/ocaml.org/pull/2476>
[@tmattio] <https://github.com/tmattio>
[ocaml/ocaml.org#2479] <https://github.com/ocaml/ocaml.org/pull/2479>
[@NathanReb] <https://github.com/NathanReb>
[ocaml/ocaml.org#2521] <https://github.com/ocaml/ocaml.org/pull/2521>
[ocaml/ocaml.org#2542] <https://github.com/ocaml/ocaml.org/pull/2542>
[ocaml/ocaml.org#2551] <https://github.com/ocaml/ocaml.org/pull/2551>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2547] <https://github.com/ocaml/ocaml.org/pull/2547>
[ocaml/ocaml.org#2544] <https://github.com/ocaml/ocaml.org/pull/2544>
[ocaml/ocaml.org#2543] <https://github.com/ocaml/ocaml.org/pull/2543>
[ocaml/ocaml.org#2548] <https://github.com/ocaml/ocaml.org/pull/2548>
[@boisgera] <https://github.com/boisgera>
[ocaml/ocaml.org#2550] <https://github.com/ocaml/ocaml.org/pull/2550>
[ocaml/ocaml.org#2535] <https://github.com/ocaml/ocaml.org/pull/2535>
[ocaml/ocaml.org#2519] <https://github.com/ocaml/ocaml.org/pull/2519>
[@blackwindforce] <https://github.com/blackwindforce>
[ocaml/ocaml.org#2500] <https://github.com/ocaml/ocaml.org/pull/2500>
[ocaml/ocaml.org#2481] <https://github.com/ocaml/ocaml.org/pull/2481>
[ocaml/ocaml.org#2533] <https://github.com/ocaml/ocaml.org/pull/2533>
[ocaml/ocaml.org#2536] <https://github.com/ocaml/ocaml.org/pull/2536>
[ocaml/ocaml.org#2538] <https://github.com/ocaml/ocaml.org/pull/2538>
[ocaml/ocaml.org#2539] <https://github.com/ocaml/ocaml.org/pull/2539>
[ocaml/ocaml.org#2488] <https://github.com/ocaml/ocaml.org/pull/2488>
[ocaml/ocaml.org#2497] <https://github.com/ocaml/ocaml.org/pull/2497>
[ocaml/ocaml.org#2529] <https://github.com/ocaml/ocaml.org/pull/2529>
[ocaml/ocaml.org#2531] <https://github.com/ocaml/ocaml.org/pull/2531>
[ocaml/ocaml.org#2492] <https://github.com/ocaml/ocaml.org/pull/2492>
[ocaml/ocaml.org#2490] <https://github.com/ocaml/ocaml.org/pull/2490>
[ocaml/ocaml.org#2504] <https://github.com/ocaml/ocaml.org/pull/2504>
[ocaml/ocaml.org#2555] <https://github.com/ocaml/ocaml.org/pull/2555>
[ocaml/ocaml.org#2559] <https://github.com/ocaml/ocaml.org/pull/2559>
[ocaml/ocaml.org#2505] <https://github.com/ocaml/ocaml.org/pull/2505>
[ocaml/ocaml.org#2508] <https://github.com/ocaml/ocaml.org/pull/2508>
[ocaml/ocaml.org#2516] <https://github.com/ocaml/ocaml.org/pull/2516>
[ocaml/ocaml.org#2520] <https://github.com/ocaml/ocaml.org/pull/2520>
[ocaml/ocaml.org#2522] <https://github.com/ocaml/ocaml.org/pull/2522>
[ocaml/ocaml.org#2541] <https://github.com/ocaml/ocaml.org/pull/2541>
[ocaml/ocaml.org#2545] <https://github.com/ocaml/ocaml.org/pull/2545>
[ocaml/ocaml.org#2524] <https://github.com/ocaml/ocaml.org/pull/2524>
[ocaml/ocaml.org#2526] <https://github.com/ocaml/ocaml.org/pull/2526>
[ocaml/ocaml.org#2477] <https://github.com/ocaml/ocaml.org/pull/2477>
[ocaml/ocaml.org#2501] <https://github.com/ocaml/ocaml.org/pull/2501>
[ocaml/ocaml.org#2507] <https://github.com/ocaml/ocaml.org/pull/2507>
[ocaml/ocaml.org#2482] <https://github.com/ocaml/ocaml.org/pull/2482>
[ocaml/ocaml.org#2484] <https://github.com/ocaml/ocaml.org/pull/2484>
[ocaml/ocaml.org#2483] <https://github.com/ocaml/ocaml.org/pull/2483>
[ocaml/ocaml.org#2485] <https://github.com/ocaml/ocaml.org/pull/2485>
[ocaml/ocaml.org#2486] <https://github.com/ocaml/ocaml.org/pull/2486>
[ocaml/ocaml.org#2515] <https://github.com/ocaml/ocaml.org/pull/2515>
[ocaml/ocaml.org#2506] <https://github.com/ocaml/ocaml.org/pull/2506>
[ocaml/ocaml.org#2546] <https://github.com/ocaml/ocaml.org/pull/2546>
ocaml-libbpf: Libbpf C-bindings for OCaml
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-libbpf-libbpf-c-bindings-for-ocaml/14905/1>
Lee Koon Wen announced
──────────────────────
I'm excited to announce the first release of ocaml-libbpf, a new
library providing OCaml bindings for libbpf, the essential C library
for working with eBPF programs. This library allows you to load,
initialize, link, and manage eBPF programs within OCaml, simplifying
the process of working with these powerful in-kernel applications.
┌────
│ opam install libbpf
└────
Key Features:
• High-level and Low-level APIs: Access both raw bindings and
user-friendly high-level functions for eBPF management.
• Seamless Integration: Load eBPF ELF files into the kernel with ease.
• BPF Map Support: Manage BPF maps for communication between user
space and kernel space.
For more information, visit the [ocaml-libbpf] repo. Contributions and
feedback are welcome!
Enjoy!
[ocaml-libbpf] <https://github.com/koonwen/ocaml-libbpf>
How I built the Acutis template language in OCaml
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-how-i-built-the-acutis-template-language-in-ocaml/14916/1>
John announced
──────────────
Acutis is a personal project I've been developing on-and-off over the
last few years. It's a template language (similar to Mustache,
Nunjucks, etc.) that has a static type system, uses pattern-matching,
and can compile templates into JavaScript files. I'm sharing it now
because it's reached a somewhat-stable state.
[You can view its home page here] and [its source code here]. I also
wrote a blog-style article that explains how I created Acutis, the
problems I faced, and the decisions I made. You can read it here:
"[The Acutis template language, or: how I over-engineered a program
that just prints text]".
I don't especially expect people to use Acutis much, since it's very
personal and based around my specific use cases. (Also, we have an
overabundance of template languages already anyway.) Nonetheless,
building it was a fun and rewarding learning experience for
me. Perhaps some people will find it as interesting as I did. 🙂
[You can view its home page here] <https://johnridesa.bike/acutis/>
[its source code here] <https://github.com/johnridesabike/acutis>
[The Acutis template language, or: how I over-engineered a program that
just prints text] <https://johnridesa.bike/software/acutis/>
MirageOS podcast
════════════════
Archive: <https://discuss.ocaml.org/t/mirageos-podcast/14927/1>
Hannes Mehnert announced
────────────────────────
I recently was interviewed by Matthias Kirschner from FSFE about
MirageOS (+ OCaml). The result is a podcast
<https://fsfe.org/news/podcast/episode-25.en.html>
Spread the word, have a listen, and please don't hesitate to give
feedback - via email or in this thread.
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 36130 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-07-02 7:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-07-02 7:30 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 11900 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 25 to July
02, 2024.
Table of Contents
─────────────────
OCaml Tech Talk | Editor Features
New release of Ocsipersist
Preview of Godotcaml for the Godot 4.2 Game Engine
euler 0.3
dune 3.15
dune 3.16
Other OCaml News
Old CWN
OCaml Tech Talk | Editor Features
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-tech-talk-editor-features/14746/5>
Continuing this thread, PizieDust announced
───────────────────────────────────────────
The video is now uploaded on YouTube at: [Ocaml | Editor Features]
[Ocaml | Editor Features] <https://youtu.be/I-e3qzPzzuI>
New release of Ocsipersist
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-ocsipersist/14874/1>
Vincent Balat announced
───────────────────────
[Ocsipersist] has been recently updated.
Ocsipersist is an OCaml interface for key-value stores, with three
implementations based on SQLite, DBM and PostgreSQL.
It proposes several interfaces: basic string to string tables, typed
tables with custom (de)serialisation functions, persistent variables …
This new version 2.0.0, adds the following features:
‣ some dependencies removed
‣ Basic interface for persistent references, in the style of Eliom's
[scoped references] (but without scope)
Example of use of persistent references from the toplevel, with the
sqlite backend:
┌────
│ # #require "lwt_ppx";;
│ (* #thread;; if you are using OCaml < 5.0.0 *)
│ # #require "ocsipersist-sqlite";;
│ # Ocsipersist.init ();;
│ # let r = Ocsipersist.Ref.ref ~persistent:"r" 444;;
│ val r : int Ocsipersist.Ref.t = <abstr>
│ # Lwt_main.run (let%lwt v = Ocsipersist.Ref.get r in print_int v; Lwt.return_unit);;
│ 444- : unit = ()
└────
Backends: Choose the backend you prefer by using packages
`ocsipersist-sqlite', `ocsipersist-dbm' or `ocsipersist-postgresql'.
Configuration:
‣ Use module `Ocsipersist_settings', provided by each backend to
configure the database
‣ Opam packages `ocsipersist-sqlite-config', `ocsipersist-dbm-config'
or `ocsipersist-postgresql-config' make it possible to configure the
backend from Ocsigen Server's config file (breaking change: this was
provided by `ocsipersist-sqlite', `ocsipersist-dbm' or
`ocsipersist-postgresql' before. You'll need to update your
configuration files).
[Ocsipersist] <https://ocsigen.org/ocsipersist/>
[scoped references]
<https://ocsigen.org/eliom/latest/api/server/Eliom_reference>
Preview of Godotcaml for the Godot 4.2 Game Engine
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-preview-of-godotcaml-for-the-godot-4-2-game-engine/14875/1>
Matt Walker announced
─────────────────────
I've released a small preview of a project I've been working on. It's
bindings to the Godot 4.2 game engine from OCaml.
To keep this announcement short, I've posted a longer explanation on
my blog:
<https://fizzixnerd.com/blog/2024-06-24-announcing-godotcaml/>
Here is the git repo:
<https://github.com/Fizzixnerd/godotcaml>
Here is another short blog post explaining how to get up and started
with it:
<https://fizzixnerd.com/blog/2024-06-28-godotcaml-basic-setup/>
Do not expect much, I've basically just reached the point where Godot
and OCaml can call each other. I just thought people might think it's
cool! Open issues or discuss in this thread if you'd like; another
blog post will be forthcoming covering the current structure of the
code if there seems to be interest.
euler 0.3
═════════
Archive: <https://discuss.ocaml.org/t/ann-euler-0-3/14877/1>
glen announced
──────────────
It is my pleasure to announce the release of Euler version
0.3. :slight_smile:
Euler is an arithmetic library for OCaml integers. For more details,
please read *[the repo]*’s README or browse *[the docs]*.
In version 0.3:
• some amount of optimization (:magic_wand: magic tricks to compute
logarithms, see source code of [`log2sup'] and [`logsup']);
• new functions (for instance: root extraction, multiplicative order);
• `Arith.gcdext' now returns minimal coefficients and avoids overflows
(which was [not trivial]);
• factorization now performs some steps of Fermat’s factor searching,
which I think closes the gap with [Owl] (mentioning this because
@struktured [had asked me] how Euler compared with Owl, and Fermat’s
algorithm was the only integer arithmetic operation that I found in
Owl not provided by Euler).
The full list of changes is found in the changelog, in the repo.
Happy factorizing!
(This is a new topic because I cannot edit [the initial one].)
[the repo] <https://github.com/gmevel/euler-lib>
[the docs]
<https://gmevel.github.io/euler-lib/index.html/euler/Euler/index.html>
[`log2sup']
<https://github.com/gmevel/euler-lib/blob/0.3/src/Arith.ml#L621-L695>
[`logsup']
<https://github.com/gmevel/euler-lib/blob/0.3/src/Arith.ml#L697-L750>
[not trivial]
<https://github.com/gmevel/euler-lib/blob/0.3/src/Arith.ml#L1390-L1514>
[Owl] <https://github.com/owlbarn/owl>
[had asked me]
<https://discuss.ocaml.org/t/ann-euler-an-arithmetic-library-for-native-integers/12482/9>
[the initial one]
<https://discuss.ocaml.org/t/ann-euler-an-arithmetic-library-for-native-integers/12482>
dune 3.15
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-15/14438/4>
Etienne Millon announced
────────────────────────
We've released 3.15.3 (some time ago already) with the following
changes:
*3.15.3 (2024-05-24)*
Fixed
╌╌╌╌╌
• Fix interpretation of `exists_if' predicate in `META' files of
installed libraries containing more than one element. (#10564, fixes
#10563, @dbuenzli, @nojb)
• Fix TSAN warning in wait4 stubs (#10554, fixes #10553, @emillon)
dune 3.16
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-16/14889/1>
Etienne Millon announced
────────────────────────
We're happy to announce the release of Dune 3.16.0.
Among the list of chances, this release contains improvements to
melange support and a way to look for references in a whole project
using merlin and ocaml-lsp.
*3.16.0 (2024-06-17)*
Added
╌╌╌╌╌
• allow libraries with the same `(name ..)' in projects as long as
they don't conflict during resolution (via `enabled_if'). (#10307,
@anmonteiro, @jchavarri)
• `dune describe pp' now finds the exact module and the stanza it
belongs to, instead of guessing the name of the preprocessed
file. (#10321, @anmonteiro)
• Print the result of `dune describe pp' with the respective dialect
printer. (#10322, @anmonteiro)
• Add new flag `--context' to `dune ocaml-merlin', which allows to
select a Dune context when requesting Merlin config. Add `dune
describe contexts' subcommand. Introduce a field
`generate_merlin_rules' for contexts declared in the workspace, that
allows to optionally produce Merlin rules for other contexts besides
the one selected for Merlin (#10324, @jchavarri)
• melange: add include paths for private library `.cmj' files during
JS emission. (#10416, @anmonteiro)
• `dune ocaml-merlin': communicate additional directives
`SOURCE_ROOT', `UNIT_NAME' (the actual name with wrapping) and
`INDEX' with the paths to the index(es). (#10422, @voodoos)
• Add a new alias `@ocaml-index' that uses the `ocaml-index' binary to
generate indexes that can be read by tools such as Merlin to provide
project-wide references search. (#10422, @voodoos)
• merlin: add optional `(merlin_reader CMD)' construct to `(dialect)'
stanza to configure a merlin reader (#8567, @andreypopp)
Changed
╌╌╌╌╌╌╌
• melange: treat private libraries with `(package ..)' as public
libraries, fixing an issue where `import' paths were wrongly
emitted. (#10415, @anmonteiro)
• install `.glob' files for Coq theories too (#10602, @ejgallego)
Fixed
╌╌╌╌╌
• Don't try to document non-existent libraries in doc-new target
(#10319, fixes #10056, @jonludlam)
• Make `dune-site''s `load_all' function look for `META' files so that
it doesn't fail on empty directories in the plugin directory
(#10458, fixes #10457, @shym)
• Fix incorrect warning for libraries defined inside non-existant
directories using `(subdir ..)' and used by executables using
`dune-build-info' (#10525, @rgrinberg)
• Don't try to take build lock when running `coq top --no-build'
(#10547, fixes #7671, @lzy0505)
• Make sure to truncate dune's lock file after locking and unlocking
so that users cannot observe incorrect pid's (#10575, @rgrinberg)
• mdx: link mdx binary with `byte_complete'. This fixes `(libraries)'
with foreign archives on Linux. (#10586, fixes #10582, @anmonteiro)
• virtual libraries: fix an issue where linking an executable
involving several virtual libries would cause an error. (#10581,
fixes #10460, @rgrinberg)
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Creating the SyntaxDocumentation Command - Part 2: OCaml LSP]
• [Testing MirageVPN against OpenVPN™]
• [Enhancing the OCaml.org Community Page: Boosting UX and UI Based on
User Research]
• [qubes-miragevpn, a MirageVPN client for QubesOS]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Creating the SyntaxDocumentation Command - Part 2: OCaml LSP]
<https://tarides.com/blog/2024-07-12-creating-the-syntaxdocumentation-command-part-2-ocaml-lsp>
[Testing MirageVPN against OpenVPN™]
<https://blog.robur.coop/articles/miragevpn-testing.html>
[Enhancing the OCaml.org Community Page: Boosting UX and UI Based on
User Research]
<https://tarides.com/blog/2024-06-26-enhancing-the-ocaml-org-community-page-boosting-ux-and-ui-based-on-user-research>
[qubes-miragevpn, a MirageVPN client for QubesOS]
<https://blog.robur.coop/articles/qubes-miragevpn.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 23394 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-06-25 13:58 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-06-25 13:58 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 19838 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 18 to 25,
2024.
Table of Contents
─────────────────
First public editor tooling dev-meeting
First release of oma
Ppxlib dev meetings
CAISAR release 2.0, a platform for characterizing AI safety and robustness
First release of baby
Preview of Stripe client and mock server - DkStdRestApis
opam 2.2.0 rc1 release
Project wide occurrences
Other OCaml News
Old CWN
First public editor tooling dev-meeting
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-public-editor-tooling-dev-meeting/14824/1>
vds announced
─────────────
We are organizing the first public dev-meeting about Merlin, OCaml-LSP
and more generally editor support for OCaml. This meeting will take
place on *Thursday, June 27th*, at 05:00 pm CEST. We plan to have
these happen every last Thursday of the month.
The goal of these meetings is to provide a place for all contributors
of these projects to discuss their work together. Whether you are a
long time maintainer, an occasional contributor, a new comer, or
simply a curious passer-by, please feel free to join and participate!
We also plan to have some short technical presentations to help
contributors learn more about the projects involved. These won't be
systematic, and if you are interested in a particular subject feel
free to ask about it or to propose a presentation.
The agenda for this first meeting, which will be focused on the
burning topic of project-wide occurrences, is the following:
• A tour-de-table to allow the participants that wish to do so to
present themselves and mention issues / prs they are interested in.
• A presentation of current on-going projects.
• A focus on project-wide occurrences: how does it work, what are the
tools that need to interact together and what are its current
limitations and possible future improvements.
• Discuss issues and pull requests that were tagged in advance or
mentioned during the tour-de-table.
• Informal discussion
We looking forward to meeting you!
Meeting link: <https://meet.google.com/imo-mkxi-hpt>
First release of oma
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-oma/13845/2>
François Pottier announced
──────────────────────────
I have just published a new release of `oma' with the following fixes
and changes:
• New functions `invalidate_open_interval' and
`invalidate_semi_open_interval'.
• Fix a serious bug in `Unsafe.first' and `Unsafe.last', which would
incorrectly return `None' when the region contains only one point.
• Fix a serious bug in `Unsafe.iter', which would systematically omit
the last point of the region.
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/25>
Nathan Rebours announced
────────────────────────
Meeting notes are available here:
<https://github.com/ocaml-ppx/ppxlib/wiki/Dev-Meeting-2024-06-18>.
Thanks to everyone who attended!
Our next meeting is scheduled for Tuesday July 16th, 6:00PM CET!
CAISAR release 2.0, a platform for characterizing AI safety and robustness
══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-caisar-release-2-0-a-platform-for-characterizing-ai-safety-and-robustness/14831/1>
Julien Girard announced
───────────────────────
On the occasion of the 34th birthday of the [abolition of the
apartheid laws], we are honoured to release CAISAR version 2.0.
The release source is available at our [public forge]. As our last
releases, CAISAR will soon be available on [opam] and on [Dockerhub].
A nix flake is available for building CAISAR directly in the
repository. Try CAISAR with `nix build
git+https://git.frama-c.com/pub/caisar'!
Here are the prominent features for this 2.0 release:
[abolition of the apartheid laws]
<https://www.dw.com/fr/il-y-a-25-ans-la-fin-de-lapartheid/a-18523920>
[public forge] <https://git.frama-c.com/pub/caisar/-/releases/2.0>
[opam] <https://opam.ocaml.org/packages/caisar/>
[Dockerhub] <https://hub.docker.com/r/laiser/caisar>
Specification and verification of several neural networks at once
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
CAISAR specification language already allowed to write specifications
that involved several neural networks at once. However, translating
such specifications to actual prover queries was not possible. We
added automated graph editing techniques to allow such verification to
take place. Within particular patterns, CAISAR will generate an ONNX
file that preserve the semantic of the different neural networks while
encapsulating parts of the specification directly in the control flow
of the new neural network. This feature allow the verification of
properties with multiple neural networks, including their composition.
This is quite a step forward, as it enables machine-learning dedicated
verifiers to tackle a much wider range of properties.
SVM as first-class citizens for interpretation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
CAISAR now fully integrate SVMs into the interpretation engine. Users
can expect vector computations and applications on SVMs to be computed
similarly as what exists already for neural networks.
We also unified the theory of machine learning models. Now, SVMs and
neural networks can be specified with only the `model' type. In the
near future, SVMs will be parsed directly into CAISAR’s Neural
Intermediate Representations, which will simplify the verification of
systems with heterogeneous AI components.
First release of baby
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-baby/14840/1>
François Pottier announced
──────────────────────────
It is my pleasure to announce the first release of `baby'.
`baby' is an OCaml library that offers several implementations of
balanced binary search trees. At this time, `baby' offers a
replacement for OCaml's `Set' module; it does not yet have a
replacement for OCaml's `Map' module.
Height-balanced and weight-balanced binary search trees are offered
out of the box. Furthermore, to advanced users, the library offers a
lightweight way of implementing other balancing strategies.
The following points offer a comparison between `baby' and OCaml's
`Set' library.
Better Performance
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
At the time of writing, `baby' offers generally better performance
than OCaml's `Set' library. Its operations are generally faster
(sometimes much faster; sometimes slightly faster; sometimes slightly
slower) than those of the `Set' library, and its memory allocation
rate is slightly lower.
Constant-Time Cardinal
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In contrast with the `Set' library, `baby''s weight-balanced trees
offer a `cardinal' function whose time complexity is *O(1)*. They also
offer a family of random access functions (`get', `index', etc.) whose
time complexity is *O(log n)*. Furthermore, by exploiting cardinality
information, the functions `subset' and `equal' are sometimes able to
return `false' in constant time.
Better Sharing
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`baby''s binary operations (`union', `inter', `diff') take advantage
of (and preserve) physical equality in a more aggressive way. This
allows them to (sometimes) be faster and allocate less memory.
Adaptive Conversions To Sets
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`baby''s conversion functions `of_list', `of_array', and `of_seq' have
adaptive complexity. If the input data is sorted, their complexity is
*O(n)*; otherwise, their complexity gracefully degrades down to
*O(n.log n)*.
More Operations
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`baby' offers a few operations that do not exist in OCaml's `Set'
library:
⁃ The symmetric difference, `xor';
⁃ The conversion functions `of_array' and `to_array';
⁃ The extremum-removal functions `remove_min_elt' and
`remove_max_elt';
⁃ The enumeration API in the submodule `Enum'. Enumerations should be
slightly faster than standard sequences, and are able to efficiently
seek ahead, via the function `from'.
Documented Complexity
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In `baby', the time complexity of every operation is documented.
Compatibility
╌╌╌╌╌╌╌╌╌╌╌╌╌
`baby' is perfectly compatible with OCaml's Set library. In other
words, using `Baby.W.Set' instead of `Set' is safe.
As a word of warning, though, if the equivalence relation on elements
is coarser than equality (that is, if `compare x y = 0' does not imply
`x = y'), then `Baby.W.Set' and `Set' might behave differently when a
choice must be made between two equivalent elements. This can occur in
`union', `of_list', `of_array', `of_seq', `add_seq', `map'.
Preview of Stripe client and mock server - DkStdRestApis
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-preview-of-stripe-client-and-mock-server-dkstdrestapis/14841/1>
jbeckford announced
───────────────────
I am pleased to announce that Stripe is the first REST API available
in the DkStdRestApis project:
<https://github.com/diskuv/DkStdRestApis?tab=readme-ov-file>
That README has a 10-minute quick start; you can do it with or without
a Stripe account.
The Stripe client and mock server have Apache 2.0 licensing and were
generated using a new OpenAPI code generator. The code generator is
not part of this preview announcement (wait until DkCoder 0.4
announcement) but since there have been a couple generators released
in the past month perhaps it is best to say what is different:
1. Both client and server source code are generated. The client
examples include direct web requests by cohttp-lwt-curl
(`src/DkStdRestApis_NotStripe/Curl2.ml') and also indirectly by
printing the `curl -d name=value https://api.stripe.com/...'
command (`src/DkStdRestApis_NotStripe/CurlCmd.ml'). The mock server
example (`src/DkStdRestApis_NotStripe/ServerTiny.ml') uses @c-cube
's [excellent tiny_httpd daemon].
2. Very small dependency cone that works on Windows/macOS/Linux
(including the REST server). And the minimum OCaml version will be
4.14 for the foreseeable future.
3. My focus is not on the code generator but having working,
maintainable REST clients for the major cloud/SaaS services that
can be included in DkCoder's liberally licensed standard
library. The server feature was a pleasant but very unplanned
accident. If I do take time to develop fancier server features
(ex. replaying mocks from a corpus, etc.) those additions will not
be open source.
4. It is intended to have high coverage of OpenAPI features. Today
that includes form URL encoding, sum types, server-side
polymorphism and style/explode support. The only major feature that
is intentionally unsupported is the `not' composition operator
(have no idea how to express negation in OCaml's type system!).
Now for the problems:
1. Stripe only compiles in bytecode mode. Why? The generated modules
are huge (8+ MB in total) because Stripe's specification is
6MB. Native compilation [can't handle that today].
2. I'm not releasing to opam until I'm sure that native compilation
won't denial-of-service developer and opam machines. I'm also
waiting for some Windows patches to dependencies to be released.
Thanks to @vlaviron for helping solve some of the compilation scaling
problems. And thanks to Nomadic Labs (and OCamlPro?) for developing
[Json_encoding] and @anuragsoni for developing [Routes]; they are both
bidirectional + lightweight + foundational.
Report bugs / add stars [in the DkCoder project].
[excellent tiny_httpd daemon] <https://v3.ocaml.org/p/tiny_httpd/latest>
[can't handle that today] <https://github.com/ocaml/ocaml/issues/13250>
[Json_encoding] <https://v3.ocaml.org/p/json-data-encoding/latest>
[Routes] <https://v3.ocaml.org/p/routes/latest/doc/index.html>
[in the DkCoder project] <https://github.com/diskuv/dkcoder>
opam 2.2.0 rc1 release
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-opam-2-2-0-rc1-release/14842/1>
R. Boujbel announced
────────────────────
We’re once again very excited to announce this first release candidate
(and hopefully only) for opam 2.2.0.
What’s new in this rc?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Fix `opam upgrade' wanting to keep rebuilding the compiler (as now
it contains an `x-env-path-rewrite' field)
• Provide defaults so `opam init -y' no longer asks questions on
Windows
• Fix `OpamConsole.menu' when there are more than 9 options (can
happen on Windows)
• A couple more fixes and general improvements
:open_book: You can read our [blog post ] for more information about
these changes and more, and for even more details you can take a look
at the [release note ] or the [changelog].
[blog post ] <https://opam.ocaml.org/blog/opam-2-2-0-rc1/>
[release note ] <https://github.com/ocaml/opam/releases/tag/2.2.0-rc1>
[changelog] <https://github.com/ocaml/opam/blob/2.2.0-rc1/CHANGES>
Windows issues
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Configuration of Windows is tricky, so please don’t be too
disheartened if things don’t work instantly. If something doesn’t work
first time, [please do report it ], even if you manage to find a way
to workaround it. If opam didn’t elegantly tell you what was wrong,
then it’s a bug and we’d love to hear about it, rather than ending up
with a series of workarounds flying around. It’s no problem at all for
us to receive a bug report which turns out to be user error - we’d far
rather that than not hear bugs which are opam’s error! :scream_cat:
[please do report it ] <https://github.com/ocaml/opam/issues>
How to upgrade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
For Unix systems
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.2.0~rc1"
└────
or from PowerShell for Windows systems
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/ocaml/opam/master/shell/install.ps1) }"
└────
We’re planning for a final opam 2.2.0 release next week, so please do
report any issue you encounter on our [bug-tracker ].
[bug-tracker ] <https://github.com/ocaml/opam/issues>
Project wide occurrences
════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-project-wide-occurrences/14847/1>
vds announced
─────────────
I am very excited to announce the first release of Merlin and
Ocaml-LSP with support for project-wide occurrences 🥳. More
precisely, it is now possible to query for every _usage_ of any value
(and type, modules, etc.) anywhere in a project built with Dune. This
is a very handy tool for code navigation !
Requirements
╌╌╌╌╌╌╌╌╌╌╌╌
• OCaml 5.2
• Latest Dune (>= `3.16.0')
• Latest Merlin (>= `5.1-502')
• Latest OCaml-LSP preview (`1.18.0~5.2preview')
Usage
╌╌╌╌╌
• Build the new `@ocaml-index' alias.
> We recommend running the indexation in watch mode along with your
usual targets: `dune build @ocaml-index --watch' so that the index
is always up to date.
• Use the `Find/Peek all references' feature of LSP-based plugins
• or `merlin-project-occurrences' in emacs
• or `OccurrencesProjectWide' in vim.
• Enjoy jumping around 🦘
<https://global.discourse-cdn.com/business7/uploads/ocaml/original/2X/c/c282815986f60d12069d33bc13f22fcdb70f0022.gif>
More information and bug reports
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Bug reports and feature requests should be submitted to the Merlin
[issue tracker]. There are already some known issues like the absence
of declarations in the results and the impossibility to query from a
declaration. Progress on occurrences can be tracked in a [pinned
meta-issue]. If you are interested in contributing and learning more
about the feature do not hesitate to join the [first public
dev-meeting] on Thursday !
[issue tracker] <https://github.com/ocaml/merlin/issues>
[pinned meta-issue] <https://github.com/ocaml/merlin/issues/1780>
[first public dev-meeting]
<https://discuss.ocaml.org/t/ann-first-public-editor-tooling-dev-meeting/14824/1>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Keeping Up With the Compiler: How we Help Maintain the OCaml
Language]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Keeping Up With the Compiler: How we Help Maintain the OCaml Language]
<https://tarides.com/blog/2024-06-19-keeping-up-with-the-compiler-how-we-help-maintain-the-ocaml-language>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 32955 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-06-18 13:05 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-06-18 13:05 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 9969 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 11 to 18,
2024.
Table of Contents
─────────────────
Your opam-repository PRs are now tested on Windows
Forester 4.1
fun-sql 0.2.3
dream-html and pure-html 3.5.2
Control Structures, English translation of lectures by Xavier Leroy
Ppxlib dev meetings
Other OCaml News
Old CWN
Your opam-repository PRs are now tested on Windows
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-your-opam-repository-prs-are-now-tested-on-windows/14781/1>
Kate announced
──────────────
Following the merge of [Windows support for the compiler in
opam-repository] and the [release of opam 2.2.0~beta3], I'm happy to
announce that a basic Windows CI using Github Actions is now in use in
opam-repository, so all your new PRs are now being tested on Windows
too.
This is a big milestone, however the upstream opam-repository hasn't
been tested with Windows before and thus many packages lacking the
proper availability metadata will fail to build in the next month or
so. If you see a package that is definitely not going to be available
on Windows, please do report it in the [opam-repository bug-tracker]
or even better open a PR if you have the time. When opening such
PRs/issues, it would help the maintainers to copy/paste the failing
log in the PR description.
Most such PRs should simply add the following line to the failing
package(s):
┌────
│ available: os != "win32"
└────
If you notice any issues in the Github Action itself or want to
improve it, please feel free to open a PRs/issue for that too, the
code is available in [opam-repository/.github/workflows/windows.yml].
[Windows support for the compiler in opam-repository]
<https://github.com/ocaml/opam-repository/pull/25861>
[release of opam 2.2.0~beta3]
<https://discuss.ocaml.org/t/ann-opam-2-2-0-beta3/14772>
[opam-repository bug-tracker]
<https://github.com/ocaml/opam-repository/issues>
[opam-repository/.github/workflows/windows.yml]
<https://github.com/ocaml/opam-repository/blob/master/.github/workflows/windows.yml>
Forester 4.1
════════════
Archive: <https://discuss.ocaml.org/t/ann-forester-4-1/14800/1>
Jon Sterling announced
──────────────────────
I am pleased to announce the release of [Forester 4.1] on opam, which
is an OCaml utility to develop “Forests”, which are densely
interlinked mathematical websites / Zettelkästen similar to the
[Stacks project] or [Kerodon ]. You can see the [release notes] on my
own [Forest].
There are a few new features, including a simplified command `forester
init` to setup a fresh forest.
Thanks to Kento Okura, Nick Hu, and Trebor Huang for their
contributions to this release.
[Forester 4.1] <http://www.jonmsterling.com/jms-00S9.xml>
[Stacks project] <https://stacks.math.columbia.edu>
[Kerodon ] <https://kerodon.net>
[release notes] <http://www.jonmsterling.com/jms-00S9.xml>
[Forest] <https://www.jonmsterling.com>
fun-sql 0.2.3
═════════════
Archive: <https://discuss.ocaml.org/t/ann-fun-sql-0-2-3/14806/1>
Yawar Amin announced
────────────────────
I am happy to announce the initial release of fun-sql, a simple
functional-style query library for SQLite and PostgreSQL.
To use it with SQLite: <https://ocaml.org/p/fun-sqlite>
To use it with PostgreSQL: <https://ocaml.org/p/fun-postgresql>
Fun-sql is not an ORM, it's a query execution and data mapping library
(sometimes called a micro-ORM). It does three things:
1. Create the prepared statement and encode the parameters
2. Execute the query
3. Decode the resultset into OCaml types using a set of combinators.
Here's an example:
┌────
│ open Fun_postgresql
│
│ module Note(Db : sig val db : Postgresql.connection end) = struct
│ open Db
│
│ type t = { id : int; txt : string }
│ let ret = ret (fun row -> { id = int 0 row; txt = text 1 row })
│
│ (* Prepared statement: *)
│ let edit = query db "update note set txt = $1 where id = $2"
│
│ (* Use by simply calling it: *)
│ let edit id txt = edit ~args:Arg.[int id; text txt] unit
│ (* val edit : int -> string -> unit *)
│
│ (* Prepared statement: *)
│ let by_id = query db "select id, txt from note where id = $1"
│
│ let by_id id = only (by_id ~args:Arg.[int id] ret)
│ (* val by_id : int -> t *)
│ end
└────
The design enforces the use of prepared statements–indeed, with
PostgreSQL, a prepared statement corresponding to a query can be
created only _once,_ so you have to ensure that you use a pattern like
the above.
MySQL support is also desired and I will get to it at some point
unless someone beats me to it!
dream-html and pure-html 3.5.2
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/14808/1>
Yawar Amin announced
────────────────────
Pleased to announce the release of dream-html 3.5.2, which actually
spawns a new package pure-html: <https://ocaml.org/p/pure-html>
This package offers the same functionality as dream-html, _except_
without a Dream dependency, so you can use whatever web server you
like, or even use it for other applications than web servers. It works
exactly the same way as dream-html, except the top-level module is
`Pure_html':
┌────
│ open Pure_html
│ open HTML
│
│ let content = article [] [
│ p [] [txt "Header"];
│ p [] [txt "Body"];
│ ]
└────
pure-html has a runtime dependency only on the `uri' package.
Control Structures, English translation of lectures by Xavier Leroy
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/control-structures-english-translation-of-lectures-by-xavier-leroy/14810/1>
unfode announced
────────────────
[Website].
Really learned a lot from the slides. For example, the most
understandable definition of continuation I've ever seen:
Given a control point in a program, its continuation is
the sequence of computations that remain to be done once
the execution reaches the given control point in order to
finish the execution of the whole program.
[Website] <https://xavierleroy.org/CdF/2023-2024/index.html>
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/24>
Nathan Rebours announced
────────────────────────
This month's meeting is scheduled today, Tuesday June 18th, at 6:00PM
CET.
Sorry for posting the announcement so late!
Here is the meeting agenda:
• 5.2 AST bump
• Driver Transform refactoring
• 5.3 support
‣ Added a trunk CI build, we should be able to consider merging
‣ Still need documentation for releases
• Driver anti-warning 34 code gen
‣ Still haven't heard from Janestreet, we need their feedback before
moving forward with this
• Ocamlfind support
‣ There seem to be a bug when a ppxlib based ppx is invoked directly
using ocamlfind -package
‣ Is this something we want to actively maintain
• Dune w/ ppx
‣ Nathan got back to it, hopefully it should be ready soon
• Repo hygiene: issue triage
‣ We have a lot of issues, most of which are extremely old
‣ A lot of issues are actually questions on how to use ppxlib for
ppx authors
‣ It's worth having a go at closing the irrelevant issues and have
some classification system for the rest
The meeting will be hosted on google meet here:
<https://meet.google.com/yxw-ejnu-cju>
You are welcome to join!
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Creating the SyntaxDocumentation Command - Part 2: OCaml LSP]
• [MirageVPN server]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Creating the SyntaxDocumentation Command - Part 2: OCaml LSP]
<https://tarides.com/blog/2024-07-12-creating-the-syntaxdocumentation-command-part-2-ocaml-lsp>
[MirageVPN server]
<https://blog.robur.coop/articles/miragevpn-server.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 23615 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-06-11 15:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-06-11 15:04 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 59200 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 04 to 11,
2024.
Table of Contents
─────────────────
Providing Opam system dependancies with Nix
ppx_deriving.6.0.2 and ppx_deriving_yojson.3.8.0
Effective ML Through Merlin's Destruct Command
OCaml Windows Working Group
Flambda2 Ep. 2: Loopifying Tail-Recursive Functions, by OCamlPro
OCaml Platform Newsletter: March-May 2024
OCaml.org Newsletter: May 2024
OCaml Windows Working Group
Registration for Fun OCaml 2024 Opens Shortly
opam 2.2.0~beta3
Other OCaml News
Old CWN
Providing Opam system dependancies with Nix
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/providing-opam-system-dependancies-with-nix/14745/1>
Ryan announced
──────────────
I've opened a [PR] with input from @dra27 and @avsm adding support for
Nix depexts (system dependencies) to Opam.
Opam supports system dependencies for other platforms by invoking the
system package manager, e.g. `apt-get install ...'. However Nix is a
bit different, as in general installing a package to your system
doesn't create the development environment required to use it; it will
only add executables to your `$PATH'. To find, for example, objects
files, outside of a Nix derivation you can use `nix-shell' and it's
descendant `nix develop'. E.g.:
┌────
│ $ nix-shell -p gmp
│ $ echo $NIX_LDFLAGS
│ -rpath /nix/store/20g5iw2r512gnfrdr4imp2y940v3vlif-shell/lib -L/nix/store/rx6nkd40819acppajq29g1hxa4d9r35f-gmp-with-cxx-6.3.0/lib -L/nix/store/rx6nkd40819acppajq29g1hxa4d9r35f-gmp-with-cxx-6.3.0/lib
└────
We support Nix depexts with Opam in a similar way. A Nix derivation is
build with the desired packages as inputs, and the resulting
environment is output as a file in the Opam switch in a format that
Opam can parse. This `nix.env' file is a symlink into the Nix store,
so acts as a garbage collection root – packages won't be removed from
the store while this file exists. Opam outputs these environment
variables on an invocation of `opam env'.
This fixes issues such as
<https://discuss.ocaml.org/t/opam-and-nixos-is-there-an-alternative-to-nix-shell/13726>.
While the primary use case is on NixOS, this depext mechanism could be
used on other platforms to provide a consistent experience including
other Linux distributions, BSDs, (and possibly [even windows] in the
future).
Nixpkgs typically only packages one version of a package at a time,
but I'm working on versioned depexts with previous version of Nixpkgs
as outlined [here].
I'm keen to get people's opinions and perspective on this!
[PR] <https://github.com/ocaml/opam/pull/5982>
[even windows] <https://github.com/NixOS/nix/pull/8901>
[here]
<https://discuss.ocaml.org/t/depending-on-non-ocaml-languages-from-the-opam-repository/12585/6>
ppx_deriving.6.0.2 and ppx_deriving_yojson.3.8.0
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-deriving-6-0-2-and-ppx-deriving-yojson-3-8-0/14750/1>
Nathan Rebours announced
────────────────────────
I am happy to announce the release of ppx_deriving.6.0.2 and
ppx_deriving_yojson.3.8.0, the first release of those packages in
years!
The main feature here is the port of [ppx_deriving]'s standard
derivers (`[@@deriving show, make, ord, eq, ...]') and
[ppx_deriving_yojson] to [ppxlib]'s `Deriving' api. There are no
changes to how you'd use those derivers but many benefits:
• Better performances and better integration with other ppx-es as the
code is now generated as part of ppxlib's driver main AST rewriting
phase rather than in a separate, dedicated phase.
• They can now be used with `[@@deriving_inline]'
• None of them will break the location invariant required by merlin
anymore, fixing a long lasting bug and providing a much better user
experience.
You can find the full release notes for ppx_deriving [here] and for
ppx_deriving_yojson [here].
I'd like to thank @sim642 for all their work on the ppxlib ports and
their patience, and all our other contributors.
I'd also like to thank the [OCaml Software Foundation] who has been
funding my work on those releases.
[ppx_deriving] <https://github.com/ocaml-ppx/ppx_deriving>
[ppx_deriving_yojson] <https://github.com/ocaml-ppx/ppx_deriving_yojson>
[ppxlib] <https://github.com/ocaml-ppx/ppxlib>
[here] <https://github.com/ocaml-ppx/ppx_deriving/releases/tag/v6.0.2>
[here]
<https://github.com/ocaml-ppx/ppx_deriving_yojson/releases/tag/v3.8.0>
[OCaml Software Foundation] <https://ocaml-sf.org/>
Effective ML Through Merlin's Destruct Command
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-effective-ml-through-merlins-destruct-command/14751/1>
Xavier Van de Woestyne announced
────────────────────────────────
I'm very pleased to present you [an article] with a collection of
small illustrations and examples of how to use the `destruct' command
to generate patterns in the presence of pattern matches.
The command has been present in [Merlin] for several years (and
accessible via [OCaml-LSP]) but, as the various changelogs relating to
Merlin mention, we have spent some time polishing it and adapting it
to the evolutions of OCaml, making it more stable (essentially in the
presence of punning) and taking into account the changes made to the
representation of functions (and their parameters).
The aim of the article is to show how the `destruct' command works in
a number of very concrete cases, and ends with an example (a little
artificial for the purposes of the article and for teaching purposes)
which shows how to use `destruct' interactively.
• [ Effective ML Through Merlin's Destruct Command]: original article,
written in English, on the Tarides blog.
• [ Effective ML, au travers de la commande 'destruct']: A
French-language interpretation of the article, published on my blog.
Can't wait to hear your feedback! Happy reading!
[an article]
<https://tarides.com/blog/2024-05-29-effective-ml-through-merlin-s-destruct-command/>
[Merlin] <https://ocaml.org/p/merlin/latest>
[OCaml-LSP] <https://ocaml.org/p/lsp/latest>
[ Effective ML Through Merlin's Destruct Command]
<https://tarides.com/blog/2024-05-29-effective-ml-through-merlin-s-destruct-command/>
[ Effective ML, au travers de la commande 'destruct']
<https://xvw.lol/pages/ocaml-merlin-destruct.html>
OCaml Windows Working Group
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-windows-working-group/14755/1>
Sudha Parimala announced
────────────────────────
I’m happy to share that we’re starting a working group for OCaml
Windows. This is part of a larger effort, [First-class Windows], to
enhance the OCaml experience on Windows. Through this effort, we aim
to coordinate our collective knowledge to identify high-priority items
for First-class Windows.
We've started a mailing list to exchange ideas and would greatly
appreciate inputs. You can sign up at –
<https://groups.google.com/u/0/g/ocaml-windows-wg>
While the mailing list is intended to be the primary means of
communication, we plan to do a sync meeting once a month, to start
with. We plan to do a kick-off meeting early next week. Please fill in
this poll if you're interested to join:
<https://strawpoll.com/polls/PbZqbmkNeyN>.
Happy camling :camel:
[First-class Windows]
<https://discuss.ocaml.org/t/launching-the-first-class-windows-project/14687>
Flambda2 Ep. 2: Loopifying Tail-Recursive Functions, by OCamlPro
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-flambda2-ep-2-loopifying-tail-recursive-functions-by-ocamlpro/14758/1>
OCamlPro announced
──────────────────
Greetings Cameleers,
We would like to share with you our latest *Flambda2 Snippet*:
[Flambda2 Ep. 2: Loopifying Tail-Recursive Functions]!
Indeed, today's topic is what is called `Loopify', one of the many
optimisation algorithms found in the `Flambda2' optimising compiler
project.
We believe `Loopify' is a nicely representative piece of software for
our readers to grasp at the general design and philosophy for all
optimisations available in `Flambda2'! Hopefully, you will do too!
Be sure to check out the [`Flambda2 Ep.0'] article to get all the
context for the project itself and the series of blog posts!
In any case, we await your feedback below, and hope that you will
enjoy reading this post, and all ensuing ones!
Kind regards, The OCamlPro Team
[Flambda2 Ep. 2: Loopifying Tail-Recursive Functions]
<https://ocamlpro.com/blog/2024_05_07_the_flambda2_snippets_2>
[`Flambda2 Ep.0']
<https://ocamlpro.com/blog/2024_03_18_the_flambda2_snippets_0/>
OCaml Platform Newsletter: March-May 2024
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-platform-newsletter-march-may-2024/14765/1>
Thibaut Mattio announced
────────────────────────
Welcome to the eleventh edition of the OCaml Platform newsletter!
In this March-May 2024 edition, we are excited to bring you the latest
on the OCaml Platform, continuing our tradition of highlighting recent
developments as seen in [previous editions]. To understand the
direction we're headed, especially regarding development workflows and
user experience improvements, check out our [roadmap].
*Highlights:*
• Explorations on Dune package management have reached a
Minimal-Viable-Product (MVP) stage: a version of Dune that can build
non-trivial projects like [OCaml.org] and [Bonsai]. With a working
MVP, the team is shifting their focus to putting Dune package
management in the hands of the community. To that end, we have
started the Dune Developer Preview Program, where we will test Dune
package management with users and refine the user experience in
preparation for a final release.
• The opam team released a second beta of [opam 2.2], and with it,
opened the [final PR] to add support for Windows OCaml to the
opam-repository. Once the PR is merged, opam 2.2 will be usable with
the upstream opam-repository on Windows, paving the way for a third
beta very soon, and a Release Candidate next.
• The odoc team has finalized the initial design for Odoc 3.0 and
opened several [RFCs] to gather community input. We've implemented a
new [Odoc driver] that follows the Odoc 3.0 design and have already
started prototyping key parts of the design.
• Merlin's project-wide references query is getting very close to
release. The necessary [compiler PR] has been merged and included in
OCaml 5.2, and the [Dune rules PR] has been merged and included in
Dune 3.16. The next steps are to merge the [PR in Merlin] itself and
the small patch in OCaml LSP.
• The set of standard derivers shipped with `ppx_deriving.std'
(i.e. `[@@deriving show, make, ord, eq, ...]') as well as
`ppx_deriving_yojson' are now directly written against Ppxlib's
API. That impacts developers in two ways. First, it allows you to
enjoy reliable editor features in projects with those derivers
(Ppxlib preserves Merlin's location invariants). Second, you can
avoid a hard dependency on those derivers by using Ppxlib's
`deriving_inline' feature on them. Thanks a lot to @sim642 for all
your work and very kind patience, @NathanReb for reviewing and
release managing, and everyone else involved!
*Releases:*
• [Ppxlib 0.32.1]
• [Merlin 5.0]
• [Dune 3.14.2]
• [Dune 3.15.0]
• [Dune 3.15.2]
• [Dune 3.15.3]
• [Odoc 2.4.2]
• [opam 2.1.6]
• [opam 2.2.0~beta2]
• [ocamlformat 0.26.2]
[previous editions] <https://discuss.ocaml.org/tag/platform-newsletter>
[roadmap] <https://ocaml.org/docs/platform-roadmap>
[OCaml.org] <https://github.com/ocaml/ocaml.org>
[Bonsai] <https://github.com/janestreet/bonsai>
[opam 2.2] <https://discuss.ocaml.org/t/ann-opam-2-2-0-beta2/14461>
[final PR] <https://github.com/ocaml/opam-repository/pull/25861>
[RFCs] <https://github.com/ocaml/odoc/discussions>
[Odoc driver] <https://github.com/ocaml/odoc/pull/1121>
[compiler PR] <https://github.com/ocaml/ocaml/pull/13001>
[Dune rules PR] <https://github.com/ocaml/dune/pull/10422>
[PR in Merlin] <https://github.com/ocaml/merlin/pull/1766>
[Ppxlib 0.32.1] <https://github.com/ocaml/opam-repository/pull/25713>
[Merlin 5.0] <https://ocaml.org/changelog/2024-05-22-merlin-5.0>
[Dune 3.14.2] <https://ocaml.org/changelog/2024-03-13-dune.3.14.2>
[Dune 3.15.0] <https://ocaml.org/changelog/2024-04-03-dune.3.15.0>
[Dune 3.15.2] <https://ocaml.org/changelog/2024-04-23-dune.3.15.2>
[Dune 3.15.3] <https://ocaml.org/changelog/2024-05-26-dune.3.15.3>
[Odoc 2.4.2] <https://ocaml.org/changelog/2024-04-30-odoc-2.4.2>
[opam 2.1.6] <https://ocaml.org/changelog/2024-05-22-opam-2-1-6>
[opam 2.2.0~beta2]
<https://ocaml.org/changelog/2024-04-09-opam-2.2.0-beta2>
[ocamlformat 0.26.2]
<https://ocaml.org/changelog/2024-04-23-ocamlformat-0.26.2>
*[Dune]* Exploring Package Management in Dune ([W4])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rgrinberg (Tarides), @Leonidas-from-XIV (Tarides),
@gridbugs (Tarides), @Alizter
*Why:* Unify OCaml tooling under a single command line for all
development workflows. This addresses one of the most important pain
points [reported by the community].
*What:* Prototyping the integration of package management into Dune
using opam as a library. We're introducing a `dune pkg lock' command
to generate a lock file and enhancing `dune build' to handle
dependencies in the lock file. More details in the [Dune RFC].
*Summary:*
Over the past three months, significant progress has been made in
adding Dune's support for package management. We are thrilled to
report that our prototypes have reached a Minimal Viable Product (MVP)
stage: an experimental version of Dune package management that can be
used to build non-trivial projects, including OCaml.org and Bonsai,
which we are using in our tests.
There is still a long way to go, but with this milestone reached, we
are now shifting our focus from prototyping to putting the feature in
the hands of the community. We are moving to testing the new Dune
feature with users, and in particular, now that we have a good
understanding of the technical blockers and their workarounds, we will
be focusing on validating and refining the developer experience (DX)
of Dune package management in preparation for a first release.
To that end, the Dune team has started a Dune Developer Preview
Program. We're currently testing the Developer Preview of package
management with selected beta testers, and once the biggest issues
have been addressed, we'll be opening it to the broader community.
*Activities:*
• Continued addressing remaining issues with ocamlfind and zarith.
• Added repro PRs for ocamlfind and zarith issues –
[ocaml/dune#10233], [ocaml/dune#10235].
• Iterated on a solution for relocatable ocamlfind –
[ocaml/ocamlfind#72].
• Removed `.mml' references in ocamlfind – [ocaml/ocamlfind#75].
• Set OCAMLFIND_DESTDIR for install actions to fix ocamlfind
installation issues – [ocaml/dune#10267].
• Added a test reproducing error when locking when a pin stanza
contains a relative path outside the workspace – [ocaml/dune#10255].
• Fixed package creation issues with directories on different
filesystems – [ocaml/dune#10214].
• Opened PRs to address user errors, improve error messages, and
enhance environment handling for pkg rules – [ocaml/dune#10385],
[ocaml/ocamlbuild#327], [ocaml/dune#10403], [ocaml/dune#10407],
[ocaml/dune#10455].
• Addressed several issues related to `withenv' actions, `dune pkg
lock', and unexpected behavior with variable updates –
[ocaml/dune#10404], [ocaml/dune#10408], [ocaml/dune#10417],
[ocaml/dune#10440], [ocaml/opam#5925], [ocaml/opam#5926].
• Approved relocatable releases of ocamlfind and ocamlbuild –
[ocaml-dune/opam-overlays#1], [ocaml-dune/opam-overlays#2].
• Cleaned up and sought feedback on the relocatable ocamlfind PR –
[ocaml/ocamlfind#72].
• To work around the fact that the compiler is not relocatable (yet!),
we worked on adding support to Dune to manage compiler and developer
tools, an experimental feature we call Dune Toolchain. –
[ocaml/dune#10470], [ocaml/dune#10474], [ocaml/dune#10475],
[ocaml/dune#10476], [ocaml/dune#10477], [ocaml/dune#10478].
• Addressed various issues related to pkg lock, environment updates,
and package management – [ocaml/dune#10512], [ocaml/dune#10499],
[ocaml/dune#10498], [ocaml/dune#10531], [ocaml/dune#10521],
[ocaml/dune#10539], [ocaml/dune#10540], [ocaml/dune#10543],
[ocaml/dune#10544], [ocaml/dune#10545], [ocaml/dune#10538],
[ocaml/dune#10542], [ocaml/dune#10595], [ocaml/dune#10596],
[ocaml/dune#10592], [ocaml/dune#10593].
• Merged PRs to use unpack code for rsync URLs and disable hg/darcs
fetch code – [ocaml/dune#10556], [ocaml/dune#10561].
[W4] <https://ocaml.org/docs/platform-roadmap#w4-build-a-project>
[reported by the community]
<https://www.dropbox.com/s/omba1d8vhljnrcn/OCaml-user-survey-2020.pdf?dl=0>
[Dune RFC] <https://github.com/ocaml/dune/issues/7680>
[ocaml/dune#10233] <https://github.com/ocaml/dune/pull/10233>
[ocaml/dune#10235] <https://github.com/ocaml/dune/pull/10235>
[ocaml/ocamlfind#72] <https://github.com/ocaml/ocamlfind/pull/72>
[ocaml/ocamlfind#75] <https://github.com/ocaml/ocamlfind/pull/75>
[ocaml/dune#10267] <https://github.com/ocaml/dune/pull/10267>
[ocaml/dune#10255] <https://github.com/ocaml/dune/pull/10255>
[ocaml/dune#10214] <https://github.com/ocaml/dune/pull/10214>
[ocaml/dune#10385] <https://github.com/ocaml/dune/pull/10385>
[ocaml/ocamlbuild#327] <https://github.com/ocaml/ocamlbuild/pull/327>
[ocaml/dune#10403] <https://github.com/ocaml/dune/pull/10403>
[ocaml/dune#10407] <https://github.com/ocaml/dune/pull/10407>
[ocaml/dune#10455] <https://github.com/ocaml/dune/pull/10455>
[ocaml/dune#10404] <https://github.com/ocaml/dune/issues/10404>
[ocaml/dune#10408] <https://github.com/ocaml/dune/issues/10408>
[ocaml/dune#10417] <https://github.com/ocaml/dune/issues/10417>
[ocaml/dune#10440] <https://github.com/ocaml/dune/issues/10440>
[ocaml/opam#5925] <https://github.com/ocaml/opam/issues/5925>
[ocaml/opam#5926] <https://github.com/ocaml/opam/issues/5926>
[ocaml-dune/opam-overlays#1]
<https://github.com/ocaml-dune/opam-overlays/pull/1>
[ocaml-dune/opam-overlays#2]
<https://github.com/ocaml-dune/opam-overlays/pull/2>
[ocaml/dune#10470] <https://github.com/ocaml/dune/pull/10470>
[ocaml/dune#10474] <https://github.com/ocaml/dune/pull/10474>
[ocaml/dune#10475] <https://github.com/ocaml/dune/pull/10475>
[ocaml/dune#10476] <https://github.com/ocaml/dune/pull/10476>
[ocaml/dune#10477] <https://github.com/ocaml/dune/pull/10477>
[ocaml/dune#10478] <https://github.com/ocaml/dune/pull/10478>
[ocaml/dune#10512] <https://github.com/ocaml/dune/pull/10512>
[ocaml/dune#10499] <https://github.com/ocaml/dune/pull/10499>
[ocaml/dune#10498] <https://github.com/ocaml/dune/pull/10498>
[ocaml/dune#10531] <https://github.com/ocaml/dune/pull/10531>
[ocaml/dune#10521] <https://github.com/ocaml/dune/pull/10521>
[ocaml/dune#10539] <https://github.com/ocaml/dune/pull/10539>
[ocaml/dune#10540] <https://github.com/ocaml/dune/pull/10540>
[ocaml/dune#10543] <https://github.com/ocaml/dune/pull/10543>
[ocaml/dune#10544] <https://github.com/ocaml/dune/pull/10544>
[ocaml/dune#10545] <https://github.com/ocaml/dune/pull/10545>
[ocaml/dune#10538] <https://github.com/ocaml/dune/issues/10538>
[ocaml/dune#10542] <https://github.com/ocaml/dune/issues/10542>
[ocaml/dune#10595] <https://github.com/ocaml/dune/pull/10595>
[ocaml/dune#10596] <https://github.com/ocaml/dune/pull/10596>
[ocaml/dune#10592] <https://github.com/ocaml/dune/issues/10592>
[ocaml/dune#10593] <https://github.com/ocaml/dune/issues/10593>
[ocaml/dune#10556] <https://github.com/ocaml/dune/pull/10556>
[ocaml/dune#10561] <https://github.com/ocaml/dune/pull/10561>
*[opam]* Native Support for Windows in opam 2.2 ([W5])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rjbou (OCamlPro), @kit-ty-kate (Ahrefs), @dra27
(Tarides), @AltGr (OCamlPro)
*Why:* Enhance OCaml's viability on Windows by integrating native opam
and `opam-repository' support, fostering a larger community, and more
Windows-friendly packages.
*What:* Releasing opam 2.2 with native Windows support, making the
official `opam-repository' usable on Windows platforms.
*Summary:*
The opam team is getting closer to a final release of opam 2.2 with
support for Windows. In the past months, we have released a second
beta of opam 2.2, addressing a number of issues reported by users on
previous releases, including Windows issues.
Excitingly, we also opened the [final PR] adding support for Windows
OCaml to opam-repository. With the PR merged, the opam team is
expecting to be able to move to a Release Candidate in June.
Stay tuned for more exciting news and releases in the coming weeks and
months!
*Activities:*
• Packaging the compiler in opam-repository
• We cleared WIP items in the [windows-initial] branch, creating the
[mingw-w64-shims] repository for the C stub program and generation
script needed for the mingw-w64-shims opam package.
• Various fixes for msvs-detect were upstreamed and the opam
packaging PR finalized – [metastack/msvs-tools#17],
[metastack/msvs-tools#18].
• Initial upstreaming PRs were opened for Visual Studio
configuration – [ocaml/opam-repository#25440], reorganization of
conf-zstd – [ocaml/opam-repository#25441], and native Windows
depexts – [ocaml/opam-repository#25442].
• Fixed mccs package dependencies upstream –
[ocaml-opam/ocaml-mccs#52], [ocaml/opam-repository#25482].
• Upstreamed support for source-packaging of flexdll –
[ocaml/flexdll#135].
• Worked on packaging scripts for winpthreads for OCaml 5.3.0 –
[ocaml/winpthreads#1].
• Further upstreaming PRs were opened for mingw-w64-shims –
[ocaml/opam-repository#25454], and flexdll and winpthreads sources
packages – [ocaml/opam-repository#25512].
• Reviewed and tested changes related to the 4.14.2 release for the
sunset branch of opam-repository-mingw –
[ocaml-opam/opam-repository-mingw#20],
[ocaml-opam/opam-repository-mingw#21].
• Updated the [windows-initial] branch to support MSYS2, including
creating [msys2-opam] to complement [mingw-w64-shims].
• Upstreamed issues with the ocaml-variants.5.1.1+effect-syntax
package – [ocaml/opam-repository#25645].
• Investigated BER MetaOCaml, determining that 4.14.1+BER does not
work on Windows and disabled it in opam-repository –
[ocaml/opam-repository#25648].
• Worked further on the draft PR, addressing the issue of invalid
maintainer email addresses for packages –
[ocaml/opam-repository#25826].
• Opened the main PR for Windows compiler support –
[ocaml/opam-repository#25861], with a parallel draft PR for
updating the compiler's opam file – [ocaml/ocaml#13160].
• Backported [ocaml/ocaml#13100] to 5.1.x ocaml-variants –
[ocaml/opam-repository#25828], awaiting opam 2.2.0~beta3 release.
• Release opam 2.2
• Completed work on various patches and PRs, including fixes for
accented characters in Dune – [ocaml/opam#5861],
[ocaml/opam#5871], [janestreet/spawn#58], [ocaml/opam#5862].
• Worked on performance improvements for Windows, including adding
job statuses and a proof-of-concept for a spinner on slow-running
build jobs – [ocaml/opam#5883].
• Finalizing fix on Cygwin PATH handling for opam 2.2.0 beta2 –
[ocaml/opam#5832].
• Mark the internal cygwin installation as recommended -
[ocaml/opam#5903]
• Hijack the `%{?val_if_true:val_if_false}%' syntax to support
extending the variables of packages with + in their name -
[ocaml/opam#5840]
• Fixed issues with downloading URLs with invalid characters and
opam's internal state – [ocaml/opam#5921], [ocaml/opam#5922].
• Assembled test harnesses for `opam init' and addressed issues with
`opam lint' warnings – [dra27/opam-testing], [ocaml/opam#5927],
[ocaml/opam#5928].
• Fixed reversal of environment updates and minor issues in GitHub
Actions – [ocaml/opam#5935], [ocaml/opam#5938].
• [Released opam 2.2~beta2].
• Fixed issues related to environment variable handling –
[ocaml/opam#5935].
• Finalized fixes for Git for Windows menu – [ocaml/opam#5963].
• Minor fixes to `--cygwin-extra-packages' – [ocaml/opam#5964].
• Refactored `opam init' for a more logical experience –
[ocaml/opam#5963].
• Updated lint warning 41 PR – [ocaml/opam#5927].
• Responded to issues found by testers of Windows compiler packages
– [ocaml/flexdll#138], [ocaml/flexdll#139].
• Completely reworked `opam init' to detect Cygwin and MSYS2
installations.
• Fixed issues with the `?' operator and MSYS2's native curl
implementation – [ocaml/opam#5983], [ocaml/opam#5984].
[W5] <https://ocaml.org/docs/platform-roadmap#w5-manage-dependencies>
[final PR] <https://github.com/ocaml/opam-repository/pull/25861>
[windows-initial]
<https://github.com/dra27/opam-repository/commits/windows-initial>
[mingw-w64-shims] <https://github.com/dra27/mingw-w64-shims>
[metastack/msvs-tools#17]
<https://github.com/metastack/msvs-tools/pull/17>
[metastack/msvs-tools#18]
<https://github.com/metastack/msvs-tools/pull/18>
[ocaml/opam-repository#25440]
<https://github.com/ocaml/opam-repository/pull/25440>
[ocaml/opam-repository#25441]
<https://github.com/ocaml/opam-repository/pull/25441>
[ocaml/opam-repository#25442]
<https://github.com/ocaml/opam-repository/pull/25442>
[ocaml-opam/ocaml-mccs#52]
<https://github.com/ocaml-opam/ocaml-mccs/pull/52>
[ocaml/opam-repository#25482]
<https://github.com/ocaml/opam-repository/pull/25482>
[ocaml/flexdll#135] <https://github.com/ocaml/flexdll/pull/135>
[ocaml/winpthreads#1] <https://github.com/ocaml/winpthreads/pull/1>
[ocaml/opam-repository#25454]
<https://github.com/ocaml/opam-repository/pull/25454>
[ocaml/opam-repository#25512]
<https://github.com/ocaml/opam-repository/pull/25512>
[ocaml-opam/opam-repository-mingw#20]
<https://github.com/ocaml-opam/opam-repository-mingw/pull/20>
[ocaml-opam/opam-repository-mingw#21]
<https://github.com/ocaml-opam/opam-repository-mingw/pull/21>
[msys2-opam] <https://github.com/dra27/msys2-opam>
[ocaml/opam-repository#25645]
<https://github.com/ocaml/opam-repository/pull/25645>
[ocaml/opam-repository#25648]
<https://github.com/ocaml/opam-repository/pull/25648>
[ocaml/opam-repository#25826]
<https://github.com/ocaml/opam-repository/pull/25826>
[ocaml/opam-repository#25861]
<https://github.com/ocaml/opam-repository/pull/25861>
[ocaml/ocaml#13160] <https://github.com/ocaml/ocaml/pull/13160>
[ocaml/ocaml#13100] <https://github.com/ocaml/ocaml/pull/13100>
[ocaml/opam-repository#25828]
<https://github.com/ocaml/opam-repository/pull/25828>
[ocaml/opam#5861] <https://github.com/ocaml/opam/issues/5861>
[ocaml/opam#5871] <https://github.com/ocaml/opam/pull/5871>
[janestreet/spawn#58] <https://github.com/janestreet/spawn/pull/58>
[ocaml/opam#5862] <https://github.com/ocaml/opam/pull/5862>
[ocaml/opam#5883] <https://github.com/ocaml/opam/pull/5883>
[ocaml/opam#5832] <https://github.com/ocaml/opam/pull/5832>
[ocaml/opam#5903] <https://github.com/ocaml/opam/pull/5903>
[ocaml/opam#5840] <https://github.com/ocaml/opam/pull/5840>
[ocaml/opam#5921] <https://github.com/ocaml/opam/pull/5921>
[ocaml/opam#5922] <https://github.com/ocaml/opam/pull/5922>
[dra27/opam-testing] <https://github.com/dra27/opam-testing>
[ocaml/opam#5927] <https://github.com/ocaml/opam/pull/5927>
[ocaml/opam#5928] <https://github.com/ocaml/opam/pull/5928>
[ocaml/opam#5935] <https://github.com/ocaml/opam/pull/5935>
[ocaml/opam#5938] <https://github.com/ocaml/opam/pull/5938>
[Released opam 2.2~beta2]
<https://discuss.ocaml.org/t/ann-opam-2-2-0-beta2/14461>
[ocaml/opam#5963] <https://github.com/ocaml/opam/pull/5963>
[ocaml/opam#5964] <https://github.com/ocaml/opam/pull/5964>
[ocaml/flexdll#138] <https://github.com/ocaml/flexdll/issues/138>
[ocaml/flexdll#139] <https://github.com/ocaml/flexdll/issues/139>
[ocaml/opam#5983] <https://github.com/ocaml/opam/pull/5983>
[ocaml/opam#5984] <https://github.com/ocaml/opam/pull/5984>
*[`odoc']* Odoc 3.0: Unify OCaml.org and Local Package Documentation ([W25])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @jonludlam (Tarides), @julow (Tarides), @panglesd
(Tarides), Luke Maurer (Jane Street)
*Why:* Improving local documentation generation workflow will help
package authors write better documentation for their packages, and
consolidating the different `odoc' documentation generators will help
make continuous improvements to `odoc' available to a larger
audience.
*What:* We will create conventions that drivers must follow to ensure
that their output will be functional. Once established, we will
update the Dune rules to follow these rules, access new `odoc'
features (e.g., source rendering), and provide similar
functionalities to docs.ocaml.org (a navigational sidebar, for
instance). This will effectively make Dune usable to generate
OCaml.org package documentation.
*Summary:*
The Odoc team has made significant progress on the upcoming Odoc
3.0. We held productive in-person meetings in Paris to discuss crucial
design aspects such as the CLI, source code rendering, and
references. These discussions led to the publications of RFCs for the
various components of the design specification.
We also started implementing a new Odoc driver that adheres to the new
design for testing purposes, and began prototyping several of the new
features.
While discussions on the RFCs and specific features are still ongoing,
we are very excited to have a solid set of design specifications under
community review and to have begun implementing key parts of the new
design.
*Activities:*
• Investigated package name/library name mismatches and module name
clashes – [jonludlam/2997e905a468bfa0e625bf98b24868e5],
[jonludlam/0a5f1391ccbb2d3040318b154da8593a].
• Continued work on odoc 3.0 design, including meetings and
discussions, culminating in the publication of the RFC –
[ocaml/odoc/discussions/1097].
• Worked on the navigation PR, added functionalities, fixed bugs, and
completed the rebase – [ocaml/odoc#1088].
• Met in Paris to discuss the odoc 3.0 design, covering topics such as
CLI, rendering source code, and references.
• Opened a PR with basic support for markdown in standalone pages –
[ocaml/odoc#1110].
• Published the current proposal for assets as a discussion –
[ocaml/odoc#1113].
• Continued discussions on Markdown rendering and asset references -
[ocaml/odoc#1110].
• Implemented a new driver for testing the odoc 3.0 implementation –
[ocaml/odoc#1121], [ocaml/odoc#1128].
• Worked on implementing the –parent-id flag part of the Odoc 3.0 spec
– [ocaml/odoc#1126].
• Worked on implementing the `-L' and `-P' flags [ocaml/odoc#1132]
[W25]
<https://ocaml.org/docs/platform-roadmap#w25-generate-documentation>
[jonludlam/2997e905a468bfa0e625bf98b24868e5]
<https://gist.github.com/jonludlam/2997e905a468bfa0e625bf98b24868e5>
[jonludlam/0a5f1391ccbb2d3040318b154da8593a]
<https://gist.github.com/jonludlam/0a5f1391ccbb2d3040318b154da8593a>
[ocaml/odoc/discussions/1097]
<https://github.com/ocaml/odoc/discussions/1097>
[ocaml/odoc#1088] <https://github.com/ocaml/odoc/pull/1088>
[ocaml/odoc#1110] <https://github.com/ocaml/odoc/pull/1110>
[ocaml/odoc#1113] <https://github.com/ocaml/odoc/discussions/1113>
[ocaml/odoc#1121] <https://github.com/ocaml/odoc/pull/1121>
[ocaml/odoc#1128] <https://github.com/ocaml/odoc/pull/1128>
[ocaml/odoc#1126] <https://github.com/ocaml/odoc/pull/1126>
[ocaml/odoc#1132] <https://github.com/ocaml/odoc/pull/1132>
*[Merlin]* Support for Project-Wide References in Merlin ([W19])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @vds (Tarides), @Ekdohibs (OCamlPro), @Octachron
(INRIA), @gasche (INRIA), @emillon (Tarides), @rgrinberg (Jane
Street), @Julow (Tarides)
*Why:* Enhance code navigation and refactoring for developers by
providing project-wide reference editor features, aligning OCaml with
the editor experience found in other languages.
*What:* Introducing `ocamlmerlin server occurrences' and LSP
`textDocument/references' support, extending compiler's Shapes for
global occurrences and integrating these features in Dune, Merlin,
and OCaml LSP.
*Summary:*
The past few months have seen fantastic progress on releasing Merlin's
project-wide reference query: The compiler PR got merged and included
in the now released OCaml 5.2; The Dune rules PR got merged, and with
it significant performance improvements have been made on the indexing
tool. The [final PR] in Merlin is open and under review. That PR as
well as the small LSP patch to support the feature are about to be
merged.
The PR on Merlin also adds support for the feature in the Merlin
server plug-in for Emacs. Support for the Merlin server plug-in for
Vim has been added separately. All editor plug-ins based on LSP will
support the new feature automatically.
*Activities:*
• We followed up on our compiler PR to improve performance for shape
aliases weak reduction. It got merged, and made it into OCaml
5.2.0. – [ocaml/ocaml#13001]
• We improved the Dune rules that drive the indexer: Simplified the
rules, added benchmarks, discussed and improved performance. The PR
got merged, and made it into Dune 3.16. - [ocaml/dune#10422]
• We polished the indexer `ocaml-index': Profiled it and improved its
speed by a factor ~2, and improved its CLI.
• We added a `:MerlinOccurrencesProjectWide' command to the Vim
plug-in based on the Merlin server - [ocaml/merlin#1767]
[W19] <https://ocaml.org/docs/platform-roadmap#w19-navigate-code>
[final PR] <https://github.com/ocaml/merlin/pull/1766>
[ocaml/ocaml#13001] <https://github.com/ocaml/ocaml/pull/13001>
[ocaml/dune#10422] <https://github.com/ocaml/dune/pull/10422>
[ocaml/merlin#1767] <https://github.com/ocaml/merlin/pull/1767>
OCaml.org Newsletter: May 2024
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-org-newsletter-may-2024/14767/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the May 2024 edition of the OCaml.org newsletter! This
update has been compiled by the OCaml.org team. You can find [previous
updates] on Discuss.
Our goal is to make OCaml.org the best resource for anyone who wants
to get started and be productive in OCaml. The OCaml.org newsletter
provides an update on our progress towards that goal and an overview
of the changes we are working on.
We couldn't do it without all the amazing people who help us review,
revise, and create better OCaml documentation and work on issues. Your
participation enables us to so much more than we could just by
ourselves. Thank you!
This newsletter covers:
• *Recipes for the OCaml Cookbook:* Help us make the OCaml Cookbook
really useful by contributing and reviewing recipes for common
tasks!
• *Community & Marketing Pages Rework:* We have UI designs for the
reworked and new pages of the community section and are starting to
implement these. We made progress towards showing videos from the
community on the OCaml Planet.
• *General Improvements:* As usual, we also worked on general
maintenance and improvements, so we're highlighting some of the
work that happened below.
[previous updates] <https://discuss.ocaml.org/tag/ocamlorg-newsletter>
Open Issues for Contributors
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
You can find [open issues for contributors here]!
Here are some (as of writing this newsletter) open issues:
• [Running OCaml Receipes in repl.it #2456]
• [Use uucp caselesseq instead of structural equality and
String.ascii_lowercase #2444]
• [OG images for OCaml Packages #1786]
[open issues for contributors here]
<https://github.com/ocaml/ocaml.org/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+no%3Aassignee>
[Running OCaml Receipes in repl.it #2456]
<https://github.com/ocaml/ocaml.org/issues/2456>
[Use uucp caselesseq instead of structural equality and
String.ascii_lowercase #2444]
<https://github.com/ocaml/ocaml.org/issues/2444>
[OG images for OCaml Packages #1786]
<https://github.com/ocaml/ocaml.org/issues/1786>
Recipes for the OCaml Cookbook
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The OCaml Cookbook is a place where OCaml developers share how to
solve common tasks using packages from the ecosystem.
A recipe is a code sample and explanations on how to perform a task
using a combination of open source libraries.
The Cookbook is live at [ocaml.org/cookbook], but there are not a lot
of recipes published yet.
When the cookbook was merged, all pull requests to the cookbook branch
were automatically closed. We recreated these pull requests and they
are ready for review.
Here's how you can help:
1. Review [open pull requests for cookbook recipes]!
2. Contribute new recipes and tasks for the cookbook!
*Relevant PRs and Activities:*
• PR: Add a checklist for OCaml Cookbook recipe review
[ocaml/ocaml.org#2419] by [@sabine]
• PR: Cookbook filesystem [ocaml/ocaml.org#2399]
• PR: Cookbook networking [ocaml/ocaml.org#2400]
• PR: Cookbook xml [ocaml/ocaml.org#2401]
• PR: cookbook httpclient [ocaml/ocaml.org#2402]
• PR: cookbook uri [ocaml/ocaml.org#2403]
• PR: Cookbook regexp2 [ocaml/ocaml.org#2404]
• PR: Cookbook unzip [ocaml/ocaml.org#2405]
• PR: Cookbook linalg [ocaml/ocaml.org#2406]
• PR: Cookbook getenv [ocaml/ocaml.org#2407]
• PR: Cookbook shell [ocaml/ocaml.org#2408]
• PR: Cookbook geodesic [ocaml/ocaml.org#2409]
• PR: Add cookbooks for JSON serialisation and deserialisation
[ocaml/ocaml.org#2415] by [@gpopides]
• PR: Cookbook Encode and Decode Bytestrings from Hex-Strings
[ocaml/ocaml.org#2445] by [@ggsmith842]
[ocaml.org/cookbook] <https://ocaml.org/cookbook>
[open pull requests for cookbook recipes]
<https://github.com/ocaml/ocaml.org/pulls?q=is%3Apr+is%3Aopen+label%3ACookbook>
[ocaml/ocaml.org#2419] <https://github.com/ocaml/ocaml.org/pull/2419>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2399] <https://github.com/ocaml/ocaml.org/pull/2399>
[ocaml/ocaml.org#2400] <https://github.com/ocaml/ocaml.org/pull/2400>
[ocaml/ocaml.org#2401] <https://github.com/ocaml/ocaml.org/pull/2401>
[ocaml/ocaml.org#2402] <https://github.com/ocaml/ocaml.org/pull/2402>
[ocaml/ocaml.org#2403] <https://github.com/ocaml/ocaml.org/pull/2403>
[ocaml/ocaml.org#2404] <https://github.com/ocaml/ocaml.org/pull/2404>
[ocaml/ocaml.org#2405] <https://github.com/ocaml/ocaml.org/pull/2405>
[ocaml/ocaml.org#2406] <https://github.com/ocaml/ocaml.org/pull/2406>
[ocaml/ocaml.org#2407] <https://github.com/ocaml/ocaml.org/pull/2407>
[ocaml/ocaml.org#2408] <https://github.com/ocaml/ocaml.org/pull/2408>
[ocaml/ocaml.org#2409] <https://github.com/ocaml/ocaml.org/pull/2409>
[ocaml/ocaml.org#2415] <https://github.com/ocaml/ocaml.org/pull/2415>
[@gpopides] <https://github.com/gpopides>
[ocaml/ocaml.org#2445] <https://github.com/ocaml/ocaml.org/pull/2445>
[@ggsmith842] <https://github.com/ggsmith842>
Community & Marketing Pages Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This month, we made some progress towards adding videos from the OCaml
community (e.g., from YouTube and watch.ocaml.org) to the OCaml
Planet.
Since the size of the OCaml Planet RSS feed grew so large that
automation tools (`dlvr.it') could no longer process it, we reduced
the timeframe for posts to show up in the RSS feed to the last 90
days.
Contributor [@ishar19] opened a pull request to add an RSS feed for
the Community/Events page. This will allow posting new events to
various social media automatically and allow you to subscribe to the
Events RSS feed with a RSS reader of your choice.
We have [UI designs for the reworked and new pages of the community
section] and we are opening small issues for contributors to
help. :orange_heart:
*Relevant PRs and Activities:*
• The OCaml Planet
• PR: Community videos scraping and list page [ocaml/ocaml.org#2441]
by [@cuihtlauac]
• PR: Scrape watch.ocaml.org as an RSS feed [ocaml/ocaml.org#2428]
by [@cuihtlauac]
• PR: No longer feature posts on the OCaml Planet
[ocaml/ocaml.org#2430] by [@cuihtlauac]
• PR: Set the cutoff date for the OCaml Planet RSS feed to 90 days
[ocaml/ocaml.org#2416] by [@sabine]
• PR: Filter OCaml Planet Blog posts for "OCaml" keyword
[ocaml/ocaml.org#2443] by [@cuihtlauac]
• PR: add redirect for /blog to /ocaml-planet [ocaml/ocaml.org#2450]
by [@sabine]
• PR: Dedupe RSS feed creation logic [ocaml/ocaml.org#2461] by
[@cuihtlauac]
• Events page
• PR: Feat/events rss feed [ocaml/ocaml.org#2437] by [@ishar19]
[@ishar19] <https://github.com/ishar19>
[UI designs for the reworked and new pages of the community section]
<https://www.figma.com/file/7hmoWkQP9PgLTfZCqiZMWa/OCaml-Community-Pages?type=design&node-id=637%3A4539&mode=design&t=RpQlGvOpeg1a93AZ-1>
[ocaml/ocaml.org#2441] <https://github.com/ocaml/ocaml.org/pull/2441>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2428] <https://github.com/ocaml/ocaml.org/pull/2428>
[ocaml/ocaml.org#2430] <https://github.com/ocaml/ocaml.org/pull/2430>
[ocaml/ocaml.org#2416] <https://github.com/ocaml/ocaml.org/pull/2416>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2443] <https://github.com/ocaml/ocaml.org/pull/2443>
[ocaml/ocaml.org#2450] <https://github.com/ocaml/ocaml.org/pull/2450>
[ocaml/ocaml.org#2461] <https://github.com/ocaml/ocaml.org/pull/2461>
[ocaml/ocaml.org#2437] <https://github.com/ocaml/ocaml.org/pull/2437>
Outreachy Internship on Interactive Exercises
─────────────────────────────────────────────
On May 27, [Divyanka Chaudhari] started working with the team, as an
Outreachy intern. She's implementing support for running the exercises
as a stand-alone project, either in GitHub Codespace, in `repl.it',
using Jupyter or LearnOcaml.
*Relevant PRs and Activities:*
• PR: Fix 007 answer folder not running test cases
[ocaml/ocaml.org#2458] by [@divyankachaudhari]
## General Improvements and Data Additions
*Notable Changes:*
• We restructured the main navigation to have a "Tools" section that
holds the OCaml Platform page and the OCaml compiler releases
page. This should make the OCaml Platform page easier to find.
• The Changelog can now be found under "News", from the main
navigation. You can also find the OCaml Planet and the Newsletters
in this new section.
• The OCaml Language Manual is now served from OCaml.org, instead of
v2.ocaml.org.
• We added some more links to learning resources to the Resources page
at <https://ocaml.org/resources>.
• Some documentation updates on "Is OCaml Web Yet?", "Is OCaml GUI
Yet?", the ThreadSanitizer tutorial, and the "Functors" tutorial.
*Relevant PRs and Activities:*
• Features
• PR: Introduce a tools section for platform page, releases page,
and a news section for changelog, OCaml Planet and Newsletters
[ocaml/ocaml.org#2410] by [@sabine]
• Migration of the Language Manual from v2.ocaml.org to OCaml.org
• PR: fix: language manual redirect, remove unnecessary append of
index.html [ocaml/ocaml.org#2470] by [@sabine]
• PR: Fix: redirect to downloadable manual files
[ocaml/ocaml.org#2439] by [@sabine]
• PR: Simplify and extend /releases/ redirects from legacy
v2.ocaml.org URLs [ocaml/ocaml.org#2448] by [@cuihtlauac]
• PR: Fix #2465 [ocaml/ocaml.org#2468] by [@cuihtlauac]
• PR: Fix more redirect [ocaml/ocaml.org#2471] by [@cuihtlauac]
• Data
• PR: (data) add some learning resources [ocaml/ocaml.org#2474] by
[@sabine]
• PR: Add University of Bologna as academic institution
[ocaml/ocaml.org#2394] by [@boozec]
• PR: (data) Update ocaml.org community meeting zoom link
[ocaml/ocaml.org#2413] by [@sabine]
• PR: (data) jobs: add a XenServer position again
[ocaml/ocaml.org#2414] by [@edwintorok]
• PR: (data) add ocaml.org newsletter April 2024
[ocaml/ocaml.org#2417] by [@sabine]
• PR: OCaml 5.2.0 announce and release page [ocaml/ocaml.org#2421]
by [@Octachron]
• PR: Update OCamlPro's logo [ocaml/ocaml.org#2436] by [@hra687261]
• PR: Changelog entry for OCaml 5.2.0~rc1 [ocaml/ocaml.org#2391] by
[@Octachron]
• PR: changelog: add Dune 3.15.1 and 3.15.2 [ocaml/ocaml.org#2389]
by [@emillon]
• PR: Add changelog entry for Merlin 5.0 [ocaml/ocaml.org#2472] by
[@pitag-ha]
• Bugfixes
• PR: fix dark style of package version pages [ocaml/ocaml.org#2438]
by [@FrugBatt]
• GitHub actions CI broke due to an OpenSSL issue on MacOS
• PR: Update debug-ci.yml [ocaml/ocaml.org#2397] by [@cuihtlauac]
• PR: Update debug-ci.yml [ocaml/ocaml.org#2398] by [@cuihtlauac]
• PR: Do brew update before installing openssl@3 to fix macos CI
[ocaml/ocaml.org#2420] by [@sabine]
• PR: (ci) Restrict openssl on macos to 3.2 to see if that fixes
CI [ocaml/ocaml.org#2390] by [@sabine]
• Documentation
• PR: Explain how to avoid cyclic abbreviation error with functor
application [ocaml/ocaml.org#2457] by [@cuihtlauac]
• PR: Update tutorial “Transitioning to Multicore with
ThreadSanitizer” [ocaml/ocaml.org#2459] by [@OlivierNicole]
• PR: (docs) web.md: jsonchema->atd exists [ocaml/ocaml.org#2454] by
[@Khady]
• PR: Update is_ocaml_yet/gui.md: Plotting [ocaml/ocaml.org#2452] by
[@lukstafi]
[Divyanka Chaudhari] <https://github.com/divyankachaudhari>
[ocaml/ocaml.org#2458] <https://github.com/ocaml/ocaml.org/pull/2458>
[@divyankachaudhari] <https://github.com/divyankachaudhari>
[ocaml/ocaml.org#2410] <https://github.com/ocaml/ocaml.org/pull/2410>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2470] <https://github.com/ocaml/ocaml.org/pull/2470>
[ocaml/ocaml.org#2439] <https://github.com/ocaml/ocaml.org/pull/2439>
[ocaml/ocaml.org#2448] <https://github.com/ocaml/ocaml.org/pull/2448>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2468] <https://github.com/ocaml/ocaml.org/pull/2468>
[ocaml/ocaml.org#2471] <https://github.com/ocaml/ocaml.org/pull/2471>
[ocaml/ocaml.org#2474] <https://github.com/ocaml/ocaml.org/pull/2474>
[ocaml/ocaml.org#2394] <https://github.com/ocaml/ocaml.org/pull/2394>
[@boozec] <https://github.com/boozec>
[ocaml/ocaml.org#2413] <https://github.com/ocaml/ocaml.org/pull/2413>
[ocaml/ocaml.org#2414] <https://github.com/ocaml/ocaml.org/pull/2414>
[@edwintorok] <https://github.com/edwintorok>
[ocaml/ocaml.org#2417] <https://github.com/ocaml/ocaml.org/pull/2417>
[ocaml/ocaml.org#2421] <https://github.com/ocaml/ocaml.org/pull/2421>
[@Octachron] <https://github.com/Octachron>
[ocaml/ocaml.org#2436] <https://github.com/ocaml/ocaml.org/pull/2436>
[@hra687261] <https://github.com/hra687261>
[ocaml/ocaml.org#2391] <https://github.com/ocaml/ocaml.org/pull/2391>
[ocaml/ocaml.org#2389] <https://github.com/ocaml/ocaml.org/pull/2389>
[@emillon] <https://github.com/emillon>
[ocaml/ocaml.org#2472] <https://github.com/ocaml/ocaml.org/pull/2472>
[@pitag-ha] <https://github.com/pitag-ha>
[ocaml/ocaml.org#2438] <https://github.com/ocaml/ocaml.org/pull/2438>
[@FrugBatt] <https://github.com/FrugBatt>
[ocaml/ocaml.org#2397] <https://github.com/ocaml/ocaml.org/pull/2397>
[ocaml/ocaml.org#2398] <https://github.com/ocaml/ocaml.org/pull/2398>
[ocaml/ocaml.org#2420] <https://github.com/ocaml/ocaml.org/pull/2420>
[ocaml/ocaml.org#2390] <https://github.com/ocaml/ocaml.org/pull/2390>
[ocaml/ocaml.org#2457] <https://github.com/ocaml/ocaml.org/pull/2457>
[ocaml/ocaml.org#2459] <https://github.com/ocaml/ocaml.org/pull/2459>
[@OlivierNicole] <https://github.com/OlivierNicole>
[ocaml/ocaml.org#2454] <https://github.com/ocaml/ocaml.org/pull/2454>
[@Khady] <https://github.com/Khady>
[ocaml/ocaml.org#2452] <https://github.com/ocaml/ocaml.org/pull/2452>
[@lukstafi] <https://github.com/lukstafi>
OCaml Windows Working Group
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-windows-working-group/14755/3>
Deep in this thread, Sudha Parimala announced
─────────────────────────────────────────────
Thanks to everyone who joined the meeting! Please find the notes here:
<https://docs.google.com/document/d/1tt-g5f441ClvdGJuK8fvO9Eu2YvWMwDF1wbZ2f8-gsI/edit#heading=h.kwwpagbnenby>.
The meeting time this time wasn't US time-zone friendly. We'll try to
find a time that works for more people next time.
Registration for Fun OCaml 2024 Opens Shortly
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/registration-for-fun-ocaml-2024-opens-shortly/14771/1>
Sabine Schmaltz announced
─────────────────────────
Registration for Fun OCaml 2024 will open shortly at 17:00 CEST
(Central European Summer Time) UTC/GMT +2 hours
Please put yourself on the waiting list if you don't get a ticket
immediately, we're doing this in a staggered fashion, unlocking more
tickets over the next days! 🧡🐫
<https://fun-ocaml.com>
opam 2.2.0~beta3
════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-2-0-beta3/14772/1>
Kate announced
──────────────
We’re once again very excited to announce this third and final beta
for opam 2.2.0.
What’s new in this beta?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• *opam init on Windows enhancements*: this beta greatly improves the
`opam init' user experience on Windows, and the number of
recognised configurations
• *opam init –cygwin-extra-packages=\<pkgs\>*: a new argument to
specify additional packages for the internal Cygwin installation
• *Support of user directories containing spaces*: opam now redirects
the opam root to `C:\opamroot\opam-xxx' when the opam root contains
spaces on Windows
• *UTF-8 paged –help on Windows* thanks to cmdliner 1.3.0 and some
additional Windows API calls, all the `opam --help' commands now
display a paged view by default similar to Unix-like systems.
• Many *fixes*, *performance* and general *improvements*
:open_book: You can read our [blog post] for more information about
these changes and more, and for even more details you can take a look
at the [release note] or the [changelog].
[blog post] <https://opam.ocaml.org/blog/opam-2-2-0-beta3/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.2.0-beta3>
[changelog] <https://github.com/ocaml/opam/blob/2.2.0-beta3/CHANGES>
Windows issues
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Configuration of Windows is tricky, so please don’t be too
disheartened if things don’t work instantly. If something doesn’t work
first time, [please do report it], even if you manage to find a way to
workaround it. If opam didn’t elegantly tell you what was wrong, then
it’s a bug and we’d love to hear about it, rather than ending up with
a series of workarounds flying around. It’s no problem at all for us
to receive a bug report which turns out to be user error - we’d far
rather that than not hear bugs which are opam’s error! 🙀
[please do report it] <https://github.com/ocaml/opam/issues>
How to upgrade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ On Windows
*BEWARE*: the command shown below is *experimental, use caution* and
please do report any issues that you are experiencing. If you prefer
to not use our experimental script, feel free to get the Windows
binary directly from [the Release Page] and put it in your directory
of choice instead.
Now that the [Windows support was merged in opam-repository],
installing opam is as simple as calling the following command from a
PowerShell terminal:
┌────
│ Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/kit-ty-kate/opam/windows-installer/shell/install.ps1) }"
└────
opening a new terminal, and a simple `opam init' will work
out-of-the-box.
[the Release Page]
<https://github.com/ocaml/opam/releases/tag/2.2.0-beta3>
[Windows support was merged in opam-repository]
<https://github.com/ocaml/opam-repository/pull/25861>
◊ On Unix-like systems
To upgrade, simply run:
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.2.0~beta3"
└────
We’re planning for an opam 2.2.0~rc1 release later next week, so
please do report any issue you encounter on our [bug-tracker].
[bug-tracker] <https://github.com/ocaml/opam/issues>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Release of Frama-C 29.0 (Copper)]
• [Secure From the Ground Up: Introducing the FIDES Project Combining
RISC-V and MirageOS]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Release of Frama-C 29.0 (Copper)]
<https://frama-c.com/fc-versions/copper.html>
[Secure From the Ground Up: Introducing the FIDES Project Combining
RISC-V and MirageOS]
<https://tarides.com/blog/2024-06-05-secure-from-the-ground-up-introducing-the-fides-project-combining-risc-v-and-mirageos>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 70117 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-06-04 13:26 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-06-04 13:26 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 21780 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 28 to June 04,
2024.
Table of Contents
─────────────────
v0.17 release of Jane Street packages
jsonschema2atd, Generate an ATD file from a JSON Schema / OpenAPI document
opam-repository policy change: checksums (no md5) and no extra-files
Camlkit – macOS/iOS/GNUstep toolkit for OCaml
position for MoonBit advocate
Why is there no tradition of CLI and TUI apps?
Ppxlib dev meetings
Yojson 2.2.0
Grace 0.2.0 💅, fancy diagnostics library for compilers
First release of Slipshow on opam!
Other OCaml News
Old CWN
v0.17 release of Jane Street packages
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-v0-17-release-of-jane-street-packages/14717/1>
Diana Kalinichenko announced
────────────────────────────
*v0.17 release of Jane Street packages*
Dear OCaml developers,
We are pleased to announce the v0.17 release of Jane Street packages!
This release comes with 15 new packages and a multitude of new
features and fixes.
Switch to OCaml 5.1
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We are switching Base and all our packages (except `sexplib0') to
OCaml 5.1 and above. We are also switching `sexplib0' to 4.14 to take
advantage of the Tail Recursion Modulo Cons optimization in the
compiler.
Core on OCaml 5.2
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Due to some changes to `Stdlib.Gc' in OCaml 5.2, `core.v0.17.0' fails
to compile with that language version. We will release a fix that
allows using Core with OCaml 5.2 soon.
Torch and VCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Due to some issues with their builds, `torch.v0.17.0' and
`vcaml.v0.17.0' were omitted from the main v0.17 release. We will soon
submit those packages to opam.
Changes
╌╌╌╌╌╌╌
Browse our [GitHub repositories] and look at the respective
`CHANGES.md' files for changes since the v0.16 release. For examples,
see changelogs for [Base], [Async_kernel], and [Bonsai].
[GitHub repositories] <https://github.com/janestreet>
[Base] <https://github.com/janestreet/base/blob/master/CHANGES.md>
[Async_kernel]
<https://github.com/janestreet/async_kernel/blob/master/CHANGES.md>
[Bonsai] <https://github.com/janestreet/bonsai/blob/master/CHANGES.md>
New packages
╌╌╌╌╌╌╌╌╌╌╌╌
[async_log] – a logging library for Async code, moved from
`async_unix'
[capitalization] – a library for case conventions and renaming
identifiers
[codicons] – icons from VS Code for use with Bonsai
[gel] – a library to mark non-record fields global for use with our
compiler extensions
[hardcaml_event_driven_sim] – a simulator library for Hardcaml
[ocaml_intrinsics_kernel] – a split from `ocaml_intrinsics' compatible
with javascript
[ocaml_openapi_generator] – an OpenAPI 3 to OCaml client generator
[ppx_diff] – a ppx for generation of diffs and update functions for
OCaml types.
[ppx_embed_file] – a ppx that allows embedding files directly into
executables/libraries as strings or bytes
[ppxlib_jane] – utilities for working with Jane Street AST constructs
[ppx_quick_test] – a ppx providing an ergonomic wrapper for quickcheck
tests, similar to `ppx_inline_test'
[ppx_string_conv] – deriving `to_string~and ~of_string'
[uopt] – unsafe option type that does not allocate, moved from
`core_kernel'
[versioned_polling_state_rpc] – helper functions for versioned
`Polling_state_rpc.t'
[virtual_dom_toplayer] – bindings for the `floating_positioning'
javascript library
[async_log] <https://github.com/janestreet/async_log>
[capitalization] <https://github.com/janestreet/capitalization>
[codicons] <https://github.com/janestreet/codicons>
[gel] <https://github.com/janestreet/gel>
[hardcaml_event_driven_sim]
<https://github.com/janestreet/hardcaml_event_driven_sim>
[ocaml_intrinsics_kernel]
<https://github.com/janestreet/ocaml_intrinsics_kernel>
[ocaml_openapi_generator]
<https://github.com/janestreet/ocaml_openapi_generator>
[ppx_diff] <https://github.com/janestreet/ppx_diff>
[ppx_embed_file] <https://github.com/janestreet/ppx_embed_file>
[ppxlib_jane] <https://github.com/janestreet/ppxlib_jane>
[ppx_quick_test] <https://github.com/janestreet/ppx_quick_test>
[ppx_string_conv] <https://github.com/janestreet/ppx_string_conv>
[uopt] <https://github.com/janestreet/uopt>
[versioned_polling_state_rpc]
<https://github.com/janestreet/versioned_polling_state_rpc>
[virtual_dom_toplayer]
<https://github.com/janestreet/virtual_dom_toplayer>
jsonschema2atd, Generate an ATD file from a JSON Schema / OpenAPI document
══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-jsonschema2atd-generate-an-atd-file-from-a-json-schema-openapi-document/14718/1>
Louis Roché announced
─────────────────────
Ahrefs has released jsonschema2atd, a cli tool to convert an OpenAPI
or Json Schema specification into an atd file.
Quite a lot of api out there are now publishing some kind of spec for
their expected input our output. It's often done through a a JSON
Schema or OpenAPI document. The goal of this tool is to save time for
large api by doing a mechanical translation to an atd file instead of
writing all the types by hand.
Unfortunately the world is kind of a mess. Most of the specs we have
seen are not following a specific version of openapi/jsonschema but
contain a bit of everything. jsonschema2atd does its best to do the
right thing, but there are probably cases that aren't covered.
The generated code might also not be optimal. It often deserves some
hand cleanup and a bit of renaming. Hopefully it still gives a good
head start.
Thanks to [Egor Chemokhonenko] for this work.
The code is available at <https://github.com/ahrefs/jsonschema2atd>
And there is a package that is published on opam
<https://ocaml.org/p/jsonschema2atd/latest>
[Egor Chemokhonenko] <https://github.com/ixzzd>
opam-repository policy change: checksums (no md5) and no extra-files
════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-opam-repository-policy-change-checksums-no-md5-and-no-extra-files/14720/1>
Hannes Mehnert announced
────────────────────────
Dear everyone,
the opam-repository policy just changed to *not accept md5-only
checksums*, and also to *avoid extra-files* in packages (use
extra-source instead).
NOTE:
╌╌╌╌╌
If you encounter issues during `opam update', please make sure to have
`opam 2.1.6' installed, and `gpatch' (especially on BSD systems and
macOS). This may break silently, if you encounter issues, please `rm
-rf ~/.opam/repo/default && opam update default' See further notes in
<https://github.com/ocaml/opam-repository/issues/25961>
What has been achieved?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• A new lint check that errors on md5-only checksum specification has
been put into place
<https://github.com/ocurrent/opam-repo-ci/pull/304>
• A new lint check that errors if `extra-files' is present
<https://github.com/ocurrent/opam-repo-ci/pull/313>
• The existing `extra-files', bundled in the opam-repository, have
been moved to opam-source-archives
(<https://github.com/ocaml/opam-source-archives/pull/28>)
• The opam files in the opam-repository were changed to use
extra-source with the opam-source-archives repository
<https://github.com/ocaml/opam-repository/commit/76eb35c8a78a891c7e5e27b5c32316d7add1f52d>
• All existing (and available) packages using only md5 have been
upgraded to use sha256 as well
(<https://github.com/ocaml/opam-repository/commit/ea87c49e51ff29a459422419e1688938fd77a46f>)
• See the PR for the full changes
<https://github.com/ocaml/opam-repository/pull/25960>
• See discussion at
<https://github.com/ocaml/opam-repository/issues/25876>
These changes were automated using `opam admin migrate-extrafiles' and
`opam admin add-hashes' (using the branch
<https://github.com/hannesm/opam/tree/migrate-extra-files>). There is
a utility to check that existing files and md5 checksums are still
present in the new opam-repository
<https://github.com/hannesm/opam-check-checksum>.
Impact on users and developers
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• A lot of packages will want to be recompiled on `opam upgrade'
(since checksum changed, extra-files/extra-source was modified) –
sorry for the extensive use of CPU time
• If you need to include a patch or an extra file for your opam
package, you will need to host it elsewhere. You can host it using a
gist (<https://gist.github.com>), or on your server. All the
`extra-source' will be cached by `opam.ocaml.org'.
The reasoning for this change
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Apart from making the mental model of "how does opam-repository work"
easier (since there's no more any `files' subdirectory which includes
files that are added during the build), it also makes the approach to
cryptographically sign the repository much smoother (since we can now
rely on non-weak hash algorithms and don't need to compute more
hashes, and not need to add further hashes to the repository).
We needed to get both (weak hashes AND removing extra-files) through
at some point, it has been done today.
Camlkit – macOS/iOS/GNUstep toolkit for OCaml
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-camlkit-macos-ios-gnustep-toolkit-for-ocaml/14722/1>
borisd announced
────────────────
I am pleased to announce the alpha release of [Camlkit]. Camlkit
provides OCaml bindings to a collection of Cocoa frameworks on macOS,
iOS, and GNUstep. Currently available are Foundation, AppKit, UIKit,
WebKit, CoreImage, Photos, and Vision.
The package `camlkit' for macOS/GNUstep development is available from
OPAM. The key libraries to add to your dune file are
`camlkit-base.foundation' and `camlkit-gui.appkit'.
iOS development requires a [cross-toolchain]. The package is named
`camlkit-ios'. UIKit is in the library `camlkit-gui.uikit'.
Other useful resources:
• [a starter project template for iOS]
• [a few example porgrams]
More information is available on the [project's github page]. Feedback
and contributions are welcome. I hope we can make OCaml viable for GUI
development and on mobile. Happy hacking!
[Camlkit] <https://github.com/dboris/camlkit>
[cross-toolchain] <https://github.com/ocaml-cross/opam-cross-ios>
[a starter project template for iOS]
<https://github.com/dboris/camlkit-starter-nostoryboard>
[a few example porgrams] <https://github.com/dboris/camlkit-examples/>
[project's github page] <https://github.com/dboris/camlkit>
position for MoonBit advocate
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-part-time-position-for-moonbit-advocate/14726/1>
Hongbo Zhang announced
──────────────────────
MoonBit is ML language inspired by Rust, Go and OCaml, it was
announced with a [Wasm backend], and recently we added a [JavaScript
backend], we plan to ship a native backend this year.
It is similar to OCaml, the main difference is that we have traits,
zero-cost generics and modern tooling support. You are welcome to DM
for more details.
[Wasm backend] <https://www.moonbitlang.com/blog/first-announce>
[JavaScript backend] <https://www.moonbitlang.com/blog/js-support>
Why is there no tradition of CLI and TUI apps?
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/why-is-there-no-tradition-of-cli-and-tui-apps/14628/17>
Deep in this thread, Jazz announced
───────────────────────────────────
I once created a command-line bookmarking tool called [Favemarks] in
OCaml using Janestreet's Core Command.
[Favemarks] <https://github.com/nyinyithann/favemarks>
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/23>
Continuing this thread, Patrick Ferris announced
────────────────────────────────────────────────
The [meeting notes are now available from the last meeting].
Thanks to everyone who attended the meeting. The next meeting is set
for [date=2024-06-18 time=17:00:00 timezone="Europe/London"], if that
changes we'll post to this thread. Hope to see you there!
[meeting notes are now available from the last meeting]
<https://github.com/ocaml-ppx/ppxlib/wiki/Dev-Meeting-2024-05-28>
Yojson 2.2.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-yojson-2-2-0/14737/1>
Marek Kubica announced
──────────────────────
Hello fellow Camel-wranglers,
It's my pleasure to announce the release of Yojson 2.2.0 which you can
find in your neighborhood [opam-repository].
The most important highlights include:
• [JSON5] support. Getting annoyed by dangling commas being a problem
or the inability to use comments? JSON5 is basically JSON but with
the object syntax of ECMAScript 5.1 which allows some additional
features like unquoted keys, dangling commas or well, comments. This
has been in the works for years but finally made it to the
finish-line. The new JSON5 parser requires `sedlex' and at least
OCaml 4.08, thus it is part of the [yojson-five] package. Its usage
mimics the `Yojson' package; there exist both `Basic' and `Safe'
variants and the AST matches the JSON variants.
• No CPPO dependency anymore. Given the large amount of
reverse-dependencies on Yojson, each dependency of Yojson is going
to be a dependency of a lot of packages, thus keeping the dependency
cone small makes everything (slightly) faster. As such, instead of
using CPPO as a compile-time dependency we now use [µCPPO] as a
light-weight alternative. µCPPO is meant for embedding as part of
the build process and supports a tiny subset of what CPPO supports
but without an extra package.
Happy de- and encoding!
[opam-repository] <https://ocaml.org/p/yojson/2.2.0>
[JSON5] <https://json5.org/>
[yojson-five] <https://ocaml.org/p/yojson-five/2.2.0>
[µCPPO] <https://github.com/Leonidas-from-XIV/mucppo>
Grace 0.2.0 💅, fancy diagnostics library for compilers
═══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-grace-0-2-0-fancy-diagnostics-library-for-compilers/14741/1>
"Alistair O'Brien announced
───────────────────────────
I'm excited to announce the release of [grace 0.2.0], an OCaml library
for building, reporting and rendering beautiful compiler diagnostics
:camel: :paintbrush:. Now available on [opam-repository].
The three main features of this release include:
• :books: *UTF8 support*: Source files can now contain Unicode
characters, including emojis ⚡️ 🌈 🚀, with proper rendering of
ASCII art for errors.
• :1234: *Error Codes*: Diagnostics can now include short, searchable
error codes. Allowing compilers to integrate a [Rust-like error code
index].
• 🤏 *Compact ANSI Errors*: `Grace_ansi_renderer' now supports a
`pp_compact_diagnostic' for concise error messages, displaying only
the file location and the error message.
<https://global.discourse-cdn.com/business7/uploads/ocaml/original/2X/3/31ba975d2cf17966eb4533c1f6ba441731686d0d.png>
Tap into the power of Grace for your error reporting! Happy hacking
👨💻
[grace 0.2.0] <https://github.com/johnyob/grace/releases/tag/0.2.0>
[opam-repository] <https://github.com/ocaml/opam-repository/pull/25956>
[Rust-like error code index]
<https://doc.rust-lang.org/error_codes/error-index.html>
CHANGES:
╌╌╌╌╌╌╌╌
• fix(renderer): remove uncessary underlines when printing a unique
'multi-line `Top' marker' ([#31])
• fix(renderer): replace unicode chars with ASCII in `Config.ascii'
([#27])
• feat(renderer): add `NO_COLOR' and `TERM' support to `Config' ([#8])
• feat(core,renderer): add support for error codes ([#30])
• feat(renderer): add support for UTF8 encoding ([#25])
• feat(renderer): re-introduce support for compact diagnostic
rendering ([#28])
• refactor(renderer)!: move `grace.renderer' library to
`grace.ansi_renderer' ([#29])
[#31] <https://github.com/johnyob/grace/pull/31>
[#27] <https://github.com/johnyob/grace/pull/27>
[#8] <https://github.com/johnyob/grace/pull/8>
[#30] <https://github.com/johnyob/grace/pull/30>
[#25] <https://github.com/johnyob/grace/pull/25>
[#28] <https://github.com/johnyob/grace/pull/28>
[#29] <https://github.com/johnyob/grace/pull/29>
BREAKING CHANGE
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• `Grace_rendering' has been removed. Use `Grace_ansi_renderer'
instead.
First release of Slipshow on opam!
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-slipshow-on-opam/14743/1>
Paul-Elliot announced
─────────────────────
It is my pleasure to announce the first [release] of [slipshow] on
`opam'.
Slipshow is a presentation tool to create presentation that are not
based on slides, but on more continuous transitions, similar to
scrolling.
<https://raw.githubusercontent.com/panglesd/slipshow/master/slip_scroll.gif>
You can find more information and examples on the [project repo] and
on the [documentation].
How is that related to the OCaml community? While the
"runtime"/"engine" is still written in javascript (I did not know
OCaml back then, but there is a [plan] to rewrite it), the compiler is
written in OCaml! And I am really grateful for the many authors of
open source libraries, of very high quality, that I depend on and
could do nothing without them :) **Thanks a lot** to all OCaml library
and tool authors!
┌────
│ $ opam update
│ $ opam install slipshow
│ # create and open ~source.md~ in your editor
│ $ slipshow --serve source.md
└────
Hope it can be useful :D
[release]
<https://github.com/ocaml/opam-repository/pull/25948#issuecomment-2146906766>
[slipshow] <https://github.com/panglesd/slipshow>
[project repo] <https://github.com/panglesd/slipshow>
[documentation] <https://slipshow.readthedocs.io>
[plan] <https://github.com/panglesd/slipshow/issues/32>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Effective ML Through Merlin's Destruct Command]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Effective ML Through Merlin's Destruct Command]
<https://tarides.com/blog/2024-05-29-effective-ml-through-merlin-s-destruct-command>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35137 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-05-28 9:07 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-05-28 9:07 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 17792 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 21 to 28,
2024.
Table of Contents
─────────────────
odoc Documentation Improvements
Using OCaml on windows with WSL
binsec 0.9.1
UDP multicast examples using async and lwt
opam 2.1.6
Getting OCaml Through the Eye of a Needle
Merlin 5.0-502
Launching the First-Class Windows Project
Chennai OCaml meetup: June 2024
Caper 1.0
Ppxlib dev meetings
Tarides GitHub Sponsorship Page – Supporting the OCaml Community Together
Other OCaml News
Old CWN
odoc Documentation Improvements
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/odoc-documentation-improvements/14674/1>
Christine announced
───────────────────
The `odoc' team is working to improve [the documentation], so we're
reaching out to the community to find out these things:
• Are you using `odoc'? If so, how do you use it? What are your
thoughts?
• What parts of the documentation have been helpful?
• What's missing?
• What suggestions do you have for improvement?
• What are you pain points for either/both the documentation or the
tool itself?
Your input is more valuable than I can express. Looking forward to
your answers!
[the documentation] <https://ocaml.github.io/odoc/>
Using OCaml on windows with WSL
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-using-ocaml-on-windows-with-wsl/14671/2>
Continuing this thread, Lukasz Stafiniak announced
──────────────────────────────────────────────────
I have a somewhat related blog post [How to update or install a new
Linux distribution on WSL].
[How to update or install a new Linux distribution on WSL]
<https://lukstafi.github.io/notes/WSL_install_new_distro.html>
binsec 0.9.1
════════════
Archive: <https://discuss.ocaml.org/t/ann-binsec-0-9-1/14677/1>
Frédéric Recoules announced
───────────────────────────
On behalf of the BINSEC team, I am glad to announce that version
`0.9.1' now lives in `Opam.'
As a short introduction, BINSEC is an open-source program analyzer
developed at [CEA List ] to help improve software security at the
binary level. It has been [successfully applied ] in a number of
security-related contexts, such as vulnerability finding, (malware)
deobfuscation, decompilation, formal verification of assembly code or
even binary-level formal verification.
The version `0.9' refactors the SMT solver API, enabling new kinds of
interaction (*incremental solving*) and paving the way to more support
to internal solver bindings ([bitwuzla], [bitwuzla-cxx], [z3]).
More information can be found on the [website ], including
[publications ], [tutorials ] or [contacts], but also the description
of [this release ] as well as [previous ones].
[CEA List ] <http://www-list.cea.fr/en/>
[successfully applied ] <https://binsec.github.io/achievements.html>
[bitwuzla] <https://opam.ocaml.org/packages/bitwuzla/>
[bitwuzla-cxx] <https://opam.ocaml.org/packages/bitwuzla-cxx/>
[z3] <https://opam.ocaml.org/packages/z3/>
[website ] <https://binsec.github.io/>
[publications ] <https://binsec.github.io/publications>
[tutorials ] <https://github.com/binsec/binsec/tree/master/doc>
[contacts] <https://binsec.github.io/#people>
[this release ]
<https://binsec.github.io/releases/binsec/2024/05/01/binsec-0.9.0.html>
[previous ones] <https://binsec.github.io/releases>
UDP multicast examples using async and lwt
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-udp-multicast-examples-using-async-and-lwt/14678/1>
Foxder announced
────────────────
I am very new to OCaml and have been enjoying learning the language. I
was looking for examples of simple UDP multicast senders and receivers
and could not find any great ones (please let me know if I missed
some) so I went about creating some [examples] for myself and anyone
in the future.
I created examples using both `async' and `lwt' for concurrency. If
anyone has feedback, I would gladly take it to improve on the
examples.
• [Github Project]
• [Post]
[examples] <https://github.com/KFoxder/udp_multicast_examples>
[Github Project] <https://github.com/KFoxder/udp_multicast_examples>
[Post] <https://www.kevinfox.dev/udp-multicast>
opam 2.1.6
══════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-6/14683/1>
Kate announced
──────────────
We are pleased to announce the minor release of [opam 2.1.6].
This opam release consists of backported fixes, of which the main ones
are:
• Warn users when `GNU patch' cannot be found. This is required for
opam-repository maintainers to go forward in implementing
[ocaml/opam-repository#23789] so that there are as little breakage
as possible.
• Improve depexts handling on Gentoo, NetBSD and OpenBSD.
You’ll find more information in the [release blog post].
To upgrade simply run:
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.1.6"
└────
or upgrade your distribution of choice if their opam package is
up-to-date.
[opam 2.1.6] <https://github.com/ocaml/opam/releases/tag/2.1.6>
[ocaml/opam-repository#23789]
<https://github.com/ocaml/opam-repository/issues/23789>
[release blog post] <https://opam.ocaml.org/blog/opam-2-1-6>
Getting OCaml Through the Eye of a Needle
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-getting-ocaml-through-the-eye-of-a-needle/14684/1>
Koala announced
───────────────
Over at lobste.rs there is some discussion on the following blog post:
<https://hypirion.com/musings/getting-ocaml-through-the-eye-of-a-needle>
Basically it’s about the ups and downs when using and installing Ocaml
packages. Personally, I’ve had similar experiences, but this article
is really well written. The author shows great technical knowledge and
I think he tries to be fair.
What do you think?
Discussion on lobste.rs:
<https://lobste.rs/s/nihkwe/getting_ocaml_through_eye_needle>
Merlin 5.0-502
══════════════
Archive: <https://discuss.ocaml.org/t/ann-merlin-5-0-502/14685/1>
vds announced
─────────────
We are pleased to announce the release of [merlin 5.0-502 ]!
[merlin 5.0-502 ] <https://github.com/ocaml/merlin/releases/tag/5.0-502>
Support for OCaml 5.2
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release brings official support for [OCaml 5.2]. Substantial
backend changes were required to adapt to this release, especially for
features such as occurrences and get-documentation. Do not hesitate to
report any suspicious behavior in the [issue tracker]!
[OCaml 5.2] <https://discuss.ocaml.org/t/ocaml-5-2-0-released/14638/6>
[issue tracker] <https://github.com/ocaml/merlin/issues>
Other changes
╌╌╌╌╌╌╌╌╌╌╌╌╌
This release also fixes a handful of issues:
• Destruct: Removal of residual patterns ([#1737], fixes [#1560])
• Destruct: Do not erase fields' names when destructing punned record
fields ([#1734], fixes [#1661])
• Ignore SIGPIPE in the Merlin server process ([#1746])
• Fix lexing of quoted strings in comments ([#1754], fixes [#1753])
• Improve cursor position detection in longidents ([#1756])
[#1737] <https://github.com/ocaml/merlin/pull/1737>
[#1560] <https://github.com/ocaml/merlin/issues/1560>
[#1734] <https://github.com/ocaml/merlin/pull/1734>
[#1661] <https://github.com/ocaml/merlin/issues/1661>
[#1746] <https://github.com/ocaml/merlin/pull/1746>
[#1754] <https://github.com/ocaml/merlin/pull/1754>
[#1753] <https://github.com/ocaml/merlin/issues/1753>
[#1756] <https://github.com/ocaml/merlin/pull/1756>
Launching the First-Class Windows Project
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/launching-the-first-class-windows-project/14687/1>
Sudha Parimala announced
────────────────────────
I'm excited to introduce the First-Class Windows Project, which aims
to make OCaml more accessible by enhancing the developer experience on
Windows to match that of Linux and macOS. Our goal is to create a
roadmap outlining the steps needed to fully support OCaml on Windows.
Check our blog post for details:
<https://tarides.com/blog/2024-05-22-launching-the-first-class-windows-project/>
As always, happy to receive questions and feedback.
Chennai OCaml meetup: June 2024
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/chennai-ocaml-meetup-june-2024/14695/1>
Sudha Parimala announced
────────────────────────
Hi all! We're hosting an OCaml meetup at the Tarides Chennai
offices. We have some interesting talks followed by informal
conversations over food.
@kayceesrk will be speaking about Concurrent Programming with Effect
Handlers. We have an open slot for another talk, please get in touch
if you'd like to present something.
People of all backgrounds and level of OCaml welcome. RSVP at the
following link:
<https://www.meetup.com/chennai-ocaml-meetup/events/301193020/?utm_medium=referral&utm_campaign=share-btn_savedevents_share_modal&utm_source=link>
Looking forward to seeing some of you there!
Caper 1.0
═════════
Archive: <https://discuss.ocaml.org/t/ann-caper-1-0/14696/1>
niksu announced
───────────────
[Caper] has now reached *v1.0*, some 5+ years after development first
started.
Caper is a tool for understanding and processing “pcap expressions”
(also known as /tcpdump filters/) which are used for network packet
analysis. It is entirely written in OCaml and includes pcap analysis
logic, a from-scratch BPF compiler, and conversion to/from English
expressions.
You can use Caper online through the [BPF Exam] site.
Caper’s README describes motivation, building, and usage examples, and
its CHANGELOG describes recent updates.
A huge thanks goes to Caper’s contributors. Further contributions and
feedback are welcome – a list of contribution ideas is included on
Caper’s web page.
[Caper] <http://caper.cs.iit.edu/>
[BPF Exam] <https://www.tcpdump.org/bpfexam/>
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/22>
Nathan Rebours announced
────────────────────────
Our next meeting is scheduled on Tuesday May 28th at 6:00PM CET.
I'll post the google meet link here on the day of the meeting.
In the meantime, here is the meeting agenda so far:
• 5.2 Release
‣ Released during compiler's beta, went smoothly
• 5.3 trunk support
‣ Reused the work from @hhugo and adapted it
‣ We have an open PR with 5.3 support that needs review
‣ External contributors already started adding support for new
features: @nojb added support for the effects patterns and an
internal change to location reports
‣ How to maintain trunk support on our main branch
• `ppx_deriving' and `ppx_deriving_yojson' ppxlib ports
‣ PRs open for the release of both
‣ A few bug fixes were required but it should be good to go now
• 5.2 internal AST bump
‣ Now that the 5.2 support has been released, we can discuss the
plan for this
If you'd like to bring something else up please answer in this thread
so we can add it to the agenda.
You are also welcome to attend the meeting, whether you have something
to bring to our attention, would like to contribute to the project or
are just interested in ppxlib and ppx in general.
Tarides GitHub Sponsorship Page – Supporting the OCaml Community Together
═════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tarides-github-sponsorship-page-supporting-the-ocaml-community-together/14705/1>
Thomas Gazagnaire announced
───────────────────────────
I am happy to share that [Tarides] now has a GitHub Sponsorship page,
live here [https://github.com/sponsors/tarides]! 🎉 As a part of the
vibrant OCaml community, Tarides is dedicated to supporting both the
projects and the individuals who make this ecosystem thrive.
*Why GitHub Sponsorship?*
The OCaml community is filled with many talented individual
contributors and collectives who deserve your support, such as
[Daniel], [Antonio], [Leandro], [Robur] and many others. We encourage
you to sponsor them directly to support their work.
But now, you can also sponsor [Tarides]! Creating a GitHub Sponsorship
page is an important step for us, aimed at sustaining projects that
currently lack direct, stable revenue sources. While we are thankful
for long-term sponsors such as Jane Street and Tezos, we want to
diversify our open-source funding stream to ensure the long-term
stability and sustainability of core infrastructure projects we are
working on for the community.
*What Can You Expect?*
On our sponsorship page, you’ll find detailed information about our
ongoing projects, including:
• *OCaml Compiler*: Maintaining ease of use, correctness, and
performance of the compiler(s).
• *OCaml Platform*: Ensuring core tools evolve and are compatible with
new OCaml releases.
• *OCaml.org*: Maintaining the central knowledge base for the OCaml
community.
• *Advanced Projects*: Such as MirageOS, Irmin and Eio.
Your support will directly contribute to the sustainability of these
projects and allow us to continue our work and maintain these
libraries and tools.
*How You Can Help*
We invite you to visit our [GitHub Sponsorship page] to learn more
about our projects and how you can get involved. We welcome any
suggestions or comments on how we can improve and better serve the
community.
*Commercial Support*
While this annoucement is about the ongoing maintenance of our core
open-source projects, we are also available to organize training,
develop custom extensions, or provide long-term commercial support for
these projects. [Get in touch](<mailto:contact@tarides.com>) for more
details.
Thank for your support, Thomas, on behalf of the Tarides Team
[Tarides] <https://tarides.com>
[https://github.com/sponsors/tarides]
<https://github.com/sponsors/tarides>
[Daniel] <https://github.com/sponsors/dbuenzli>
[Antonio] <https://github.com/sponsors/anmonteiro>
[Leandro] <https://github.com/sponsors/leostera>
[Robur] <https://robur.coop/Donate>
[Tarides] <https://github.com/sponsors/tarides>
[GitHub Sponsorship page] <https://github.com/sponsors/tarides>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [From Computer to Production With Nix]
• [Melange 4.0 is here]
• [Launching the First-Class Windows Project]
[the ocaml.org blog] <https://ocaml.org/blog/>
[From Computer to Production With Nix]
<https://priver.dev/blog/nix/from-computer-to-production-with-nix/>
[Melange 4.0 is here] <https://melange.re/blog/posts/melange-4-is-here>
[Launching the First-Class Windows Project]
<https://tarides.com/blog/2024-05-22-launching-the-first-class-windows-project>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30391 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-05-21 13:07 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-05-21 13:07 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 21190 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 14 to 21,
2024.
Table of Contents
─────────────────
We Want Your Feedback on the odoc Developer Experience
Windows compiler support in opam 2.2.0~beta2
OCaml Workshop 2024 at ICFP – announcement and call for proposals
Odoc syntax cheatsheet
DkCoder 0.2 - Scripting in OCaml
Imandra SysML Transpiler Internship Opportunity!
Bam - A property-based testing with internal shrinking
Stitch - Note Managing for Unorganized Minimalists
7 OCaml Gotchas
Using OCaml on windows with WSL
Other OCaml News
Old CWN
We Want Your Feedback on the odoc Developer Experience
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/we-want-your-feedback-on-the-odoc-developer-experience/14646/1>
Sabine Schmaltz announced
─────────────────────────
Hey all, 🧡🐫
the documentation team at [Tarides] is looking for input and feedback
on odoc.
I would be super happy if everyone who uses odoc or would use odoc if
it worked for them can drop an answer in this feedback form:
<https://docs.google.com/forms/d/e/1FAIpQLSfpZHlnbQjWolAhKJvn41aT5QJc7Gb7uZJSdtTT7MZeAdyMow/viewform?usp=sf_link>
[Tarides] <https://tarides.com>
Windows compiler support in opam 2.2.0~beta2
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/windows-compiler-support-in-opam-2-2-0-beta2/14648/1>
David Allsopp announced
───────────────────────
On behalf of the entire opam team, but also with a personal sense of
relief, I'm very pleased to announce that the process of upstreaming
support for Windows OCaml to opam-repository in
[ocaml/opam-repository#25861] finally started on Friday!
There's a full [blog post] with details on how you can try this out
now with opam 2.2.0~beta2. The TL;DR, assuming you have winget on your
Windows system (open the Microsoft Store app and install the [App
Installer] package from Microsoft if you don't) then you can issue:
┌────
│ winget install Git.Git
└────
if you don't have Git for Windows and:
┌────
│ winget install opam
└────
if you don't yet have the 2.2.0~beta2 binary. *You must then launch a
fresh Command Prompt / PowerShell session*. For there, you can then
run:
┌────
│ opam init git+https://github.com/dra27/opam-repository.git#windows-initial
└────
or
┌────
│ opam init -a --no-git-location --cygwin-internal-install git+https://github.com/dra27/opam-repository.git#windows-initial
└────
if you'd like to be asked fewer questions. *There is a known and big
pause when updating the repository*. However, after a little bit of
time (coffee, or [a sword battle], if that's your thing), you should
then be faced with a fully initialised opam with
ocaml-base-compiler.5.2.0 installed for the mingw-w64 amd64 port of
native Windows opam.
Things with depexts will likely not work: the blog post contains
details on how to get started with PRs, but issues are also helpful.
The blog post covers what we regard as the "default use case" - that
is a native Windows user expecting to use this new OCaml thing they
heard about natively. i.e. not running in WSL or Cygwin or MSYS2 or
any other "are you sure can't just install Linux on that?" approach.
However, all the other use cases matter too! You're meant to be able
to run native Windows opam from your own Cygwin or MSYS2 mintty bash
terminal; we are aiming for the opam 2.2.0 binary to be a drop-in
replacement (apart from setting `os-distribution' to `"cygwinports"')
for "OCaml for Windows" for legacy use with [the "sunset" repository];
you're meant to be able to provide your own Cygwin or MSYS2
installation if you really need to (and you really might!). But we do
need help testing all of it 🙂
We anticipate one further beta of opam 2.2.0 by the end of the
month. From the Windows perspective, this will fix a known bug in the
environment variable handling (see [ocaml/opam#5838]) but will also
hopefully straighten out the behaviour of `opam init' for some of
these "non-default" use cases. We're then hoping to rocket towards a
release candidate in June 🚀
Happy Windows hacking! Please open issues; please ask for further
help; please have fun!
David, on behalf of the opam team.
[ocaml/opam-repository#25861]
<https://github.com/ocaml/opam-repository/pull/25861>
[blog post] <https://opam.ocaml.org/blog/opam-2-2-0-windows/>
[App Installer] <https://apps.microsoft.com/detail/9nblggh4nns1>
[a sword battle] <https://xkcd.com/303/>
[the "sunset" repository]
<https://github.com/ocaml-opam/opam-repository-mingw>
[ocaml/opam#5838] <https://github.com/ocaml/opam/issues/5838>
OCaml Workshop 2024 at ICFP – announcement and call for proposals
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2024-at-icfp-announcement-and-call-for-proposals/14371/6>
Continuing this thread, Sonja Heinze said
─────────────────────────────────────────
One more update, this time about hybrid modalities: We now have the
confirmation from sigplan (the organizers behind ICFP) that we'll have
the same hybrid modalities as last year :tada: So in particular,
speakers can give talks remotely via a Zoom call. We'll also make sure
this time that the remote speaker can see the audience over the
call. To promote a good atmosphere, communication and engagement, we
do prefer to have most talks in-person, but remote talks will be most
welcome as well. So, don't hesitate to submit a talk even if you can't
make it in person.
Cheers, @Armaël and @pitag
PD: Once the time comes closer, we'll give detail on youtube live and
discord links for remote attendance as well
Guillaume Munch-Maccagnoni then added
─────────────────────────────────────
Thanks, this update about hybridity should also be true for the ML
workshop.
Odoc syntax cheatsheet
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-odoc-syntax-cheatsheet/14658/1>
Paul-Elliot announced
─────────────────────
Hello!
I'm happy to announce the addition of a [cheatsheet] for odoc's
syntax!
I hope it will make it less painful to learn or refresh yourself on
the topic. The [full syntax reference] is still useful to have some
details.
Have {b fun} :slight_smile: !
[cheatsheet] <https://ocaml.github.io/odoc/cheatsheet.html>
[full syntax reference]
<https://ocaml.github.io/odoc/odoc_for_authors.html>
DkCoder 0.2 - Scripting in OCaml
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dkcoder-0-2-scripting-in-ocaml/14560/2>
jbeckford announced
───────────────────
The 0.3 version is now available. It has a publicly accessible
<https://github.com/diskuv/dkcoder> so issues can be filed, and
`cohttp 6.0.0~beta2' is now bundled.
Most important, 0.3 was sufficient to build the real production
service
<https://gitlab.com/diskuv/samples/devops/DkSubscribeWebhook>. It has
a Dockerfile and Docker Compose for easy deployment to production, and
the Docker container is based on Google's
<https://github.com/GoogleContainerTools/distroless#readme> for a
"small" size (well, 100MB is not small but it is not big either). The
only executable in the container is `ocamlrunx' (no `/bin/sh',
etc.). In an ideal world where I had more time the service would be
embedded inside MirageOS instead.
Imandra SysML Transpiler Internship Opportunity!
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/imandra-sysml-transpiler-internship-opportunity/14660/1>
Ben Bellick announced
─────────────────────
I wanted to share an opportunity for a summer internship with Imandra!
If you're someone with an interest in writing production OCaml or
using a battle-worn automated theorem prover in an industry setting,
please apply!
It is based in Austin, TX.
You can find more details and apply [here].
Thanks!
[here] <https://apply.workable.com/imandra/j/15392A4445/>
Bam - A property-based testing with internal shrinking
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bam-a-property-based-testing-with-internal-shrinking/14661/1>
François Thiré announced
────────────────────────
I am excited to introduce *Bam*, a robust and versatile property-based
testing (PBT) library. Bam simplifies the process of testing
properties across a wide range of randomly generated values, making it
easier to identify and debug issues in your code.
Key Features
╌╌╌╌╌╌╌╌╌╌╌╌
• *Monad-like Generators*: Create new generators easily with a
monad-like pattern that works seamlessly with shrinking mechanisms.
• *PPX Support*: Automatically derive generators based on type
descriptions. The customizable deriver ensures smooth integration
into your codebase.
• *Tezt Integration*: Integrates with the Tezt test framework,
providing a user-friendly experience, especially notable in
debugging scenarios.
• *Internal Shrinking*: Various default shrinking strategies help
efficiently pinpoint minimal counterexamples. Internal shrinking
ensures that only 'smaller' values are used during the process, and
this is done in a way that is compatible with the monad-like
operators.
• *Custom Shrinking*: Define custom shrinkers that work well with the
existing shrinking strategies.
Installation
╌╌╌╌╌╌╌╌╌╌╌╌
You can install Bam using opam:
┌────
│ opam install bam tezt-bam
└────
Getting started
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Here is an example to get you started:
┌────
│ open Tezt_bam
│
│ type t = Foo of {a: int; b: string} | Bar of int list [@@deriving gen]
│ (** The deriver creates a value [val gen : t Bam.Std.t]. *)
│
│ let register () =
│ let property = function
│ | Foo {a; b} ->
│ if a > 1_000 && String.contains b 'z' then
│ Error (`Fail "A counter-example was found")
│ else Ok ()
│ | Bar [1; 2; 3; 4] ->
│ Error `Bad_value
│ | Bar _ ->
│ Ok ()
│ in
│ Pbt.register ~__FILE__ ~title:"Simple example of bam" ~tags:["bam"; "simple"]
│ ~gen ~property ()
│
│ let _ =
│ register ();
│ Test.run ()
└────
There are several more detailed [examples] in the repository to show
you around the library.
[examples] <https://github.com/francoisthire/bam/tree/master/example>
Contributions
╌╌╌╌╌╌╌╌╌╌╌╌╌
Contributions from the community are welcome! If you have ideas, bug
reports, or improvements, feel free to share them!
Kakadu asked and François Thiré replied
───────────────────────────────────────
Can it be compared to <https://github.com/c-cube/qcheck/>
?
My work around /Bam/ started after using "QCheck" and especially
"QCheck2" quite a lot for the Tezos project.
With respect to QCheck, QCheck2 came with "integrated" shrinking
allowing to derive automatically shrinkers for generators. This aim to
simplify debugging when a counter-example is found, so that a smaller
example is reported to the user.
However, this came with a cost:
• Performance-wise, there was a regression from "QCheck", especially
the time taken to report a counter-example because the shrinking
process was taking a lot of time
• At some point, we even faced an issue were the shrinking process
never ended. We started to implement an ad-hoc shrinker but it was
not working either and we never really figured out. The solution was
to deactivate shrinking
• There are other UX considerations: debugging can be tedious
(especially "hello" debugging)
So basically /Bam/ started as an experiment to understand shrinking
and come up with something easier to understand and compose
better. This is why /bam/ relies mainly on monadic operators.
This makes the writing of generators easier, the shrinking is
/internal/ ensuring the shrinking won't create new value. If you use
the mondic operator of QCheck2, last time I checked it was not the
case. This is why to create a generator for a pair, it is recommended
to use `tup2' instead of monadic operators.
Using monadic-operators allows you also to have a smaller kernel that
is hopefully easier to maintain.
I also developped the integration of /bam/ with Tezt in a way to avoid
currently pitfalls we had with `QCheck2':
• You can easily control the stopping condition of the test
• The test can be easily run in parallel or in a loop mode to help you
find a counter-example quicker
• The runner can fail if not enough values were generated or execution
was too long (likely due to a regression)
• It captures the output, so that only the one for the counter-example
printed is shown. This is very handy during debugging. Otherwise, it
is quite tedious to understand which line comes from which attempt
• It is easy to opt-out from shrinking if it takes too much time. Can
be useful for a CI. Shrinking only needs to be executed locally
(assuming the property is deterministic) with a given seed
I also had some fun trying to define shrinking strategies allowing you
to skip elements in a list. This is very handy when your property is
about running a scenario made of a list of actions (a use-case very
close to the monolith library from François Pottier). In general the
initial counter-example contains superfluous actions. Such a strategy
allows you to remove them to easy the debugging.
I don't have concrete data to compare Bam with QCheck2 at the
moment. Let me know if you have ideas to make an objective comparison
between those two libraries.
Stitch - Note Managing for Unorganized Minimalists
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/stitch-note-managing-for-unorganized-minimalists/14664/1>
Marc Coquand announced
──────────────────────
Hey everyone!
I wanted to share a cli tool built in OCaml I've been working on, that
was only possible with the help of the community. :slight_smile:
The tool is called stitch, and is a minimal note-managing tool that
aims to be a good unix citizen. It allows you to take notes in
whatever format/editor you want while spending minimal time organizing
them.
I built it using Cmdliner, Notty and Shexp. I'm drafting a longer
writeup to share the challenges and general experience, but in short
all three libraries were a bit short on examples but ultimately
excellent and very easy to work with. Afterward, packaging everything
turned out to be a bit harder.
Some screenshots: [overview], [todo], [full-notes].
And link to repo:
<https://git.mccd.space/pub/stitch/about/>
It's still in it's early days and the code-base is a bit messy. But I
use it as my daily driver for notes. :slight_smile:
[overview] <https://blobs.mccd.space/stitch/notes-view.png>
[todo] <https://blobs.mccd.space/stitch/todo-view.png>
[full-notes] <https://blobs.mccd.space/stitch/full-notes-view.png>
7 OCaml Gotchas
═══════════════
Archive: <https://discuss.ocaml.org/t/blog-7-ocaml-gotchas/14667/1>
Dmitrii Kovanikov announced
───────────────────────────
Hi everyone! :wave:
I've been using OCaml for a while, and I'm quite enjoying the
language. In my not-so-long journey, I discovered a few surprising
OCaml behaviours, so I decided to share them with everyone in a blog
post.
• [7 OCaml Gotchas]
I hope it reduces frustration for newcomers when they see something
unexpected for the first time!
[7 OCaml Gotchas] <https://dev.to/chshersh/7-ocaml-gotchas-207e>
Using OCaml on windows with WSL
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-using-ocaml-on-windows-with-wsl/14671/1>
PizieDust announced
───────────────────
When I got started in OCaml, my setup was basically a dual boot of
Windows 11 and Ubuntu. I had a few issues setting up OCaml on windows
at the time and started looking up WSL and if it was a good
alternative (I really disliked having to dual boot always). So I wrote
this article detailing exactly how I setup OCaml on WSL and have been
using it for the past 12 months with no issues. So if you are looking
to get started with programming in OCaml on windows, this article is
for you.
[How to setup OCaml on Windows with WSL]
Note: `opam 2.2' makes it a breeze using OCaml on windows natively so
if you are particularly interested about using OCaml without WSL you
should check it out.
[How to setup OCaml on Windows with WSL]
<https://tarides.com/blog/2024-05-08-how-to-setup-ocaml-on-windows-with-wsl/>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [The MirageOS retreat 2024]
• [The OCaml 5.2 Release: Features and Fixes!]
• [Beta release of Frama-C 29.0~beta (Copper)]
• [Bye Opam, Hello Nix]
• [How to Setup OCaml on Windows with WSL]
• [Announcing DBCaml, Silo, Serde Postgres and a new driver for
postgres]
• [Fixing and Optimizing the GnuCOBOL Preprocessor]
[the ocaml.org blog] <https://ocaml.org/blog/>
[The MirageOS retreat 2024]
<https://hannes.robur.coop/Posts/Retreat2024>
[The OCaml 5.2 Release: Features and Fixes!]
<https://tarides.com/blog/2024-05-15-the-ocaml-5-2-release-features-and-fixes>
[Beta release of Frama-C 29.0~beta (Copper)]
<https://frama-c.com/fc-versions/copper.html>
[Bye Opam, Hello Nix]
<https://priver.dev/blog/ocaml/bye-opam-hello-nix/>
[How to Setup OCaml on Windows with WSL]
<https://tarides.com/blog/2024-05-08-how-to-setup-ocaml-on-windows-with-wsl>
[Announcing DBCaml, Silo, Serde Postgres and a new driver for postgres]
<https://priver.dev/blog/dbcaml/dbcaml-project/>
[Fixing and Optimizing the GnuCOBOL Preprocessor]
<https://ocamlpro.com/blog/2024_04_30_fixing_and_optimizing_gnucobol>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35295 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-05-14 13:25 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-05-14 13:25 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 34428 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 07 to 14,
2024.
Table of Contents
─────────────────
Some code for Molecular Mechanics in OCaml
OCaml.org Newsletter: April 2024
Example of using LSP server in Emacs
Dune Developer Experience Feedback Form
DkML 2.1.1
A May update on wasm_of_ocaml
OCaml 5.2.0 released
Old CWN
Some code for Molecular Mechanics in OCaml
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/some-code-for-molecular-mechanics-in-ocaml-ann/14610/1>
UnixJunkie announced
────────────────────
Recently, I released a bunch of code for some Molecular Mechanics
calculations in OCaml.
This is pretty much at the beta stage for the moment.
<https://github.com/UnixJunkie/MMO>
Maybe in the future I will create a proper library to encapsulate the
Mol and Mol2 modules in there; they allow to perform some operations
on small molecules.
For those interested, there is a partial implementation of the
Universal Force Field (UFF) in there; only the part concerning
non-bonded interactions.
OCaml.org Newsletter: April 2024
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-org-newsletter-april-2024/14611/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the April 2024 edition of the OCaml.org newsletter! This
update has been compiled by the OCaml.org team. You can find [previous
updates] on Discuss.
Our goal is to make OCaml.org the best resource for anyone who wants
to get started and be productive in OCaml. The OCaml.org newsletter
provides an update on our progress towards that goal and an overview
of the changes we are working on.
We couldn't do it without all the amazing people who help us review,
revise, and create better OCaml documentation and work on issues. Your
participation enables us to so much more than we could just by
ourselves. Thank you!
This newsletter covers:
• *OCaml Cookbook:* We shipped a new, community-driven section in the
Learn area. Help us make it really useful by contributing and
reviewing recipes for common tasks!
• *Community & Marketing Pages Rework:* We have UI designs for the
reworked and new pages of the community section and are starting
work to implement these.
• *General Improvements:* As usual, we also worked on general
maintenance and improvements, so we're highlighting some of the
work that happened below.
[previous updates] <https://discuss.ocaml.org/tag/ocamlorg-newsletter>
Open Issues for Contributors
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
You can find [open issues for contributors here]!
Here's some new (and as of time of writing this newsletter still open)
issues that were opened this month:
• Package Versions page is missing dark mode styles
[ocaml/ocaml.org#2341] by [@sabine]
• (Data) Extend the Data Model of Academic Institution to Record
Information about Course Materials [ocaml/ocaml.org#2328] by
[@sabine]
[open issues for contributors here]
<https://github.com/ocaml/ocaml.org/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+no%3Aassignee>
[ocaml/ocaml.org#2341] <https://github.com/ocaml/ocaml.org/issues/2341>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2328] <https://github.com/ocaml/ocaml.org/issues/2328>
The OCaml Cookbook
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We shipped a new, community-driven section in the Learn area: the
OCaml Cookbook!
The OCaml Cookbook is a place where OCaml developers share how to
solve common tasks using packages from the ecosystem.
A task is something that needs to be done inside a project. A recipe
is a code sample and explanations on how to perform a task using a
combination of open source libraries.
The Cookbook now live at [ocaml.org/cookbook], but there are not a lot
of recipes published yet.
Here's how we need your help:
1. Help review [open pull requests for cookbook recipes]!
2. Contribute new recipes and tasks for the cookbook!
3. Suggest improvements to existing recipes and the UI.
*Relevant PRs and Activities:*
• Open PRs in need of reviewers:
• PR: Cookbook geodesic [ocaml/ocaml.org#2381] by [@F-Loyer]
• PR: Cookbook / subprocess creation [ocaml/ocaml.org#2382] by
[@F-Loyer]
• PR: Cookbook getenv [ocaml/ocaml.org#2383] by [@F-Loyer]
• PR: Cookbook : linalg [ocaml/ocaml.org#2386] by [@F-Loyer]
• PR: Use camlzip and with_open_text [ocaml/ocaml.org#2371] by
[@cuihtlauac]
• PR: Deserialise and post-process YAML recipes
[ocaml/ocaml.org#2372] by [@cuihtlauac]
• PR: Rebased database recipes [ocaml/ocaml.org#2376] by
[@cuihtlauac]
• PR: Rebased basic concurrency recipe [ocaml/ocaml.org#2377] by
[@cuihtlauac]
• PR: Rebased sorting recipe [ocaml/ocaml.org#2378] by [@cuihtlauac]
• PR: Rebased ascii and utf-8 recipes [ocaml/ocaml.org#2379] by
[@cuihtlauac]
[ocaml.org/cookbook] <https://ocaml.org/cookbook>
[open pull requests for cookbook recipes]
<https://github.com/ocaml/ocaml.org/pulls?q=is%3Apr+is%3Aopen+label%3ACookbook>
[ocaml/ocaml.org#2381] <https://github.com/ocaml/ocaml.org/pull/2381>
[@F-Loyer] <https://github.com/F-Loyer>
[ocaml/ocaml.org#2382] <https://github.com/ocaml/ocaml.org/pull/2382>
[ocaml/ocaml.org#2383] <https://github.com/ocaml/ocaml.org/pull/2383>
[ocaml/ocaml.org#2386] <https://github.com/ocaml/ocaml.org/pull/2386>
[ocaml/ocaml.org#2371] <https://github.com/ocaml/ocaml.org/pull/2371>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2372] <https://github.com/ocaml/ocaml.org/pull/2372>
[ocaml/ocaml.org#2376] <https://github.com/ocaml/ocaml.org/pull/2376>
[ocaml/ocaml.org#2377] <https://github.com/ocaml/ocaml.org/pull/2377>
[ocaml/ocaml.org#2378] <https://github.com/ocaml/ocaml.org/pull/2378>
[ocaml/ocaml.org#2379] <https://github.com/ocaml/ocaml.org/pull/2379>
Community & Marketing Pages Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We have [UI designs for the reworked and new pages of the community
section] and are starting work to implement these. We are opening
small issues for contributors to help. :orange_heart:
*Relevant PRs and Activities:*
• PR: UI: Added DateTime of Event on the Client Side in the User's
Timezone [ocaml/ocaml.org#2339] by [@maha-sachin]
• PR: Create new Events page with routing under Community
[ocaml/ocaml.org#2338] by [@shakthimaan]
• PR: Add event_type field to Events, and render tag in Event cards
[ocaml/ocaml.org#2366] by [@csaltachin]
[UI designs for the reworked and new pages of the community section]
<https://www.figma.com/file/7hmoWkQP9PgLTfZCqiZMWa/OCaml-Community-Pages?type=design&node-id=637%3A4539&mode=design&t=RpQlGvOpeg1a93AZ-1>
[ocaml/ocaml.org#2339] <https://github.com/ocaml/ocaml.org/pull/2339>
[@maha-sachin] <https://github.com/maha-sachin>
[ocaml/ocaml.org#2338] <https://github.com/ocaml/ocaml.org/pull/2338>
[@shakthimaan] <https://github.com/shakthimaan>
[ocaml/ocaml.org#2366] <https://github.com/ocaml/ocaml.org/pull/2366>
[@csaltachin] <https://github.com/csaltachin>
General Improvements and Data Additions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Relevant PRs and Activities:*
• Bugfixes
• PR: fix: add .modules style for odoc-generated documentation pages
[ocaml/ocaml.org#2355] by [@sabine]
• PR: Fix: correct text color on community resource card
[ocaml/ocaml.org#2329] by [@sabine]
• PR: fix: Make Community card about LearnOCaml point to the correct
URL [ocaml/ocaml.org#2331] by [@yurug]
• Documentation
• PR: OCaml Tour: -New sections- Introduction and Before We
Begin. Added REPL definition and double semicolon use
[ocaml/ocaml.org#2336] by [@Alfredo-Carlon]
• PR: Minor line editing on "Values and Functions" Tutorial
[ocaml/ocaml.org#2321] by [@jeuxdeau]
• Data
• PR: [planet]: add melange blog [ocaml/ocaml.org#2362] by
[@anmonteiro]
• PR: (data) add april OUPS meetup [ocaml/ocaml.org#2360] by
[@sabine]
• PR: Add TUM as an academic institution [ocaml/ocaml.org#2347] by
[@PumPum7]
• PR: Add Routine job post. [ocaml/ocaml.org#2325] by [@mefyl]
• PR: (data) Add OCaml Workshop to Upcoming Events
[ocaml/ocaml.org#2326] by [@sabine]
• PR: (data) add ReasonSTHLM meetup [ocaml/ocaml.org#2308] by
[@sabine]
• PR: Add missing Mdx changelogs [ocaml/ocaml.org#2368] by
[@tmattio]
• PR: Fix small typo in Dune 3.14 announcement
[ocaml/ocaml.org#2315] by [@Leonidas-from-XIV]
• PR: Dune 3.15.0 announcement [ocaml/ocaml.org#2316] by
[@Leonidas-from-XIV]
• PR: OCaml 5.2.0-beta2 changelog entry [ocaml/ocaml.org#2343] by
[@Octachron]
• PR: (data) add March 2024 OCaml.org newsletter
[ocaml/ocaml.org#2317] by [@sabine]
• PR: Add the announement for opam 2.2.0~beta2
[ocaml/ocaml.org#2334] by [@kit-ty-kate]
• PR: jobs: remove XenServer positions [ocaml/ocaml.org#2387] by
[@edwintorok]
• Move of the OCaml Language Manual from v2.ocaml.org to ocaml.org
• PR: fix: Serve manual under /lts and /latest URLs
[ocaml/ocaml.org#2345] by [@sabine]
• PR: Remove /manual/lts URL, fix broken route for /manual/latest
[ocaml/ocaml.org#2348] by [@sabine]
• PR: Add /api/** redirection [ocaml/ocaml.org#2352] by [@mtelvers]
• PR: Handle lts, default and missing version in middleware
[ocaml/ocaml.org#2358] by [@cuihtlauac]
• PR: Add served pages to sitemap [ocaml/ocaml.org#2363] by
[@cuihtlauac]
• PR: Skip unreleased manuals from sitemap [ocaml/ocaml.org#2367] by
[@cuihtlauac]
• PR: Turn some v2 redirects into local [ocaml/ocaml.org#2356] by
[@cuihtlauac]
• Refactor / Code health
• PR: Remove Commit module from Global [ocaml/ocaml.org#2319] by
[@cuihtlauac] (created/merged: 2024-04-05T14:17:31Z)
• PR: chore: remove learn_sidebar.eml, which was not used anymore
[ocaml/ocaml.org#2342] by [@sabine]
• PR: Add link to deploy.ci.ocaml.org in HACKING
[ocaml/ocaml.org#2354] by [@cuihtlauac]
• PR: Use type annotation for data parameters [ocaml/ocaml.org#2384]
by [@cuihtlauac]
[ocaml/ocaml.org#2355] <https://github.com/ocaml/ocaml.org/pull/2355>
[@sabine] <https://github.com/sabine>
[ocaml/ocaml.org#2329] <https://github.com/ocaml/ocaml.org/pull/2329>
[ocaml/ocaml.org#2331] <https://github.com/ocaml/ocaml.org/pull/2331>
[@yurug] <https://github.com/yurug>
[ocaml/ocaml.org#2336] <https://github.com/ocaml/ocaml.org/pull/2336>
[@Alfredo-Carlon] <https://github.com/Alfredo-Carlon>
[ocaml/ocaml.org#2321] <https://github.com/ocaml/ocaml.org/pull/2321>
[@jeuxdeau] <https://github.com/jeuxdeau>
[ocaml/ocaml.org#2362] <https://github.com/ocaml/ocaml.org/pull/2362>
[@anmonteiro] <https://github.com/anmonteiro>
[ocaml/ocaml.org#2360] <https://github.com/ocaml/ocaml.org/pull/2360>
[ocaml/ocaml.org#2347] <https://github.com/ocaml/ocaml.org/pull/2347>
[@PumPum7] <https://github.com/PumPum7>
[ocaml/ocaml.org#2325] <https://github.com/ocaml/ocaml.org/pull/2325>
[@mefyl] <https://github.com/mefyl>
[ocaml/ocaml.org#2326] <https://github.com/ocaml/ocaml.org/pull/2326>
[ocaml/ocaml.org#2308] <https://github.com/ocaml/ocaml.org/pull/2308>
[ocaml/ocaml.org#2368] <https://github.com/ocaml/ocaml.org/pull/2368>
[@tmattio] <https://github.com/tmattio>
[ocaml/ocaml.org#2315] <https://github.com/ocaml/ocaml.org/pull/2315>
[@Leonidas-from-XIV] <https://github.com/Leonidas-from-XIV>
[ocaml/ocaml.org#2316] <https://github.com/ocaml/ocaml.org/pull/2316>
[ocaml/ocaml.org#2343] <https://github.com/ocaml/ocaml.org/pull/2343>
[@Octachron] <https://github.com/Octachron>
[ocaml/ocaml.org#2317] <https://github.com/ocaml/ocaml.org/pull/2317>
[ocaml/ocaml.org#2334] <https://github.com/ocaml/ocaml.org/pull/2334>
[@kit-ty-kate] <https://github.com/kit-ty-kate>
[ocaml/ocaml.org#2387] <https://github.com/ocaml/ocaml.org/pull/2387>
[@edwintorok] <https://github.com/edwintorok>
[ocaml/ocaml.org#2345] <https://github.com/ocaml/ocaml.org/pull/2345>
[ocaml/ocaml.org#2348] <https://github.com/ocaml/ocaml.org/pull/2348>
[ocaml/ocaml.org#2352] <https://github.com/ocaml/ocaml.org/pull/2352>
[@mtelvers] <https://github.com/mtelvers>
[ocaml/ocaml.org#2358] <https://github.com/ocaml/ocaml.org/pull/2358>
[@cuihtlauac] <https://github.com/cuihtlauac>
[ocaml/ocaml.org#2363] <https://github.com/ocaml/ocaml.org/pull/2363>
[ocaml/ocaml.org#2367] <https://github.com/ocaml/ocaml.org/pull/2367>
[ocaml/ocaml.org#2356] <https://github.com/ocaml/ocaml.org/pull/2356>
[ocaml/ocaml.org#2319] <https://github.com/ocaml/ocaml.org/pull/2319>
[ocaml/ocaml.org#2342] <https://github.com/ocaml/ocaml.org/pull/2342>
[ocaml/ocaml.org#2354] <https://github.com/ocaml/ocaml.org/pull/2354>
[ocaml/ocaml.org#2384] <https://github.com/ocaml/ocaml.org/pull/2384>
Example of using LSP server in Emacs
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/example-of-using-lsp-server-in-emacs/14601/4>
Tim McGilchrist announced
─────────────────────────
I wrote a blog post about my setup
<https://lambdafoo.com/posts/2022-09-07-ocaml-with-emacs-2022.html>
The only change I've made is to use `envrc-mode' rather than
`direnv-mode'.
Dune Developer Experience Feedback Form
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dune-developer-experience-feedback-form/14617/1>
ostera announced
────────────────
The Dune team at [Tarides] is looking to get inputs from all of you to
improve the Dune DX (developer experience), so we've opened a [small,
anonymous, unstructured feedback form] to hear your ideas on how Dune
could be improved :camel:
We're looking forward to your ideas! :sparkles:
[Tarides] <https://tarides.com>
[small, anonymous, unstructured feedback form]
<https://forms.gle/izg5xSt1XNp3i4Rc8>
DkML 2.1.1
══════════
Archive: <https://discuss.ocaml.org/t/ann-dkml-2-1-1/14620/1>
jbeckford announced
───────────────────
Use [https://ocaml.org/install] if you are a first-time user (the
install steps haven't changed).
The upgrade steps and release notes are available at
<https://gitlab.com/dkml/distributions/dkml/-/releases/2.1.1>. For
those who are on 2.1.0, the upgrade is the following in PowerShell:
┌────
│ 1..6 | % { @("bash","sh","with-dkml","ocamllsp","git","opam","dune","ocamlrun") | % { taskkill /F /IM "$_.exe" }; Start-Sleep 1 }
│ winget upgrade dkml
└────
[https://ocaml.org/install] <https://ocaml.org/install>
Major Changes
╌╌╌╌╌╌╌╌╌╌╌╌╌
• The opam repository is fixed to [commit
6c3f73f42890cc19f81eb1dec8023c2cd7b8b5cd] for stability. If you need
a new version of a package and can't wait for the next version of
DkML, you can pin that package's url (recommended) or float the opam
repository with `opam repository set-url default
git+https://github.com/ocaml/opam-repository.git#main'.
• Windows SDK 10.0.22621.0 and VC 17.8 (14.38) added to allowed
list. This supports Visual Studio 2022, especially for GitLab CI.
• New supported package: `tiny_httpd'
[commit 6c3f73f42890cc19f81eb1dec8023c2cd7b8b5cd]
<https://github.com/ocaml/opam-repository/tree/6c3f73f42890cc19f81eb1dec8023c2cd7b8b5cd>
Patches
╌╌╌╌╌╌╌
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Package What Issue
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
`base_bigstring.v16.0' Implement `memmem' for Windows <https://github.com/janestreet/base_bigstring/issues/6>
`core_kernel.v0.16.0' MSVC fix didn't make it to 0.16.0 <https://github.com/janestreet/core_kernel/pull/107>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Upgraded Packages
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Package From To
─────────────────────────────────────────────────────────────────────────
dune (et al) 3.12.1 3.15.0
ocaml 4.14.0 4.14.2
ocamlformat (et al) 0.25.1 0.26.1
odoc 2.2.0 2.4.1
odoc-parser 2.0.0 2.4.1
lsp (et al) 1.16.2 1.17.0
mdx 2.3.0 2.4.1
ctypes (et al) 0.19.2-windowssupport-r7 0.19.2-windowssupport-r8
tiny_httpd 0.16
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Thanks to OCaml Software Foundation for sponsoring DkML!
A May update on wasm_of_ocaml
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-may-update-on-wasm-of-ocaml/14635/1>
Jan Midtgaard announced
───────────────────────
Spring is over us and several months have passed since we last shared
[an update on WebAssembly compilation].
[an update on WebAssembly compilation]
<https://discuss.ocaml.org/t/a-december-update-from-the-ocaml-wasm-organisation/13565>
Introduction
╌╌╌╌╌╌╌╌╌╌╌╌
[`wasm_of_ocaml'] is a compiler from OCaml bytecode to [WebAssembly],
similar to [`js_of_ocaml'] from which it was forked. `wasm_of_ocaml'
offers a functional, almost drop-in replacement for `js_of_ocaml' -
with better performance.
For now, the compiler targets a JavaScript-hosted WebAssembly
engine. The produced code furthermore requires the following [Wasm
extensions] to run:
• [the GC extension], including functional references and 31-bit
integers
• [the tail-call extension]
• [the exception handling extension]
[`wasm_of_ocaml'] <https://github.com/ocaml-wasm/wasm_of_ocaml>
[WebAssembly] <https://webassembly.org/>
[`js_of_ocaml'] <https://github.com/ocsigen/js_of_ocaml>
[Wasm extensions] <https://webassembly.org/roadmap/>
[the GC extension] <https://github.com/WebAssembly/gc>
[the tail-call extension]
<https://github.com/WebAssembly/tail-call/blob/main/proposals/tail-call/Overview.md>
[the exception handling extension]
<https://github.com/WebAssembly/exception-handling/blob/master/proposals/exception-handling/Exceptions.md>
Platform support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [Node 22 now supports the WasmGC extension], meaning that it can run
`wasm_of_ocaml' output out of the box!
• CloudFlare uses [V8 12.0 since Dec 4, 2023]. [This corresponds to
Chrome 120], and thus includes the WasmGC extension, effectively
enabling OCaml development on CloudFlare! For more details see the
[WebAssembly CloudFlare docs]
• [The upcoming 0.14.0 release] of [the WasmEdge WebAssembly engine]
adds WasmGC support too. Along with the [just merged exception
support], this paves the way for running `wasm_of_ocaml' output…
[Node 22 now supports the WasmGC extension]
<https://nodejs.org/en/blog/announcements/v22-release-announce>
[V8 12.0 since Dec 4, 2023]
<https://developers.cloudflare.com/workers/platform/changelog/#2023-12-04>
[This corresponds to Chrome 120] <https://v8.dev/docs/version-numbers>
[WebAssembly CloudFlare docs]
<https://developers.cloudflare.com/workers/runtime-apis/webassembly/>
[The upcoming 0.14.0 release]
<https://github.com/WasmEdge/WasmEdge/releases/tag/0.14.0-rc.4>
[the WasmEdge WebAssembly engine] <https://github.com/WasmEdge/WasmEdge>
[just merged exception support]
<https://github.com/WasmEdge/WasmEdge/pull/3306>
`wasm_of_ocaml' news
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Since the last update in December
• Jérôme gave a talk about `wasm_of_ocaml' at the INRIA Cambium
seminar - [slides available here]
• Olivier Nicole joined the `wasm_of_ocaml' effort
• Jérôme and Olivier visited Jane Street to help them adopt
`wasm_of_ocaml'
Notable features
• Sourcemap support was added [ocaml-wasm/wasm_of_ocaml#27]
• This required adding sourcemap support to the `wasm-metadce' and
`wasm-merge' binaryen tools [WebAssembly/binaryen#6372]
• A first implementation of separate compilation was completed
[ocaml-wasm/wasm_of_ocaml#36]
• One can compile cmo and cma files, producing intermediate archive
files
• Then the files can be linked together: relevant Wasm modules are
put in a directory, and JavaScript code is generated to load them
and link them together
• Store long-lived toplevel values into globals
[ocaml-wasm/wasm_of_ocaml#30]
• The initialization code produced by `wasm_of_ocaml' can be large
and contain a large number of variables. This is challenging to
both binaryen tools and the Wasm engines. The problem can be
alleviated by storing long-lived toplevel values into global
variables. As an side benefit, many closures can be statically
allocated (since their free variables are now stored in globals),
which again can provide performance improvements in the remaining
parts of the code.
• Tuple syntax changes [ocaml-wasm/wasm_of_ocaml#31]
• Prepared the switch to the new version of binaryen, which has
small syntax changes
• Use the JS String Builtins proposal for string conversions when
available [ocaml-wasm/wasm_of_ocaml#33]
• Improve the WAT (Wasm text format) output to be more readable
[ocaml-wasm/wasm_of_ocaml#34]
• Name local variables (they were just numbered) and use shorter
names (the names used to be systematically suffixed to ensure they
were unique).
Other features and fixes
• Fixed file descriptor management so that it works with large file
descriptors [ocaml-wasm/wasm_of_ocaml#18]
• PR: Update Firefox version information in README (no longer beta)
[ocaml-wasm/wasm_of_ocaml#19]
• PR: Fix pin branch in installation instructions
[ocaml-wasm/wasm_of_ocaml#20]
• PR: Add `Stdlib.String.fold_{left,right}' to build on OCaml < 4.13
[ocaml-wasm/wasm_of_ocaml#21]
• PR translating stubs of `integers_js_stubs' to Wasm
[o1-labs/integers_stubs_js#10]
• Tracked a bug in a test on the repo [o1-labs/integers_stubs_js#9]
• PR: Generate valid Wasm code [ocaml-wasm/wasm_of_ocaml#22]
• PR: Avoid using `eval' for statically known strings
[ocaml-wasm/wasm_of_ocaml#24]
• PR: Have physical equality inspect Javascript objects
[ocaml-wasm/wasm_of_ocaml#25]
• PR: Tune optimization profiles [ocaml-wasm/wasm_of_ocaml#26]
• PR: Correction and precision about Binaryen version
[ocaml-wasm/wasm_of_ocaml#29]
Binaryen fixes
• PR: wasm-merge: check that the types of imports and exports
match. [WebAssembly/binaryen#6437]
• Improved binaryen's linker to check that the types of imports and
exports match. Found a type mismatch in the wasm_of_ocaml runtime
this way.
• PR: Fixes regarding explicit names [WebAssembly/binaryen#6466]
• The name of some module components were lost during module linking
• PR: Fix writing of data segment names in name section
[WebAssembly/binaryen#6462]
• Binaryen could actually generate a malformed name section
[slides available here]
<https://cambium.inria.fr/seminaires/transparents/20231213.Jerome.Vouillon.pdf>
[ocaml-wasm/wasm_of_ocaml#27]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/27>
[WebAssembly/binaryen#6372]
<https://github.com/WebAssembly/binaryen/pull/6372>
[ocaml-wasm/wasm_of_ocaml#36]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/36>
[ocaml-wasm/wasm_of_ocaml#30]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/30>
[ocaml-wasm/wasm_of_ocaml#31]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/31>
[ocaml-wasm/wasm_of_ocaml#33]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/33>
[ocaml-wasm/wasm_of_ocaml#34]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/34>
[ocaml-wasm/wasm_of_ocaml#18]
<https://github.com/ocaml-wasm/wasm_of_ocaml/issues/18>
[ocaml-wasm/wasm_of_ocaml#19]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/19>
[ocaml-wasm/wasm_of_ocaml#20]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/20>
[ocaml-wasm/wasm_of_ocaml#21]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/21>
[o1-labs/integers_stubs_js#10]
<https://github.com/o1-labs/integers_stubs_js/pull/10>
[o1-labs/integers_stubs_js#9]
<https://github.com/o1-labs/integers_stubs_js/issues/9>
[ocaml-wasm/wasm_of_ocaml#22]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/22>
[ocaml-wasm/wasm_of_ocaml#24]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/24>
[ocaml-wasm/wasm_of_ocaml#25]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/25>
[ocaml-wasm/wasm_of_ocaml#26]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/26>
[ocaml-wasm/wasm_of_ocaml#29]
<https://github.com/ocaml-wasm/wasm_of_ocaml/pull/29>
[WebAssembly/binaryen#6437]
<https://github.com/WebAssembly/binaryen/pull/6437>
[WebAssembly/binaryen#6466]
<https://github.com/WebAssembly/binaryen/pull/6466>
[WebAssembly/binaryen#6462]
<https://github.com/WebAssembly/binaryen/pull/6462>
OCaml 5.2.0 released
════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-5-2-0-released/14638/1>
octachron announced
───────────────────
The OCaml team has the pleasure of celebrating the birthday of Inge
Lehmann by announcing the release of OCaml version 5.2.0.
Some of the highlights in OCaml 5.2.0 are:
• Re-introduced GC compaction
GC compaction can now be manually triggered by calling `Gc.compact
()' manually. This is expected to be particularly useful for
programs that wish to release memory to the operating system after a
temporary memory-intensive phase.
• Restored native backend for POWER 64 bits
With this restored backend, all 64 bits architecture supported in
OCaml 4 are supported bin OCaml 5
• Thread sanitizer support
Thread sanitizer is a dynamic data race detector which instrument
memory accesses to detect and explain data races at execution
time. Since the instrumentation is costly (with a 2x to 7x
slowdown), it must be enabled with the `ocaml-option-tsan'
configuration flag. (The reference manual contains more information
on how to use TSAN.)
• New Dynarray module
This new standard library module provides a standard implementation
for resizeable array, which is guaranteed to be memory safe even in
presence of data races.
• New -H flag for hidden include directories
This new flag makes it possible for build tools to split cleanly
dependencies between direct (the dependencies explicitly added by
the project) and indirect dependencies (the dependencies introduced
by the direct dependencies) without the quirks of previous
implementations.
• Project-wide occurence metadata support for developer tools
When compiling a module with the `-bin-annot' and
`-bin-annot-occurrences' flags, the compiler stores in the `.cmt'
file an index of all occurences of values, types, modules, …
• Raw identifiers
To improve OCaml upward-compatibility, there is a new syntax for
lowercase identifiers, `let \#if = 0', which works even if the
identifier is a keyword in some OCaml versions. This change has been
adopted in OCaml 5.2 in preparation of the introduction of the
`effect' keyword in OCaml 5.3
• Local open in type expressions
Local open are now allowed in type expression: `val (+): Int64.(t ->
t -> t)'.
And a lot of incremental changes:
• Around 20 new functions in the standard library besides the new
Dynarray module (in the `Array', `Float', `Format', `Fun',
`In_channel', `Out_channel', and `Random' modules )
• Many fixes and improvements in the runtime
• Many bug fixes
OCaml 5.2.0 is still a somewhat experimental release compared to the
OCaml 4.14 branch. In particular
• The Windows MSVC port is still unavailable.
• Ephemeron performances need to be investigated.
• `statmemprof' is being tested in the developer branch of OCaml.
• There are a number of known runtime concurrency or GC performance
bugs (that trigger under rare circumstances).
Since the Windows MSVC port and statmemprof are still missing, the
maintenance support for OCaml 4.14 will be extended until at least the
end of the year.
Please report any unexpected behaviours on the [OCaml issue tracker]
and post any questions or comments you might have here on discuss.
The full list of changes can be found in the changelog below.
[OCaml issue tracker] <https://github.com/ocaml/ocaml/issues>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands:
┌────
│ opam update
│ opam switch create 5.2.0
└────
The source code for the release candidate is also directly available
on:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.0.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.0.tar.gz>
Fine-Tuned Compiler Configuration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
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.1.0+options <option_list>
└────
where `<option_list>' is a space separated list of `ocaml-option-*'
packages. For instance, for a `flambda' and `no-flat-float-array'
switch:
┌────
│ opam switch create 5.2.0+flambda+nffa ocaml-variants.5.2.0+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
OCaml 5.2.0 Changelog (13 May 2024)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
(Changelog elided to reduce message size. Please follow the archive link
above.)
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 46495 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-05-07 7:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-05-07 7:30 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 18862 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 30 to May
07, 2024.
Table of Contents
─────────────────
Deploying Ocsigen applications
OCaml linting tools and techniques
dune 3.15
bitgenerators v0.1.0
checked_oint v0.1.0
Liquidsoap 2.2.5 is out!
OCaml 5.2.0 - First Release Candidate
Announcing DBCaml, Silo, Serde Postgres and a new driver for postgres
Pretty Printing in OCaml: Format Primer
Send us Talk and Workshop Proposals for Fun OCaml 2024 in Berlin, September 16+17
OCaml Workshop 2024 at ICFP – announcement and call for proposals
Other OCaml News
Old CWN
Deploying Ocsigen applications
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/deploying-ocsigen-applications/14572/1>
Hans Ole Rafaelsen announced
────────────────────────────
I have written a short text on how Ocsigen applications might be
packed in order to be deployed to other nodes, that don't have your
development environment installed.
[Deploying Ocsigen]
If you happen to have a better way, or solutions to parts that I have
not been able to solve, please let me know.
[Deploying Ocsigen] <https://github.com/hansole/deploying_ocsigen>
OCaml linting tools and techniques
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-ocaml-linting-tools-and-techniques/14574/1>
Simmo Saan announced
────────────────────
Recently, I started wondering about linting tools for OCaml, so I went
looking. This ended up being a quite extensive survey. Therefore, I
decided to publish my findings in a blog post: [OCaml linting tools
and techniques].
In particular, I focused on linting with dune and Ppxlib because
there's many variations out there. In the post I describe the
technical choices that go into such linters and provide an overview of
those that work and how well. In the process of experimenting, I tried
them out myself and published them as demos on GitHub:
[sim642/dune-lint-demo].
Feel free to let me know if I missed any tools out there or you have
any questions/comments. There isn't much information about this out
there (and existing tool does it slightly differently), so I hope this
overview benefits others as well.
[OCaml linting tools and techniques]
<https://sim642.eu/blog/2024/05/01/ocaml-linting>
[sim642/dune-lint-demo] <https://github.com/sim642/dune-lint-demo>
dune 3.15
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-15/14438/2>
Etienne Millon announced
────────────────────────
We've released 3.15.1 and 3.15.2. The latter is particularly important
for Coq users since it fixes a regression in incremental compilation
introduced in 3.13.0.
Here's the combined changelog:
Fixed
╌╌╌╌╌
• Fix overflow in sendfile stubs (copy of large files could fail or
end with truncated files) (#10333, @tonyfettes)
• Fix crash when a rule with a directory target is disabled with
`enabled_if` (#10382, fixes #10310, @gridbugs)
• melange: remove all restrictions around virtual libraries in
Melange. They may be used as otherwise in libraries and
executables. (#10412, @anmonteiro)
• spawn: fix compatibility with RHEL7 (#10428, @emillon)
• If no directory targets are defined, then do not evaluate
`enabled_if` (#10442, @rgrinberg)
• Fix a bug where Coq projects were being rebuilt from scratch each
time the dependency graph changed. (#10446, fixes #10149, @alizter)
bitgenerators v0.1.0
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bitgenerators-v0-1-0/14577/1>
zoj613 announced
────────────────
Hi everyone. I'd like to announce the first release of
[bitgenerators]. This library implements an OCaml port of NumPy's
bitgenerator interface for working with Psuedo-random numbers (see:
<https://numpy.org/doc/stable/reference/random/bit_generators/index.html>).
• This library implements several PRNGs that are exposed through this
common interface. It also implements an `SeedSequence' module for
seeding PRNGs using high quality initial states based on the ideas
discussed [here].
• Morever, the module provides functions that help easily generate
independent and non-overlapping instances of a PRNG for use in
parallel computation in a /reproducible/ manner.
• Implemented PRNG's include [PCG64], [SFC64], [Philox4x64],
[Xoshiro256**] and [ChaCha]. All of which pass stringent statistical
randomness tests like PractRand and Testu01.
• The API documentation can be found [here]
• The source code is hosted on github:
<https://github.com/zoj613/bitgenerators>
• The README file contains examples of how the library can be used.
This is my first Ocaml project and therefore I would highly appreciate
feedback from experienced users regarding it's usefulness and possibly
how it could be improved (e.g. usability and performance). I tried to
keep the implementation as functional as possible, though not very
sure if that's the best approach here.
[bitgenerators] <https://github.com/zoj613/bitgenerators>
[here]
<https://www.pcg-random.org/posts/developing-a-seed_seq-alternative.html>
[PCG64] <https://www.cs.hmc.edu/tr/hmc-cs-2014-0905.pdf>
[SFC64] <https://pracrand.sourceforge.net/RNG_engines.txt>
[Philox4x64] <https://ieeexplore.ieee.org/document/6114424/>
[Xoshiro256**] <https://prng.di.unimi.it/>
[ChaCha] <https://cr.yp.to/chacha/chacha-20080128.pdf>
[here]
<https://zoj613.github.io/bitgenerators/bitgenerators/Bitgen/index.html>
checked_oint v0.1.0
═══════════════════
Archive: <https://discuss.ocaml.org/t/ann-checked-oint-v0-1-0/14580/1>
Sima Kinsart announced
──────────────────────
I'd like to announce a new library: [`checked_oint']. It implements
checked arithmetic for both signed and unsigned integers of 8, 16, 32,
64, and 128 bits. Unlike `stdint' or `ocaml-integers', routines in
this library either return an option or raise an exception when a
result of an arithmetic operation cannot be represented in a desired
integer type. In addition, it contains abstractions for manipulating
arbitrary integers and integer types in a generic and type-safe
manner, which I find quite useful for compiler/interpreter
implementations.
Usage example:
┌────
│ open Checked_oint
│
│ let () =
│ let x = U8.of_int_exn 50 in
│ let y = U8.of_int_exn 70 in
│ assert (U8.equal (U8.add_exn x y) (U8.of_int_exn 120));
│ assert (Option.is_none (U8.mul x y))
└────
Feel free to ask any questions in the comments.
[`checked_oint'] <https://github.com/Hirrolot/checked_oint>
Liquidsoap 2.2.5 is out!
════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-liquidsoap-2-2-5-is-out/14582/1>
Romain Beauxis announced
────────────────────────
Liquidsoap `2.2.5' has out! Full release details are here:
<https://github.com/savonet/liquidsoap/releases/tag/v2.2.5>
Liquidsoap is a statically typed scripting general-purpose language
with dedicated operators and backend for all thing media, streaming,
file generation, automation, HTTP backend and more.
This is hopefully the *last* release of the `2.2.x' release cycle
before we kick off the new `2.3.x' release cycle. We've got a couple
feature to bring there and then it'll be ready for more testing.
Liquidsoap `2.2.5' has some good bugfixes and some minor changes but
its most exciting feature is the *autocue* . It was developed in close
collaboration with several users. The feature is an opt-in crossfade
extension that computes the /perfect/ crossfade transitions for your
tracks.
Over the years, it's been very interesting to maintain an application
and language that is now pretty large and complex using the OCaml
compiler and ecosystem. It's amazing to see how easy it is now to
build integrate new packages. It also brings in some interesting,
real-life challenges such as some very specific [memory issues].
Next, we would like to work on optimizing the language by introducing
modules, to reduce the standard library's memory footprint, and to use
the new OCaml parallelism to fully leverage CPU and memory usage when
streaming large amount of data such as video streams.
[memory issues] <https://github.com/ocaml/ocaml/issues/13123>
OCaml 5.2.0 - First Release Candidate
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-5-2-0-first-release-candidate/14584/1>
octachron announced
───────────────────
The release of OCaml 5.2.0 is imminent. As a final step, we are
publishing a release candidate to check that everything is in order
before the release in the upcoming week(s).
If you find any bugs, please report them on [OCaml's issue tracker].
Compared to the second beta, this release contains one small
compiler-libs printer fix and one configuration tweak.
The full change log for OCaml 5.2.0 is available [on GitHub]. A short
summary of the changes since the second beta release is also available
below.
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.2/Changes>
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands on opam 2.1 and later:
┌────
│ opam update
│ opam switch create 5.2.0~rc1
└────
The source code for the release candidate is also directly available
on:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.0-rc1.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.0~rc1.tar.gz>
Fine-Tuned Compiler Configuration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
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.2.0~rc1+options <option_list>
└────
where `<option_list>' is a space-separated list of `ocaml-option-*'
packages. For instance, for a `flambda' and `no-flat-float-array'
switch:
┌────
│ opam switch create 5.2.0~rc1+flambda+nffa ocaml-variants.5.2.0~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Changes since the second beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#13130]: Minor fixes to `pprintast' for raw identifiers and local
module open syntax for types. (Chet Murthy, review by Gabriel
Scherer)
• [#13100] Fix detection of `zstd' when compiling with `musl-gcc'
(David Allsopp, review by Samuel Hym)
[#13130] <https://github.com/ocaml/ocaml/issues/13130>
[#13100] <https://github.com/ocaml/ocaml/issues/13100>
Announcing DBCaml, Silo, Serde Postgres and a new driver for postgres
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-dbcaml-silo-serde-postgres-and-a-new-driver-for-postgres/14585/1>
Emil Priver announced
─────────────────────
<https://priver.dev/blog/dbcaml/dbcaml-project/>
Pretty Printing in OCaml: Format Primer
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-pretty-printing-in-ocaml-format-primer/14599/1>
Vladimir Keleshev announced
───────────────────────────
Hi folks, I wrote another +monad+ Format tutorial.
<https://keleshev.com/pretty-printing-in-ocaml-a-format-primer>
Here's some of layouts that are covered:
┌────
│ [[],
│ ["one", "two", "three"],
│ ["one",
│ "two",
│ "three",
│ "four",
│ "five",
│ "six",
│ "seven",
│ "eight",
│ "nine",
│ "ten"]]
└────
┌────
│ [
│ [],
│ ["one", "two", "three"],
│ [
│ "one",
│ "two",
│ "three",
│ "four",
│ "five",
│ "six",
│ "seven",
│ "eight",
│ "nine",
│ "ten",
│ ]
│ ]
└────
┌────
│ [ []
│ , [ "one", "two", "three" ]
│ , [ "one"
│ , "two"
│ , "three"
│ , "four"
│ , "five"
│ , "six"
│ , "seven"
│ , "eight"
│ , "nine"
│ , "ten"
│ ]
│ ]
└────
I tried to share some of my experience using Format. As a bonus—JSON
pretty printer.
Send us Talk and Workshop Proposals for Fun OCaml 2024 in Berlin, September 16+17
═════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/send-us-talk-and-workshop-proposals-for-fun-ocaml-2024-in-berlin-september-16-17/14603/1>
Sabine Schmaltz announced
─────────────────────────
*Fun OCaml 2024* is a *2 days open source hacking event* dedicated to
OCaml enthusiasts and professionals. We focus on the impact and
potential of OCaml for solving real-world problems and get together
in Berlin for a conference/hackathon over two days:
• Day 1 (Monday, September 16): talks (which are live-streamed) and
socializing/hacking.
• Day 2 (Tuesday, September 17): Workshops and hacking.
Topics we're interested in:
• how you use OCaml in your business / in your projects
• OCaml libraries, frameworks, and other Open Source projects built on
OCaml
• hands-on demonstrations that encourage people to try things on the
second day of the event or at home
• seeing actual code and reasoning behind design decisions
• experience reports
For more details, check out the website and the CFP linked from there:
<https://fun-ocaml.com>
Registration for attendees will be announced later this week in
advance, but is not open yet.
Thanks! :sparkles: :orange_heart: :camel:
OCaml Workshop 2024 at ICFP – announcement and call for proposals
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2024-at-icfp-announcement-and-call-for-proposals/14371/5>
Sonja Heinze continued this thread
──────────────────────────────────
As mentioned above, the submission deadline for the OCaml Workshop at
ICFP is getting closer.
As a new note: A few weeks after the OCaml Workshop at ICFP, there'll
be the new initiative [Fun OCaml] in Berlin. It's super exciting to
have three OCaml-related workshops (first the ML Workshop and the
OCaml Workshop at ICFP, and then Fun OCaml) over the course of a few
weeks, and we're also very much looking forward to Fun OCaml!
We've already mentioned that when reading the submissions, as every
year, we'll collaborate closely with the organizers of the ML workshop
at ICFP, which intersects with the OCaml Workshop on talks with a
strong theoretical and research-oriented focus. We'll also collaborate
with the organizers of Fun OCaml this year, which might intersect on
talks with a strong practical focus. With collaboration, we mainly
mean potentially transferring submissions from one workshop to another
after checking in with the authors (side-note: if you want your
presentation to be taken into account for a potential transfer, you
need to respect the earlier of the two submission deadlines).
Best, and looking forward to this exciting year of OCaml workshops,
@Armael and @pitag
[Fun OCaml]
<https://discuss.ocaml.org/t/send-us-talk-and-workshop-proposals-for-fun-ocaml-2024-in-berlin-september-16-17/14603>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [We Host Our First OCaml Retreat in India!]
[the ocaml.org blog] <https://ocaml.org/blog/>
[We Host Our First OCaml Retreat in India!]
<https://tarides.com/blog/2024-05-01-we-host-our-first-ocaml-retreat-in-india>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 33418 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-04-30 7:22 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-04-30 7:22 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 19915 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 23 to 30,
2024.
Table of Contents
─────────────────
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
I roughly translated Real World OCaml's Async concurrency chapter to eio
Using Property-Based Testing to Test OCaml 5
OCaml Backtraces on Uncaught Exceptions, by OCamlPro
OCaml Users on Windows: Please share your insights on our user survey
Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts
dream-html 3.0.0
DkCoder 0.2 - Scripting in OCaml
Ocaml-protoc-plugin 6.1.0
Other OCaml News
Old CWN
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
═════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocannl-0-3-1-a-from-scratch-deep-learning-i-e-dense-tensor-optimization-framework/14492/8>
Lukasz Stafiniak announced
──────────────────────────
Third time the charm. OCANNL 0.3.3 is out now. I might need to change
the name of the project, because of the lint warnings: Possible name
collision with packages 'OCADml', 'ocal', 'ocaml'?
I roughly translated Real World OCaml's Async concurrency chapter to eio
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/i-roughly-translated-real-world-ocamls-async-concurrency-chapter-to-eio/14548/1>
Dennis Dang announced
─────────────────────
Repo at
<https://github.com/dangdennis/rwo-eio/blob/main/lib/rwo_eio.ml>
I was inspired by Taride's [Make an Eio version of the Async examples
in Real World OCaml] to translate the Async examples to eio to test
out eio's concurrency story. Warning, it's a rough translation. I
hardly know OCaml and eio as well as I know my day-job languages
:smile: .
There are still a few examples I haven't figured out.
1. I don't know how to implement [`copy_blocks']. In [this section],
the example uses an intermediate buffer of some sorts to then copy
from reader to writer. For now, I've left that intermediate buffer
out.
2. I can't find an `interrupt' option in `cohttp-eio' as well as
`choice' and `choose'. The book explains that cohttp-async can
cancel http requests via an `interrupt' ([see section]).
3. For [`log_delays'], I have yet to solve how to await my own `every'
ticker such that I can await its completion and then log the timer
at the end.
[Make an Eio version of the Async examples in Real World OCaml]
<https://github.com/tarides/hackocaml/issues/9>
[`copy_blocks']
<https://github.com/dangdennis/rwo-eio/blob/a666d8aaaed0884218d706f94b6babeed85debea/lib/rwo_eio.ml#L88>
[this section]
<https://dev.realworldocaml.org/concurrent-programming.html>
[see section]
<https://dev.realworldocaml.org/concurrent-programming.html>
[`log_delays']
<https://github.com/dangdennis/rwo-eio/blob/a666d8aaaed0884218d706f94b6babeed85debea/lib/rwo_eio.ml#L348>
Using Property-Based Testing to Test OCaml 5
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-using-property-based-testing-to-test-ocaml-5/14550/1>
Jan Midtgaard announced
───────────────────────
Here's a blog post about how we have been using property-based testing
to test OCaml 5:
<https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5/>
OCaml Backtraces on Uncaught Exceptions, by OCamlPro
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-ocaml-backtraces-on-uncaught-exceptions-by-ocamlpro/14551/1>
OCamlPro announced
──────────────────
Here's another one of our heads up about our latest blog release!
Today's topic is about an unintentionally hidden feature of the OCaml
dev environmment: [backtraces on uncaught exception]!
We believe this will be old news to the veteran OCaml devs but could
be of much use to the newer Cameleers out there!
Hopefully, you will learn a thing or two from reading this short
article, we welcome all feedback in this very thread, thank you for
reading!
[backtraces on uncaught exception]
<https://ocamlpro.com/blog/2024_04_25_ocaml_backtraces_on_uncaught_exceptions/>
OCaml Users on Windows: Please share your insights on our user survey
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-users-on-windows-please-share-your-insights-on-our-user-survey/14554/1>
Sudha Parimala announced
────────────────────────
Do you use OCaml on Windows? We want to hear from you! Participate in
our user survey to share your experiences with the OCaml development
environment on Windows. Your feedback is important in helping us
understand the current pain points and identify areas for
improvement. Whether you're a seasoned OCaml developer or just
starting out, your input can make a significant difference.
Please sign up here <https://forms.gle/SxRvNaEZXgedxrnR9>, and we'll
reach out to you.
Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/graphql-jsoo-client-0-1-0-library-for-graphql-clients-using-websockts/14557/1>
Hans Ole Rafaelsen announced
────────────────────────────
I'm glad to announce the release of graphql_jsoo_client.
This is the client side implementation of the [GraphQL over WebSocket
Protocol]. It is mainly intended for use with Dream, which implements
the server side. This library supports writing client code in Ocaml,
that will run in the browser.
It can be found [here].
[GraphQL over WebSocket Protocol]
<https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md>
[here] <https://github.com/hansole/graphql_jsoo_client>
dream-html 3.0.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dream-html-3-0-0/14013/8>
Yawar Amin announced
────────────────────
[ANN] dream-html 3.4.1
Add 'livereload' support ie automatically reloading the page in the
browser when the Dream server restarts. Useful to run with dune's
watch mode for a fast dev cycle.
This is adapted from Dream's own livereload middleware but with a
slightly different approach. Full details in the module documentation:
<https://yawaramin.github.io/dream-html/dream-html/Dream_html/Livereload/>
Why reimplement this? It seems that Dream's built-in livereload needs
to parse the HTML markup, find its `head' tag, and dynamically inject
the reloader `script' inside. Since parsing HTML can be pretty tricky
and potentially buggy, I decided to manually add the script in the
`head' tag as a strong-typed dream-html `node':
┌────
│ head [] [
│ ...
│ Livereload.script;
│ ...
│ ]
└────
DkCoder 0.2 - Scripting in OCaml
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dkcoder-0-2-scripting-in-ocaml/14560/1>
jbeckford announced
───────────────────
I'm happy to announce the second release of DkCoder, an OCaml
scripting tool.
The first release was about /install ease/: a couple clicks and four
(4) minutes later you and your Windows and macOS users can start
scripting. All users, including glibc-based Linux desktop users, can
also use their Unix shells or Windows PowerShell. OCaml does *not*
need to be pre-installed. Just copy and paste two lines (you'll see
some in this post) and your script is running and your project is
editable with OCaml LSP.
This second release is about /technical ease/. The three "big" ideas
in this release are:
• You don't write build files. If that sounds like `/bin/sh' that is
intentional.
• Almost every OCaml file is a script you can run. If that sounds like
how Python scripts are almost indistinguishable from Python modules,
that is intentional.
• Almost every OCaml file can be referenced with a fully-qualified
name. If that sounds like Java packages that is intentional.
Here are some examples:
1. (*one of my own scripts*) The incomplete but growing DkCoder
documentation is written in a script:
<https://diskuv.com/dksdk/coder/2024-intro-scripting/>. /The
documentation is a side-effect of running tests./
In a Unix shell or in PowerShell, the following will a) run tests
using [tezt], b) collect outputs, c) generate HTML documentation,
and then d) serve the doc page on a [tiny_httpd] webserver for a
quick preview:
┌────
│ git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git
│
│ ./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --serve
└────
The following will print mixed Markdown/HTML that I can render and
publish with a static site generator to a website:
┌────
│ ./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --doc --doc-format markdown
└────
2. (*someone else's*) The Bogue demo game Snoke written by @sanette
was "ported" to DkCoder. /The port did not change a single line of
the original code/. I did re-arrange the directory structure
(recall that there is a Java-like package mechanism underneath
DkCoder) and I did add an extra `.ml' file. Run:
┌────
│ git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git
│
│ ./SanetteBogue/dk DkRun_V0_2.Run -- SanetteBogue_Snoke.Snoke
└────
The remaining items for DkCoder before a 1.x release: auto-downloading
remote libraries (mostly done), meta/codegen tools (in progress),
conditional compilation (in design), and a security policy (in
design).
But right now DkCoder is at a reasonable enough point that I can now
recommend using it for your own scripts. With the usual caveats that
this is a 0.x release.
/I'd like some feedback, especially on pain points and missing
must-have features./
[tezt] <https://v3.ocaml.org/p/tezt/latest>
[tiny_httpd] <https://v3.ocaml.org/p/tiny_httpd/latest>
Tech Details (if interested)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Very simplistically, DkCoder is a high-level build system that
transparently manages lower-level build systems (today that is Dune).
I think (?) DkCoder is the first build system to use [the `codept'
OCaml dependency analyzer]. Huge huge thanks to @octachron for that
tool.
The rather boring driver pipeline is:
1. Seed a "universe" of modules with the single `.ml' file the user
wants to run from the `./dk' CLI, or seed with all the `.ml' files
if run through OCaml LSP.
2. Let `codept' analyse any module references inside the current
universe. Any *missing modules* are located and added to the
universe. Rinse and repeat until there is a closed universe with no
more missing module references.
3. Generate and/or incrementally update the build files. Each `.ml'
file is mapped to a single OCaml `.cma' library.
4. Run the chosen build tool (ie. Dune) and execute the code.
What does that pipeline give us? Even in this early 0.2 release you
get some unusual benefits:
• Step 2: The *missing modules* can be created implicitly. The Snoke
game has font, image and sound assets. By using `Tr1Assets.LocalDir'
in the code DkCoder automatically creates a module that has all the
assets (think [ocaml-crunch]). If a script does not need the assets,
the `codept' analysis knows it doesn't use `Tr1Assets', and the
assets won't waste time getting built.
• Step 3: The *one-to-one .ml/.cma correspondence* means DkCoder can
apply a unique set of compiler flags to each `.ml' file. You get the
Java-like package structure by opening a unique set of modules per
`.ml' with `-open' flags (nit: I also used implicitly created
directory modules to let you navigate the packages in your source
code).
• Step 4: You can take the generated `dune-project' and `dune' files,
tweak them and run them outside of DkCoder. /That means you are not
locked into DkCoder!/ You can alternatively do what I did with
Snoke: make your project compatible with both regular dune
(/ocamlbuild/etc.) and DkCoder. Either way, you only need to deal
with two issues that arise from DkCoder's bytecode compilation and
prebuilt C libraries: a) build C dependencies yourself, and b) tell
Dune to switch from bytecode mode to native code mode. If you are a
mildly experienced Linux/OCaml user who understands the terms
"opam", "pkg-config", "depexts", and "dune-configurator", this is a
low bar.
Script references:
• [https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git]
• [https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git]
[the `codept' OCaml dependency analyzer]
<https://discuss.ocaml.org/t/local-open-seems-to-confuse-dunes-dependency-cycle-detector/9529/2?u=jbeckford>
[ocaml-crunch] <https://v3.ocaml.org/p/crunch/latest>
[https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git]
<https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git>
[https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git]
<https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git>
Ocaml-protoc-plugin 6.1.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-6-1-0/14566/1>
Anders Fugmann announced
────────────────────────
I'm happy to announce the release of [Ocaml-protoc-plugin] version
6.1.0 Ocaml-protoc-pluginis a plugin for google's protobuf compiler
(`protoc') that generates an idomatic ocaml mapping and
(de-)serialization functions based on .proto files. The library aims
to be 100% compliant implementation of the protobuf specification.
The 6.1.0 (and 6.0.0) release introduces Json serialization and
deserialization based on protobuffers guidelines and the ability to
copy comments from .proto into ocaml generated code for improved
documentation as well as numerous bug fixes and other improvements.
*Full changelog since release 5.0.0*
[Ocaml-protoc-plugin]
<https://github.com/andersfugmann/ocaml-protoc-plugin>
6.1.0: 2024-04-25
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Fix name resolution leading to wrongly mapped names
• Fix codegen bug causing the plugin to reject valid protobuf
• Add preliminary support for melange though disabling eager
evaluation of serialize and deserialize functions when not using
native or bytecode backends
• Fix missing cflags when compiling test c stub
• Make Map tests compatible with older versions of protoc
• Fix negative integer test failues due to a bug in older versions of
protobuf (google) c lib
6.0.0: 2024-04-13
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ New features
• Implement json serialization and deserialization (#5)
• Support special json mapping for google types (#9)
• Add deprecation annotations for deprecated fields, services etc (#8)
• Add option to prefix generated files with their package name
• Copy documentation from proto files into generated ocaml bindings
◊ Bug fixes
• Fix file output name if files contains a '-'
• Resolve bug for Request/Response module aliases leading to
generating uncompilable code. (#21)
• Fix codegen bug for messages without fields and setting
singleton_records = true (#20)
• In Services, the package field is now correctly set to None if the
service if not defined in a package scope (#24)
◊ Misc changes
• Unify serialization and deserialization spec and optimize oneof
handling
• Simplify types used in code generation to improve readaility
• *Replace `val name': unit -> string' with `val name: unit -> string'
which will only return the full protobuf name
• Optimize merge functions by applying eager evaluation
• Change signature of `to_proto'' to return unit and not a writer
(`*' indicates breaking change)
◊ Notes
`Message.name': unit -> string' has been renamed to `Message.name:
unit -> string', and is now contains the fully qualified protobuf
message name. Before the name was the ocaml module name of the
message.
`Service.Message' signature has been deprecated and replaced with
`Spec.Message' signature. `Service.Message' is now an alias for
`Spec.Message' and will be removed in future releases.
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [OCaml Backtraces on Uncaught Exceptions]
• [Under the Hood: Developing Multicore Property-Based Tests for OCaml
5]
[the ocaml.org blog] <https://ocaml.org/blog/>
[OCaml Backtraces on Uncaught Exceptions]
<https://ocamlpro.com/blog/2024_04_25_ocaml_backtraces_on_uncaught_exceptions>
[Under the Hood: Developing Multicore Property-Based Tests for OCaml 5]
<https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 31088 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-04-23 12:17 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-04-23 12:17 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 34364 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 16 to 23,
2024.
Table of Contents
─────────────────
A second beta for OCaml 5.2.0
An implementation of purely functional double-ended queues
Feedback / Help Wanted: Upcoming OCaml.org Cookbook Feature
Picos — Interoperable effects based concurrency
Ppxlib dev meetings
Ortac 0.2.0
OUPS meetup april 2024
Mirage 4.5.0 released
patricia-tree 0.9.0 - library for patricia tree based maps and sets
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
Other OCaml News
Old CWN
A second beta for OCaml 5.2.0
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-second-beta-for-ocaml-5-2-0/14498/1>
octachron announced
───────────────────
Last week, we merged in the 5.2 branch of OCaml an update to the
compiler-libs "shape" API for querying definition information from the
compiler.
Unfortunately, this small change of API breaks compatibility with at
least odoc. Generally, we try to avoid this kind of changes during the
beta releases of the compiler. However, after discussions we concluded
that it will be easier on the long term to fix the API right now in
order to avoid multiplying the number of supported versions of the
shape API in the various OCaml developer tools .
We have thus released a second beta version of OCaml 5.2.0 to give the
time to developer tools to update their 5.2.0 version ahead of the
release (see below for the installation instructions).
Beyond this changes of API, the new beta contains three minor bug
fixes and three documentation updates, which is a good sign in term of
stability.
As usual, you can follow the last remaining compatibility slags on the
[opam readiness for 5.2.0 meta-issue].
If you find any bugs, please report them on [OCaml's issue tracker].
Currently, the release is planned for the beginning of May.
If you are interested in full list of features and bug fixes of the
new OCaml version, the updated change log for OCaml 5.2.0 is available
[on GitHub].
[opam readiness for 5.2.0 meta-issue]
<https://github.com/ocaml/opam-repository/issues/25182>
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.2/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.2.0~beta2
└────
The source code for the beta is also available at these addresses:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.0-beta2.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.0~beta2.tar.gz>
Fine-Tuned Compiler Configuration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
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.2.0~beta2+options <option_list>
└────
where `option_list' is a space-separated list of `ocaml-option-*'
packages. For instance, for a `flambda' and `no-flat-float-array'
switch:
┌────
│ opam switch create 5.2.0~beta2+flambda+nffa ocaml-variants.5.2.0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Changes since the first beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Compiler-libs API Changes
• [#13001]: do not read_back entire shapes to get aliases' uids when
building the usages index (Ulysse Gérard, review by Gabriel Scherer
and Nathanaëlle Courant)
[#13001] <https://github.com/ocaml/ocaml/issues/13001>
◊ Bug Fixes
• [#13058]: Add TSan instrumentation to caml_call_gc(), since it may
raise exceptions. (Fabrice Buoro, Olivier Nicole, Gabriel Scherer
and Miod Vallat)
• [#13079]: Save and restore frame pointer across Iextcall on ARM64
(Tim McGilchrist, review by KC Sivaramakrishnan and Miod Vallat)
• [#13094]: Fix undefined behavior of left-shifting a negative number.
(Antonin Décimo, review by Miod Vallat and Nicolás Ojeda Bär)
[#13058] <https://github.com/ocaml/ocaml/issues/13058>
[#13079] <https://github.com/ocaml/ocaml/issues/13079>
[#13094] <https://github.com/ocaml/ocaml/issues/13094>
◊ Documentation Updates
• [#13078]: update Format tutorial on structural boxes to mention
alignment questions. (Edwin Török, review by Florian Angeletti)
• [#13092]: document the existence of the `[@@poll error]' built-in
attribute (Florian Angeletti, review by Gabriel Scherer)
• [#13066], update OCAMLRUNPARAM documentation for the stack size
parameter l (Florian Angeletti, review by Nicolás Ojeda Bär, Tim
McGilchrist, and Miod Vallat)
[#13078] <https://github.com/ocaml/ocaml/issues/13078>
[#13092] <https://github.com/ocaml/ocaml/issues/13092>
[#13066] <https://github.com/ocaml/ocaml/issues/13066>
An implementation of purely functional double-ended queues
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/an-implementation-of-purely-functional-double-ended-queues/14499/1>
Humza Shahid announced
──────────────────────
I have some code that might be useful to others here. I had the idea
of a new purely functional implementation for double ended queues, and
I implemented it (<https://github.com/hummy123/bro-deque>)[here].
The idea is pretty simple, and it proves to be quite fast in
benchmarks.
The idea is to have a record containing:
• A head array representing the start of the queue, with a limit on
the number of elements it can have.
• A tail array representing the end of the queue, also with a limit on
the number of elements it can have.
• A balanced binary tree based on the rope data structure. (The
internal nodes pointing to other nodes contain integer metadata
indicating the number of elements on the left and right subtrees,
and leaf nodes contain an array of elements.)
When trying to insert into either the head or tail array when the
array is at max capacity, the array is either appended or prepended to
the tree and the array/element we wanted to insert is now either the
head or tail.
I was looking for some way to test the performance and adapted (this
code)[<https://discuss.ocaml.org/t/ocaml-speed-recursive-function-optimization/13502/3>]
to use it, and it's pretty fast - only about 4x slower than the
standard library's mutable queue. (Although this was really
implemented in mind aiming for fast access time rather than fast
insertion/removal time.)
It has some non-standard functions for double ended queues too, like
O(log n) insert/removal/indexing at any arbitrary location (with a
constant that makes this faster than on a typical binary tree - a
typical binary tree contains on element per node, increasing height,
but this contains arrays of elements at the leaves so more data is
packed and the height is shorter).
Some other people might find it useful, so here it is for others to
copy-and-paste. I don't know if it's worth putting on opam (I don't
have a use for this myself in any of my projects but curiosity led me
to implement it.)
Feedback / Help Wanted: Upcoming OCaml.org Cookbook Feature
═══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/feedback-help-wanted-upcoming-ocaml-org-cookbook-feature/14127/12>
Cuihtlauac Alvarado announced
─────────────────────────────
We've just updated the cookbook:
<https://staging.ocaml.org/cookbook>. We'd love to have your feedback
on it. The corresponding PR is still the same:
<https://github.com/ocaml/ocaml.org/pull/1839>
The visual design is not yet final, but it works. It is organized in
recipes, tasks and categories.
A task is something that needs to be done inside a
project. A recipe is a code sample and explanation of how
to perform a task using a combination of packages. Some
tasks can be performed using different combination of
libraries, each is a different recipe. Categories are
groups of tasks or categories
You'll see most tasks don't have any recipes. We hope to collect the
best recipes. Categories are also open for discussion.
Picos — Interoperable effects based concurrency
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-picos-interoperable-effects-based-concurrency/14507/1>
polytypic announced
───────────────────
[Picos] is a framework for building interoperable elements such as
• schedulers that multiplex large numbers of user level fibers to run
on a small number of system level threads,
• mechanisms for managing fibers and for structuring concurrency,
• communication and synchronization primitives, such as mutexes and
condition variables, message queues, STMs, and more, and
• integrations with low level asynchronous IO systems,
of effects based cooperative concurrent programming models.
[Picos] <https://github.com/ocaml-multicore/picos>
polytypic then announced
────────────────────────
I'm happy to announce that version 0.2.0 of Picos is now available on
opam.
A small core [picos] framework allows concurrent abstractions
[implemented in Picos] to communicate with [Picos compatible]
schedulers.
In addition to the core framework, the `picos' package comes with a
couple of sample schedulers and some scheduler agnostic libraries as
well as bunch of auxiliary libraries.
Sample schedulers:
• [picos.fifos] — Basic single-threaded effects based Picos compatible
scheduler for OCaml 5.
• [picos.threaded] — Basic Thread based Picos compatible scheduler for
OCaml 4.
Scheduler agnostic libraries:
• [picos.sync] — Basic communication and synchronization primitives
for Picos.
• [picos.stdio] — Basic IO facilities based on OCaml standard
libraries for Picos.
• [picos.select] — Basic `Unix.select' based IO event loop for Picos.
Auxiliary libraries:
• [picos.domain] — Minimalistic domain API available both on OCaml 5
and on OCaml 4.
• [picos.exn_bt] — Wrapper for exceptions with backtraces.
• [picos.fd] — Externally reference counted file descriptors.
• [picos.htbl] — Lock-free hash table.
• [picos.mpsc_queue] — Multi-producer, single-consumer queue.
• [picos.rc] — External reference counting tables for disposable
resources.
• [picos.thread] — Minimalistic thread API available with or without
`threads.posix'.
All of the above are entirely opt-in and you are free to mix-and-match
with any other Picos compatible [future] schedulers and libraries
implemented in Picos or develop your own.
See the [reference manual] for further information.
[picos]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos/index.html>
[implemented in Picos]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/index.html#implemented-in-picos>
[Picos compatible]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/index.html#picos-compatible>
[picos.fifos]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_fifos/index.html>
[picos.threaded]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_threaded/index.html>
[picos.sync]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_sync/index.html>
[picos.stdio]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_stdio/index.html>
[picos.select]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_select/index.html>
[picos.domain]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_domain/index.html>
[picos.exn_bt]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_exn_bt/index.html>
[picos.fd]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_fd/index.html>
[picos.htbl]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_htbl/index.html>
[picos.mpsc_queue]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_mpsc_queue/index.html>
[picos.rc]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_rc/index.html>
[picos.thread]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/Picos_thread/index.html>
[future]
<https://discuss.ocaml.org/t/ann-miou-a-simple-scheduler-for-ocaml-5/12963/14>
[reference manual]
<https://ocaml-multicore.github.io/picos/0.2.0/picos/index.html>
Ppxlib dev meetings
═══════════════════
Archive: <https://discuss.ocaml.org/t/ppxlib-dev-meetings/12441/21>
Nathan Rebours announced
────────────────────────
You can find our last meeting's notes [here].
We had three guests yesterday: @shonfeder @lubegasimon and
@moazzammoriani.
You are always welcome to join whether you have a specific topic you
want to bring up or you just want to tag along. We'll post the link
here ahead of the meeting.
[here] <https://github.com/ocaml-ppx/ppxlib/wiki/Dev-Meeting-2024-04-16>
Ortac 0.2.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-ortac-0-2-0/14510/1>
Nicolas Osborne announced
─────────────────────────
We are very excited to announce this new Ortac release!
Ortac is a set of tools that translate Gospel specifications into
OCaml code and use these translations to generate programs that check
at runtime that the OCaml implementation respects the Gospel
specifications.
You can find the project on [this repo] and install it via `opam'.
This new release contains four packages:
• `ortac-core'
• `ortac-runtime'
• `ortac-qcheck-stm'
• `ortac-runtime-qcheck-stm'
The main improvements that brings this release concern the
`ortac-qcheck-stm' plugin (the other three packages are mainly
released for compatibility reasons).
`ortac-qcheck-stm' provides a plugin for Ortac. It generates
QCheck-STM tests for a module specified with Gospel. QCheck-STM is a
model-based testing framework and Ortac/QCheck-STM relies on the
Gospel models you gave in the specifications to build the QCheck-STM
tests.
I'd like to highlight two of these improvements.
The first one is that type invariants for what we call the system
under test are now checked. Let's say you want to generate QCheck-STM
tests for a fixed-size container. You can give the following
specification to your type:
┌────
│ type 'a t
│ (*@ mutable model contents : 'a list
│ model size : int
│ with t invariant List.length t.contents <= t.size *)
└────
Now, the generated tests will check that the invariant is respected at
initialisation of the system under test (the value of type `'a t') and
that it is preserved by the functions being tested.
The second improvement concerns the test failure message. In order to
make the failure more informative, a message stating which part of the
Gospel specifications has been violated and a small OCaml program that
demonstrates the unexpected behaviour will be displayed.
For example, with an artificial bug in the `Array.length' function,
running the Ortac/QCheck-STM-generated test will print the following
failure message:
┌────
│ random seed: 172339461
│ generated error fail pass / total time test name
│ [✗] 1 0 1 0 / 1000 0.0s Array STM tests (generating)
│
│ --- Failure --------------------------------------------------------------------
│
│ Test Array STM tests failed (5 shrink steps):
│
│ length sut
│
│ +++ Messages ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
│
│ Messages for test Array STM tests:
│
│ Gospel specification violation in function length
│
│ File "array.mli", line 7, characters 12-22:
│ i = t.size
│
│ when executing the following sequence of operations:
│
│ open Array
│ let protect f = try Ok (f ()) with e -> Error e
│ let sut = make 16 'a'
│ let r = length sut
│ assert (r = 16)
│ (* returned 42 *)
│
│ ================================================================================
│ failure (1 tests failed, 0 tests errored, ran 1 tests)
└────
Although it has already helped find and fix some bugs, this project is
still fairly new. So, feel free to try it and report any [issue].
Happy testing!
[this repo] <https://github.com/ocaml-gospel/ortac>
[issue] <https://github.com/ocaml-gospel/ortac/issues>
OUPS meetup april 2024
══════════════════════
Archive: <https://discuss.ocaml.org/t/oups-meetup-april-2024/14512/1>
zapashcanon announced
─────────────────────
The next OUPS meetup will take place on *Thursday, 25th of April*
2024. It will start at *7pm* at the *4 place Jussieu* in Paris.
:warning: :trumpet: It will be in the in the *Esclangon building*
(amphi Astier). :trumpet: :warning:
Please, *[register on meetup ]* as soon as possible to let us know how
many pizza we should order.
For more details, you may check the [OUPS’ website ].
This month will feature the following talks :
*Symbolic execution for all with [Owi] and Wasm – Léo Andrès*
WebAssembly (Wasm) is a new binary compilation target adopted by many
high-level programming languages such as C/C++, Rust, Java, and
Go. Building on this foundation, we present Owi, a toolkit to work
with Wasm within the OCaml ecosystem. In particular, Owi features a
reference interpreter for Wasm capable of performing both concrete and
symbolic execution. In this presentation, we describe how we designed
reusable components and a modular interpreter from a concrete one,
enabling the sharing of code between the concrete and symbolic
interpreters. Additionally, we demonstrate how it is possible to
perform symbolic execution of other languages by compiling them to
Wasm using the symbolic interpreter. We provide examples of symbolic
execution applied to C and Rust code and describe our current work to
extend this functionality to support OCaml and other garbage-collected
languages by integrating WasmGC into Owi.
*[Smt.ml] - A Multi Back-end Front-end for SMT Solvers in OCaml –
Filipe Marques*
SMT solvers are crucial tools in fields such as Software Verification,
Program Synthesis, and Test-Case Generation. However, using their
APIs, especially in typed functional languages like OCaml, can be
challenging due to their complexity and lack of user-friendly
interfaces. To address this, we propose Smt.ml, an open-source library
that serves as a single interface for multiple SMT solvers in
OCaml. Currently supporting solvers such as Z3, Colibri2, and
Bitwuzla, Smt.ml enables users to seamlessly work with different
solvers using one unified syntax. The library incorporates built-in
optimizations to handle both concrete and symbolic expressions
efficiently. Smt.ml has been successfully integrated with Owi, an
interpreter and toolkit for WebAssembly. This integration allowed Owi
to perform static symbolic execution and test-case generation for
WebAssembly programs. Notably, Owi was able to identify known
vulnerabilities in a widely-used C data structure libraries.
[register on meetup ]
<https://www.meetup.com/fr-FR/ocaml-paris/events/300474192>
[OUPS’ website ] <https://oups.frama.io>
[Owi] <https://github.com/ocamlpro/owi>
[Smt.ml] <https://github.com/formalsec/encoding>
Mirage 4.5.0 released
═════════════════════
Archive: <https://discuss.ocaml.org/t/mirage-4-5-0-released/14518/1>
Thomas Gazagnaire announced
───────────────────────────
On behalf of the Mirage team, I'm happy to announce the release of
MirageOS 4.5.0. This was merged in `opam-repository' last week, so it
should be available just in time for the upcoming [14th MirageOS hack
retreat]!
This release introduces a significant change in the Mirage tool by
splitting the definition of command-line arguments used at
configure-time and runtime. Command-line arguments used in the
configure script (also called 'configuration keys' and defined in the
`Key' module) are essential during the setup of module dependencies
for the unikernel, allowing for specialized production of a unikernel
for a given target runtime environment. On the other hand,
command-line arguments that the unikernel can use a runtime (defined
in the `Runtime_arg' module) are helpful for customizing deployments
without altering the dependencies of the unikernels.
• API changes:
• There is no more `~stage' parameter for `Key.Arg.info'.
• `Key' now define command-line arguments for the configuration
tool.
• There is a new module `Runtime_arg' to define command-line
arguments for the unikernel.
• As there are no more keys type `'Both', users are now expected to
create two separated keys in that case (one for configure-time,
one for runtime) or decide if the key is useful at runtime of
configure-time.
• Intended use of configuration keys (values of type `'a key'):
• Used to set up module dependencies of the unikernel, such as the
target (hvt, xen, etc.) and whether to use DHCP or a fixed IP
address.
• Enable the production of specialized unikernels suitable for
specific target runtime environments and dedicated network and
storage stacks.
• Similar keys will produce reproducible binaries to be uploaded to
artifact repositories like Docker Hub or
<https://builds.robur.coop/>.
• Intended use of command-line runtime arguments (values of type `a
runtime_arg'):
• Allow users to customize deployments by changing device
configuration, like IP addresses, secrets, block device names,
etc., post downloading of binaries.
• These keys don’t alter the dependencies of the unikernels.
• A runtime keys is just a reference to a normal Cmdliner term.
• `key_gen.ml' is not generated anymore, so users cannot refer to
`Key_gen.<key_name>' directly.
• Any runtime argument has to be declared (using `runtime_arg' and
registered on the device (using `~runtime_args'). The value of
that argument will then be passed as an extra parameter of the
`connect' function of that device.
• Configuration keys are not available at runtime anymore. For
instance, `Key_gen.target' has been removed.
• Code migration:
┌────
│ (* in config.ml *)
│ let key =
│ let doc = Key.Arg.info ~doc:"A Key." ~stage:`Run [ "key" ] in
│ Key.(create "key" Arg.(opt_all ~stage:`Run string doc))
│ let main = main ~keys:[abstract hello] ..
└────
┌────
│ (* in unikernel.ml *)
│ let start _ =
│ let key = Key_gen.hello () in
│ ...
└────
becomes:
┌────
│ (* in config.ml *)
│ let hello = runtime_arg ~pos:__POS__ "Unikernel.hello"
│ let main = main ~runtime_args:[hello] ...
└────
┌────
│ (* in unikernel.ml *)
│ open Cmdliner
│
│ let hello =
│ let doc = Arg.info ~doc:"How to say hello." [ "hello" ] in
│ Arg.(value & opt string "Hello World!" doc)
│
│ let start _ hello =
│ ...
└────
The [mirage-skeleton] repository and a few tutorials on
<https://mirage.io> have been updated and now compile with [mdx] to
check for future API breakage. Documentation PRs are very welcome if
you find some missing updates. We also welcome more general feedback
regarding this API change.
I also would like to use this announcement as a reminder that we have
restarted the mirage bi-weekly calls. Check the [MirageOS mailing
list] or the [MirageOS Matrix channel] for more info. The next one is
planned for the 29th of April. If you are using or planning to use
MirageOS (or are just curious about the project), feel free to join,
it's open to everyone!
Happy hacking!
[14th MirageOS hack retreat] <https://retreat.mirage.io/>
[mirage-skeleton] <https://github.com/mirage/mirage-skeleton>
[mdx] <https://github.com/realworldocaml/mdx>
[MirageOS mailing list]
<https://lists.xenproject.org/archives/html/mirageos-devel/>
[MirageOS Matrix channel]
<https://matrix.to/#/!CokxBnmvmEfvUKOmHg:matrix.org?via=matrix.org&via=recoil.org&via=asra.gr>
patricia-tree 0.9.0 - library for patricia tree based maps and sets
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-patricia-tree-0-9-0-library-for-patricia-tree-based-maps-and-sets/14535/1>
Dorian Lesbre announced
───────────────────────
I'm happy to announce the release of a new `patricia-tree' library,
version 0.9.0 on opam.
This library that implements sets and maps as Patricia Trees, as
described in Okasaki and Gill's 1998 paper [/Fast mergeable integer
maps/]. It is a space-efficient prefix trie over the big-endian
representation of the key's integer identifier.
For full details, visit see [the documentation] or [the source on
github].
[/Fast mergeable integer maps/]
<https://www.semanticscholar.org/paper/Fast-Mergeable-Integer-Maps-Okasaki-Gill/23003be706e5f586f23dd7fa5b2a410cc91b659d>
[the documentation] <https://codex.top/patricia-tree/>
[the source on github]
<https://github.com/codex-semantics-library/patricia-tree>
Features
╌╌╌╌╌╌╌╌
• Similar to OCaml's `Map' and `Set', using the same function names
when possible and the same convention for order of arguments. This
should allow switching to and from Patricia Tree with minimal
effort.
• The functor parameters (`KEY' module) requires an injective `to_int
: t -> int' function instead of a `compare' function. `to_int'
should be fast, injective, and only return positive integers. This
works well with [hash-consed] types.
• The Patricia Tree representation is stable, contrary to maps,
inserting nodes in any order will return the same shape. This allows
different versions of a map to share more subtrees in memory, and
the operations over two maps to benefit from this sharing. The
functions in this library attempt to **maximally preserve sharing
and benefit from sharing**, allowing very important improvements in
complexity and running time when combining maps or sets is a
frequent operation.
• Since our Patricia Tree use big-endian order on keys, the maps and
sets are sorted in increasing order of keys. We only support
positive integer keys. This also avoids a bug in Okasaki's paper
discussed in [/QuickChecking Patricia Trees/] by Jan Mitgaard.
• Supports generic maps and sets: a `'m map' that maps `'k key' to
`('k, 'm) value'. This is especially useful when using [GADTs] for
the type of keys. This is also sometimes called a dependent map.
• Allows easy and fast operations across different types of maps and
set (e.g. an intersection between a map and a set), since all sets
and maps, no matter their key type, are really positive integer sets
or maps.
• Multiple choices for internal representation (`NODE'), which allows
for efficient storage (no need to store a value for sets), or using
weak nodes only (values removed from the tree if no other pointer to
it exists). This system can also be extended to store size
information in nodes if needed.
• Exposes a common interface (`view') to allow users to write their
own pattern matching on the tree structure without depending on the
`NODE' being used.
[hash-consed] <https://en.wikipedia.org/wiki/Hash_consing>
[/QuickChecking Patricia Trees/]
<https://www.cs.tufts.edu/comp/150FP/archive/jan-midtgaard/qc-patricia.pdf>
[GADTs] <https://v2.ocaml.org/manual/gadts-tutorial.html>
Comparison to other OCaml libraries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ ptmap and ptset
There are other implementations of Patricia Tree in OCaml, namely
[ptmap] and [ptset]. These are smaller and closer to OCaml's built-in
Map and Set, however:
• Our library allows using any type `key' that comes with an injective
`to_int' function, instead of requiring `key = int'.
• We support generic (heterogeneous) types for keys/elements.
• We support operations between sets and maps of different types.
• We use a big-endian representation, allowing easy access to min/max
elements of maps and trees.
• Our interface and implementation tries to maximize the sharing
between different versions of the tree, and to benefit from this
memory sharing. Theirs do not.
• These libraries work with older version of OCaml (`>= 4.05' I
believe), whereas ours requires OCaml `>= 4.14'
• Our keys are limited to positive integers.
[ptmap] <https://github.com/backtracking/ptmap>
[ptset] <https://github.com/backtracking/ptset>
◊ dmap
Additionally, there is a dependent map library: [dmap]. It allows
creating type safe dependent maps similar to our heterogeneous
maps. However, its maps aren't Patricia trees. They are binary trees
build using a (polymorphic) comparison function, similarly to the maps
of the standard library. Another difference is that the type of values
in the map is independent of the type of the keys, allowing keys to be
associated with different values in different maps. i.e. we map `'a
key' to any `('a, 'b) value' type, whereas dmap only maps `'a key' to
`'a'.
`dmap' also works with OCaml `>= 4.12', whereas we require OCaml `>=
4.14'.
[dmap] <https://gitlab.inria.fr/bmontagu/dmap>
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
═════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocannl-0-3-1-a-from-scratch-deep-learning-i-e-dense-tensor-optimization-framework/14492/4>
Lukasz Stafiniak announced
──────────────────────────
OCANNL 0.3.2 is out now. Thanks!
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Creating the SyntaxDocumentation Command - Part 1: Merlin]
• [Speeding up MirageVPN and use it in the wild]
• [Frama-C Days 2024]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Creating the SyntaxDocumentation Command - Part 1: Merlin]
<https://tarides.com/blog/2024-04-17-creating-the-syntaxdocumentation-command-part-1-merlin>
[Speeding up MirageVPN and use it in the wild]
<https://blog.robur.coop/articles/miragevpn-performance.html>
[Frama-C Days 2024]
<https://frama-c.com/2024/04/15/Frama-C-Days-2024.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 50297 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-04-16 12:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-04-16 12:00 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 19887 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 09 to 16,
2024.
Table of Contents
─────────────────
Melange 2024 Progress Update
Ppxlib maintenance summary
The OCaml community is signed up for Outreachy!
opam 2.2.0~beta2
Gospel 0.3.0
Fred 0.1.0 - Federal Reserve Economic Data API
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
Other OCaml News
Old CWN
Melange 2024 Progress Update
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-melange-2024-progress-update/14457/1>
Antonio Nuno Monteiro announced
───────────────────────────────
we recently shared what we've been up to around Melange & ecosystem in
a blog post which you can find here:
<https://melange.re/blog/posts/whats-2024-brought-to-melange-so-far>
I hope you find the above informative. Looking forward to your
thoughts.
Ppxlib maintenance summary
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ppxlib-maintenance-summary/14458/1>
Nathan Rebours announced
────────────────────────
I recently started working on ppxlib again thanks to the OCaml
Software Foundation and wanted to report back to the community all the
work their funding made possible so far along with the plan for the
next steps.
Know that OCSF is only funding me part time on this and that I'm open
to more OCaml freelance work!
Summary of the work
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Improved error reporting
Ppxlib has an `-embed-error' flag that is most useful to merlin as it
allows it to always get an AST out of the driver and allows it to keep
operating normally when a ppx raises a located exception (as in raised
with `Location.raise_errorf') as it would always get an AST out of the
driver run.
The problem with this mode was that it didn't try to recover from such
exceptions and would stop applying transformations. The error was
properly reported by merlin and it still had a valid AST to work with
but none of the potential errors from subsequent rewriting or code gen
would be reported. This lead to a tedious workflow where the user
would fix one error, save the file, see a new error reported by
merlin, fix it, save, and so on.
There was a series of PRs by @Burnleydev1 long pending review that
were fixing this by collecting all such exceptions while keeping on
the rewriting phases using the last valid AST or node.
I reviewed and fixed those PRs ([#447], [#453] and [#457]) and worked
on a couple fixes and improvements to error reporting related to this
work.
[#447] <https://github.com/ocaml-ppx/ppxlib/pull/447>
[#453] <https://github.com/ocaml-ppx/ppxlib/pull/463>
[#457] <https://github.com/ocaml-ppx/ppxlib/pull/457>
◊ Driver mode for dune
Dune has ongoing internal work to be able to use ppx in
development. Since it cannot depend on ppxlib or any ppx at build
time, their solution relies on using ppxlib and ppx normally in
development but using already preprocessed copies of source files that
require rewriting for bootstrapping, making their opam build ppx-free.
They require a special driver mode that writes to the output file only
if any actual rewriting happened.
I worked on a first prototype of this using a pre-existing hook called
for each generated AST node.
◊ 5.2 compat on trunk-support
The main task since I started working on ppxlib was the 5.2
support. As OCaml 5.2 is coming out soon and ppxlib is a central piece
in the OCaml ecosystem, it's important that ppxlib has a compatible
version available for testing out the new compiler. Without it, a lot
of opam packages can't be built with the alpha and beta releases of
the compiler because of their ppx dependencies.
ppxlib has a `trunk-support' branch that is meant to be kept up to
date for such occasions. While it already contained the AST migration
from/to the 5.2 version, it was out of sync with the main branch of
ppxlib.
I rebased the 5.2 relevant parts of the branch on top of our main
branch to be able to cut a first preview version with 5.2 compat and
fixed a couple of bugs and quirks in the code base that prevented the
test suite from running properly with the 5.2 support.
After the first release of the preview version we discovered a series
of bugs with the help of @kit-ty-kate, @octachron and @anmonteiro. The
most important among those being:
• A bug in the round trip migration of the new `Pexp_function' node
from 5.2 that was causing compilation errors when the function's
return type was coerced.
• The new syntax for `ocaml.ppx.context' was causing driver crashes
when reading some binary ASTs. I wrote a migration for those
attributes that fixed the issue.
• The driver was silently relying on the compiler to re-open files to
display source quotation when reporting located exceptions.
Since this was removed from the compiler in 5.2, I fixed the driver to
properly set `Location.input_lexbuf' and re-enable source-quotation.
◊ ppx_deriving maintenance
`ppx_deriving' is quite a central piece of the ppx ecosystem,
especially for the set of standard derivers it provides
(pretty-printers, equality and comparison functions, etc.).
The project was lacking maintainers with enough time to review an
important PR migrating those standard derivers to ppxlib. This is
important because it makes those quite broadly used derivers better
integrated with ppxlib features and improves both performances and
error reporting for their users as they are now applied as part of the
main ppxlib driver AST traversal.
I reviewed the PR and cleaned up the repo a bit to attempt a release,
something that has not happened for 3 years for this package.
The initial release failed for two reasons:
• `ppx_deriving.show''s deriver accepts an argument that specifies how
the implementation should behave without impacting the
function signature. In the ppxlib port we did not register this
argument for the signature deriver since it had no impact on the
generated code there. It turns out at least one opam package used the
argument in an `.mli' file so we added it for compatibility as
`ppx_deriving' duplicated the set of arguments for implementation and
interfaces
• `ppx_deriving' used to automatically register extensions for each
derivers that can be used to inline the derived function for a
given type in an expression. We preserved this in the ppxlib port but
it caused a conflict with `ppx_let'. This conflict should be resolved
on `ppx_let''s side as they were declaring an extension named `map'
without any possible prefix such as `ppx_let.map' which is the
recommended way. Using a prefix allows the user to disambiguate if
several ppx declare an extension with the same base name.
We had to cancel the release to fix those issues before attempting
again.
◊ General maintenance
There was also some regular maintenance such as improving our homemade
expect test runner to be able to better run our tests across all
supported compiler versions, reviewing all pending PRs, upgrading
ocamlformat and cutting a release of ppxlib with the latest features.
Next steps
╌╌╌╌╌╌╌╌╌╌
Along with the general maintenance of the project there are two things
that would greatly reduce the maintenance burden on ppxlib and would
improve the state of the ecosystem for the community that we would
like to work on.
◊ Upstreaming Astlib to the compiler
This has been in the works for quite a long time but the previous
maintainers haven't had the chance to see it through.
The plan is to upstream a small part of ppxlib into the compiler to
ease the release process for new compilers.
This small library should contain the minimal subset of stable API
ppxlib needs to properly function and, most importantly, the AST
migrations from the current version of the compiler to the previous
version and back. The idea is that trunk would then provide the
migration to the latest released version at all time and ppxlib would
be able to use those if it does not natively supports them yet. That
would make testing the compiler on opam work without requiring a
special release of ppxlib and would also ease the migration writing
process as they would be written at the time of the AST change by the
person who modified it and therefore that is most qualified to do so.
Indeed the migration writing process is time consuming at the moment
because it is done by ppxlib maintainers when the next ocaml releasing
is closing in and requires us to dive into changes we are not
necessarily familiar with.
During the compiler release process, ppxlib would incorporate those
new migration to the entire set of migrations it supports, allowing it
to be compatible with the "new" trunk until the next release.
The core of this work is to formally write down this process and start
the discussion with the compiler team. Once we agree on a plan, I
don't expect there is a lot of code to write for this as all of it
already lives inside ppxlib.
◊ Refining the release process for ppxlib with an AST bump
Part of the ppxlib contract is that all ppx-es written with ppxlib
must use the same version of the AST chosen by ppxlib. This allows for
better performances and semantics of rewriting. This version is
usually the latest supported version as it is required for ppx-es to
support all the new language features. It sometimes happen that the
internal AST version lags behind if no new features would be
"unlocked" by upgrading the AST, as it has been the case since 4.14.
Every now and then ppxlib has to bump its internal AST though,
potentially breaking its API and therefore a few of its reverse
dependencies.
In the past few years, we decided to build the entire set of reverse
dependencies every time were releasing such a change and to send PRs
to fix revdeps to help keep the ppx ecosystem sane and avoid putting
to much pressure on individual ppx-es maintainers.
We know that we will have to do this for the 5.3 release as it will be
adding effects syntax.
The current workflow relies on building a "duniverse" i.e. some sort
of large dune-project containing ppxlib and a clone of all its reverse
dependencies. This proves quite a challenge as it is often hard to get
everything to build together. An ideal solution would be to rely more
on `opam-ci' for this but in its current state it is not very
reliable.
I'd like to spend some time on improving the process of building
revdeps of ppxlib and submitting PRs and experiment to prepare for the
next bump which will include the 5.2 changes to `Pexp_function' that
we expect to potentially break quite a lot of reverse dependencies.
The OCaml community is signed up for Outreachy!
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/the-ocaml-community-is-signed-up-for-outreachy/13892/18>
Nathan Rebours announced
────────────────────────
I'm a bit late to the party but still wanted to let you know about the
project we submitted with @shonfeder and @dinakajoy.
[ocaml-api-watch] is a fresh project that aims at providing a suite of
tools to help OCaml library maintainers and users deal with changes in
the public API of their libraries or the ones they use. This includes
libraries and CLI tools to detect potentially unwanted breaking
changes before releasing a new version or to determine the version of
a library that introduced a new function.
The goal of the internship is to develop a library and tool pair that
detects changes in the public API of a library, build an internal
representation of them and displays them in a human readable, git
diff-like format.
The application period went really well and we have several strong
candidates. We've been extremely happy to work with all of them and
are looking forward to the internship.
[ocaml-api-watch] <https://github.com/NathanReb/ocaml-api-watch>
opam 2.2.0~beta2
════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-2-0-beta2/14461/1>
Kate announced
──────────────
We're very excited to announce this second beta for opam 2.2.0.
What’s new in this beta?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• *Windows support*: this beta introduces a bunch of changes necessary
to be able to make the default opam-repository support Windows out
of the box. We will write a dedicated blog post very soon on this,
once we have finalised the PR/branch that you can test.
• *opam-repository scalability*: The current draft resolution
resulting from the discussion in [ocaml/opam-repository#23789]
includes the removal of packages from opam-repository. Currently
opam can misbehave (in particular on macOS) when exposed to file
deletions in repositories due to the use of the system `patch`
command. To fix this, as a stop gap, after many trials and errors,
opam now warns when GNU patch is not detected on your system. These
changes will make their way to the upcoming opam 2.1.6, in a few
weeks.
• Many *regression fixes*, *performance* and general *improvements*
:open_book: You can read our [blog post] for more information about
these changes and more, and for even more details you can take a look
at the [release note] or the [changelog].
[ocaml/opam-repository#23789]
<https://github.com/ocaml/opam-repository/issues/23789>
[blog post] <https://opam.ocaml.org/blog/opam-2-2-0-beta2/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.2.0-beta2>
[changelog] <https://github.com/ocaml/opam/blob/2.2.0-beta2/CHANGES>
How to upgrade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• For Windows we will write a dedicated blog post to show how to
install and use opam on Windows very soon. Stay tuned!
• On Unix-like systems, to upgrade, simply run:
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.2.0~beta2"
└────
We're on the home stretch for the final release of opam 2.2.0, so feel
free to report any issue you encounter on our [bug-tracker].
Happy hacking, *<> <> The opam team <> <>* :camel:
[bug-tracker] <https://github.com/ocaml/opam/issues>
Gospel 0.3.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-gospel-0-3-0/14480/1>
Nicolas Osborne announced
─────────────────────────
Hi! We are very happy to announce the release of `gospel.0.3.0'
Gospel is a tool-agnostic behavioural specification language for
OCaml. It allows you to write strongly typed contract-based
specifications for your OCaml libraries (for a reasonable subset of
OCaml). Gospel’s syntax has been designed to be easy to learn for an
OCaml programmer. You can access the documentation [here]
Apart from some bug fixes, this release brings two main improvements:
• Make the type-checker save type information in a `.gospel' file
• Make the `with' keyword necessary when declaring type invariants
Beware that `ortac.0.1.0' is not compatible with this version, please
use Ortac development version from the git repository until the next
Ortac release.
[here] <https://ocaml-gospel.github.io/gospel/>
Fred 0.1.0 - Federal Reserve Economic Data API
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-fred-0-1-0-federal-reserve-economic-data-api/14489/1>
Geoffrey Borough announced
──────────────────────────
Hi folks howdy! I just release the first version of Fred, a library
for the Federal Reserve Economic Data API binding. I made this to
facilitate one of my personal project but I hope others would find
this library useful in some way.
Source code: <https://github.com/gborough/fred>
Documentation: <https://gborough.github.io/fred/fred/fred/index.html>
Opam repo publish on the way
OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
═════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocannl-0-3-1-a-from-scratch-deep-learning-i-e-dense-tensor-optimization-framework/14492/1>
Lukasz Stafiniak announced
──────────────────────────
Hi! I'm happy to announce release 0.3.1 of OCANNL, a tensor
optimization framework with:
• concise notation via PPXs,
• powerful shape inference,
• backpropagation (first-order automatic differentiation),
• low-level backends – currently only one, CPU via `gccjit`, but Cuda
is on the horizon.
OCANNL is sponsored by [Ahrefs]. ([Ahrefs website].)
[ahrefs/ocannl: OCANNL: OCaml Compiles Algorithms for Neural Networks
Learning (github.com)]
I am not submitting it to Opam yet as OCANNL is insufficiently
documented at the moment. I welcome your feedback if you decide to
take a look!
[Ahrefs] <https://ocaml.org/success-stories/peta-byte-scale-web-crawler>
[Ahrefs website] <https://ahrefs.com/>
[ahrefs/ocannl: OCANNL: OCaml Compiles Algorithms for Neural Networks
Learning (github.com)] <https://github.com/ahrefs/ocannl>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Multicore Testing Tools: DSCheck Pt 2]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Multicore Testing Tools: DSCheck Pt 2]
<https://tarides.com/blog/2024-04-10-multicore-testing-tools-dscheck-pt-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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 31912 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-04-09 9:15 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-04-09 9:15 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 37466 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 02 to 09,
2024.
Table of Contents
─────────────────
moonpool 0.6
sqids 0.1.0
OCaml Retreat at Auroville, India (March 10th - March 15th)
Miou, a simple scheduler for OCaml 5
OCaml.org Newsletter: March 2024
Opam 102: Pinning Packages, by OCamlPro
dune 3.15
Ocsigen: summary of recent releases
Js_of_ocaml 5.7
Eio Developer Meetings
Ocaml developer at Routine, Paris
dream-html 3.0.0
Other OCaml News
Old CWN
moonpool 0.6
════════════
Archive: <https://discuss.ocaml.org/t/ann-moonpool-0-6/14424/1>
Simon Cruanes announced
───────────────────────
Dearest friends of the dual hump,
I'm happy to announce the release of [moonpool 0.6]. Moonpool is a
library of schedulers and concurrency primitives for OCaml 4.xx and
5.xx, based on threads (possibly spread on multiple domains). Previous
release announcements ([0.5], [0.4], [0.3], [0.2], [0.1]) contain more
details.
This release is fairly large and contains some new libraries. The
biggest improvement is the addition of `moonpool.fib' (OCaml 5 only):
it defines lightweight _fibers_ with structured concurrency, where the
fibers can run on a thread pool chosen by the user. Fibers also come
with fiber-local storage and a notion of cancellation that is
propagated to children fibers. Overall, fibers are a nicer abstraction
than bare futures (especially with monadic combinators). There are
currently no cooperative IO primitives provided by the scheduler but I
have plans.
Another new, more experimental library is `moonpool-lwt' (OCaml 5
only) which allows for interoperability between Lwt and moonpool: a
moonpool future (or fiber) can be turned into a Lwt promise; and it
becomes possible to `await' a Lwt promise from moonpool, in a
thread-safe way.
Docs:
• [moonpool]
• [moonpool-lwt]
[moonpool 0.6] <https://github.com/c-cube/moonpool/releases/tag/v0.6>
[0.5] <https://discuss.ocaml.org/t/ann-release-of-moonpool-0-5/13387>
[0.4] <https://discuss.ocaml.org/t/ann-moonpool-0-4/12941>
[0.3] <https://discuss.ocaml.org/t/ann-moonpool-0-3/12632>
[0.2] <https://discuss.ocaml.org/t/ann-moonpool-0-2/12447>
[0.1] <https://discuss.ocaml.org/t/ann-moonpool-0-1/12387>
[moonpool] <https://c-cube.github.io/moonpool/moonpool/index.html>
[moonpool-lwt]
<https://c-cube.github.io/moonpool/moonpool-lwt/index.html>
sqids 0.1.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-sqids-0-1-0/14425/1>
Leo Soares announced
────────────────────
I'm happy to announce the first release (0.1.0) of the [official OCaml
port of Sqids].
Sqids (pronounced "squids") is an open-source library that
lets you generate short unique identifiers from
numbers. These IDs are URL-safe, can encode several
numbers, and do not contain common profanity words.
<https://opam.ocaml.org/packages/sqids>
[official OCaml port of Sqids] <https://sqids.org/ocaml>
OCaml Retreat at Auroville, India (March 10th - March 15th)
═══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-retreat-at-auroville-india-march-10th-march-15th/14006/4>
Sudha Parimala announced
────────────────────────
I'm happy to share the experience report from the first OCaml Retreat:
<https://ocamlretreat.org/2024/03/24/retreat-experience.html>. Thanks
to all the participants for contributing to the magic of the event. We
hope to run more such retreats in the future!
Miou, a simple scheduler for OCaml 5
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-miou-a-simple-scheduler-for-ocaml-5/12963/14>
Calascibetta Romain announced
─────────────────────────────
I am delighted to announce the release of `miou.0.1.0'. This release
is undoubtedly the culmination and synthesis of the work of several
individuals to offer a library that best fits our needs. We're quite
convinced by the API we're proposing and quite happy with the
implementation. As such, we're coming out of beta to offer version
0.1.0. Above all, this means that the API will change very little, and
the library is now ready for use. However, we are not yet in 1.0.0
because we would like to give you time to use Miou, to observe
possible bugs, and to give us time to correct these possible bugs in
order to prepare version 1.0.0 with peace of mind. You can install the
package via OPAM (it will be available soon):
┌────
│ $ opam install miou
└────
We would sincerely like to thank all individuals who have contributed,
whether directly or indirectly, to the project.
Furthermore, this new version of Miou builds upon the excellent work
of @polytypic and his [picos] project. We have incorporated certain
elements that are suitable for implementing a scheduler, and we hope
that our efforts will lead to a certain standardization of the effects
used by different schedulers in OCaml.
This rewrite has been carried out while trying to maintain the same
semantics and API as what we offered in version `0.0.1~beta2'
(however, it is the nature of a beta to potentially break
versions). This rewrite culminated in the reimplementation of an [HTTP
client and server] (supporting http/1.1 or h2 with TLS which can
handle [200k req/sec]) as well as our good old [happy-eyeballs]
example. Moreover, the outcome of these implementations is more
satisfying to us than their previous versions. At least for now,
considering the various changes our cooperative has embarked on¹, we
will not yet release them.
We also took the time to integrate a version of the priority queue
verified using [Why3]. We would like to thank @Armael and
@backtracking (as well as the individuals who contributed to and
maintained the [Vocal] project) for their assistance.
Finally, I would like to personally thank the [Robur] cooperative for
providing me with the necessary time to evolve this project.
This release further confirms what we aim to offer to users, and in
this regard, we have taken the time to write a small book explaining
the use of Miou. This can also be seen as an introduction to
asynchronous programming and effects. It is available [here] and is
part of the Miou distribution.
For any questions or assistance, we are available via email, this
forum, or Discord.
Happy hacking!
*¹*: As explained in [this article], we try to replace `Cstruct.t' by
`string' and it requires obviously a deep change across severals
packages.
[picos] <https://github.com/ocaml-multicore/picos>
[HTTP client and server] <https://github.com/robur-coop/httpcats>
[200k req/sec]
<https://twitter.com/Dinoosaure/status/1775586989749788745>
[happy-eyeballs] <https://github.com/robur-coop/miou/tree/main/happy>
[Why3] <https://www.why3.org/>
[Vocal] <https://github.com/ocaml-gospel/vocal>
[Robur] <https://robur.coop/>
[here] <https://robur-coop.github.io/miou/>
[this article]
<https://blog.robur.coop/articles/speeding-ec-string.html>
OCaml.org Newsletter: March 2024
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-org-newsletter-march-2024/14431/1>
Sabine Schmaltz announced
─────────────────────────
Welcome to the March 2024 edition of the OCaml.org newsletter! This
update has been compiled by the OCaml.org team. You can find [previous
updates] on Discuss.
Our goal is to make OCaml.org the best resource for anyone who wants
to get started and be productive in OCaml. The OCaml.org newsletter
provides an update on our progress towards that goal and an overview
of the changes we are working on.
We couldn't do it without all the amazing OCaml community members who
help us review, revise, and create better OCaml documentation. Your
feedback enables us to better prioritise our work. Thank you!
This newsletter covers:
• *OCaml Cookbook:* A prototype of an OCaml cookbook that provides
short code examples that solve practical problems using packages
from the OCaml ecosystem is on staging.ocaml.org/cookbook.
• *Dark Mode:* We enabled the dark mode on all pages of OCaml.org,
based on your operating system / browser settings.
• *Community & Marketing Pages Rework:* We are seeking feedback on
wireframes for the community section and for the marketing-related
pages.
• *General Improvements:* As usual, we also worked on general
maintenance and improvements based on user feedback, so we're
highlighting some of our work below.
[previous updates] <https://discuss.ocaml.org/tag/ocamlorg-newsletter>
Open Issues for Contributors
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
You can find [open issues for contributors here]!
[open issues for contributors here]
<https://github.com/ocaml/ocaml.org/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+no%3Aassignee>
Upcoming OCaml Cookbook
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We're in the process of adding a community-driven section to the Learn
area: the OCaml Cookbook. This cookbook is designed as a collection of
recipes, offering code samples for tackling real-world tasks using
packages from the OCaml ecosystem. It's a practical effort to enrich
our learning resources, making them more applicable and useful for our
community.
This month, our focus shifted towards finalizing the cookbook for
release. This includes
• restructuring the directory structure and placement of recipe files,
and
• adding tasks to the cookbook, so that you can contribute recipes for
these tasks (we took inspiration from the excellent [Rust
Cookbook]).
It will always be possible to propose more tasks for the OCaml
Cookbook. The main criteria here are:
1. task must require more than just a single Standard Library function
call to solve,
2. task must be focused on common problems that occur when trying to
build products,
3. if in doubt, make the task more specific, instead of more generic.
A good place to give feedback on the cookbook is [this discuss
thread].
*Relevant PRs and Activities:*
• [(WIP) Cookbook compression / decompression] by @F-Loyer
• [Cookbook : fix in Lwt (type mismatch with iter_s/iter_p functions)]
by @F-Loyer
• [Update 00-caqti-ppx-rapper.ml - fix caqti-driver-sqlite ->
caqti-driver-sqlite3] by @F-Loyer
[Rust Cookbook] <https://rust-lang-nursery.github.io/rust-cookbook/>
[this discuss thread]
<https://discuss.ocaml.org/t/feedback-help-wanted-upcoming-ocaml-org-cookbook-feature/14127/10>
[(WIP) Cookbook compression / decompression]
<https://github.com/ocaml/ocaml.org/pull/2133>
[Cookbook : fix in Lwt (type mismatch with iter_s/iter_p functions)]
<https://github.com/ocaml/ocaml.org/pull/2127>
[Update 00-caqti-ppx-rapper.ml - fix caqti-driver-sqlite ->
caqti-driver-sqlite3] <https://github.com/ocaml/ocaml.org/pull/2126>
Dark Mode Released
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We're happy to anounce that we shipped the Dark Mode for
OCaml.org. Dark mode is activated based on your operating system /
browser settings. If you see anything wrong, please open an issue and
include the URL on which you're seeing a problem.
*Relevant PRs and Activities:*
• [Announce Dark Mode on Discuss]
• [Add Preliminary Dark Mode for Package Documentation] by @sabine
• [Fix: dark text color on blue background] by @amarachigoodness74
• [(dark mode) adjust breadcrumbs text color] by @sabine
• [(ui) Activate Dark Mode] by @sabine
• [Correctly invert text on "Is OCaml Web" page] by @SquidDev
• [fix: add missing darkmode styles for in-package search results] by
@sabine
• [Remove legacy tailwind colors and styles, tidy up darkmode colors]
by @sabine
[Announce Dark Mode on Discuss]
<https://discuss.ocaml.org/t/announcing-the-new-dark-mode-on-ocaml-org/14273>
[Add Preliminary Dark Mode for Package Documentation]
<https://github.com/ocaml/ocaml.org/pull/2159>
[Fix: dark text color on blue background]
<https://github.com/ocaml/ocaml.org/pull/2138>
[(dark mode) adjust breadcrumbs text color]
<https://github.com/ocaml/ocaml.org/pull/2161>
[(ui) Activate Dark Mode] <https://github.com/ocaml/ocaml.org/pull/2160>
[Correctly invert text on "Is OCaml Web" page]
<https://github.com/ocaml/ocaml.org/pull/2191>
[fix: add missing darkmode styles for in-package search results]
<https://github.com/ocaml/ocaml.org/pull/2299>
[Remove legacy tailwind colors and styles, tidy up darkmode colors]
<https://github.com/ocaml/ocaml.org/pull/2301>
Homepage & Marketing Pages Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The Home page project kicked off with an analysis of user surveys and
interviews, and the development of an initial wireframe for the
homepage and the "Industrial Users" and "Academic Users" pages.
We've been [reaching out to the community on Discuss] and Twitter to
find what people say about OCaml, so we can give a bit more context
through testimonials on the "Academic Users" page.
Besides this, we've been [asking on Twitter for ideas for the main
tagline of the homepage]
You can comment on the wireframes in Figma [here].
If you have opinions on the homepage, feel free to share them in [this
discuss thread]!
[reaching out to the community on Discuss]
<https://discuss.ocaml.org/t/academic-ocaml-users-testimonials/14338>
[asking on Twitter for ideas for the main tagline of the homepage]
<https://x.com/sabine_s_/status/1772264108479467629?s=20>
[here]
<https://www.figma.com/file/eLNSdvayxqvvfBsRsdbJXN/OCaml-Home-Page?type=design&node-id=5%3A2500&mode=design&t=hHclskuVpoOzKP2u-1>
[this discuss thread]
<https://discuss.ocaml.org/t/your-feedback-needed-on-ocaml-home-page-wireframe/14366>
Community Section Rework
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This week, we focused on creating wireframes for the Event, Job,
Internship, and Workshop pages, followed by soliciting feedback from
the community via Discuss. Concurrently, work commenced on the UI
design for the Community Landing page, as well as the Event and Job
pages.
We also made some improvements to the Events section on the Community
page. This involves better treatment of start/end times of events, as
well as listing more upcoming events.
If you have opinions on the community section, feel free to share them
in [this discuss thread]!
*Relevant PRs and Activities:*
• Invite people to add events to events directory:
<https://discuss.ocaml.org/t/add-your-ocaml-events-to-the-community-page-on-ocaml-org/14251>
• [Improve Events Directory] by @sabine
• [Fix template bug on upcoming events list] by @sabine
• [Make clear upcoming event time is UTC] by @sabine
• Data contributed to events:
• [(data) Add S-REPLS event] by @sabine
• [(data) fix wrong date on event] by @sabine
• [(data) Add OCaml Retreat Auroville] by @D8kTwoXfSUWLdpXruFrQiw
• [(data) add OCaml Manila Meetup] by @sabine
[this discuss thread]
<https://discuss.ocaml.org/t/looking-for-ideas-for-the-community-page-at-ocaml-org/14032/9>
[Improve Events Directory]
<https://github.com/ocaml/ocaml.org/pull/2132>
[Fix template bug on upcoming events list]
<https://github.com/ocaml/ocaml.org/pull/2136>
[Make clear upcoming event time is UTC]
<https://github.com/ocaml/ocaml.org/pull/2307>
[(data) Add S-REPLS event]
<https://github.com/ocaml/ocaml.org/pull/2135>
[(data) fix wrong date on event]
<https://github.com/ocaml/ocaml.org/pull/2143>
[(data) Add OCaml Retreat Auroville]
<https://github.com/ocaml/ocaml.org/pull/2134>
[(data) add OCaml Manila Meetup]
<https://github.com/ocaml/ocaml.org/pull/2305>
Outreachy Application Period & Internship
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
In March, OCaml.org hosted the application period for one [Outreachy
internship] on creating an interactive experience for solving OCaml
exercises.
The process of selecting an Outreachy intern involved creating and
managing 15 issues, reviewing 61 pull requests from 8 applicants. The
tasks were similar in nature and dealt with restructuring the
exercises to enable an interactive experience, adding test cases and
solutions (where missing).
*Relevant PRs and Activities:*
• [Create practice folder] by @cuihtlauac
• [Sort exercises by slug before emitting template] by @csaltachin
• Turning exercises into practice @Ozyugoo, @mnaibei,
@divyankachaudhari, @Kxrishx03, @maha-sachin, @MissJae, @jahielkomu,
@Appleeyes
[Outreachy internship] <https://www.outreachy.org/>
[Create practice folder] <https://github.com/ocaml/ocaml.org/pull/2166>
[Sort exercises by slug before emitting template]
<https://github.com/ocaml/ocaml.org/pull/2227>
General Improvements and Data Additions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Relevant PRs and Activities:*
• (WIP) we're moving the OCaml Language Manual from v2.ocaml.org to
ocaml.org
• set up dlvr.it to automatically post RSS feed items from OCaml
Planet and OCaml Changelog to new ocaml_org Twitter account
• [Link to recently added videos on watch.ocaml.org] by @sabine
• [Change twitter account from OCamlLang to ocaml_org] by @sabine
• [fix: small improvements on news.eml] by @sabine
• [is yet category slug] by @cuihtlauac
• [Add a badge from the green web foundation to the carbon footprint
page] by @0xrotense
• Deployment of odoc 2.4.1 to package documentation pipeline:
• [Compatibility with odoc.2.4.1] by @gpetiot
• [Patch for voodoo / odoc 2.4.1 upgrade] by @sabine
• [chore: set doc url to live, after voodoo upgrade] by @sabine
• Data:
• [(data) add ocaml.org newsletter February] by @sabine
• [Changelog entry for OCaml 4.14.2~rc1] by @Octachron
• [Add dune.3.14.2 announcement] by @Leonidas-from-XIV
• [OCaml 4.14.2 release and changelog pages] by @Octachron
• [OCaml 4.14.2: fix release year] by @edwintorok
• [Add Platform changelogs for February 2024] by @tmattio
• [Changelog entry for OCaml 5.2.0~beta1] by @Octachron
• [Add Outreachy winter 2023 round] by @patricoferris
• Documentation:
• [DOC: note about windows ppx_show] by @heathhenley
• [(docs) Fix small typos] by @kenranunderscore
• [(docs) Add link for instances of Array] by @rmeis06
• [Linking exercise to tutorials] by @rmeis06
• [Explain why t-first works with labels ] by @mikhailazaryan
• [Document that begin … end use] by @rmeis06
• [Use uniform syntax for eval steps] by @cuihtlauac
• [Linking mentions of atomic module to doc] by @rmeis06
• [Linking Bigarray references] by @rmeis06
• [(docs) fix example in 'Libraries With Dune'] by @0xRamsi
• [Fix typo in 4ad_01_operators.md] by @vog
• [(docs) Use DkML 2.1.0] by @jonahbeckford
[Link to recently added videos on watch.ocaml.org]
<https://github.com/ocaml/ocaml.org/pull/2128>
[Change twitter account from OCamlLang to ocaml_org]
<https://github.com/ocaml/ocaml.org/pull/2111>
[fix: small improvements on news.eml]
<https://github.com/ocaml/ocaml.org/pull/2295>
[is yet category slug] <https://github.com/ocaml/ocaml.org/pull/2303>
[Add a badge from the green web foundation to the carbon footprint page]
<https://github.com/ocaml/ocaml.org/pull/2241>
[Compatibility with odoc.2.4.1]
<https://github.com/ocaml-doc/voodoo/pull/128>
[Patch for voodoo / odoc 2.4.1 upgrade]
<https://github.com/ocaml/ocaml.org/pull/2300>
[chore: set doc url to live, after voodoo upgrade]
<https://github.com/ocaml/ocaml.org/pull/2304>
[(data) add ocaml.org newsletter February]
<https://github.com/ocaml/ocaml.org/pull/2154>
[Changelog entry for OCaml 4.14.2~rc1]
<https://github.com/ocaml/ocaml.org/pull/2145>
[Add dune.3.14.2 announcement]
<https://github.com/ocaml/ocaml.org/pull/2190>
[OCaml 4.14.2 release and changelog pages]
<https://github.com/ocaml/ocaml.org/pull/2225>
[OCaml 4.14.2: fix release year]
<https://github.com/ocaml/ocaml.org/pull/2286>
[Add Platform changelogs for February 2024]
<https://github.com/ocaml/ocaml.org/pull/2288>
[Changelog entry for OCaml 5.2.0~beta1]
<https://github.com/ocaml/ocaml.org/pull/2291>
[Add Outreachy winter 2023 round]
<https://github.com/ocaml/ocaml.org/pull/2244>
[DOC: note about windows ppx_show]
<https://github.com/ocaml/ocaml.org/pull/2094>
[(docs) Fix small typos] <https://github.com/ocaml/ocaml.org/pull/2152>
[(docs) Add link for instances of Array]
<https://github.com/ocaml/ocaml.org/pull/2146>
[Linking exercise to tutorials]
<https://github.com/ocaml/ocaml.org/pull/2148>
[Explain why t-first works with labels ]
<https://github.com/ocaml/ocaml.org/pull/2157>
[Document that begin … end use]
<https://github.com/ocaml/ocaml.org/pull/2147>
[Use uniform syntax for eval steps]
<https://github.com/ocaml/ocaml.org/pull/2183>
[Linking mentions of atomic module to doc]
<https://github.com/ocaml/ocaml.org/pull/2153>
[Linking Bigarray references]
<https://github.com/ocaml/ocaml.org/pull/2163>
[(docs) fix example in 'Libraries With Dune']
<https://github.com/ocaml/ocaml.org/pull/2247>
[Fix typo in 4ad_01_operators.md]
<https://github.com/ocaml/ocaml.org/pull/2219>
[(docs) Use DkML 2.1.0] <https://github.com/ocaml/ocaml.org/pull/2249>
Opam 102: Pinning Packages, by OCamlPro
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-opam-102-pinning-packages-by-ocamlpro/14437/1>
OCamlPro announced
──────────────────
Greetings Cameleers,
Here’s another heads up for all opam users: [Opam 102: Pinning
Packages], our latest blog post breaking down opam for the community;
as a keen eye would have already guessed, today's subject is package
pinning!
We hope that this may be useful to anybody curious about getting
acquainted with opam's pins. This article is made for whom wonders how
they work and when they are useful to be aware of.
Hoping that it may serve as a reference for all newcomers to the
ecosystem.
We appreciate and are thankful for every reader, we welcome all your
feedback, right here, in this thread. :smile:
Kind regards, The OCamlPro Team
[Opam 102: Pinning Packages]
<https://ocamlpro.com/blog/2024_03_25_opam_102_pinning_packages/>
dune 3.15
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-15/14438/1>
Marek Kubica announced
──────────────────────
We're happy to announce that Dune 3.15.0 is now available. This
feature has many fixes and new features that you can find in the
changelog.
There are a few new features that we would like to specially
highlight.
Removal of previous limitations in many forms
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Prior to Dune 3.15 there were a number of limitations where percent
forms like `%{env:...}' could be used to expand to useful values. In
this release, @rgrinberg put some effort to relax a lot of these
restrictions where possible.
In the new version some of these limitations have been lifted, so for
example `{env:...}' can be used in `install' stanzas ([#10160]).
Likewise there was no consistency where `%{cma:...}' or `%{cmo:...}'
could be used. With [#10169], these forms should work consistently
everywhere.
Similarly the variables allowed in `enabled_if' fields have been
expanded in [#10250], from just allowing variables that can be
computed from the context to now allowing all variables as long as
expanding these variables does not introduce dependency cycles.
These relaxed rules can also be combined to enable a library depending
on environment variables, e.g. `(enabled_if
%{env:ENABLE_LIBFOO=false}))'.
[#10160] <https://github.com/ocaml/dune/pull/10160>
[#10169] <https://github.com/ocaml/dune/pull/10169>
[#10250] <https://github.com/ocaml/dune/pull/10250>
Overlapping names in different contexts
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Continuing the theme of conditionally enabling or disabling code to be
built, @jchavarri and @rgrinberg's work on [#10220] makes it possible
to have overlapping names between `executable' and `melange.emit'
targets. This can be useful when a name is to be shared in different
contexts (e.g. one context with native compilation and one emitting
code for the browser).
[#10220] <https://github.com/ocaml/dune/pull/10220>
Properly output UTF-8 encoded text when formatting
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Dune does not assume an encoding of dune files, however when files
were formatted the formatter would err on the safe side and escape
bytes outside the ASCII range. This means that UTF-8 characters
outside of ASCII would get escaped into decimal escape sequences.
This was especially annoying in places where the user would write
natural language texts, which is common when defining Opam packages in
`dune-project' files. For example a discussion of a paper by Paul
Erdős, Peter Frankl, Vojtěch Rödl would upon reformatting be turned
into Paul Erd\\197\\145s, Peter Frankl, Vojt\\196\\155 R\\195\\182,
which does a disservice to these scientists and is hard to read.
Thanks to the work of @moyodiallo in [#9728] starting with Dune 3.15
the original encoding will be preserved, so your package descriptions
will be more readable.
[#9728] <https://github.com/ocaml/dune/pull/9728>
Changelog
╌╌╌╌╌╌╌╌╌
◊ Added
• Add link flags to to `ocamlmklib' for ctypes stubs (#8784,
@frejsoya)
• Remove some unnecessary limitations in the expansions of percent
forms in install stanza. For example, the `%{env:..}' form can be
used to select files to be installed. (#10160, @rgrinberg)
• Allow artifact expansion percent forms (`%{cma:..}', `%{cmo:..}',
etc.) in more contexts. Previously, they would be randomly forbidden
in some fields. (#10169, @rgrinberg)
• Allow `%{inline_tests}' in more contexts (#10191, @rgrinberg)
• Remove limitations on percent forms in the `(enabled_if ..)' field
of libraries (#10250, @rgrinberg)
• Support dialects in `dune describe pp' (#10283, @emillon)
• Allow defining executables or melange emit stanzas with the same
name in the same folder under different contexts. (#10220,
@rgrinberg, @jchavarri)
◊ Fixed
• coq: Delay Coq rule setup checks so OCaml-only packages can build in
hybrid Coq/OCaml projects when `coqc' is not present. Thanks to
@vzaliva for the test case and report (#9845, fixes #9818,
@rgrinberg, @ejgallego)
• Fix conditional source selection with `select' on `bigarray' in
OCaml 5 (#10011, @moyodiallo)
• melange: fix inconsistency in virtual library
implementation. Concrete modules within a virtual library can now
refer to its virtual modules too (#10051, fixes #7104, @anmonteiro)
• melange: fix a bug that would cause stale `import' paths to be
emitted when moving source files within `(include_subdirs ..)'
(#10286, fixes #9190, @anmonteiro)
• Dune file formatting: output utf8 if input is correctly encoded
(#10113, fixes #9728, @moyodiallo)
• Fix expanding dependencies and locks specified in the cram
stanza. Previously, they would be installed in the context of the
cram test, rather than the cram stanza itself (#10165, @rgrinberg)
• Fix bug with `dune exec --watch' where the working directory would
always be set to the project root rather than the directory where
the command was run (#10262, @gridbugs)
• Regression fix: sign executables that are promoted into the source
tree (#10263, fixes #9272, @emillon)
• Fix crash when decoding dune-package for libraries with
`(include_subdirs qualified)' (#10269, fixes #10264, @emillon)
Changed
╌╌╌╌╌╌╌
• Remove the `--react-to-insignificant-changes' option. (#10083,
@rgrinberg)
Ocsigen: summary of recent releases
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocsigen-summary-of-recent-releases/13817/8>
Vincent Balat announced
───────────────────────
Eliom 10.4:
• Basic client-server distillery template: sqlite is now the default
backend
• Basic template now has license unlicense
• Basic template fixes
• Compatibility with Tyxml >= 4.6.0 (by Vincent Laporte)
Ocsigen Start 6.3
• Adding license Unlicense to the template
• Dependecy to Tyxml >= 4.6
Js_of_ocaml 5.7
═══════════════
Archive: <https://discuss.ocaml.org/t/ann-js-of-ocaml-5-7/14191/3>
Hhugo announced
───────────────
Js_of_ocaml 5.7.2 was released recently. It adds missing primitives
required by OCaml 5.2.0~beta
Eio Developer Meetings
══════════════════════
Archive: <https://discuss.ocaml.org/t/eio-developer-meetings/12207/5>
Sudha Parimala announced
────────────────────────
Following the release of Eio 1.0
(<https://discuss.ocaml.org/t/ann-eio-1-0-first-major-release/14334>),
Eio goes into maintenance mode for a bit. We've decided to pause the
Eio developer meetings until further notice. Meanwhile, we remain
active on the [issue tracker] and the [matrix channel]. I encourage
folks to try out Eio and report their findings.
[issue tracker] <https://github.com/ocaml-multicore/eio/issues>
[matrix channel] <https://matrix.to/#/#eio:roscidus.com>
Ocaml developer at Routine, Paris
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-ocaml-developer-at-routine-paris/14448/1>
mefyl announced
───────────────
Routine ([https://routine.co ]) is once more looking for OCaml
developers.
Routine is a personal productivity assistant and knowledge
manager. The technological stack revolves heavily around OCaml which
represents 80% of the codebase, both client and server side. The
remaining 20% are the UIs in various frontend framework:
• Browser and desktop (Linux/Macos/Windows) through electron, using
Js_of_ocaml (eyeing on WASM).
• iOS via Swift bindings.
• Android via JVM bindings (upcoming).
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.
• Automatic API and foreign binding generation for the different front
end technology, cross compilation.
• [Incremental ] based state updates to refresh minimal subsets of the
app.
• Integrated graph query language to query and manipulate all the app
data, including defining custom data types and workflows.
• Highly concurrent implementation through Lwt and Eio - migrating to
the later as we go. Exception-free design. OCaml 5 with all the
goodies.
• Angstrom based parsing for the interactive console with highlighting
and completion.
• Everything is very much library-oriented, with loads of reusable and
scaffolded packages. Most of the work is intended to be open
sources, or already has been published.
• An obsession for compile-time checks and type safety.
We use state of the art CI/CD and development processes. Salary is up
to market standard depending on the profile, plus usual options
package, to be discussed. We have a preference for presential work in
our Paris 11th office (Charonne, 3 days a week) to help foster team
spirit but we won't pass on talented remote individuals.
We're looking to extend the team with talented and passionate
engineers who see the global picture and will work through all layers
of the project to see it succeed and create something we're proud
of. 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](<mailto:quentin.hocquet@routine.co>) or
refer this to someone who may be interested.
Thanks for your time and happy hacking !
[https://routine.co ] <https://routine.co>
[Incremental ] <https://github.com/janestreet/incremental>
dream-html 3.0.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-dream-html-3-0-0/14013/7>
Yawar Amin announced
────────────────────
[ANN] dream-html 3.3.1
Add `to_xml' and `pp_xml' functions to render in XML style
Normally, dream-html defaults to rendering nodes in HTML style,
meaning that void elements are rendered just like opening tags. Eg
`<br>'. With the new `to_xml' and `pp_xml' functions, we can now
render nodes in XML style, meaning `<br />'. This allows XML parsers
to successfully parse the output. So eg you can use dream-html to
author an ePub book.
Escape URI attributes like `href' with normal attribute escaping rules
in addition to percent-encoding. Most significantly, ampersands are
encoded now, eg `/foo?a=1&b=2' is rendered as `/foo?a=1&b=2'.
Change where line breaks are inserted into the output markup, so that
there is no chance of injecting spurious whitespace into the rendered
page. This gives complete control over whitespace to the user.
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Updates to OCaml.org's Learn Section: Enhancing UI and UX]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Updates to OCaml.org's Learn Section: Enhancing UI and UX]
<https://tarides.com/blog/2024-04-03-updates-to-ocaml-org-s-learn-section-enhancing-ui-and-ux>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 49578 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-04-02 14:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-04-02 14:31 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 29707 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 26 to April
02, 2024.
Table of Contents
─────────────────
Odoc 3.0 planning
OCaml Platform Newsletter: February 2024
Your Feedback Needed on OCaml Home Page Wireframe!
OCaml Workshop 2024 at ICFP – announcement and call for proposals
down.0.2.0 and omod.0.4.0
stdlib-random 1.2
Other OCaml News
Old CWN
Odoc 3.0 planning
═════════════════
Archive: <https://discuss.ocaml.org/t/odoc-3-0-planning/14360/1>
Jon Ludlam announced
────────────────────
For many years we've had a team here at Tarides working away on Odoc,
quietly adding new features, fixing bugs, speeding things up and
generally enabling OCaml package mantainers to write good
documentation. Up until recently, those improvements have mostly been
incremental, but with the recent addition of some larger new features
like search and source rendering we've found we need to think a bit
more broadly and consider how these changes will fit into the larger
ecosystem. We're also thinking of how to extend the abilities of Odoc
to handle more structure in the documentation, with better support for
images, an improved sidebar, and a better ability to link to the docs
of other packages.
We've therefore started the process that's going to lead to Odoc 3.0,
which will involve not only work on odoc itself, but also on
ocaml.org, the documentation pipeline that produces the docs for
ocaml.org, dune, and odig. It's being done incrementally, so we've
started with the core issues of how to structure your docs, how to do
references both within the docs and across packages, what the output
file structure will look like and how the breadcrumbs will reflect
that. What we've posted so far is by no means the final version, and
we'd love to get feedback on the suggestions we've got so far. Getting
this right is surprisingly complicated, so the more people we have
thinking about it, the better our chances of success!
So if you're interested in writing or reading docs, I encourage you to
head on over to [the discussion] we've just started on [ocaml/odoc]
and join in the conversation!
[the discussion] <https://github.com/ocaml/odoc/discussions/1097>
[ocaml/odoc] <https://github.com/ocaml/odoc/>
OCaml Platform Newsletter: February 2024
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-platform-newsletter-february-2024/14361/1>
Thibaut Mattio announced
────────────────────────
Welcome to the tenth edition of the OCaml Platform newsletter!
In this February 2024 edition, we are excited to bring you the latest
on the OCaml Platform, continuing our tradition of highlighting recent
developments as seen in [previous editions]. To understand the
direction we're headed, especially regarding development workflows and
user experience improvements, check out our [roadmap].
*Highlights:*
• The OCaml Platform tools have added support for OCaml 5.2. It's
available in the temporary releases
• [`Merlin 4.14-502~preview'] (@voodoos (Tarides))
• [`Ocaml-lsp-server 1.18.0~5.2preview'] (@voodoos (Tarides))
• [`Ppxlib 0.32.1~5.2preview'] (@NathanReb (partly funded by the
OCaml Software Foundation)).
*Releases:*
• [UTop 2.14.0]
• [Merlin 4.14]
• [Dune 3.14.0]
• [Ppxlib 0.31.2]
• [Dune 3.13.1]
[previous editions] <https://discuss.ocaml.org/tag/platform-newsletter>
[roadmap] <https://ocaml.org/docs/platform-roadmap>
[`Merlin 4.14-502~preview']
<https://ocaml.org/p/merlin/4.14-502~preview>
[`Ocaml-lsp-server 1.18.0~5.2preview']
<https://ocaml.org/p/ocaml-lsp-server/1.18.0~5.2preview>
[`Ppxlib 0.32.1~5.2preview']
<https://ocaml.org/p/ppxlib/0.32.1~5.2preview>
[UTop 2.14.0] <https://ocaml.org/changelog/2024-02-27-utop-2.14.0>
[Merlin 4.14] <https://ocaml.org/changelog/2024-02-26-merlin-4.14>
[Dune 3.14.0] <https://ocaml.org/changelog/2024-02-12-dune.3.14.0>
[Ppxlib 0.31.2] <https://ocaml.org/changelog/2024-02-07-ppxlib-0.32.0>
[Dune 3.13.1] <https://ocaml.org/changelog/2024-02-05-dune-3.13.1>
*[Dune]* Exploring Package Management in Dune ([W4])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rgrinberg (Tarides), @Leonidas-from-XIV (Tarides),
@gridbugs (Tarides), @kit-ty-kate (Tarides), @Alizter
*Why:* Unify OCaml tooling under a single command line for all
development workflows. This addresses one of the most important pain
points [reported by the community].
*What:* Prototyping the integration of package management into Dune
using opam as a library. We're introducing a `dune pkg lock' command
to generate a lock file and enhancing `dune build' to handle
dependencies in the lock file. More details in the [Dune RFC].
*Activities:*
• One of the main remaining blockers to make Dune package management
usable in real world project is to make some of the low level
dependencies, notably OCamlFind and the OCaml compiler,
relocatable. – [ocaml/ocamlfind#72]
• We experimented with a Coq-platform patch to make OCamlFind
relocatable, but we faced issues with packages using `topkg' due to
`ocamlbuild' build failures. This led to identifying an error with
directory symlink handling in Dune [ocaml/dune#9873],
[ocaml/dune#9937]
• To track the buildability of opam packages with Dune package
management, we worked on a GitHub action that effectively provides
us with a dashboard of opam packages coverage on a select set of
packages. The repository is available at
[gridbugs/dune-pkg-dashboard].
• Based on the findings from the above, several issues were opened on
the Dune issue tracker. All the known issues are now tracked in the
[Package Management MVP] milestone on Dune's issue tracker.
• We also focused on improving features that were previously
implemented. Noteworthy changes include the addition of [workspace
package pins] and enhancements for correct path handling in packages
– [ocaml/dune#9940]
• Work included updates and refactorings to improve source fetching,
particularly the removal of a rudimentary Git config parser in favor
of using `git config' directly ([ocaml/dune#9905]), and enhancements
to how Dune handles Git repositories, such as the checking out of
Git repos via `rev_store' ([ocaml/dune#10060]).
• Contributions also focused on refining and testing Dune's package
handling, including a fix to ensure that opam's untar code is not
used ([ocaml/dune#10085]), and improvements to Dune's handling of
recursive submodules in Git repos ([ocaml/dune#10130]).
[W4] <https://ocaml.org/docs/platform-roadmap#w4-build-a-project>
[reported by the community]
<https://www.dropbox.com/s/omba1d8vhljnrcn/OCaml-user-survey-2020.pdf?dl=0>
[Dune RFC] <https://github.com/ocaml/dune/issues/7680>
[ocaml/ocamlfind#72] <https://github.com/ocaml/ocamlfind/pull/72>
[ocaml/dune#9873] <https://github.com/ocaml/dune/issues/9873>
[ocaml/dune#9937] <https://github.com/ocaml/dune/pull/9937>
[gridbugs/dune-pkg-dashboard]
<https://github.com/gridbugs/dune-pkg-dashboard>
[Package Management MVP]
<https://github.com/ocaml/dune/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Package+Management+MVP%22>
[workspace package pins] <https://github.com/ocaml/dune/pull/10072>
[ocaml/dune#9940] <https://github.com/ocaml/dune/pull/9940>
[ocaml/dune#9905] <https://github.com/ocaml/dune/pull/9905>
[ocaml/dune#10060] <https://github.com/ocaml/dune/pull/10060>
[ocaml/dune#10085] <https://github.com/ocaml/dune/pull/10085>
[ocaml/dune#10130] <https://github.com/ocaml/dune/pull/10130>
*[opam]* Native Support for Windows in opam 2.2 ([W5])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @rjbou (OCamlPro), @kit-ty-kate (Tarides), @dra27
(Tarides), @AltGr (OCamlPro)
*Why:* Enhance OCaml's viability on Windows by integrating native opam
and `opam-repository' support, fostering a larger community, and more
Windows-friendly packages.
*What:* Releasing opam 2.2 with native Windows support, making the
official `opam-repository' usable on Windows platforms.
*Activities:*
• Addressed the issue where the Windows loader would display blocking
dialogue boxes upon failing to find DLLs, adhering to best practices
by suppressing these dialogs, and opting for exit codes
instead. This enhancement eliminates disruptive interruptions,
ensuring a more seamless operation for automated tasks and CI
environments. – [#5828]
• Fixed shell detection issues when opam is invoked via Cygwin's
`/usr/bin/env', enhancing compatibility and user experience for
those utilising Cygwin alongside `cmd' or PowerShell. – [#5797]
• Recommend Developer Mode on Windows. To optimise storage and align
with best practices, Developer Mode is recommended for enabling
symlink support. – [#5831]
• Resolved issues related to environment variable handling,
specifically fixing bugs where updates or additions to environment
variables would incorrectly remove or alter them. – [#5837]
• Addressed early loading of git location information, particularly
benefiting Windows users by ensuring correct retrieval and
application of git-related configurations. – [#5842]
• Disabled ACL in Cygwin. By setting `noacl' in `/etc/fstab' for
`/cygdrive' mount, this change avoids permission mismatch errors,
enhancing reliability and usability for Cygwin users. – [#5796]
• Introduced the ability to define the package manager path at
initialisation, improving customisation and integration capabilities
for Windows users. – [#5847]
• Added `winsymlinks:native' to the Cygwin environment variable,
improving compatibility within the Cygwin ecosystem. – [#5793]
• Fixed script generation issues related to path quoting, ensuring
smoother initialisation and setup processes, especially in
mixed-environment scenarios like Cygwin. – [#5841]
• Corrected the precedence and handling of `git-location'
configurations during initialisation, streamlining Git integration
and providing clearer control over Git settings. – [#5848]
• Extended the use of eval-variables to internal Cygwin installations
and adjusted the setup to better accommodate Windows-specific
requirements, enhancing flexibility and system compiler
integration. – [#5829]
[W5] <https://ocaml.org/docs/platform-roadmap#w5-manage-dependencies>
[#5828] <https://github.com/ocaml/opam/pull/5828>
[#5797] <https://github.com/ocaml/opam/pull/5797>
[#5831] <https://github.com/ocaml/opam/pull/5831>
[#5837] <https://github.com/ocaml/opam/pull/5837>
[#5842] <https://github.com/ocaml/opam/pull/5842>
[#5796] <https://github.com/ocaml/opam/pull/5796>
[#5847] <https://github.com/ocaml/opam/pull/5847>
[#5793] <https://github.com/ocaml/opam/pull/5793>
[#5841] <https://github.com/ocaml/opam/pull/5841>
[#5848] <https://github.com/ocaml/opam/pull/5848>
[#5829] <https://github.com/ocaml/opam/pull/5829>
*[`odoc']* Unify OCaml.org and Local Package Documentation ([W25])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @jonludlam (Tarides), @julow (Tarides), @panglesd
(Tarides), Luke Maurer (Jane Street)
*Why:* Improving local documentation generation workflow will help
package authors write better documentation for their packages, and
consolidating the different `odoc' documentation generators will help
make continuous improvements to `odoc' available to a larger audience.
*What:* We will write conventions that drivers must follow to ensure
that their output will be functional. Once established, we will update
the Dune rules to follow these rules, access new `odoc' features
(e.g., source rendering), and provide similar functionalities to
docs.ocaml.org (a navigational sidebar, for instance). This will
effectively make Dune usable to generate OCaml.org package
documentation.
*Activities:*
• Work continued on the design for the new `odoc' drivers conventions
shared by Dune and OCaml.org, and we plan to publish the RFC in
March.
• We also started comparing and prototyping various approaches to add
sidebar support to `odoc'. Several prototypes have been developed
and discussed with the team, and we will resume work on the sidebar
implementation once the driver conventions have been adopted.
[W25]
<https://ocaml.org/docs/platform-roadmap#w25-generate-documentation>
*[`odoc']* Add Search Capabilities to `odoc' ([W25])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @panglesd (Tarides), @EmileTrotignon (Tarides),
@julow (Tarides), @jonludlam (Tarides)
*Why:* Improve usability and navigability in OCaml packages
documentation, both locally and on OCaml.org, by offering advanced
search options like type-based queries.
*What:* Implementing a search engine interface in `odoc', complete
with a UI and a search index. Additionally, we're developing a default
client-side search engine based on Sherlodoc.
*Activities:*
• The implementation and refinement of sherlodoc's integration with
odoc were our major focuses, this included making sherlodoc pass
opam CI on different architectures and adjusting the dune rules for
better usability – [ocaml/dune#9956]
• After the big sherlodoc PR was merged and sherlodoc released last
month, work continued on refining the dune rules for sherlodoc and
on adjusting the search bar's scope based on discussions with the
team.
• We implemented keyboard navigation in the search bar to improve its
usability – [ocaml/odoc#1088]
[W25]
<https://ocaml.org/docs/platform-roadmap#w25-generate-documentation>
[ocaml/dune#9956] <https://github.com/ocaml/dune/pull/9956>
[ocaml/odoc#1088] <https://github.com/ocaml/odoc/pull/1088>
*[`odoc']* Improving `odoc' Performance ([W25])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @jonludlam (Tarides), @julow (Tarides), @gpetiot
(Tarides)
*Why:* Address performance issues in `odoc', particularly for
large-scale documentation, to enhance efficiency and user experience
and unlock local documentation generation in large code bases.
*What:* Profiling `odoc' to identify the main performance bottlenecks
and optimising `odoc' with the findings.
*Activities:*
• Performance improvements were achieved by addressing issues with
source location lookups for non-existent identifiers, significantly
improving link time for large codebases.
• Several PRs from the module-type-of work were opened, including
fixes and tests aimed at enhancing `odoc''s handling of transitive
library dependencies, shape lookup, and module-type-of expansions –
[ocaml/odoc#1078], [ocaml/odoc#1081]
• Improve the efficiency of finding `odoc' files in accessible paths,
cutting the time to generate documentation by two in some of our
tests – [ocaml/odoc#1075]
[W25]
<https://ocaml.org/docs/platform-roadmap#w25-generate-documentation>
[ocaml/odoc#1078] <https://github.com/ocaml/odoc/pull/1078>
[ocaml/odoc#1081] <https://github.com/ocaml/odoc/pull/1081>
[ocaml/odoc#1075] <https://github.com/ocaml/odoc/pull/1075>
*[Merlin]* Support for Project-Wide References in Merlin ([W19])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @voodoos (Tarides)
*Why:* Enhance code navigation and refactoring for developers by
providing project-wide reference editor features, aligning OCaml with
the editor experience found in other languages.
*What:* Introducing `ocamlmerlin server occurrences' and LSP
`textDocument/references' support, extending compiler's Shapes for
global occurrences and integrating these features in Dune, Merlin, and
OCaml LSP.
*Activities:*
• Continued investigations and improvements on Dune rules to address
configuration issues
• After adding support for OCaml 5.2 to `merlin-lib', we've rebased
the project-wide occurrences work over it.
• We also started work with the Jane Stree team to test project wide
references at scale in their monorepo. Following our initial
integration, we focused on refining Merlin's indexing and occurrence
query capabilities, including addressing bottlenecks and regressions
in shape reductions – [ocaml/ocaml#13001]
[W19] <https://ocaml.org/docs/platform-roadmap#w19-navigate-code>
[ocaml/ocaml#13001] <https://github.com/ocaml/ocaml/pull/13001>
*[Merlin]* Improving Merlin's Performance ([W19])
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
*Contributed by:* @pitag (Tarides), @Engil (Tarides)
*Why:* Some Merlin queries have been shown to scale poorly in large
codebases, making the editor experience subpar. Users report that they
sometimes must wait a few seconds to get the answer. This is obviously
a major issue that hurts developer experience, so we're working on
improving Merlin performance when it falls short.
*What:* Developing benchmarking tools and optimising Merlin's
performance through targeted improvements based on profiling and
analysis of benchmark results.
*Activities:*
• In `merlin-lib', we've continued the work on a prototype to process
the buffer in parallel with the query computation. Parallelism
refers to OCaml 5 parallelism (domains).
[W19] <https://ocaml.org/docs/platform-roadmap#w19-navigate-code>
Your Feedback Needed on OCaml Home Page Wireframe!
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/your-feedback-needed-on-ocaml-home-page-wireframe/14366/1>
Claire Vandenberghe announced
─────────────────────────────
I'm reaching out to ask for a few minutes of your time to review the
wireframe designs for the OCaml Home, Industrial, and Academic pages.
After conducting user interviews with OCaml enthusiasts, we've
gathered valuable insights on what information newcomers find most
helpful when visiting the OCaml home.
As a result, we've been working on restructuring these three major
pages to better cater to user needs.
(*Please note that these wireframes primarily focus on navigation,
layout, and content, rather than the User Interface (UI).*)
Your feedback is crucial at this stage, so please feel free to leave
comments directly on Figma, via email, or let's schedule a quick call
to discuss. Thank you for taking part in this review.
*Figma Link*:
<https://www.figma.com/file/eLNSdvayxqvvfBsRsdbJXN/OCaml-Home-Page?type=design&node-id=5%3A2500&mode=design&t=hHclskuVpoOzKP2u-1>
OCaml Workshop 2024 at ICFP – announcement and call for proposals
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2024-at-icfp-announcement-and-call-for-proposals/14371/1>
Sonja Heinze announced
──────────────────────
This year, [ICFP] (the International Conference on Functional
Programming) is going to take place in beautiful Milan.
<https://hackmd.io/_uploads/rJIS7LPAT.jpg>
Such as every year since 2012, on the last day of that conference,
i.e. on *September 7th (Saturday)*, we'll hold a workshop on
OCaml. The workshop is intended to cover all different kinds of
aspects of the OCaml programming language as well as the OCaml
ecosystem and its community, such as scientific and/or
research-oriented, engineering and/or user-oriented, as well as social
and/or community-oriented.
[ICFP] <https://icfp24.sigplan.org/>
Call for talk proposals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The [call for talk proposals] for the workshop is open.
[call for talk proposals]
<https://icfp24.sigplan.org/home/ocaml-2024#Call-for-Papers>
◊ Dates
Here are the important dates:
• Talk proposal submission deadline: May 30th (Thursday)
• Author notification: July 4th (Thursday)
• Workshop: September 7th (Saturday)
◊ Submissions
Submissions are typically around 2 pages long (flexible), describing
the motivations of the work and what the presentation would be about.
We encourage everyone who might be interested in giving a talk to
submit a proposal! We truly mean everyone, and also have strongly
anyone in mind who belongs to a group that's traditionally
underrepresented at OCaml workshops, e.g. due to your gender(s) or
non-gender, where you're from or based or whatever other kinds of
characteristics you might have. You should all be able to find all
information you'll need to submit a proposal on the official [call for
talk proposals]. However, if you have any question, don't hesitate to
ask us.
[call for talk proposals]
<https://icfp24.sigplan.org/home/ocaml-2024#Call-for-Papers>
◊ Quota on accepted talks per affiliation
Even though none of us is a fan of quotas, last year's workshop
experimented with a quota of a maximum of four talks given by speakers
with the same company/university/institute affiliation. In order to
guarantee a coverage of a diverse range of topics and perspectives,
we'll experiment with the same affiliation quota again.
Do not hesitate to submit your talk proposal in any case: quotas, if
needed, will be taken into account by the PC after reviewing all
submissions, so there's no reason to self-select upfront.
About the workshop itself
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
So far, we've only talked about talk proposals and formalities. The
really exciting part will be the workshop itself! It's going to be a
whole-day workshop and, similarly to previous years, it's likely going
to have four sessions of about four talks each. It's a rather informal
and interactive environment, where people engage in all kinds of
conversations about OCaml during the breaks and after the workshop.
◊ Hybrid attendance and cost for speakers
We're aiming to make the workshop hybrid with the same streaming
modalities as last year, meaning that *talks as well as participation
can be either in-person or remote*, and *remote attendance will be
free*. To promote a good atmosphere, communication and engagement, we
prefer to have most talks in-person, but remote talks will be most
welcome as well.
We know that giving the talk in-person comes with an economic
cost. We're very happy to announce that thanks to the [OCaml Software
Foundation], *registration fees will be covered for speakers* in case
they can't get them funded by other means (e.g. their employer).
We will do our best to provide the best workshop experience possible
for remote participants, within the constraints of the hybrid
format. While attending in-person does come with advantages, it also
comes with an environmental cost, and we strongly support
transitioning to a less plane-intensive organization for conferences
and community events :deciduous_tree: .
[OCaml Software Foundation] <https://ocaml-sf.org/>
◊ Related events
The day before the OCaml workshop, i.e. Sep 6th (Friday), is the day
of the [ML workshop], with focus on more theoretical aspects of OCaml
and the whole family of ML languages in general. The ML workshop [has
already been announced on the OCaml discuss] and tends to be very
interesting for OCaml lovers as well.
We're looking forward to the the talk submissions and to the workshop!
Let us know if you have any questions. @Armael and @pitag
[ML workshop] <https://icfp24.sigplan.org/home/mlworkshop-2024>
[has already been announced on the OCaml discuss]
<https://discuss.ocaml.org/t/call-for-presentations-ml-2024-acm-sigplan-ml-family-workshop/14284>
down.0.2.0 and omod.0.4.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-down-0-2-0-and-omod-0-4-0/14380/1>
Daniel Bünzli announced
───────────────────────
It's my pleasure to announce new releases for [down] and [omod] which
provide a nice `ocaml' toplevel user experience upgrade. Simply add to
your `.ocamlinit':
┌────
│ #use "down.top"
│ #use "omod.top"
└────
And enjoy all the benefits you can learn about in the [down manual]
and in the [omod tutorial].
These are mainly maintenance releases but if you ever though that down
was a bit slow when pasting code, it now (well for almost two years…)
implements [bracketed pastes]. Thanks to @emillon for the reference.
[down] <https://erratique.ch/software/down>
[omod] <https://erratique.ch/software/omod>
[down manual] <https://erratique.ch/software/down/doc/manual.html>
[omod tutorial] <https://erratique.ch/software/omod/doc/tutorial.html>
[bracketed pastes] <https://cirw.in/blog/bracketed-paste>
stdlib-random 1.2
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-stdlib-random-1-2/14381/1>
octachron announced
───────────────────
The library `stdlib-random' is a small compatibility library that
provides compiler-independent implementations of the PRNGs used in the
history of the standard library `Random':
• stdlib-random.v3: implement the PRNG used in OCaml 3.07 to 3.11
• stdlib-random.v4: implement the PRNG used in OCaml 3.12 to 4.14
• stdlib-random.v5: implement the PRNG currently used in OCaml 5
• stdlib-random.v5o: implement the PRNG currently used in OCaml 5 in
pure OCaml
This library is targeted toward programs that need a deterministic and
stable behaviour of the `Random' module across OCaml versions.
The newly released version 1.2.0 updates all implementations to
provide the new `int_in_range' function (and its `int32_in_range',
`nativeint_in_range', `int64_in_range' variants) that will be
available in OCaml 5.2.0.
Note however that the implementations on the pre-OCaml 5 PRNGs are not
optimal, since I prioritised the maintenance cost over performance,
but that could be changed if required.
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [NetHSM: Bringing Open Source to the World of Hardware Security
Modules]
• [Frama-Clang v0.0.15 for Frama-C 28.0 Nickel]
[the ocaml.org blog] <https://ocaml.org/blog/>
[NetHSM: Bringing Open Source to the World of Hardware Security Modules]
<https://tarides.com/blog/2024-03-27-nethsm-bringing-open-source-to-the-world-of-hardware-security-modules>
[Frama-Clang v0.0.15 for Frama-C 28.0 Nickel]
<https://frama-c.com/fc-plugins/frama-clang.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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 41021 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-03-26 6:32 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-03-26 6:32 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 19440 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 19 to 26,
2024.
Table of Contents
─────────────────
The Flambda2 Snippets, by OCamlPro
Eio 1.0: First major release
ppx_minidebug 1.3.0: toward a logging framework
Academic OCaml Users Testimonials!
Volunteers for ICFP 2024 Artifact Evaluation Committee (AEC)
First beta release for OCaml 5.2.0
Other OCaml News
Old CWN
The Flambda2 Snippets, by OCamlPro
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/blog-the-flambda2-snippets-by-ocamlpro/14331/1>
OCamlPro announced
──────────────────
Greetings Cameleers,
Today, we are excited to share with you a first glance at some
redactional work that has been brewing behind at the scenes at
OCamlPro for quite a some time now!
We are starting a series of blogposts on the Flambda2 project. The
goals are plenty, one of them being to give all readers an idea of the
inner workings of this great piece of software, 10 years of research &
development in the making.
The first two episodes are rather special to the series:
• [Episode 0] gives context and broader information on both the
Flambda2 Optimising Compiler project, and the series of blogposts
itself.
• [Episode 1], on the other hand, steps right into the subject at hand
and covers some of the foundational design decisions of this
compiler.
We await your feedback below, and hope that you will enjoy reading
these posts, and all ensuing ones!
Kind regards, The OCamlPro Team
[Episode 0]
<https://ocamlpro.com/blog/2024_03_18_the_flambda2_snippets_0/>
[Episode 1]
<https://ocamlpro.com/blog/2024_03_19_the_flambda2_snippets_1/>
Eio 1.0: First major release
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-eio-1-0-first-major-release/14334/1>
Sudha Parimala announced
────────────────────────
I'm happy to announce the release of [Eio 1.0], its first major
release. Eio started as an experimental effects-based library by the
same team that was working on Multicore OCaml. We did not initially
plan on upstreaming effects with OCaml 5.0. However, thanks to the
efforts from the multicore team and OCaml core developers, effect
handlers shipped with OCaml 5.0 (making it one of the first mainstream
languages to do so). This presented the opportunity to develop
effect-based concurrency libraries for OCaml, and Eio was the first of
the lot..
Find more about the journey of Eio in this post – [ Eio 1.0 Release:
Introducing a new Effects-Based I/O Library for OCaml]
This is the beginning of the journey towards effect-based schedulers!
We are keen to hear from you all to shape up what would be Eio 2.0.
If you're looking to get started with Eio, the [README] is a good
place to start. Additionally, @talex5's [video introduction], and
[tutorial to port your Lwt applications to Eio] serve as good primers.
I'd like to thank all the contributors for their work and users for
their thoughtful feedback. As always, happy to hear feedback about
Eio.
Happy hacking!
[Eio 1.0] <https://github.com/ocaml-multicore/eio/releases/tag/v1.0>
[ Eio 1.0 Release: Introducing a new Effects-Based I/O Library for
OCaml]
<https://tarides.com/blog/2024-03-20-eio-1-0-release-introducing-a-new-effects-based-i-o-library-for-ocaml/>
[README] <https://github.com/ocaml-multicore/eio/blob/main/README.md>
[video introduction] <https://watch.ocaml.org/w/1k1T919WGXoT4tjnRZEmMd>
[tutorial to port your Lwt applications to Eio]
<https://github.com/ocaml-multicore/icfp-2023-eio-tutorial>
ppx_minidebug 1.3.0: toward a logging framework
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ppx-minidebug-1-3-0-toward-a-logging-framework/14213/3>
Lukasz Stafiniak announced
──────────────────────────
Happy to announce ppx_minidebug 1.5.0. It should soon propagate to the
opam repository. Two new features since 1.4.0:
• `[%log_entry header_string; body...]' syntax to explicitly create
log subtrees without polluting with source location
information. Note that if you want the source location you could
always do `let _for_debug : type... = body... in...'.
• Minimalistic flame graphs. Example:
<https://global.discourse-cdn.com/business7/uploads/ocaml/optimized/2X/c/ce80302bd2abf9dbefd401cd7297184da0fa2ad6_2_1380x414.png>
(Note that the output is very configurable, e.g. by default the `at
elapsed' time information is not printed.)
Academic OCaml Users Testimonials!
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/academic-ocaml-users-testimonials/14338/1>
Claire Vandenberghe announced
─────────────────────────────
*Are you an academic user of OCaml?*
By sharing your testimonial, you're not only showcasing your expertise
and experience but also contributing to the OCaml community.
Your insights can help prospective users understand the academic value
of OCaml and inspire them to explore its potential further.
Your testimonial will be featured on our academic user page, inspiring
others to explore OCaml's potential.
*Tell us:*
1. Your name and academic affiliation.
2. A brief description of how you’ve used OCaml in your academic
endeavors.
3. Your thoughts on the benefits and challenges of using OCaml.
Thanks
OCaml.org Team
UnixJunkie then replied
───────────────────────
Some years ago, I wrote a testimonial in an invited paper:
Chemoinformatics and structural bioinformatics in OCaml
<https://jcheminf.biomedcentral.com/articles/10.1186/s13321-019-0332-0>
Volunteers for ICFP 2024 Artifact Evaluation Committee (AEC)
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/volunteers-for-icfp-2024-artifact-evaluation-committee-aec/14355/1>
Benoît Montagu announced
────────────────────────
Dear all,
We are looking for motivated people to be members of the ICFP 2024
Artifact Evaluation Committee (AEC). Students, researchers and people
from the industry or the free software community are all welcome. The
artifact evaluation process aims to improve the quality and
reproducibility of research artifacts for ICFP papers. In case you
want to nominate someone else (students, colleagues, etc.), please
send them the nomination form.
Nomination form: <https://forms.gle/KJAjtDzhm5VLxjVf9>
Deadline for nominations: Mon April 8th 2024
For more information, see the AEC webpage:
<https://icfp24.sigplan.org/track/icfp-2024-artifact-evaluation>
The primary responsibility of committee members is to review the
artifacts submitted corresponding to the already conditionally
accepted papers in the main research track. In particular, run the
associated tool or benchmark, check whether the results in the paper
can be reproduced, and inspect the tool and the data.
We expect evaluation of one artifact to take about a full day. Each
committee member will receive 2 to 3 artifacts to review.
All of the AEC work will be done remotely/online. The AEC will work in
June, with the review work happening between June 5th and July 5th.
Come join us in improving the quality of research in our field!
Best, the Artifact Evaluation chairs: Quentin Stiévenart and Benoît
Montagu
First beta release for OCaml 5.2.0
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/first-beta-release-for-ocaml-5-2-0/14356/1>
octachron announced
───────────────────
Nearly two months after the first alpha release, the release of OCaml
5.2.0 is drawing near.
We have thus released a first beta version of OCaml 5.2.0 to help you
update your softwares and libraries ahead of the release (see below
for the installation instructions).
Compared to the alpha release, this beta contains a majority of
runtime system fixes, and a handful of other fixes across many
subsystems.
Overall, the opam ecosystem looks in a good shape for the first beta
release. Most core development tools support OCaml 5.2.0 or have
compatibility patch under review (for `odoc' and `ocamlformat'), and
you can follow the last remaining wrinkles on the [opam readiness for
5.2.0 meta-issue].
If you find any bugs, please report them on [OCaml's issue tracker].
Currently, the release is planned for the end of April or the
beginning of May.
If you are interested in full list of features and bug fixes of the
new OCaml version, the updated change log for OCaml 5.2.0 is available
[on GitHub].
[opam readiness for 5.2.0 meta-issue]
<https://github.com/ocaml/opam-repository/issues/25182>
[OCaml's issue tracker] <https://github.com/ocaml/ocaml/issues>
[on GitHub] <https://github.com/ocaml/ocaml/blob/5.2/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.2.0~beta1
└────
The source code for the alpha is also available at these addresses:
• [GitHub]
• [OCaml archives at Inria]
[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.0-beta1.tar.gz>
[OCaml archives at Inria]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.0~beta1.tar.gz>
◊ Fine-Tuned Compiler Configuration
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.2.0~beta1+options <option_list>
└────
where `option_list' is a space-separated list of `ocaml-option-*'
packages. For instance, for a `flambda' and `no-flat-float-array'
switch:
┌────
│ opam switch create 5.2.0~beta1+flambda+nffa ocaml-variants.5.2.0~beta1+options
│ ocaml-option-flambda ocaml-option-no-flat-float-array
└────
All available options can be listed with `opam search ocaml-option'.
Changes since the first alpha
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Runtime System Fixes
• [#12875], [#12879], [#12882]: Execute preemptive systhread switching
as a delayed pending action. This ensures that one can reason within
the FFI that no mutation happens on the same domain when allocating
on the OCaml heap from C, consistently with OCaml 4. This also fixes
further bugs with the multicore systhreads implementation.
(Guillaume Munch-Maccagnoni, bug reports and suggestion by Mark
Shinwell, review by Nick Barnes and Stephen Dolan)
• [#12876]: Port ThreadSanitizer support to Linux on POWER (Miod
Vallat, review by Tim McGilchrist)
• [#12678], [#12898]: free channel buffers on close rather than on
finalization (Damien Doligez, review by Jan Midtgaard and Gabriel
Scherer, report by Jan Midtgaard)
• [#12915]: Port ThreadSanitizer support to Linux on s390x (Miod
Vallat, review by Tim McGilchrist)
• [#12914]: Slightly change the s390x assembly dialect in order to
build with Clang's integrated assembler. (Miod Vallat, review by
Gabriel Scherer)
• [#12897]: fix locking bugs in Runtime_events (Gabriel Scherer and
Thomas Leonard, review by Olivier Nicole, Vincent Laviron and Damien
Doligez, report by Thomas Leonard)
• [#12860]: Fix an assertion that wasn't taking into account the
possibility of an ephemeron pointing at static data. (Mark
Shinwell, review by Gabriel Scherer and KC Sivaramakrishnan)
• [#11040], [#12894]: Silence false data race observed between
caml_shared_try_alloc and oldify. Introduces macros to call tsan
annotations which help annotate a ~~happens before'' relationship.
(Hari Hara Naveen S and Olivier Nicole, review by Gabriel Scherer
and Miod Vallat)
• [#12919]: Fix register corruption in caml_callback2_asm on s390x.
(Miod Vallat, review by Gabriel Scherer)
• [#12969]: Fix a data race in caml_darken_cont (Fabrice Buoro and
Olivier Nicole, review by Gabriel Scherer and Miod Vallat)
[#12875] <https://github.com/ocaml/ocaml/issues/12875>
[#12879] <https://github.com/ocaml/ocaml/issues/12879>
[#12882] <https://github.com/ocaml/ocaml/issues/12882>
[#12876] <https://github.com/ocaml/ocaml/issues/12876>
[#12678] <https://github.com/ocaml/ocaml/issues/12678>
[#12898] <https://github.com/ocaml/ocaml/issues/12898>
[#12915] <https://github.com/ocaml/ocaml/issues/12915>
[#12914] <https://github.com/ocaml/ocaml/issues/12914>
[#12897] <https://github.com/ocaml/ocaml/issues/12897>
[#12860] <https://github.com/ocaml/ocaml/issues/12860>
[#11040] <https://github.com/ocaml/ocaml/issues/11040>
[#12894] <https://github.com/ocaml/ocaml/issues/12894>
[#12919] <https://github.com/ocaml/ocaml/issues/12919>
[#12969] <https://github.com/ocaml/ocaml/issues/12969>
◊ Standard Library Fix
• [#12677], [#12889]: make Domain.DLS thread-safe (Gabriel Scherer,
review by Olivier Nicole and Damien Doligez, report by Vesa
Karvonen)
[#12677] <https://github.com/ocaml/ocaml/issues/12677>
[#12889] <https://github.com/ocaml/ocaml/issues/12889>
◊ Type System Fix
• [#12924], [#12930]: Rework package constraint checking to improve
interaction with immediacy (Chris Casinghino and Florian Angeletti,
review by Florian Angeletti and Richard Eisenberg)
[#12924] <https://github.com/ocaml/ocaml/issues/12924>
[#12930] <https://github.com/ocaml/ocaml/issues/12930>
◊ Compiler User-Interface Fix
• [#12971], [#12974]: fix an uncaught Ctype.Escape exception on some
invalid programs forming recursive types. (Gabriel Scherer, review
by Florian Angeletti, report by Neven Villani)
[#12971] <https://github.com/ocaml/ocaml/issues/12971>
[#12974] <https://github.com/ocaml/ocaml/issues/12974>
◊ Build System Fixes
• [#12198], [#12321], [#12586], [#12616], [#12706], [#13048]: continue
the merge of the sub-makefiles into the root Makefile started with
[#11243], [#11248], [#11268], [#11420] and [#11675]. (Sébastien
Hinderer, review by David Allsopp and Florian Angeletti)
• [#12768], [#13030]: Detect mingw-w64 coupling with GCC or LLVM,
detect clang-cl, and fix C compiler feature detection on macOS.
(Antonin Décimo, review by Miod Vallat and Sébastien Hinderer)
• [#13019]: Remove linking instructions for the Unix library from
threads.cma (this was done for threads.cmxa in OCaml
3.11). Eliminates warnings from new lld when using threads.cma of
duplicated libraries. (David Allsopp, review by Nicolás Ojeda Bär)
• [#12758], [#12998]: Remove the `Marshal.Compression' flag to the
`Marshal.to_*' functions. The compilers are still able to use ZSTD
compression for compilation artefacts. This is a forward port and
clean-up of the emergency fix that was introduced
[#12198] <https://github.com/ocaml/ocaml/issues/12198>
[#12321] <https://github.com/ocaml/ocaml/issues/12321>
[#12586] <https://github.com/ocaml/ocaml/issues/12586>
[#12616] <https://github.com/ocaml/ocaml/issues/12616>
[#12706] <https://github.com/ocaml/ocaml/issues/12706>
[#13048] <https://github.com/ocaml/ocaml/issues/13048>
[#11243] <https://github.com/ocaml/ocaml/issues/11243>
[#11248] <https://github.com/ocaml/ocaml/issues/11248>
[#11268] <https://github.com/ocaml/ocaml/issues/11268>
[#11420] <https://github.com/ocaml/ocaml/issues/11420>
[#11675] <https://github.com/ocaml/ocaml/issues/11675>
[#12768] <https://github.com/ocaml/ocaml/issues/12768>
[#13030] <https://github.com/ocaml/ocaml/issues/13030>
[#13019] <https://github.com/ocaml/ocaml/issues/13019>
[#12758] <https://github.com/ocaml/ocaml/issues/12758>
[#12998] <https://github.com/ocaml/ocaml/issues/12998>
◊ Compiler Internals Fix
• [#12389], [#12544], [#12984], +[#12987]: centralize the handling of
metadata for compilation units and artifacts in preparation for
better unicode support for OCaml source files. (Florian Angeletti,
review by Vincent Laviron and Gabriel Scherer)
[#12389] <https://github.com/ocaml/ocaml/issues/12389>
[#12544] <https://github.com/ocaml/ocaml/issues/12544>
[#12984] <https://github.com/ocaml/ocaml/issues/12984>
[#12987] <https://github.com/ocaml/ocaml/issues/12987>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Eio 1.0 Release: Introducing a new Effects-Based I/O Library for
OCaml]
• [CPS Representation and Foundational Design Decisions in Flambda2]
• [The Flambda2 Snippets, Episode 0 ]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Eio 1.0 Release: Introducing a new Effects-Based I/O Library for OCaml]
<https://tarides.com/blog/2024-03-20-eio-1-0-release-introducing-a-new-effects-based-i-o-library-for-ocaml>
[CPS Representation and Foundational Design Decisions in Flambda2]
<https://ocamlpro.com/blog/2024_03_19_the_flambda2_snippets_1>
[The Flambda2 Snippets, Episode 0 ]
<https://ocamlpro.com/blog/2024_03_18_the_flambda2_snippets_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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 30846 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-03-19 15:09 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-03-19 15:09 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 22492 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 12 to 19,
2024.
Table of Contents
─────────────────
dune 3.14
Announcing OCaml Manila Meetups
Outreachy internship demo session
OCaml 4.14.2 released
Docfd 3.0.0: TUI multiline fuzzy document finder
Shape with us the New OCaml.org Community Area!
Opam-repository: Updated documentation, retirement and call for maintainers
DkCoder 0.1.0
A Versatile OCaml Library for Git Interaction - Seeking Community Feedback
Other OCaml News
Old CWN
dune 3.14
═════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-14/14096/7>
Marek Kubica announced
──────────────────────
We're happy to announce that Dune 3.14.2 is now available.
Note that due to a regression that was detected before publishing to
opam version `3.14.1' should not be used. The fix for the regression
is part of this release.
This feature brings some small bugfixes around the handling of Coq as
well as solves an issue where Dune is running on Windows in a path
that contains Unicode characters. This affected e.g. users with
diacritics or non-latin script in their name when running Dune within
their home directory.
• When a directory is changed to a file, correctly remove it in
subsequent `dune build' runs. (#9327, fix #6575, @emillon)
• Fix a problem with the doc-new target where transitive dependencies
were missed during compile. This leads to missing expansions in the
output docs. (#9955, @jonludlam)
• coq: fix performance regression in coqdep unescaping (#10115, fixes
#10088, @ejgallego, thanks to Dan Christensen for the report)
• coq: memoize coqdep parsing, this will reduce build times for Coq
users, in particular for those with many .v files (#10116,
@ejgallego, see also #10088)
• on Windows, use an unicode-aware version of `CreateProcess' to avoid
crashes when paths contains non-ascii characters. (#10212, fixes
#10180, @emillon)
• fix compilation on non-glibc systems due to `signal.h' not being
pulled in spawn stubs. (#10256, @emillon)
Announcing OCaml Manila Meetups
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-ocaml-manila-meetups/14300/1>
Thibaut Mattio announced
────────────────────────
I'm thrilled to announce the OCaml Manila Meetup!
Seeing that OCaml doesn't seem to have reached the Philippines just
yet (I wasn't able to find existing OCaml or FP communities), the goal
is to build one, starting small, with a few people meeting every month
in a coffee to hack on fun projects, and letting it grow organically.
The inaugural event is scheduled for the 4th of April:
<https://www.meetup.com/ocaml-manila/events/299786391/>
If you're living in Manila, or if you know anyone who would be
interested in joining, please don't hesitate to reach out!
I would also greatly appreciate retweets if you happen to be on
Twitter: <https://twitter.com/tmattio_/status/1768169167004577997>
Happy hacking!
Outreachy internship demo session
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-internship-demo-session/14247/2>
Continuing this thread, Patrick Ferris announced
────────────────────────────────────────────────
The recording from the demo session is now live on watch.ocaml.org
:camel:
<https://watch.ocaml.org/w/b7sv1LQSVZQH6trf4xpwFX>
OCaml 4.14.2 released
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-14-2-released/14308/1>
octachron announced
───────────────────
We have the pleasure of celebrating the birthday of Grace Chisholm
Young by announcing the release of OCaml version 4.14.2.
This release is a collection of safe bug fixes, cherry-picked from the
OCaml 5 branch. If you are still using OCaml 4.14 and cannot yet
upgrade to OCaml 5, this release is for you.
The 4.14 branch is expected to receive updates for at least one year,
while the OCaml 5 branch is stabilising.
Thus don't hesitate to report any bugs on the OCaml issue tracker (at
<https://github.com/ocaml/ocaml/issues>).
See the list of changes below for more details.
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands:
┌────
│ opam update
│ opam switch create 4.14.2
└────
The source code for the release candidate is also directly available
on:
• [GitHub]
• [Inria archive]
[GitHub] <https://github.com/ocaml/ocaml/archive/4.14.2.tar.gz>
[Inria archive]
<https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.2.tar.gz>
Changes since OCaml 4.14.1
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Runtime system:
• [#11764], [#12577]: Add prototypes to old-style C function
definitions and declarations. (Antonin Décimo, review by Xavier
Leroy and Nick Barnes)
• [#11763], [#11759], [#11861], [#12509], [#12577]: Use strict
prototypes on primitives. (Antonin Décimo, review by Xavier Leroy,
David Allsopp, Sébastien Hinderer and Nick Barnes)
• (*breaking change*) [#10723]: do not use `-flat-namespace' linking
for macOS. (Carlo Cabrera, review by Damien Doligez)
• [#11332], [#12702]: make sure `Bool_val(v)' has type `bool' in C++
(Xavier Leroy, report by ygrek, review by Gabriel Scherer)
[#11764] <https://github.com/ocaml/ocaml/issues/11764>
[#12577] <https://github.com/ocaml/ocaml/issues/12577>
[#11763] <https://github.com/ocaml/ocaml/issues/11763>
[#11759] <https://github.com/ocaml/ocaml/issues/11759>
[#11861] <https://github.com/ocaml/ocaml/issues/11861>
[#12509] <https://github.com/ocaml/ocaml/issues/12509>
[#10723] <https://github.com/ocaml/ocaml/issues/10723>
[#11332] <https://github.com/ocaml/ocaml/issues/11332>
[#12702] <https://github.com/ocaml/ocaml/issues/12702>
Build system:
╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#11590]: Allow installing to a destination path containing spaces.
(Élie Brami, review by Sébastien Hinderer and David Allsopp)
• [#12372]: Pass option -no-execute-only to the linker for OpenBSD >=
7.3 so that code sections remain readable, as needed for closure
marshaling. (Xavier Leroy and Anil Madhavapeddy, review by Anil
Madhavapeddy and Sébastien Hinderer)
• [#12903]: Disable control flow integrity on OpenBSD >= 7.4 to avoid
illegal instruction errors on certain CPUs. (Michael Hendricks,
review by Miod Vallat)
[#11590] <https://github.com/ocaml/ocaml/issues/11590>
[#12372] <https://github.com/ocaml/ocaml/issues/12372>
[#12903] <https://github.com/ocaml/ocaml/issues/12903>
Bug fixes:
╌╌╌╌╌╌╌╌╌╌
• [#12061], [#12063]: don't add inconsistent equalities when computing
high-level error messages for functor applications and
inclusions. (Florian Angeletti, review by Gabriel Scherer)
• [#12878]: fix incorrect treatment of injectivity for private
recursive types. (Jeremy Yallop, review by Gabriel Scherer and
Jacques Garrigue)
• [#12971], [#12974]: fix an uncaught Ctype.Escape exception on some
invalid programs forming recursive types. (Gabriel Scherer, review
by Florian Angeletti, report by Neven Villani)
• [#12264], [#12289]: Fix compact_allocate to avoid a pathological
case that causes very slow compaction. (Damien Doligez, report by
Arseniy Alekseyev, review by Sadiq Jaffer)
• [#12513], [#12518]: Automatically enable emulated `fma' for Visual
Studio 2019+ to allow configuration with either
pre-Haswell/pre-Piledriver CPUs or running in VirtualBox. Restores
parity with the other Windows ports, which don't require explicit
`--enable-imprecise-c99-float-ops'. (David Allsopp, report by Jonah
Beckford and Kate Deplaix, review by Sébastien Hinderer)
• [#11633], [#11636]: bugfix in caml_unregister_frametable (Frédéric
Recoules, review by Gabriel Scherer)
• [#12636], [#12646]: More prudent reinitialization of I/O mutexes
after a fork() (Xavier Leroy, report by Zach Baylin, review by
Enguerrand Decorne)
• (*breaking change*) [#10845] Emit frametable size on amd64 BSD
(OpenBSD, FreeBSD, NetBSD) systems (emitted for Linux in [#8805])
(Hannes Mehnert, review by Nicolás Ojeda Bär)
• [#12958]: Fix tail-modulo-cons compilation of try-with, && and ||
expressions. (Gabriel Scherer and Nicolás Ojeda Bär, report by
Sylvain Boilard, review by Gabriel Scherer)
• [#12116], [#12993]: explicitly build non PIE executables on x86
32bits architectures (Florian Angeletti, review by David Allsopp)
• [#13018]: Don't pass duplicate libraries to the linker when
compiling ocamlc.opt and when using systhreads (new versions of lld
emit a warning). (David Allsopp, review by Nicolás Ojeda Bär)
[#12061] <https://github.com/ocaml/ocaml/issues/12061>
[#12063] <https://github.com/ocaml/ocaml/issues/12063>
[#12878] <https://github.com/ocaml/ocaml/issues/12878>
[#12971] <https://github.com/ocaml/ocaml/issues/12971>
[#12974] <https://github.com/ocaml/ocaml/issues/12974>
[#12264] <https://github.com/ocaml/ocaml/issues/12264>
[#12289] <https://github.com/ocaml/ocaml/issues/12289>
[#12513] <https://github.com/ocaml/ocaml/issues/12513>
[#12518] <https://github.com/ocaml/ocaml/issues/12518>
[#11633] <https://github.com/ocaml/ocaml/issues/11633>
[#11636] <https://github.com/ocaml/ocaml/issues/11636>
[#12636] <https://github.com/ocaml/ocaml/issues/12636>
[#12646] <https://github.com/ocaml/ocaml/issues/12646>
[#10845] <https://github.com/ocaml/ocaml/issues/10845>
[#8805] <https://github.com/ocaml/ocaml/issues/8805>
[#12958] <https://github.com/ocaml/ocaml/issues/12958>
[#12116] <https://github.com/ocaml/ocaml/issues/12116>
[#12993] <https://github.com/ocaml/ocaml/issues/12993>
[#13018] <https://github.com/ocaml/ocaml/issues/13018>
Docfd 3.0.0: TUI multiline fuzzy document finder
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-docfd-3-0-0-tui-multiline-fuzzy-document-finder/14314/1>
Darren announced
────────────────
Hi all, I am happy to announce Docfd 3.0.0, which adds a
non-interactive search mode and support of DOCXs and other file
formats via `pandoc', as well as many polishes.
[Repo]
Think interactive grep for text files, PDFs, DOCXs, etc, but
word/token based instead of regex and line based, so you can search
across lines easily.
Docfd aims to provide good UX via integration with common text editors
and PDF viewers, so you can jump directly to a search result with a
single key press.
[Repo] <https://github.com/darrenldl/docfd>
Demos
╌╌╌╌╌
Navigating repo:
<https://github.com/darrenldl/docfd/raw/main/demo-vhs-gifs/repo.gif>
Quick search with non-interactive mode:
<https://github.com/darrenldl/docfd/raw/main/demo-vhs-gifs/repo-non-interactive.gif>
PDF navigation:
<https://github.com/darrenldl/docfd/raw/main/screenshots/pdf-viewer-integration.jpg>
Shape with us the New OCaml.org Community Area!
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/shape-with-us-the-new-ocaml-org-community-area/14322/1>
Claire Vandenberghe announced
─────────────────────────────
I’m reaching out to request a few minutes of your time to review the
wireframe for the OCaml community area. Following user interviews with
those unfamiliar with OCaml, we gathered insights on what would be
helpful for you landing on the community page.
As a result, we’re restructuring aspects of the pages and content on
the landing page. This is a wireframe, so the focus is on checking the
navigation, layout, and content, not the User Interface (UI).
Your feedback are needed at this stage, and please feel free to leave
comments directly on Figma, via email, or let’s schedule a quick
call. Thank you for participating in this review. Have a great day and
week ahead.
Link:
<https://www.figma.com/file/7hmoWkQP9PgLTfZCqiZMWa/OCaml-Community-Pages?type=design&node-id=152%3A386&mode=design&t=jzXnvmUyoQth2558-1>
Page: “Wireframe”
Opam-repository: Updated documentation, retirement and call for maintainers
═══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-updated-documentation-retirement-and-call-for-maintainers/14325/1>
Kate announced
──────────────
After having been maintainer of opam-repository for the past 6 and
half years, I'm publicly announcing my retirement from it, to focus on
opam itself. This change has been more or less already in effect since
September last year (following a burnout) and I have since been
working on writing enough documentation so that my move away from
opam-repository can be as smooth as possible.
This documentation is now live in:
• [CONTRIBUTING.md]: documentation at destination of package
maintainers. This document has been rewritten in hopes of being more
helpful for beginner and well as experimented publishers.
• the [opam-repository wiki], which now also includes:
‣ a [FAQ]
‣ [informations about the infrastructure]
‣ a [governance / points of contacts] document
‣ a helper on [How To deal with CI]
‣ a list of all the [current policies] i could think of, as well as
their reasoning and exceptions. These policies were previously
mostly passed down orally, most of them have been in place since
the very beginning
‣ several documents at destination of current opam-repository
maintainers and opam-repository maintainers in training, all
freely accessible for the curious eyes (although rereading them
now, i will admit those documents are not my finest work, as they
were the first ones i wrote in the past 6 months 🙈)
Any improvements to these documents are also welcome. To contribute
simply open a PR on opam-repository, or a ticket on the
[opam-repository bugtracker] to contribute to the wiki.
Hopefully, all these documents are a solid enough base so that they
get updated as time goes on, by current and future opam-repository
maintainers.
I'm also writing this post to call for said future opam-repository
maintainers: if you want to become a maintainer, feel free to contact
@mseri and @raphael-proust. I do recommend the experience of working
with them on opam-repository 😊
[CONTRIBUTING.md]
<https://github.com/ocaml/opam-repository/blob/master/CONTRIBUTING.md>
[opam-repository wiki] <https://github.com/ocaml/opam-repository/wiki>
[FAQ] <https://github.com/ocaml/opam-repository/wiki/FAQ>
[informations about the infrastructure]
<https://github.com/ocaml/opam-repository/wiki/Infrastructure-info>
[governance / points of contacts]
<https://github.com/ocaml/opam-repository/wiki/Governance>
[How To deal with CI]
<https://github.com/ocaml/opam-repository/wiki/How-to-deal-with-CI>
[current policies]
<https://github.com/ocaml/opam-repository/wiki/Policies>
[opam-repository bugtracker]
<https://github.com/ocaml/opam-repository/issues>
DkCoder 0.1.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-dkcoder-0-1-0/14327/1>
jbeckford announced
───────────────────
I wrote an article [DkCoder: Intro to Scripting] that describes a very
early cut of OCaml-ified scripting:
Hello Builder! Scripting is a small, free and important
piece of DkSDK. Walk with me as we use the DkSDK tool
"*DkCoder*" to write little scripts that become
full-fledged programs. My hope is that /within minutes/
you feel like your dev experience is as productive as in
Python, but enhanced so you:
1. have nothing to install except Git and optionally
Visual Studio Code
2. have safe and understandable code ("static typing")
DkCoder is a transparently installed OCaml 4.14 environment with one
API: run a script. It shouldn't be confused with conventional OCaml
distributions, although underneath DkCoder has the conventional
bytecode binaries¹, and `dune' and `ocamllsp'.
No C compiler, Cygwin/MSYS2, Homebrew or MacPorts are needed. Please
skim the article for the exact Windows/macOS/Linux requirements.
It grew out of two things:
1. My frustrations sharing scripts with others. It was easy for
inter-dependencies between scripts to break POSIX shell scripts
(the basis of the DkML installer) and CMake scripts (most of my
tools).
2. My need to have a good delivery vehicle for my own software.
Please don't do anything major with DkCoder yet. In fact, if you think
you'll be using DkCoder for your own scripts or your own software,
please send me a message so I can prioritize/deprioritize.
I'd like to thank @octachron for the [codept analyzer]. It is lightly
used now but as hinted in the Security section of the article it will
become much more important. And also thanks to the projects that have
fixed their newly discovered bytecode-only bugs over the past two
months.
¹: Actually, I bundle a new binary called `ocamlrunx' which is a
DT_NEEDED/LC_LOAD_DYLIB re-linking of `ocamlrun' against all the C
libraries (`ffi', `SDL2*' and their deps today) to get macOS and Linux
bytecode working.
[DkCoder: Intro to Scripting]
<https://diskuv.com/dksdk/coder/2024-intro-scripting/>
[codept analyzer] <https://github.com/Octachron/codept>
A Versatile OCaml Library for Git Interaction - Seeking Community Feedback
══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-versatile-ocaml-library-for-git-interaction-seeking-community-feedback/14155/11>
Continuing this thread, Mathieu Barbin announced
────────────────────────────────────────────────
I've recently pushed updates to the [vcs] public repo with most of the
contents of my early draft. For those interested in early
experimentation, I've created a release on my custom opam-repository.
The interface is still very a work in progress, but you can already
see how the pieces fit together. In particular, the [provider]
component, which is crucial for the dynamic dispatch implementation of
`vcs', is now available on opam. The `vcs' project serves as a good
real-world example of the capabilities this provides.
Please feel free to open issues on GitHub with general feedback,
requests, or to start a discussion.
@kopecs, I don't have a precise timeline for an initial publication on
opam yet. I've created this [milestone] if you'd like to follow the
progress or leave a comment. Thank you for your interest!
@paurkedal: Your setup has been a great source of inspiration for me,
and I've found it incredibly helpful. Thank you so much!
@samoht: I chose the approach that felt most comfortable for this
particular project, but I greatly appreciate your input. I'll
definitely keep your suggestions in mind for future projects. Thanks!
[vcs] <https://github.com/mbarbin/vcs>
[provider] <https://opam.ocaml.org/packages/provider/>
[milestone] <https://github.com/mbarbin/vcs/milestone/1>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [My experience at IndiaFOSS 2023: Community, Workshop, and Talks]
• [Lean 4: When Sound Programs become a Choice]
[the ocaml.org blog] <https://ocaml.org/blog/>
[My experience at IndiaFOSS 2023: Community, Workshop, and Talks]
<https://tarides.com/blog/2024-03-13-my-experience-at-indiafoss-2023-community-workshop-and-talks>
[Lean 4: When Sound Programs become a Choice]
<https://ocamlpro.com/blog/2024_03_07_lean4_when_sound_programs_become_a_choice>
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
to the [caml-list].
[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>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 34523 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-03-12 10:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-03-12 10:31 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 55096 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-03-05 14:50 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-03-05 14:50 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 54604 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-02-27 13:53 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-02-27 13:53 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 51611 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-02-20 9:12 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-02-20 9:12 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 31115 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-02-13 8:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-02-13 8:42 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 51975 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-02-06 15:14 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-02-06 15:14 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 34537 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-01-30 14:16 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-01-30 14:16 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 61379 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-01-23 9:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-01-23 9:45 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 52817 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-01-16 10:01 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-01-16 10:01 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 34402 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-01-09 13:40 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-01-09 13:40 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 40497 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2024-01-02 8:59 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2024-01-02 8:59 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 27569 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-12-26 10:12 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-12-26 10:12 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 29435 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-12-19 10:10 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-12-19 10:10 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 49491 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-12-12 10:20 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-12-12 10:20 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 34799 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-12-05 10:13 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-12-05 10:13 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 68802 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-11-28 9:09 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-11-28 9:09 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 56955 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-11-21 7:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-11-21 7:47 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 33940 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-11-14 13:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-11-14 13:42 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 28466 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-11-07 10:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-11-07 10:31 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 30435 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-10-31 10:43 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-10-31 10:43 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 49426 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-10-17 7:46 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-10-17 7:46 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 32751 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-10-10 7:48 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-10-10 7:48 UTC (permalink / raw)
To: lwn, caml-list
[-- Attachment #1: Type: text/html, Size: 38283 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-10-03 13:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-10-03 13:00 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 32210 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-09-19 8:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-09-19 8:54 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 43166 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-09-12 13:21 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-09-12 13:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 34215 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-09-05 9:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-09-05 9:00 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 29035 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-08-29 13:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-08-29 13:04 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 56829 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-08-22 9:20 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-08-22 9:20 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 36313 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-08-15 16:33 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-08-15 16:33 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 62179 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-08-08 8:53 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-08-08 8:53 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 37269 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-08-01 7:13 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-08-01 7:13 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 38473 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-07-25 8:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-07-25 8:45 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 62475 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-07-11 8:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-07-11 8:45 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 46626 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-07-04 9:18 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-07-04 9:18 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 27030 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-06-27 8:38 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-06-27 8:38 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 49044 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-06-20 9:52 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-06-20 9:52 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 57974 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-06-13 7:09 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-06-13 7:09 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 26299 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-06-06 14:22 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-06-06 14:22 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 69103 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-05-30 15:43 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-05-30 15:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 24014 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-05-23 9:41 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-05-23 9:41 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 85136 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-05-16 13:05 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-05-16 13:05 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 51443 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-05-09 11:49 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-05-09 11:49 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/html, Size: 59626 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-05-02 8:01 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-05-02 8:01 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 21512 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-04-25 9:25 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-04-25 9:25 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 43685 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-04-18 8:50 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-04-18 8:50 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 19346 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-04-11 12:41 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-04-11 12:41 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 38699 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-04-04 8:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-04-04 8:45 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 21100 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-03-28 7:21 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-03-28 7:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 33522 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-03-21 10:07 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-03-21 10:07 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 34086 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-03-14 9:52 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-03-14 9:52 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 38908 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-03-07 9:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-03-07 9:02 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 31182 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-02-28 14:38 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-02-28 14:38 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 26591 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-02-21 10:19 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-02-21 10:19 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 36793 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-02-14 8:12 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-02-14 8:12 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 25964 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-02-07 8:16 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-02-07 8:16 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 30531 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-01-31 6:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-01-31 6:44 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 19643 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-01-24 8:57 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-01-24 8:57 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 36100 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2023-01-17 8:37 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2023-01-17 8:37 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 27709 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-11-29 14:53 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-11-29 14:53 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/html, Size: 36558 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-09-27 7:17 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-09-27 7:17 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 29726 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 20 to
27, 2022.
Table of Contents
─────────────────
Esperanto, when OCaml meets Cosmopolitan
OBazl Toolsuite - tools for building OCaml with Bazel
Orsetto: structured data interchange languages (release 1.1.2)
Interest in a Http_sig library?
Outreachy summer ’22 closing commemoration session on 23rd Sept
findlib-1.9.6
Interesting OCaml Articles
Other OCaml News
Old CWN
Esperanto, when OCaml meets Cosmopolitan
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-esperanto-when-ocaml-meets-cosmopolitan/10501/1>
Calascibetta Romain announced
─────────────────────────────
I am delighted to present the first *experimental* release of
Esperanto. This project is a new OCaml _toolchain_ that creates
binaries compiled with the [Cosmopolitan C library] and linked with
the [αcτµαlly pδrταblε εxεcµταblε] link script. The binary produced is
then portable to different platforms:
<https://worker.jart.workers.dev/redbean/linux.png>
<https://worker.jart.workers.dev/redbean/windows10.png>
<https://worker.jart.workers.dev/redbean/msdos60.png>
<https://worker.jart.workers.dev/redbean/macos.png>
<https://worker.jart.workers.dev/redbean/freebsd64.png>
<https://worker.jart.workers.dev/redbean/openbsd.png>
<https://worker.jart.workers.dev/redbean/netbsd2.png>
The main objective of Esperanto is to provide a toolchain capable of
producing a portable binary from an existing project. This would allow
to finally be able to distribute software for all these platforms
without having to:
1) manage multiple platforms orthogonally, the Cosmopolitan C library
offers you the POSIX API for all platforms (including Windows)
2) Produce several versions of the same software for each platform.
Only the binary is needed to run on all platforms
Cosmopolitan *does not* however produce a binary with a multi-platform
assembler. At this stage, our distribution only supports the `x86_64'
assembler (the most common one) but we are working on the possibility
to produce a binary with different assemblers.
I would like to give special thanks to Justine, the author of the
Cosmopolitan project (to develop [redbean], a small portable HTTP
server) for her excellent work.
[Cosmopolitan C library] <https://justine.lol/cosmopolitan/>
[αcτµαlly pδrταblε εxεcµταblε] <https://justine.lol/ape.html>
[redbean] <https://redbean.dev/>
A _toolchain_
╌╌╌╌╌╌╌╌╌╌╌╌╌
In OCaml, the “toolchain” principle allows the existence of several
compilers within an OPAM switch and to choose one of them when it
comes to cross-compiling a project. This principle, even though it is
not clearly defined and even though its use remains very limited,
exists through the `ocamlfind` tool.
You can find these toolchains in your switch:
┌────
│ $ ls $(opam var lib)/findlib.conf.d/
│ esperanto.conf solo5.conf
└────
From our experience with Mirage as well as the work done in `dune'
regarding cross-compilation, the choice to propose a new _toolchain_
in order to allow cross-compilation of projects with OPAM is both a
historical choice but also the most relevant one in our opinion [1].
◊ Why we need to cross-compile?
The term cross-compilation can be misunderstood if we only consider
the question of the assembler issued by the compiler (does it match
the host assembler or not). In our case, cross-compilation is a
broader term that implies the use of external artefacts to the
compiler that are different from the default and the use of compiler
options that must be used throughout the production of the final
binary.
In other words, even though we are emitting the same assembler, we are
doing so in a different “context” which requires the definition of a
new _toolchain_ which includes our artefacts and compiler options.
One of these artefacts is of course the C library used by the compiler
which will then be systematically used by the _runtime caml_, the well
named `libasmrun.a'. This is why, for example, there is a version of
OCaml with [musl]. So there must be a version of OCaml with
Cosmopolitan.
This new _toolchain_ also allows you to include the necessary options
for compiling C files because, yes, you can compile a C file with
`ocamlopt'.
In order to provide a coherent _workflow_ for a project, we need to
provide not only a `libasmrun.a' compiled with our Cosmopolitan C
library but also an OCaml compiler capable of invoking the C compiler
with the right options required by Cosmopolitan.
Finally, we also need to describe in this _toolchain_ how to link the
object files together to actually produce a portable binary using the
APE script.
[musl] <https://musl.libc.org/>
◊ A simple example with this new _toolchain_
Installing Esperanto is very easy with OPAM. It will install the
cross-compiler and the necessary files so that `ocamlfind~/~dune' can
recognise this new _toolchain_:
┌────
│ $ opam install esperanto
└────
Finally, let’s try to produce a simple binary that displays “Hello
World!”:
┌────
│ $ cat >main.ml <<EOF
│ let () = print_endline "Hello World!"
│ EOF
│ $ ocamlfind -toolchain opt main.ml
│ $ objcopy -S -O binary a.out
│ $ file a.out
│ a.out: DOS/MBR boot sector
└────
The binary produced can already be executed. However, there are still
some issues that have been fixed since then but which are probably not
yet integrated in your system. They concern `zsh' and `binfmt_misc' in
particular.
The first problem with `zsh' is that it does not recognise the binary
correctly. This problem has been fixed in the latest version of
`zsh.5.9.0'.
┌────
│ $ zsh --version
│ zsh 5.8.1
│ $ zsh
│ $ ./a.out
│ zsh: exec format error: ./a.out
└────
The second problem concerns `binfmt_misc' which intervenes upstream at
the execution of your programs in order to choose how to execute them.
In this case, `binfmt_misc' recognises Cosmopolitan binaries as
Windows software by default.
Here too, a solution is available and described by the author of
Cosmopolitan here: [APE loader]
[APE loader] <https://justine.lol/apeloader/#binfmt_misc>
◊ Execution & Assimilation
If you are not concerned by the above problems, you can simply run
the program:
┌────
│ $ ./a.out
│ Hello World!
└────
There is a final solution that requires a little explanation of what
αcτµαlly pδrταblε εxεcµταblε is. Indeed, the latter makes it
possible to create a polyglot binary whose first point of entry is
not your program but a small program which tries to recognize on
which platform the binary tries to run.
After this recognition, this little program will “inject” values
corresponding to the platform in which you try to run your program
in order to finally let Cosmopolitan manage the translation between
its interface and the real POSIX interface that your system offers.
Of course, this step has a cost as it adds an indirection between
what your program wants to do and what is available on the system
running your program. However, APE offers a very special option that
allows the program to be assimilated to the platform in which it
wants to run.
┌────
│ $ file a.out
│ a.out: DOS/MBR boot sector
│ $ sh -c "./a.out --assimilate"
│ $ file a.out
│ a.out: ELF 64-bit LSB executable, x86-64
│ $ ./a.out
│ Hello World!
└────
This option makes your application truly native to the platform in
which you run it. This means above all that the program is *no
longer* portable.
◊ Esperanto, `dune' & `opam monorepo'
The `dune' software also incorporates this toolchain idea using the
`-x' option. More pragmatically, it is possible to define a new dune
context to use Esperanto as a compilation toolchain.
However, the original aim of Esperanto is to produce a portable
binary. This implies, among other things, that it should not depend
on remaining artefacts in order to run and, in this sense, the
compilation of your project should be a static compilation. This
means that all dependencies of your project must be available to
compile in the same context as your project.
Again, this is particularly necessary if any of your dependencies
include C files, so they need to be compiled in some way.
This is where `opam monorepo' comes in, it will simply “vendor” your
dependencies into a “duniverse” folder. Here are the steps needed to
compile a project with Esperanto. We’ll take [`decompress'] as an
example which produces a binary that can compress/decompress
documents:
┌────
│ $ git clone https://github.com/mirage/decompress
│ $ cd decompress
│ $ cat >>bin/dune <<EOF
│ (rule
│ (target decompress.com)
│ (enabled_if
│ (= %{context_name} esperanto))
│ (mode promote)
│ (deps decompress.exe)
│ (action (run objcopy -S -O binary %{deps} %{target})))
│ EOF
│ $ cat >dune-workspace <<EOF
│ (lang dune 2.0)
│ (context (default))
│ (context
│ (default
│ (name esperanto)
│ (toolchain esperanto)
│ (merlin)
│ (host default)))
│ $ opam monorepo lock --build-only
│ $ opam monorepo pull
│ $ dune build bin/decompress.com
│ $ sh -c "echo 'Hello World' | ./bin/decompress.com -d | ./bin/decompress.com"
│ Hello World
└────
[`decompress'] <https://github.com/mirage/decompress>
Issues
╌╌╌╌╌╌
Apart from the outcomes described above, however, the Esperanto
toolchain is not complete. Indeed, the OCaml distribution gives
several libraries such as `unix.cmxa' and `threads.cmxa'. A little
work has been done to make the former available. The second one is
however unavailable for the moment since Cosmopolitan only partially
implements `pthread'.
However, it seems that the author of Cosmopolotian wants to implement
the rest of the `pthread' API which will then allow us to provide
support for `threads.cmxa' and OCaml 5.
This of course makes support for the projects more limited than we
imagined (and that’s why this release is experimental) however, an
effort has already been made to lwt into Cosmopolitan’s hypothetical
future support for `pthread'.
Future
╌╌╌╌╌╌
As explained above, support for `threads.cmxa' and OCaml 5 remains the
priority. however, an effort has already been made to support [Lwt]
via Cosmopolitan’s hypothetical future support for `pthread'.
However, it is possible that Cosmopolitan could become a target for
the MirageOS project in the same way as Solo5 (or our recent
experiment on Raspberry Pi 4).
In this sense, we will surely propose an integration in MirageOS so
that projects can both produce unikernels with Solo5 or portable
binaries with Cosmopolitan.
[1] However, the question remains open at several levels, that of the
compiler, that of OPAM and of course that of `dune'. It is clear that
the current situation is not the best in terms of what we need to do
to produce such a cross-compiler. Only the feedback from Solo5 (which
requires cross-compilation) allows us to say that it is surely the
right choice for what we want to offer.
[Lwt] <https://github.com/ocsigen/lwt/>
Conclusion
╌╌╌╌╌╌╌╌╌╌
We hope that this project will facilitate the distribution of
software. You can read a more technical article about our work [here].
Finally, I would like to thank [robur.io] (an association you [can
help]) for allowing me to do this project.
*EDIT*: The author of Cosmopolitan just released Cosmopolitan with
`pthread' support. So we will definitely try to improve our
distribution to include OCaml with `threads.cmxa' support and move
forward with OCaml 5!
[here] <https://blog.osau.re/articles/esperanto.html>
[robur.io] <https://robur.io/>
[can help] <https://robur.io/Donate>
OBazl Toolsuite - tools for building OCaml with Bazel
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/obazl-toolsuite-tools-for-building-ocaml-with-bazel/10021/15>
Deep into this thread, Yawar Amin asked and Gregg Reynolds replied
──────────────────────────────────────────────────────────────────
Doesn’t dune get advertised as being able to handle
multiple programming languages, including C/C++?
There’s really no comparison. Dune evidently can use the (C ABI)
outputs of a “foreign” build (if you write the glue code needed to
make this work) but there’s no real /build/ integration, and no
hermeticity guarantees. Under Bazel different languages use different
rulesets but they’re all Bazel rulesets, so you get one dependency
graph across all languages, and if the rulesets are hermetic you get a
hermetic build. Without ABI restrictions. For example if your build
needs to run a Python (or Javascript, Ruby, whatever) tool, Bazel will
build the tool and run it for you.
Even for C I think Bazel has much better integration. The rules in
rules_cc (e.g. cc_library producing a .a file) deliver a CcInfo
provider (a provider is a kind of struct whose fields contain the
artifacts delivered by a build action). The rules in rules_ocaml (e.g.
ocaml_module) understand CcInfo dependencies and pass them around
using OcamlProvider (a provider specific to the ocaml rules). Bazel
supports a merge operation for CcInfo, and the ocaml rules always
merge their CcInfo deps and pass them on. So every build target
delivers the merge of all its CcInfo deps. The ocaml_binary rule that
links its dependencies into an executable merges its CcInfo deps
(which include merged CcInfo from their deps, recursively) and ends up
with a single CcInfo containing every cc dependency in the dep graph,
in the right order, with no duplicates. Then its simply a matter of
constructing the link command with the appropriate –ccopt options.
More succinctly: you can add a C dep directly to the module that needs
it, and Bazel it pass it up the dependency chain, ensuring that it
ends up on the command line when needed - building archives or
executables. You don’t need to add a C dep to an archive target when
only one of n modules in the archive actually depends on it.
I’ve just started working on rules_jsoo, which I think will nicely
demonstrate the virtues of Bazel integration. The Bazel ecosystem
includes a bunch of tools for working with Javascript; for example
rules_js and rules_nodejs make it easy to control which node toolchain
version to use, integrate npm stuff, etc. Wouldn’t it be nice to be
able to use such tools directly, without writing a bunch of glue code?
Now a key element of Bazel integration is the use of providers. Rules
deliver providers, and since providers act as a kind of rudimentary
type system, I can use the JsInfo provider (defined by rules_js) to
integrate rules_jsoo with the larger Bazel js ecoystem. For example,
the jsoo_library rule takes the OcamlProvider provider delivered by
ocaml_module rules, which contains the .cmo file. So jsoo_library runs
those .cmo files through the jsoo compiler and delivers the resulting
js files in a JsInfo provider. That provider is suitable as input to
the rules in rules_js, which gives us seamless integration. So we can
use the js_binary rule of rules_js to run code produced by
jsoo_library under node. All that’s needed is to list the latter as a
dependency of the former. That’s the plan, anyway. Isn’t that nice?
Gregg Reynolds said and Daniel Bünzli replied
─────────────────────────────────────────────
Ideally somebody learning a new language should not need
to spend any time (at first) dealing with a build language
too.
This doesn’t only apply to learning. It also applies to prototyping,
hypothesis generation and testing.
That’s the reason why I built [`brzo'] which I hope I’ll be able to
release at some point (still needs a good design review and changes to
the OCaml strategy since it assumed we were moving towards a model
that didn’t happen in the end – namely the [library linking proposal],
I’d also like to add more languages to the mix but that could wait).
None of my projects do not start with ~brzo~ing these days and the
hassle free build experience is exhilarating.
Build systems often are “complex and confusing”, but
that’s largely because the problem space itself is complex
and confusing. There’s no getting around that.
Note however that this is largely /accidental/ complexity due to the
fact that compilers work in idiosyncratic ways for what build systems
need in order to do their incremental and parallelization business.
They are still stuck in a world where people would invoke their
compiler manually at the cli level or specify the invocations
themselves in a `Makefile'.
In fact if it were not for the actual tools and the (lack) of
information they give us, build is in fact an excessively simple
problem.
More specific to OCaml, the compiler clis have an insane amount of
quirks and the whole system greatly suffers from an underspecified
linking model. Basically it was not a good idea to let that be defined
by a third party tool, if only so that you can actually talk about
libraries in error messages from the compiler.
[`brzo'] <https://erratique.ch/software/brzo>
[library linking proposal] <https://github.com/ocaml/RFCs/pull/17>
Orsetto: structured data interchange languages (release 1.1.2)
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-release-1-1-2/10506/1>
james woodyatt announced
────────────────────────
Announcing the release to OPAM of [Orsetto 1.1.2], an update to a
personal project of mine not sponsored by my employer. Licensed with
BSD 2-Clause.
*Q. What is Orsetto?*
Aspires to do eventually for OCaml more or less what [Serde] has done
for Rust, i.e. to be a curated and self-contained collection of
structured data interchange languages with a cohesive and unified
model of serialization and deserialization.
Two interchange languages are currently supported: [JSON ] and [CBOR
].
*Q. What is new in this release?*
Mostly error corrections, particularly in the CBOR library, produced
by improving test coverage.
The change log for the release is here: [CHANGES.md ]
Highlights:
• Major improvements in test coverage.
• Many corrections for logic errors.
• A few minor usability improvements.
Some things have not changed:
• Still has no Programmer Guide or Tutorial, or really any
introduction at all.
• Still requires *ocamlfind* and builds with *omake*, which is
currently not compatible with OCaml 5.0.
• Still only supports JSON and CBOR.
*Q. It looks incomplete. What are your plans for future development?*
Yes, it’s a personal project, and yes, I’m aware there are no reverse
dependencies on it currently in the public OPAM repository. Still, I’d
welcome opportunities to collaborate with others who share my vision
for the project. As long as it’s just me working on this, development
will continue to be somewhat slow, as I’m prone to over-engineer
things I care about. I have a lot of projects, and this is the only
open source one.
• *Orsetto 1.0.3* is the previous release. It offered parsers and
emitter combinators for JSON and CBOR for OCaml >= 4.06.1
(including 4.13~alpha1). The quality of its JSON support is
adequate, and it scores well on the >[nst/JSONTestSuite] tests. The
quality of its CBOR support is provisional, >and not recommended.
• *Orsetto 1.1.2* is the current release. It adds generalized and
extensible structured data interchange models with specializations
for producing emitters and parsers for JSON and CBOR. The quality
of the CBOR support is much improved, and I’m using it with good
results in other projects. Supported on OCaml >= 4.08.
• *Orsetto 1.2* is the next planned release. It will drop interfaces
marked `@caml.deprecated` in the 1.1 release. It will also drop
support for OCaml < 4.10, and it will stop depending on
**ocamlfind**. I hope to add a PPX for deriving parsers and
emitters from OCaml data type definitions. I might also consider
one or more new interchange languages— suggestions are heartily
encouraged.
[Orsetto 1.1.2] <http://opam.ocaml.org/packages/orsetto/>
[Serde] <https://serde.rs>
[JSON ] <https://json.org>
[CBOR ] <https://cbor.io>
[CHANGES.md ] <https://bitbucket.org/jhw/orsetto/src/r1.1.2/CHANGES.md>
[nst/JSONTestSuite] <https://github.com/nst/JSONTestSuite>
Interest in a Http_sig library?
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/interest-in-a-http-sig-library/10518/1>
Kiran Gopinathan announced
──────────────────────────
Heyo all! I’ve been working on an activitypub server for a while now,
and while it’s still not yet complete, recently I’ve reached a point
where I realised that I’ve actually been sitting on some libraries
that the community might benefit from, as the current ecosystem
doesn’t seem to handle these things.
One such component that seemed to be in a state that was suitable to
split off from was a small helper module to implement a particular
http signature scheme that seems to be rather common in the
activitypub scene.
In particular, the scheme I’m referring to is defined here:
<https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12>
┌────
│ Signing HTTP Messages
│ draft-cavage-http-signatures-12
│
│ Abstract
│ When communicating over the Internet using the HTTP protocol, it can
│ be desirable for a server or client to authenticate the sender of a
│ particular message. It can also be desirable to ensure that the
│ message was not tampered with during transit. This document
│ describes a way for servers and clients to simultaneously add
│ authentication and message integrity to HTTP messages by using a
│ digital signature.
└────
I’ve written a small library that glues together some components in
the OCaml ecosystem to somewhat handle the signing (I have been mainly
working off an “implement-enough-to-make-the-system-work” process
rather than directly transcribing the specification above):
┌────
│ (** [verify ~signed_string ~signature key] returns true iff
│ [signature] over [signed_string] is valid according to [key]. *)
│ val verify: signed_string:string -> signature:string -> X509.Public_key.t -> bool
│
│ (** [verify_request ~resolve_public_key req] verifies that a dream
│ request has been signed according to the HTTP signature scheme *)
│ val verify_request:
│ resolve_public_key:(string -> (X509.Public_key.t, 'a) Lwt_result.t) ->
│ Dream.request -> (bool, 'a) result Lwt.t
│
│ (** [build_signed_headers ~priv_key ~key_id ~headers ~body_str
│ ~current_time ~method_ ~uri] returns a list of signed headers using
│ [priv_key] according to the HTTP signature scheme. [key_id] should
│ be a string that can be used to look up the public key associated
│ with [priv_key]. *)
│ val build_signed_headers:
│ priv_key:X509.Private_key.t ->
│ key_id:string ->
│ headers:string StringMap.t ->
│ body_str:string ->
│ current_time:Ptime.t -> method_:string -> uri:Uri.t -> (string * string) list
└────
The library is currently published at
<https://github.com/Gopiandcode/http_sig_ocaml> under the LGPL, but I
haven’t released it on opam.
Anyway, I was wondering if anyone else had interest in this kind of
package, and whether it would be a good candidate for submission to
opam - or if there are actually already existing libraries in the
OCaml ecosystem that would actually already do this.
Outreachy summer ’22 closing commemoration session on 23rd Sept
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-summer-22-closing-commemoration-session-on-23rd-sept/10450/5>
Patrick Ferris announced
────────────────────────
Thank you to everyone that could make it to the presentation today.
The presentation is now live:
<https://watch.ocaml.org/videos/watch/dc5bbf5b-3dd9-4c8d-b26a-71e730a67788>
:camel:
In particular a massive congratulations and thank you to
@moazzammoriani and @IIITM-Jay. Thank you also to @sudha for being the
driving force behind making the presentation happen again this round!
See you all for the next round!
Aside: if anybody has any issues with the live video please do reach
out here either publicly or privately, we gave prior warning of our
intentions to record and put the video on watch.ocaml.org, but I
appreciate some people joined a little later/might have some
reservations etc.
findlib-1.9.6
═════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2022-09/msg00007.html>
Gerd Stolpmann announced
────────────────────────
findlib-1.9.6 is out, now supporting OCaml-5.00 (as far as we know
it). There are also a few other install-related fixes in it.
For manual, download, manuals, etc. see here:
<http://projects.camlcity.org/projects/findlib.html>
An updated OPAM package will follow soon.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/100>
Deep in this thread, alan said
──────────────────────────────
An interesting paper that uses OCaml is
<http://gallium.inria.fr/~fpottier/publis/fpottier-elaboration.pdf> by
Francois Pottier, which gives a declarative DSL for implementing type
rules with applicative functors. It has an associated library,
<https://opam.ocaml.org/packages/inferno/>.
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Tarides Sponsors High School Hackers]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Tarides Sponsors High School Hackers]
<https://tarides.com/blog/2022-09-23-tarides-sponsors-high-school-hackers>
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: 46499 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-09-20 14:01 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-09-20 14:01 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 22079 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 13 to
20, 2022.
Table of Contents
─────────────────
Sandmark Nightly Service now reports Instructions Retired along with Time
Outreachy December 2022
Unicode 15.0.0 update for Uucd, Uucp, Uunf and Uuseg
OUPS meetup september 2022 (french only)
strymonas v2: library for highest-performance stream processing
OCaml Community Code of Conduct
Use OCaml to interact with Neovim
What will be required to transpile OCaml to Lua?
OBazl Toolsuite - tools for building OCaml with Bazel
Old CWN
Sandmark Nightly Service now reports Instructions Retired along with Time
═════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/sandmark-nightly-service-now-reports-instructions-retired-along-with-time/10475/1>
Shakthi Kannan announced
────────────────────────
Sandmark Nightly is a service for the OCaml compiler developers that
helps benchmark the development branches of the compiler on the large
set of Sandmark benchmarks on tuned machines and reports the results
in an interactive UI. Currently, Sandmark nightly reported many
metrics including running time. But running time is a notoriously
noisy metric on modern architectures due to the effects of modern OS,
arch and micro-arch optimisations. There could be swings of 50% in
either directions when the directory in which the program is run
changes.
While we run Sandmark benchmarks on tuned machines, we still see
impact of noise on the real time measurements. To this end, we
introduce a new metric into Sandmark nightly that in addition to real
time, would help interpret the results accounting for the noise. We
now report “instructions retired” for Sandmark runs. Instructions
retired report the number of instructions executed by the program
during its run and hence is shielded from the noise that affects real
time measurements. Of course, the same number of instructions may be
discharged at different rates by the processor due to
instruction-level parallelism and hence, the instructions discharged
metric should be used in conjunction with real time measurements. For
example, if a new compiler feature adds 2 instructions to the prolog
of the function, then the instructions retired metric should inform
you how many new instructions are actually executed on top of the
baseline.
The instructions retired metric is collected from `perf' command. We
also have other useful metrics from perf such as page faults,
branches, branch misses, cache misses at various levels of the
hierarchy, etc. We will add graphs to report these going forward.
Enjoy the new feature, and as ever, report issues and bugs to
[Sandmark Issues].
The web service is available at <https://sandmark.tarides.com> and you
can select the `Perfstat Output' radio button on the left panel as
shown below.
<https://global.discourse-cdn.com/standard11/uploads/ocaml/original/2X/5/5f9d3d8d87ba6821e8f41f027ce7a6b0074ec95a.png>
After selecting the variants and a baseline for comparison, you can
view the normalised `instructions per cycle' change as illustrated
below:
<https://global.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1baf673b1246eb3505f8603a260ee4f22f32fb85.png>
You can also request for your development branches to be added to the
Sandmark Nightly Service at the [sandmark-nightly-config] repository
for the nightly runs.
[Sandmark Issues] <https://github.com/ocaml-bench/sandmark/issues>
[sandmark-nightly-config]
<https://github.com/ocaml-bench/sandmark-nightly-config>
References
╌╌╌╌╌╌╌╌╌╌
1. Run perfstat with Sandmark nightly service. [Sandmark PR #394]
2. Add webpage with perfstat output from Sandmark. [Sandmark-nightly
PR #81]
3. perfstat.ipynb. [Sandmark perfstat Jupyter notebook]
[Sandmark PR #394] <https://github.com/ocaml-bench/sandmark/pull/394>
[Sandmark-nightly PR #81]
<https://github.com/ocaml-bench/sandmark-nightly/pull/81>
[Sandmark perfstat Jupyter notebook]
<https://github.com/ocaml-bench/sandmark/blob/main/notebooks/perfstat/perfstat.ipynb>
Outreachy December 2022
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-december-2022/10336/18>
Patrick Ferris said
───────────────────
Just a reminder the deadline for mentor signup is in 9 days, the same
day as
<https://discuss.ocaml.org/t/outreachy-summer-22-closing-commemoration-session-on-23rd-sept/10450>
:camel:
Unicode 15.0.0 update for Uucd, Uucp, Uunf and Uuseg
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-unicode-15-0-0-update-for-uucd-uucp-uunf-and-uuseg/10485/1>
Daniel Bünzli announced
───────────────────────
Unicode 15.0.0 was released on the 13th of september. It adds 4489 new
characters to the standard.
Given the increasing contributions from the South Asian subcontinent
to OCaml we are glad this includes support for the 42 (sic) characters
of the [Nag Mundari script]. For information about 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.
Note that starting from Unicode 16.0.0 – that is in a year – these
libraries will be changed to use the UTF decoders of the standard
library rather than rely on Uutf. They will thus only be available for
OCaml >= 4.14.
The OCaml tips of the [minimal Unicode introduction], which you should
read if Unicode still puzzles you, have been updated to mention the
new standard library UTF decoders.
Also, the `ucharinfo' tool distributed with `uucp'[^1] can now also
lookup characters by matching substrings in their Unicode name or name
aliases.
Best,
Daniel
A big thanks for funding from the [OCaml Software Foundation] and from
my [faithful donators].
• Uucd 15.0.0 Unicode character database decoder for OCaml.
<http://erratique.ch/software/uucd>
• Uucp 15.0.0 Unicode character properties for OCaml.
<http://erratique.ch/software/uucp>
• Uunf 15.0.0 Unicode text normalization for OCaml.
<http://erratique.ch/software/uunf>
• Uuseg 15.0.0 Unicode text segmentation for OCaml.
<http://erratique.ch/software/uuseg>
[^1]: It’s a depopt you’ll need `opam install cmdliner uutf uunf uucp'
to install it.
[Nag Mundari script]
<https://unicode.org/charts/PDF/Unicode-15.0/U150-1E4D0.pdf>
[announcement page]
<https://blog.unicode.org/2022/09/announcing-unicode-standard-version-150.html>
[minimal Unicode introduction]
<https://erratique.ch/software/uucp/doc/unicode.html>
[OCaml Software Foundation] <http://ocaml-sf.org/>
[faithful donators] <https://github.com/sponsors/dbuenzli>
OUPS meetup september 2022 (french only)
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/oups-meetup-september-2022-french-only/10492/1>
zapashcanon announced
─────────────────────
(this is in french only as the talks will be in french it’s probably
not relevant for english speakers)
Le prochain OUPS aura lieu le *jeudi 29 septembre* 2022. Le
rendez-vous est fixé à *19h* au *4 place Jussieu (salle à préciser)*,
75005 Paris.
*[L’inscription est obligatoire]* pour pouvoir accéder au meetup !
Les exposés seront également retransmis en ligne sur le [galène du
OUPS].
Toutes les informations sont disponibles sur le [site du OUPS].
*Programme :*
*COBOL 101 – Émilien Lemaire*
COBOL est un langage très ancien et est assez éloigné de ceux que nous
manipulons tous les jours. Malgré cela il reste l’un des plus utilisés
dans le monde.
Durant cette présentation je vais donc vous introduire au langage,
voir comment sont écrit les programmes, comment les variables
sont-elles déclarées et comment les manipuler. Je vais aussi vous
présenter quelques features “intéressantes” du langage, dont certaines
sont inattendues.
*OCaml Multicore – Florian Angeletti*
*Opam-bin: Opam et paquets binaires – Fabrice Le Fessant*
L’utilisation d’un gestionnaire de paquets sources comme Opam n’est
pas toujours optimale en temps, car l’outil passe beaucoup de temps à
recompiler des paquets, dèjà compilés dans le passé ou par d’autres
utilisateurs. Le plugin Opam-bin répond à ce problème en permettant de
créer à la volée des paquets binaires, qui seront réutilisés à
l’avenir et peuvent être partagés avec d’autres utilisateurs. L’exposé
montre son utilisation et comment il fonctionne.
Les présentations seront suivies par des discussions libres. Les
pizzas seront offertes par la fondation OCaml ! :pizza:
[L’inscription est obligatoire]
<https://www.meetup.com/fr-FR/ocaml-paris/events/288520108/>
[galène du OUPS] <https://galene.irill.org/group/oups/>
[site du OUPS] <https://oups.frama.io/>
strymonas v2: library for highest-performance stream processing
═══════════════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2022-09/msg00004.html>
Oleg announced
──────────────
As has just been announced at the OCAML 2022 workshop, the new,
re-written version of strymonas library is now available at
<https://strymonas.github.io>
Strymonas is the stream processing library that achieves the highest
performance of existing OCaml streaming libraries, attaining the speed
and memory efficiency of hand-written state machines. It supports
finite and infinite streams with the familiar declarative interface,
of any combination of map, filter, take(while), drop(while), zip,
flatmap combinators and tupling. Experienced users may use the
lower-level interface of stateful streams and implement accumulating
maps, compression and windowing. The library is based on assured code
generation (at present, of OCaml and C) and guarantees in all cases
complete fusion.
Compared with the original strymonas (POPL 2017), the new version is
completely re-written and:
• Generates not only OCaml but also C (which needs no OCaml run-time
and vectorizable)
• Has Core + code-generation Backends architecture: MetaOCaml is
needed only for the OCaml backend and benchmarks; the Core and the C
generation backend are pure OCaml. More backends can be easily
added.
• The complete fusion is now achieved in all cases
• Supports both user-friendly and familiar declarative combinators,
and low-level core of stafeful streams (which can be used together)
• Core streams support streams over tuples, records and even abstract
data types
• Fusion is now performed as normalization-by-evaluation
The paper <https://strymonas.github.io/docs/ocaml-22.pdf> and the
OCAML 2022 talk (soon to be available on YouTube’s SIGPLAN
channel, among all other talks of the ICFP 2022 event) give
more details. The github repo contains the complete code of
the library, examples and all benchmarks.
OCaml Community Code of Conduct
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-community-code-of-conduct/10494/1>
Sudha Parimala announced
────────────────────────
Hello all! On behalf of the OCaml CoC committee, I’d like to present
the proposed Code of Conduct for the OCaml community. We hope this is
a step towards ensuring a friendly and inclusive community for
everyone.
The CoC text, based on Contributor Covenant can be found [here].
[here]
<https://gist.github.com/Sudha247/ed049de0fd91d26f43777fb11ac0453f>
The committee
╌╌╌╌╌╌╌╌╌╌╌╌╌
The current committee consists of the following people:
• Louis Roché ( @Khady, Ahrefs)
• Marcello Seri ( @mseri, University of Groningen)
• Raja Boujbel ( @rjbou, OCamlPro)
• Simon Cruanes ( @c-cube, Imandara Software)
• Sonja Heinze (@pitag, Tarides)
Scope
╌╌╌╌╌
The spaces within the scope of the committee at the moment are:
• discuss.ocaml.org
• OCaml mailing list
• OCaml IRC
• OCaml GitHub organisation
Timeline
╌╌╌╌╌╌╌╌
The committee has discussed on the CoC text. We’d be happy to hear any
feedback from the community. If all goes well, the CoC will be
enforced roughly a month from now. We’ll keep this thread updated with
any developments.
Role of OCaml Software foundation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While this effort is endorsed by the OCaml Software Foundation,
they’re not directly involved with the committee’s operation or
decisions by the committee on the enforcement, and this would remain
the same in future.
Onboarding more projects
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The committee is open to onboarding more projects under the umbrella
of this CoC.
We see two ways to go forward:
(1) Projects adopt the CoC text and the project maintainers do the
moderation work themselves.
(2) Projects adopt the CoC text and the committee would also act as
arbitrers for violation reports submitted to them.
Ideally we could do a combination of both. Smaller projects could
possibly adopt the latter and take help from the committee for
enforcement, while bigger projects with capacity to do the moderation
themselves can adopt the CoC text. The decision to accept projects
into the umbrella lies with the committee.
We’re keen to hear any thoughts or suggestions for improvement. If
you’re interested to adopt this CoC for your OCaml project, please
don’t hesitate to post here or contact me (write to me at sudharg247
[at] gmail [dot] com or DM here) or any of the committee members (DM
here).
Use OCaml to interact with Neovim
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/what-will-be-required-to-transpile-ocaml-to-lua/10493/10>
Deep in this thread, Dani Dickstein said
────────────────────────────────────────
For the Neovim-specific use case, you may want to take a look at
[vcaml], which lets you write OCaml programs that interact with Neovim
over msgpack RPC. Do note though that while the library as-is should
provide you with the functionality you need, it is under active
development so the API may change (improve) in significant ways
between releases.
[vcaml] <https://opam.ocaml.org/packages/vcaml/>
What will be required to transpile OCaml to Lua?
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/what-will-be-required-to-transpile-ocaml-to-lua/10493/14>
Deep in this thread, David Jeffrey said
───────────────────────────────────────
Doesn’t necessarily help much, but a while ago I wrote a
proof-of-concept ML-style language (using OCaml, of course) that
transpiled to Lua - <https://github.com/merle-lang/luml> (I was mostly
thinking about targeting game engines… I did enough to implement
Tetris and then gave up on it).
The module that emits Lua source code was pretty simple:
<https://github.com/merle-lang/luml/blob/master/lib/compile.ml> - I
did thinking about trying to target byte code but it seemed tricky due
to different Lua versions, I think.
OBazl Toolsuite - tools for building OCaml with Bazel
═════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/obazl-toolsuite-tools-for-building-ocaml-with-bazel/10021/10>
Continuing this thread, james woodyatt asked and Gregg Reynolds replied
───────────────────────────────────────────────────────────────────────
Any chance we might see a `conf-bazel' package added to
OPAM so a package can depend on a compatible version of
Bazel being installed on the host?
I’ve put a lot of work into seamless OPAM integration, but only in one
direction: make it easy to use OPAM resources in a Bazel build
program. I have not put much thought into integrating Bazel itself
into the OPAM ecosystem. For example publishing a Bazel-enabled
package to OPAM. It looks like writing such a conf-bazel package would
be pretty easy, but I’m not sure it would do us much good at the
moment. What specific use cases do you have in mind?
There are two ways to integrate Bazel and OPAM. One is to
automatically generate BUILD.bazel files for OPAM packages. Then Bazel
would build everything, eliminating the need for the OPAM engine. This
is the strategy followed by rust (tool: cargo_raze, evidently now
supplanted by crate_universe) and go (tool: gazelle). Unfortunately a
complete solution along these lines is not feasible for OCaml, since
source files do not carry enough information to support inference to a
build program, and OPAM packages may use a variety of build languages
(Dune, Makefiles, OMake, etc.). On the other hand, Dune seems to be
the most widely used build engine by a considerable margin, and the
Dune language is easy to parse (if not so easy to interpret), so I’m
working on a conversion tool that automatically converts Dune files to
BUILD.bazel files.
The other strategy is to rely on OPAM to build dependencies and then
“import” the built artifacts into Bazel. OBazl defines an
`opam_import' rule for this purpose, and a tool that bazelizes OPAM
switches, generating an OBazl ’coswitch’. The mapping from OPAM
package name to Bazel label is straightforward: ’yojson’ to
`@yojson//lib/yojson', ’lwt.unix’ to `@lwt//lib/unix', etc.
So in practice OBazl supports a hybrid approach. Use Bazel to build
your code, but import pre-built OPAM dependencies. To do that you run
the opam conversion tool to generate a ’coswitch’ which defines a
local Bazel repo for each OPAM package, and configure your
WORKSPACE.bazel to import those repos. Write your BUILD.bazel files
using opam labels as above. If your project already uses dune, you can
run the dune conversion tool to generate your BUILD.bazel files, which
in some cases will need some tweaking, since some Dune stanzas lack
sufficient information for conversion, and in others the conversion
code needs complicated logic that I haven’t gotten around to writing,
or that does not seem worth the bother.
The OPAM “import” conversion tool is fairly stable. It converts the
META files in OPAM into BUILD.bazel files, which include dependency
information. So when you depend on an `opam_import' target you get its
entire dependency graph.
The Dune migration tool is another matter. Reverse-engineering the
Dune language is a non-trivial task, lemme tell ya. The good news is
that after what seems like eons of work the end is in sight. I’ve been
running it against a semi-random set of projects (js_of_ocaml,
ocaml-protoc, some ppx libs, etc.) and working through the quirks
inch-by-inch. Rule stanzas are a real PITA, can I just say that? In
any case, it looks like I should have an alpha release with
documentation and some case studies within a week or so. I hope. At
the very least I’ll convert my dev configuration into something usable
by others so you can follow along if you want.
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: 34041 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-09-13 8:40 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-09-13 8:40 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 17186 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 06 to
13, 2022.
Table of Contents
─────────────────
Caqti 1.9.0 and Plans for 2.0.0
Outreachy summer ’22 closing commemoration session on 23rd Sept
MirageOS for B2B SaaS
Tuareg and Caml modes for Emacs: what are the differences?
Engineer position at Imandra (Austin TX/UK)
Acme plumbing rules for OCaml
Other OCaml News
Old CWN
Caqti 1.9.0 and Plans for 2.0.0
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-caqti-1-9-0-and-plans-for-2-0-0/10448/1>
Petter A. Urkedal announced
───────────────────────────
First I would like to announce the 1.9.0 minor release, see the
release notes below for details.
There is also ongoing work in the [caqti2 branch] targeted for the
next major release. If someone have an opinion on directions, we can
discuss it here, or in the issue tracker ([meta-issue]), see my brief
notes below.
I will attend parts of the ICFP 2022 virtually next week so there may
be time to discuss over audio.
[caqti2 branch] <https://github.com/paurkedal/ocaml-caqti/tree/caqti2>
[meta-issue] <https://github.com/paurkedal/ocaml-caqti/issues/90>
Release Notes for 1.9.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
New features:
• Allow unquoted semicolons in query strings in the new API. There are
corner cases where it is needed, as reported in issue #87, and a
parser which rejects semicolons are still available for loading
schema files statement by statement.
• Add support for MySQL and MariaDB configuration files, as a solution
to issue #86.
• Add a limit to the number of times a database connection is reused
when pooling connections (#94). Thanks to Peter Mondlock for
investigating resource usage server side motivating this addition.
• Provide access to the raw SQLite3 connection handle for the purpose
of defining custom functions (#56).
Fixes:
• Add missing dune dependency on unix (GPR#85 by David Allsopp).
• Documentation fixes (GPR#82, GPR#83, GPR#84 by Reynir Björnsson,
GPR#88 by Jonathan Duarte, and GPR#92 by Jim Tittsler).
Deprecations:
• `Caqti_type.field' was deprecated in favour of `Caqti_type.Field.t'.
Other:
• Replace deprecated core_kernel dependency with core.
Notes on 2.0.0 Development
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The main addition is pgx and mirage support. It is already functional,
but not very useful for production, since it lacks TLS. The trick here
is that PostgreSQL uses STARTTLS, so we can’t use conduit-lwt as-is.
Another thing in progress, but unpublished, is [per-connection
configuration]. Up till now, configuration has only been possible
through the connection URL or behind-the-scene via C libraries (now
also for MariaDB). However, this will no longer be practical for
delivering CA certificates to pgx. Two design issues which you may
have an opinion about:
• Driver specific options can be defined in the `caqti' package or in
`caqti-driver-*' packages. In the former case, the configuration can
be manipulated without depending on specific drivers, but the
downside is that we will pull in dependencies on `x509',
`domain-name', `ipaddr' and possibly `tls' and `sexplib0'.
• My current sketch provides sexp-serialisation, a choice mainly
motivated by the availability of such serialization for client
configuration of `tls', but I hope to find a more generic solution
which allows easy embedding of Caqti configuration in application
configuration independent of which format is used.
An example of how an sexp-formatted configuration might look like:
┌────
│ (connection
│ (pool
│ (max-use-count 20)
│ (max-idle-size 10))
│ (driver postgresql)
│ (endpoints
│ (inet pg1.example.org)
│ (inet pg2.example.org))
│ (target-session-attrs read-write))
└────
where the `(pool ...)' clause is driver-indepnedent and the `(driver
...)' clause determines which DB-specific options are valid. In the
current draft, order does not matter despite this dependency.
(I could also mention plans of wrapping modules, but this will be done
first as a forward-compatible module in parallel to the current
modules preferably at the beginning of a major release cycle. The
reason I haven’t written that main `Caqti' module yet, is that I would
like to take the opportunity to tidy up the namespace to make it
easier for newcomers to discover the main entry points.)
[per-connection configuration]
<https://github.com/paurkedal/ocaml-caqti/issues/89>
Outreachy summer ’22 closing commemoration session on 23rd Sept
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/outreachy-summer-22-closing-commemoration-session-on-23rd-sept/10450/1>
Moazzam Moriani announced
─────────────────────────
I, along with Jay, were the two [Outreachy] interns working with the
OCaml :camel: community this summer. I worked on [Multicore
Applications] and Jay on [TopoJSON]. Our internship, of course, was
only made possible because @sudha and @patricoferris generously chose
to volunteer to mentor us–as our respective mentors–throughout the
summer. We are grateful to the both of them :heart:.
Our three-month long Outreachy internship just ended relatively
recently and, personally, I have really enjoyed working on my project
and learning OCaml. So much so that Jay and I would like to share our
experiences with the rest of the community. :sparkles:
To carry forward a tradition established by the [previous Outreachy
cohort], we will host a virtual session that will consist of two short
presentations from the both of us followed by a Q&A. The session will
be on Friday 23rd September 2-3pm CET.
It is open to whoever wishes to join. A recording will be shared later
online as well.
We hope you will join us! :raised_hands:
[Outreachy] <https://www.outreachy.org/>
[Multicore Applications] <https://github.com/ocaml-bench/sandmark>
[TopoJSON] <https://github.com/geocaml/ocaml-topojson>
[previous Outreachy cohort]
<https://discuss.ocaml.org/t/friday-03-04-intern-presentations-open-attendance/9429>
Marcus Rohrmoser asked and Moazzam Moriani replied
──────────────────────────────────────────────────
I suppose you mean CEST i.e.
2022-09-23T14:00:00+02:00/PT1H
Yes I do. Thank you for pointing it out.
MirageOS for B2B SaaS
═════════════════════
Archive: <https://discuss.ocaml.org/t/mirageos-for-b2b-saas/10454/1>
Volodymyr Melnyk asked
──────────────────────
I have an idea to build a SaaS for corporate blogging (like Medium,
but for companies) and I want to try MirageOS as a total platform for
services. I have no production experience with OCaml (only Golang, JS,
Ruby) and have no experience with MirageOS and unikernels (only
Docker, Linux, and a little bit k8s), but I’m very interested in both.
Could you please help me to clarify possible issues with such an
approach?
Also I’m interested about a hosting for MirageOS services. I don’t
like containers and k8s stuff and I prefer dedicated and virtual
servers instead of cloud stuff because I have no resources to pay up
to 5x more for hosting.
Thank you for your help!
Calascibetta Romain replied
───────────────────────────
Thank you for your interest in MirageOS. MirageOS is first and
foremost a framework for creating an application (such as a blog) for
several targets. One of these targets is [Solo5] which allows to
create an entire system which includes everything necessary for OCaml
(its runtime). Thus, one can deploy a MirageOS application on:
• KVM (with the target `hvt')
• [Xen]
• or produce a simple executable taking advantage of [seccomp] (and
thus finely controlling access to the executable).
• we can also mention the experimental target for [Raspberry Pi 4]
The objective of MirageOS is to make the choice of targets transparent
to the application. This means that for a given application, deploying
for KVM or Xen should not be an upstream choice (which would govern
the development of the application) but the last of the choices which
can, of course, be left to third party users.
This reverses the development logic of an application thanks to
abstraction mechanisms (specific to OCaml) (the [functors]) that allow
to get rid of any specialisation to a given system (Solo5, Unix,
Raspberry Pi, etc.).
This is of course the theory and in practice, it works quite well :) .
To take the example of the blog, you can see [Hannes’ blog] or [mine]
which runs on MirageOS (KVM). The latter have a similar architecture:
a unikernel managing TLS certificates and redirecting HTTP connections
to unikernels on a local network ([tlstunnel] or [contruno]) and a
unikernel ([unipi]) that only transmits what appears in a Git
repository via the HTTP protocol (http/1.1 and h2).
Deployment depends of course on what you have. Regarding KVM, you can
follow the tutorials [here] (quite general) and [there]. You can
deploy your unikernels on Google Cloud with this (probably a bit old)
[tutorial]. Finally, a deployment with seccomp is possible, it is a
simple executable.
Of course, most of these unikernels are already available for download
[here] thanks to the excellent work of [robur.io]. It is ensured that
the generated image is reproducible regardless of the context.
There is of course a whole series of unikernels made by the community
that you can mainly find on GitHub. We can talk about several services
like [DNS] or [emails].
I would like to specify that all this is still experimental. We are
gradually reaching the stage where our unikernels are used in
production domains, but it still requires a lot of work and a lot of
skills for such a small team :) . Of course, we are open to everyone’s
participation and we are especially here to help newcomers.
[Solo5] <https://github.com/Solo5/solo5/>
[Xen] <https://xenproject.org/>
[seccomp]
<https://code.google.com/archive/p/seccompsandbox/wikis/overview.wiki>
[Raspberry Pi 4] <https://github.com/dinosaure/gilbraltar/>
[functors] <https://ocaml.org/docs/functors>
[Hannes’ blog] <https://hannes.nqsb.io/>
[mine] <https://blog.osau.re>
[tlstunnel] <https://github.com/roburio/tlstunnel>
[contruno] <https://github.com/dinosaure/contruno>
[unipi] <https://github.com/roburio/unipi>
[here] <https://robur.coop/Projects/Reproducible_builds>
[there] <https://blog.osau.re/articles/blog_requiem.html>
[tutorial]
<https://github.com/aantron/dream/tree/master/example/w-mirage>
[here] <https://builds.robur.coop/>
[robur.io] <https://robur.io/>
[DNS] <https://github.com/roburio/dns-primary-git>
[emails] <https://mirage.io/blog/2022-04-01-Mr-MIME>
Tuareg and Caml modes for Emacs: what are the differences?
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tuareg-and-caml-modes-for-emacs-what-are-the-differences/10285/12>
Deep in this thread, Tim McGilchrist announced
──────────────────────────────────────────────
I wrote up a longer form version of my setup at
<https://lambdafoo.com/posts/2022-09-07-ocaml-with-emacs-2022.html>
There are still some bits I am not happy with but I have been using it
daily. Also @bbatsov wrote his version at
<https://batsov.com/articles/2022/08/23/setting-up-emacs-for-ocaml-development/>
Engineer position at Imandra (Austin TX/UK)
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/engineer-position-at-imandra-austin-tx-uk/10465/1>
Simon Cruanes announced
───────────────────────
[Imandra] is looking for a full time engineer in the UK or in Austin,
Texas.
The job offers can be found [here].Imandra is an AI startup developing
a cloud-native automated reasoning engine for analysis of algorithms
and data. Whether you’re writing mission-critical code or need to
understand the countless complex decisions that a system may make, use
Imandra to ensure the algorithms you create are safe, explainable and
fair. OCaml is the main language used at Imandra.
[Imandra] <https://imandra.ai/>
[here] <https://apply.workable.com/imandra/>
Acme plumbing rules for OCaml
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/acme-plumbing-rules-for-ocaml/10467/1>
David A. Arroyo announced
─────────────────────────
I am sure that the intersection of OCaml users and [Acme] users is
small, but I have reason to believe it is a non-zero set :) . For
those of you using this spartan editor, here are some plumbing rules
that I use that allow me to right-click on error messages returned by
the OCaml compilers, and jump to the referenced location in acme:
┌────
│ # example: in file "foo/bar.ml", line 155, characters 30-62
│ type is text
│ data matches '.*[Ff]ile "([^"]+)", line ([0-9]+), characters ([0-9]+)-([0-9]+).*'$nl'?'
│ arg isfile $1
│ data set $file
│ attr add addr=$2-#0+#$3,$2-#0+#$4
│ plumb to edit
│ plumb client $editor
│
│ # example: File "tests/dune", line 2, characters 7-22:
│ type is text
│ data matches '.*[Ff]ile "([^"]+)", lines ([0-9]+)-([0-9]+).*'$nl'?'
│ arg isfile $1
│ data set $file
│ attr add addr=$2,$3
│ plumb to edit
│ plumb client $editor
└────
It could probably be extended to search `~/.opam' so you could plumb
errors in files outside of your project, but I do not use opam, so I
haven’t needed to do it.
Here is a short demo of its use: <https://youtu.be/Evl-N0oNNd0>
It’s not in OCaml, but I also wrote
<https://github.com/droyo/acme-autoformat> and put an `OcamlFmt'
script in acme’s $PATH like so:
┌────
│ #!/bin/sh
│ exec /usr/local/bin/acme-autoformat -r '\.mli?$' \
│ -- ocamlformat --name='{{.Basename}}' --enable-outside-detected-project -
└────
This calls `ocamlformat' whenever I Put an .ml[i] file. This is
probably obviated by combining acme-lsp and ocaml-lsp, but these two
bits work well enough that I haven’t felt a need to pursue it.
[Acme] <https://acme.cat-v.org/>
Other OCaml News
════════════════
>From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Tarides Sponsors Girls Can Code]
• [Introducing the Jane Street Graduate Research Fellowship]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Tarides Sponsors Girls Can Code]
<https://tarides.com/blog/2022-09-06-tarides-sponsors-girls-can-code>
[Introducing the Jane Street Graduate Research Fellowship]
<https://blog.janestreet.com/graduate-research-fellowship/>
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: 27859 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-08-23 8:06 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-08-23 8:06 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 16 to 23,
2022.
Table of Contents
─────────────────
Writing a transpiler from PHP to polyglot PHP+C code
How to speed up this function?
Old CWN
Writing a transpiler from PHP to polyglot PHP+C code
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/discussion-writing-a-transpiler-from-php-to-polyglot-php-c-code/10301/4>
Deep in this thread, Olle Härstedt announced
────────────────────────────────────────────
Made a small prototype here, very standard thing:
<https://github.com/olleharstedt/pholyglot/tree/main/src>
Parser and lexer in Menhir, AST that represents the subset PHP lang,
then I'd have to iterate over it to infer some types, transform to
polyglot AST and from there to string.
The one thing to make it more professional would be proper error
messages for the end user… But you have to carry file and line in the
AST, right? Maybe I can google around. :thinking:
How to speed up this function?
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-to-speed-up-this-function/10286/29>
Deep in a huge discussion, Yaron Minsky said
────────────────────────────────────────────
From our perspective at Jane Street, unboxed types is a /very/ high
priority. A large slice of the team is thinking about it, and Chris
Casinghino and Richard Eisenberg have joined recently and have it as
their primary focus, along with Antal.
In terms of when it makes it upstream, that's less clear. We're
working hard on getting out some initial versions done, and we plan on
iterating internally, where it's easier for us to try things out and
then change them as we go. Once we have a design that we really
believe in, we intend to propose it upstream, but how quickly that
goes (and whether it's successful at all!) depends on whether upstream
maintainers and the larger community find the improvements compelling.
In any case, I find this conversation encouraging, since it suggests
there's some real hunger for improvements in this space.
I expect ICFP in particular to be a good opportunity for people to
learn more about the work we're doing both here, and also on type-safe
stack allocation. (For what it's worth, the latter is already in
production internally and looks very promising.)
If you'll be at ICFP:
• Richard Eisenberg will be giving a [talk on unboxed types] at the ML
workshop
• Stephen Dolan will be giving a [talk on stack allocation] at the
OCaml Users and Developers Workshop.
[talk on unboxed types]
<https://icfp22.sigplan.org/details/mlfamilyworkshop-2022-papers/13/Unboxed-types-for-OCaml>
[talk on stack allocation]
<https://icfp22.sigplan.org/details/ocaml-2022-papers/9/Stack-allocation-for-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: 13016 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-08-16 8:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-08-16 8:51 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 21491 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 09 to 16,
2022.
Table of Contents
─────────────────
Emacs on windows, merlin mode, merlin server remote on linux, tramp, ssh
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
opam 2.1.3
Application-specific Improvements to the Ecosystem
Use GitHub CI to build simple binary distribution?
setup-dkml.yml GitHub Actions workflow for distributing binaries
Diskuv OCaml 1.x.x; Windows OCaml installer no longer in preview
Old CWN
Emacs on windows, merlin mode, merlin server remote on linux, tramp, ssh
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/emacs-on-windows-merlin-mode-merlin-server-remote-on-linux-tramp-ssh/10243/3>
Artem Pianykh said
──────────────────
I managed to set up Emacs + TRAMP + LSP to do remote development (not
on the first attempt though, as these things were quite fiddly to set
up).
Here's what I got:
1. You need `opam install ocaml-lsp-server' on the remote machine.
2. Tell TRAMP to use path from the remote shell: `(add-to-list
'tramp-remote-path 'tramp-own-remote-path)'
3. Use [Eglot] as an LSP client. Although, `lsp-mode' claims that they
support remote servers, I couldn't quite make it work with
`lsp-mode'. This is what I have in my `init.el':
┌────
│ (require 'eglot)
│ (add-hook 'tuareg-mode-hook #'eglot-ensure)
└────
[Eglot] <https://github.com/joaotavora/eglot>
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/27>
Thierry Martinez announced
──────────────────────────
`clangml.4.7.0' is now in opam, with the bug fixes/features requested
by @n47 and some others. All LLVM/Clang versions up to 14.0.x are
supported, as well as OCaml 5.0. The official repo is now on github:
<https://github.com/thierry-martinez/clangml> which should ease
posting issues and pull requests (and should be more convenient than
discussions on this thread!).
Support for the upcoming Clang 15 is planned for the next release that
should happen soon (the development version already supports Clang
15).
opam 2.1.3
══════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-3/10299/1>
R. Boujbel announced
────────────────────
We are pleased to announce minor release of opam [2.1.3].
This opam release consists of [backported] fixes. You’ll find more
information in the [blog post].
To upgrade simply run:
┌────
│ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh) --version 2.1.3"
└────
[2.1.3] <https://github.com/ocaml/opam/releases/tag/2.1.3>
[backported] <https://github.com/ocaml/opam/issues/5000>
[blog post] <https://opam.ocaml.org/blog/opam-2-1-3>
Application-specific Improvements to the Ecosystem
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/application-specific-improvements-to-the-ecosystem/10223/54>
Deep in this thread, Jp R said
──────────────────────────────
Regarding Perl vs OCaml: An (impressive) implementation of all the
solutions of the Perl Cookbook in the Objective CAML language (used at
the time) is available here:
<http://pleac.sourceforge.net/pleac_ocaml/index.html>
Re-writing these examples with "modern" code/libraries could be very
interesting.
Use GitHub CI to build simple binary distribution?
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/use-github-ci-to-build-simple-binary-distribution/10303/1>
Christian Lindig asked
──────────────────────
Is there a recommended way (or example) to build a simple binary
distribution of an OCaml project using the GitHub CI? I am mostly
interested in building the executables and packaging them in some
archive format and make that available for download for different
architectures.
Guillaume Bury replied
──────────────────────
I have such a workflow for one of my project, see [this workflow
file]. It automatically triggers on new releases, builds the project
with the appropriate compiler (e.g. `flambda'), and uploads the built
artefact to the release page where it can be downloaded. It currently
works for both linux and mac (last time I tried it with windows I got
some errors and I haven't yet had the time to look into that, so i
don't know if the errors were caused by the workflow, or my project).
[this workflow file]
<https://github.com/Gbury/dolmen/blob/master/.github/workflows/release.yml>
jbeckford also replied
──────────────────────
That was a weird coincidence that I released a GitHub workflow
<https://discuss.ocaml.org/t/ann-setup-dkml-yml-github-actions-workflow-for-distributing-binaries/10308>
for this today. @zozozo's solution is simpler if it works for your
intended target audience.
Calascibetta Romain replied
───────────────────────────
I did the same for my little project [bob] but it provides a
[Cosmopolitan] binary which should run anywhere, see the [workflow]
and the [last uploaded artifact] :slight_smile:.
[bob] <https://github.com/dinosaure/bob>
[Cosmopolitan] <https://github.com/jart/cosmopolitan>
[workflow]
<https://github.com/dinosaure/bob/blob/main/.github/workflows/esperanto.yml>
[last uploaded artifact]
<https://github.com/dinosaure/bob/actions/runs/2749978142>
setup-dkml.yml GitHub Actions workflow for distributing binaries
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-setup-dkml-yml-github-actions-workflow-for-distributing-binaries/10308/1>
jbeckford announced
───────────────────
I am pleased to announce the `v0` release of `setup-dkml.yml`, a
GitHub Actions workflow for distributing executables or libraries to
the public:
• <https://github.com/diskuv/dkml-workflows#readme>
It is similar to the [GitHub Action setup-ocaml] but has several
advantages when you are releasing a finished product to the public:
• On Linux it uses an ancient GLIBC (C library) so your binaries run
on most Linux distributions without static linking. Statically
linked binaries are simple to distribute, but can be problematic for
some copy-left licenses, and makes it difficult for your end-users
to do security patching of the libraries you linked with.
• On Windows it uses the Visual Studio compiler rather than the
non-standard (for Windows) GCC compiler. This is a necessity when
distributing Windows libraries, and reduces runtime bugs when
linking native Windows libraries into your OCaml-built Windows
executables. In addition you can generate Windows 32-bit binaries.
• On macOS it can build both ARM64 and x86_64 binaries if you use
[opam-monorepo] to build your project. /Alpha-release caution: This
works today but only if you hand-edit the .locked file. So only
advanced users today!/
Even if you are not releasing to the public, if you are a package
maintainer you may want to use /both/ `setup-ocaml' and `setup-dkml'
so that you get additional coverage for Visual Studio and [MSYS2] on
Windows, and coverage for an older GLIBC on Linux.
The full comparison matrix available at
[https://github.com/diskuv/dkml-workflows#readme] is:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
`setup-dkml' `setup-ocaml' Consequence
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
`dkml-base-compiler' `ocaml-base-compiler' `setup-dkml' *only supports 4.12.1 today*. `setup-ocaml' supports all versions and variants of OCaml
GitHub child workflow GitHub Action `setup-dkml' is more complex to configure, and takes *longer to run*
MSVC + MSYS2 GCC + Cygwin On Windows `setup-dkml' can let your native code use ordinary Windows libraries without ABI conflicts. You can also distribute your executables without the license headache of redistributing or statically linking `libgcc_s_seh' and `libstdc++'
`dkml-base-compiler' `ocaml-base-compiler' On macOS, `setup-dkml' cross-compiles to ARM64 with `dune -x darwin_arm64'
CentOS 7 and Linux distros from 2014 Latest Ubuntu On Linux, `setup-dkml' builds with an old GLIBC. `setup-dkml' dynamically linked Linux executables will be highly portable as GLIBC compatibility issues should be rare, and compatible with the unmodified LGPL license used by common OCaml dependencies like [GNU MP]
0 yrs 4 yrs `setup-ocaml' is officially supported and well-tested.
Some pinned packages No packages pinned `setup-dkml', for some packages, must pin the version so that cross-platform patches (especially for Windows) are available. With `setup-ocaml' you are free to use any version of any package
`diskuv/diskuv-opam-repository' `fdopen/opam-repository' Custom patches for Windows are sometimes needed. `setup-dkml' uses a much smaller set of patches. `setup-ocaml' uses a large but deprecated set of patches.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Put simply, use `setup-dkml' when you are distributing
executables or libraries to the public. Use `setup-ocaml'
for all other needs.
`setup-dkml' will setup the following OCaml build environments for
you:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ABIs Native `ocamlopt' compiler supports building executables for the following operating systems:
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
win32-windows_x86 32-bit Windows [1] for Intel/AMD CPUs
win32-windows_x86_64 64-bit Windows [1] for Intel/AMD CPUs
macos-darwin_all 64-bit macOS for Intel and Apple Silicon CPUs. Using `dune -x darwin_arm64' will cross-compile to both; otherwise defaults to Intel.
manylinux2014-linux_x86 32-bit Linux: CentOS 7, CentOS 8, Fedora 32+, Mageia 8+, openSUSE 15.3+, Photon OS 4.0+ (3.0+ with updates), Ubuntu 20.04+
manylinux2014-linux_x86_64 64-bit Linux: CentOS 7, CentOS 8, Fedora 32+, Mageia 8+, openSUSE 15.3+, Photon OS 4.0+ (3.0+ with updates), Ubuntu 20.04+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Thanks to the [OCaml Software Foundation (OCSF)] for their support of
DKML. Enjoy!
[GitHub Action setup-ocaml]
<https://github.com/marketplace/actions/set-up-ocaml>
[opam-monorepo] <https://github.com/ocamllabs/opam-monorepo#readme>
[MSYS2] <https://www.msys2.org/>
[https://github.com/diskuv/dkml-workflows#readme]
<https://github.com/diskuv/dkml-workflows#readme>
[GNU MP] <https://gmplib.org/manual/Copying>
[OCaml Software Foundation (OCSF)] <https://ocaml-sf.org/>
Diskuv OCaml 1.x.x; Windows OCaml installer no longer in preview
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-diskuv-ocaml-1-x-x-windows-ocaml-installer-no-longer-in-preview/10309/1>
jbeckford announced
───────────────────
Diskuv OCaml (DKML) has graduated to version 1.0.0. That means you'll
see DKML listed as a Windows option for OCaml on the various OCaml
websites soon.
To recap … by following the simple [download and install instructions
for Windows] you will get:
• OCaml 4.12.1
• `dune' and `opam' working transparently as if you were on Unix
• a `playground' Opam switch so you can start coding without having to
learn many Opam commands
• your Opam switches supported by the Visual Studio OCaml plugin
• all the prerequisites you need for OCaml programming:
• a C compiler and assembler (Visual Studio Build Tools)
• a UNIX environment (MSYS2; mostly you won't see it)
• source control (Git for Windows)
• support! File an issue at
[https://github.com/diskuv/dkml-installer-ocaml/issues]. I don't
promise your Windows issue will be fixed, but it will be reviewed.
Changes since 0.4.0:
• An uninstaller. Now you can Add and Remove "Diskuv OCaml" from the
Control Panel
• The old GitLab repository at
[https://gitlab.com/diskuv/diskuv-ocaml] is being retired. There
will be a new GitLab repository with much more testing capacity that
will be online in the next few months.
Full documentation is at
[https://diskuv.gitlab.io/diskuv-ocaml/#introduction].
/Package maintainers/: Have a look at the [just announced
`setup-dkml'] to test your own GitHub packages using most of the
Windows functionality listed above.
Thanks (again!) to the [OCaml Software Foundation (OCSF)] for their
support of DKML. Please consider becoming a contributor to DKML to
improve the Windows ecosystem. Enjoy!
[download and install instructions for Windows]
<https://github.com/diskuv/dkml-installer-ocaml#installing>
[https://github.com/diskuv/dkml-installer-ocaml/issues]
<https://github.com/diskuv/dkml-installer-ocaml/issues>
[https://gitlab.com/diskuv/diskuv-ocaml]
<https://gitlab.com/diskuv/diskuv-ocaml>
[https://diskuv.gitlab.io/diskuv-ocaml/#introduction]
<https://diskuv.gitlab.io/diskuv-ocaml/#introduction>
[just announced `setup-dkml']
<https://discuss.ocaml.org/t/ann-setup-dkml-yml-github-actions-workflow-for-distributing-binaries/10308>
[OCaml Software Foundation (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: 27802 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-08-09 8:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-08-09 8:02 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 14524 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 02 to 09,
2022.
Table of Contents
─────────────────
pyml_bindgen: a CLI app to generate Python bindings directly from OCaml value specifications
Interesting OCaml Articles
Logs to a file (a primitive way)
Timedesc 0.8.0 - modern date time handling
OCaml website: Owl book not listed
Application-specific Improvements to the Ecosystem
Other OCaml News
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/8>
Ryan Moore announced
────────────────────
New release
╌╌╌╌╌╌╌╌╌╌╌
Version 0.4.1 is now available from [GitHub] and [Opam]. The [change
log] has more details.
[GitHub]
<https://github.com/mooreryan/ocaml_python_bindgen/releases/tag/0.4.1>
[Opam] <https://opam.ocaml.org/packages/pyml_bindgen/>
[change log]
<https://github.com/mooreryan/ocaml_python_bindgen/blob/main/CHANGELOG.md>
New stuff
╌╌╌╌╌╌╌╌╌
New attributes
┄┄┄┄┄┄┄┄┄┄┄┄┄┄
There is a new attribute you can use: `py_arg_name'. It allows you to
use different argument names on the OCaml side from those that are
used on the Python side.
One use case is for Python functions that have an argument name that
is the same as some reserved OCaml keyword. In this case, you can use
`py_arg_name' to map it to something else on the OCaml side.
┌────
│ val f : t -> method_:string -> unit -> string
│ [@@py_arg_name method_ method]
└────
The attribute is followed by two items, the first is the argument name
on the OCaml side, and the second is the argument name on the Python
side.
See the [attributes example] on GitHub for more info.
[attributes example]
<https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples/attributes>
Helper scripts
┄┄┄┄┄┄┄┄┄┄┄┄┄┄
I added a couple of scripts to help in cases where you need to run
`pyml_bindgen' on a lot of different input files in one go. I have
been using them when writing bindings for bigger Python libraries, and
in cases where there are a lot of cyclic python classes to bind.
[This] example has more info about using the helper scripts.
[This]
<https://github.com/mooreryan/ocaml_python_bindgen/tree/main/examples/recursive_modules>
Other stuff
┄┄┄┄┄┄┄┄┄┄┄
• Added an option to split generated modules into `ml' and `mli'
files.
• Added a dev package for (hopefully) easier installation of
development dependencies.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/99>
Calascibetta Romain announced
─────────────────────────────
Hi, I would like to share my recent article about GADTs and state
machines: [GADTs and state machine]
It's another introduction about GADTs and it explains a bit what I did
for [robur.io]. Eenjoy it and happy hacking!
[GADTs and state machine]
<https://blog.osau.re/articles/gadt_and_state_machine.html>
[robur.io] <https://robur.io>
Logs to a file (a primitive way)
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/logs-to-a-file-a-primitive-way/10262/1>
🌍 Marcus Rohrmoser asked
─────────────────────────
I found
<https://github.com/oxidizing/sihl/blob/c6786f25424c1b9f40ce656e908bd31515f1cd09/sihl/src/core_log.ml#L18>
and wonder what a primitive way to log to a file would be.
I need to keep `stdout' clean and not show any log message under all
circumstances.
🌍 Marcus Rohrmoser later added
───────────────────────────────
I do a cgi and `stdout' is the response – logging has to go to a
separate file. Not even `stderr' as I want debug logs not to taint the
webserver error log in case. And I would like to funnel logging
through `Logs'.
Yawar Amin suggested and 🌍 Marcus Rohrmoser replied
────────────────────────────────────────────────────
I don't know about `logs' but it should be relatively easy
to keep an open file handle and print log messages there.
<https://opam.ocaml.org/packages/logs/> - I like the loglevel
approach. But maybe I will do without and pass around the channel,
yes.
Jean Michel suggested
─────────────────────
I believe logs support logging to a file via Format. See
<https://erratique.ch/software/logs/doc/Logs/index.html#val-format_reporter>
Shon also suggested
───────────────────
I’ve found logs very ergonomic and easy to work with. I tend to pull
it in via [Bos], which has a very nice interface to OS
interactions. Opening the `Bos_setup' module also does default logs
configuration, and I find all quite painless and pleasant.
[Bos] <https://erratique.ch/software/bos>
🌍 Marcus Rohrmoser said
────────────────────────
thanks @yawaramin @beajeanm @shonfeder, I took a [middle ground] and
went along the lines of <https://opam.ocaml.org/packages/logs/> (using
the loglevels and logging call style) but base writing almost directly
on [out_channel]. (I need a log rotation on top)
I was struggling with lost messages however – the logfile remained
empty until I flushed after each log message.
Is that known behaviour that writing to a channel (with
[Printf.fprintf]) doesn't necessarily end up in the file? Even when
closed quickly.
[middle ground]
<https://codeberg.org/mro/seppo/src/branch/develop/lib/logr.ml>
[out_channel] <https://ocaml.org/api/Stdlib.html#TYPEout_channel>
[Printf.fprintf] <https://ocaml.org/api/Printf.html>
UnixJunkie replied
──────────────────
You must Printf.printf with "%!" at the end of your format string, to
be sure that the log is flushed to file.
That's what I do in dolog: <https://github.com/UnixJunkie/dolog>
Timedesc 0.8.0 - modern date time handling
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-timedesc-0-8-0-modern-date-time-handling/10138/2>
Darren announced
────────────────
Tiny update: Timedesc 0.9.0 has been released, moving `sexplib'
dependency into `timedesc-sexp' and moved from `mparser' to `angstrom'
for some date time text parsers since angstrom is a strict necessity
for some binary (de)serialization already.
This overall means Timedesc is about as slim as it can get as a date
time handling lib, depending only on: `seq', `angstrom', `result', and
`ptime' (`ptime' is not a strict dependency, but it's nice to have
timedesc <-> ptime convertors).
Florent Monnier asked
─────────────────────
Is this a lib that targets to process dates and time in a
programmatically way? (this is what the provided example make me
think) Or is it also supposed to be used to print something readable
for a user else than a programmer?
If there is no end-user goal in this lib, please just ignore my
message, and sorry to make you lose some time.
In the other case if you consider printing for end users, it's maybe
worth to mention that there is the [DateLocale-ocaml] module that is
available and which provides the name for the months, and days for
more than 200 languages. It also provides abbreviated versions for
both months and days, which are often used.
The [ocaml-community/calendar] was not designed with localisation in
mind, it just does `String.sub d 0 3' to provide short names, which
will not work with languages that need UTF8.
There is this PR that is still waiting for some review since 2 years
to make it compatible with localisation:
[ocaml-community/calendar/pull/33].
(At least the patch is available there for someone who could be
interested.)
I don't know if it could interest some one but I see that the example
outputs a list of dates, that look like some kind of logs. In case
some one would like to visualise it in a way similar than the unix
command `cal' you can just create empty files where the file name
follows the pattern YYYY-MM-DD like for example "dir/2022-08-06.txt",
you will then be able to visualise it in the console with [detri].
[DateLocale-ocaml] <https://github.com/fccm/DateLocale-ocaml>
[ocaml-community/calendar] <https://github.com/ocaml-community/calendar>
[ocaml-community/calendar/pull/33]
<https://github.com/ocaml-community/calendar/pull/33/commits/9fcd7386e287f8841e503fb1d1e0547295aeb0c9>
[detri] <https://github.com/fccm/detri>
Darren replied
──────────────
Is this a lib that targets to process dates and time in a
programmatically way? (this is what the provided example
make me think) Or is it also supposed to be used to print
something readable for a user else than a programmer?
Development has been primarily focused on former, mostly because
solving it properly was already (very) involved.
Now that Timedesc has stabilised, the latter reads like a very nice
next TODO to match feature parity of other date time libs.
In the other case if you consider printing for end users,
it’s maybe worth to mention that there is the
[DateLocale-ocaml] module that is available and which
provides the name for the months, and days for more than
200 languages. It also provides abbreviated versions for
both months and days, which are often used.
Looks neat! I believe there have been requests of locale sensitive
pretty printing/conversion functions, so I definitely would be
interested in incorporating your work (if that was the intention).
I don’t know if it could interest some one but I see that
the example outputs a list of dates, that look like some
kind of logs. In case some one would like to visualise it
in a way similar than the unix command `cal` you can just
create empty files where the file name follows the pattern
YYYY-MM-DD like for example “dir/2022-08-06.txt”, you will
then be able to visualise it in the console with [detri].
I was interested in something like this for another small utility cmd
I've written, neat!
[DateLocale-ocaml] <https://github.com/fccm/DateLocale-ocaml>
[detri] <https://github.com/fccm/detri>
OCaml website: Owl book not listed
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-website-owl-book-not-listed/10274/1>
Andreas Poisel said
───────────────────
It would be nice to add [OCaml Scientific Computing] to the list on
<https://ocaml.org/books>.
This is a great book and it would be a shame not to promote it. Maybe
anyone responsible for the website reads this or can point me in the
right direction.
I'm not in any way affiliated with the authors of this book.
[OCaml Scientific Computing]
<https://link.springer.com/book/10.1007/978-3-030-97645-3>
Application-specific Improvements to the Ecosystem
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/application-specific-improvements-to-the-ecosystem/10223/49>
Deep in this thread, Kay-Uwe Kirstein said
──────────────────────────────────────────
Personally, I often use the monadic Result type together with a
polymorphic variant for the actual errors. This makes dealing with
errors from different "levels" of my software (library, command-line
tool, and GUI) quite comfortable (and type-safe!). @keleshev has
written a nice blog post on this:
<https://keleshev.com/composable-error-handling-in-ocaml> with a
recent follow up:
<https://keleshev.com/advanced-error-handling-in-ocaml>
Other OCaml News
════════════════
From the ocaml.org blog
───────────────────────
Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].
• [Irmin in the Browser]
[the ocaml.org blog] <https://ocaml.org/blog/>
[Irmin in the Browser]
<https://tarides.com/blog/2022-08-02-irmin-in-the-browser>
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: 26625 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-08-02 9:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-08-02 9:51 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 8994 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 26 to August
02, 2022.
Table of Contents
─────────────────
OCaml Software Foundation: summer 2022 update
Old CWN
OCaml Software Foundation: summer 2022 update
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-software-foundation-summer-2022-update/10234/1>
gasche announced
────────────────
A quick update on recent works of the [OCaml Software Foundation]. It
is a non-profit foundation ([earlier thread]) that receives funding
from [our industrial sponsors] each year, and tries its best to spend
it to support and strengthen the OCaml ecosystem and community.
The funding volume we receive each year is around 200K€. (For
comparison: this is the yearly cost of one experienced full-time
software engineer in many parts of the world.) We do not fund people
full-time for long periods. Most actions receive from 3K€ to 20K€.
The work to prepare and execute actions is mostly done by the (unpaid)
[Executivee Committee]. It is currently formed by Nicolás Ojeda Bär
('nojb'), Damien Doligez, Xavier Leroy, Kim Nguyễn and myself, with
administrative personel provided by [INRIA].
Our current sponsors (thanks!) are [ahrefs], [Jane Street], [Tezos],
[Bloomberg], [Lexifi], [SimCorp], [MERCE] and [Tarides]. (If your
company would like to join as a sponsor, please [get in touch].
Unfortunately, we still cannot efficiently process small donations, so
we are not calling for individual donations.)
Feel free to use this thread for discussions, questions, suggestions
and criticism, or to send a message/email for feedback.
[OCaml Software Foundation] <http://ocaml-sf.org/>
[earlier thread]
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476>
[our industrial sponsors] <http://ocaml-sf.org/#sponsors>
[Executivee Committee] <http://ocaml-sf.org/about-us/>
[INRIA]
<https://en.wikipedia.org/wiki/French_Institute_for_Research_in_Computer_Science_and_Automation>
[ahrefs] <https://ahrefs.com/>
[Jane Street] <https://janestreet.com/>
[Tezos] <https://tezos.com/>
[Bloomberg] <https://bloomberg.com/>
[Lexifi] <https://lexifi.com/>
[SimCorp] <https://simcorp.com/>
[MERCE] <https://www.mitsubishielectric-rce.eu/>
[Tarides] <https://tarides.com/>
[get in touch] <http://ocaml-sf.org/becoming-a-sponsor/>
Recent actions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Below are some of the actions that we funded in the last year or so,
and which have been actively worked on already by the people receiving
the funding.
Tooling
┄┄┄┄┄┄┄
We worked on improving the debugging experience for OCaml by funding
Fabian ('copy') to work on OCaml symbol demangling in Linux `perf'
([thread]), and supporting Yuxiang Wen ('hackwaly')'s work on
[ocamlearlybird] ([thread]), an OCaml bytecode debugger for vscode.
We also funded the early development work of [mutaml], a
mutation-testing prototype by Jan Midtgaard.
[thread]
<https://discuss.ocaml.org/t/ann-perf-demangling-of-ocaml-symbols-a-short-introduction-to-perf/7143/>
[ocamlearlybird] <https://github.com/hackwaly/ocamlearlybird>
[thread]
<https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180>
[mutaml] <https://github.com/jmid/mutaml>
Communication
┄┄┄┄┄┄┄┄┄┄┄┄┄
We decided to fund the time that Alan Schmitt ('brab') spends on the
[Caml Weekly News] – Alan also started cross-posting them on [reddit]
on this occasion.
We funded John Whitington to work on OCaml documentation, on the core
manual (see in particular [this PR]) or newcomer-oriented content on
ocaml.org ([Get Up and Running with OCaml] and [A First Hour With
OCaml]). We also purchased rights to John Whitington's book [OCaml
from the Very Beginning] to put it [online] ([thread]). This is a good
introduction to OCaml for people with little to no programming
experience, and we hope that it will be easier to onboard people if
they can get a free version online – of course they are encouraged to
buy a paper copy if they like it and can afford it.
We supported editing work for an upcoming book from the [Owl] team,
"Architecture of Numerical Systems", with the requirement that the
book be Open Access. (The idea followed our attempt to fund a hacking
retreat for the Owl project in 2019, that was cancelled due to COVID.)
We are also funding some work to refresh an older book about Caml in
French, [Le Langage Caml], also available online, which several people
in the community cite as their favorite OCaml book. Currently we are
funding Armaël Guéneau to refresh the book's (crufty build system and)
content to work with current OCaml versions – the book was written in
1993 for Caml Light – and we are considering funding an English
translation.
[Caml Weekly News] <https://alan.petitepomme.net/cwn/>
[reddit] <https://www.reddit.com/r/ocaml/>
[this PR] <https://github.com/ocaml/ocaml/pull/10247>
[Get Up and Running with OCaml] <https://ocaml.org/docs/up-and-running>
[A First Hour With OCaml] <https://ocaml.org/docs/first-hour>
[OCaml from the Very Beginning] <http://ocaml-book.com/>
[online]
<https://johnwhitington.net/ocamlfromtheverybeginning/index.html>
[thread]
<https://discuss.ocaml.org/t/ocaml-from-the-very-beginning-now-free-in-pdf-and-html-formats/9361>
[Owl] <https://ocaml.xyz/>
[Le Langage Caml] <https://caml.inria.fr/pub/distrib/books/llc.pdf>
Teaching
┄┄┄┄┄┄┄┄
We funded Louis Gesbert ('AltGr') to do some technical development
work on the LearnOCaml codebase. LearnOCaml is a technical platform to
deploy automatically-graded OCaml exercices, used in various
universities with probably around a few thousands students each year.
We are also funding a Summer School about OCaml at the university of
Zaragoza in Spain in early September 2022 ([thread], [website]).
Note: if you are organizing an OCaml event (workshop, meetup, etc.),
please get in touch to see whether/how we could support you.
[thread]
<https://discuss.ocaml.org/t/ocaml-summer-school-in-spain-call-for-industry-speakers/9685>
[website] <https://webdiis.unizar.es/evpf/>
Ecosystem
┄┄┄┄┄┄┄┄┄
We are funding part of the time Kate ('kit-ty-kate') spends on
release-readiness for the OCaml compiler distribution – monitoring
build results for the whole OPAM repository and working with compiler
maintainers and downstream package authors to solve compatibility
issues before the release. This is great work which we think had a
strong impact. There is now a larger concerted effort (not funded by
us) to coordinate core tools around compiler releases – see [this
opam-repository PR] for example, which puts the ecosystem in a fairly
good place compared to how new compiler versions felt a few years ago.
We are also supporting Marcello Seri ('mseri') for his contributions
to opam-repository maintenance.
We are supporting Jonah Beckford ('jbeckford')'s work on his [Diskuv
OCaml] distribution for Windows.
[this opam-repository PR]
<https://github.com/ocaml/opam-repository/issues/17530>
[Diskuv OCaml] <https://diskuv.gitlab.io/diskuv-ocaml/>
Libraries
┄┄┄┄┄┄┄┄┄
We are funding Petter Urkedal ('paurkedal') to work on [Caqti], an
OCaml library to work with SQL databases.
We are supporting Zach Shipko's maintenance work on the [ocaml-rs]
library, a library to write bindings / FFI code between OCaml and
Rust.
Finally, we supported some development work by Anton Bachin and Andrey
Popp around the Dream web framework. They concentrated their efforts
on [hyper] and [dream-social-login].
[Caqti] <https://github.com/paurkedal/ocaml-caqti/>
[ocaml-rs] <https://github.com/zshipko/ocaml-rs>
[hyper] <https://github.com/aantron/hyper>
[dream-social-login] <https://github.com/camlworks/dream-social-login>
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: 18424 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-07-26 17:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-07-26 17:54 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-07-19 8:58 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-07-19 8:58 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-07-12 7:59 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-07-12 7:59 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-07-05 7:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-07-05 7:42 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-06-28 7:37 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-06-28 7:37 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-06-21 8:06 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-06-21 8:06 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-06-14 9:29 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-06-14 9:29 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-06-07 10:15 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-06-07 10:15 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-05-31 12:29 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-05-31 12:29 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-05-24 8:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-05-24 8:04 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-05-17 7:12 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-05-17 7:12 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-05-10 12:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-05-10 12:30 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-05-03 9:11 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-05-03 9:11 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-04-26 6:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-04-26 6:44 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-04-19 5:34 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-04-19 5:34 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-04-12 8:10 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-04-12 8:10 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-04-05 11:50 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-04-05 11:50 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-03-29 7:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-03-29 7:42 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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.
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-03-22 13:01 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-03-22 13:01 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-03-15 9:59 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-03-15 9:59 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-03-01 13:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-03-01 13:54 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-02-22 12:43 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-02-22 12:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-02-08 13:16 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-02-08 13:16 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-02-01 13:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-02-01 13:00 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-01-25 12:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-01-25 12:44 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-01-11 8:20 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-01-11 8:20 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2022-01-04 7:56 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2022-01-04 7:56 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-12-28 8:59 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-12-28 8:59 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-12-21 9:11 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-12-21 9:11 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-12-14 11:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-12-14 11:02 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-11-30 10:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-11-30 10:51 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-11-16 8:41 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-11-16 8:41 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-11-09 10:08 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-11-09 10:08 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-11-02 8:50 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-11-02 8:50 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-10-19 8:23 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-10-19 8:23 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-28 6:37 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-09-28 6:37 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-21 9:09 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-09-21 9:09 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-07 13:23 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-09-07 13:23 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-24 13:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-08-24 13:44 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-17 6:24 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-08-17 6:24 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-10 16:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-08-10 16:47 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-27 8:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-07-27 8:54 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-20 12:58 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-07-20 12:58 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-06 12:33 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-07-06 12:33 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-29 12:24 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-06-29 12:24 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-22 9:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-06-22 9:04 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-01 9:23 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-06-01 9:23 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-25 7:30 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-05-25 7:30 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-11 14:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-05-11 14:47 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-04 8:57 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-05-04 8:57 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-27 14:26 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-04-27 14:26 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-20 9:07 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-04-20 9:07 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-06 9:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-04-06 9:42 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-30 14:55 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-03-30 14:55 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-23 9:05 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-03-23 9:05 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-16 10:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-03-16 10:31 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-09 10:58 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-03-09 10:58 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-23 9:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-02-23 9:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-16 13:53 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-02-16 13:53 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-02 13:56 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-02-02 13:56 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-26 13:25 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-01-26 13:25 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-19 14:28 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-01-19 14:28 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-12 9:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-01-12 9:47 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-05 11:22 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2021-01-05 11:22 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-29 9:59 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-12-29 9:59 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-22 8:48 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-12-22 8:48 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-15 9:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-12-15 9:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-01 8:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-12-01 8:54 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-11-03 15:15 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-11-03 15:15 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- 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 --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-27 8:43 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-10-27 8:43 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 18183 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 20 to 27,
2020.
Table of Contents
─────────────────
Bisect_ppx, the coverage tool, now has excellent integration with Dune
Js_of_ocaml in the VSCode OCaml Platform
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
Set up OCaml 1.1.2
Set up OCaml 1.1.3
First release of FSML
Qrc 0.1.0, a QR code encoder
cumulus 0.0.1
Brr 0.0.1, a toolkit for programming browsers
Old CWN
Bisect_ppx, the coverage tool, now has excellent integration with Dune
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bisect-ppx-the-coverage-tool-now-has-excellent-integration-with-dune/6634/1>
Anton Bachin announced
──────────────────────
[*Bisect_ppx*], the coverage tool, has just had its [2.5.0] release,
in which the main addition is a very neat integration with Dune:
┌────
│ dune runtest --instrument-with bisect_ppx --force
└────
This uses the new [instrumentation support] added in Dune 2.7.0, and
is a considerable improvement over the dubious methods Bisect and its
users were previously forced to rely on :)
It is no longer necessary to edit `dune' files for a release, as
Bisect only becomes a dependency of your project when
`--instrument-with bisect_ppx' is supplied on the Dune command line,
which is only during development and in CI. This makes projects ready
for release from any commit. Dune also now knows to rebuild affected
files when instrumentation is turned on or off, so you don't have to
manually run `dune clean' in between. Everything just works the way it
should.
See the updated [instructions] for all the details on how to use this
integration.
I've also adapted [Lambda Soup] as a simple full-project example. See
its [`opam'], [`dune-project'], [`dune'], and [`Makefile'].
Bisect_ppx still supports all the older integrations, so if you have
an existing setup, you don't have to edit it. Support may eventually
be removed in the future, however, so I encourage users to gradually
update.
See the full [changelog] for information on bugs fixed by the release.
Thanks to the Dune team for adding `--instrument-with', to @undu for
supporting it on the Bisect side, and to all the Bisect_ppx users and
contributors!
Happy testing!
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>
<https://github.com/aantron/bisect_ppx>
[*Bisect_ppx*] <https://github.com/aantron/bisect_ppx>
[2.5.0] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
[instrumentation support]
<https://dune.readthedocs.io/en/stable/instrumentation.html?highlight=instrument-with>
[instructions] <https://github.com/aantron/bisect_ppx#Dune>
[Lambda Soup] <https://github.com/aantron/lambdasoup>
[`opam']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/lambdasoup.opam#L17-L22>
[`dune-project']
<https://github.com/aantron/lambdasoup/blob/master/dune-project#L1>
[`dune']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/src/dune#L7>
[`Makefile']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/Makefile#L15>
[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
Js_of_ocaml in the VSCode OCaml Platform
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/js-of-ocaml-in-the-vscode-ocaml-platform/6635/1>
Max LANTAS announced
────────────────────
I just finished a write-up about [vscode-ocaml-platform]'s recent
transition to Js_of_ocaml:
<https://mnxn.github.io/blog/ocaml/vscode-jsoo/>
I can answer any questions here.
This is also my first technical blog post, so any constructive
criticism or comments about my writing would be very helpful.
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform/>
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
═════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-10/msg00018.html>
Laurène Gibaud announced
────────────────────────
At OCamlPro, we will be organizing 2 cross-company training sessions
in French. Both sessions interleave theory and practice. You'll have
time to ask your specific questions and get personalized feedback on
your programs.
• Our Beginner session will allow developers to build upon their
experience of other programming languages (such as C, C++, Python,
C# or Java) to program confidently in OCaml. Feel free to share the
info with your coworkers or your network!
• Our “Expert OCaml” training will allow you to master OCaml’s
advanced features such as its type-system, OCaml’s open source tools
and libraries, and how to write compact and efficient code.
More info on the program and prerequisites on
<http://www.ocamlpro.com/training-ocamlpro/> or ask away (answer this
email or write at contact@ocamlpro.com).
When? The Beginner session is scheduled for November 23-24, 2020. The
Expert session will be on November 25-26, 2020.
Where? Paris 14, in OCamlPro's office.
How? Register on:
<https://www.ocamlpro.com/pre-inscription-a-une-session-de-formation-inter-entreprises/>
We can also organize custom and on-site sessions upon request.
Set up OCaml 1.1.2
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-2/6643/1>
Sora Morimoto announced
───────────────────────
This release contains these changes:
• Add the Cygwin setup to a known location for later steps
• Check if the switch exists before creating the switch
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.2>
Set up OCaml 1.1.3
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-3/6644/1>
Sora Morimoto announced
───────────────────────
This release contains these changes:
• Update the `@actions/core' package to address [CVE-2020-15228]
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.3>
[CVE-2020-15228] <https://github.com/advisories/GHSA-mfwh-5m23-j46w>
First release of FSML
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-fsml/6645/1>
jserot announced
────────────────
This is to announce the first public release of FSML, an OCaml library
for describing and describing synchronous finite state machines.
FSML is a simplified version of the library provided in the [Rfsm]
package for which
• the system is composed of a single FSM
• this FSM has a single, implicit, triggering event (typically called
the *clock* , hence the term *synchronous* used in the description)
The FSML library provides
• a type `Fsm.t' for describing FSMs
• possibly having *local variables*
• for which *transitions* , implicitely triggered by a clock, are
defined by a set of *boolean guards* and a set of *actions*
• a set of PPX extensions for building values of type `Fsm.t'
• functions for producing and viewing graphical representations of
FSMs in the `.dot' format
• functions for saving and reading FSM representations in files using
the JSON format
• functions for performing single or multi-step simulations of FSMs
and generating trace files in the `.vcd' format to be viewed by VCD
viewers such as [gtkwave]
• functions for generating C or VHDL code from a FSM representation
(for integration into existing
code and/or simulation)
FSML is available from [Github] or as an [OPAM package].
[Rfsm] <http://github.com/jserot/rfsm>
[gtkwave] <http://gtkwave.sourceforge.net/>
[Github] <https://github.com/jserot/fsml>
[OPAM package] <https://opam.ocaml.org/packages/fsml>
Qrc 0.1.0, a QR code encoder
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qrc-0-1-0-a-qr-code-encoder/6647/1>
Daniel Bünzli announced
───────────────────────
QR codes are unsightly – a mirror of their specification. But they
enable all sorts of neat tricks now that scanners for them are in many
pockets.
Qrc generate them:
Qrc encodes your data into QR codes. It has built-in QR
matrix renderers for SVG, ANSI terminal and text.
Qrc is distributed under the ISC license. It has no
dependencies.
Homepage: <https://erratique.ch/software/qrc>
API docs: <https://erratique.ch/software/qrc/doc/> or `odig doc qrc'
Install: `opam install qrc'
cumulus 0.0.1
═════════════
Archive: <https://discuss.ocaml.org/t/ann-cumulus-0-0-1/6655/1>
Petter A. Urkedal announced
───────────────────────────
I would like to announce a new FRP library built on the React library.
The purpose of [cumulus] is to help organize code which work on
differential updates. The main type is the *cumulus signal*, which is
analogous to a react signal, except that information about the
difference from the previous value is provided to consumers along with
the new value, when the cumulus signal changes.
So, why does a cumulus signal provide both the state and the
difference to downstream signals? That is, what is the difference
between the following:?
┌────
│ type t1 = state * change React.E (* initial value and even of changes *)
│ type t2 = (state, change) Cumulus.t (* the cumulus signal *)
└────
The former type presumes that after the consumer has received the
initial state, it will only need to know what changes on successive
updates. This seems quite natural. It works well if, for instance,
we want to reconstruct a signal holding a set of strings, given an
initial set and a series of additions and removals:
┌────
│ module String_set = Set.Make (String)
│
│ type 'a set_patch = [`Add of string | `Remove of string]
│ type 'a update = 'a -> 'a
│
│ let patch_string_set : string set_patch -> String_set.t update = function
│ | `Add x -> String_set.add x
│ | `Remove x -> String_set.remove x
│
│ let integrate_strings (init, changes) =
│ React.E.fold (fun l p -> patch_string_set p l) init changes
└────
But what if we want to maintain a signal holding the intersection of
two sets of strings? If we try to lift the intersection operation to
work on patches, we discover that learning about the addition of an
element to left-hand set is not sufficient to determine whether the
element shall the added to the resulting set; we also need to know
whether the element is a member of the right-hand set. So, in this
case we would instead use cumulus signals:
┌────
│ let cu : (String_set.t, string set_patch) Cumulus.t = ...
│ let cv : (String_set.t, string set_patch) Cumulus.t = ...
│ let cuv =
│ let init u v = String_set.inter u v in
│ let patch (u, du) (v, dv) r' =
│ (match du, dv with
│ | None, Some x when String_set.mem x u ->
│ Cumulus.Patch (String_set.add x r', `Add1 x)
│ ...)
│ in
│ Cumulus.l2 ~init ~patch cu cv
└────
For the complete example, using integers instead of strings, see
[`test_isecn.ml'] from the testsuite.
(Footnote: If consumers know how to integrate the states they depend
on, they could in principle keep their own record of the full states
of the arguments. But this would be inefficient if there are many
consumers, and there is also a simplification of code and possibly
improved abstraction in letting the producer maintain its own state.)
Formally, we can understand the difference between `t1' and `t2' in
terms of calculus. For instance, the differential of a product
`d(x·y) = dx·y + x·dy' contains a mix of both the differentials and
values of the two variables. But if the expression is linear, only
differentials will will occur: `d(a·x + b·y + c) = a·dx + b·dy'. So,
when `t1' is sufficient, we are dealing with the analogue of a linear
function. The above example could be turned into a linear one by
making `Labels.t' a multiset type and considering the multiset union
operation.
Thus far we only considered purely functional code, but a cumulus
signal may chose to modify and return the same physical state during
an update. Also note when designing the differential component of the
cumulus signal, that we may exploit the fact the consumers also may
inspect the corresponding new state. Combining these two points, a
cumulus signal holding an array might have the type `('a array, [`Set
of int | `Resize of int])'. Here the state may be reused for ``Set'
and replaced for ``Resize'.
On a related not, there is also the [reactiveData] library which deals
with (linear) patching of containers.
I must also mention that there there is an [OCaml project with the
same name] (except casing). Sorry for not checking thoroughly in
advance. I hope it is not an issue in practise, otherwise there is
still time to rename while the library is fresh.
[cumulus] <https://github.com/paurkedal/ocaml-cumulus/>
[`test_isecn.ml']
<https://github.com/paurkedal/ocaml-cumulus/blob/master/tests/test_isecn.ml>
[reactiveData] <https://github.com/ocsigen/reactiveData>
[OCaml project with the same name] <https://github.com/Cumulus/Cumulus>
Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/5>
Continuing this thread, Yoann Padioleau asked Daniel Bünzli replied
───────────────────────────────────────────────────────────────────
What are the differences with the default bindings
provided in js_of_ocaml to the browser APIs (e.g., js.mli,
dom.mli, etc.)?
I'm not sure exactly what you are asking but:
1. If you are asking about the way API are exposed: `brr' does not
type JavaScript's objects as phantom types. It simply relies on
OCaml's abstract data types and plain functions. More about this
can be found in brr's [FFI manual] and [FFI cookbook].
2. If you are asking about binding coverage, you should be able to get
a sense of what is bound in `brr' [here].
Regarding 2. `brr''s coverage of more recent browser APIs is broader
and more consistent than in `js_of_ocaml' – Promise support, Fetch,
Service workers, Media capture APIs, WebGL2, Webcrypto, WebAudio,
etc. Conversly older APIs supported in `js_of_ocaml' may not supported
in `brr' (e.g. XMLHTTPRequest). Besides `brr''s coverage of some of
the DOM *element-specific* interfaces may be shallower than in
`js_of_ocaml'. There is however good coverage for the
[`HTMLMediaElement'], [`HTMLCanvasElement'], [`HTMLFormElement'] and
[`HTMLInputElement'] interfaces. For the rest the [attribute and
property API] and the occasional trivial FFI method binding should be
able to get you a long way.
[FFI manual] <https://erratique.ch/software/brr/doc/ffi_manual.html>
[FFI cookbook] <https://erratique.ch/software/brr/doc/ffi_cookbook.html>
[here] <https://erratique.ch/software/brr/doc/index.html#supported_apis>
[`HTMLMediaElement']
<https://erratique.ch/software/brr/doc/Brr_io/Media/index.html#el>
[`HTMLCanvasElement']
<https://erratique.ch/software/brr/doc/Brr_canvas/Canvas/index.html>
[`HTMLFormElement']
<https://erratique.ch/software/brr/doc/Brr_io/Form/index.html>
[`HTMLInputElement']
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ifaces>
[attribute and property API]
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ats_and_props>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35020 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-20 8:15 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-10-20 8:15 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 22169 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 13 to 20,
2020.
Table of Contents
─────────────────
Dialo is hiring frontend and backend OCaml developers (Remote)
Progress 0.1.0
Brr 0.0.1, a toolkit for programming browsers
New release of Conduit
Easy cross compilation using esy
OCaml User Survey 2020
Old CWN
Dialo is hiring frontend and backend OCaml developers (Remote)
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/dialo-is-hiring-frontend-and-backend-ocaml-developers-remote/6604/1>
Wojtek Czekalski announced
──────────────────────────
[Dialo] is an early stage company with an experienced founding
team. Assembling a team that consists of the best and brightest is our
top priority. In the immediate term we are building a visual
programming language for conversational AI. Our long term vision is
that personalized contact we are enabling will cause deeper
relationships between users and businesses and turn all interactions
into a unified long term customer journey.
The work is quite demanding when it comes to both ideation and
implementation. We are aiming to provide a room for growth both
technically and/or as a leader. For current open source maintainers we
are willing to sponsor your work on OSS for 20% of time.
We use OCaml for frontend and backend (along with Python for machine
learning, natural language processing). We are hiring people for
different positions. Both people with extensive experience and
newcomers are encouraged to apply. We try to find the sharpest people
rather than checking boxes with particular skills.
The official job posting:
<https://dialo.recruitee.com/o/software-developer-ocamlreason> We are
also hiring for two other (related) positions:
• <https://dialo.recruitee.com/o/software-developer-frontend>
• <https://dialo.recruitee.com/o/software-developer-backend>
[Dialo] <https://dialo.ai>
Progress 0.1.0
══════════════
Archive: <https://discuss.ocaml.org/t/ann-progress-0-1-0/6607/1>
Craig Ferguson announced
────────────────────────
I'm pleased to announce the first release of [`Progress'], now
available on Opam.
<https://raw.githubusercontent.com/CraigFe/progress/main/.meta/example.svg>
`Progress' is a small library for quickly defining and using progress
bars in OCaml programs. It aims to provide the following:
• support for rendering multiple progress bars simultaneously;
• responds dynamically to changes in terminal size;
• allows user-defined progress bar layouts.
[`Progress'] <https://github.com/CraigFe/progress/>
Defining your own progress bars
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The example animation above uses a pre-provided progress bar layout
that should meet many needs ([`Progress_unix.counter']), but it's
fairly easy to re-define it ourselves using the low-level
[`Progress.Segment'] API:
┌────
│ let counter filename =
│ let proportion i = Int64.to_float i /. 1_000_000. in
│ let open Progress in
│ Segment.(
│ list
│ [
│ const filename;
│ Units.bytes of_pp;
│ Progress_unix.stopwatch ();
│ bar ~mode:`ASCII proportion;
│ using proportion (Units.percentage of_pp);
│ ]
│ |> box_winsize ~fallback:80 (* Dynamically scale to window size *)
│ |> periodic 100 (* Re-render once every 100 updates *)
│ |> accumulator Int64.add 0L (* Accumulate progress updates *))
│ |> make ~init:0L
└────
The `Segment' combinators are similar to those of general-purpose
pretty-printing libraries (e.g. [`pp'] and [`fmt']), but are equipped
with extra logic for "stateful" segments and segments that can have
dynamic width. Together, these make for a convenient way to express
common patterns when pretty-printing progress bars. For instance, the
stateful segment `periodic' seen above can be used to ensure that very
frequent updates from a hot-loop do not result in too much time spent
re-rendering the output.
The library is not yet feature-complete, but should still be
reasonably useful :slightly_smiling_face: Happy hacking!
[`Progress_unix.counter']
<https://craigfe.github.io/progress/progress/Progress_unix/index.html#val-counter>
[`Progress.Segment']
<https://craigfe.github.io/progress/progress/Progress/Segment/index.html>
[`pp'] <https://github.com/ocaml-dune/pp>
[`fmt'] <https://erratique.ch/software/fmt>
Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/1>
Daniel Bünzli announced
───────────────────────
I'd like to announce the first release of Brr.
The TL; DR is:
If you are looking for a productive way to program
browsers with js_of_ocaml but without ppx and ghost OCaml
objects, give Brr a try.
The details:
Brr is a toolkit for programming browsers in OCaml with
the [`js_of_ocaml'] compiler. It provides:
• Interfaces to a [selection] of browser APIs.
• Note based reactive support (optional and experimental).
• An [OCaml console] developer tool for live interaction
with programs running in web pages.
• A JavaScript FFI for idiomatic OCaml programming.
Brr is distributed under the ISC license. It depends on
[Note] and on the `js_of_ocaml' compiler and runtime – but
not on its libraries or syntax extension.
• Homepage: <https://erratique.ch/software/brr>
• API Docs & manuals: <https://erratique.ch/software/brr/doc/> or
`odig doc brr'
• Install: `opam install brr'
Brr is essentially what I need to be productive for browser
programming with js_of_ocaml: an obvious FFI with JavaScript objects
as abstract data types without OCaml object phantom types and binding
documentation precisely linking into MDN.
The OCaml console is the hack on the cake. In the past I often found
it frustrating to have OCaml programs running in my webpages and be
greeted with a JavaScript prompt in the browser dev tools. Quite a
bit of polishing could be done on that though. Some of which should
likely directly be done upstream in the toplevel machinery
(e.g. identifier completion, a better toploop API and support for easy
pretty printer installation). It would also be nice if we could cut
down on `js_of_ocaml''s toplevel compilation times ;–)
Parts of Brr have been seriously dogfooded in the past but that new
incarnation is largely untested for now and certain APIs might need
adjustements. Early adopters should study actual binding coverage,
expect glitches and little breakages in the future.
The Note reactive functionality was also seriously used in the past
but Note itself needs a new design round and I don't have the
ressources to do it right now, expect breakage, don't pay too much
attention to it for now.
My thanks to the `js_of_ocaml' developers for the nice ocaml to
javascript compiler and a special shootout to Hugo Heuzard for not
getting mad at me when pinging him directly for questions.
Happy browser compatibility bug hunting,
[`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml>
[selection]
<https://erratique.ch/software/brr/doc/index.html#supported_apis>
[OCaml console]
<https://erratique.ch/software/brr/doc/ocaml_console.html>
[Note] <https://erratique.ch/software/note>
gasche asked
────────────
It's not really released, but I'm curious about [Note] now: this is a
new FRP library from you, the author of [React] (the FRP library for
OCaml, not the Javascript framework of the same name).
Would you say a few words on why you went for a different library? My
guess would be that React depends on runtime mechanisms (weak
pointers) that are not well-supported in Javascript-lang; but even if
the guess is right, I'm not sure what would be the impact on the API
or properties of the library.
[Note] <https://erratique.ch/software/note>
[React] <https://erratique.ch/software/react>
Daniel Bünzli replied
─────────────────────
Would you say a few words on why you went for a different
library?
`Note' is the result from seeing people (and myself) struggling to use
~React~/FRP "correctly" over the years.
Some of this, I largely attribute to ergonomic problems with the
API. It's my hope for `Note' to address most of these points (one
thing that still needs to be done is replace fix points by a simple
lazy infinitesimal delay combinator).
I don't think I could have made all these changes in `React' itself so
I found it better to start a new library. Also I lost the trademark on
the name :–)
`Note' also tries to provide a much simpler implementation. `React''s
implementation was based on the [FrTime Phd thesis]. It's quite subtle
and involved and, as you suggested, uses weak pointer. `Note' tries to
avoid them since those are not available in the browser (but you have
things like [MutationObservers] which I use as gc in Brr's Note-based
[reactive dom support]).
However not using weak pointers has a semantic uncleanness cost whose
impact I'm unsure yet – without discipline from the programmer it may
lead to subtle and hard to track bugs when the reactive graph changes
dynamically, which I'm a bit wary of.
When my brain dumped `Note' I wrote a few more technical points in the
readme you can read them [here].
[FrTime Phd thesis] <http://cs.brown.edu/people/ghcooper/thesis.pdf>
[MutationObservers]
<https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver>
[reactive dom support]
<https://erratique.ch/software/brr/doc/Brr_note/Elr/index.html>
[here] <https://github.com/dbuenzli/note#history>
New release of Conduit
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611/1>
Calascibetta Romain announced
─────────────────────────────
*Conduit 3.0.0*
Hello everyone,
We're glad to announce the new release of [`conduit'], a framework
that allows to _abstract_ over transfer protocols. One of its main
advantages is allowing the implemententation of _free-dependencies_
protocols.
[`conduit'] <https://github.com/mirage/ocaml-conduit>
Introduction
╌╌╌╌╌╌╌╌╌╌╌╌
There are several ways to abstract over an implementation in
OCaml. However, those solutions are often lost deep in the stack of
protocols and allowing the user to choose the implementations of the
sub-procotols implies growing complexity as we move up through the
stack. (For example, allowing to abstract over the implementation of
the TLS protocol from the implementation of the HTTP protocol)
One of those solutions, the _functors_, can rapidly become a hellish
nightmare for the end-user. This is especially true in the case of
MirageOS, which literally wants to abstract over everything!
This is why Conduit was implemented: it aims to provide to the user a
cleaner abstraction mechanism which would allow the protocol
developers to get rid of most of the responsibilities concerning the
choice of sub-protocols (Like which TLS implementation use between
OpenSSL or our great [ocaml-tls] library), while giving the end-users
an easy way to compose the protocols of their choice and inject them
in the stack via conduit.
[ocaml-tls] <https://github.com/mirleft/ocaml-tls>
Usage of Conduit
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Such a framework allows us to separate the logic of a protocol from
underlying implementation needed to communicate with a peer. The
distribution of Conduit comes with [a simple tutorial] which explains
step by step how to implement a _ping-pong_ client & server and, most
importantly, how to upgrade them with TLS.
With Conduit, we ensure the compatibility with MirageOS (and specially
[mirage-tcpip]) while being useful for others. Of course, Conduit is
not mandatory to ensure this compatibility, but it helps us for
_higher_ libraries such as [ocaml-git]/[Irmin] or [Cohttp].
[a simple tutorial]
<https://mirage.github.io/ocaml-conduit/conduit/howto.html>
[mirage-tcpip] <https://github.com/mirage/mirage-tcpip>
[ocaml-git] <https://github.com/mirage/ocaml-git>
[Irmin] <https://github.com/mirage/irmin>
[Cohttp] <https://github.com/mirage/ocaml-cohttp>
Specific improvements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Abstract and destruct it!
The most requested feature on the new version of Conduit is the
ability to _destruct_ the [Conduit.flow][conduit-flow]. The ability to
abstract the protocol comes with the _abstract_ type
`Conduit.flow'. The new version permits to _destruct_ it to a
well-known value (such as an UNIX socket):
┌────
│ let handler flow = match flow with
│ | Conduit_lwt.TCP.T (Value file_descr) ->
│ let peer = Lwt_unix.getpeername file_descr in
│ ...
│ | flow -> ... (* other kind of protocol *)
│
│ let run =
│ Cohttp_lwt_unix.serve ~handler
│ { sockaddr= Unix.inet_addr_loopback }
└────
◊ The dispatch of the protocol
The second most interesting feature of Conduit is the full control
over the dispatch between protocols by the end-user. From a concrete
information such as an `Uri.t', the end-user is able to describe how
Conduit should choose the protocol (and with which value it should try
to initiate the connection):
┌────
│ let my_tls_config = Tls.Config.client ...
│
│ let connect uri =
│ let edn = Conduit.Endpoint.of_string
│ (Uri.host_with_default ~default:"localhost" uri) in
│ let resolvers = match Uri.scheme uri with
│ | Some "https" ->
│ let port = Option.value ~default:443 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt_tls.TCP.protocol
│ (Conduit_lwt_tls.TCP.resolve ~port ~config:my_tls_config)
│ Conduit.empty
│ | Some "http" | None ->
│ let port = Option.value ~default:80 (Uri.port uri) in
│ Conduit_lwt.add
│ Conduit_lwt.TCP.protocol
│ (Conduit_lwt.TCP.resolve ~port)
│ Conduit.empty in
│ Conduit_lwt.resolve ~resolvers edn >>= fun flow ->
│ ...
└────
◊ An explicit way to launch a server
Conduit comes with a new API for the server-side, where everything
becomes explicit: no dispatch, no hidden choice. It proposes now a
simple function to start the usual server loop:
┌────
│ let run handler =
│ Conduit_lwt.serve ~handler
│ Conduit_lwt.TCP.service
│ { Conduit_lwt.TCP.sockaddr= Unix.(ADDR_INET (inet_addr_loopback, 8080)
│ ; capacity= 40 }
└────
Reverse-dependencies
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Conduit is used by many libraries (~150 packages) and we spend 2
months to track this breaking-change. Currently, it's mostly about
[Cohttp] and [Irmin] and both have a PR according the new version of
Conduit. These packages will be released as soon as we can with the
new version of Conduit.
[Cohttp] <https://github.com/mirage/ocaml-cohttp>
[Irmin] <https://github.com/mirage/irmin>
Conclusion
╌╌╌╌╌╌╌╌╌╌
Conduit is a piece required by many libraries but nobody really uses
it. This new version wants to replace and redefine more concretely
what Conduit is. The update is [huge] for us but small for people
where we tried to keep the same global idea of the abstraction.
I would like to thank many people (MirageOS core team, Cohttp peoples,
some not so famous guys of the Reason/OCaml eco-system) who followed
us on this deep development (and tried and iterated on our
version). It does not change too much our world, but it paves the way
for a better MirageOS/OCaml eco-system.
As a french guy, I just would like to say: Conduit est mort, Vive
Conduit!
[huge] <https://github.com/mirage/ocaml-conduit/pull/311>
Easy cross compilation using esy
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-easy-cross-compilation-using-esy/6612/1>
EduardoRFS announced
────────────────────
I've been working on this for a couple of months now, and now it is
ready for an initial announcement of my tools to cross compiling OCaml
and ReasonML Native.
<https://github.com/EduardoRFS/reason-mobile>
What it can do
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Out of box it can cross compile most dune and topkg, packages
available on opam for a couple of platforms, there is also patches for
popular packages.
You can also compile opam packages by making an wrapper, like
<https://github.com/mirage/mirage-crypto/pull/84/files>
Limitations
╌╌╌╌╌╌╌╌╌╌╌
Your package should build with OCaml 4.10, and all the packages that
are built for the `host' will also be build for the `target', so
sometimes you need to fix a package that you will not use directly.
Some packages you will need to pin to a `dune-universe' fork version
How to use it
╌╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ ## compile your project
│ esy
│
│ ## generate the wrapper
│ esy add -D generate@EduardoRFS/reason-mobile:generate.json
│ esy generate android.arm64
│
│ ## build for android.arm64
│ esy @android.arm64
└────
Platforms
╌╌╌╌╌╌╌╌╌
All of the following are tested from Linux and macOS, but I would
suppose that FreeBSD should be also working as a build system.
━━━━━━━━━━━━━━━━━━━━━━
Targets
──────────────────────
android.arm64
android.x86_64
ios.arm64
ios.simulator.x86_64
linux.musl.arm64
linux.musl.x86_64
━━━━━━━━━━━━━━━━━━━━━━
What I tested
╌╌╌╌╌╌╌╌╌╌╌╌╌
In the past I was able to build `Revery' the UI framework for
`Android' and `iOS'
But recently I did compile `esy' the package manager itself for all of
the following platforms above from an `Arch Linux x86_64' and `macOS
Catalina x86_64'. Including `iOS', with the right version of OCaml it
will run inside of the new `macOS ARM64' and inside of a jailbroken
iPhone.
OCaml User Survey 2020
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/1>
gasche announced
────────────────
We are happy to announce the [OCaml User Survey 2020]. We are trying
to get a better picture of the OCaml community and its needs. It would
be very useful if you could fill the survey (10-15 minutes), and share
it widely with other OCaml programmers!
The survey is run by the [OCaml Software Foundation]. Thanks in
particular to our sponsors OCamlPro (@MuSSF) for preparing many of the
questions, Jane Street (@Yaron_Minsky) for excellent feedback, and to
Kim @K_N Nguyễn for his technical help.
This is our first year running the survey, we hope to continue in
following years. There are many things to improve; please feel free to
give us feedback! (There is a feedback question at the end of the
survey, or you can post here, or send me a message/email.)
The survey was inspired by programming-language surveys ran by other
communities. See for example past survey results for [Go], [Haskell],
[Rust], and [Scala].
[OCaml User Survey 2020] <https://forms.gle/MAT7ZE7RtxTWuNgK7>
[OCaml Software Foundation] <https://ocaml-sf.org/>
[Go] <https://blog.golang.org/survey2019-results>
[Haskell] <https://taylor.fausak.me/2019/11/16/haskell-survey-results/>
[Rust] <https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html>
[Scala] <https://scalacenter.github.io/scala-developer-survey-2019/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 41767 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-06 7:22 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-10-06 7:22 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 29 to
October 06, 2020.
Table of Contents
─────────────────
vue-jsoo 0.2
Rehabilitating packs using functors and recursivity, part 2
Clap 0.1.0 (Command-Line Argument Parsing)
Old CWN
vue-jsoo 0.2
════════════
Archive: <https://discuss.ocaml.org/t/ann-vue-jsoo-0-2/6522/1>
levillain.maxime announced
──────────────────────────
I'd like to announce the second release of vue-jsoo (vue-jsoo.0.2). A
js_of_ocaml binding and helpers to use the vue-js framework with
js_of_ocaml.
Xavier Van de Woestyne added
────────────────────────────
Here is the link: <https://gitlab.com/o-labs/vue-jsoo>
(Congratulation!)
Rehabilitating packs using functors and recursivity, part 2
═══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity-part-2/6525/1>
OCamlPro announced
──────────────────
Following the publication of [the first part] of our blogpost about
the redemption of packs in the OCaml ecosystem, we are pleased to
share "[Rehabilitating packs using functors and recursivity, part 2.]"
This blog post and the previous one about functor packs
covers two RFCs currently developed by OCamlPro and Jane
Street. We previously introduced functor packs, a new
feature adding the possiblity to compile packs as
functors, allowing the user to implement functors as
multiple source files or even parameterized libraries.
In this blog post, we will cover the other aspect of the
packs rehabilitation: allowing anyone to implement
recursive compilation units using packs (as described
formally in the RFC#20). Our previous post introduced
briefly how packs were compiled and why we needed some
bits of closure conversion to effectively implement big
functors. Once again, to implement recursive packs we will
need to encode modules through this technique, as such we
advise the reader to check at least the introduction and
the compilation part of functor packs.
[the first part]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>
[Rehabilitating packs using functors and recursivity, part 2.]
<https://www.ocamlpro.com/2020/09/30/rehabilitating-packs-using-functors-and-recursivity-part-2/>
Clap 0.1.0 (Command-Line Argument Parsing)
══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-clap-0-1-0-command-line-argument-parsing/6544/1>
rbardou announced
─────────────────
I am happy to announce the first release of Clap.
Clap is a library for command-line argument parsing. Clap works by
directly consuming arguments in an imperative way. Traditionally,
argument parsing in OCaml is done by first defining a specification
(an OCaml value defining the types of arguments), and then parsing
from this specification. The "impure" approach of Clap skips the need
to define a specification and results in code which is quite simple in
practice, with limited boilerplate.
Clap is available as an opam package (`opam install clap').
Source code, API documentation and a full commented example are
available at: <https://github.com/rbardou/clap/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 15116 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-29 7:02 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-09-29 7:02 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 14486 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 22 to
29, 2020.
Table of Contents
─────────────────
Opam-repository: security and data integrity posture
jsonoo 0.1.0
Interesting OCaml Articles
Rehabilitating Packs using Functors and Recursivity
the OCaml Software Foundation
dual 0.1.0
Old CWN
Opam-repository: security and data integrity posture
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478/1>
Chas Emerick said, spawning a huge thread
─────────────────────────────────────────
In connection with [another thread] discussing the fact that
Bitbucket's closure of mercurial support had affected the availability
of around 60+ projects' published versions, I learned of a number of
facts about how the opam repository is arranged, and how it is managed
that are concerning.
In summary, it seems that opam / opam-repository:
1. Never retains "published" artifacts, only links to them as provided
by library authors.
2. Allows very weak hashes (even md5).
3. Allows authors to _update_ artifact URLs and hashes of previously
"published" versions.
4. Offers scant support for individually signing artifacts or
metadata.
All of these are quite dangerous. As a point of reference, the
ecosystems I am most familiar with using prior to OCaml (JVM and
Javascript) each had very serious documented failures and exploits
(and many many more quiet ones) until their respective package
managers (Maven Central et al., and npm) plugged the above
vulnerabilities that opam-repository suffers from.
To make things concrete, without plugging the above (and especially
items 1-3):
• the availability and integrity of published libraries can be
impacted by third-party hosting services changing or going offline
(as in the case of the Bitbucket closure)
• the integrity of libraries can be impacted by authors
non-maliciously publishing updates to already-released versions,
affecting functionality, platform compatibility, build
reproducibility, or all of the above (anecdotes of which were shared
with me when talking about this issue earlier today)
• the integrity of libraries can be impacted by malicious authors
publishing updates to already-released versions
• the integrity of libraries can be impacted by malicious non-authors
changing the contents at tarball URLs to include changed code that
could e.g. exfiltrate sensitive data from within the organizations
that use those libraries. This is definitely the nuclear nightmare
scenario, and unfortunately opam is wide open to it thanks to
artifacts not being retained authoritatively and [essential
community libraries] continuing to use md5 in 2020.
Seeing that this has been well-established policy for years was
honestly quite shocking (again, in comparison to other languages'
package managers that have had these problems licked for a very very
long time). I understand that opam and its repository probably have
human-decades of work put into them, and that these topics have been
discussed here and there (in somewhat piecemeal fashion AFAICT), so
I'm certain I have not found (nevermind read) all of the prior art,
but I thought it reasonable to open a thread to gauge what the
projects' posture is in general.
[another thread]
<https://discuss.ocaml.org/t/bitbucket-stopped-supporting-mercurial-repositories/6324/3?u=cemerick>
[essential community libraries]
<https://github.com/ocaml/opam-repository/blob/master/packages/core/core.v0.14.0/opam>
Hannes Mehnert replied
──────────────────────
first of all thanks for your post raising this issue, which is
important for me as well.
I've been evaluating and working on improving the security of the
opam-repository over the years, including to not use `curl –insecure`
(i.e. properly validate TLS certificates) - the WIP result is [conex],
which aims at cryptographically signed community repositories without
single points of failures (threshold signatures for delegations,
built-in key rollover, …) - feel free to read the blog posts or OCaml
meeting presentations. Unfortunately it still has not enough traction
to be deployed and mandatory for the main opam repository. Without
cryptopgraphic signatures (and an established public key
infrastructure), the hashes used in opam-repository and opam are more
checksums (i.e. integrity protection) than for security. Threat models
- I recommend to read section [1.5.2 "goals to protect against
specific attacks"] - that's what conex above is based on and attempts
to mitigate. I'll most likely spend some time on improving conex over
the next year, and finally deploying it on non-toy repositories.
In the meantime, what you're mentioning:
1. "Never retains 'published' artifacts" <- this is not true, the
opam.ocaml.org host serves as an artifact cache, and is used by
opam when you use the default repository. This also means that the
checksums and the tarballs are usually taken from the same host ->
the one who has access there may change anything arbitrarily for
all opam users.
2. "Weak hashes" <- this is true, I'd appreciate if (a) opam would
warn (configurable to error out) if a package which uses weak
checksum algorithms, and (b) Camelus or some other CI step would
warn when md5/sha1 are used
3. "Authors can modify URLs and hashes" <- sometimes (when a
repository is renamed or moved on GitHub) the GitHub auto-generated
tarball has a different checksum. I'd appreciate to, instead of
updating that meta-data in the opam-repository to add new
patch-versions (1.2.3-1 etc.) with the new URL & hash - there could
as well be a CI job / Camelus check what is allowed to be modified
in an edit of a package (I think with the current state of the
opam-repository, "adding upper bounds" on dependencies needs to be
allowed, but not really anything else).
4. I'm not sure I understand what you mean - is it about cryptographic
signatures and setting up a public key infrastructure?
[conex] <https://github.com/hannesm/conex>
[1.5.2 "goals to protect against specific attacks"]
<https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification>
Anton Kochkov said
──────────────────
Closely related issue is
<https://discuss.ocaml.org/t/how-to-setup-local-opam-mirror/4423>,
since the integrity checks and verification will become even more
important if there will be multiple mirrors in the future.
jsonoo 0.1.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-jsonoo-0-1-0/6480/1>
Max LANTAS announced
────────────────────
Hello! I am announcing the first release of `jsonoo', a JSON library
for Js_of_ocaml.
<https://github.com/mnxn/jsonoo>
<https://opam.ocaml.org/packages/jsonoo>
This library provides a very similar API to the excellent BuckleScript
library, [bs-json] by [glennsl]. Unlike bs-json, this port of the
library tries to follow OCaml naming conventions and be easier to
interface with other OCaml types like `Hashtbl.t' . This library
passes a nearly equivalent test suite.
This project is part of ongoing work to port [vscode-ocaml-platform]
to Js_of_ocaml.
Generated documentation can be found [here].
[bs-json] <https://github.com/glennsl/bs-json>
[glennsl] <https://github.com/glennsl>
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[here] <https://mnxn.github.io/jsonoo/jsonoo/Jsonoo/index.html>
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/62>
Ryan Slade announced
────────────────────
<https://blog.darklang.com/fizzboom-benchmark/>
Rehabilitating Packs using Functors and Recursivity
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity/6497/1>
OCamlPro announced
──────────────────
Our new blogpost is about the redemption of packs in the OCaml
ecosystem. This first part shows our work to generate functor units
and functor packs : [Rehabilitating Packs using Functors and
Recursivity, part 1.]
Packs in the OCaml ecosystem are kind of an outdated
concept (options `-pack' and `-for-pack' the OCaml manual,
and their main utility has been overtaken by the
introduction of module aliases in OCaml 4.02. What if we
tried to redeem them and give them a new youth and utility
by adding the possibility to generate functors or
recursive packs?
This blog post covers the functor units and functor packs,
while the next one will be centered around recursive
packs. Both RFCs are currently developed by JaneStreet and
OCamlPro. This idea was initially introduced by functor
packs (Fabrice Le Fessant) and later generalized by
functorized namespaces (Pierrick Couderc /et al/.).
[Rehabilitating Packs using Functors and Recursivity, part 1.]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>
the OCaml Software Foundation
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/19>
gasche announced
────────────────
We were all very busy during the last semester, and have been mostly
quiet on the foundation activities, but of course our actions were
running in the background. Some highlights:
• Kate @kit-ty-kate Deplaix has worked on opam-repository QA for the
OCaml 4.11 release, and the work and results are just as superb as
for 4.10. We will fund Kate to work again on the upcoming 4.12
release.
• We are funding ongoing maintenance work on [ocaml-rs] (a port of the
OCaml FFI library from C to Rust) by its author and maintainer, Zach
@zshipko Shipko. Zach did a big round of cleanup changes this
summer, improving the overall design of the library and completing
its feature set.
• We are funding @JohnWhitington (the author of [OCaml from the Very
Beginning]) to do some technical writing work for OCaml
documentation. His contributions so far have been very diverse, from
a script to harmonize the documentation of List and ListLabels (and
Array and ArrayLabels, etc.) in the standard library, to small
cleanups and improvement to ocaml.org web pages. One focus of his
work is the upcoming documentation page "Up and running with OCaml",
taking complete newcomers through the basic setup, using the
toplevel and building and running a Hello World. ([ocaml.org#1165],
[rendered current state])
• Two [Outreachy] internships were supervised this summer, focusing on
the compiler codebase. Florian @Octachron Angeletti (INRIA)
supervised an intern on adding a JSON format for some compiler
messages (we expect PRs to be submitted soon). Vincent @vlaviron
Laviron and Guillaume @zozozo Bury (OCamlPro) supervised an intern
on reducing mutable state in the internal implementation.
• Inspired by [this Discuss thread], we are funding experimental work
by @sanette on the HTML rendering of the OCaml manual. This work is
in the process of being reviewed for upstreaming in the OCaml
compiler distribution. ([#9755].) This is a better end-result than I
had initially expected.
(We also had a couple non-highlights. For example, we funded a sprint
(physical development meeting) for the [Owl] contributors, with
Marcello @mseri Seri doing all the organization work; it was planned
for the end of March, and had to be postponed due to the pandemic.)
[ocaml-rs] <https://github.com/zshipko/ocaml-rs/>
[OCaml from the Very Beginning] <http://ocaml-book.com/>
[ocaml.org#1165] <https://github.com/ocaml/ocaml.org/pull/1165>
[rendered current state]
<https://github.com/johnwhitington/ocaml.org/blob/up-and-running/site/learn/tutorials/up_and_running.md>
[Outreachy] <https://outreachy.org>
[this Discuss thread]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
[#9755] <https://github.com/ocaml/ocaml/pull/9755>
[Owl] <https://github.com/owlbarn>
dual 0.1.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dual-0-1-0/6512/1>
Jason Nielsen announced
───────────────────────
I’ve released [dual] which is now up on opam. It is a dual numbers
library which includes a one dimensional root finder (via Newton's
method).
[dual] <https://github.com/drjdn/ocaml_dual>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26248 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-22 7:27 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-09-22 7:27 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15579 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 15 to
22, 2020.
Table of Contents
─────────────────
Liquidsoap 1.4.3
Simple63 v1: compression of integer sequences
bentov v1: streaming estimation of 1D histograms
opam-compiler 0.1.0
lua_parser 1.0.0
Merlin 3.4.0 : introducing external configuration readers
gRPC server and client in OCaml
Bitstring (and ppx_bitstring) 4.0.0
Old CWN
Liquidsoap 1.4.3
════════════════
Archive: <https://discuss.ocaml.org/t/ann-liquidsoap-1-4-3/6429/1>
Romain Beauxis announced
────────────────────────
I'm happy to announce that liquidsoap `1.4.3' is out at:
<https://github.com/savonet/liquidsoap/releases/tag/v1.4.3>
This is the 3rd bugfix release for the `1.4.x' branch. It contains
important fixes and a couple of new minor features. Update is
recommended and should be fairly safe.
Along we this release, we have now added builds for `arm64' debian
packages and docker-ready production images for `amd64' and `arm64'
architectures available at:
<https://hub.docker.com/repository/docker/savonet/liquidsoap>
Again, we would like to warmly thank all users, contributors and
reporters for helping us bring liquidsoap to the next step!
Also, please note that a couple of issues had to be left out to make
sure that the release comes out on time. These are listed [here] and
will be tackled as soon as possible.
Next for liquidsoap, we will focus on getting the current `2.x' branch
finalized and polished. We already have support for encoded content
and ffmpeg raw frames. We need to write a couple of inline encoders
and decoders and we'll have 90% of the features ready. This will be a
major update for us!
[here] <https://github.com/savonet/liquidsoap/milestone/7>
Simple63 v1: compression of integer sequences
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-simple63-v1-compression-of-integer-sequences/6431/1>
Mika Illouz announced
─────────────────────
This is to announce Simple63, an opam package for compression of
integer sequences; similar to Anh and Moffat's Simple-8b. More details
found in:
• github: [https://github.com/barko/simple63]
• documentation: [https://barko.github.io/simple63/]
Feedback and bug reports welcome.
[https://github.com/barko/simple63] <https://github.com/barko/simple63>
[https://barko.github.io/simple63/] <https://barko.github.io/simple63/>
bentov v1: streaming estimation of 1D histograms
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bentov-v1-streaming-estimation-of-1d-histograms/6434/1>
Mika Illouz announced
─────────────────────
This is to announce bentov, a opam package that implements a 1D
histogram-sketching algorithm. For more details:
• github: [https://github.com/barko/bentov]
• documentation: [https://barko.github.io/bentov]
Feedback and bug reports welcome.
[https://github.com/barko/bentov] <https://github.com/barko/bentov>
[https://barko.github.io/bentov] <https://barko.github.io/bentov>
opam-compiler 0.1.0
═══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-compiler-0-1-0/6442/1>
Etienne Millon announced
────────────────────────
On behalf of the opam maintainers, I'd like to announce the first
release of opam-compiler, a plugin to work with compiler variants,
branches and forks.
This can cover a pretty wide range of use cases, so the first version
is starting small with a single command to create a switch from a
branch or github PR:
┌────
│ % opam compiler create '#9921'
│ Opam plugin "compiler" is not installed. Install it on the current switch? [Y/n] y
│
│ ...
│
│ <><> Carrying on to "opam compiler create #9921" ><><><><><><><><><><><><><><><>
│
│ [ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised from
│ git+https://github.com/gasche/ocaml#Atomic.create
│ ocaml-variants is now pinned to git+https://github.com/gasche/ocaml#Atomic.create (version
│ 4.12.0+trunk)
│ % opam switch
│ ...
│ → ocaml-ocaml-9921
│ [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Atomic.make into Atomic.create
└────
You can also override the arguments passed to `--configure'.
As you can see in the above snippet, it's an opam plugin so it will
auto-install if needed (assuming you ran `opam update' recently) and
will be available across all switches. Its sources and issue tracker
are available [here].
For the next releases, our plan is to add a user-friendly way to setup
a switch based on a local git clone, so that it's easy to test your
compiler fork with opam packages. You can find the other features we'd
like to add in the future in [the relevant part of the opam roadmap].
Thanks and have fun compiling compilers!
[here] <https://github.com/ocaml-opam/opam-compiler>
[the relevant part of the opam roadmap]
<https://github.com/ocaml/opam/wiki/Spec-for-working-with-the-OCaml-compiler>
lua_parser 1.0.0
════════════════
Archive: <https://discuss.ocaml.org/t/ann-lua-parser-1-0-0/6445/1>
Jason Nielsen announced
───────────────────────
I've release [lua_parser] which is now up on opam. It is a parser and
pretty-printer for lua 5.2. Actually it was developed with luajit in
mind which is lua 5.1 plus goto/labels (which syntactically for the
purposes of parsing and pretty-printing is lua 5.2).
[lua_parser] <https://github.com/drjdn/ocaml_lua_parser>
Merlin 3.4.0 : introducing external configuration readers
═════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-merlin-3-4-0-introducing-external-configuration-readers/6446/1>
vds announced
─────────────
I am glad to announce, on behalf of the Merlin team, the release of
Merlin `3.4.0' which brings some major changes in the way
configuration is handled.
As you might know, Merlin reads its configuration from the closest
`.merlin' file to the source file being edited. These files tell
merlin where to find other source files and build artifacts, but also
which flags should be passed to the compiler, which syntax extensions
are enabled and which packages are used by the project.
In this setting the configuration is the same for all the source files
of a folder, regardless of their specificities. In other words, the
configuration loaded for a single source file contains the union of
the dependencies of this file and of all its siblings which is not an
optimal behavior.
Starting with version `3.4.0' merlin will ship with two packages:
`merlin' and `dot-merlin-reader' which, as the name suggests, reads
configuration from `.merlin' files. Both are necessary for proper
function.
When a `.merlin' file is present in the source folder the Merlin
server will start a `dot-merlin-reader' process and communicate with
it via standard input and output following a simple protocol. These
processes are halted with the server.
*This change should not have any visible impact on users' workflows as
long as the `dot-merlin-reader' binary is correctly installed and in
the path*. (which should be the case in opam-based setups)
This change in itself will not solve the granularity problem mentioned
earlier, but it paves the way for such improvements: in a near-future
Dune will stop generating `.merlin' files and Merlin will obtain
file-based configuration directly from the build system using the same
protocol as the one used by `dot-merlin-reader'.
Changelog
╌╌╌╌╌╌╌╌╌
⁃ merlin binary
• fix completion of pattern matchings with exception patterns
(#1169)
• delegate configuration reading to external programs via a simple
protocol and create a new package `dot-merlin-reader' with a
binary that reads `.merlin' files. (#1123, #1152)
gRPC server and client in OCaml
═══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/grpc-server-and-client-in-ocaml/6465/1>
blandinw announced
──────────────────
TL;DR <https://github.com/blandinw/ocaml-grpc-envoy/>
Hey, I'm new to OCaml after writing some Clojure, C++ and Haskell in
various contexts, including working at FB (relevant below).
After browsing this forum and Reddit for a bit, the assumption seems
to be that OCaml is not a good fit for gRPC, since there's no pure
implementation today. Now, this is something I have experience with,
so I thought I'd try and challenge this assumption.
As you may know, services inside FB use Thrift (both the format and
protocol) to communicate. The Thrift team worked primarily in C++ (for
good reasons), causing support for other languages to lag behind
despite their best efforts. Now, the interchange format (equivalent to
Protobuf) does not change very often so it's fine to have a
per-language implementation, but the client and server (equivalent to
HTTP2 + gRPC) frequently receive new features, optimizations and
fixes. After a valiant and continued effort to support most languages
used internally, the Thrift team came up with an idea. Instead of
maintaining multiple implementations and dealing with obscure FFI
bugs, ~FingerprintTrustManagerFactory~s and whatnot, they would focus
solely on the C++ implementation and provide a daemon to be ran
alongside whatever code you were trying to run. You could then use
simple IPC to exchange Thrift (the format) messages with that daemon,
and it would handle all the nitty-gritty of running a service at scale
(load balancing, connection pooling, service discovery, security,
retries, timeouts, network stats, hot restarts, etc.). Needless to
say, it worked remarkably well even at very high scale and everybody
was much happier.
I wanted to replicate this idea with OCaml and gRPC. We already have
support for protobuf thanks to the excellent `ocaml-protoc'. All we
need is a way to exchange protobuf messages reliably on the wire.
Instead of having an OCaml implementation that will have to stay
up-to-date and have its own set of bugs (the official `grpc/grpc-java'
repo has 4450 commits and 2400 issues at the moment), can we reuse
existing infra with already massive support and production time?
Fortunately, the people at Lyft built just that, open-sourced it and
contributed it to the Cloud Native Computing Foundation in late
2017. It is called Envoy and it is bliss.
I demonstrate how to fit these pieces together at
[blandinw/ocaml-grpc-envoy] to build a simple KV store, including a
gRPC client and server in 200 lines of OCaml code. The idea is to
spawn an Envoy process that will handle all gRPC communication for our
OCaml code. We use HTTP/1.1 to exchange Protobuf messages with it,
using for example `httpaf' and `Lwt'. This solution has the added
benefit that it is highly scalable from the start, allowing you for
instance to spawn one OCaml process per core and load balance between
them. You can also use Envoy (with proper config!) as your web reverse
proxy instead of say, nginx.
At the very least, this solution allows us to start writing gRPC code
today, and gracefully evolve towards HTTP/2, Multicore and maybe a
native OCaml implementation later.
I'm curious to hear your perspective on the future of building
services with OCaml, or your past experience like what went well, what
was missing, etc.
[blandinw/ocaml-grpc-envoy]
<https://github.com/blandinw/ocaml-grpc-envoy/>
Yawar Amin asked and blandinw replied
─────────────────────────────────────
Fantastic idea. So if I understand correctly, the only
thing that Envoy (server-side) is doing is translating the
Protobuf from gRPC HTTP2 transport to HTTP1, and
forwarding these Protobuf objects over HTTP1 to the OCaml
server? Envoy doesn't know to know about the actual gRPC
schema, because it doesn't touch the Protobuf objects
themselves, right?
That's correct. Envoy is only concerned with transporting bytes (along
with load balancing, routing, etc, etc). Only OCaml knows about the
Protobuf schemas.
In the OCaml server case, Envoy listens for HTTP/2 gRPC requests,
accesses the bytes payload with no knowledge of the actual
schema/layout and repackages these same bytes in a HTTP/1.1 request
that OCaml can process. OCaml then responds with bytes (an encoded
Protobuf response message) that Envoy sends back on the original HTTP2
connection.
Bitstring (and ppx_bitstring) 4.0.0
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-bitstring-and-ppx-bitstring-4-0-0/6471/1>
xrguerin announced
──────────────────
Features
╌╌╌╌╌╌╌╌
• Add support for let bindings introduced in 4.08
• Switch to PPXLIB
Deprecations
╌╌╌╌╌╌╌╌╌╌╌╌
As PPXLIB requires `ocaml >= 4.04' support for earlier versions has
been dropped.
Breaking changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release splits the library from the PPX to reduce runtime
dependencies. Projects using the PPX from bitstring will need to also
depends on ppx_bitstring from now on.
Rudi Grinberg added
───────────────────
The project is hosted [here] for those who are interested.There's also
some excellent [docs]
[here] <https://github.com/xguerin/bitstring>
[docs] <https://bitstring.software/documentation/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 28846 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-08 13:11 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-09-08 13:11 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 29657 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of September 01 to
08, 2020.
Table of Contents
─────────────────
OCaml 4.11.1: early bugfix release
textmate-language 0.1.0
Batteries v3.1.0
Job offer in Paris - Be Sport
Some SIMD in your OCaml
A PPX Rewriter approach to ocaml-migrate-parsetree
telltime - when is when exactly?
Ocamlunit emacs minor-mode
Sihl 0.1.0
promise_jsoo 0.1.0
Other OCaml News
Old CWN
OCaml 4.11.1: early bugfix release
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-4-11-1-early-bugfix-release/6337/1>
octachron announced
───────────────────
A serious bug has been discovered last week in OCaml 4.11.0: explicit
polymorphic annotations are checked too permissively. Some incorrect
programs (possibly segfaulting) are accepted by the compiler in
4.11.0.
Programs accepted by OCaml 4.10 are unchanged.
We are thus releasing OCaml 4.11.1 as an early bugfix version. You
are advised to upgrade to this new version if you were using OCaml
4.11.0.
It is (or soon will be) available as a set of OPAM switches with
┌────
│ opam switch create 4.11.1
└────
and as a source download here:
<https://caml.inria.fr/pub/distrib/ocaml-4.11/>
This bug was introduced when making polymorphic recursion easier to
use. We are working on making the typechecker more robust and more
exhaustively tested to avoid such issues in the future.
Bug fixes:
╌╌╌╌╌╌╌╌╌╌
• [#9856], [#9857]: Prevent polymorphic type annotations from
generalizing weak polymorphic variables. (Leo White, report by
Thierry Martinez, review by Jacques Garrigue)
• [#9859], [#9862]: Remove an erroneous assertion when inferred
function types appear in the right hand side of an explicit :>
coercion (Florian Angeletti, report by Jerry James, review by Thomas
Refis)
[#9856] <https://github.com/ocaml/ocaml/issues/9856>
[#9857] <https://github.com/ocaml/ocaml/issues/9857>
[#9859] <https://github.com/ocaml/ocaml/issues/9859>
[#9862] <https://github.com/ocaml/ocaml/issues/9862>
Rwmjones then said
──────────────────
We've now got 4.11.1 in Fedora 33 & Fedora 34. No apparent problems
so far.
textmate-language 0.1.0
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-textmate-language-0-1-0/6339/1>
dosaylazy announced
───────────────────
I am pleased to announce [textmate-language 0.1.0]. Textmate-language
is a library for tokenizing code using TextMate grammars. Therefore,
it may be useful for implementing syntax highlighters. Please report
any bugs or API inconveniences you find.
[textmate-language 0.1.0]
<https://opam.ocaml.org/packages/textmate-language/textmate-language.0.1.0/>
Batteries v3.1.0
════════════════
Archive: <https://discuss.ocaml.org/t/batteries-v3-1-0/6347/1>
UnixJunkie announced
────────────────────
OCaml Batteries Included is a community-maintained extended standard
library for OCaml.
The latest API can be found here:
<https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>
This minor release adds support for OCaml 4.11. It has been available
in opam for some days.
Special thanks to all the contributors!
The changelog follows:
• Compatibility fixes for OCaml-4.11 [#962] (Jerome Vouillon)
• BatEnum: added combination [#518] (Chimrod, review by hcarty)
• fix benchmarks [#956] (Cedric Cellier)
• BatFile: added count_lines [#953] (Francois Berenger, review by
Cedric Cellier)
• BatArray: use unsafe_get and unsafe_set more often [#947] (Francois
Berenger, review by Cedric Cellier)
• fix some tests for ocaml-4.10.0 [#944] (kit-ty-kate)
• BatResult: BatPervasives.result is now equal to Stdlib.result
instead of sharing constructors without being the same type [#939],
[#957] (Clément Busschaert, Cedric Cellier).
[#962]
<https://github.com/ocaml-batteries-team/batteries-included/pull/962>
[#518]
<https://github.com/ocaml-batteries-team/batteries-included/pull/518>
[#956]
<https://github.com/ocaml-batteries-team/batteries-included/pull/956>
[#953]
<https://github.com/ocaml-batteries-team/batteries-included/pull/953>
[#947]
<https://github.com/ocaml-batteries-team/batteries-included/pull/947>
[#944]
<https://github.com/ocaml-batteries-team/batteries-included/pull/944>
[#939]
<https://github.com/ocaml-batteries-team/batteries-included/pull/939>
[#957]
<https://github.com/ocaml-batteries-team/batteries-included/pull/957>
Job offer in Paris - Be Sport
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-offer-in-paris-be-sport/6355/1>
Vincent Balat announced
───────────────────────
Be Sport is looking to hire an OCaml developer with skills in
• Mobile/web feature design
• Team management
• Use of Social networks
She/he will take part in the development of our Web and mobile apps,
entirely written in OCaml with Ocsigen, and participate in reflections
on features.
Please contact me for more information or send an email to
jobs@besport.com.
Some SIMD in your OCaml
═══════════════════════
Archive: <https://discuss.ocaml.org/t/some-simd-in-your-ocaml/6367/1>
Anmol Sahoo announced
─────────────────────
Fresh from a weekend of hacking, I would like to share some results of
an experiment I conducted of creating a library for exposing Intel
AVX2 intrinsics to OCaml code. AVX2 is an instruction set subset that
adds data-parallel operations in hardware.
I chose to fork the amazing [bigstringaf] library and modified it. You
can find the additions to the code here - [bigstringaf_simd].
[bigstringaf] <https://github.com/inhabitedtype/bigstringaf>
[bigstringaf_simd]
<https://github.com/anmolsahoo25/bigstringaf/blob/8df94c4fb5607317ee9634611784eea65368a270/lib/bigstringaf_simd.mli#L287>
Overview
╌╌╌╌╌╌╌╌
Given a type `Bigstring.t' (1 dimensional byte arrays) there now exist
functions such as -
┌────
│ val cmpeq_i8 : (t * int) -> (t * int) -> (t * int) -> unit
└────
So `cmpeq_i8 (x,o1) (y,o2) (z,03)' will compare 32 bytes starting at
`o1' and `o2' from `x' and `y' respectively and store the result in
`z' at `o3'.
Why?
╌╌╌╌
This was mainly an exercise in curiosity. I just wanted to learn
whether something like this is viable. I also want to see if adding
some type-directed magic + ppx spells can let us write data parallel
code much more naturally similar to what `lwt / async' did for async
code.
At the same time, you might ask - why not use something like Owl
(which already has good support for data-parallel operations)? Apart
from the fact that such libraries are oriented towards numerical code,
I would also like to explore if we can operate directly on OCaml types
and cast them into data parallel algorithms. Like how `simdjson'
pushed the boundaries of JSON parsing, it would be nice to port
idiomatic code to data-parallel versions in OCaml. Can we, at some
point, have generic traversals of data-types, which are actually
carried out in a data-parallel fashion?
Does it work?
╌╌╌╌╌╌╌╌╌╌╌╌╌
Given the limitation of the current implementation (due to foreign
function calls into C), I still found some preliminary results to be
interesting! Implementing the `String.index' function, which returns
the first occurence of a char, the runtime for finding an element at
the `n-1' position in an array with `320000000' elements is -
┌────
│ serial: 1.12 seconds
│ simd: 0.72 seconds (1.5x)
└────
I still have to do the analysis what the overhead of the function call
into C is (even with `[@@noalloc]'!
Future directions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
It would be interesting to see, if we can create a representation
which encapsulates the various SIMD ISA's such as AVX2, AVX512, NEON,
SVE etc. Further more, it would be really interesting to see if we can
use ppx to automatically widen `map` functions to operate on blocks of
code, or automatically cast data types in a data parallel
representation.
Disclaimer
╌╌╌╌╌╌╌╌╌╌
This was mostly a hobby project, so I cannot promise completing any
milestones or taking feature requests etc. I definitely do not
recommend using this in production, because of the lack of testing
etc.
A PPX Rewriter approach to ocaml-migrate-parsetree
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-ppx-rewriter-approach-to-ocaml-migrate-parsetree/6369/1>
Chet Murthy announced
─────────────────────
TL;DR
╌╌╌╌╌
Based on `camlp5' and the `pa_ppx' PPX rewriters, I've written a new
one, `pa_deriving_plugins.rewrite', that automates almost all the work
of writing a migration from one version of OCaml's AST to another.
1. It took a few days (b/c of laziness) to write the initial PPX
rewriter
2. A day to get 4.02->4.03 AST migration working
3. a couple of hours to get 4.03->4.02 working
4. and a few more hours to get 4.03<->4.04 and 4.04<->4.05 working
At this point, I fully expect that the other version-pairs will not be
difficult.
You can find this code [warning: very much a work-in-progress] at
<https://github.com/chetmurthy/pa_ppx/tree/migrate-parsetree-hacking>
The file `pa_deriving.plugins/pa_deriving_rewrite.ml' contains the
source for the PPX rewriter.
The directory `pa_omp' contains the migrations, typically named
`rewrite_NNN_MMM.ml'.
A slightly longer-winded explanation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If you think about it, `ppx_deriving.map' isn't so different from what
we need for `ocaml-migrate-parsetree'. `ppx_deriving.map', from a
type definition for ~ 'a t~, will automatically generate a function
┌────
│ map_t : ('a -> 'b) -> 'a t -> 'b t
└────
If you think about it, if we could just substitute our own type for
the second occurrence of `t' (somehow …. yeah *grin*) then it would be
almost like what we want for o-m-p, yes?
With 11 versions of the Ocaml AST so far, maybe it's worth thinking
about how to automate more of the migration task. Also, since so much
of it is type-structure-driven, one would think that it would be an
excellent opportunity to apply PPX rewriting technology. *Indeed, one
might think that a good test of PPX rewriting, is the ability to
automate precisely such tasks.*
So what's hard about this migration task? Here are some issues (maybe
there are more):
1. the types are slightly differently-organized in different versions
of the AST. Types might move from one module to another.
2. sometimes new types are introduced and old ones disappear
3. constructor data-types may get new branches, or lose them
4. record-types may get new fields, or lose them
5. sometimes the analogous types in two consecutive versions are just
really, really different [but this is rare]: we need to supply the
code directly
6. when mapping from one version to another, sometimes features are
simply not mappable, and an error needs to be raised; that error
ought to contain an indication of where in the source that
offending feature was found
7. And finally, when all else fails, we might need to hack on the
migration code directly
But morally, the task is really straightforward (with problems listed
in-line):
1. use `ppx_import' to copy over types from each of the AST times of
each Ocaml version
• `ppx_import' works on `.cmi' files, and those have different
formats in different versions of Ocaml. Wouldn't it be nice if
it worked on `.mli' files, whose syntax (b/c OCaml is
well-managed) doesn't change much?
2. build a single OCaml module that has all the AST types in it (from
all the versions of OCaml)
• but without the form
┌────
│ type t = M.t = A of .. | B of ....
└────
that is, without the "type equation" that allows for a new
type-definition to precisely repeat a previous one.
3. Then use `ppx_import' against this single module to construct a
recursive type-declaration list of all the AST types for a
particular version of OCaml, and apply a "souped-up" version of
ppx_deriving.map to it, to map the types to *another* version of
the AST types.
• but `ppx_deriving.map' doesn't do this today, and besides, it
would have to provide a bunch of "escape hatches" for all the
special-cases I mentioned above.
But this is in principle doable, and it has the nice feature that all
the tedious boilerplate is mechanically-generated from
type-definitions, hence likely to not contain errors (assuming the PPX
rewriter isn't buggy).
So I decided to do it, and this little post is a result.
Discussion
╌╌╌╌╌╌╌╌╌╌
I think this is a quite viable approach to writing
`ocaml-migrate-parsetree', and I would encourage the PPX community to
consider it. One of the nice things about this approach, is that it
relies *heavily* on PPX rewriting itself, to get the job done. I
think one of the important things we've learned in programming
languages research, is that our tools need to be largely sufficient to
allow us to comfortably implement those same tools. It's a good test
of the PPX infrastructure, to see if you can take tedious tasks and
automate them away.
I'm not going to describe anymore of how this works, b/c I'd rather
get the rest of the migrations working, start figuring out how to
test, and get this code integrated with camlp5.
But for anybody who's interested, I'd be happy to interactively
describe the code and walk them thru how it works.
Louis Roché then asked
──────────────────────
For a person who hasn't digged into OMP, can you explain how it is
different from what is done currently? Because the idea I had of OMP
is basically what you describe, a set of functions transformation an
AST from vX to vX-1 and vX+1. So I am obviously missing something.
Chet Murthy replied
───────────────────
Yes, you're right: imagine a series of modules M2…M11. Each declares
the same set of types, but with different definitions, yes? Then
you'd have migration modules, `migrate_i_j' (j=i+1 or j=i-1) that have
functions that convert between the analogously-named types. The
entire question is: how are these functions implemented? By hand?
With significant mechanized support? They can't be implemented
fully-mechanically, because there are decisions to be made about how
to bridge differences in type-definitions. For instance, look at the
4.02 type `label' and the 4.03 type `arg_label'. Sometimes these are
analogous (and sometimes they're not). When they're analogous, the
code that converts between -cannot- be automatically inferred: a human
has to write it. But -most- of the code of these migration functions
can be inferred automatically from the type-definitions themselves.
And that's really all that my little experiment does: automatically
infer the migration code (most of the time) with some hints for those
cases where it's not possible to automatically infer.
Now, why would one do this? Well, two reasons:
1. it should be more maintainable to automatically generate most of
the code from types, and it should be quicker to bring online a
migration for a new version of the Ocaml AST.
2. this should be a good test of PPX rewriting. That is, if we're
going to build a macro-preprocessing support system, shouldn't it
be able to make solving such straightforward, but very tedious,
problems much, much easier?
Chet Murthy then added
──────────────────────
I forgot to add a third reason why this PPX-rewriter-based approach is
better:
1. If you look at ocaml-migrate-parsetree "migrations", you'll find
that they're almost all boilerplate code. But sprinkled
here-and-there, is actual logic, actual decisions about how to come
up with values for new fields, about which fields, when non-trivial
(e.g. not "[]") should lead to migration-failure, etc. It is this
code, that is the actual meat of the migration, and it's not at all
obvious, when sprinkled thru the mass of mechanically-produclble
boilerplate.
A mechanized production of that boilerplate would mean that we
retained explicitly only this nontrivial code, and hence for
maintenance we could focus on it, and make sure it does the right
thing.
Josh Berdine asked
──────────────────
Figuring out ways to make maintaining this stuff more efficient would
be great! One aspect that isn't clear to me is how this approach
compares to the process currently used to generate the omp code. I
haven't done it myself, but at first glance the tools to generate the
omp code (e.g. gencopy) seem to also accurately be describable as
heavily using ppx infrastructure in order to implement the map code
from one version to another. Is there an executive summary that
compares and contrasts that and this proposal?
Chet Murthy replied
───────────────────
From the README, gencopy is used to generate a prototype file for each
migration, and then a human goes in and fixes up the code. A way to
put my point is: gencopy should be provided the fixups in some compact
form, and apply them itself.
telltime - when is when exactly?
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-telltime-when-is-when-exactly/6372/1>
Darren announced
────────────────
I'm happy to announce release of [telltime] 0.0.1, a small cli tool
for interacting with Daypack-lib (a schedule, time, time slots
handling library) components.
It primarily answers time related queries, with support for union
(`||'), intersect (`&&') and "ordered select" (`>>', explanation of
this is at the bottom).
The query language, time expression, aims to mimic natural language,
but without ambiguity. The grammar is only documented in the online
demo [here] at the moment.
Some examples copied from the README are as follows.
[telltime] <https://github.com/daypack-dev/telltime>
[here] <https://daypack-dev.github.io/time-expr-demo/>
Search for time slots matching Daypack time expression
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
"Hm, I wonder what years have Febuary 29th?"
┌────
│ $ telltime search --time-slots 5 --years 100 "feb 29 00:00"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 03 19:24:15
│
│ Matching time slots (in above time zone):
│ [2024 Feb 29 00:00:00, 2024 Feb 29 00:00:01)
│ [2028 Feb 29 00:00:00, 2028 Feb 29 00:00:01)
│ [2032 Feb 29 00:00:00, 2032 Feb 29 00:00:01)
│ [2036 Feb 29 00:00:00, 2036 Feb 29 00:00:01)
│ [2040 Feb 29 00:00:00, 2040 Feb 29 00:00:01)
└────
"Would be handy to know what this cron expression refers to"
┌────
│ $ telltime search --time-slots 5 "0 4 8-14 * *"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 06 17:39:56
│
│ Matching time slots (in above time zone):
│ [2020 Sep 08 04:00:00, 2020 Sep 08 04:01:00)
│ [2020 Sep 09 04:00:00, 2020 Sep 09 04:01:00)
│ [2020 Sep 10 04:00:00, 2020 Sep 10 04:01:00)
│ [2020 Sep 11 04:00:00, 2020 Sep 11 04:01:00)
│ [2020 Sep 12 04:00:00, 2020 Sep 12 04:01:00)
└────
"I have a bunch of time ranges, but some of them overlap, and they are
not in the right order. If only there is a way to combine and sort
them easily."
┌────
│ $ telltime search --time-slots 1000 "2020 . jan . 1, 10, 20 . 13:00 to 14:00 \
│ || 2019 dec 25 13:00 \
│ || 2019 dec 25 10am to 17:00 \
│ || 2020 jan 5 10am to 1:30pm \
│ || 2020 . jan . 7 to 12 . 9:15am to 2:45pm"
│ Searching in time zone offset (seconds) : 36000
│ Search by default starts from (in above time zone) : 2020 Sep 06 18:01:12
│
│ Matching time slots (in above time zone):
│ [2019 Dec 25 10:00:00, 2019 Dec 25 17:00:00)
│ [2020 Jan 01 13:00:00, 2020 Jan 01 14:00:00)
│ [2020 Jan 05 10:00:00, 2020 Jan 05 13:30:00)
│ [2020 Jan 07 09:15:00, 2020 Jan 07 14:45:00)
│ [2020 Jan 08 09:15:00, 2020 Jan 08 14:45:00)
│ [2020 Jan 09 09:15:00, 2020 Jan 09 14:45:00)
│ [2020 Jan 10 09:15:00, 2020 Jan 10 14:45:00)
│ [2020 Jan 11 09:15:00, 2020 Jan 11 14:45:00)
│ [2020 Jan 12 09:15:00, 2020 Jan 12 14:45:00)
│ [2020 Jan 20 13:00:00, 2020 Jan 20 14:00:00)
└────
Get exact time after some duration from now
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
┌────
│ $ telltime from-now "1 hour"
│ Now : 2020-09-03 15:53:29
│ Duration (original) : 1 hour
│ Duration (normalized) : 1 hours 0 mins 0 secs
│ Now + duration : 2020-09-03 16:53:29
└────
┌────
│ $ telltime from-now "1.5 days 2.7 hours 0.5 minutes"
│ Now : 2020-09-03 15:55:43
│ Duration (original) : 1.5 days 2.7 hours 0.5 minutes
│ Duration (normalized) : 1 days 14 hours 42 mins 30 secs
│ Now + duration : 2020-09-05 06:38:13
└────
Difference between ordered select and union
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`s1 >> s2' is similar to `s1 || s2', but `>>' picks between s1 and s2
in a round robin fashion, instead of just picking the smallest between
two.
One specific differing case would be when the search starts at 4pm
today, `3pm || 5pm' would return 5pm today and 3pm tomorrow, and so
on, while `3pm >> 5pm' would return 3pm tomorrow and 5pm tomorrow (a
5pm is only picked after a 3pm has been picked already).
Ocamlunit emacs minor-mode
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocamlunit-emacs-minor-mode/6373/1>
Manfred Bergmann announced
──────────────────────────
Here is a first version of this plugin that allows running `dune test'
with an Emacs key stroke. It shows the test result in a separate
buffer and a simple colorized status 'message'.
<https://github.com/mdbergmann/emacs-ocamlunit>
While it is possible to run `dune' in 'watch' mode I'd like to
manually run tests.
I didn't find a way to specify individual test modules in `dune'. Is
that possible?
Sihl 0.1.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-sihl-0-1-0/6374/1>
jerben announced
────────────────
I am happy to announce this milestone release of Sihl, a web framework
for OCaml.
Github: <https://github.com/oxidizing/sihl>
opam: <http://opam.ocaml.org/packages/sihl/>
Sihl is really just a collection of services that can be plugged into
each other and a tiny core that knows how to start them. The goal is
to take care of infrastructure concerns so you can focus on the
domain.
After many iterations, the API is in a shape where we dare to show it
to you :slight_smile: It is still under heavy development so expect
breakage without a major version bump. However, we just finished
migrating a project from Reason on NodeJS to OCaml on Sihl, so we use
it in production.
We provide service implementations that were useful to us so far. In
the future we want to provide many more to cover all kinds of
needs. (PRs are always welcome!)
Any feedback is greatly appreciated, thanks! :)
jerben then added
─────────────────
Here is an example of a tiny Sihl app:
┌────
│ module Service = struct
│ module Random = Sihl.Utils.Random.Service
│ module Log = Sihl.Log.Service
│ module Config = Sihl.Config.Service
│ module Db = Sihl.Data.Db.Service
│ module MigrationRepo = Sihl.Data.Migration.Service.Repo.MariaDb
│ module Cmd = Sihl.Cmd.Service
│ module Migration = Sihl.Data.Migration.Service.Make (Cmd) (Db) (MigrationRepo)
│ module WebServer = Sihl.Web.Server.Service.Make (Cmd)
│ module Schedule = Sihl.Schedule.Service.Make (Log)
│ end
│
│ let services : (module Sihl.Core.Container.SERVICE) list =
│ [ (module Service.WebServer) ]
│
│ let hello_page =
│ Sihl.Web.Route.get "/hello/" (fun _ ->
│ Sihl.Web.Res.(html |> set_body "Hello!") |> Lwt.return)
│
│ let routes = [ ("/page", [ hello_page ], []) ]
│
│ module App = Sihl.App.Make (Service)
│
│ let _ = App.(empty |> with_services services |> with_routes routes |> run)
└────
promise_jsoo 0.1.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-promise-jsoo-0-1-0/6377/1>
Max LANTAS announced
────────────────────
Hello! I am announcing the first release of `promise_jsoo', a library
for JS promises in Js_of_ocaml.
<https://github.com/mnxn/promise_jsoo>
<https://opam.ocaml.org/packages/promise_jsoo/>
The library has bindings to the core `Promise' methods as well as
helper functions that make it easier to deal with a `Promise' of an
`option' or `result'. It is also possible to use this library with
[gen_js_api] to make for an easier JavaScript binding experience
Inspired by [aantron/promise], this library also uses indirection
internally when handling nested promises in order to ensure that the
bindings are type safe.
This project is part of ongoing work to port [vscode-ocaml-platform]
to Js_of_ocaml.
Generated documentation can be found [here].
[gen_js_api] <https://github.com/LexiFi/gen_js_api>
[aantron/promise]
<https://github.com/aantron/promise#discussion-how-reason-promise-makes-promises-type-safe>
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[here]
<https://mnxn.github.io/promise_jsoo/promise_jsoo/Promise/index.html>
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Announcing Signals and Threads, a new podcast from Jane Street]
[OCaml Planet] <http://ocaml.org/community/planet/>
[Announcing Signals and Threads, a new podcast from Jane Street]
<https://blog.janestreet.com/announcing-signals-and-threads-index/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 48472 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-01 7:55 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-09-01 7:55 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15200 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 25 to
September 01, 2020.
Table of Contents
─────────────────
Writing bindings for Google Apps Script (GAS)
What the Jane Street interns have wrought
a small library for shell/AWK/Perl-like scripting
letters 0.2.0
raylib-ocaml 0.1.0
OCaml Workshop 2020 Online Conference is live now
Other OCaml News
Old CWN
Writing bindings for Google Apps Script (GAS)
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/writing-bindings-for-google-apps-script-gas/6293/1>
Danielo Rodríguez announced
───────────────────────────
Thanks to the help of this community I successfully completed a crazy
idea: To write some ocaml functions to use inside [Google Apps Script]
for a small stupid spreadsheet that I had.
The way it works now is by having a main index.js file that calls the
Ocaml functions that are available under a global Lib
namespace. Everything is bundled using parcel and the Idea was to use
as few JS code as possible. Because it was easier than I expected I
decided to go one step further and write some bindings for the GAS
functions I was using and reduce the glue JS code even more.
This are the bindings that I wrote so far. They work, but are not
usable inside Ocaml yet.
┌────
│ type spreadsheet
│ type sheet
│ type range
│ external getActiveSpreadsheet : unit -> spreadsheet = "getActiveSpreadsheet" [@@bs.val][@@bs.scope
│ "SpreadsheetApp"]
│ external getSheets : spreadsheet -> sheet array = "getSheets" [@@bs.send]
│ external getSheetByName : spreadsheet -> string -> sheet = "getSheetByName" [@@bs.send]
│ external getDataRange : sheet -> range = "getDataRange" [@@bs.send]
│ external getValues : range -> 'a array array = "getValues" [@@bs.send]
└────
My doubt are on the edges. When it is just obscure GAS stuff I have no
doubt, abstract types and functions to interact with them. Is when a
GAS function returns data where I have doubts. Usually they are just
arrays of arrays of Numbers or Strings. In the example above, the last
definition says that you will get an array of arrays of `'a', but that
is not true because it will be an array of "stuff" (strings, numbers,
floats). How should I type it in a way that it's flexible but not
cumbersome? For example, I don't think using a functor will help
because you will need to create a functor for every possible return
type, in my case if you have 3 sheets with 3 different shapes, you
will need 3 functors. An alternative that I have used was to provide
some helper functions to convert from JS to Ocaml types and then
unwrap the Ocaml types, like the example I'm doing with
Number_or_string. This is nothing serious and I will just add the
bindings that I may need for now, but I want to hear what the
community (and potential users) thinks.
If anyone is interested in taking a look on the project, it is here:
<https://github.com/danielo515/ElectronicProjectsSpreadsheet>
[Google Apps Script] <https://developers.google.com/apps-script>
Matthieu Dubuget said
─────────────────────
Not answering directly to your question, sorry.
But here is a binding I have been using for around 4 years:
<https://dubuget.fr/gitea/matthieu/ocaml-google-app.git>.
Hongbo Zhang also replied
─────────────────────────
For return type polymorphism, you can use GADT with bs.ignore, the
rough idea:
┌────
│ type 'a t = Int : int t | String : string t
│ external f : ('a t [@bs.ignore]) -> ... -> 'a = "xx"
└────
I read discuss.ocaml.org from time to time, but checks
<https://forum.rescript-lang.org/> daily where you can get a quick
answer
What the Jane Street interns have wrought
═════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/what-the-jane-street-interns-have-wrought/6294/1>
Yaron Minsky announced
──────────────────────
I thought folks here might find this interesting:
<https://blog.janestreet.com/what-the-interns-have-wrought-2020/>
The post summarizes three of the intern projects that happened this
summer at Jane Street. It might be interesting if you're looking for
an internship (or know someone who is), or if you're interested in any
of the underlying tech. For example, if there's significant interest
in a library for writing OCaml, we'd be more likely to open-source it.
a small library for shell/AWK/Perl-like scripting
═════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-08/msg00021.html>
Oleg announced
──────────────
Some time ago Chet Murthy asked about writing shell-like scripts in
OCaml. Prompted by it, I also want to report on my experience and
announce a small library that made it pleasant to do
shell/AWK/Perl-like scripting in OCaml.
The library is available at
<http://okmij.org/ftp/ML/myawk/0README.dr>
and consists of two small ML files, myawk.ml and strings.ml. The
latter collects general-purpose string operations, more convenient
than those in Stdlib.String. The rest of that web directory contains
half a dozen sample scripts with comments.
Here is the first example: a typical AWK script, but written in OCaml:
┌────
│ #!/bin/env -S ocaml
│
│ #load "myawk.cma"
│ open Myawk open Strings
│ let hash = string_of_int <|> Hashtbl.hash
│ ;;
│ (* Sanitize the files originally used by join1.ml and join2.ml
│ The files are made of space-separated fields; the first field is the
│ key. It is sensitive; but because it is a key it can't be replaced with
│ meaningless garbage. We obfuscate it beyond recognition. The third field
│ is obfuscated as well. The second and fourth can be left as they are,
│ and the fifth, if present, is replaced with XXX
│
│ The script is a proper filter: reads from stdin, writes to stdout
│ *)
│
│ for_each_line @@ map words @@ function (f1::f2::f3::f4::rest) ->
│ print [hash f1; f2; hash f3; f4; if rest = [] then "" else "XXX"]
│ ;;
└────
Here <|> is a function composition. I wish it were in Stdlib. The real
example, used in real life, was performing a database join
┌────
│ SELECT T2.* from Table1 as T1, Table2 as T2 where T1.f1 = T2.f1
└────
where Table1 and Table2 are text files with space-separated column
values. Table1 is supposed to be fed to stdin:
┌────
│ let () =
│ for_each_line @@ map words @@
│ map_option (function (x::_) -> Some x | _ -> None) @@
│ (ignore <|> shell "grep %s table1.txt")
└────
It is a typical rough-and-dirty script. Alas, it was too rough: I was
so excited that it typechecked and worked the first time, that I
didn't look carefully at the output and overlooked what I was looking
for (resulting in an unneeded hassle and apology). I should have
queried exactly for what I wanted:
┌────
│ SELECT T1.f1, T1.f4 FROM Table1 as T1, Table2 as T2
│ WHERE T1.f1 = T2.f1 AND T1.f3 <> "3"
└────
which is actually easy to write in myawk (probably not so in AWK
though)
┌────
│ let () =
│ for_each_line ~fname:"table2.txt" @@ map words @@
│ map_option (function (w::_) -> Some w | _ -> None) @@
│ fun w ->
│ for_each_line ~fname:"table1.txt" @@ map words @@
│ map_option (function
│ (x::f2::f3::f4::_) when x = w && f4 <> "3" -> Some [x;f4] | _ -> None) @@
│ print
└────
This is the classical nested loop join. Chet Murthy might be pleased
to see the extensive use of the continuation-passing style. I was
apprehensive at first, but it turned out not to be a hassle.
The library has a few other examples, including case-branching and
rewriting a real AWK script from the OCaml distribution.
Finally, let's compare with shell scripts. The example below doesn't
show off the library, but it does show the benefits of OCaml for
scripting. The original shell script is a sample GIT commit hook,
quoted in the comments:
┌────
│ (*
│ From GIT's sample hooks:
│ ANY-GIT-REPO/.git/hooks/commit-msg.sample
│
│ # Called by "git commit" with one argument, the name of the file
│ # that has the commit message. The hook should exit with non-zero
│ # status after issuing an appropriate message if it wants to stop the
│ # commit. The hook is allowed to edit the commit message file.
│
│ # This example catches duplicate Signed-off-by lines.
│
│ test "" = "$(grep '^Signed-off-by: ' "$1" |
│ sort | uniq -c | sed -e '/^[ ]*1[ ]/d')" || {
│ echo >&2 Duplicate Signed-off-by lines.
│ exit 1
│ }
│
│ *)
│ module H = Hashtbl
│
│ let commit_msg = Sys.argv.(1)
│ let ht = H.create 5
│ let () =
│ for_each_line ~fname:commit_msg @@ fun l ->
│ if is_prefix "Signed-off-by: " l <> None then begin
│ if H.find_opt ht l <> None then begin
│ prerr_endline "Duplicate Signed-off-by lines.";
│ exit 1
│ end else
│ H.add ht l ()
│ end
└────
Although the OCaml script seems to have more characters, one doesn't
need to type them all. Scripts like that are meant to be entered in an
editor; even ancient editors have completion facilities.
Looking at the original shell script brings despair, and drives me
right towards Unix Haters. Not only the script is algorithmically
ugly: if a duplicate signed-off line occurs near the beginning, we can
report it right away and stop. We don't need to read the rest of the
commit message, filter it, sort it, precisely count all duplicates and
filter again. Not only the script gratuitously wastes system resources
(read: the laptop battery) by launching many processes and allocating
communication buffers. Mainly, the script isn't good at its primary
purpose: it isn't easy to write and read. Pipeline composition of
small stream processors is generally a good thing – but not when each
stream processor is written in its own idiosyncratic
language. Incidentally, I have doubts about the script: I think that
quotes around $1 are meant to be embedded; but why they are not
escaped then? Probably it is some edge case of bash, out of several
0thousands.
In contrast, OCaml script does exactly what is required, with no extra
work. Everything is written in only one language.
letters 0.2.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-letters-0-2-0/6307/1>
Miko announced
──────────────
Getting this release done took a bit longer than expected due to some
real life factors, but finally here it is.
This one mainly focuses on the most requested features and
improvements like simplifying configuration around CA certificates,
provides some basic documentation and additionally adds support for
`multipart/alternative' emails with combined HTML and plain text
content.
jerben then added
─────────────────
Link to Github: <https://github.com/oxidizing/letters>
raylib-ocaml 0.1.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-raylib-ocaml-0-1-0/6313/1>
Tobias Mock announced
─────────────────────
I'd like to announce the first version of [raylib-ocaml], a binding to
the awesome [raylib] game development library. The release can be
found on opam as ["raylib"].
The bindings are nearly complete, as far as functions and types go,
but only a subset was tested so far. I will work on bringing more of
the numerous examples of the C version to OCaml in the future.
Currently, raylib-ocaml only works on Linux, but I plan to support
Windows (and possibly other targets) in the future.
Feel free to give it a spin and please report any issues you run into.
[raylib-ocaml] <https://github.com/tjammer/raylib-ocaml>
[raylib] <https://www.raylib.com/>
["raylib"] <https://opam.ocaml.org/packages/raylib/>
OCaml Workshop 2020 Online Conference is live now
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-workshop-2020-online-conference-is-live-now/6287/30>
Deep in this thread, Didier Wenzek announced
────────────────────────────────────────────
[OCaml 2020 All Videos]
[OCaml 2020 All Videos]
<https://www.youtube.com/playlist?list=PLKO_ZowsIOu5fHjRj0ua7_QWE_L789K_f>
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [BuckleScript Good and Bad News]
• [What the interns have wrought, 2020 edition]
• [Coq 8.12.0 is out]
[OCaml Planet] <http://ocaml.org/community/planet/>
[BuckleScript Good and Bad News]
<http://psellos.com/2020/08/2020.08.east-van-girls.html>
[What the interns have wrought, 2020 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2020/>
[Coq 8.12.0 is out] <https://coq.inria.fr/news/coq-8-12-0-is-out.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 34062 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-08-18 7:25 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-08-18 7:25 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7186 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 11 to 18,
2020.
Table of Contents
─────────────────
Ppx: omp 2.0.0 and next steps
Old CWN
Ppx: omp 2.0.0 and next steps
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231/1>
Jérémie Dimino announced
────────────────────────
quick summary:
• ocaml-migrate-parsetree 2.0.0 release
• you should add a upper bound in your dev repos
• ppxlib compatible version coming soon
• ppxlib is now the official ppx library supported by the OCaml
platform
Hi everyone,
As [previously announced], we are [releasing the version 2.0.0 of
ocaml-migrate-parsetree]. At the moment nothing is compatible with the
new version and we will soon release a version of ppxlib that is
compatible with it. If your project depends on
ocaml-migrate-parsetree, you should add a upper bound to your
development repository.
If you plan to use ocaml-migrate-parsetree 2.0.0 directly, please note
however that this is a transitory package. The technology implemented
by ocaml-migrate-parsetree will live on and hopefully find a new home
in the compiler repository proper. However, ocaml-migrate-parsetree as
a standalone project will eventually stop being maintained.
I am also taking the opportunity to announce that *ppxlib is the first
ppx library officially supported by the OCaml platform*, and the one
we recommend all ppx authors to use. It is the library that we plan to
maintain for the long term.
Other libraries such as `ppx_tools' or `ppx_tools_versioned' may
continue to be maintained by open source contributors, however they
will not be maintained by the OCaml platform and will not receive
updates from the platform when new compilers are released. Only ppxlib
will receive updates from the platform.
If you would like to port your project to use ppxlib and are
experiencing difficulties or have any question, please get in touch by
replying to this post or opening a ticket on
<https://github.com/ocaml-ppx/ppxlib>.
The overall plan described in this post is the result of various
discussions and/or collaborative effort between the following people:
@avsm, @ceastlund, @Drup, @gasche, @jeremiedimino, @kit-ty-kate,
@let-def, @NathanReb and @pitag.
[previously announced]
<https://discuss.ocaml.org/t/ocaml-migrate-parsetree-2-0-0/5991>
[releasing the version 2.0.0 of ocaml-migrate-parsetree]
<https://github.com/ocaml/opam-repository/pull/16999>
Next steps
╌╌╌╌╌╌╌╌╌╌
As soon as the new version of ppxlib is released, we will work towards
our next milestone. As a reminder, our current goal is to setup a ppx
ecosystem that is continously compatible with the trunk of OCaml. To
achieve that goal, we plan to add a stable API called "Astlib" on top
of the compiler libraries. To keep things sustainable on the compiler
side and increase flexibility, Astlib will be minimal and will be
targeted at ppxlib only rather than be a general API aimed at ppx
authors.
The difficulty of this API is that it must expose a stable interface
to the OCaml AST, which is composed of a large collection of data
types. To make it work, we plan to use the technology developed in
ocaml-migrate-parsetree; i.e. whole AST migration functions.
While we eventually want Astlib to live in the compiler repository, we
will initially develop it inside the ppxlib repository. Once it is
ready, we will submit it for inclusion in the compiler. Although, we
will keep a copy inside ppxlib for older versions of the compiler.
We also plan to setup a smooth workflow for compiler developers to
update Astlib when they change the development AST.
Once this is all done, we will be in a situation where the ppx
ecosystem is compatible with the trunk of OCaml at all time. And as a
result, new releases of the compiler will no longer break ppx packages
as long as they limit themselves to the ppxlib API.
Future
╌╌╌╌╌╌
While this work will make the ecosystem compatible with the trunk of
OCaml at all times, it will essentially move the backward
compatibility issue from the compiler to ppxlib.[1] This will already
give us a lot more flexibility as for instance a single version of
ppxlib can be compatible with a wide range of OCaml versions. However,
we recognise that it is not usual to ask a community to rely on an
unstable API.
We made this choice as a trade-off between sustainability and
complexity. Indeed, we want to maintain Astlib and Ppxlib over the
long term and the best way to make things sustainable is to use simple
and clear designs. While we do have solutions in our sleeves that
would provide a fully stable ppx API, these are much more complicated
to maintain and work with.
To mitigate this, we are setting up a Dune based workflow to upgrade
all ppx rewriters at once. So once the system is rolling and if your
ppx rewriters are up to date and using Dune, you should expect to
receive pull requests as we update ppxlib. This last part will take
some time to be fully rolling, so please bear with us :)
In any case, about a year after this new world is fully setup, we will
review the situation and decide whether it is sustainable or whether
we need to go all the way and mint a fully stable ppx API.
Timeline
╌╌╌╌╌╌╌╌
• today: ocaml-migrate-parsetree 2.0.0 is being released
• next week: a ppxlib compatible version is released
• December 2020: astlib is ready inside the ppxlib repository
• next OCaml release after that: astlib lives in the compiler
• September 2021: we review the situation and decide what to do next
[1]: At any given time the API of ppxlib refer to a single version of
the OCaml AST. In order to allow OCaml users to enjoy both ppx
rewriters and new language features, the version of the AST selected
by ppxlib needs to be bumped after each release of the compiler, which
is a breaking change that has the potential to break several ppx
packages. As a result, ppx packages will still need to be regularly
updated in order to stay compatible with the latest version of ppxlib.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18147 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-28 16:57 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-07-28 16:57 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 23258 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 21 to 28,
2020.
As I will be away with no internet next week, the next CWN will be on
August 11.
Table of Contents
─────────────────
Embedded ocaml templates
Proposal: Another way to debug memory leaks
Camlp5 (8.00~alpha01) and pa_ppx (0.01)
OCaml 4.11.0, third (and last?) beta release
Other OCaml News
Old CWN
Embedded ocaml templates
════════════════════════
Archive: [https://discuss.ocaml.org/t/embedded-ocaml-templates/6124/1]
Emile Trotignon announced
─────────────────────────
I am very happy to announce the release of ocaml-embedded-templates.
This is a tool similar to camlmix, but camlmix was not updated for 7
years, and there is no easy way to handle a lot of templates (my
command takes a directory as an argument and generate an ocaml module
by going through the directory recursively) I also choosed to use a
syntax similar to EJS, and there is a ppx for inline EML.
You can check it out here :
[https://github.com/EmileTrotignon/embedded_ocaml_templates]
Here is a more extensive exemple of what can be done with this :
[https://github.com/EmileTrotignon/resume_of_ocaml] (This project
generate my resume/website in both latex and html).
This is my first opam package : feedback is very much welcome.
Proposal: Another way to debug memory leaks
═══════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/proposal-another-way-to-debug-memory-leaks/6134/1]
Jim Fehrle said
───────────────
`memprof' helps you discover where memory was allocated, which is
certainly useful. However, that may not be enough information to
isolate a leak. Sometimes you'd like to know what variables refer to
excessive amounts of memory.
For this, you'd want to examine all the garbage collection roots and
report how much memory is used by each. This is useful information if
you can map a GC root back to a source file and variable.
I prototyped code to do that to help with Coq bug
[https://github.com/coq/coq/issues/12487]. It localized several leaks
enough across over 500 source files so that we could find and fix
them. But my prototype code is a bit crude. I'd like to clean it up
and submit it as a PR. Since this could be done in various ways, I
wanted to get some design/API feedback up front rather than maybe
doing some of it twice. Also I'd like to confident that such a PR
would be accepted and merged in a reasonable amount of time–otherwise
why bother.
[caml_do_roots] shows how to access the GC roots. There are several
types of roots:
• global roots, corresponding to top-level variables in source files
• dynamic global roots
• stack and local roots
• global C roots
• finalized values
• memprof
• hook
*API (in Gc):*
┌────
│ val print_global_reachable : out_channel -> int -> unit
└────
Prints a list to `out_channel' of the global roots that reach more
than the specified number of words. Each item shows the number of
reachable words, the associated index of the root in the `*glob' for
that file and the name of the source file.
Something like this (but with only filenames rather than pathnames):
┌────
│ 102678 field 17 plugins/ltac/pltac.ml
│ 102730 field 18 plugins/ltac/pltac.ml
│ 164824 field 20 plugins/ltac/tacenv.ml
│ 1542857 field 26 plugins/ltac/tacenv.ml
│ 35253743 field 65 stm/stm.ml
│ 35201913 field 8 vernac/vernacstate.ml
│ 8991864 field 24 vernac/library.ml
│ 112035 field 8 vernac/egramml.ml
│ 6145454 field 84 vernac/declaremods.ml
│ 6435878 field 89 vernac/declaremods.ml
└────
I would use ELF information in the binary file to map from `*glob'
back to a filename. For example, the address symbol of the entry
`camlTest' corresponds to `test.ml'. This would only work for binary
executables compiled with the `-g' option. It wouldn't work for
byte-compiled code. It would print an error message if it's not ELF
or not `-g'. Also, being a little lazy, how essential is it to
support 32-bit binaries? (Q: What happens if you have 2 source files
with the same name though in different directories? Would the symbol
table distinguish them?)
┌────
│ val get_field_index : Obj.t -> int
└────
Returns the `*glob' index number for the top-level variable (passed as
`Obj.repr var'). I expect there's no way to recover variable names
from the `*glob' index. In my experiments, it appeared that the
entries in `*glob' were in the same order as as the variable and
function declarations. This would let a developer do a binary search
in the code to locate the variable which it probably a necessity for
large, complex files such as Coq's `stm.ml'–3300 lines, 10+ modules
defined within the file. (I noticed that variables defined in modules
defined within the source file were not in `*glob'. I expect there is
a root for the module as a whole and that those variables can be
readily found within that root.)
This would need an extended explanation in `gc.mli'.
┌────
│ val print_stack_reachable : out_channel -> int -> unit
└────
Prints a backtrace to `out_channel' that also shows which roots for
each frame reach more than the specified number of words. (I'd keep
the "item numbers" since there's no way to translate them to variables
and they might give some clues.)
┌────
│ Called from file "tactics/redexpr.ml" (inlined), line 207, characters 29-40
│ 356758154 item 0 (stack)
│ Called from file "plugins/ltac/tacinterp.ml", line 752, characters 6-51
│ 17646719 item 0 (stack)
│ 119041 item 1 (stack)
│ Called from file "engine/logic_monad.ml", line 195, characters 38-43
│ 119130 item 0 (stack)
│ 373378237 item 1 (stack)
└────
As it turns out, 90% of the memory in Coq issue mentioned above is
reachable only from the stack.
I didn't consider the other types of roots yet, which I don't fully
understand, such as local roots. Just covering global and stack roots
seems like a good contribution. Dynamic global roots may be easy to
add if they are otherwise similar to global roots. For the others I
could print the reachable words, but I don't know how to direct the
developer to look at the relevant part of the code, especially if it's
in C code. I suppose `print_global_reachable' and
`print_stack_reachable' could be a single routine as well. That's
probably better.
Let me know your thoughts.
[caml_do_roots]
https://github.com/ocaml/ocaml/blob/80326033cbedfe59c0664e3912f21017e968a1e5/runtime/roots_nat.c#L399
Camlp5 (8.00~alpha01) and pa_ppx (0.01)
═══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-camlp5-8-00-alpha01-and-pa-ppx-0-01/6144/1]
Chet Murthy announced
─────────────────────
`Camlp5 (8.00~alpha01)' and `pa_ppx (0.01)'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I'm pleased to announce the release of two related projects:
1. [Camlp5]: version 8.00~alpha01 is an alpha release of Camlp5, with
full support for OCaml syntax up to version 4.10.0, as well as
minimal compatibility with version 4.11.0. In particular there is
full support for PPX attributes and extensions.
2. [pa_ppx]: version 0.01 is a re-implementation of a large number of
PPX rewriters (e.g. ppx_deriving (std (show, eq, map, etc), yojson,
sexp, etc), ppx_import, ppx_assert, others) on top of Camlp5, along
with an infrastructure for developing new ones.
This allows projects to combine the existing style of Camlp5 syntax
extension, with PPX rewriting, without having to jump thru hoops to
invoke camlp5 on some files, and PPX processors on others.
Camlp5 alone is not compatible with existing PPX rewriters: Camlp5
syntax-extensions (e.g. "stream parsers") would be rejected by the
OCaml parser, and PPX extensions/attributes are ignored by Camlp5
(again, without `pa_ppx'). `pa_ppx' provides Camlp5-compatible
versions of many existing PPX rewriters, as well as new ones, so that
one can use Camlp5 syntax extensions as well as PPX rewriters. In
addition, some of the re-implemented rewriters are more-powerful than
their original namesakes, and there are new ones that add interesting
functionality.
[Camlp5] https://github.com/camlp5/camlp5
[pa_ppx] https://github.com/chetmurthy/pa_ppx
For democratizing macro-extension-authoring in OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
TL;DR Writing OCaml PPX rewriters is *hard work*. There is a
complicated infrastructure that is hard to explain, there are multiple
such incompatible infrastructures (maybe these are merging?) and it is
hard enough that most Ocaml programmers do not write macro-extensions
as a part of their projects. I believe that using Camlp5 and pa_ppx
can make it easier to write macro-extensions, via:
1. providing a simple way of thinking about adding your extension to
the parsing process.
2. providing transparent tools (e.g. quotations) for
pattern-matching/constructing AST fragments
Explained below in [Macro Extensions with
Pa_ppx](#macro-extensions-with-pa_ppx).
◊ The original arguments against Camlp4
The original argument against using Camlp4 as a basis for
macro-preprocessing in Ocaml, had several points (I can't find the
original document, but from memory):
1. *syntax-extension* as the basis of macro-extension leads to brittle
syntax: multiple syntax extensions often do not combine well.
2. a different AST type than the Ocaml AST
3. a different parsing/pretty-printing infrastructure, which must be
maintained alongside of Ocaml's own parser/pretty-printer.
4. A new and complicated set of APIs are required to write syntax
extensions.
To this, I'll add
1. Camlp4 was *forked* from Camlp5, things were changed, and hence,
Camlp4 lost the contribution of its original author. Hence,
maintaining Camlp4 was always labor that fell on the Ocaml
team. [Maybe this doesn't matter, but it counts for something.]
◊ Assessing the arguments, with some hindsight
1. *syntax-extension* as the basis of macro-extension leads to brittle
syntax: multiple syntax extensions often do not combine well.
In retrospect, this is quite valid: even if one prefers and enjoys
LL(1) grammars and parsing, when multiple authors write
grammar-extensions which are only combined by third-party projects,
the conditions are perfect for chaos, and of a sort that
project-authors simply shouldn't have to sort out. And this chaos
is of a different form, than merely having two PPX rewriters use
the same attribute/extension-names (which is, arguably, easily
detectable with some straightforward predeclaration).
2. Camlp4/5 has a different AST type than the Ocaml AST
Over time, the PPX authors themselves have slowly started to
conclude that the current reliance on the Ocaml AST is fraught with
problems. The "Future of PPX" discussion thread talks about using
something like s-expressions, and more generally about a
more-flexible AST type.
3. a different parsing/pretty-printing infrastructure, which must be
maintained alongside of Ocaml's own parser/pretty-printer.
A different AST type necessarily means a different
parser/pretty-printer. Of course, one could modify Ocaml's YACC
parser to produce Camlp5 ASTs, but this is a minor point.
4. A new and complicated set of APIs are required to write syntax
extensions.
With time, it's clear that PPX has produced the same thing.
5. Maintaining Camlp4 was always labor that fell on the Ocaml team.
The same argument (that each change to the Ocaml AST requires work
to update Camlp5) can be made for PPX (specifically, this is the
raison d'etre of ocaml-migrate-parsetree). Amusingly, one could
imagine using ocaml-migrate-parsetree as the basis for making
Camlp5 OCaml-version-independent, too. That is, the "backend" of
Camlp5 could use ocaml-migrate-parsetree to produce ASTs for a
version of OCaml different from the one on which it was compiled.
Arguments against the current API(s) of PPX rewriting
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The overall argument is that it's too complicated for most OCaml
programmers to write their own extensions; what we see instead of a
healthy ecosystem of many authors writing and helping-improve PPX
rewriters, is a small number of rewriters, mostly written by Jane
Street and perhaps one or two other shops. There are a few big
reasons why this is the case (which correspond to the responses
above), but one that isn't mentioned is:
1. When the "extra data" of a PPX extension or attribute is
easily-expressed with the fixed syntax of PPX payloads, all is
`~well~' ok, but certainly not in great shape. Here's an example:
┌────
│ type package_type =
│ [%import: Parsetree.package_type
│ [@with core_type := Parsetree.core_type [@printer Pprintast.core_type];
│ Asttypes.loc := Asttypes.loc [@polyprinter fun pp fmt x -> pp fmt x.Asttypes.txt];
│ Longident.t := Longident.t [@printer pp_longident]]]
│ [@@deriving show]
└────
The expression-syntax of assignment is used to express type-expression
rewrites. And this is necesarily limited, because we cannot (for
example) specify left-hand-sizes that are type-expressions with
variables. It's a perversion of the syntax, when what we really want
to have is something that is precise: "map this type-expression to
that type-expression".
Now, with the new Ocaml 4.11.0 syntax, there's a (partial) solution:
use "raw-string-extensions" like `{%foo|argle|}'. This is the same as
`[%foo {|argle|}]'. This relies on the PPX extension to parse the
payload. But there are problems:
1. Of course, there's no equivalent `{@foo|argle|}' (and "@@", "@@@"
of course) for attributes.
2. If the payload in that string doesn't *itself* correspond to some
parseable Ocaml AST type, then again, we're stuck: we have to
cobble together a parser instead of being able to merely extend the
parser of Ocaml to deal with the case.
Note well that I'm not saying that we should extend the parsing rules
of the Ocaml language. Rather, that with an *extensible parser*
(hence, LL(1)) we can add new nonterminals, add rules that reference
existing nonterminals, and thereby get an exact syntax (e.g.) for the
`ppx_import' example above. That new nonterminal is used *only* in
parsing the payload – nowhere else – so we haven't introduced examples
of objection #1 above.
And it's not even very hard.
Macro Extensions with Pa_ppx
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The basic thesis of `pa_ppx' is "let's not throw the baby out with the
bathwater". Camlp5 has a lot of very valuable infrastructure that can
be used to make writing macro-preprocessors much easier. `pa_ppx'
adds a few more.
1. Quotations for patterns and expressions over all important OCaml
AST types.
2. "extensible functions" to make the process of recursing down the
AST transparent, and the meaning of adding code to that process
equally transparent.
3. `pa_ppx' introduces "passes" and allows each extension to register
which other extensions it must follow, and which may follow it;
then `pa_ppx' topologically sorts them, so there's no need for
project-authors to figure out how to order their PPX extension
invocations.
As an example of a PPX rewriter based on `pa_ppx', here's
[pa_ppx.here] from the `pa_ppx' tutorial. In that example, you'll see
that Camlp5 infrastructure is used to make things easy:
1. quotations are used to both build the output AST fragment, and to
pattern-match on inputs.
2. the "extensible functions" are used to add our little bit of
rewriter to the top-down recursion.
3. and we declare our rewriter to the infrastructure (we don't specify
what passes it must come before or after, since `pa_ppx.here' is so
simple).
[pa_ppx.here]
https://pa-ppx.readthedocs.io/en/latest/tutorial.html#an-example-ppx-rewriter-based-on-pa-ppx
Conclusion
╌╌╌╌╌╌╌╌╌╌
I'm not trying to convince you to switch away from PPX to Camlp5.
Perhaps, I'm not even merely arguing that you should use `pa_ppx' and
author new macro-extensions on it. But I *am* arguing that the
features of
1. quotations, with antiquotations in as many places as possible, and
hence, *in places where Ocaml identifiers are not permitted*.
2. facilities like "extensible functions", with syntax support for
them
3. a new AST type, that is suitable for macro-preprocessing, but isn't
merely "s-expressions" (after all, there's a reason we all use
strongly-typed languages)
4. an extensible parser for the Ocaml language, usable in PPX
attribute/extension payloads
are important and valuable, and a PPX rewriter infrastructure that
makes it possible for the masses to write their own macro-extensions,
is going to incorporate these things.
OCaml 4.11.0, third (and last?) beta release
════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-third-and-last-beta-release/6149/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is near. As one step further in this
direction, we have published a third and potentially last beta
release.
This new release fixes an infrequent best-fit allocator bug and an
issue with floating-point software emulation in the ARM EABI port. On
the ecosystem side, merlin is now available for this new version of
OCaml. The compatibility of the opam ecosystem with OCaml 4.11.0 is
currently good, and it should be possible to test this beta without
too much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta3.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta3.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands:
┌────
│ opam update
│ opam switch create ocaml-variants.4.11.0+beta3 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam update
│ opam switch create ocaml-variants.4.11.0+beta3+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
We would love to hear about any bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
Compared to the previous beta release, the exhaustive list of changes
is as follows:
Runtime:
╌╌╌╌╌╌╌╌
• [#9736], [#9749]: Compaction must start in a heap where all free
blocks are blue, which was not the case with the best-fit
allocator. (Damien Doligez, report and review by Leo White)
• + [*new bug fixes*] [#9316], [#9443], [#9463], [#9782]: Use typing
information from Clambda or mutable Cmm variables. (Stephen Dolan,
review by Vincent Laviron, Guillaume Bury, Xavier Leroy, and Gabriel
Scherer; temporary bug report by Richard Jones)
[#9736] https://github.com/ocaml/ocaml/issues/9736
[#9749] https://github.com/ocaml/ocaml/issues/9749
[#9316] https://github.com/ocaml/ocaml/issues/9316
[#9443] https://github.com/ocaml/ocaml/issues/9443
[#9463] https://github.com/ocaml/ocaml/issues/9463
[#9782] https://github.com/ocaml/ocaml/issues/9782
Manual and documentation:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9541]: Add a documentation page for the instrumented runtime;
additional changes to option names in the instrumented
runtime. (Enguerrand Decorne, review by Anil Madhavapeddy, Gabriel
Scherer, Daniel Bünzli, David Allsopp, Florian Angeletti, and
Sébastien Hinderer)
Entries marked with "+" were already present in previous alphas, but
they have been complemented by new bug fixes.
If you are interested by the list of new features, and the nearly
final list of bug fixes the updated change log for OCaml 4.11.0 is
available at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
[#9541] https://github.com/ocaml/ocaml/issues/9541
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-Clang 0.0.9 is out. Download it here.]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-Clang 0.0.9 is out. Download it here.]
http://frama-c.com/index.html
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 37178 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-21 14:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-07-21 14:42 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7349 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 14 to 21,
2020.
Table of Contents
─────────────────
Dune-release: version 1.4.0 released
Using AF_XDP sockets for high-performance packet processing in OCaml
Ubase 0.03
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
Old CWN
Dune-release: version 1.4.0 released
════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/dune-release-version-1-4-0-released/6103/1]
Sonja Heinze announced
──────────────────────
This post is about [dune-release], a tool that helps users release
their packages to Opam in a fast and organized manner. You can install
it via `opam install dune-release'.
On behalf of the dune-release team at Tarides, I'm happy to announce
the new dune-release [1.4.0 release]. The release includes two new
subcommands described below and a variety of bug fixes and user
experience improvements. In particular, we've put some work into
improving the error handling and reporting.
One of the new subcommands is `dune-release config' , which inspects
and edits dune-release's global configuration, such as git related,
opam related and github related data. For example, if you insert a
typo when being asked for your github id during your first release
with dune-release, you can correct it comfortably with that new
subcommand.
The other new subcommand is `dune-release delegate-info', which helps
users with an alternative release workflow to integrate dune-release
into it: imagine you want to use dune-release only for a couple of
things, such as tagging the distribution and creating the distribution
tarball and the documentation. In that case, now you can integrate
the work done by dune-release into your individual release workflow by
accessing the path to the created tarball etc via `dune-release
delegate-info'. It forms part of the broader change in progress
described in the following post:
[https://discuss.ocaml.org/t/replacing-dune-release-delegates/4767]
[dune-release] https://github.com/ocamllabs/dune-release/#readme
[1.4.0 release]
https://github.com/ocamllabs/dune-release/releases/tag/1.4.0
Using AF_XDP sockets for high-performance packet processing in OCaml
════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/using-af-xdp-sockets-for-high-performance-packet-processing-in-ocaml/6106/1]
suttonshire announced
─────────────────────
I just wanted to share a fun result from a project I've been hacking
on. [ocaml-xsk] is a binding to AF_XDP interface of libbpf.
AF_XDP is an address family in Linux for high-performance packet
processing. With an AF_XDP socket a packet bypasses most of the kernel
networking stack and is passed directly to userspace program.
Depending on the configuration packets can be passed from the NIC
without any data copies on either Rx or Tx. If you're interested in
this kind of stuff here are a couple very useful resources:
• [https://github.com/torvalds/linux/blob/master/Documentation/networking/af_xdp.rst]
• [https://github.com/xdp-project/xdp-tutorial/tree/master/advanced03-AF_XDP]
The cool part is that without installing large dependencies like DPDK
you can get packets into your program basically as fast as your NIC
can provide them! It turns out this is true even if your program is
written in OCaml. Using ocaml-xsk I could receive or transmit 64 byte
UDP packets at 14.8M packets per second. This is the limit for a
10Gb/s NIC.
I'm still trying to figure out the best interface for AF_XDP. There
are several resources to manage, and simple receive and transmit
operations actually require a few steps. But it's encouraging know
OCaml doesn't get in the way of packet throughput.
[ocaml-xsk] https://github.com/suttonshire/ocaml-xsk
Ubase 0.03
══════════
Archive: [https://discuss.ocaml.org/t/ann-ubase-0-03/6115/1]
sanette announced
─────────────────
I'm happy to announce the release of [ubase], a tiny library whose
only purpose is to remove diacritics (accents, etc.) from utf8-encoded
strings using the latin alphabet.
It was created after the discussion:
[https://discuss.ocaml.org/t/simplify-roman-utf8/4398].
It's now available from `opam':
`opam install ubase'
This also installs an executable that you may use in a shell, for
instance:
┌────
│ $ ubase "et grønt træ"
│ et gront trae
│
│ $ ubase Anh xin lỗi các em bé vì đã đề tặng cuốn sách này cho một ông người lớn.
│ Anh xin loi cac em be vi da de tang cuon sach nay cho mot ong nguoi lon.
└────
More info [here].
[ubase] https://github.com/sanette/ubase
[here] https://sanette.github.io/ubase/
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
═══════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-clangml-4-2-0-ocaml-bindings-for-clang-api-for-c-and-c-parsing/6123/1]
Thierry Martinez announced
──────────────────────────
We are happy to announce the new clangml 4.2.0 release. Clangml
provides bindings for all versions of Clang, from 3.4 to the not yet
released 10.0.1.
The library can be installed via opam: `opam install clangml' The
documentation is online:
[https://memcad.gitlabpages.inria.fr/clangml/]
This new release improves C++ support, including C++20 specific
constructs.
All Clang C/C++ attributes should now be supported. You may have a
look to the interface of the new auto-generated module [`Attributes'].
There is now a lazy version of the AST (`Clang.Lazy.Ast'): this is
useful to explore large ASTs efficiently (note that Clang parsing
itself can still be slow; the lazy part only concerns the conversion
into the `Clang.Lazy.Ast' datatypes).
[`Attributes']
https://memcad.gitlabpages.inria.fr/clangml/doc/clangml/Clang__/Attributes/
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 18807 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-14 9:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-07-14 9:54 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 7882 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of July 07 to 14,
2020.
Table of Contents
─────────────────
OCaml 4.11.0, second beta release
letters - simple client abstractions for sending emails over SMTP
A question about Ocaml
Alcotest 1.2.0
Set up OCaml 1.1.0
Old CWN
OCaml 4.11.0, second beta release
═════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-second-beta-release/6063/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is approaching. As one step further in
this direction, we have published a second beta release. This new
release fixes an MSVC-specific runtime issue.
The compatibility of the opam ecosystem with OCaml 4.11.0 is currently
quite good with only 7 packages not currently available, and it should
be possible to test this beta without too much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta2.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta2.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands:
┌────
│ opam switch create ocaml-variants.4.11.0+beta2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+beta2+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these: afl, flambda, fp,
fp+flambda
We would love to hear about any bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
If you are interested by the list of new features, and the on-going
list of bug fixes the updated change log for OCaml 4.11.0 is available
at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
Compared to the previous beta release, the exhaustive list of changes
is as follows:
Runtime
╌╌╌╌╌╌╌
• [#9714], [#9724]: Use the C++ alignas keyword when compiling in
C++. Fixes a bug with MSVC C++ 2015/2017. Add a terminator to the
`caml_domain_state' structure to better ensure that members are
correctly spaced. (Antonin Décimo, review by David Allsopp and
Xavier Leroy)
[#9714] https://github.com/ocaml/ocaml/issues/9714
[#9724] https://github.com/ocaml/ocaml/issues/9724
Manual and documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#8644]: fix formatting comment about @raise in stdlib's mli files
(Élie Brami, review by David Allsopp)
• [#9712]: Update the version format to allow "`". The new format is
"major.minor[.patchlevel][(+|')additional-info]", for instance
"4.12.0~beta1+flambda". This is a documentation-only change for the
4.11 branch, the new format will be used starting with the 4.12
branch. (Florian Angeletti, review by Damien Doligez and Xavier
Leroy)
[#8644] https://github.com/ocaml/ocaml/issues/8644
[#9712] https://github.com/ocaml/ocaml/issues/9712
letters - simple client abstractions for sending emails over SMTP
═════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-letters-simple-client-abstractions-for-sending-emails-over-smtp/6071/1]
Miko announced
──────────────
Earlier today I've published the first release of [letters]. This
library aims to provide simple to use client library for sending
emails over SMTP using _lwt_ for async execution.
It is build on top of _mrmime_ and _colombe_. While these libraries
are very capable, they aren't that simple to use, _letters_ is trying
to fill that gap. Anyway, big thanks for the authors of these projects
for doing the heavy lifting.
As this library is still in its early stage, I believe I will break
the API with first few releases. Luckily the API is quite simple so
following these changes should be quite easy.
To make this library awesome, any feedback or feature request is
welcome. I'll try to address them as quickly as I can.
I hope I've managed to scratch someone else's itch too, enjoy.
[letters] https://github.com/oxidizing/letters
A question about Ocaml
══════════════════════
Archive: [https://discuss.ocaml.org/t/a-question-about-ocaml/6075/21]
Deep in this theard, Yawar Amin said
────────────────────────────────────
A few ReasonML books:
• [Web Development With ReasonML]
• [Exploring ReasonML] (free online)
• [Learn Type-Driven Development] (co-authored by me)
[Web Development With ReasonML] https://pragprog.com/titles/reasonml/
[Exploring ReasonML] http://reasonmlhub.com/exploring-reasonml/toc.html
[Learn Type-Driven Development]
https://www.packtpub.com/application-development/learn-type-driven-development
Alcotest 1.2.0
══════════════
Archive: [https://discuss.ocaml.org/t/ann-alcotest-1-2-0/6089/1]
Craig Ferguson announced
────────────────────────
I'm pleased to announce the release of [Alcotest] 1.2.0, now available
on Opam.
This release includes:
• a new `alcotest-mirage' package for running tests on MirageOS;
• full UTF-8 support;
• default coloured output in Dune (without needing to pass
`--no-buffer');
• an improved output format.
The full changelog is available [here].
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/ac89cfe4dfeed063560212136c9e2b690a888b6c.png]
Thanks to our many contributors in this release cycle.
[Alcotest] https://github.com/mirage/alcotest/
[here] https://github.com/mirage/alcotest/blob/1.2.0/CHANGES.md
Set up OCaml 1.1.0
══════════════════
Archive: [https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-0/6093/1]
Sora Morimoto announced
───────────────────────
This release contains these changes:
• The default opam repository can now be set via input.
• Linux VMs now use opam 2.0.7.
[https://github.com/avsm/setup-ocaml/releases/tag/v1.1.0]
Sora Morimoto then added
────────────────────────
In fact, this release was a long time ago, but I completely forgot to
post this. By the way, we have made significant improvements to some
of the documentation. In particular, the action versioning section is
applicable to other GitHub Actions and definitely worth reading!
[https://github.com/avsm/setup-ocaml#how-to-specify-the-version]
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 20500 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-07 10:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-07-07 10:04 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 25998 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 30 to July
07, 2020.
Table of Contents
─────────────────
Releases of ringo
Multicore OCaml: June 2020
Time expression demo
Interactive OCaml development with utop in Emacs
Old CWN
Releases of ringo
═════════════════
Archive: [https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/5]
Continuing this thread, Raphaël Proust said
───────────────────────────────────────────
Ringo provides bounded-size key-value stores. More specifically, it
provides a functor similar to `Hastbl.Make' except that the number of
bindings held by the tables is limited: inserting additional bindings
when the limit has been reached causes some previously inserted
binding to be removed.
More more specifically, Ringo provides a function `map_maker' that
takes parameters to customise the policies that determine the
behaviour of the cache when supernumerary bindings are inserted, and
returns the functor described above. Once a module `Cache' is
instantiated using this functor, it can be used as follows:
┌────
│ let cache = Cache.create size
│ let fetch_data uri =
│ match Cache.find_opt cache uri with
│ | Some data -> data
│ | None ->
│ let data = really_fetch_data uri in
│ Cache.replace cache uri data;
│ data
└────
The cache will only hold up to [size] bindings, which avoids leaking
memory. Additionally, the parameters for `map_maker' allow you to
customise:
• The replacement policy: which binding is removed when a
supernumerary is inserted (currently supports least-recently used
and first-in first-out).
• The overflow policy: whether the cache can weakly hold some
supernumerary elements (if so, the cache may hold more but the GC
can always collect them if space is lacking).
• The accounting precision: whether to keep precise track of
removed/replaced elements.
In addition, Ringo also provide set-caches: i.e., sets (rather than
maps) with bounded size and all the same properties as above.
Also note Ringo-Lwt (`ringo-lwt') provides Lwt wrappers around Ringo
caches.
If you have suggestions for a different concise synopsis for `opam',
feel free to send them this way.
Use cases are, I guess, caches. In particular those that might receive
many elements not all of which you can hold in memory. We use it in a
few places in the Tezos project to hold resources (blocks, operations,
etc.) that are fetched from the P2p layer: it avoids having to fetch
them again from the network.
I think `anycache', `lru', and `lru-cache' are all alternatives
available on opam.
Raphaël Proust later added
──────────────────────────
The documentation is now available online at
[https://nomadic-labs.gitlab.io/ringo/index.html]
Of particular interest:
• [The signature for a `ringo' key-value cache]
• [The entry point for the `ringo' library] (allowing you to
instantiate modules with the above signature as well as simple value
caches)
• [The signature for `ringo-lwt' cache]
[The signature for a `ringo' key-value cache]
https://nomadic-labs.gitlab.io/ringo/ringo/Ringo/module-type-CACHE_MAP/index.html
[The entry point for the `ringo' library]
https://nomadic-labs.gitlab.io/ringo/ringo/Ringo/index.html
[The signature for `ringo-lwt' cache]
https://nomadic-labs.gitlab.io/ringo/ringo-lwt/Ringo_lwt/Sigs/module-type-CACHE_MAP/index.html
Multicore OCaml: June 2020
══════════════════════════
Archive:
[https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047/1]
Anil Madhavapeddy announced
───────────────────────────
Welcome to the June 2020 [Multicore OCaml] report! As with [previous
updates], many thanks to @shakthimaan and @kayceesrk for collating the
updates for the month of June 2020. /This is an incremental update;
new readers may find it helpful to flick through the previous posts
first./
This month has seen a tremendous surge of activity on the upstream
OCaml project to prepare for multicore integration, as @xavierleroy
and the core team have driven a number of initiatives to prepare the
OCaml project for the full multicore featureset. To reflect this,
from next month we will have a status page on the ocaml-multicore wiki
with the current status of both our multicore branch and the upstream
OCaml project itself.
Why not from this month? Well, there's good news and bad news. [Last
month], I observed that we are a PR away from most of the opam
ecosystem working with the multicore branch. The good news is that we
are still a single PR away from it working, but it's a different one
:-) The retrofitting of the `Threads' library has brought up [some
design complexities], and so rather than putting in a "bandaid" fix,
we are integrating a comprehensive solution that will work with system
threads, domains and (eventually) fibres. That work has taken some
time to get right, and I hope to be able to update you all on an
opam-friendly OCaml 4.10.0+multicore in a few weeks.
Aside from this, there have been a number of other improvements going
into the multicore branches: [mingw Windows support], [callstack
improvements], [fixing the Unix module] and so on. The full list is in
the detailed report later in this update.
[Multicore OCaml] https://github.com/ocaml-multicore/ocaml-multicore
[previous updates] https://discuss.ocaml.org/tag/multicore-monthly
[Last month]
https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898
[some design complexities]
https://github.com/ocaml-multicore/ocaml-multicore/pull/342
[mingw Windows support]
https://github.com/ocaml-multicore/ocaml-multicore/pull/351
[callstack improvements]
https://github.com/ocaml-multicore/ocaml-multicore/pull/363
[fixing the Unix module]
https://github.com/ocaml-multicore/ocaml-multicore/pull/346
Sandmark benchmarks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
A major milestone in this month has been the upgrade to the latest
dune.2.6.0 to build Multicore OCaml 4.10.0 for the Sandmark
benchmarking project. A number of new OPAM packages have been added,
and the existing packages have been upgraded to their latest
versions. The Multicore OCaml code base has seen continuous
performance improvements and enhancements which can be observed from
the various PRs mentioned in the report.
We would like to thank:
• @xavierleroy for working on a number of multicore-prequisite PRs to
make stock OCaml ready for Multicore OCaml.
• @camlspotter has reviewed and accepted the camlimages changes and
made a release of camlimages.5.0.3 required for Sandmark.
• @dinosaure for updating the decompress test benchmarks for Sandmark
to build and run with dune.2.6.0 for Multicore OCaml 4.10.0.
A chapter on Parallel Programming in Multicore OCaml with topics on
task pool, channels section, profiling with code examples is being
written. We shall provide an early draft version of the document to
the community for your valuable feedback.
Papers
╌╌╌╌╌╌
Our "Retrofitting Parallism onto OCaml" paper has been officially
accepted at [ICFP 2020] which will be held virtually between August
23-28, 2020. A [preprint] of the paper was made available earlier, and
will be updated in a few days with the camera-ready version for ICFP.
Please do feel free to send on comments and queries even after the
paper is published, of course.
Excitingly, another multicore-related paper on [Cosmo: A Concurrent
Separation Logic for Multicore OCaml] will also be presented at the
same conference.
The Multicore OCaml updates are first listed in our report, which are
followed by improvements to the Sandmark benchmarking
project. Finally, the changes made to upstream OCaml which include
both the ongoing and completed tasks are mentioned for your reference.
[ICFP 2020]
https://icfp20.sigplan.org/track/icfp-2020-papers#event-overview
[preprint] https://arxiv.org/abs/2004.11663
[Cosmo: A Concurrent Separation Logic for Multicore OCaml]
http://gallium.inria.fr/~fpottier/publis/mevel-jourdan-pottier-cosmo-2020.pdf
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore#339] Proposal for domain-local
storage
An RFC proposal to implement a domain-local storage in Multicore
OCaml. Kindly review the idea and share your feedback!
• [ocaml-multicore/ocaml-multicore#342] Implementing the threads
library with Domains
An effort to rebase @jhwoodyatt's implementation of the Thread
library for Domains.
• [ocaml-multicore/ocaml-multicore#357] Implementation of systhreads
with pthreads
Exploring the possibilty of implementing systhreads with pthreads,
while still maintaining compatibility with the existing solution.
• [ocaml/dune#3548] Dune fails to pick up secondary compiler
The `ocaml-secondary-compiler' fails to install with
dune.2.6.0. This is required as Multicore OCaml cannot build the
latest dune without systhreads support.
[ocaml-multicore/ocaml-multicore#339]
https://github.com/ocaml-multicore/ocaml-multicore/issues/339
[ocaml-multicore/ocaml-multicore#342]
https://github.com/ocaml-multicore/ocaml-multicore/pull/342
[ocaml-multicore/ocaml-multicore#357]
https://github.com/ocaml-multicore/ocaml-multicore/issues/357
[ocaml/dune#3548] https://github.com/ocaml/dune/issues/3548
◊ Completed
• [ocaml-multicore/multicore-opam#22] Update dune to 2.6.0
The dune version in the Multicore OPAM repository is now updated to
use the latest 2.6.0.
• [ocaml-multicore/ocaml-multicore#338] Introduce Lazy.try_force and
Lazy.try_force_val
An implementation of `Lazy.try_force' and `Lazy.try_force_val'
functions to implement concurrent lazy abstractions.
• [ocaml-multicore/ocaml-multicore#340] Fix Atomic.exchange in
concurrent_minor_gc
A patch that introduces `Atomic.exchange' through `Atomic.get' that
provides the appropriate read barrier for correct exchange semantics
for `caml_atomic_exchange' in `memory.c'.
• [ocaml-multicore/ocaml-multicore#343] Fix extcall noalloc DWARF
The DWARF information emitted for `extcall noalloc' had broken
backtraces and this PR fixes the same.
• [ocaml-multicore/ocaml-multicore#345] Absolute exception stack
The representation of the exception stack is changed from relative
addressing to absolute addressing and the results are promising. The
Sandmark serial benchmark results after the change is illustrated in
the following graph:
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/b385409b3f9e44cbfef98de668b0b4d0ed403472_2_1380x436.png]
• [ocaml-multicore/ocaml-multicore#347] Turn on -Werror by default
Adds a `--enable-warn-error' option to `configure' to treat C
compiler warnings as errors.
• [ocaml-multicore/ocaml-multicore#353] Poll for interrupts in
cpu_relax without locking
Use `Caml_check_gc_interrupt' first to poll for interrupts without
locking, and then proceeding to handle the interrupt with the lock.
• [ocaml-multicore/ocaml-multicore#354] Add Caml_state_field to
domain_state.h
The `Caml_state_field' macro definition in domain_state.h is
required for base-v0.14.0 to build for Multicore OCaml 4.10.0 with
dune.2.6.0.
• [ocaml-multicore/ocaml-multicore#355] One more location to poll for
interrupts without lock
Another use of `Caml_check_gc_interrupt' first to poll for
interrupts without lock, similar to
[ocaml-multicore/ocaml-multicore#353].
• [ocaml-multicore/ocaml-multicore#356] Backup threads for domain
Introduces `backup threads' to perform GC and handle service
interrupts when the domain is blocked in the kernel.
• [ocaml-multicore/ocaml-multicore#358] Fix up bad CFI information in
amd64.S
Add missing `CFI_ADJUST' directives in `runtime/amd64.S' for
`caml_call_poll' and `caml_allocN'.
• [ocaml-multicore/ocaml-multicore#359] Inline caml_domain_alone
The PR makes `caml_domain_alone' an inline function to improve
performance for `caml_atomic_cas_field' and other atomics in
`memory.c'.
• [ocaml-multicore/ocaml-multicore#360] Parallel minor GC inline mask
rework
The inline mask rework for the promotion path to the
`parallel_minor_gc' branch gives a 3-5% performance improvement for
`test_decompress' sandmark benchmark, and a decrease in the executed
instructions for all other benchmarks.
• [ocaml-multicore/ocaml-multicore#361] Mark stack push work credit
The PR improves the Multicore mark work accounting to be in line
with stock OCaml.
• [ocaml-multicore/ocaml-multicore#362] Iloadmut does not clobber rax
and rdx when we do not have a read barrier
A code clean-up to free the registers `rax' and `rdx' for OCaml code
when `Iloadmut' is used.
[ocaml-multicore/multicore-opam#22]
https://github.com/ocaml-multicore/multicore-opam/pull/22
[ocaml-multicore/ocaml-multicore#338]
https://github.com/ocaml-multicore/ocaml-multicore/pull/338
[ocaml-multicore/ocaml-multicore#340]
https://github.com/ocaml-multicore/ocaml-multicore/pull/340
[ocaml-multicore/ocaml-multicore#343]
https://github.com/ocaml-multicore/ocaml-multicore/pull/343
[ocaml-multicore/ocaml-multicore#345]
https://github.com/ocaml-multicore/ocaml-multicore/pull/345
[ocaml-multicore/ocaml-multicore#347]
https://github.com/ocaml-multicore/ocaml-multicore/pull/347
[ocaml-multicore/ocaml-multicore#353]
https://github.com/ocaml-multicore/ocaml-multicore/pull/353
[ocaml-multicore/ocaml-multicore#354]
https://github.com/ocaml-multicore/ocaml-multicore/pull/354
[ocaml-multicore/ocaml-multicore#355]
https://github.com/ocaml-multicore/ocaml-multicore/pull/355
[ocaml-multicore/ocaml-multicore#356]
https://github.com/ocaml-multicore/ocaml-multicore/pull/356
[ocaml-multicore/ocaml-multicore#358]
https://github.com/ocaml-multicore/ocaml-multicore/pull/358
[ocaml-multicore/ocaml-multicore#359]
https://github.com/ocaml-multicore/ocaml-multicore/pull/359
[ocaml-multicore/ocaml-multicore#360]
https://github.com/ocaml-multicore/ocaml-multicore/pull/360
[ocaml-multicore/ocaml-multicore#361]
https://github.com/ocaml-multicore/ocaml-multicore/pull/361
[ocaml-multicore/ocaml-multicore#362]
https://github.com/ocaml-multicore/ocaml-multicore/pull/362
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-bench/sandmark#8] Ability to run compiler variants in
Sandmark
A feature to specify configure options when building compiler
variants such as `flambda' is useful for development and
testing. This feature is being worked upon.
• [ocaml-bench/sandmark#107] Add Coq benchmarks
We are continuing to add more benchmarks to Sandmark for Multicore
OCaml and investigating adding the [Coq] benchmarks to our
repertoire!
• [ocaml-bench/sandmark#124] User configurable paramwrapper added to
Makefile
A `PARAMWRAPPER' environment variable can be passed as an argument
by specifying the `--cpu-list' to be used for parallel benchmark
runs.
• [ocaml-bench/sandmark#131] Update decompress benchmarks
Thanks to @dinosaure for updating the decompress benchmarks in order
to run them with dune.2.6.0 for Multicore OCaml 4.10.0.
• [ocaml-bench/sandmark#132] Update dependency packages to use
dune.2.6.0 and Multicore OCaml 4.10.0
Sandmark has been running with dune.1.11.4, and we need to move to
the latest dune.2.6.0 for using Multicore OCaml 4.10.0 and beyond,
as mentioned in [Promote dune to > 2.0]. The PR updates over 30
dependency packages and successfully builds both serial and parallel
benchmarks!
[ocaml-bench/sandmark#8]
https://github.com/ocaml-bench/sandmark/issues/8
[ocaml-bench/sandmark#107]
https://github.com/ocaml-bench/sandmark/issues/107
[Coq] https://coq.inria.fr/
[ocaml-bench/sandmark#124]
https://github.com/ocaml-bench/sandmark/pull/124
[ocaml-bench/sandmark#131]
https://github.com/ocaml-bench/sandmark/pull/131
[ocaml-bench/sandmark#132]
https://github.com/ocaml-bench/sandmark/pull/132
[Promote dune to > 2.0]
https://github.com/ocaml-bench/sandmark/issues/106
◊ Completed
• [camlspotter/camlimages#1] Use dune-configurator instead of
configurator for camlimages
A new release of `camlimages.5.0.3' was made by @camlspotter after
accepting the changes to camlimages.opam in order to build with
dune.2.6.0.
• [ocaml-bench/sandmark#115] Task API Port: LU-Decomposition, Floyd
Warshall, Mandelbrot, Nbody
The changes to use the `Domainslib.Task' API for the listed
benchmarks have been merged.
• [ocaml-bench/sandmark#121] Mention sudo access for
run_all_parallel.sh script
The README.md file has been updated with the necessary `sudo'
configuration steps to execute the `run_all_parallel.sh' script for
nightly builds.
• [ocaml-bench/sandmark#125] Add cubicle benchmarks
The `German PFS' and `Szymanski's mutual exclusion algorithm'
cubicle benchmarks have been included in Sandmark.
• [ocaml-bench/sandmark#126] Update ocaml-versions README to reflect
4.10.0+multicore
The README has now been updated to reflect the latest 4.10.0
Multicore OCaml compiler and its variants.
• [ocaml-bench/sandmark#129] Add target to run parallel benchmarks in
the CI
The .drone.yml file used by the CI has been updated to run both the
serial and parallel benchmarks.
• [ocaml-bench/sandmark#130] Add missing dependencies in
multicore-numerical
The `domainslib' library has been added to the dune file for the
multicore-numerical benchmark.
[camlspotter/camlimages#1]
https://gitlab.com/camlspotter/camlimages/-/merge_requests/1
[ocaml-bench/sandmark#115]
https://github.com/ocaml-bench/sandmark/pull/115
[ocaml-bench/sandmark#121]
https://github.com/ocaml-bench/sandmark/pull/121
[ocaml-bench/sandmark#125]
https://github.com/ocaml-bench/sandmark/pull/125
[ocaml-bench/sandmark#126]
https://github.com/ocaml-bench/sandmark/pull/126
[ocaml-bench/sandmark#129]
https://github.com/ocaml-bench/sandmark/pull/129
[ocaml-bench/sandmark#130]
https://github.com/ocaml-bench/sandmark/pull/130
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9541] Add manual page for the instrumented runtime
The [instrumented runtime] has been merged to OCaml 4.11.0. A manual
for the same has been created and is under review.
• [sadigqj/ocaml#1] GC colours change
This PR removes the grey colour used in stock OCaml to match the
scheme used by the Multicore major collector. The performance and
considerations are included for review.
[ocaml/ocaml#9541] https://github.com/ocaml/ocaml/pull/9541
[instrumented runtime] https://github.com/ocaml/ocaml/pull/9082
[sadigqj/ocaml#1] https://github.com/sadiqj/ocaml/pull/1
◊ Completed
• [ocaml/ocaml#9619] A self-describing representation for function
closures
The PR provides a way to record the position of the environment for
each entry point for function closures.
• [ocaml/ocaml#9649] Marshaling for the new closure representation
The `output_value' marshaler has been updated to use the new closure
representation. There is no change required for the `input_value'
unmarshaler.
• [ocaml/ocaml#9655] Introduce type Obj.raw_data and functions
Obj.raw_field, Obj.set_raw_field to manipulate out-of-heap pointers
The PR introduces a type `Obj.bits', and functions `Obj.field_bits'
and `Obj.set_field_bits' to read and write bit representation of
block fields to support the no-naked-pointer operation.
• [ocaml/ocaml#9678] Reimplement Obj.reachable_word using a hash table
to detect sharing
The `caml_obj_reachable_words' now uses a hash table instead of
modifying the mark bits of block headers to detect sharing. This is
required for compatibility with Multicore OCaml.
• [ocaml/ocaml#9680] Naked pointers and the bytecode interpreter
The bytecode interpreter implementation is updated to support the
no-naked-pointers mode operation as required by Multicore OCaml.
• [ocaml/ocaml#9682] Signal handling in native code without the page
table
The patch uses the code fragment table instead of a page table
lookup for signal handlers to know whether the signal came from
ocamlopt-generated code.
• [ocaml/ocaml#9683] globroots.c: adapt to no-naked-pointers mode
The patch considers out-of-heap pointers as major-heap pointers in
no-naked-pointers mode for global roots management.
• [ocaml/ocaml#9689] Generic hashing for the new closure
representation
The hashing functions have been updated to use the latest closure
representation from [ocaml/ocaml#9619] for the no-naked-pointers
mode.
• [ocaml/ocaml#9698] The end of the page table is near
The PR eliminates some of the use of the page tables in the runtime
system when built with no-naked-pointers mode.
Our thanks to all the OCaml developers and users in the community for
their continued support and contribution to the project. Stay safe!
[ocaml/ocaml#9619] https://github.com/ocaml/ocaml/pull/9619
[ocaml/ocaml#9649] https://github.com/ocaml/ocaml/pull/9649
[ocaml/ocaml#9655] https://github.com/ocaml/ocaml/pull/9655
[ocaml/ocaml#9678] https://github.com/ocaml/ocaml/pull/9678
[ocaml/ocaml#9680] https://github.com/ocaml/ocaml/pull/9680
[ocaml/ocaml#9682] https://github.com/ocaml/ocaml/pull/9682
[ocaml/ocaml#9683] https://github.com/ocaml/ocaml/pull/9683
[ocaml/ocaml#9689] https://github.com/ocaml/ocaml/pull/9689
[ocaml/ocaml#9698] https://github.com/ocaml/ocaml/pull/9698
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• CFI: Call Frame Information
• CI: Continuous Integration
• DWARF: Debugging With Attributed Record Formats
• GC: Garbage Collector
• ICFP: International Conference on Functional Programming
• OPAM: OCaml Package Manager
• PR: Pull Request
• RFC: Request for Comments
Time expression demo
════════════════════
Archive: [https://discuss.ocaml.org/t/time-expression-demo/6052/1]
Darren announced
────────────────
An interactive demo for a small part of our time stuff and schedule
handling library is available here:
[https://daypack-dev.github.io/time-expr-demo/]
Time expression is in essence a language for specifying time points or
time slots precisely and concisely, while trying to mimic natural
language.
The implementation of the demo core itself can be seen here:
[https://github.com/daypack-dev/time-expr-demo/blob/master/src/demo.ml]
, where the usage of Daypack-lib is shown.
Lastly, the library is still a prototype, so expect some faults in the
outputs of the demo here and there.
Interactive OCaml development with utop in Emacs
════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/interactive-ocaml-development-with-utop-in-emacs/6058/1]
Samarth Kishor announced
────────────────────────
I made a [blog post] about REPL driven development with utop in Emacs
a few months ago. Please let me know if you found it useful or have
anything to add! I'm a bit new to OCaml so any feedback helps.
There was a [similar post about REPL driven development] last year and
my post addresses a lot of those points. I wish I'd seen that post
before I wrote this since there's a ton of useful information in the
comments.
[blog post]
https://samarthkishor.github.io/posts/interactive_ocaml_development/
[similar post about REPL driven development]
https://discuss.ocaml.org/t/ocaml-repl-driven-development/4068
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 39647 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-30 7:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-06-30 7:00 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 7753 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 23 to 30,
2020.
Table of Contents
─────────────────
finch - static site generator
ANN: Releases of ringo
OCaml 4.11, first beta release
FlexDLL 0.38 released
Other OCaml News
Old CWN
finch - static site generator
═════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-finch-static-site-generator/6026/1]
roddy announced
───────────────
Announcing [finch], a simple static site generator. It uses content
written as Markdown plus YAML frontmatter like Jekyll/Hugo etc. and
produces output with [Jingoo] templates. It also has some integrations
with React (as in the JS library) in the form of Jingoo filters: the
motivation behind it was to make it easier to develop sites that use
React just for some in some parts rather than structuring the whole
site as a single page application.
[finch] https://github.com/roddyyaga/finch
[Jingoo] https://github.com/tategakibunko/jingoo
ANN: Releases of ringo
══════════════════════
Archive: [https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/3]
Raphaël Proust announced
────────────────────────
Version 0.5 of `ringo' and `ringo-lwt' are now available in
`opam'. Although this version changes `ringo-lwt' only, both packages
are released anew to keep the version numbers in sync. This version
includes:
• Improvement in documentation.
• Simplifications and reduction in the memory footprint of lwt-wrapped
caches.
• Fix for a race condition in the automatic cleanup (previously, on
weak caches only, a promise being rejected could cause a different
promise to be removed from the cache)
• Fix a leak
• More test, including a test for leakiness.
OCaml 4.11, first beta release
══════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-first-beta-release/6042/1]
octachron announced
───────────────────
The release of OCaml 4.11.0 is approaching.
After three alpha releases, we have created a first beta version to
help you adapt your software to the new features ahead of the release.
The compatibility of the opam ecosystem with OCaml 4.11.0 is currently
quite good, and it should be possible to test this beta without too
much trouble.
The source code is available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+beta1.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta1.tar.gz]
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.11.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+beta1+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
We want to know about all bugs. Please report them here:
[https://github.com/ocaml/ocaml/issues]
If you are interested by the list of new features, and the on-going
list of bug fixes the updated change log for OCaml 4.11.0 is available
at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
Compared to the last alpha release, this first beta release contains
the following new bug fixes:
Driver
╌╌╌╌╌╌
• [#9011]: Allow linking .cmxa files with no units on MSVC by not
requiring the .lib file to be present. (David Allsopp, report by
Dimitry Bely, review by Xavier Leroy)
[#9011] https://github.com/ocaml/ocaml/issues/9011
Typechecker
╌╌╌╌╌╌╌╌╌╌╌
• [#9384], [#9385]: Fix copy scope bugs in substitutions (Leo White,
review by Thomas Refis, report by Nick Roberts)
• [#9695], [#9702]: no error when opening an alias to a missing module
(Jacques Garrigue, report and review by Gabriel Scherer)
[#9384] https://github.com/ocaml/ocaml/issues/9384
[#9385] https://github.com/ocaml/ocaml/issues/9385
[#9695] https://github.com/ocaml/ocaml/issues/9695
[#9702] https://github.com/ocaml/ocaml/issues/9702
Warnings
╌╌╌╌╌╌╌╌
• [#7897], [#9537]: Fix warning 38 for rebound extension constructors
(Leo White, review by Florian Angeletti)
• [#9244]: Fix some missing usage warnings (Leo White, review by
Florian Angeletti)
[#7897] https://github.com/ocaml/ocaml/issues/7897
[#9537] https://github.com/ocaml/ocaml/issues/9537
[#9244] https://github.com/ocaml/ocaml/issues/9244
Toplevel
╌╌╌╌╌╌╌╌
• [#9415]: Treat `open struct' as `include struct' in toplevel (Leo
White, review by Thomas Refis)
• [#9416]: Avoid warning 58 in flambda ocamlnat (Leo White, review by
Florian Angeletti)
[#9415] https://github.com/ocaml/ocaml/issues/9415
[#9416] https://github.com/ocaml/ocaml/issues/9416
Flambda backend
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9163]: Treat loops properly in un_anf (Leo White, review by Mark
Shinwell, Pierre Chambart and Vincent Laviron)
[#9163] https://github.com/ocaml/ocaml/issues/9163
FlexDLL 0.38 released
═════════════════════
Archive: [https://discuss.ocaml.org/t/flexdll-0-38-released/6043/1]
David Allsopp announced
───────────────────────
We are pleased to announce the release of FlexDLL 0.38!
FlexDLL provides a dlopen-like interface for Windows and is used to
simplify the linking process for the native Windows ports of OCaml and
to allow dynamic loading of C code (bytecode stub libraries and native
Dynlink). It is also used for the same purpose in the Cygwin ports of
OCaml, except that they can be configured without shared library
support.
The release includes various bugfixes as well as proper support for
C++ linking on mingw and linking against data symbols in import
libraries.
Please see the [release page] for more information.
[release page] https://github.com/alainfrisch/flexdll/releases/tag/0.38
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-C 21.1 (Scandium) is out. Download it here.]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-C 21.1 (Scandium) is out. Download it here.]
http://frama-c.com/index.html
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 20340 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-16 8:36 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-06-16 8:36 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 12607 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 09 to 16,
2020.
Table of Contents
─────────────────
First release of monolith
Sylvain Conchon joined OCamlPro's team
First release of streaming
Senior software engineer at Asemio in Tulsa, OK
Other OCaml News
Old CWN
First release of monolith
═════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-first-release-of-monolith/5946/1]
François Pottier announced
──────────────────────────
It is my pleasure to announce the first release of Monolith.
Monolith offers facilities for testing an OCaml library (for instance,
a data structure implementation) by comparing it against a reference
implementation. It uses a form of black-box testing, and relies on
`afl-fuzz' for efficiency.
The user must describe what types and operations the library
provides. Under the best circumstances, this requires 2-3 lines of
code per type or operation. The user must also provide a reference
implementation of the library.
Then, like a monkey typing on a keyboard, Monolith attempts to
exercise the library in every possible way, in the hope of discovering
a scenario where the library behaves incorrectly. If such a scenario
is discovered, it is printed in the form of an OCaml program, so as to
help the user reproduce the problem.
At this time, a tutorial is not yet available. There is however an API
documentation and a number of demos.
Repository: [https://gitlab.inria.fr/fpottier/monolith]
API Documentation:
[http://cambium.inria.fr/~fpottier/monolith/doc/monolith/Monolith/index.html]
Installation:
┌────
│ opam update
│ opam install monolith
└────
Sylvain Conchon joined OCamlPro's team
══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/sylvain-conchon-joined-ocamlpros-team/5956/1]
OCamlPro announced
──────────────────
Sylvain Conchon joined OCamlPro's team as Formal Methods CSO. He
created Alt-Ergo and has been teaching OCaml in universities for about
20 years. He shares thoughts on interactions between industry and
research labs, and his vision of Formal methods and OCaml as language
for the industry. Read his interview on our blog:
[https://www.ocamlpro.com/2020/06/05/interview-sylvain-conchon-cso-on-formal-methods/]
First release of streaming
══════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-first-release-of-streaming/5961/1]
Rizo announced
──────────────
It is my pleasure to announce the first public release of `streaming'
– a library for building efficient, incremental data processing
pipelines that compose and don't leak resources.
I built streaming as a result of many experiments with different
streaming and iteration models for OCaml. There are multiple packages
on OPAM that share some of the goals of `streaming' (we even have
`Stdlib.Seq' now!), but none of them combine (1) excellent
performance, (2) safe resource handling and (3) pure functional style
for combinators. Streaming solves these problems by implementing
three basic and independent models: _sources_, _sinks_ and _flows_ –
they represents different parts of the pipeline that correspond to
producing, consuming and transforming elements. These models can be
defined and composed independently to produce reusable "streaming
blocks".
The library defines a central `Stream' model that relies on sources,
sinks and flows. This model is a push-based iterator with performance
characteristics similar to the `iter' iterator, which has type `('a ->
unit) -> unit', and is known for being very efficient. But unlike
`iter', it has a pure functional core (no need to use mutable state
and exceptions for flow control!) and can handle resource allocation
and clean up in a lazy and deterministic way. All of this while having
a slightly better performance for common stream operations.
For those who are curious about the performance characteristics of
`streaming' and other models, I created a dedicated repository for
stream benchmarks: [https://github.com/rizo/streams-bench]. In
particular, it includes a few simple benchmarks for `Gen',
`Base.Sequence', `Stdlib.Seq', `Iter', `Streaming.Stream' and
`Streaming.Source'.
The library should soon be published on opam. In the meantime, I
invite you to read the docs and explore the code:
• Library documentation: [https://odis-labs.github.io/streaming]
• Github project: [https://github.com/odis-labs/streaming]
Guillaume Bury askec
────────────────────
That's great ! From the benchmarks, it looks like you hit a really
good implementation !
I've looked (maybe a bit fast) at the API documentation, and it is
admittedly a bit outside the scope of streams/iterators, but I was
wondering if there was some proper way to:
• connect a sink to a source to create some loop
• have some kind of fixpoint on streams
I guess it would always be possible to use some references and/or some
complex functions to encode these into the provided API, but I was
wondering if there was a clean way to do it.
For a bit of context and explanation, what I have in mind is the case
of a program (let's say a type-checker or something close to the idea)
with a *persistent state*, that should operate over a stream of
inputs, which are top-level phrases, and produce some outputs, for
instance print some result for each correctly type-checked statement
(and an error otherwise). The type-checker would basically be a
function of type `(`input * `state) -> (`output * `state)', and
starting from an initial state, it would process an input element
(giving the output to some sink), and then the next input element
would be processed with the state that was reached after processing
the previous element: the state would reach the sink of the flow, and
then be inserted back into the source. Separately, imagine the
language being type-checked has a notion of include, then one of the
step of the flow would be to expand each include into a stream of
inputs/phrases, but each of the phrases in this stream would need to
be expanded, so a simple `flat_map~/~flatten' is not enough.
I already have a custom implementation that handle these features, but
I was wondering whether I could use `streaming' to handle most of the
code linking all of the steps, ^^
Rizo replied
────────────
if there was some proper way to:
• connect a sink to a source to create some loop
• have some kind of fixpoint on streams
Regarding the first point: yes! That's exactly the point of the
`Stream' module. You see, sources are pull-based abstractions, while
sinks are push-based. Source's type essentially says something like
_"I might give you some data, if you ask"_, while sink's type is the
opposite _"I might take some data, if you give it to me"_. They are
completely and intentionally decoupled; it is Stream's role to drive
the computation by pulling data from sources and pushing it into
sinks. So the easiest way to connect them is:
┌────
│ Stream.(from srouce |> into sink)
└────
Of course, that's not very useful per se, but it illustrates my
point. Take a look at the [`Stream.from'] code to see the
implementation of the loop you're asking for. It does some extra work
to ensure that resources are correctly handled, but it should be clear
what the loop is doing.
The stream types in the library are currently abstract because I
didn't want to commit to a particular representation just yet. If this
is a problem for your use case, let me know, I'll expose them in a
`Private' module.
Regarding the second point: I'm not sure what you mean in practice by
"fixpoint on streams". I guess the one thing that could help implement
something like that is the [`Stream.run'] function. It allows you to
continue reading elements from a source even after a sink is filled by
returning a leftover stream. This stream can be used with
`Stream.run' repeatedly.
Alternatively there's also [`Flow.through'], which consumes input
trying to fill sinks repeatedly and produces their aggregated values
as a stream. Super useful for things like streaming parsing. Might
even help with your use-case for top-level phrases.
On a more general note though, the type `('input * 'state) -> ('output
* 'state)' looks a lot like a [mealy machine]. `Streaming.Sink' is a
[moore machine], which is slightly less general because the output
values do not depend on input values, only on the state.
I thought about exposing different kinds of sinks in streaming, but
wanted to make sure that the common use cases are covered first. I'll
keep your case in mind for future versions of the library.
[`Stream.from']
https://github.com/odis-labs/streaming/blob/0.8.0/lib/Stream.ml#L42
[`Stream.run']
https://odis-labs.github.io/streaming/streaming/Streaming/Stream/index.html#val-run
[`Flow.through']
https://odis-labs.github.io/streaming/streaming/Streaming/Flow/index.html#val-through
[mealy machine] https://en.wikipedia.org/wiki/Mealy_machine
[moore machine] https://en.wikipedia.org/wiki/Moore_machine
Senior software engineer at Asemio in Tulsa, OK
═══════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/senior-software-engineer-at-asemio-in-tulsa-ok/5979/1]
Simon Grondin announced
───────────────────────
We are Asemio and our team of data scientists, software engineers,
architects, and management consultants are working together to achieve
a nationwide data ecosystem for social good.
You’ll be working on the Asemio Community Integration Platform. It
features state-of-the-art privacy-preserving, pre-processing and
pipeline management, as well as record linkage technology.
The back end is written in OCaml. The front end is compiled from OCaml
to JavaScript and uses a modern MVC framework. The work you’ll be
doing will touch numerous technical disciplines, including
cryptography, distributed systems, language design and implementation,
data analytics, and data visualizations.
We prefer candidates willing to relocate, but we could make an
exception for an exceptional candidate.
For more information or to apply, please refer to our SE listing:
[https://stackoverflow.com/jobs/401383/ocaml-senior-software-engineer-asemio]
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Frama-C 21.0 (Scandium) is out. Download it here.]
• [Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]
[OCaml Planet] http://ocaml.org/community/planet/
[Frama-C 21.0 (Scandium) is out. Download it here.]
http://frama-c.com/index.html
[Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]
http://math.andrej.com/2020/06/09/epigram-2-autopsy-obituary-apology/
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2.2: Type: text/html, Size: 25107 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-06-09 8:28 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-06-09 8:28 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 28667 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of June 02 to 09,
2020.
Table of Contents
─────────────────
Multicore Update: April 2020, with a preprint paper
BAP 2.1.0 Release
Migrating an Async project to Lwt, a short primer
jose 0.4.0
OCaml 4.11.0, second alpha release
OCaml Workshop 2020: Call for Volunteers
Introduction to Lwt
Other OCaml News
Old CWN
Multicore Update: April 2020, with a preprint paper
═══════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/multicore-update-april-2020-with-a-preprint-paper/5630/26]
Continuing this thread, Daniel Bünzli asked and KC Sivaramakrishnan replied
───────────────────────────────────────────────────────────────────────────
One thing that I didn’t get from the paper is how exactly
`ConcurMinor' breaks the current FFI and the impact it
would have on the existing eco-system, on a scale from “it
affect all projects” to “only people doing *that* fancy
thing” :–) ?
All the projects that use the C API. The details are here:
[https://github.com/ocaml-multicore/ocaml-multicore/wiki/C-API-changes]
At the end of the paper it seems you make the point that
`ParMinor' is the solution to go with for the time
being. Does this means you are going to leave behind the
work done on `ConcurMinor' or do you intend to continue to
maintain it ?
We don't intend to maintain it. It is quite a bit of work to maintain
and port the changes across two different GCs. `ParMinor' GC is now
at 4.11 branch point (the default multicore compiler is 4.10 +
ParMinor now). The `ConcMinor' is at 4.06.1.
Given that `ConcMinor' breaks the C API, the ecosystem would have to
be fixed for `ConcMinor' to be useful. The code changes are indeed
intricate; the differences are not just in the minor GC, but the
compilers internal use of the C API. It will be quite a bit of work to
keep both GCs in the same source distribution.
Guillaume Munch-Maccagnoni then said
────────────────────────────────────
Given that `ConcMinor' breaks the C API, the ecosystem
would have to be fixed for `ConcMinor' to be useful.
I do not think this is necessarily true.
Here is why I think so, but be warned that this is preliminary as I do
not have time to explore this idea further on my own at the moment.
State in Rust
╌╌╌╌╌╌╌╌╌╌╌╌╌
Breaking the C API is a consequence of deciding that all
single-threaded shared mutable state must assume they are also shared
between threads. So a new read barrier is used to promote values when
read from another thread. But for data types that were correct up to
now, users must also be careful to avoid races from now on… for
instance by avoiding sharing values of such types between domains.
One lesson of Rust is that there are different kinds of mutable state,
for different usages, with different means to achieve thread-safety.
The closest there is to current OCaml's `mutable' is the notion of
single-threaded multiple-writers mutable state (_`Cell'_). It is made
thread-safe in Rust by statically preventing values containing `Cell'
from crossing thread boundaries (by virtue of not having the _`Send'
trait_). The same restriction is used to make some data structures
more efficient by avoiding the cost of synchronisation (cf. the
reference-counting pointer `Rc' vs. the atomic reference-counting
pointer `Arc').
This is not enough by itself, and Rust offers other kinds of state for
communicating and sharing values between threads.
_`UnsafeCell'_ like Ocaml multicore's `mutable' (though yours is safe
thanks to the work on the memory model): it has almost no restriction
and can be sent across domains, but the user is likewise told to
“avoid data races”. It is rarely used alone, but together with type
abstraction it can be used to program safe concurrent data structures.
Lastly, the default notion of state in Rust is linear state, which can
be sent freely across threads. Thread-safety is ensured by restricting
aliasing using the ownership and borrowing discipline.
A backwards-compatible concurrent collector?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
If I had to imagine a backwards-compatible OCaml with static control
of interference à la Rust based on `ConcMinor', it would distinguish
the three kinds of state (concretely with other keywords in addition
to `mutable'). `mutable' would keep its current meaning of
single-domain, multiple-writers state and not require a read barrier,
and in particular preserve the API. (I count systhreads as
single-threaded for this purpose, since here it means "sharing the
same minor heap".)
Programs could progressively transition to other kinds of state when
parallelising the program. Concretely, a data structure like
`Stack.t', instead of becoming racy, would keep its current meaning,
but users could replace it with a linear stack or a concurrent stack,
two data structures distinct from the first one, when parallelizing
their programs.
So how could this fit with the current plans? It is not entirely clear
to me. If people start to rely on parallelism in an unstructured way
(e.g. no clear distinction between different kinds of data types
arising from different ways of ensuring thread-safety) then one will
also lose the ability to retrofit `ConcMinor' in a
backwards-compatible manner (by losing the information that the
current `mutable' API is single-threaded). The API breakage of
`ConcMinor' which might only be virtual right now (if I trust this
preliminary, not fully-explored idea) will become real. (Further
difficulties arise with the emulation of the `Thread' library with
domains, but this could be changed later.)
But if users are provided in advance with a general direction for a
model of control of interference this might happen differently. And
eventually having such a model is desirable in any case, as it helps
parallelizing programs (for instance the Firefox people reported that
they had attempted and failed twice to parallelise the CSS engine in
C++ before succeeding with Rust). Furthermore, in an imaginary
retrofitting of `ConcMinor', one could imagine enforcing something
like the `Send' trait at the level of the read barrier until there is
a better way (there would be two kinds of barriers, one of which would
raise an exception if a state happened to be incorrectly shared across
domains, and not be required in the FFI).
I find `ConcMinor' interesting from a systems programming perspective
compared to the stop-the-world collector because it could (I hope)
offer possibilities such as having a low-latency domain communicating
with a higher-latency domain. Moreover the performance cost of the
read barrier might be lower in this scheme if it could be removed for
all but the concurrent data structures.
BAP 2.1.0 Release
═════════════════
Archive: [https://discuss.ocaml.org/t/ann-bap-2-1-0-release/5906/1]
Ivan Gotovchits announced
─────────────────────────
The Carnegie Mellon University Binary Analysis Platform ([CMU BAP]) is
a suite of utilities and libraries that enables analysis of programs
that are represented as machine code (aka binaries). CMU BAP is
written in OCaml and uses plugin-based architecture to enable
extensibility. We also have a domain-specific language, called Primus
Lisp, that we use to write analysis, specify verification conditions,
interact with the built-in SMT solver, and model the semantics of
machine instructions and functions.
The 2.1.0 Release is very rich in [new features] but the most
prominent addition is the new [symbolic executor] mode for the Primus
framework. We also significantly updated the Primus framework,
integrated it with our new Knowledge Base, which was introduced in the
BAP 2.0 release; we made our interpreter much faster; we added the
systems and components facilities, inspired by Common Lisp; and we
implemented a gradual type checker for Primus Lisp with type
inference. We also added an ability to represent machine instructions
as intrinsic functions so now it is possible to express their
semantics using Primus Lisp since we added IEEE754 primitives to the
Lisp interpreter.
As usual, we upgraded BAP to the newer versions of the Core library
and OCaml (we now support OCaml versions from 4.07 to 4.09). We also
significantly improved our build times and added an optional omake
backend, which we are using in-house.
From the user perspective, one of the key features of BAP as an
analysis platform is that you can run BAP on binaries that you can't
run otherwise, either because they need special hardware or software,
or need to interact with the outside world. In the past couple of
months, we have run BAP on various firmware and found numerous
zero-day vulnerabilities, particular, we were able to find critical
vulnerabilities in the VxWorks operating system that runs on,
potentially, billions of devices including mission-critical and
military appliances.
As always, questions, suggestions, and opinions are very welcome!
[CMU BAP] https://github.com/BinaryAnalysisPlatform/bap
[new features]
https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.1.0
[symbolic executor]
https://github.com/BinaryAnalysisPlatform/bap/pull/1105
Migrating an Async project to Lwt, a short primer
═════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/migrating-an-async-project-to-lwt-a-short-primer/5908/1]
Michael Bacarella announced
───────────────────────────
Consider this a post where I think aloud about my experience migrating
an Async project to Lwt. I've spent about a weekend doing such a
thing, and if, in the process of talking about it here I can save a
few people an hour or two (or perhaps inspire confidence to take such
a project on in the first place) then it will have been worthwhile.
This wouldn't be a complete post if I didn't also mention @dkim's
[translation of Real World OCaml's Async examples to Lwt]
This was born out of a previous effort where I [tried to mix Lwt and
Async in the same project]. This didn't go so well, so I tried
converting the whole thing to Lwt, and it turns out adapting to Lwt if
you're an Async person is actually much easier than I thought it would
be.
[translation of Real World OCaml's Async examples to Lwt]
https://github.com/dkim/rwo-lwt
[tried to mix Lwt and Async in the same project]
https://discuss.ocaml.org/t/best-practices-on-mixing-lwt-and-async/5372
Basics
╌╌╌╌╌╌
Both libraries involve promises/futures. Async calls its promises
`Deferred.t', whereas in Lwt they're called `Lwt.t'.
In Async you start your program by saying `never_returns (Scheduler.go
())' or `Command.async_spec' after you set up your initial
`Deferred.t'.
In Lwt you say `Lwt_main.run' on a top-level `Lwt.t' argument. Note
you can re-run `Lwt_main.run' in a single program as many times as you
want, but perhaps you shouldn't run multiple `Lwt_main.run' in
parallel.
There's an easy correspondence between basic operators.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Async Lwt
────────────────────────────────────────────────────
`Deferred.bind' `Lwt.bind'
`Deferred.return' `Lwt.return'
`>>=' `>>='
`Deferred.map' `Lwt.map'
`>>|' `>|='
`Deferred.don't_wait_for' `Lwt.async'
`In_thread.run' `Lwt_preemptive.detach'
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Starvation worries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The most important difference between Async and Lwt is that *fulfilled
promises are acted on immediately*, whereas Async kinda punts them to
the end of a work queue and runs their thunks later.
A return loop like this starves the rest of Lwt:
┌────
│ open Lwt.Infix
│
│ let main () =
│ let rec loop () =
│ Lwt.return ()
│ >>= fun () ->
│ loop ()
│ in
│ Lwt.async (loop ());
│ Lwt_io.printlf "this line never prints!"
│ ;;
│
│ let () = Lwt_main.run main ;;
└────
whereas the corresponding Async loop does not starve:
┌────
│ open! Async
│
│ let main () =
│ let rec loop () =
│ Deferred.return ()
│ >>= fun () ->
│ loop ()
│ in
│ don't_wait_for (loop ());
│ printf "this line does print!\n";
│ return ()
│ ;;
│
│ let () =
│ let cmd = Command.async_spec ~summary:"" Command.Spec.empty main in
│ Command.run cmd
│ ;;
└────
Fortunately there's a workaround. You can get something closer to the
Async-style behavior in Lwt by using `Lwt.yield ()' instead of
`Lwt.return ()'.
Spawning threads
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
From time to time you may need to run something in a system thread.
In Async you say `In_thread.run', whereas in Lwt you say
`Lwt_preemptive.detach'. For simple things they're pretty much
interchangeable, but one stumbling point for me was that in Async you
can create a named thread and always use that for the `In_thread.run',
with multiple simultaneous dispatches to that thread becoming
sequenced.
This is really useful for interacting with libraries that aren't so
thread friendly.
Lwt's detach doesn't provide an easy way to do this out of the box,
but I think you can still deal with thread unfriendly libraries by
using the `Lwt_preemptive.run_in_main' call.
Basically, never exit the detach thread you started to interact with
your library, and instead have it block on promise that gets filled
through run_in_main. In this way you can sequence your detached Lwt
thread similarly to Async.
Happy to explain further if this is unclear.
Other libraries
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`Async.Unix' has a somewhat built-up conception of the UNIX API,
whereas `Lwt_main' is more a direct mapping of ocaml's `Unix' module
to promises.
Async `Clock.every' and `Clock.after' don't have exact analogs, but
you can make new versions pretty simply.
Example of a shallow imitation of Async `Clock.every'
┌────
│ let every span f =
│ Lwt.async (fun () ->
│ let span = Time.Span.to_sec span in
│ let rec loop () =
│ f ();
│ Lwt_unix.sleep span
│ >>= fun () ->
│ loop ()
│ in
│ loop ())
│ ;;
└────
*Open questions*
I haven't sorted out a good Lwt substitute that's as comfortable as
Async Pipe yet. Though some combination of Lwt_stream, Lwt_sequence
and `lwt-pipe' might fit the bill. If you just happen to know already
feel free to cluephone.
Closing remarks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This is basically everything? I'm almost suspicious that I'm not
having more problems, but will happily accept grace when it arises.
Raphaël Proust then said
────────────────────────
I haven’t sorted out a good Lwt substitute that’s as
comfortable as Async Pipe yet. Though some combination of
Lwt_stream, Lwt_sequence and `lwt-pipe' might fit the
bill. If you just happen to know already feel free to
cluephone.
The Tezos project has a pipe-like module:
[https://gitlab.com/tezos/tezos/-/blob/master/src/lib_stdlib/lwt_pipe.mli]
It hasn't been released as a standalone library (yet) but it is
released as part of the `tezos-stdlib' package.
I haven't used Async's pipe, so I don't know how close of a match it
is.
jose 0.4.0
══════════
Archive: [https://discuss.ocaml.org/t/ann-jose-0-4-0/5909/1]
Ulrik Strid announced
─────────────────────
A new release of JOSE has been published to opam
The following changes has been made
• RFC7638: Implement thumbprints @undu
• Make kid optional in the header and jwk to align better with the
spec, this is a breaking change
I have started dog fooding the library for a OpenID Connect client
which hopefully will help with the design going forward.
OCaml 4.11.0, second alpha release
══════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-second-alpha-release/5910/1]
octachron announced
───────────────────
A new alpha version of OCaml 4.11.0 has been published. Compared to
the first alpha version, this version contains the following new bug
fixes:
• *additional fixes* [6673], [1132], [+9617]: Relax the handling of
explicit polymorphic types (Leo White, review by Jacques Garrigue
and Gabriel Scherer)
• *additional fixes* [7364], [2188], [+9592], [+9609]: improvement of
the unboxability check for types with a single
constructor. Mutually-recursive type declarations can now contain
unboxed types. This is based on the paper
[https://arxiv.org/abs/1811.02300]
• [7817], [9546]: Unsound inclusion check for polymorphic variant
(Jacques Garrigue, report by Mikhail Mandrykin, review by Gabriel
Scherer)
• [9549], [9557]: Make -flarge-toc the default for PowerPC and
introduce -fsmall-toc to enable the previous behaviour. (David
Allsopp, report by Nathaniel Wesley Filardo, review by Xavier Leroy)
• [9320], [9550]: under Windows, make sure that the Unix.exec*
functions properly quote their argument lists. (Xavier Leroy, report
by André Maroneze, review by Nicolás Ojeda Bär and David Allsopp)
• [9490], [9505]: ensure proper rounding of file times returned by
Unix.stat, Unix.lstat, Unix.fstat. (Xavier Leroy and Guillaume
Melquiond, report by David Brown, review by Gabriel Scherer and
David Allsopp)
• [8676], [9594]: turn debugger off in programs launched by the
program being debugged (Xavier Leroy, report by Michael Soegtrop,
review by Gabriel Scherer)
• [9552]: restore ocamloptp build and installation (Florian Angeletti,
review by David Allsopp and Xavier Leroy)
• [7708], [9580]: Ensure Stdlib documentation index refers to
Stdlib. (Stephen Dolan, review by Florian Angeletti, report by
Hannes Mehnert)
• [9189], [9281]: fix a conflict with Gentoo build system by removing
an one-letter Makefile variable. (Florian Angeletti, report by Ralph
Seichter, review by David Allsopp and Damien Doligez)
The compiler can be installed as an OPAM switch with one of the
following commands
┌────
│ opam switch create ocaml-variants.4.11.0+alpha2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+alpha2+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where <VARIANT> is replaced with one of these: afl, flambda, fp,
fp+flambda
The source code for the alpha is also available at these addresses:
• [https://github.com/ocaml/ocaml/archive/4.11.0+alpha2.tar.gz]
• [https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+alpha2.tar.gz]
If you find any bugs, please report them here:
[https://github.com/ocaml/ocaml/issues]
[6673] https://github.com/ocaml/ocaml/issues/6673
[1132] https://github.com/ocaml/ocaml/issues/1132
[+9617] https://github.com/ocaml/ocaml/issues/9617
[7364] https://github.com/ocaml/ocaml/issues/7364
[2188] https://github.com/ocaml/ocaml/issues/2188
[+9592] https://github.com/ocaml/ocaml/issues/9592
[+9609] https://github.com/ocaml/ocaml/issues/9609
[7817] https://github.com/ocaml/ocaml/issues/7817
[9546] https://github.com/ocaml/ocaml/issues/9546
[9549] https://github.com/ocaml/ocaml/issues/9549
[9557] https://github.com/ocaml/ocaml/issues/9557
[9320] https://github.com/ocaml/ocaml/issues/9320
[9550] https://github.com/ocaml/ocaml/issues/9550
[9490] https://github.com/ocaml/ocaml/issues/9490
[9505] https://github.com/ocaml/ocaml/issues/9505
[8676] https://github.com/ocaml/ocaml/issues/8676
[9594] https://github.com/ocaml/ocaml/issues/9594
[9552] https://github.com/ocaml/ocaml/issues/9552
[7708] https://github.com/ocaml/ocaml/issues/7708
[9580] https://github.com/ocaml/ocaml/issues/9580
[9189] https://github.com/ocaml/ocaml/issues/9189
[9281] https://github.com/ocaml/ocaml/issues/9281
OCaml Workshop 2020: Call for Volunteers
════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-workshop-2020-call-for-volunteers/5913/1]
Ivan Gotovchits announced
─────────────────────────
The OCaml Workshop will be held in the virtual format this year, which
poses new challenges and requires people with special talents and
training. The Organizing Committee is seeking for members who will
volunteer to fill one (or more) of the following roles:
1. AV Editor
2. Session Host
3. Transcribers/Interpreter
4. Content Manager
5. Accessibility Chair
The roles are described in details below. We are asking prospective
Organizing Committee members to contact the Organizing Committee chair
([ivg@ieee.org]([mailto:ivg@ieee.org])), indicating which role(s) they
are ready to take.
[AV Editor]
╌╌╌╌╌╌╌╌╌╌╌
AV (Audio/Video) editors are responsible for previewing the
presentations and providing help and feedback to the authors. Ideally
we target for one editor per talk.
[AV Editor] https://icfp20.sigplan.org/home/ocaml-2020#av-editor
◊ [Duties]
• Preview and (if necessary) post-process or (ask the author to shoot
again) the pre-recorded videos.
• Advise authors and help in choice of software and hardware, teach
how to set up the camera, light, make sure that the audio is of good
quality and, in general, channel our quality guidelines.
• Ensure that all videos are of the same quality, the audio levels are
the same, and that everything is loud and clear.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Session Hosts]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Session hosts will assist session chairs in streaming the pre-recorded
videos as well as helping and moderating the Q&A sessions and the
panel session. They will also be responsible for security and be ready
to react to potential threats and wrongdoers. Since we will broadcast
sessions in several time zones we need several hosts for each session.
[Session Hosts] https://icfp20.sigplan.org/home/ocaml-2020#session-hosts
◊ [Duties]
• Moderating the text chats
• Controlling microphones in the video-conferencing
• Watching for the time
• Performing sound checks
• Welcoming and otherwise guiding participants
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Transcribers / Interpreters]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We would like to have at least English transcriptions for each talk
and translations to other languages are very welcome. Transcriptions
enable accessibility as well as potentially increase the audience and
publicity as they could be indexed by the search engines.
[Transcribers / Interpreters]
https://icfp20.sigplan.org/home/ocaml-2020#transcribers-interpreters
◊ [Duties]
• Create transcriptions for videos, potentially in other languages.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
[Content Manager]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The content manager will be responsible for maintaining the web
presence of the conference on [https://ocaml.org/]. We plan to have
all videos available, as well as maintain a page for each submitted
work.
[Content Manager]
https://icfp20.sigplan.org/home/ocaml-2020#content-manager
[Accessibility Chair]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We are striving to make the conference accessible to everyone and we
are looking for volunteers who have experience in online
accessibility.
[Accessibility Chair]
https://icfp20.sigplan.org/home/ocaml-2020#accessibility-chair
◊ [Duties]
• Helping with the selection of accessible platforms and tools.
• Working with attendees to ensure the necessary access services are
included.
• Establishing best practices for preparing and running accessible
sessions.
[Duties] https://icfp20.sigplan.org/home/ocaml-2020#duties
Introduction to Lwt
═══════════════════
Archive: [https://discuss.ocaml.org/t/introduction-to-lwt/5940/1]
Raphaël Proust announced
────────────────────────
I've published
[https://raphael-proust.github.io/code/lwt-part-1.html], a 2-part
introduction to Lwt.
The main aim of the introduction is to give a good mental model of
what promises are, how they behave and how to use them. It assumes
basic familiarity with OCaml.
Don't hesitate to ask questions or share feedback.
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Using ASCII waveforms to test hardware designs]
[OCaml Planet] http://ocaml.org/community/planet/
[Using ASCII waveforms to test hardware designs]
https://blog.janestreet.com/using-ascii-waveforms-to-test-hardware-designs/
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 46346 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-19 9:52 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-05-19 9:52 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 26620 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 12 to 19,
2020.
Table of Contents
─────────────────
ocamlformat 0.14.2
ML Family Workshop 2020: Call for presentations
memprof-limits preview (and a guide to handle asynchronous exceptions)
Tezos 7.0 is now available on opam
Official OCaml bindings for verified Everest cryptography
nmea and sail-gadgets
Is there specialized math library for statistics?
New OCaml books?
Other OCaml News
Old CWN
ocamlformat 0.14.2
══════════════════
Archive: [https://discuss.ocaml.org/t/ann-ocamlformat-0-14-2/5754/1]
Guillaume Petiot announced
──────────────────────────
We are pleased to announce the release of `ocamlformat' 0.14.2. This
minor release improves the recent 0.14.0 and 0.14.1 releases regarding
the `doc-comments' option.
How to migrate from 0.13.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Here are the changes of the `doc-comments' options compared to
ocamlformat 0.13.0:
• `after' has been renamed to `after-when-possible' to take into
account the technical limitations of ocamlformat;
• a new value `before-except-val' has been added, placing doc-comments
before the corresponding code, but placing doc-comments of val and
external declarations after the corresponding declaration;
• `before' is unchanged.
Here is the full list of changes made by the 0.14.0 release:
[https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435]
How to migrate from 0.14.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The 0.14.0 release lead to some regression of the `doc-comments'
behavior that (although intended for us) lead to some surprise from a
lot of users. The behavior of `doc-comments' has thus been reverted
to it's 0.13.0 state with the following changes:
The `doc-comments-val' option has been removed and merged with
`doc-comments'. The placement of documentation comments on `val' and
`external' items is now controlled by `doc-comments' .
• `doc-comments=after' becomes `doc-comments=after-when-possible' to
take into account the technical limitations of ocamlformat;
• `doc-comments=before' is unchanged;
• `doc-comments-val' is now replaced with `doc-comments'
To reproduce the former behaviors
• `doc-comments=before' + `doc-comments-val=before' : now use
`doc-comments=before' ;
• `doc-comments=before' + `doc-comments-val=after' : now use
`doc-comments=before-except-val' ;
• `doc-comments=after' + `doc-comments-val=before' : this behavior did
not make much sense and is not available anymore;
• `doc-comments=after' + `doc-comments-val=after' : now use
`doc-comments=after-when-possible'.
How to migrate from 0.14.1
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The 0.14.1 release was preserving the behavior of 0.13.0 regarding
`doc-comments', it added a `unset' value to the `doc-comments-val'
option. This option has been removed with the following changes:
The `doc-comments-val' option has been removed and merged with
`doc-comments'. The placement of documentation comments on `val' and
`external' items is now controlled by `doc-comments' .
• `doc-comments=after' becomes `doc-comments=after-when-possible' to
take into account the technical limitations of ocamlformat;
• `doc-comments=before' is unchanged;
• `doc-comments-val' is now replaced with `doc-comments'
To reproduce the former behaviors
• `doc-comments=before' + `doc-comments-val=before' : now use
`doc-comments=before' ;
• `doc-comments=before' + `doc-comments-val=after' : now use
`doc-comments=before-except-val' ;
• `doc-comments=after' + `doc-comments-val=before' : this behavior did
not make much sense and is not available anymore;
• `doc-comments=after' + `doc-comments-val=after' : now use
`doc-comments=after-when-possible'.
Thank you
╌╌╌╌╌╌╌╌╌
We would like to thank our early users to help us on the road of a
stable 1.0.0 release of ocamlformat.
ML Family Workshop 2020: Call for presentations
═══════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ml-family-workshop-2020-call-for-presentations/5441/4]
Leo White announced
───────────────────
ICFP, and by extension the ML workshop, will be now officially be held
online with a significantly reduced fee. Due to the change in official
status we decided to extend the submission deadline to the end of May.
Important Dates (updated)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Friday 29th May (any time zone): Abstract submission deadline
• Friday 17th July: Author notification
• Thursday 27th August: ML Family Workshop
memprof-limits preview (and a guide to handle asynchronous exceptions)
══════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-memprof-limits-preview-and-a-guide-to-handle-asynchronous-exceptions/5756/1]
Guillaume Munch-Maccagnoni announced
────────────────────────────────────
Dear OCamlers, I am happy to pre-announce [memprof-limits], an
implementation of per-thread global memory limits, and per-thread
allocation limits à la Haskell, compatible with systhreads.
Memprof-limits interrupts the execution by raising an _asynchronous
exception_, an exception that can arise at almost any location in the
code. I also announce [a guide on how to recover from asynchronous
exceptions and other unexpected exceptions] that you find in the
documentation. It summarises knowledge acquired in OCaml by the Coq
proof assistant as well as in other programming languages. To my
knowledge, this has never been told in OCaml textbooks, so I thought
it might be of general interest to you. This research is part of a
wider work aiming to regulate the use of asynchronous exceptions in
OCaml in coordination with multicore language designers.
_Global memory limits_ let you bound the memory consumption inside
specific parts of your program, in terms of memory used by the whole
program. It is inspired by [this other post], but in a form readily
available for use with systhreads.
_Allocation limits_ let you bound the execution of parts of the
program measured in number of allocations, analogous to the same
feature in Haskell advocated in [a nice post by Simon
Marlow]. Allocation limits count allocations but _not_ deallocations,
and is therefore a measure of the work done, which can be more
suitable than execution time.
Memprof-limits, as the name tells, uses the upcoming Memprof engine
from OCaml 4.11, with a low sampling rate that does not affect
performance. A reimplementation of the Memprof interface compatible
with memprof-limits running at the same time is provided for profiling
needs.
Memprof-limits is available on the public opam repository, but depends
on OCaml 4.11 which at the moment is available from the beta opam
repository only. It is _experimental_ for reasons explained in the
manual.
[memprof-limits] https://gitlab.com/gadmm/memprof-limits
[a guide on how to recover from asynchronous exceptions and other
unexpected exceptions] https://gitlab.com/gadmm/memprof-limits#recover
[this other post]
https://discuss.ocaml.org/t/todays-trick-memory-limits-with-gc-alarms/4431
[a nice post by Simon Marlow]
https://simonmar.github.io/posts/2017-01-24-asynchronous-exceptions.html
FAQ
╌╌╌
◊ “Is it wise to rely on the statistical nature of Memprof? If I set an allocation limit of 100 KB, and run a function that allocates exactly 50 KB, then the function might fail, due to the random nature of Memprof.”
Memprof-limits is provided with a [statistical analysis] meant to help
you chose appropriate values for the limit depending on a target safe
allocation value. (Nice pictures omitted because this discuss does not
support svg.)
Long story short, memprof-limits starts being accurate-enough starting
around a safe allocation value of 100 KB with the default sampling
rate (meaning a limit of 1 to 3 MB depending on chosen precision),
with the ratio between the maximal safe allocation and the limit
dropping very quickly for higher values. Correctly, the analysis shows
that limits under 500 KB are unreliable.
I have found that the statistical nature of Memprof makes it very easy
to reason about its application and not have to factor in runtime
implementation details. In addition, Memprof is nevertheless
deterministic, which is (essential and) useful for reproducing runs in
test scenarios.
[statistical analysis]
https://gitlab.com/gadmm/memprof-limits#statistical
◊ “But can we really program with memprof-limits, that is, not only write programs but also reason about them, given the probabilistic nature of the guarantees?”
Yes, if we make two additional hypotheses:
1. Allocation limits (as used in Haskell) are used by determining peak
reasonable allocation usage empirically and picking a limit at a
comfortable margin over it, rather than computing a precise memory
bound to be used as a limit. In very controlled environments where
the latter would be possible, there probably would be better
solutions, and the language this is inspired from makes it very
hard to make predictions on memory use.
2. The programmer is fine with a very unlikely possibility of a false
positive; indeed the program is already designed to let true
positives fail without bringing down mission-critical parts of the
program. For instance they can prefer to see a legitimate client
having a connexion closed once every 10ⁿ year for *n* of their
choosing, if that is the price to pay for avoiding being subject to
DOS on maliciously-crafted requests.
Under these hypotheses, the statistical limit is just as reliable as
the precise limits à la Haskell.
◊ “Is it possible to also implement _local memory limits_, to bound the memory consumption of a particular function?”
Yes but read on.
[Yang & Mazières (2014)] advocates in favour of an _allocator-pays_
model of cost attribution, and note its similarity with memory
profiling. In this model, it is possible for instance to process
untrusted user input under some memory limit, before the result is
distributed to the rest of the program.
Implementing memory limits based on the allocator-pays model, by
adapting allocation limits to take into account deallocations, would
be very easy thanks to the facilities provided by Memprof. Moreover,
the statistical analysis of allocation limits can be transposed, and
guarantees similarly accuracy at a low runtime cost for limits greater
than 100KB.
There is one surprising difficulty, though, which has to do with the
way the GC works. The GC has a space overhead: memory that is wasted
because unreachable values are not collected immediately. This
overhead has to be taken into account when choosing the
limit. However, this overhead is non-local and dependent on the
_total_ major heap size: one cannot just say “take the double of the
desired limit”. Indeed, active threads will pay for memory that has
been allocated in the past and kept alive. More experimentation is
needed to provide guidance on how to take the space overhead into
account.
[Yang & Mazières (2014)]
https://dl.acm.org/doi/10.1145/2594291.2594341
◊ “Can this be used to bound the consumption of lightweight threads in Lwt and Async?”
It is straightforward to make memprof-limits parametric in the notion
of _thread id_ used to track per-thread limits. However, to the best
of my knowledge, Lwt and Async are not meant to play well when the
computation is interrupted by asynchronous exceptions. If you have
more information about this limitation or are interested in
experimenting, please get in touch.
Thanks
╌╌╌╌╌╌
Thank you to Jacques-Henri Jourdan for his explanations about Memprof
and Stephen Dolan for his feedback.
Tezos 7.0 is now available on opam
══════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-tezos-7-0-is-now-available-on-opam/5764/1]
Pierre Boutillier announced
───────────────────────────
Tezos executables and libraries have just been released on `opam'. You
can thus build them from source with a simple `opam install tezos' and
build your own projects upon them.
What is Tezos
╌╌╌╌╌╌╌╌╌╌╌╌╌
Tezos is a distributed consensus platform with meta-consensus
capability. Tezos not only comes to consensus about the state of its
ledger, like Bitcoin or Ethereum. It also comes to consensus about how
the protocol and the nodes should adapt and upgrade. For more
information about the project, see [https://tezos.com].
Our implementation of Tezos is written in OCaml. It is split into
several libraries (command-line interface `tezos-clic', peer-to-peer
library `tezos-p2p', cryptographic primitives `tezos-crypto~…) and
executables (node ~tezos-node', client ~tezos-client~…).
Useful Links
╌╌╌╌╌╌╌╌╌╌╌╌
Source code for this particular implementation can be found at
[https://gitlab.com/tezos/tezos/]. Developer documentation is
available at [https://tezos.gitlab.io/]. In particular, documentation
for this specific release (version 7.0) is available at
[http://tezos.gitlab.io/releases/version-7.html].
Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Tezos (internal compiler in order to self amend itself) requires a
specific version of the compiler (OCaml 4.09.1):
┌────
│ opam switch 4.09.1
└────
Tezos also requires some external libraries:
┌────
│ opam depext tezos
└────
Finally, to install all binaries:
┌────
│ opam install tezos
└────
Replying to Nick Betteridge, Raphaël Proust said
────────────────────────────────────────────────
Tezos has a soft-updating mechanism that works (roughly) as follows:
The network starts with a genesis protocol (“protocol” here means
“economic protocol”: the rules according to which smart contracts are
initiated and acted upon, transactions take place, etc.) in which a
single public key is specified.
The genesis protocol has no notion of coin, currency, smart-contract,
etc. Instead, the genesis protocol knows a single operation: a
protocol injection.
The protocol injection for genesis requires the operation to be signed
by the private key that matches the public key of the genesis
block. And the protocol injection changes, irreversibly, the genesis
protocol to a new protocol. This new protocol specifies what
constitutes a valid block to add to the chain.
In the Tezos blockchain, the protocol injected on top of genesis
included a notion of coins and an in-protocol voting system to inject
new protocols based on consensus amongst coin-holders. There is even a
system to obtain the protocol sources over the blockchain network so
they can be compiled by each node and dynlinked directly in: you don't
need to update/restart your node to get the protocol updates. However,
this is arbitrary: you can start a new block-chain with a different
protocol.
For example, you could re-implement Bitcoin (proof-of-work,
coins+transfer, etc.) as a protocol that you inject on top of
genesis. Your block chain would have a tezos genesis block, then a
block that activate your own version of bitcoin, and then the blocks
would be similar to what you would find on the bitcoin block-chain.
Of particular interest to you, the protocol you inject can have
entirely different on-chain notions (e.g., a TCG/CCG with no coins at
all but a notion of ownership over cards) and different soft-updating
mechanism (e.g., the new protocol can accept genesis-style updates (a
“dictatorship” where a single person controls the protocol) or even no
soft-updating mechanism at all (a “stale” protocol where you need to
hard-fork if you want to make significant changes)).
For this use case (of starting your own chain with a different
protocol), you might be better off cloning the git repository, doing
some minimal clean up, etc. This is because the tezos binaries include
the sources for all protocols that have been used on the chain (so you
don't *need* to get them over the network even if you can).
You might be interested in the following blog post about how to write
your own protocol:
[https://blog.nomadic-labs.com/how-to-write-a-tezos-protocol.html]
Official OCaml bindings for verified Everest cryptography
═════════════════════════════════════════════════════════
Archive:
[https://sympa.inria.fr/sympa/arc/caml-list/2020-05/msg00017.html]
Jonathan Protzenko announced
────────────────────────────
The Everest team is pleased to announce the release of official OCaml
bindings for all of our verified cryptographic algorithms, now
available through OPAM as packages hacl-star and hacl-star-raw.
We provide bindings for the following:
• HACL*, a library of pure C algorithms
• Vale, a collection of optimized core assembly routines for maximum
performance
• EverCrypt, an agile, multiplexing API with CPU auto-detection that
brings together HACL* and Vale.
Our code is compiled from the F* programming language to C via the
KReMLin compiler ("K&R meets ML"). We offer two OPAM packages:
• hacl-star-raw consists of low-level ocaml-ctypes bindings generated
by KReMLin
• hacl-star is a hand-written OCaml idiomatic API that uses much more
pleasant signatures, types and abstractions and is also safer, as it
checks all static preconditions at run-time
We support AES{128,256}-GCM, Chacha20-Poly1305, Curve25519 / Ed25519,
P256, MD5, SHA-{1,2,3} (all variants), Blake2 (s&b), HMAC/HKDF, and
the HPKE and SecretBox high-level APIs. Some algorithms are optimized
for Intel chips, notably AES-GCM – see
[https://hacl-star.github.io/Supported.html] for full details.
General documentation about the project is available at
[https://hacl-star.github.io/index.html] – sample code for the OCaml
API is provided as part of the test suite
[https://github.com/project-everest/hacl-star/tree/master/bindings/ocaml/tests]
This work was performed by Victor Dumitrescu from Nomadic Labs, one of
the teams responsible for the core development of the Tezos
blockchain.
nmea and sail-gadgets
═════════════════════
Archive: [https://discuss.ocaml.org/t/ann-nmea-sail-gadgets/5773/1]
Davide Gessa announced
──────────────────────
Ahoy developers, few days ago I published a new ocaml library called
*nmea*, which is essentially a parser for NMEA0183 sentences, a format
for encoding instruments data in boats. There are many sentences,
regarding GPS, compass data, wind, air pressure, water temperature,
waypoints handling, ais, autopilot and more; at the moment the library
is able to decode GPS sentences and compass data, but I'll implement
more sentences in the spare time. I tested it with my boat GPS and
with a gps usb dongle.
After that, I started a new tiny experiment called *sail-gadgets*,
which is a Gtk program that elaborates and displays NMEA data received
from various boat instruments (wind vane, autopilot, gps, radar, ais,
etc). Sail-gadgets can be extended with "gadgets" modules, each one
providing new functionalities and new tabs to the main interface.
Data from sensors are handled using /React/ signals, so in every
gadget we can compose data from various sensor to obtain new reactive
values.
The gadgets I'm planning to write:
• dashboard: shows current position, speed, heading, tripdist, compass
• satview: shows current connected gps satellites (partially done)
• wind: shows wind indicator with true / apparent speed and direction
• radar: shows AIS and Radar targets in range
• mob: allows to drop a marker in the current position, and drive you
to that point
• startline: helper for regatta start
• track: shows current track in a vector map
The hard thing in my opinion is writing new custom widget with cairo
(compass, radar, and things like that).
Finally, the project is intended to run over *gtk-broadway*, so every
html5 enabled device can access the application.
[https://raw.githubusercontent.com/dakk/sail-gadgets/master/media/broadway.jpg]
Hope there are some sailor here that want to join writing some gadgets
:) Repos are:
• [https://github.com/dakk/nmea]
• [https://github.com/dakk/sail-gadgets]
Is there specialized math library for statistics?
═════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/is-there-specialized-math-library-for-statistics/5778/1]
hss asked
─────────
I searched to find math library which is written in OCaml, but there
are only few repositories.
I'd like to use some function like coefficient correlation,
covariance, etc.
I found Lacaml but it seems not to support them.
Could you give some link if you know?
bnguyenvanyen replied
─────────────────────
Hi, you can take a look at Owl : [https://ocaml.xyz/]
There are stat functions and also a lot more
UnixJunkie also replied
───────────────────────
There is also this one:
[https://github.com/superbobry/pareto]
GSL powered OCaml statistics library
[http://superbobry.github.io/pareto/0.2]
And probably even some more:
┌────
│ opam search statistic
│ # Packages matching: match(*statistic*)
│ # Name # Installed # Synopsis
│ [...]
│ gsl -- GSL - Bindings to the GNU Scientific Library
│ oml -- Math Library
│ owl -- OCaml Scientific and Engineering Computing
│ owl-plplot -- OCaml Scientific and Engineering Computing
│ pareto -- GSL powered OCaml statistics library.
│ statsd-client -- StatsD client library
│ [...]
└────
New OCaml books?
════════════════
Archive: [https://discuss.ocaml.org/t/new-ocaml-books/5789/1]
Axel Wintermann asked
─────────────────────
I wonder, why there are no new OCaml books since 2014 year? Many books
are published on Haskell, Scala, F# themes, but no OCaml. I think we
need new books for learning and for rising interest in our beautiful
language.
Takuma Ishikawa replied
───────────────────────
• There is an ongoing work for 2nd edition of Real World OCaml:
[http://dev.realworldocaml.org/].
• OCaml Scientific Computing is also ongoing:
[https://ocaml.xyz/book/].
• A Japanese book "コンピュータを操る", published in Feb. 2020 for
beginners of programming, uses OCaml Blockly:
[https://www.saiensu.co.jp/search/?isbn=978-4-7819-1470-1&y=2020#detail].
Weng Shiwei also replied
────────────────────────
A Chinese book [OCaml语言编程基础教程] ([an introduction to OCaml
language programming]) is published in 2018.
[OCaml语言编程基础教程] https://e.jd.com/30417662.html
[an introduction to OCaml language programming]
https://caml.inria.fr/about/books.en.html#idm277
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Every proof assistant: MMT]
[OCaml Planet] http://ocaml.org/community/planet/
[Every proof assistant: MMT]
http://math.andrej.com/2020/05/15/mmt-a-foundation-independent-logical-system/
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 42565 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-12 7:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-05-12 7:45 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 15797 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of May 05 to 12,
2020.
Table of Contents
─────────────────
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
Are there learning materials for OCaml for those with no programming experience?
Dune meeting notes
OCaml 4.11.0, first alpha release
OCaml Users and Developers Meeting 2020
VSCode Platform Plugin 0.5.0
Other OCaml News
Old CWN
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/looking-for-lovely-idiomatic-examples-of-ocaml-used-for-shell-scripting-in-the-manner-of-perl-python-but-esp-perl/5703/13]
Continuing this thread, Chet Murthy said and Aaron L. Zeng replied
──────────────────────────────────────────────────────────────────
• needs to be Ocaml code, not an interpreter. I mean, if
I’m not going to write it in Ocaml, I might as well
write in Perl, yes?
I think shexp might deserve another look. It's not an interpreter for
a sexp-based shell language, as its name might unfortunately
deceivingly suggest. It's really a DSL for constructing shell
pipelines using a `'a Process.t' monad. The s-expression part is
advertising that you can debug and trace the actions performed using
s-expressions.
The second-most-important part of Perl/Bash scripting is
string-handling. And it’s certainly the part of Ocaml
that’s most painful when writing scripts. Let’s stipulate
that there are nice libraries to make this easy. I’m an
Ocaml bigot, I have to believe this anyway *grin* . This
library doesn’t seem to use 'em, nor choose/promote a
particular set of such libraries.
I've found [Base] plus [Re] to be sufficient for most of my
string-manipulation needs. It's never going to be as concise as
Perl's built-in "magic" support for regexps, but you gain explicitness
and clarity, which is part of the benefit of OCaml anyway.
[Base] https://github.com/janestreet/base/
[Re] https://github.com/ocaml/ocaml-re
Chet Murthy said and Donn Cave replied
──────────────────────────────────────
It’s not as trivial in Ocaml, for many complicated reasons
that boil down to “gee, string-handling is a PITA”.
Really? hadn't noticed. Ha ha.
I could never really get urge for Perl, but I use its ancestor awk a
lot, and I'm trying out some awk-like simple string functions, like
┌────
│ let strlen = String.length
│ let sub s i n = let b = strlen s
│ in if i < b
│ then let n = min n (b - i)
│ in String.sub s i n
│ else ""
│ (* substring to end of line *)
│ let substr a i = if i < strlen a
│ then String.sub a i ((strlen a) - i)
│ else ""
│ let matchre t s = try
│ Str.search_forward t s 0
│ with | Not_found -> -1
└────
etc.
So "open Awk" gets me a handful of more basic variations on common
string functions, with less elaborate parameters, no normal
exceptions, etc. Including a line by line file processing function.
I have just newly started on this and haven't used it extensively, but
it seems fairly promising. No wacky syntax or hyper intelligent
string processing, no packages, just a few dozen lines of cheater
functions.
"Awk" is a misnomer, in that there's little correspondence between
this and awk, it was just what inspired me to try it.
Raphaël Proust said
───────────────────
I don't think it's lovely and I have no idea if it is idiomatic, but I
made a few scripts of my own in OCaml using the same library that
other mentioned: `bos'
• [typepass] uses `xdotool' to type passwords from the `password'
password manager
• [conn] wraps `wpa_supplicant', `dhcpcd', `ip', and other network
management CLI
• [laptop-status] fetches status information for laptops (e.g.,
battery level) and prints it in a nicely formatted form
• [bakelite] increases or decreases screen brightness
[typepass] https://gitlab.com/raphael-proust/typepass
[conn] https://gitlab.com/raphael-proust/conn
[laptop-status] https://gitlab.com/raphael-proust/laptop-status
[bakelite] https://gitlab.com/raphael-proust/bakelite
Vasile Rotaru also said
───────────────────────
[https://github.com/hammerlab/genspio]
Gabriel Radanne also said
─────────────────────────
I have no particular opinion about the rest, but at least on the regex
side, this might be of interest:
[https://github.com/paurkedal/ppx_regexp]
If that's still not good enough, I would be very interested by
suggestions on how to make it more convenient. :)
OCamlUser proposed
──────────────────
I'm not sure about idiomatic, but I do have a utop config that I use
to do some one-off scripting in OCaml that uses `shexp'
┌────
│ #use "topfind"
│ #warnings "+a"
│ #thread
│ #require "ppx_jane,core"
│ #require "shexp.process"
│ #require "lambdasoup"
│ module List' = List
│ open Shexp_process
│ open Shexp_process.Infix
│ open Core
│
│ module Html = struct
│ include Soup
│
│ let of_string = parse
│ end
│
│ let read_lines cmd =
│ eval (call cmd |- read_all)
│ ;;
│
│ let wget url =
│ read_lines ["wget"; "-O"; "-"; url]
│ ;;
│
│ let chrome_curl url =
│ read_lines ["curl"; "-k"; "-sA"; "Chrome"; "-L"; url; "-o"; "-"]
│ ;;
│
│ let split_lines = String.split ~on:'\n'
│ let filter_lines substring = List.filter ~f:String.(is_substring ~substring)
│ let to_html = Html.of_string
│ let find_html pat html = Html.(html $$ pat)
│
│ let (%) = Fn.compose
└────
Then a simple script called `shexp' in my path:
┌────
│ utop -init ~/bin/ocaml-shexp-config
└────
I add little helper functions as I come upon them. I find it's much
easier to transition to a file, or full program when I need
it. Example program:
┌────
│ utop # read_lines ["sensors"] |> split_lines |> filter_lines "Core 0";;
│ - : string list =
│ ["Core 0: +63.0°C (high = +84.0°C, crit = +100.0°C)"]
└────
Anton Kochkov said
──────────────────
Not exactly OCaml, but can be made with the OCaml syntax as well - see
[BATSH].
[BATSH] https://github.com/batsh-dev-team/Batsh
Bikal Lem also said
───────────────────
I just found this - [https://github.com/ShamoX/cash]. @Chet_Murthy
This may be the closest to ocaml shell scripting experience re perl.
Are there learning materials for OCaml for those with no programming experience?
════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/are-there-learning-materials-for-ocaml-for-those-with-no-programming-experience/5684/9]
Continuing this threaad, Luc_ML said
────────────────────────────────────
Before studying more complex books, it's a good idea to first get an
overview.
[OCaml for the Skeptical / OCaml in a Nutshell] : the title is funny;
its main advantage is that it covers most OCaml concepts in *21 short
sections* where you can experiment by yourself on simple but essential
things.
The books/courses already mentioned are nice. You can also consider
this one that offers many examples/exercises and also a good overview:
[Developing Applications With Objective Caml].
LE LANGAGE CAML mentioned by @nojb is an excellent book. Written in
Caml Light, it's easy to turn it by yourself into OCaml. It offers a
great chance to learn how to do a lot of things in *pure* Caml with
only stdlib and a simple syntax extension system (use camlp5 (i.e. the
"genuine camlp4") that is fine for that. It works out of the box to
deal with streams and it's a chance to understand what is a
LL(1)/recursive descent parser).
[OCaml for the Skeptical / OCaml in a Nutshell]
https://www2.lib.uchicago.edu/keith/ocaml-class/class-01.html
[Developing Applications With Objective Caml]
https://caml.inria.fr/pub/docs/oreilly-book/
Dune meeting notes
══════════════════
Archive: [https://discuss.ocaml.org/t/dune-meeting-notes/5710/1]
Jérémie Dimino announced
────────────────────────
I just wanted to publicise that we are now publishing the notes from
our Dune meetings on the wiki:
[https://github.com/ocaml/dune/wiki]
These meetings happen via video-conference every two weeks. If you are
interested in following the development of Dune more closely, this is
good place to look at.
OCaml 4.11.0, first alpha release
═════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-4-11-0-first-alpha-release/5716/1]
octachron announced
───────────────────
The set of new features for the future version 4.11.0 of OCaml has
been frozen. In the next few months, the OCaml compiler team is
focusing on bug hunting and fixing.
For this release cycle, we have decided to test publishing regularly
alpha versions of OCaml 4.11.0 in order to help fellow hackers join us
early in our bug hunting and opam ecosystem fixing fun. Once the opam
ecosystem is in shape, these alpha releases will morph into the usual
beta and release candidate releases.
If you find any bugs, please report them here:
[https://github.com/ocaml/ocaml/issues]
The compiler can be installed as an OPAM switch with one of the
following commands
┌────
│ opam switch create ocaml-variants.4.11.0+alpha1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.11.0+alpha1+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace VARIANT with one of these: afl, flambda, fp,
fp+flambda
The source code for the alpha is also available at these addresses:
[https://github.com/ocaml/ocaml/archive/4.11.0+alpha1.tar.gz]
[https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+alpha1.tar.gz]
If you are interested by the ongoing list of new features and fixed
bugs, the updated change log for OCaml 4.11.0 is available at:
[https://github.com/ocaml/ocaml/blob/4.11/Changes]
OCaml Users and Developers Meeting 2020
═══════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ocaml-users-and-developers-meeting-2020/5454/2]
Ivan Gotovchits announced
─────────────────────────
Due to the multiple requests and since ICFP will be now officially
held online with a significantly reduced fee, we decided to extend the
submission deadline till the end of this month. We are hoping to
attract a larger and more diverse audience this year, given that the
new format is more accessible both travel-wise and financially.
Please, share the news widely!
Important Dates (updated)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Talk proposal submission deadline: May 29th, 2020, AoE
• Author Notification: July 17th, 2020
• OCaml Workshop: August 28th, 2020
VSCode Platform Plugin 0.5.0
════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-vscode-platform-plugin-0-5-0/5752/1]
Rudi Grinberg announced
───────────────────────
This release contains a couple of major improvements:
• Syntax highlighting is vastly improved. There's now highlighting for
many more filetypes, and the core highlighting for OCaml is far more
accurate.
• There's integration with package managers such as opam and esy. One
may now explicitly use them to explicitly select the sandbox that
contains the lsp server and related tools.
Under the hood, the entire plugin was rewritten from typescript to
OCaml (bucklescript). This should hopefully make contribution more
accessible to OCaml hackers.
I'd like to thank @rustykey, @mnxn, @prometheansacrifice, and @imbsky
for their contributions to this release. Their help is the reason for
this vastly improved version of the plugin.
As usual, the plugin is available directly using vscode's extension
market place. I'll leave a link to the plugin [here] to avoid
confusion with the many other OCaml plugins available.
Please report any issues on the [bug tracker]
[here]
https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform
[bug tracker] https://github.com/ocamllabs/vscode-ocaml-platform/issues
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Ocsigen Start 2.18 released]
• [Ocsigen Toolkit 2.7 with new widget Ot_tongue]
[OCaml Planet] http://ocaml.org/community/planet/
[Ocsigen Start 2.18 released]
https://ocsigen.github.io/blog/2020/05/05/os/
[Ocsigen Toolkit 2.7 with new widget Ot_tongue]
https://ocsigen.github.io/blog/2020/05/04/ot/
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 33105 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-05-05 7:45 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-05-05 7:45 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12736 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 28 to May
05, 2020.
Table of Contents
─────────────────
Lwt now has let* syntax
JOSE 0.3.0 - Now with 100% more encryption
Are there learning materials for OCaml for those with no programming experience?
The recent evolution of utop, lambda-term, zed and underneath projects
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
Old CWN
Lwt now has let* syntax
═══════════════════════
Archive: [https://discuss.ocaml.org/t/lwt-now-has-let-syntax/5651/1]
Anton Bachin announced
──────────────────────
[Lwt] now has `let*' and `let+' syntax, which can be used like this:
┌────
│ open Lwt.Syntax
│
│ let () =
│ let request =
│ let* addresses = Lwt_unix.getaddrinfo "google.com" "80" [] in
│ let google = Lwt_unix.((List.hd addresses).ai_addr) in
│
│ Lwt_io.(with_connection google (fun (incoming, outgoing) ->
│ let* () = write outgoing "GET / HTTP/1.1\r\n" in
│ let* () = write outgoing "Connection: close\r\n\r\n" in
│ let* response = read incoming in
│ Lwt.return (Some response)))
│ in
│
│ let timeout =
│ let* () = Lwt_unix.sleep 5. in
│ Lwt.return None
│ in
│
│ match Lwt_main.run (Lwt.pick [request; timeout]) with
│ | Some response -> print_string response
│ | None -> prerr_endline "Request timed out"; exit 1
└────
This is now released in Lwt [5.3.0]. Thanks to Rahul Kumar for adding
`let*', and @CraigFe for adding `let+'!
[Lwt] https://github.com/ocsigen/lwt
[5.3.0] https://github.com/ocsigen/lwt/releases/tag/5.3.0
Thomas Coopman asked
────────────────────
Awesome this looks great.
2 quick questions:
1. I don't see this new version documented on ocsigen yet? Is that a
build that needs to be done manually?
2. Is `ppx_lwt' still recommend for some usecases like `try%'? For
what cases is one preferred over the other?
Anton Bachin replied
────────────────────
Good questions :slight_smile:
1. The docs generation is blocked on an Ocsigen "internal" package
`wikidoc', which has not been updated to support 4.08. So,
effectively, `let*' is exactly what is preventing docs generation
for the time being. I'll post the docs as soon as that is fixed.
2. `ppx_lwt' is probably still the recommended way, because of better
backtraces, and things like `try%lwt'. `let*' is nice for people
that don't want to use the PPX. They can still benefit from a
monadic syntax.
JOSE 0.3.0 - Now with 100% more encryption
══════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/ann-jose-0-3-0-now-with-100-more-encryption/5667/1]
Ulrik Strid announced
─────────────────────
I recently released a version 0.3.0 of JOSE.
[https://github.com/ulrikstrid/reason-jose]
[https://ulrikstrid.github.io/reason-jose]
It now includes some of the JWE (JSON Web Encryption) spec. A huge
thank you goes out to @hannes for helping me implementing one of the
gnarlier combinations of decryption that I could then use as a base
for encryption and more `alg' and `enc'.
I also refactored the JWK (JSON Web Keys) implementation to unify and
simplify the representation. It is now possible to use a private key
for anything a public key can do since it's a superset.
A special thanks to @anmonteiro for helping me with the design and
reviewing my code.
Are there learning materials for OCaml for those with no programming experience?
════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/are-there-learning-materials-for-ocaml-for-those-with-no-programming-experience/5684/1]
Aaron Christianson asked
────────────────────────
OCaml is a language with some advanced features, but a very gentle
learning curve. It seems like it would be well-suited to teaching
beginners to program (a few tricky error messages notwithstanding),
but I haven't seen many resources targeted at teaching programming
from scratch. Does anyone here know any?
Daniel Bünzli replied
─────────────────────
There is [*OCaml from the Very Beginning*] written by @JohnWhitington.
[*OCaml from the Very Beginning*] http://ocaml-book.com/
Nicolás Ojeda Bär also replied
──────────────────────────────
An excellent (free) book is "LE LANGAGE CAML"
[https://caml.inria.fr/pub/distrib/books/llc.pdf].
Pierre also replied
───────────────────
There's also [CS3110] from Cornell University. Here's [the
textbook]. It's pretty great!
[CS3110] https://www.cs.cornell.edu/courses/cs3110/2020sp/
[the textbook]
https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/
The recent evolution of utop, lambda-term, zed and underneath projects
══════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/the-recent-evolution-of-utop-lambda-term-zed-and-underneath-projects/5687/1]
ZAN DoYe announced
──────────────────
Hi, dear OCaml guys! We've been keeping quiet for more than one year
though utop, lambda-term, zed and some related projects were still
evolving during the period of time. This is because of two reasons:
1. The new feature had nothing to do with the fields where most OCaml
developers are working on:
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a30d5fb6fc075a50801b387299cc820965d48ca0.png]
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/9/91b88f0c492702212f00f17af1bf0e18ee1a463b.png]
Recognizing, editing, fuzzy searching for Character
Variation(mainly for ancient CJK characters).
Nevertheless, the new feature brought us a good side effect – the
long-existing [Issue with asian charset] was resolved. UTop users
will notice the refinement naturally, so no announcement was
needed.
2. I didn't deem the first few new editions of zed 2 and lambda-term 2
stable enough.
[Issue with asian charset]
https://github.com/ocaml-community/lambda-term/issues/2
3.0 era
╌╌╌╌╌╌╌
This time, we are entering zed 3, lambda-term 3 era. The features
introduced since zed 2, lambda-term 2 are quite stable now and the new
feature coming to us will have a bit more impact, especially to vim
users. So it's worthwhile to draft an announcement:
◊ VI Editing Mode
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/c/ca11924046977d89d4345ad135977c6960470edc.gif]
OCaml guys, hope you enjoy this.
List of notable changes:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• zed 2:
• wide, combined glyph(Character Variation, IPA, CJK …)
• add wanted_column support for wide width character
• lambda-term 2:
• wide, combined glyph(Character Variation, IPA, CJK …)
• add horizontal scrolling support for wide width character
• zed 3:
• add new actions for convenience
• lambda-term 3:
• `LTerm_read_line': add initial support for vi editing mode:
• motions:
• h l 0 ^ $
• j k gg G
• w W e E b B ge gE
• f F t T
• aw iw aW iW
• include or inner ( ), [ ], { }, < >, ' and "
• generic quote: aq? iq? where ? could be any character
• bracket matching: jump back and forth between matched brackets
• delete, change, yank with motions
• paste: p P
• line joining: J
for a full list of the changes, please visit the homepages of each
project.
Projects underneath:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [charInfo_width]: Determine column width for a character
• [mew] & [mew_vi]: Modal editing witch & Its VI interpreter
complement. In a word, modal editing engine generators.
[charInfo_width] https://bitbucket.org/zandoye/charinfo_width/
[mew] https://github.com/kandu/mew
[mew_vi] https://github.com/kandu/mew_vi
What's next
╌╌╌╌╌╌╌╌╌╌╌
◊ VI Editing Mode
1. Visual mode
[https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/7/7cc45010710ad28d8d1e859e9b28806469ef8080.gif]
2. register support and more vi compatible
◊ CJKV
We've recorded more then 100 thousand entries about the structure of
CJK characters, what is a character consists of, how are the
sub-assemblies glue together etc. And as a complement to
charInfo_width, we may release a new project called charInfo_structure
;)
Looking for "lovely, idiomatic" examples of Ocaml used for shell-scripting in the manner of Perl/Python (but esp. Perl)
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
[https://discuss.ocaml.org/t/looking-for-lovely-idiomatic-examples-of-ocaml-used-for-shell-scripting-in-the-manner-of-perl-python-but-esp-perl/5703/1]
Chet Murthy announced
─────────────────────
I wonder if there are people who have written nontrivial Ocaml code
for shell-scripting, that they think exemplifies the right way to do
it. I've been a Perl hacker for 25yr, and so when I reach for Ocaml
to write stuff that should be Perl shell-scripts, I always find it a
bit painful, and there's a significant overhead to getting the job
done. Some of that is applying ocaml to a new domain, but some of it
is that I'm just not using the right idioms and tools (and there are
so many to choose from).
So if anybody has good pointers, I'd appreciate learning about them.
Bikal Lem
─────────
Haven't tried it myself, but this looks promising …
[https://github.com/janestreet/shexp].
At least it has the great Sean Connery in its README so possibly worth
delving a bit. :)
Hezekiah Carty
──────────────
[bos] seems like it can do a lot of what you're looking for. It's at
least worth taking a look, though it may not be at Perl levels of
concise for this kind of task.
[bos] https://erratique.ch/software/bos
Martin Jambon
─────────────
I tried to summarize my take on the subject into this gist:
[https://gist.github.com/mjambon/bb07b24f89fa60c973735307ce9c6cb9]
I'm not aware of the existence of such tool, but this is how I might
design it. This should be reminiscent of camlp4's quotation and
anti-quotation system, which allows alternating between two syntaxes
within a source file.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] mailto:alan.schmitt@polytechnique.org
[the archive] http://alan.petitepomme.net/cwn/
[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss
[online] http://lists.idyll.org/listinfo/caml-news-weekly/
[Alan Schmitt] http://alan.petitepomme.net/
[-- Attachment #2: Type: text/html, Size: 28610 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-28 12:44 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-04-28 12:44 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 29726 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 21 to 28,
2020.
Table of Contents
─────────────────
opam 2.0.7 and 2.1.0 alpha
OCaml 4.11, release plan
ocamlformat pre-commit hook
New release of naboris 0.1.2
ANN: Releases of ringo
resto 0.2 released
Retrofitting Parallelism onto OCaml (research paper)
Multicore Update: April 2020, with a preprint paper
Why did Core remove polymorphic comparison operators in OCaml 4.10.0?
New release of js_of_ocaml 3.6.0
Other OCaml News
Old CWN
opam 2.0.7 and 2.1.0 alpha
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-opam-2-0-7-and-2-1-0-alpha/5583/1>
R. Boujbel announced
────────────────────
We are pleased to announce the release of [opam 2.0.7] and an [2.1.0
alpha].
This 2.0.7 version contains backported fixes, you can find more
information in this [blog post].
The 2.1.0~alpha contains many new features (cf. [blog post] or
[release note]). If you want to take a look, a few glitches or
regressions are expected, please report them to [the bug-tracker].
*opam is a source-based package manager for OCaml. It supports
multiple simultaneous compiler installations, flexible package
constraints, and a Git-friendly development workflow.*
[opam 2.0.7] <https://github.com/ocaml/opam/releases/tag/2.0.7>
[2.1.0 alpha] <https://github.com/ocaml/opam/releases/tag/2.1.0-alpha>
[blog post] <https://opam.ocaml.org/blog/opam-2-0-7>
[blog post] <https://opam.ocaml.org/blog/opam-2-1-0-alpha/>
[release note] <https://github.com/ocaml/opam/releases/tag/2.1.0-alpha>
[the bug-tracker] <https://github.com/ocaml/opam/issues>
Anil Madhavapeddy then added
────────────────────────────
Thanks for all the hard work that's gone into this release, @rjbou
@AltGr and @dra27!
To set expectations, this alpha release is for our users to smoke test
the new features and let us know if they work for your usecases.
In particular, the opam external dependency management and support for
recursive pins are both commonly requested features. Please do take
this alpha for a spin, and report feedback here on this thread.
After this alpha is cut, there will be a sequence of beta releases
(the number of which depend on the reported bug tail), and then the
final opam 2.1.0 release. Your testing _now_ will greatly help us put
a quality release out of the door.
OCaml 4.11, release plan
════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-11-release-plan/5600/1>
octachron announced
───────────────────
The new version of OCaml, OCaml 4.11.0, has started its bugfix period:
the set of new features is now mostly frozen, and in the three
upcoming months, we will focus mostly on fixing bugs.
For this release cycle, we will experiment releasing an alpha version
of the compiler.
This new alpha version is expected to work as a synchronization point
for people working on updating the opam ecosystem for the new
release. Once the opam ecosystem is in shape for some wider audience
testings, we will publish a beta version as usual. This should be
happen around June.
One of the most notable change in this release is `Statmemprof', a new
statistical memory profiler directly integrated into the GC.
The provisional Changes list is [here].
At this point of time, it is better to take this list with a grain of
salt: there are a handful of new features that are still under
integration, problematic features might be removed, and of course the
list of bug fixes is incomplete.
But one of the most notable feature in this change log, `Statmemprof'
which a new statistical memory profiler API, is most probably here to
stay.
[here] <https://github.com/ocaml/ocaml/blob/4.11/Changes>
Guillaume Munch-Maccagnoni then added
─────────────────────────────────────
It should be mentioned that Memprof is documented as “~EXPERIMENTAL~”,
and at least one breaking change is being considered in 4.12. This
also mean that suggestion for improvement will be welcome (AFAIU).
ocamlformat pre-commit hook
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocamlformat-pre-commit-hook/5602/1>
Brendan Long announced
──────────────────────
This is kind of trivial but I figured it might be useful for other
people. We created a hook config for using [ocamlformat] with
[pre-commit]:
<https://github.com/arenadotio/pre-commit-ocamlformat>
pre-commit is a tool that makes it easier to run checks on changed
files before commiting them, and this makes it so you can auto-run
ocamlformat and ensure no unformatted code gets into your repo.
1. [Install pre-commit] like `pip install pre-commit'
2. In your repo, add a .pre-commit-config.yaml like:
┌────
│ ---
│ repos:
│ - repo: https://github.com/arenadotio/pre-commit-ocamlformat
│ rev: master # or pick a commit sha I guess
│ hooks:
│ - id: ocamlformat
└────
1. Run `pre-commit install'
2. Now every time you run `git commit' (or `pre-commit run'), it will
run every staged OCaml file through ocamlformat and complain if
there are any changes:
┌────
│ $ pre-commit run ocamlformat
│ ocamlformat.....Failed
│ - hook id: ocamlformat
│ - files were modified by this hook
│ $ git add .
│ $ pre-commit run ocamlformat
│ ocamlformat.....Passed
└────
[ocamlformat] <https://github.com/ocaml-ppx/ocamlformat#ocamlformat>
[pre-commit] <https://pre-commit.com/>
[Install pre-commit] <https://pre-commit.com/#install>
New release of naboris 0.1.2
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-naboris-0-1-2/5604/1>
Shawn McGinty announced
───────────────────────
Simple http server for OCaml/ReasonML.
[naboris] has been updated to 0.1.2
This release comes with a few improvements to the API but most notably
it has much better documentation at [naboris.dev]
[naboris] <https://naboris.dev>
[naboris.dev] <https://naboris.dev>
ANN: Releases of ringo
══════════════════════
Archive: <https://discuss.ocaml.org/t/ann-releases-of-ringo/5605/1>
Raphaël Proust announced
────────────────────────
On behalf of Nomadic Labs, I am please to announce the first few
releases of Ringo: a library for caches. Ringo offers two kinds of
caches: Maps for caches of key-value pairs and Sets for caches of
simple elements. In addition, each kind of cache can be tweaked to
handle their bounds differently.
Ringo versions 0.1, 0.2 and 0.3 are available on `opam'. As the
version number and the bundled announce suggests, this library is
still in early phases of release: additional replacement policies will
be added, the interface will probably change somewhat,
etc. Suggestions welcome!
Even though the interface is still in early phases of release, the
implementation is covered by a lot of tests and is already in use in
the Tezos project.
The code is available at <https://gitlab.com/nomadic-labs/ringo>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/3>
Raphaël Proust announced
────────────────────────
Release of `resto 0.5'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
On behalf of Nomadic Labs, I'm happy to announce the release of
version 0.5 of `resto'.
The main change brought in this release are:
• relaxing of dependency bounds,
• documentation!
Retrofitting Parallelism onto OCaml (research paper)
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/retrofitting-parallelism-onto-ocaml-research-paper/5628/1>
Guillaume Munch-Maccagnoni announced
────────────────────────────────────
The following paper on the multicore GC design by @kayceesrk and his
coauthors has been posted on arXiv today and might interest the
community: <https://arxiv.org/abs/2004.11663>
Multicore Update: April 2020, with a preprint paper
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-update-april-2020-with-a-preprint-paper/5630/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the April 2020 update from the Multicore OCaml team, across
the UK, India, France and Switzerland! Although most of us are in
lockdown, we continue to march forward. As with [previous updates],
thanks to @shakthimaan and @kayceesrk for help assembling it all.
[previous updates] <https://discuss.ocaml.org/tag/multicore-monthly>
◊ Preprint: Retrofitting Parallelism onto OCaml
We've put up a preprint of a paper titled ["Retrofitting Parallelism
onto OCaml" ] for which we would be grateful to receive feedback. The
paper lays out the problem space for the multicore extension of OCaml
and presents the design choices, implementation and evaluation of the
concurrent garbage collector (GC).
Note that this is *not a final paper* as it is currently under peer
review, so any feedback given now can still be incorporated. Please
use the e-mail contact details in the [pdf paper] for @kayceesrk and
myself so we can aggregate (and acknowledge!) any such comments.
["Retrofitting Parallelism onto OCaml" ]
<https://arxiv.org/abs/2004.11663>
[pdf paper] <https://arxiv.org/pdf/2004.11663.pdf>
◊ Rebasing Progress
The Multicore OCaml rebase from 4.06.1 has gained momentum. We have
successfully rebased the parallel-minor-GC all the way onto the [4.09
OCaml trees]. We will publish updated opam packages when we get to
the recently branched 4.11 in the next couple of weeks.
Rebasing complex features like this is a "slow and steady" process due
to the number of intermediate conflicts and bootstrapping, so we will
not be publishing opam packages for every intermediate version –
instead, the 4.11 trees will form the new "stable base" for any PRs.
[4.09 OCaml trees]
<https://github.com/ocaml-multicore/ocaml-multicore/tree/parallel_minor_gc_4_09>
◊ Higher-level Domainslib API
A thread from [last month's update] on building a parallel raytracer
led to some useful advancements in the [domainslib] library to provide
async/await-style task support. See the updates below for more
details.
There is also an interesting discussion on
[ocaml-multicore/ocaml-multicore#324] about how to go about profiling
and optimising your own small programs. More experiments with
parallel algorithms with different scheduling properties would be most
useful at this time.
[last month's update]
<https://discuss.ocaml.org/t/multicore-ocaml-march-2020-update/5406/8>
[domainslib] <https://github.com/ocaml-multicore/domainslib>
[ocaml-multicore/ocaml-multicore#324]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324>
◊ Upstreamed features in 4.11
The [4.11 release has recently branched] and has the following
multicore-relevant changes in it:
• A concurrency-safe marshalling implementation (originally in
[ocaml#9293], then implemented again in [ocaml#9353]). This will
have a slight speed hit to marshalling-heavy programs, so feedback
on trying this in your projects with 4.11 will be appreciated to the
upstream OCaml issue tracker.
• A runtime eventlog tracing system using the CTF format is on the
verge of being merged in 4.11 over in [ocaml#9082]. This will also
be of interest to those who need sequential program profiling, and
is a generalisation of the infrastructure that was essential to our
development of the multicore GC. If anyone is interested in helping
with hacking on the OCaml side of CTF support to build clients,
please get in touch with me or @kayceesrk.
In addition to the above highlights, we have also been making
continuous improvements and additions to the Sandmark benchmarking
test infrastructure. The various ongoing and completed tasks are
provided below for your reference.
[4.11 release has recently branched]
<https://discuss.ocaml.org/t/ocaml-4-11-release-plan/5600>
[ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
[ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
[ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore] Promote Multicore OCaml to trunk
The rebasing of Multicore OCaml from 4.06 to 4.10 is being worked,
and we are now at 4.09! In a few weeks, we expect to complete the
rebase to the latest trunk release.
• [ocaml-multicore/eventlog-tools]: OCaml Eventlog Tools
A project that provides a set of tools for runtime tracing for OCaml
4.11.0 and higher has been created. This includes a simple OCaml
decoder for eventlog's trace and a built-in chrome converter tool.
• [ocaml-multicore/domainslib#5] Add parallel_scan to domainslib
A [parallel_scan] implementation that uses the Task API with
prefix_sum and summed_area_table has now been added to the
Domain-level Parallel Programming library for Multicore OCaml
(domainslib) library.
[ocaml-multicore/ocaml-multicore]
<https://github.com/ocaml-multicore/ocaml-multicore/tree/parallel_minor_gc_4_09>
[ocaml-multicore/eventlog-tools]
<https://github.com/ocaml-multicore/eventlog-tools>
[ocaml-multicore/domainslib#5]
<https://github.com/ocaml-multicore/domainslib/pull/5>
[parallel_scan]
<https://en.wikipedia.org/wiki/Prefix_sum#Shared_memory:_Two-level_algorithm>
◊ Completed
The following PRs have been merged into Multicore OCaml and its
ecosystem projects:
• [ocaml-multicore/ocaml-multicore#328] Multicore compiler with
Flambda
Support for Flambda has been merged into the Multicore OCaml project
repository. The translation is now performed at cmmgen instead of
lambda for clambda conversion.
• [ocaml-multicore/ocaml-multicore#324] Optimizing a Multicore program
The following [documentation] provides a detailed example on how to
do performance debugging for a Multicore program to improve the
runtime performance.
• [ocaml-multicore/ocaml-multicore#325] Added eventlog_to_latencies.py
script
A script to generate a latency report from an eventlog has now been
included in the ocaml-multicore repository.
• [ocaml-multicore/domainslib#4] Add support for task_pools
The domainslib library now has support for work-stealing task pools
with async/await parallelism. You are encouraged to try the
[examples].
[ocaml-multicore/ocaml-multicore#328]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/328>
[ocaml-multicore/ocaml-multicore#324]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324>
[documentation]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/324#issuecomment-610183856>
[ocaml-multicore/ocaml-multicore#325]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/325>
[ocaml-multicore/domainslib#4]
<https://github.com/ocaml-multicore/domainslib/pull/4>
[examples]
<https://github.com/ocaml-multicore/domainslib/tree/task_pool/test>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
A number of new benchmarks are being ported to the [Sandmark]
performance benchmarking test suite.
• [ocaml-bench/sandmark#104] Added python pip3 dependency
A check_dependency function has now been defined in the Makefile
along with a list of dependencies and pip packages for Ubuntu. You
can now run `make depend' prior to building the benchmark suite to
ensure that you have the required software. The `python3-pip'
package has been added to the list of dependencies.
• [ocaml-bench/sandmark#96] Sandmark Analyze notebooks
The setup, builds and execution scripts for developer branches on
bench2.ocamllabs.io have been migrated to winter.ocamllabs.io.
A UI and automated script driven notebooks for analyzing sequential
bench results is being worked upon.
• [ocaml-bench/sandmark#108] Porting mergesort and matrix
multiplication using Task Pool API library
This is an on-going PR to implement merge sort and
matrix_multiplication using `parallel_for'.
• [cubicle]
`Cubicle' is a model checker and an automatic SMT theorem prover. At
present, it is being ported to Multicore OCaml, and this is a work
in progress.
• [raytracers]
Raytracers is a repository that contains ray tracer implementation
for different parallel functional programming languages. The OCaml
implementation has now been updated to use the new `Domainslib.Task'
API.
Also, a few [experiments] were performed on flambda parameters for
the Multicore raytracer which gives around 25% speedup, but it does
not yet remove the boxing of floats. The experiments are to be
repeated with a merge against the wip flambda2 trees on 4.11, that
removes float boxing.
[Sandmark] <https://github.com/ocaml-bench/sandmark>
[ocaml-bench/sandmark#104]
<https://github.com/ocaml-bench/sandmark/pull/104>
[ocaml-bench/sandmark#96]
<https://github.com/ocaml-bench/sandmark/issues/96>
[ocaml-bench/sandmark#108]
<https://github.com/ocaml-bench/sandmark/pull/108>
[cubicle] <https://github.com/Sudha247/cubicle/tree/add-multicore>
[raytracers] <https://github.com/athas/raytracers/pull/6>
[experiments]
<https://github.com/kayceesrk/raytracers/blob/flambda/ocaml/myocamlbuild.ml>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
A substantial number of commits have gone into this PR based on
reviews and feedback. These include updates to the configure script,
handling warnings and exceptions, adding build support for Windows,
removing unused code and coding style changes. This patch will be
cherry-picked for the 4.11 release.
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
◊ Completed
• [ocaml/ocaml#9353] Reimplement `output_value' using a hash table to
detect sharing
This PR which implements a hash table and bit vector as required for
Multicore OCaml has been merged to 4.11.
Our thanks as always go to all the OCaml developers and users in the
community for their continued support, and contribution to the
project!
[ocaml/ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• GC: Garbage Collector
• PIP: Pip Installs Python
• PR: Pull Request
• SMT: Satisfiability Modulo Theories
• UI: User Interface
Why did Core remove polymorphic comparison operators in OCaml 4.10.0?
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/why-did-core-remove-polymorphic-comparison-operators-in-ocaml-4-10-0/5633/1>
Trung Ta asked
──────────────
I'm using the Core library in a project, and recently when I upgraded
my OCaml from 4.08.1 to 4.10.0, plenty of compilation errors suddenly
appears for comparison expressions like:
`if (xs = []) then ...' or `if (x = true) then ...'
I saw that this change was discussed in this [thread] about
monomorphic comparison operators in Base, but did not expect that Core
would make it a default behavior.
So I'd like to ask since which version that Core removed such
polymorphic comparison operators? (I couldn't find it in release
notes of Core)
Also, if I defined a sum type like `type ternary = True | False |
Unkn', what will be a correct way to write `if (x = True) then ...'
(which is allowed in the new Core)?
I can temporarily fix by writing `if (x == True) then ...', but using
`==' doesn't seem correct, since `==' is about comparing physical
objects…
Thanks for spending your time to check my question.
[thread]
<https://discuss.ocaml.org/t/monomorphic-comparison-operator-of-janestreet-base-library/1585>
Aaron L. Zeng replied
─────────────────────
The change was announced in
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>,
although unfortunately it doesn't look like the CHANGES.md file was
updated in the repo. I would consider the thread to be the canonical
announcement.
Also, if I defined a sum type like `type ternary = True |
False | Unkn' , what will be a correct way to write `if (x
= True) then ...' (which is allowed in the new Core)?
Here's a few suggestions:
1. Define equality/compare functions using [`ppx_compare']
┌────
│ type ternary = True | False | Unkn [@@deriving equal]
│
│ let f x = if (equal_ternary x True) then ...
└────
2. Define equality/compare functions manually
┌────
│ let equal_ternary t1 t2 =
│ match t1, t2 with
│ | True, True | False, False | Unkn, Unkn -> true
│ | _ -> false
└────
3. Explicitly request polymorphic comparison operators using the
`Poly' module:
┌────
│ let f x = if (Poly.(=) x True) then ...
└────
[`ppx_compare'] <https://github.com/janestreet/ppx_compare>
Trung said and Aaron L. Zeng replied
────────────────────────────────────
btw,
┌────
│ type ternary = True | False | Unkn [@@deriving equal]
└────
should be: `[@@deriving eq]'
That depends on which preprocessor you are using. `[@@deriving
equal]' comes from ppx_compare, whereas `[@@deriving eq]' comes from
[ppx_deriving]. Base/Core and the like have better support for the
former, which is a Jane Street project, although you can feel free to
use the latter—the naming conventions are different, so it may not be
as convenient.
[ppx_deriving] <https://github.com/ocaml-ppx/ppx_deriving>
New release of js_of_ocaml 3.6.0
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-js-of-ocaml-3-6-0/5634/1>
Hhugo announced
───────────────
I'm pleased to announce the release [Js_of_ocaml] 3.6.0.
Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes
it possible to run pure OCaml programs in JavaScript environment like
browsers and Node.js.
Try it [online].
Notable changes:
• The `js_of_ocaml' compiler now accepts sub-commands (link,
build-runtime, build-fs, ..). The plan for future versions is to
remove other binary (e.g. jsoo_link) and consolidate everything
inside the `js_of_ocaml' binary itself.
• The standard JavaScript runtime is now embedded in the compiler
(findlib is no longer needed to locate it)
• Add support for the Str library (Regular expressions and high-level
string processing) shipped with the OCaml compiler
• Change memory representation of `Int64.t' (you might need to update
your JavaScript stubs)
• Many bug fixes (thanks to many more tests)
[Js_of_ocaml] <https://github.com/ocsigen/js_of_ocaml>
[online]
<https://ocsigen.org/js_of_ocaml/3.6.0/manual/files/toplevel/index.html>
Kirill Alexander Khalitov asked and Hhugo replied
─────────────────────────────────────────────────
1 Does the project have roadmap?
There is no official roadmap, the project evolves based on issues,
requests and contributions. You can take a look at some of the
[Github issues]
2 Is the project generally exists only for Ocsigen needs?
js_of_ocaml is used by various projects, not only Ocsigen. See
[Bonsai], [sketch-sh] or [jscoq] for instance.
3 Will it be adopted for modern front-end development
(commonjs/esmodules compatibility for working with
existing building tools ex. webpack, etc).
Being more friendly with the JavaScript ecosystem as been discussed
here and there in the past but little has been done, possibly by lack
of interest or use cases.
4 Does the project competing with bucklescript?
I don't think so. The two projects have different goals and different
audience. One of Js_of_ocaml main goal is to stay as close as possible
to the official OCaml semantic, allowing to leverage existing OCaml
libraries without any modification.
5 Why not to do ocaml to js compiler tools (based on
js_of_ocaml and bucklescript experience) that combine
possibility of using native ocaml and js libraries across
back-end and front-end like implemented in Scala.js/Fable
F#?
I don't understand this question. I would expect both js_of_ocaml and
bucklescript to be like Scala.js/Fable F# in their own way.
[Github issues]
<https://github.com/ocsigen/js_of_ocaml/issues?q=is:open+is:issue+label:enhancement>
[Bonsai] <https://github.com/janestreet/bonsai>
[sketch-sh] <https://github.com/Sketch-sh/sketch-sh>
[jscoq] <https://github.com/jscoq/jscoq>
Kirill Alexander Khalitov then said
───────────────────────────────────
I mean what Scala.js/Fable F# allows to use the most native libraries
(not all) and JS ones (from npm registry or from custom JS module) in
one project (ex. front-end). But in case of js_of_ocaml we limited to
native OCaml libs and "HTML scripts" (not JS compatible modules). For
bucklescript case we have whole JS ecosystem but have no access to
useful native libs from opam registry.
Xavier Van de Woestyne replied
──────────────────────────────
In Js_of_OCaml, you can deal with JavaScript's module (and npm/yarn),
using for example:
┌────
│ (* val require : string -> 'a *)
│ let require module_name =
│ let open Js.Unsafe in
│ fun_call
│ (js_expr "require")
│ [|inject (Js.string module_name)|]
└────
Other OCaml News
════════════════
>From the ocamlcore planet blog
──────────────────────────────
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [Every proof assistant]
• [opam 2.0.7 release]
• [opam 2.1.0 alpha is here!]
[OCaml Planet] <http://ocaml.org/community/planet/>
[Every proof assistant]
<http://math.andrej.com/2020/04/28/every-theorem-prover/>
[opam 2.0.7 release]
<http://www.ocamlpro.com/2020/04/21/opam-2-0-7-release/>
[opam 2.1.0 alpha is here!]
<http://www.ocamlpro.com/2020/04/21/opam-2-1-0-alpha-is-here/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 47670 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-21 8:58 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-04-21 8:58 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 27263 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 14 to 21,
2020.
Table of Contents
─────────────────
Current_incr: a small incremental library with no dependencies
Scikit-learn for OCaml
OCaml and opam container images updated: new Fedora/Alpine/Ubuntu images
OCamlformat 0.14.0
Hashconsing an AST via PPX
Genprint v0.4
Other OCaml News
Old CWN
Current_incr: a small incremental library with no dependencies
══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-current-incr-a-small-incremental-library-with-no-dependencies/5531/1>
Thomas Leonard announced
────────────────────────
The recent [OCurrent 0.2] release included a little incremental
library which might be interesting to some people. It is useful for
writing programs that need to keep some computation up-to-date
efficiently as the inputs change.
It is similar to the existing [incremental] and [react] libraries
already in opam. Unlike `incremental' (which pulls in the whole of
`core_kernel'), `current_incr' has no runtime dependencies (and build
dependencies only on `ocaml' and `dune'). Unlike `react',
`current_incr' immediately stops computations when they are no longer
needed (rather than relying on weak references and the garbage
collector).
It is a fairly direct implementation of the [Adaptive Functional
Programming] paper, and might be a good starting point for people
wanting to learn about that.
You can get the library using `opam':
┌────
│ opam install current_incr
└────
Here's a simple example (in utop):
┌────
│ #require "current_incr";;
│
│ let total = Current_incr.var 10
│ let complete = Current_incr.var 5
│
│ let status =
│ Current_incr.of_cc begin
│ Current_incr.read (Current_incr.of_var total) @@ function
│ | 0 -> Current_incr.write "No jobs"
│ | total ->
│ Current_incr.read (Current_incr.of_var complete) @@ fun complete ->
│ let frac = float_of_int complete /. float_of_int total in
│ Printf.sprintf "%d/%d jobs complete (%.1f%%)"
│ complete total (100. *. frac)
│ |> Current_incr.write
│ end
└────
This defines two input variables (`total' and `complete') and a
"changeable computation" (`status') whose output depends on them. At
the top-level, we can observe the initial state using `observe':
┌────
│ # print_endline @@ Current_incr.observe status;;
│ 5/10 jobs complete (50.0%)
└────
Unlike a plain `ref' cell, a `Current_incr.var' keeps track of which
computations depend on it. After changing them, you must call
`propagate' to update the results:
┌────
│ # Current_incr.change total 12;;
│ # Current_incr.change complete 4;;
│ # print_endline @@ Current_incr.observe status;;
│ 5/10 jobs complete (50.0%) (* Not yet updated *)
│
│ # Current_incr.propagate ();
│ # print_endline @@ Current_incr.observe status;;
│ 4/12 jobs complete (33.3%)
└────
Computations can have side-effects, and you can use `on_release' to
run some compensating action if the computation needs to be undone
later. Here's a function that publishes a result, and also registers a
compensation for it:
┌────
│ let publish msg =
│ Printf.printf "PUBLISH: %s\n%!" msg;
│ Current_incr.on_release @@ fun () ->
│ Printf.printf "RETRACT: %s\n%!" msg
└────
It can be used like this:
┌────
│ # let display = Current_incr.map publish status;;
│ PUBLISH: 4/12 jobs complete (33.3%)
│
│ # Current_incr.change total 0;
│ # Current_incr.propagate ()
│ RETRACT: 4/12 jobs complete (33.3%)
│ PUBLISH: No jobs
└────
A major difference between this and the react library (which I've used
in previously in [0install's progress reporting] and [CueKeeper]) is
that `Current_incr' does not depend on the garbage collector to decide
when to stop a computation. In react, you'd have to be careful to make
sure that `display' didn't get GC'd (even though you don't need to
refer to it again) because if it did then the output would stop
getting updated. Also, setting `total' to `0' in react might cause the
program to crash with a division-by-zero exception, because the `frac'
computation will continue running until it gets GC'd, even though it
isn't needed for anything now.
[`Current_incr''s API] is pretty small. You might want to wrap it to
provide extra features, e.g.
• Use of a `result' type to propagate errors.
• Integration with `Lwt' to allow asynchronous computations.
• Static analysis to render your computation with graphviz.
• Persistence of state to disk.
If you need that, consider using the main [OCurrent] library, which
extends `current_incr' with these features.
[OCurrent 0.2] <https://github.com/ocurrent/ocurrent/releases/tag/v0.2>
[incremental] <https://github.com/janestreet/incremental>
[react] <https://erratique.ch/software/react>
[Adaptive Functional Programming]
<https://www.cs.cmu.edu/~guyb/papers/popl02.pdf>
[0install's progress reporting]
<https://stackoverflow.com/questions/19975140/how-to-stop-ocaml-garbage-collecting-my-reactive-event-handler>
[CueKeeper]
<https://roscidus.com/blog/blog/2015/06/22/cuekeeper-internals-irmin/>
[`Current_incr''s API]
<https://ocurrent.github.io/ocurrent/current_incr/Current_incr/index.html>
[OCurrent] <https://github.com/ocurrent/ocurrent>
Scikit-learn for OCaml
══════════════════════
Archive: <https://discuss.ocaml.org/t/scikit-learn-for-ocaml/5536/1>
UnixJunkie announced
────────────────────
Ronan Lehy just hacked this:
<https://github.com/lehy/ocaml-sklearn>
This might interest a significant number of people out there. We are
no more condemned to live in a world full of snakes that will bite us
at run-time. :smiley:
Ronan Le Hy then said
─────────────────────
So I came here to announce ocaml-sklearn as it just got published on
Opam, but I see @UnixJunkie did it for me (arigato gozai
masu). Anyway:
• this ambitions to cover the complete scikit-learn API
• this ambition is currently not totally realized, but I wanted to
release something initial that one can play with
• it's all @UnixJunkie's fault with his funny R wrappers.
So:
• opam install sklearn
• go check out [scikit-learn and its awesome documentation] to know
what it does
• look at [ocaml-sklearn's documentation] to see what the current
OCaml API looks like
• have fun with it and tell me what you think of it.
[scikit-learn and its awesome documentation] <https://scikit-learn.org>
[ocaml-sklearn's documentation] <https://lehy.github.io/ocaml-sklearn/>
Anton Kochkov then added
────────────────────────
Probably worth to add here:
• <https://github.com/ocaml-community/awesome-ocaml#machine-learning>
OCaml and opam container images updated: new Fedora/Alpine/Ubuntu images
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-and-opam-container-images-updated-new-fedora-alpine-ubuntu-images/5539/1>
Anil Madhavapeddy announced
───────────────────────────
The Docker [ocaml and opam container images] have been updated:
• Alpine 3.11, Fedora 31 and Ubuntu 20.04 (beta) are now included.
• Ubuntu 19.04 and Fedora 29 and 30 are now deprecated.
• OCaml 4.09.1 and 4.11.0~dev have been refreshed.
You can find the full details of the container images available [on
the OCaml infrastructure wiki].
The containers are generated from a set of scripts using
[ocaml-dockerfile], and will be migrating over the next six months to
use an [ocurrent]-based infrastructure. There will be an announcement
on this forum about any user-facing changes that involves, with plenty
of time to transition your own CIs over. Thanks go to @talex5 and
@XVilka for contributions to this round of updates.
[ocaml and opam container images] <https://hub.docker.com/r/ocaml/opam2>
[on the OCaml infrastructure wiki]
<https://github.com/ocaml/infrastructure/wiki/Containers>
[ocaml-dockerfile] <https://github.com/avsm/ocaml-dockerfile>
[ocurrent] <https://ocurrent.org>
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/24>
Jules announced
───────────────
As Etienne mentioned, we have released OCamlformat 0.14.1, reverting
the change to the defaults and our plans to deprecate the
`doc-comments' option.
For projects that already upgraded to 0.14.0 (eg. Coq), the
`doc-comments' option will change its meaning again. It is necessary
to add `doc-comments=before' to have the documentation comments placed
before. Moreover, the new option `doc-comments-val' added in 0.14.0
has a higher precedence than `doc-comments', even when it's not
set. It is thus necessary to set them both to `before' to have the old
"before" behavior. This will be improved in the next release (see
<https://github.com/ocaml-ppx/ocamlformat/pull/1340>).
Thank you to our early adopters to bear us. We are improving our
release process to reduce confusion for the next updates. As usual, if
you have any feedback, please open an issue on
<https://github.com/ocaml-ppx/ocamlformat> to discuss it with us.
Hashconsing an AST via PPX
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/hashconsing-an-ast-via-ppx/5558/1>
Chet Murthy announced
─────────────────────
[up-front (so nobody gets the wrong idea): I'm not pushing Camlp5.
Rather, I'm just noting that this sort of thing is really easy to do,
and I encourage someone to do something similar using the PPX
infrastructure.]
I didn't want to derail the "Future of PPX" thread, so I thought I'd
post separately to answer ivg@ 's issue about hashconsing of ASTs
using PPX. It's actually [uh, I think] really, really easy to
implement hashconsing of ADTs, using a PPX extension. On a lark, I
decided to do it *today*, and while the code I've got isn't sufficient
to use, I think it's not very far away, and I have the perfect
use-case already in-mind. It took me two hours to implement the
rewriter and the testcase, on top of the other infrastructure, which
has no support for hashconsing of any sort.
Here are some examples of data-types and functions that are
automaticaly hash-consed. The idea is that in the pattern-match the
pattern is annotated with a variable (in this example, "z"); the
expression that is supposed to be hash-consed against that pattern is
annotated with that same variable. [The code that descends to the
expression is a little weak right now, but I think that's easily
fixable.] The algorithm goes as follows:
(1) "decorate" the pattern with "as z_<integer>" variables everywhere
in constructors. This allows us to refer to parts of the original
value.
(2) then find each expression that is marked with that same varable.
Structurally descend the pattern and the expression in parallel and
generate code to compare sub-structure and hashcons where appropriate.
And that's really it. I'm sure this can be implemented using the PPX
tools.
Some comments: (1) what's nice, is that we can just take
already-written code like `List.map' and annotate it; that generates a
hash-consed version. And since the generated code never uses deep
structural equality (only pointer-equality) it should be only
marginally slower than the original implementation.
(2) The variable in the annotation ("z") is used as the base for
generating a whole slew of fresh variables, and I don't bother (yet)
to check for clashes; this (again) is straightforward, but hey, I
started two hours ago.
┌────
│ type t = Leaf of int | Node of t * int * t
│
│ module HCList = struct
│
│ let rec map f = function
│ [][@hashrecons z] -> [][@hashrecons z]
│ | (a::l)[@hashrecons z] -> let r = f a in ((r :: map f l)[@hashrecons z])
│
│ end
│
│ let deep =
│ let rec deep = (function
│ Leaf n[@hashrecons z] -> Leaf n[@hashrecons z]
│ | Node (l, n, r) [@hashrecons z] ->
│ Node (deep l, n, deep r) [@hashrecons z]
│ )
│ [@@ocaml.warning "-26"]
│ in deep
│
│ type sexp =
│ | Atom of string
│ | List of sexp list
│
│ let sexp_deep =
│ let rec deep = function
│ Atom s[@hashrecons z] -> Atom s[@hashrecons z]
│ | List l[@hashrecons z] -> List (HCList.map deep l)[@hashrecons z]
│ in deep
└────
Links: First, at the commit, so they won't change
the testcase file:
<https://github.com/chetmurthy/pa_ppx/commit/5dd6b2ef3ca3677e11a0ad696074200101bd661f#diff-e6dffe78fc6c27bdffa41970c4a7f1ca>
the "ppx rewriter":
<https://github.com/chetmurthy/pa_ppx/commit/5dd6b2ef3ca3677e11a0ad696074200101bd661f#diff-24aeaf51366017948f5735727f001c85>
Second, the files with human-readable names, etc.:
the testcase:
<https://github.com/chetmurthy/pa_ppx/blob/master/tests/test_hashrecons.ml>
the "ppx rewriter":
<https://github.com/chetmurthy/pa_ppx/blob/master/pa_hashrecons/pa_hashrecons.ml>
The projects:
chetmurthy/pa_ppx: A reimplementation of ppx_deriving, all its
plugins, ppx_import, and a few others.
<https://github.com/chetmurthy/pa_ppx>
chetmurthy/camlp5: Camlp5, version pre-8.00 on which the above is
based. This is on the branch 26.attempt-pa-deriving .
Kakadu said
───────────
I experimented with this some time ago for ML workshop. The idea was
to provide function: `t -> htbl -> htbl * t' which rewrites value of
type `t' by removing equal subtrees. Essentially it is just a fold
over data type.
<https://github.com/kakadu/GT/blob/master/regression/test816hash.ml#L74>
Chet Murthy asked and Josh Berdine replied
──────────────────────────────────────────
If you wanna use a hashtable (and, I presume, Obj.magic)
you can write a single function that does the trick for
all immutable data-types, right?
Yes, we have some magic @mbouaziz [code] in Infer that does this to
create as much sharing as possible as values are Marshaled out.
[code]
<https://github.com/facebook/infer/blob/master/infer/src/istd/MaximumSharing.ml>
Genprint v0.4
═════════════
Archive: <https://discuss.ocaml.org/t/ann-genprint-v0-4/5575/1>
progman announced
─────────────────
A re-announcement of Genprint, a general value printing library, that
addresses prior limitations that made it none too useful!
1. It didn't work correctly for 4.08.0, the latest compiler release as
of first announcement (though fine for 4.02 .. 4.07.1)
2. There was an awkward need to specify a search path for .cmt files
when working with the likes of Dune (which uses separate
directories for source, .cmi and (for opt) .cmt files)
3. More often than not values of interest would display simply as
`<abstr>' owing to the presence of signature abstraction of the
module's type of interest.
These issues have been addressed:
1. Works with versions 4.04 .. 4.10.0 (earlier versions became invalid
after a dependency change to ppxlib)
2. The location of .cmt files is captured automatically by the PPX
preprocessor.
3. Signatures at the implementation level (.mli files) and internally
(functor application constraints) are removed to reveal the inner
structure of otherwise abstract values. For instance, the
Ephemeron module:
┌────
│ module EM=Ephemeron.K1.Make(struct type t=int let equal=(=) let hash=Hashtbl.hash end)
│ open EM
│ let _=
│ let v=EM.create 0 in
│ EM.add v 12345678 'X';
│ let emprint ppf (v: Obj.Ephemeron.t) =
│ Format.fprintf ppf "<C wrapper of key/data>" in
│ [%install_printer emprint];
│ [%pr ephem v];
└────
Which prints:
┌────
│ ephem => {size = 1;
│ data =
│ [|Empty; Empty; Empty; Empty; Empty; Empty; Empty; Empty; Empty;
│ Empty; Empty; Cons (922381915, <C wrapper of key/data>, Empty);
│ Empty; Empty; Empty; Empty|];
│ seed = 0; initial_size = 16}
└────
This also demos the [%install_printer] facility which mirrors the
REPL's.
Installation is via the Opam main repository.
Additionally, the project repository [contains] two compiler versions
of _ocamldebug_ integrated with the Genprint library which thereby
becomes its default printer.
All of which makes this library much more useful than previously. See
the [project page] for the details.
[contains]
<https://github.com/progman1/genprintlib/tree/master/debugger>
[project page] <https://github.com/progman1/genprintlib>
Other OCaml News
════════════════
From the ocamlcore planet blog
──────────────────────────────
Editor note: Thanks to [ezcurl], I can restore this section. I'm
putting all the links this week, I will prune to only put the new ones
next week.
Here are links from many OCaml blogs aggregated at [OCaml Planet].
• [An in-depth Look at OCaml’s new “Best-fit” Garbage Collector
Strategy]
• [Sliding Tile Puzzle, Self-Contained OCaml Webapp]
• [New version of Try OCaml in beta!]
• [Frama-Clang 0.0.8 is out. Download it here.]
• [A reasonable TyXML release | Drup's thingies]
• [Alt-Ergo Users’ Club Annual Meeting]
• [OCaml iOS Apps Ported to Browser]
• [Watch all of Jane Street's tech talks]
• [Mercurial: prettyconfig extension]
• [Mercurial extensions (update)]
• [2019 at OCamlPro]
• [Bitbucket repository migration]
• [Troubleshooting systemd with SystemTap]
• [Ocsigen Start updated]
• [Ocsigen Start updated]
• [opam 2.0.6 release]
• [opam 2.0.6 release]
• [Hackers and climate activists join forces in Leipzig]
• [Deploying authoritative OCaml-DNS servers as MirageOS unikernels]
• [Reproducible MirageOS unikernel builds]
• [Using Python and OCaml in the same Jupyter notebook]
• [Coq 8.11+beta1 is out]
• [Deep-Learning the Hardest Go Problem in the World]
• [Frama-C 20.0 (Calcium) is out. Download it here.]
• [Testing OCaml releases with opamcheck]
• [Coq 8.10.2 is out]
• [Announcing Irmin 2.0.0]
• [BAP 2.0 is released]
• [CI/CD pipelines: Monad, Arrow or Dart?]
• [On fixed-point theorems in synthetic computability]
• [Runners in action]
• [Coq 8.10.1 is out]
• [Announcing MirageOS 3.6.0]
• [Commas in big numbers everywhere: An OpenType adventure]
• [Coq 8.10.0 is out]
• [OCaml expert and beginner training by OCamlPro (in French):
Nov. 5-6 & 7-8]
• [Mr. MIME - Parse and generate emails]
• [A look back on OCaml since 2011]
• [Frama-C 19.1 (Potassium) is out. Download ithere.]
• [Coq 8.10+beta3 is out]
• [Updated Cheat Sheets: OCaml Language and OCaml Standard Library]
• [Frama-Clang 0.0.7 is out. Download ithere.]
• [Decompress: Experiences with OCaml optimization]
• [On complete ordered fields]
• [An introduction to fuzzing OCaml with AFL, Crowbar and Bun]
• [What is algebraic about algebraic effects?]
• [The blog moved from Wordpress to Jekyll]
• [OCamlPro’s compiler team work update]
• [What the interns have wrought, 2019 edition]
• [Decompress: The New Decompress API]
[ezcurl] <https://github.com/c-cube/ezcurl>
[OCaml Planet] <http://ocaml.org/community/planet/>
[An in-depth Look at OCaml’s new “Best-fit” Garbage Collector Strategy]
<http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/>
[Sliding Tile Puzzle, Self-Contained OCaml Webapp]
<http://psellos.com/2020/03/2020.03.how-i-wrote-elastic-man.html>
[New version of Try OCaml in beta!]
<http://www.ocamlpro.com/2020/03/16/new-version-of-try-ocaml-in-beta/>
[Frama-Clang 0.0.8 is out. Download it here.]
<http://frama-c.com/index.html>
[A reasonable TyXML release | Drup's thingies]
<https://drup.github.io/2020/03/06/tyxml440/>
[Alt-Ergo Users’ Club Annual Meeting]
<http://www.ocamlpro.com/2020/03/03/alt-ergo-userss-club-annual-meeting/>
[OCaml iOS Apps Ported to Browser]
<http://psellos.com/2020/02/2020.02.kid-charlemagne.html>
[Watch all of Jane Street's tech talks]
<https://blog.janestreet.com/watch-all-of-jane-streets-tech-talks/>
[Mercurial: prettyconfig extension]
<http://blog.0branch.com/posts/2020-02-15-prettyconfig-extension.html>
[Mercurial extensions (update)]
<http://blog.0branch.com/posts/2020-02-05-hg-extensions.html>
[2019 at OCamlPro]
<http://www.ocamlpro.com/2020/02/04/2019-at-ocamlpro/>
[Bitbucket repository migration]
<http://blog.0branch.com/posts/2020-02-03-bitbucket-migration.html>
[Troubleshooting systemd with SystemTap]
<https://blog.janestreet.com/troubleshooting-systemd-with-systemtap/>
[Ocsigen Start updated]
<https://ocsigen.github.io/blog/2020/01/20/release/>
[opam 2.0.6 release]
<http://www.ocamlpro.com/2020/01/16/opam-2-0-6-release/>
[opam 2.0.6 release] <https://opam.ocaml.org/blog/opam-2-0-6/>
[Hackers and climate activists join forces in Leipzig]
<https://mirage.io/blog/ccc-2019-leipzig>
[Deploying authoritative OCaml-DNS servers as MirageOS unikernels]
<https://hannes.nqsb.io/Posts/DnsServer>
[Reproducible MirageOS unikernel builds]
<https://hannes.nqsb.io/Posts/ReproducibleOPAM>
[Using Python and OCaml in the same Jupyter notebook]
<https://blog.janestreet.com/using-python-and-ocaml-in-the-same-jupyter-notebook/>
[Coq 8.11+beta1 is out]
<https://coq.inria.fr/news/coq-8-11beta1-is-out.html>
[Deep-Learning the Hardest Go Problem in the World]
<https://blog.janestreet.com/deep-learning-the-hardest-go-problem-in-the-world/>
[Frama-C 20.0 (Calcium) is out. Download it here.]
<http://frama-c.com/index.html>
[Testing OCaml releases with opamcheck]
<http://gallium.inria.fr/blog/an-ocaml-release-story-1>
[Coq 8.10.2 is out] <https://coq.inria.fr/news/coq-8-10-2-is-out.html>
[Announcing Irmin 2.0.0] <https://mirage.io/blog/introducing-irmin-v2>
[BAP 2.0 is released]
<http://binaryanalysisplatform.github.io/bap-2-release>
[CI/CD pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
[On fixed-point theorems in synthetic computability]
<http://math.andrej.com/2019/11/07/on-fixed-point-theorems-in-synthetic-computability/>
[Runners in action]
<http://math.andrej.com/2019/10/28/runners-in-action/>
[Coq 8.10.1 is out] <https://coq.inria.fr/news/coq-8-10-1-is-out.html>
[Announcing MirageOS 3.6.0]
<https://mirage.io/blog/announcing-mirage-36-release>
[Commas in big numbers everywhere: An OpenType adventure]
<https://blog.janestreet.com/commas-in-big-numbers-everywhere/>
[Coq 8.10.0 is out] <https://coq.inria.fr/news/coq-8-10-0-is-out.html>
[OCaml expert and beginner training by OCamlPro (in French): Nov. 5-6 &
7-8]
<http://www.ocamlpro.com/2019/09/25/ocaml-expert-and-beginner-training-by-ocamlpro-in-french-nov-5-6-7-8/>
[Mr. MIME - Parse and generate emails]
<https://tarides.com/blog/2019-09-25-mr-mime-parse-and-generate-emails.html>
[A look back on OCaml since 2011]
<http://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/>
[Frama-C 19.1 (Potassium) is out. Download ithere.]
<http://frama-c.com/index.html>
[Coq 8.10+beta3 is out]
<https://coq.inria.fr/news/coq-8-10beta3-is-out.html>
[Updated Cheat Sheets: OCaml Language and OCaml Standard Library]
<http://www.ocamlpro.com/2019/09/13/updated-cheat-sheets-ocaml-language-and-ocaml-standard-library/>
[Frama-Clang 0.0.7 is out. Download ithere.]
<http://frama-c.com/index.html>
[Decompress: Experiences with OCaml optimization]
<https://tarides.com/blog/2019-09-13-decompress-experiences-with-ocaml-optimization.html>
[On complete ordered fields]
<http://math.andrej.com/2019/09/09/on-complete-ordered-fields/>
[An introduction to fuzzing OCaml with AFL, Crowbar and Bun]
<https://tarides.com/blog/2019-09-04-an-introduction-to-fuzzing-ocaml-with-afl-crowbar-and-bun.html>
[What is algebraic about algebraic effects?]
<http://math.andrej.com/2019/09/03/what-is-algebraic-about-algebraic-effects/>
[The blog moved from Wordpress to Jekyll]
<http://math.andrej.com/2019/09/03/the-blog-moved-from-wordpress-to-jekyll/>
[OCamlPro’s compiler team work update]
<http://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>
[What the interns have wrought, 2019 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2019/>
[Decompress: The New Decompress API]
<https://tarides.com/blog/2019-08-26-decompress-the-new-decompress-api.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 47059 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-14 7:28 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-04-14 7:28 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 8637 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of April 07 to 14,
2020.
Table of Contents
─────────────────
Announcing dune-deps: produces a project-centric dependency graph
OCamlformat 0.14.0
Dune 2.5.0
Old CWN
Announcing dune-deps: produces a project-centric dependency graph
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-dune-deps-produces-a-project-centric-dependency-graph/5451/3>
Martin Jambon announced
───────────────────────
Since the original announcement, I received some good feedback from
users working on large projects. Thank you!
The latest version released today is 1.2.0. It is already available on
opam-repository (thank you @kit-ty-kate). The changes since the
original release, besides bug fixes, include:
• Ability to select or ignore dune files and folders to scan. For
example, `dune-deps foo bar -x bar/test' uses all the dune files
found in folders `foo' and `bar' but will ignore `bar/test'. This is
useful for ignoring uninteresting parts of the project and for
ignoring parse errors (see bug [#4]).
• Executable name disambiguation. For example, private executables of
the same name like `foo/main' and `bar/baz/main' are now rendered as
`main<foo>' and `main<baz>' respectively instead of just `main'.
• Optional exclusion of all executables or all external libraries with
`--no-exe' and `--no-ext'.
• Ability to show only the dependencies and/or the reverse
dependencies of selected libraries. See below.
Whole-project graphs for large projects tend to be unreadable. To deal
with that, I added support for an "hourglass view" (⌛) option for
showing only the dependencies and reverse dependencies of a component
of interest.
The following is obtained with `-h opam-client' on the opam project:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/6/66098faac9fd6681e3c0f4fe357aef8ff34bcaf2.png>
Please [let us know] if this works for your favorite projects! The
source code of dune-deps makes it somewhat easier now to experiment
with new strategies for eliminating nodes. See the `Filter' and
`Filterable' modules.
Check out `dune-deps --help' for detailed documentation on the
options.
[#4] <https://github.com/mjambon/dune-deps/issues/4>
[let us know] <https://github.com/mjambon/dune-deps/issues>
Sean Grove said and Martin Jambon replied
─────────────────────────────────────────
That’s a nice idea - it’d be great to have this available
as a GitHub action so anyone could do this with just a
click or two!
So, I made a [generic yaml workflow] that people can stick into their
git/github project. This will automatically maintain the dependency
graph `.deps/deps.png' which can be included in a readme.
[generic yaml workflow] <https://github.com/mjambon/dune-deps-action>
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/21>
Etienne Millon announced
────────────────────────
As described in this thread, ocamlformat 0.14.0 introduced a new
algorithm to determine how documentation comments are placed. We
underestimated the impact of making this the default, and this means
that many unwanted diffs were present for 0.13.0 -> 0.14.0 upgrades.
We are going to prepare a 0.14.1 release next week reverting this
behavior back to the 0.13.0 defaults. Users still on 0.13.0 are
encouraged to wait for this and upgrade directly to 0.14.1.
Sorry for the inconvenience, and thanks for the feedback!
Dune 2.5.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-5-0/5494/1>
Rudi Grinberg announced
───────────────────────
The dune team is pleased to announce the release of dune 2.5.0. This
release has been brewing for a while and contains a few interesting
features. I'll highlight some of the bigger ones:
• The coq support has been thoroughly extended. There's now support
for both composition of coq libraries in the same workspace and
extraction of coq code to OCaml.
• There's a new `$ dune upgrade' subcommand to help you upgrade dune
files from 1.x to 2.x
• `$ dune utop' will now load ppx preprocessors to the toplevel. Ppx
authors might enjoy this style of interactive development.
• There's a new `(subdir ..)' stanza that can be used to evaluate
stanzas in sub directories. This makes it possible to have a single
dune file for an entire project (generated or not).
I'd like to thank everyone who contributed to dune 2.5.0. Your help is
greatly appreciated.
Here's the full change log:
2.5.0 (09/04/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Add a `--release' option meaning the same as `-p' but without the
package filtering. This is useful for custom `dune' invocation in
opam files where we don't want `-p' (#3260, @diml)
• Fix a bug introduced in 2.4.0 causing `.bc' programs to be built
with `-custom' by default (#3269, fixes #3262, @diml)
• Allow contexts to be defined with local switches in workspace files
(#3265, fix #3264, @rgrinberg)
• Delay expansion errors until the rule is used to build something
(#3261, fix #3252, @rgrinberg, @diml)
• [coq] Support for theory dependencies and compositional builds using
new field `(theories ...)' (#2053, @ejgallego, @rgrinberg)
• From now on, each version of a syntax extension must be explicitely
tied to a minimum version of the dune language. Inconsistent
versions in a `dune-project' will trigger a warning for version
<=2.4 and an error for versions >2.4 of the dune language. (#3270,
fixes #2957, @voodoos)
• [coq] Bump coq lang version to 0.2. New coq features presented this
release require this version of the coq lang. (#3283, @ejgallego)
• Prevent installation of public executables disabled using the
`enabled_if' field. Installation will now simply skip such
executables instead of raising an error. (#3195, @voodoos)
• `dune upgrade' will now try to upgrade projects using versions <2.0
to version 2.0 of the dune language. (#3174, @voodoos)
• Add a `top' command to integrate dune with any toplevel, not just
utop. It is meant to be used with the new `#use_output' directive of
OCaml 4.11 (#2952, @mbernat, @diml)
• Allow per-package `version' in generated `opam' files (#3287,
@toots)
• [coq] Introduce the `coq.extraction' stanza. It can be used to
extract OCaml sources (#3299, fixes #2178, @rgrinberg)
• Load ppx rewriters in dune utop and add pps field to toplevel
stanza. Ppx extensions will now be usable in the toplevel (#3266,
fixes #346, @stephanieyou)
• Add a `(subdir ..)' stanza to allow evaluating stanzas in sub
directories. (#3268, @rgrinberg)
• Fix a bug preventing one from running inline tests in multiple modes
(#3352, @diml)
• Allow the use of the `%{profile}' variable in the `enabled_if' field
of the library stanza. (#3344, @mrmr1993)
• Allow the use of `%{ocaml_version}' variable in `enabled_if' field
of the library stanza. (#3339, @voodoos)
• Fix dune build freezing on MacOS when cache is enabled. (#3249,
fixes ##2973, @artempyanykh)
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 20312 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-04-07 7:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-04-07 7:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 26459 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 31 to April
07, 2020.
Table of Contents
─────────────────
Making a music player in OCaml
The end of Camlp4
OCamlformat 0.14.0
ML Family Workshop 2020: Call for presentations
Announcing Sek, an efficient implementation of sequences
Announcing dune-deps: produces a project-centric dependency graph
OCaml Users and Developers Meeting 2020
Old CWN
Making a music player in OCaml
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/making-a-music-player-in-ocaml/5413/1>
Dracose asked
─────────────
I'm interested in making my own music player in OCaml so I wanted to
know whether there were any existing ones and/or examples of how to
make one. Bear in mind, I am interested in the actual logic of how to
read a music file (or a playlist) and listening to it, rather than the
front-end part of a music player. (My knowledge of OCaml is
intermediate)
Thomas Blanc suggested
──────────────────────
You want to check <https://github.com/savonet/liquidsoap>
Yotam Barnoy then said
──────────────────────
Wow @PatJ I didn't know about liquidsoap. I added it to
ocamlverse. This is what we have for the audio page now, in case it's
helpful to the OP: <https://ocamlverse.github.io/content/audio.html>
gndl also replied
─────────────────
I experimented with several solutions in the [playo] project. One of
the possible solutions is to use [ocaml-gstreamer]. If you find that
the gstreamer framework is too annoying (which I can understand :-),
you can use [ocaml-ffmpeg]. note however that, in the latest version
of ocaml-ffmpeg, the audio device output [no longer works]. To
overcome this drawback, you can use [ocaml-portaudio].
[playo] <https://github.com/gndl/playo>
[ocaml-gstreamer] <https://github.com/savonet/ocaml-gstreamer>
[ocaml-ffmpeg] <https://github.com/savonet/ocaml-ffmpeg>
[no longer works] <https://github.com/savonet/ocaml-ffmpeg/issues/32>
[ocaml-portaudio] <https://github.com/savonet/ocaml-portaudio>
The end of Camlp4
═════════════════
Archive: <https://discuss.ocaml.org/t/the-end-of-camlp4/4216/96>
Continuing this old thread, Chet Murthy announced
─────────────────────────────────────────────────
Perhaps worth mentioning briefly that for anybody who -wants- to
continue using camlp4, I'm (a) maintaining camlp5 and bringing it
up-to-date with everything in ocaml 4.10.0 that I can think of, and
(b) I'd be happy to help them port their dependency over to camlp5.
This is not to be construed as an argument for using camlp4/5.
OCamlformat 0.14.0
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-14-0/5435/1>
Etienne Millon announced
────────────────────────
On behalf of the development team, I'd like to announce the release of
ocamlformat version 0.14.0 :tada:.
Here are the main highlights of this release:
Support for OCaml 4.10
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This means both that it compiles and runs using this version, but also
that it can format 4.10-specific language features (`module _' and
multi-indices operators).
Preliminary support for invalid files
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
As OCamlformat operates on ASTs, it normally requires a valid input
file. This release adds a `--format-invalid-files' option to detect
invalid parts and print them verbatim. This feature is still
experimental.
Preserving more concrete syntax
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Starting with this release, OCamlformat is going to preserve more
concrete syntax. For example, `module M = functor (K : S) -> struct
end' and `module M (K : S) = struct end' are equivalent. In the past,
both variants would be formatted as the latter. Now, the original
syntax is preserved. In some cases, preserving was possible through
the means of an option: for example, to choice between `let%name x = e
in body' and `[%name let x = e in body]', was controlled by the
`extension-sugar' option. This option is now deprecated and
OCamlformat will now always preserve what was in the source file (this
was the default behaviour).
Similarly, it was possible to control how special characters are
escaped in string and character literals through the `escape-strings'
and `escape-chars' options. They are being deprecated and the only
possible behavior will be preserving the concrete syntax (as done by
default).
The reason for this change is that we feel that ocamlformat should be
just about formatting. The fact that this behavior was configurable is
in part due to the fact that it operates on OCaml ASTs, but end users
should not have to be surprised by their code being transformed on
reformatting.
In the future, we plan to extend that to other similar constructs,
such as using `(~/')~ or `begin~/~end', or spacing between module
items.
Placement of doc comments
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Placing doc comments `(** ... *)' is controlled by the `doc-comments'
configuration option. It is always possible to put them before the
item they refer to, and this is what the `doc-comments=before' option
does. The alternative `doc-comments=after' will try to do its best to
put them after, but in some cases it is not possible. For example, in
a variant type declaration, a doc-comment put immediately after will
be attached to the last constructor by documentation
tools. Ocamlformat needs to preserve the meaning of programs, so in
these cases, it will instead put the comment before. In the case of
`module' declarations, putting the comment after might not be very
useful if the corresponding module is very large.
This requires a complex rule to determine which comments will be put
before and which comments will be put after. So in this version, we
are deprecating this mechanism and replacing it with a simpler one
controlled by `doc-comments-val' that applies only to `val' and
`external' items. For these items, it is always possible to attach
documents before or after them. For all other items, like type or
module declarations, the doc comments will consistenly be put before.
Many bugs found by fuzzing
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We hooked ocamlformat to AFL, looking for programs that parse
correctly but trigger errors during formatting. This approach worked
very well and more than 20 logical bugs were found with this
technique.
Upgrading
╌╌╌╌╌╌╌╌╌
To upgrade from ocamlformat 0.13.0, one needs to upgrade the
ocamlformat binary and replace the `version' field in `.ocamlformat'
files by `0.14.0' and then:
• if you used `doc-comments=after', you can replace it by
`doc-comments-val=after'. This will move doc-comments on module
items except `val' and `external' ones.
• if you used `doc-comments=before', you can remove it as it is now
the default.
• if you set `escape-chars=preserve', `escape-strings=preserve', or
`extension-sugar=preserve' explicitly, you can
remove them safely (they were the default)
• if you used another value for one of these options (such as
`escape-strings=hexadecimal'), you will need to remove them as
well. This will not trigger a diff, but ocamlformat will not enforce
a particular concrete syntax for new code.
A note for new users
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We encourage you to try ocamlformat, that can be installed from opam
directly (`opam install ocamlformat'), but please remember that it is
still beta software. We added a [FAQ for new users] that should help
you decide if ocamlformat is the right choice for you.
[FAQ for new users]
<https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users>
Etienne Millon later added
──────────────────────────
This upgrade is likely to generate a huge diff on projects that use
the default profile, so I would like to expand a bit on the reason.
According to [the syntax rules used by the ocaml tools] (the ocaml
compilers, ocamldoc, odoc), it is always possible to put the
doc-comment before an item.
Some teams prefer to put the documentation after. But that is not
always possible. For example, `type t = A | B (** doc *)' will attach
the doc-comment to `B', not to `t'. The only way to attach the comment
to `t' is by putting the comment before.
Enter ocamlformat: doc-comment placement is controlled by an option
with two values, `before' or `after'. `before' will always place the
comment before. `after' determines if it is possible to put the
comment after, and if it is not, will put it before.
Some items cannot have comments after, like variant types (as
described above). But there is another reason not to put comments
after. In some cases, that can put the comment far from the thing it
is documenting. Considering modules, the following is nice:
┌────
│ module M = L.M
│ (** doc *)
└────
But this is not great is the structure is large:
┌────
│ module M = struct
│ ...
│ ...
│ end
│ (** doc *)
└────
To summarize, when ocamlformat is configured to put comments after, it
has to follow a complex heuristic to determine whether it has to
fallback to before. In the case of a module, it depends on its shape,
how many functor arguments are there, this kind of things (for various
reasons, we don't know how large something is going to be in advance,
so we have to look at its shape). The point is that it is complicated
to understand and explain, and that fixing it always makes it more
complex. Another aspect is that in the end, we want ocamlformat to be
pretty stable when it reaches 1.0.0, and complex rules are at odds
with this goal.
So, we have decided to simplify the rule: instead of looking deep in
the AST, we just look at the kind of item this is. For `val' and
`external' items, it is always possible to put the doc-comment after,
so we follow exactly what the configuration option says.
As a user of the default profile, what this means for you: for items
that are not `val' or `external', and considered "simple" by the
0.13.0 heuristic, doc-comments are going to move from after to before.
Based on these reasons, you will understand that `before' is always
simpler. You can opt into this by setting
`doc-comments-val=before'. This will cause an even larger diff as all
items are going to move before (that is: all items described just
above, plus `val' and `external' items), but the rule gets extremely
simple (everything is put before). It is possible that this option
will become the default in the future, but we have not decided this
yet (in this case, if you did not opt into it, you will see comments
on `val' and `external' items move at that time).
[the syntax rules used by the ocaml tools]
<https://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html#ss:ocamldoc-placement>
ML Family Workshop 2020: Call for presentations
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ml-family-workshop-2020-call-for-presentations/5441/1>
Leo White announced
───────────────────
We are happy to invite submissions to the ML Family Workshop 2020, to
be held during the ICFP conference week on Thursday, August 27th.
The ML family workshop warmly welcomes submission touching on the
programming languages traditionally seen as part of the "ML family"
(Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml,
etc.). The scope of the workshop includes all aspects of the design,
semantics, theory, application, implementation, and teaching of the
members of the ML family. We also encourage presentations from related
languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*,
Eff, ATS, etc), to exchange experience of further developing ML ideas.
Currently, the workshop is still scheduled to go ahead as planned in
Jersey City, however it is likely that the ML workshop will end up
being a virtual workshop this year. Either way provisions will be made
to allow speakers to present their work remotely.
See our detailed CFP online on the ICFP website:
<https://icfp20.sigplan.org/home/mlfamilyworkshop-2020>
Important dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Friday 15th May (any time zone): Abstract submission deadline
• Friday 26th June: Author notification
• Thursday 27th August: ML Family Workshop
Program committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Youyou Cong (Tokyo Institute of Technology)
• Gowtham Kaki (Purdue University)
• Neel Krishnaswami (University of Cambridge)
• Daan Leijen (Microsoft Research)
• Koko Muroya (Kyoto University)
• Atsushi Ohori (Tohoku University)
• Jonathan Protzenko (Microsoft Research)
• Gabriel Radanne (INRIA)
• Claudio Russo (Dfinity)
• Leo White (Jane Street) (Chair)
• Jeremy Yallop (University of Cambridge)
Submission details
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
See the online CFP for the details on the expected submission format.
Submissions must be uploaded to the workshop submission website
<https://ml2020.hotcrp.com/>
before the submission deadline.
Announcing Sek, an efficient implementation of sequences
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-sek-an-efficient-implementation-of-sequences/5442/1>
François Pottier announced
──────────────────────────
We are pleased to announce the first release of Sek, an OCaml library
that offers an efficient implementation of sequences.
The library offers both ephemeral (mutable) sequences and persistent
(immutable) sequences, and offers constant-time conversions between
these flavors.
It supports all of the standard operations on stacks, queues, deques
(e.g. push, pop at either end), catenable sequences (concat, split),
and random access sequences (get, set).
Data is stored internally in chunks (fixed-capacity arrays), which is
why this data structure is known as a chunK SEquence.
It is intended to achieve excellent time complexity and memory usage.
This is an initial release. The library has not been tested in
production, but has received extensive unit testing, via afl-fuzz and
ocaml+afl – which are remarkably effective tools, by the way!
This is work in progress; more features, such as iterators, will be
added in the future.
To install Sek, just type
┌────
│ opam update && opam install sek
└────
Documentation is [online].
Feedback is welcome!
Arthur Charguéraud
François Pottier
with contributions by Émilie Guermeur
[online] <http://cambium.inria.fr/~fpottier/sek/doc/sek/Sek/index.html>
Yaron Minsky asked and Fabian replied
─────────────────────────────────────
I’m particularly interested in how it compares to
Base.Sequence and Seq in the OCaml distribution, but
surely there are others as well.
This actually looks like an array/vector structure (supporting, among
other things, fast access to the nth element), so a comparison with
`CCVector', `CCFun_vec', `BatVect', `Clarity.Vector' etc. would be
more appropriate. The name is a bit unfortunate considering the naming
used in the general ecosystem.
Some time ago, I added some crude benchmarks to [containers'
benchsuite]. I'll see if I can add Sek when I find time.
[containers' benchsuite]
<https://github.com/c-cube/ocaml-containers/blob/d34b7588b028f3618cc44d3f4c6417295db586c8/benchs/run_benchs.ml#L112>
gasche said
───────────
I think it really is a sequence library in the sense that in maintains
an in-order sequence of items, and sequences can be joined/split
efficiently. It also provides logarithmic random access, but this is
probably not competitive with fixed-size arrays. It would be
comparable to "persistent vector" libraries, ropes, finger trees,
etc. The fact that the authors expose a Stack/Queue interface suggests
that it has also been tuned to perform reasonably well in this case.
It does not provide any delayed computation of items, so in that
regard it is not comparable to Sequence/Seq.
@charguer has designed similar datastructures in the past to represent
the work-queues of concurrent workers (you want at least a fast "push"
to add a new task and, when doing work-stealing, having a fast "split"
is convenient). See [Theory and Practice of Chunked Sequences], Umut
Acar, Arthur Charguéraud, Mike Rainey, 2014, and [A Work-Efficient
Algorithm for Parallel Unordered Depth-First Search].
As far as I know, the OCaml implementation just released has not been
tested/benchmarked for parallel algorithms. I would be curious to see
an experiment of parallel graph traversal with this structure and
Multicore-OCaml.
[Theory and Practice of Chunked Sequences]
<https://www.chargueraud.org/research/2014/chunkedseq/chunkedseq.pdf>
[A Work-Efficient Algorithm for Parallel Unordered Depth-First Search]
<https://www.chargueraud.org/research/2015/pdfs/pdfs_sc15.pdf>
Announcing dune-deps: produces a project-centric dependency graph
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announcing-dune-deps-produces-a-project-centric-dependency-graph/5451/1>
Martin Jambon announced
───────────────────────
I'm happy to announce the availability of [dune-deps], a command-line
tool that scans a dune project and gathers the dependencies into a
graph. The output is in the dot format, supported by the `dot' command
from [graphviz].
It shows the dependencies between the following:
• libraries defined by the project,
• executables defined by the project,
• direct dependencies on external libraries.
Dependencies are extracted by parsing `dune' files. As an example,
here's what we obtain for the [sources of opam], which has over 50K
lines of code:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/f/f6213fa7fda52521c6782988155ab23b997dafb8.png>
The commands for this are:
┌────
│ # obtain the project's sources
│ $ git clone --depth=1 https://github.com/ocaml/opam.git
│
│ # extract dependencies and eliminate superfluous graph edges
│ $ dune-deps opam | tred > deps.dot
│
│ # render the graph
│ $ dot -Tpng deps.dot -o deps.png
└────
A suggestion is to include such graph in your project's `README.md'.
[dune-deps] <https://github.com/mjambon/dune-deps>
[graphviz] <https://www.graphviz.org/>
[sources of opam] <https://github.com/ocaml/opam>
OCaml Users and Developers Meeting 2020
═══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-users-and-developers-meeting-2020/5454/1>
Ivan Gotovchits announced
─────────────────────────
It is my pleasure to invite submissions to the OCaml Users and
Developers Workshop 2020, which is again co-located with ICFP and will
be held on Friday 28th August 2020 in Jersey City, NJ, USA.
The OCaml Users and Developers Workshop brings together the OCaml
community, including users of OCaml in industry, academia, hobbyists
and the free software community. Previous editions have been
co-located with ICFP since 2012 in Copenhagen, Boston, Gothenburg,
Nara, Oxford, St Louis and last year in Berlin, following OCaml
Meetings in Paris in 2010 and 2011.
Important Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• <https://ocaml.org/meetings/ocaml/2020/>
• <https://icfp20.sigplan.org/home/ocaml-2020>
• <https://ocaml2020.hotcrp.com/>
Important Dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Talk proposal submission deadline: May 8th, 2020, AoE
• Author Notification: June 26th, 2020
• OCaml Workshop: August 28th, 2020
Scope
╌╌╌╌╌
Presentations and discussions focus on the OCaml programming language
and its community. We aim to solicit talks on all aspects related to
improving the use or development of the language and its programming
environment, including, for example (but not limited to):
• compiler developments, new backends, runtime and architectures
• practical type system improvements, such as GADTs, first-class
modules, generic programming, or dependent types
• new library or application releases, and their design rationales
• tools and infrastructure services, and their enhancements
• prominent industrial or experimental uses of OCaml, or deployments
in unusual situations.
Presentations
╌╌╌╌╌╌╌╌╌╌╌╌╌
The workshop is an informal meeting with no formal proceedings. The
presentation material will be available online from the workshop
homepage. The presentations may be recorded and made available at a
later date.
The main presentation format is a workshop talk, traditionally around
20 minutes in length, plus question time, but we also have a poster
session during the workshop – this allows to present more diverse
work, and gives time for discussion. The program committee will decide
which presentations should be delivered as posters or talks.
Submission
╌╌╌╌╌╌╌╌╌╌
To submit a presentation, please register a description of the talk
(about 2 pages long) at
<https://ocaml2020.hotcrp.com/>
providing a clear statement of what will be provided by the
presentation: the problems that are addressed, the solutions or
methods that are proposed.
LaTeX-produced PDFs are a common and welcome submission format. For
accessibility purposes, we ask PDF submitters to also provide the
sources of their submission in a textual format, such as .tex
sources. Reviewers may read either the submitted PDF or the text
version.
ML family workshop
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The ML family workshop, held on the previous day, deals with general
issues of the ML-style programming and type systems, focuses on more
research-oriented work that is less specific to a language in
particular. There is an overlap between the two workshops, and we have
occasionally transferred presentations from one to the other in the
past. Authors who feel their submission fits both workshops are
encouraged to mention it at submission time and/or contact the Program
Chairs.
Program Committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Ivan Gotovchits, CMU, USA
• Florian Angeletti, INRIA, France
• Chris Casinghino, Draper Laboratory, USA
• Catherine Gasnier, Facebook, USA
• Rudi Grinberg, OCaml Labs, UK
• Oleg Kiselyov, Tohoku University, Japan
• Andreas Rossberg, Dfinity Stiftung, Germany
• Marcello Seri, University of Groningen, Netherlands
• Edwin Torok, Citrix, UK
• Leo White, Jane Street, USA
• Greta Yorsh, Jane Street, USA
• Sarah Zennou, Airbus, France
COVID-19 Notice
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While ICFP-20 [is still scheduled to be held as planned], chances are
high that it will be turned into a virtual conference. Which means a
wider audience and reduced (hopefully) fees. We will keep you posted.
[is still scheduled to be held as planned]
<https://icfp20.sigplan.org/home/icfp-2020>
Questions and contact
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Please send any questions to the chair: Ivan Gotovchits (ivg@ieee.org)
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 42475 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-31 9:54 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-03-31 9:54 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 30045 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 24 to 31,
2020.
Table of Contents
─────────────────
An In-Depth Look at OCaml’s New “Best-Fit” Garbage Collector Strategy
First release of Pp, a pretty-printing library
soupault: a static website generator based on HTML rewriting
routes: path based routing for web applications
Compiler Engineer at Mixtional Code in Darmstadt or anywhere else in Germany
tiny-httpd 0.5
Visual Studio Code plugin for OCaml
Dismas: a tool for automatically making cross-versions of opam packages
Multicore OCaml: March 2020 update
Old CWN
An In-Depth Look at OCaml’s New “Best-Fit” Garbage Collector Strategy
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/an-in-depth-look-at-ocaml-s-new-best-fit-garbage-collector-strategy/5370/1>
OCamlPro announced
──────────────────
The Garbage Collector is probably OCaml’s greatest unsung hero. Its
pragmatic approach allows us to allocate without much fear of
efficiency loss. We looked into its new "Best-fit" strategy and here
is what we learned!
[http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/]
[http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/]
<http://www.ocamlpro.com/2020/03/23/ocaml-new-best-fit-garbage-collector/>
First release of Pp, a pretty-printing library
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-pp-a-pretty-printing-library/5371/1>
Jérémie Dimino announced
────────────────────────
I'm happy to announce the first release of the [pp library]! This
library provides a lean alternative to the [Format module] of the
standard library. It uses the same comcepts of boxes and break hints,
however it defines its own algebra which some might find easier to
work with and reason about. I personally do :) The final rendering is
still done via a formatter which makes it easy to integrate `Pp' in
existing programs using `Format'.
We introduced this module in [Dune] to help improve the formatting of
messages printed in the terminal and it has been a success. The new
API is smaller, simpler and makes it easy for developers to do the
right thing. Once the `Pp' module of Dune was mature enough, we
decided to extract it into a separate library so that it could benefit
others.
The library itself is composed of a single `Pp' module and has no
dependencies. Its documentation is self-contained and no previous
knowledge is required to start using it, however the various guides
for the `Format' module such as [this one] should be applicable to
`Pp' as well.
If you have used `Format' before and like me found its API complicated
and difficult to use, I hope that you will find `Pp' nicer to work
with!
[pp library] <https://github.com/diml/pp>
[Format module]
<https://caml.inria.fr/pub/docs/manual-ocaml/libref/Format.html>
[Dune] <https://dune.build>
[this one] <http://caml.inria.fr/resources/doc/guides/format.en.html>
Josh Berdine then said
──────────────────────
Another great resource for understanding the core mental model of
Format is [Format Unraveled], although if I understand pp correctly
the discussion about Format not being document-based won't apply to
pp.
[Format Unraveled]
<https://hal.archives-ouvertes.fr/hal-01503081/file/format-unraveled.pdf>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/13>
Daniil Baturin announced
────────────────────────
[1.10.0] release is available.
Bug fixes:
• Files without extensions are handled correctly.
New features:
• Plugin discovery: if you save a plugin to `plugins/my-plugin.lua',
it's automatically loaded as a widget named
`my-plugin'. List of plugin directories is configurable.
• New plugin API functions: `HTMLget_tag_name', `HTML.select_any_of',
`HTML.select_all_of'.
• The `HTML' module is now "monadic": giving a nil to a function that
expects an element gives you a nil back, rather than cause a runtime
error.
[1.10.0] <https://soupault.neocities.org/blog/soupault-1.10-release>
routes: path based routing for web applications
═══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-routes-path-based-routing-for-web-applications/3624/6>
Anurag Soni announced
─────────────────────
[0.7.2] release is now available on opam. There have been quite a few
changes since the previous versions.
• Routes doesn't deal with HTTP methods anymore
• The internal implementation is now based around a trie like data
structure
• Routes have pretty printers
• sprintf style route printing is supported again
• Minimum supported OCaml version is now 4.05 (it used to be 4.06)
• There is a release available for bucklescript as well and it is
available to install via [npm].
[0.7.2] <http://opam.ocaml.org/packages/routes/>
[npm] <https://www.npmjs.com/package/@anuragsoni/routes>
Compiler Engineer at Mixtional Code in Darmstadt or anywhere else in Germany
════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/compiler-engineer-at-mixtional-code-in-darmstadt-or-anywhere-else-in-germany/5377/1>
Gerd Stolpmann announced
────────────────────────
Type of position:
• regular hire (no freelancers)
• full time
• work from home anywhere in Germany, or in the office in Darmstadt
• work for a small and highly skilled international team, located in
the US and Europe
• the team language is English
We are developing a compiler for a no-code platform that translates
our DSL to bytecode and/or WebAssembly. The language is largely of
functional type but is also able to manage state with a spreadsheet
model, allowing reactive programming without having to resort to
libraries. The language is statically typed using a Hindley-Milner
type checker. The compiler is primarily written in OCaml. Other
languages of our platform are Go, Elm, and Javascript.
We are looking for a compiler engineer with strong skills in all
relevant areas:
• fluent in OCaml or a similar language such as Haskell
• Understanding of the structure of the DSL, including syntax and
semantics
• Translation of FP languages to executable code
• Code optimization
• Graph algorithms
• Type checking
We are open to both juniors and seniors, and payment will be
accordingly. We are not so much interested in formal certifications
but rather in real practice, either from previous jobs, research
projects, or contributions to open source projects.
The no-code platform is being developed by engineers in Europe and the
US at various places, and we usually do not meet physically but in
video conferences. Working from home is very usual. We also get you a
desk in your home town if you prefer this. The compiler development is
lead by Gerd Stolpmann from Darmstadt.
Due to the strong connections to the US, video conferences will often
have to take place in evening hours, until around 7pm or 8pm.
Applications: please follow the "Apply" link at the official web page
describing the position: <https://rmx.mixtional.de/static/54657cda/>
Gerd Stolpmann
CEO of Mixtional Code GmbH (and OCaml hacker of the first hour)
Contact and company details: <https://www.mixtional.de/contact.html>
Sébastien Besnier asked
───────────────────────
I'm living in France, can I apply to the position (we are neighbors!)?
Gerd Stolpmann replied
──────────────────────
Well, I can (at the moment) only make contracts using German law and
for the social security system here. So, if you need a doctor you'd
have to travel… If my company was a bit bigger there would be the
option of opening a second site in France (even a very minimal one),
but the setup costs are so far too high (lawyers and accountants), and
it is too distracting for me to keep up with the fine points of the
system in France. Unfortunately, the EU is not that far that it is
super simple for an employer to hire anywhere in Europe. - Thanks for
asking.
tiny-httpd 0.5
══════════════
Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-5/5381/1>
Simon Cruanes announced
───────────────────────
I just released tiny-httpd 0.5 and the new tiny-httpd-camlzip, which
makes it possible to use `deflate' transparently for queries and
responses. The server has evolved quietly and is getting somewhat more
robust: I'm using it for an internal tool with big html pages (up to
several MB) and it's reasonably fast and doesn't seem to
memleak. There's also an improved `http_of_dir' to quickly and simply
serve a directory on an arbitrary port.
Previous announcement [here]
[here] <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727>
Visual Studio Code plugin for OCaml
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-preview-visual-studio-code-plugin-for-ocaml/5395/1>
Rudi Grinberg announced
───────────────────────
I'm proud to announce a preview release of an [VSC extension for
OCaml]. You can fetch and install this plugin directly from the
extension marketplace if you search for "OCaml Labs". The extension
isn't yet mature, but I believe that it offers a user experience
comparable to other VSC extensions for OCaml already. The plugin
should be used in conjunction with [ocaml-lsp]
The extension is for the OCaml "platform", which means that its scope
includes support for various tools used in OCaml development such as
dune, opam.
Bug reports & contributions are welcome. Happy hacking.
[VSC extension for OCaml]
<https://github.com/ocamllabs/vscode-ocaml-platform>
[ocaml-lsp] <https://github.com/ocaml/ocaml-lsp>
Dismas: a tool for automatically making cross-versions of opam packages
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-prototype-dismas-a-tool-for-automatically-making-cross-versions-of-opam-packages/5404/1>
Daniil Baturin announced
────────────────────────
opam-cross-* are seriously lagging behind the official opam repository
and fdopen's opam-windows, not least because importing packages by
hand is a lot of work. I suppose at least a semi-automated process
could help those repos grow and stay in sync with the upstream much
faster.
I've made a prototype of a tool for "stealing" packages into
cross-repos. For obvious reasons it's called Dismas. You can find it
here: <https://github.com/dmbaturin/scripts/blob/master/dismas.ml>
Limitations:
• the code is a real mess for now
• only dune is supported by automatic build command adjustment
• it cannot handle cases when both native and cross-version of a
dependency are needed
However:
• For simple packages that use dune exclusively, it's completely
automated. I've ported bigstreamaf and angstrom to test it, and
cross-versions built just fine from its output, no editing was
needed.
• It automatically converts dependencies from foo to too-$toolchain
and removes dependencies and build steps only
needed for `with-test' and `with-doc'.
┌────
│ $ ./dismas.ml windows containers ~/devel/opam-repository/packages/containers/containers.2.8.1/opam
│ opam-version: "2.0"
│ maintainer: "simon.cruanes.2007@m4x.org"
│ synopsis:
│ "A modular, clean and powerful extension of the OCaml standard library"
│ build: [
│ ["dune" "build" "-p" "containers" "-j" jobs "-x" "windows"]
│ ]
│ depends: [
│ "ocaml-windows" {>= "4.03.0"}
│ "dune" {>= "1.1"}
│ "dune-configurator"
│ "seq-windows"
│ ]
│ depopts: ["base-unix" "base-threads"]
│ tags: ["stdlib" "containers" "iterators" "list" "heap" "queue"]
│ homepage: "https://github.com/c-cube/ocaml-containers/"
│ doc: "https://c-cube.github.io/ocaml-containers"
│ dev-repo: "git+https://github.com/c-cube/ocaml-containers.git"
│ bug-reports: "https://github.com/c-cube/ocaml-containers/issues/"
│ authors: "Simon Cruanes"
│ url {
│ src: "https://github.com/c-cube/ocaml-containers/archive/v2.8.1.tar.gz"
│ checksum: [
│ "md5=d84e09c5d0abc501aa17cd502e31a038"
│ "sha512=8b832f4ada6035e80d81be0cfb7bdffb695ec67d465ed6097a144019e2b8a8f909095e78019c3da2d8181cc3cd730cd48f7519e87d3162442562103b7f36aabb"
│ ]
│ }
│
│ $ ./dismas.ml windows containers ~/devel/opam-repository/packages/containers/containers.2.8.1/opam | diff
│ ~/devel/opam-repository/packages/containers/containers.2.8.1/opam -
│ 3c3,4
│ < synopsis: "A modular, clean and powerful extension of the OCaml standard library"
│ ---
│ > synopsis:
│ > "A modular, clean and powerful extension of the OCaml standard library"
│ 5,7c6
│ < ["dune" "build" "-p" name "-j" jobs]
│ < ["dune" "build" "@doc" "-p" name ] {with-doc}
│ < ["dune" "runtest" "-p" name "-j" jobs] {with-test}
│ ---
│ > ["dune" "build" "-p" "containers" "-j" jobs "-x" "windows"]
│ 10,11c9,10
│ < "ocaml" { >= "4.03.0" }
│ < "dune" { >= "1.1" }
│ ---
│ > "ocaml-windows" {>= "4.03.0"}
│ > "dune" {>= "1.1"}
│ 13,21c12
│ < "seq"
│ < "qtest" { with-test }
│ < "qcheck" { with-test }
│ < "ounit" { with-test }
│ < "iter" { with-test }
│ < "gen" { with-test }
│ < "uutf" { with-test }
│ < "mdx" { with-test & >= "1.5.0" & < "2.0.0" }
│ < "odoc" { with-doc }
│ ---
│ > "seq-windows"
│ 23,27c14,15
│ < depopts: [
│ < "base-unix"
│ < "base-threads"
│ < ]
│ < tags: [ "stdlib" "containers" "iterators" "list" "heap" "queue" ]
│ ---
│ > depopts: ["base-unix" "base-threads"]
│ > tags: ["stdlib" "containers" "iterators" "list" "heap" "queue"]
└────
Things to do:
• identify all packages that don't need cross-versions. Is cppo one of
them, for example?
• add support for cases when both native and cross versions are
needed. If menhir the only one?
• add support for other build systems. Do all of them work well with
`OCAMLFIND_TOOLCHAIN=windows` if the build setup is written
correctly?
Input from @toots and @pirbo is welcome.
Romain Beauxis then said
────────────────────────
That's a great initiative! Here are a couple of thoughts:
• For dune-based packages, things are indeed pretty
straight-forward. Finding out which dependencies need to be ported
as cross-dependency is indeed the part that's hard to automatize
• For other build systems, it's less clear to me how to
automatize. Maybe others have some thoughts about it.
• The CI system on opam-cross-windows is pretty good at building from
scratch and failing if some deps are missing so trial and error
there can be a great tool.
• Once solved for one cross situation, the problem of
cross-dependencies should be exactly the same for all other cross
environment (android, iOS)
I haven't looked at the tool very closely yet but I'd say a first
improvement would be to be able to track cross-dependencies resolution
and generate new version of the package using them and/or generate
other cross-compiled packages using them.
Anton Kochkov said
──────────────────
For automated pull requests, you might be interested in
<https://discuss.ocaml.org/t/dependabot-and-ocaml/4282>
Daniil Baturin then asked
─────────────────────────
I'm not sure if I understand the premise of dependabot. Why would
anyone hardcode specific dependency versions? Maybe it makes sense in
certain ecosystems that suffer from never-ending ecological disasters…
;)
In any case, most opam packages don't have a constraint on the upper
versions of their dependencies. Can dependabot use custom tracking
rules to check for presense of a newer version in the repo? My
thought was much simpler actually: track the commits in
opam-repository, run recently changed files through Dismas and send
pull requests to opam-cross-*
Yawar Amin replied
──────────────────
It's common practice nowadays to use semantic versioning and have
lockfiles for reproducible builds. Dependabot updates semantic version
ranges and lockfiles. See e.g.
• <https://github.com/thoughtbot/velveteen/pull/31/files>
• <https://github.com/mozilla/adr/pull/77/files>
Multicore OCaml: March 2020 update
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-march-2020-update/5406/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the March 2020 news update from the Multicore OCaml team!
This update has been assembled with @shakthimaan and @kayceesrk, as
with the [February] and [January] ones.
Our work this month was primarily focused on performance improvements
to the Multicore OCaml compiler and runtime, as part of a
comprehensive evaluation exercise. We continue to add additional
benchmarks to the Sandmark test suite. The eventlog tracing system and
the use of hash tables for marshaling in upstream OCaml are in
progress, and more PRs are being queued up for OCaml 4.11.0-dev as
well.
The biggest observable change for users trying the branch is that a
new GC (the "parallel minor gc") has been merged in preference to the
previous one ("the concurrent minor gc"). We will have the details in
longer form at a later stage, but the essential gist is that *the
parallel minor GC no longer requires a read barrier or changes to the
C API*. It may have slightly worse scalability properties at a very
high number of cores, but is roughly equivalent at up to 24 cores in
our evaluations. Given the vast usability improvement from not having
to port existing C FFI uses, we have decided to make the parallel
minor GC the default one for our first upstream runtime patches. The
concurrent minor GC follow at a later stage when we ramp up testing to
64-core+ machines. The [multicore opam remote] has been updated to
reflect these changes, for those who wish to try it out at home.
We are now at a stage where we are porting larger applications to
multicore. Thanks go to:
• @UnixJunkie who helped us integrate the Gram Matrix benchmark in
<https://github.com/ocaml-bench/sandmark/issues/99>
• @jhw has done extensive work towards supporting Systhreads in
<https://github.com/ocaml-multicore/ocaml-multicore/pull/240>. Systhreads
is currently disabled in multicore, leading to some popular packages
not compiling.
• @antron has been advising us on how best to port `Lwt_preemptive`
and the `Lwt_unix` modules to multicore, giving us a widely used IO
stack to test more applications against.
If you do have other suggestions for application that you think might
provide useful benchmarks, then please do get in touch with myself or
@kayceesrk.
Onto the details! The various ongoing and completed tasks for
Multicore OCaml are listed first, which is followed by the changes to
the Sandmark benchmarking infrastructure and ongoing PRs to upstream
OCaml.
[February]
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227>
[January]
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090>
[multicore opam remote]
<https://github.com/ocaml-multicore/multicore-opam>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Ongoing
• [ocaml-multicore/ocaml-multicore#240] Proposed implementation of
threads in terms of Domain and Atomic
A new implementation of the `Threads` library for use with the new
`Domain` and `Atomic` modules in Multicore OCaml has been
proposed. This builds Dune 2.4.0 which in turn makes it useful to
build other packages. This PR is open for review.
• [ocaml-multicore/safepoints-cmm-mach] Better safe points for OCaml
A newer implementation to insert safe points at the Cmm level is
being worked upon in this branch.
[ocaml-multicore/ocaml-multicore#240]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/240>
[ocaml-multicore/safepoints-cmm-mach]
<https://github.com/anmolsahoo25/ocaml-multicore/tree/safepoints-cmm-mach>
◊ Completed
The following PRs have been merged into Multicore OCaml:
• [ocaml-multicore/ocaml-multicore#303] Account correctly for
incremental mark budget
The patch correctly measures the incremental mark budget value, and
improves the maximum latency for the `menhir.ocamly` benchmark.
• [ocaml-multicore/ocaml-multicore#307] Put the phase change event in
the actual phase change code. The PR includes the
`major_gc/phase_change` event in the appropriate context.
• [ocaml-multicore/ocaml-multicore#309] Don't take all the full pools
in one go.
The code change selects one of the `global_full_pools` to try
sweeping it later, instead of adopting all of the full ones.
• [ocaml-multicore/ocaml-multicore#310] Statistics for the current
domain are more recent than other domains
The statistics (`minor_words`, `promoted_words`, `major_words`,
`minor_collections`) for the current domain are more recent, and are
used in the right context.
• [ocaml-multicore/ocaml-multicore#315] Writes in `caml_blit_fields`
should always use `caml_modify_field` to record `young_to_young`
pointers
The PR enforces that `caml_modify_field()` is always used to store
`young_to_young` pointers.
• [ocaml-multicore/ocaml-multicore#316] Fix bug with `Weak.blit`.
The ephemerons are allocated as marked, but, the keys or data can be
unmarked. The blit operations copy weak references from one
ephemeron to another without marking them. The patch marks the keys
that are blitted in order to keep the unreachable keys alive for
another major cycle.
• [ocaml-multicore/ocaml-multicore#317] Return early for 0 length blit
The PR forces a `CAMLreturn()` call if the blit length is zero in
`byterun/weak.c`.
• [ocaml-multicore/ocaml-multicore#320] Move `num_domains_running`
decrement
The `caml_domain_alone()` invocation needs to be used in the shared
heap teardown, and hence the `num_domains_running` decrement is
moved as the last operation for at least the `shared_heap` lockfree
fast paths.
[ocaml-multicore/ocaml-multicore#303]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/303>
[ocaml-multicore/ocaml-multicore#307]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/307>
[ocaml-multicore/ocaml-multicore#309]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/309>
[ocaml-multicore/ocaml-multicore#310]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/310>
[ocaml-multicore/ocaml-multicore#315]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/315>
[ocaml-multicore/ocaml-multicore#316]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/316>
[ocaml-multicore/ocaml-multicore#317]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/317>
[ocaml-multicore/ocaml-multicore#320]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/320>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
The [Sandmark] performance benchmarking test suite has had newer
benchmarks added, and work is underway to enhance its functionality.
• [ocaml-bench/sandmark#88] Add PingPong Multicore benchmark
The PingPong benchmark that uses producer and consumer queues has
now been included into Sandmark.
• [ocaml-bench/sandmark#98] Add the read/write Irmin benchmark
A basic read/write file performance benchmark for Irmin has been
added to Sandmark. You can vary the following input parameters:
number of branches, number of keys, percentage of reads and writes,
number of iterations, and the number of write operations.
• [ocaml-bench/sandmark#100] Add Gram Matrix benchmark
A request [ocaml-bench/sandmark#99] to include the Gram Matrix
initialization numerical benchmark was created. This is useful for
machine learning applications and is now available in the Sandmark
performance benchmark suite. The speedup
(sequential_time/multi_threaded_time) versus number of cores for
Multicore (Concurrent Minor Collector), Parmap and Parany is quite
significant and illustrated in the graph:
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/2/20dc869a8dda1c815714a97e6a84f6f81c914cf4.png>
• [ocaml-bench/sandmark#103] Add depend target in Makefile
Sandmark now includes a `depend` target defined in the Makefile to
check that both `libgmp-dev` and `libdw-dev` packages are installed
and available on Ubuntu.
• [ocaml-bench/sandmark#90] More parallel benchmarks
An issue has been created to add more parallel benchmarks. We will
use this to keep track of the requests. Please feel free to add your
wish list of benchmarks!
[Sandmark] <https://github.com/ocaml-bench/sandmark>
[ocaml-bench/sandmark#88]
<https://github.com/ocaml-bench/sandmark/pull/88>
[ocaml-bench/sandmark#98]
<https://github.com/ocaml-bench/sandmark/pull/98>
[ocaml-bench/sandmark#100]
<https://github.com/ocaml-bench/sandmark/issues/100>
[ocaml-bench/sandmark#99]
<https://github.com/ocaml-bench/sandmark/issues/99>
[ocaml-bench/sandmark#103]
<https://github.com/ocaml-bench/sandmark/pull/103>
[ocaml-bench/sandmark#90]
<https://github.com/ocaml-bench/sandmark/issues/90>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
The configure script has now been be updated so that it can build on
Windows. Apart from this major change, a number of minor commits
have been made for the build and sanity checks. This PR is currently
under review.
• [ocaml/ocaml#9353] Reimplement output_value using a hash table to
detect sharing.
The [ocaml/ocaml#9293] "Use addrmap hash table for marshaling" PR
has been re-implemented using a hash table and bit vector, thanks to
@xavierleroy. This is a pre-requisite for Multicore OCaml that uses
a concurrent garbage collector.
As always, we thank the OCaml developers and users in the community
for their code reviews, support, and contribution to the project. From
OCaml Labs, stay safe and healthy out there!
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
[ocaml/ocaml#9353] <https://github.com/ocaml/ocaml/pull/9353>
[ocaml/ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 43742 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-24 9:31 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-03-24 9:31 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 13108 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 17 to 24,
2020.
Table of Contents
─────────────────
Luv 0.5.1 — a libuv binding — Windows support
resto 0.2 released
Bisect_ppx 2.0.0 — code coverage for OCaml with nice HTML reports
OCaml 4.09.1 released
Cookie 0.1.6
First release of lwt-pipeline
Using Ocaml as scripting language - piping sh commands
Old CWN
Luv 0.5.1 — a libuv binding — Windows support
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/luv-0-5-1-a-libuv-binding-windows-support/5334/1>
Anton Bachin announced
──────────────────────
I am pleased to announce release [0.5.1] of [**Luv**]. The main change
is the addition of Windows support, which makes Luv fully
cross-platform.
Accordingly, Luv 0.5.1 is now installable from both the main opam
repo, and from opam-repository-mingw.
<https://github.com/aantron/luv>
Also, as a side effect of the build system refactoring that was needed
to support Windows, Luv's build system no longer requires Python, and
supports cross-compilation.
The other noteworthy change in release 0.5.1 is a routine upgrade of
the vendored libuv to its latest version, [1.35.0].
[0.5.1] <https://github.com/aantron/luv/releases/tag/0.5.1>
[**Luv**] <https://github.com/aantron/luv>
[1.35.0] <https://github.com/libuv/libuv/releases/tag/v1.35.0>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/2>
Raphaël Proust announced
────────────────────────
Releases of `resto' 0.3 and 0.4
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
On behalf of Nomadic Labs, I'm happy to announce the release of
versions 0.3 and 0.4 of `resto'. Both versions are available through
`opam' and available on <https://gitlab.com/nomadic-labs/resto>.
The main change in 0.3 is to depend on `json-data-encoding', the fork
of the unmaintained `ocplib-json-typed'.
The changes of 0.4 are more invasive and require users changes:
• handle the new ``Gone' response code, and
• pass `gettimeofday' manually.
This last feature removes a dependency from `resto-cohttp' to `Unix',
and thus helps with use within a `js_of_ocaml' environment.
Bisect_ppx 2.0.0 — code coverage for OCaml with nice HTML reports
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bisect-ppx-2-0-0-code-coverage-for-ocaml-with-nice-html-reports/5338/1>
Anton Bachin announced
──────────────────────
I am pleased to announce [release 2.0.0] of [**Bisect_ppx**], the
OCaml coverage tool, which helps you see which parts of your code are
not being tested.
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>
This release is a major upgrade. The highlights are:
• Support for BuckleScript, js_of_ocaml, and esy. In other words,
Bisect_ppx now compiles to both native code and JS, and is published
in both opam and npm.
• The ability to [send reports automatically] from Travis and CircleCI
to Coveralls and Codecov. More integrations can be added over time.
• The awkward `(*BISECT-IGNORE*)' comments for excluding code from
instrumentation have been replaced by AST attributes like
`[@coverage off]'
(<https://github.com/aantron/bisect_ppx#Exclusion>).
• A new, more principled instrumentation algorithm.
• A new reporter command line based on [Cmdliner]. Run
`bisect-ppx-report --help' to get started with it.
• Syntax highlighting.
You are invited to peruse the all-new [README] for details :)
Several features have been deprecated; mostly command-line flags. You
can see the list in the *Deprecations* section of the
[changelog]. However, it may be easier to simply try using Bisect_ppx
as before – it will warn you if you use a deprecated flag. The
deprecated flags will be removed in Bisect_ppx 2.1.0, expected around
July 2020.
Happy testing!
<https://github.com/aantron/bisect_ppx>
[release 2.0.0]
<https://github.com/aantron/bisect_ppx/releases/tag/2.0.0>
[**Bisect_ppx**] <https://github.com/aantron/bisect_ppx>
[send reports automatically]
<https://github.com/aantron/bisect_ppx#Coveralls>
[Cmdliner] <https://erratique.ch/software/cmdliner/doc/Cmdliner>
[README] <https://github.com/aantron/bisect_ppx#readme>
[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.0.0>
OCaml 4.09.1 released
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-09-1-released/5341/1>
octachron announced
───────────────────
We have the pleasure of celebrating the anniversary of the first
spacewalk, conducted by Alexei Leonov, by announcing the release of
OCaml version 4.09.1. This is mainly a bug-fix release, with a
handful of configuration fixes and a GC fix backported from 4.10.0
. See the list of changes below for more details.
It is (or soon will be) available as a set of OPAM switches, and as a
source download here:
<https://github.com/ocaml/ocaml/archive/4.09.1.tar.gz>
Changes in 4.09.1:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• [#9073], [#9120]: fix incorrect GC ratio multiplier when allocating
custom blocks with caml_alloc_custom_mem in runtime/custom.c (Markus
Mottl, review by Gabriel Scherer and Damien Doligez)
• [#8855], [#8858]: Links for tools not created when installing with
–disable-installing-byecode-programs (e.g. ocamldep.opt installed,
but ocamldep link not created) (David Allsopp, report by Thomas
Leonard)
• [#8947], [#9134], [#9302]: fix/improve support for the BFD library
(Sébastien Hinderer, review by Damien Doligez and David Allsopp)
• [#8953], [#8954]: Fix error submessages in the toplevel: do not
display dummy locations (Armaël Guéneau, review by Gabriel Scherer)
• [#8965], [#8979]: Alpine build failure caused by
check-parser-uptodate-or-warn.sh (Gabriel Scherer and David Allsopp,
report by Anton Kochkov)
• [#8985], [#8986]: fix generation of the primitives when the locale
collation is incompatible with C. (David Allsopp, review by Nicolás
Ojeda Bär, report by Sebastian Rasmussen)
• [#9050], [#9076]: install missing compilerlibs/ocamlmiddleend
archives (Gabriel Scherer, review by Florian Angeletti, report by
Olaf Hering)
• [#9144], [#9180]: multiple definitions of global variables in the C
runtime, causing problems with GCC 10.0 and possibly with other C
compilers (Xavier Leroy, report by Jürgen Reuter, review by Mark
Shinwell)
• [#9180]: pass -fno-common option to C compiler when available, so as
to detect problematic multiple definitions of global variables in
the C runtime (Xavier Leroy, review by Mark Shinwell)
• [#9128]: Fix a bug in bytecode mode which could lead to a
segmentation fault. The bug was caused by the fact that the atom
table shared a page with some bytecode. The fix makes sure both the
atom table and the minor heap have their own pages. (Jacques-Henri
Jourdan, review by Stephen Dolan, Xavier Leroy and Gabriel Scherer)
[#9073] <https://github.com/ocaml/ocaml/issues/9073>
[#9120] <https://github.com/ocaml/ocaml/issues/9120>
[#8855] <https://github.com/ocaml/ocaml/issues/8855>
[#8858] <https://github.com/ocaml/ocaml/issues/8858>
[#8947] <https://github.com/ocaml/ocaml/issues/8947>
[#9134] <https://github.com/ocaml/ocaml/issues/9134>
[#9302] <https://github.com/ocaml/ocaml/issues/9302>
[#8953] <https://github.com/ocaml/ocaml/issues/8953>
[#8954] <https://github.com/ocaml/ocaml/issues/8954>
[#8965] <https://github.com/ocaml/ocaml/issues/8965>
[#8979] <https://github.com/ocaml/ocaml/issues/8979>
[#8985] <https://github.com/ocaml/ocaml/issues/8985>
[#8986] <https://github.com/ocaml/ocaml/issues/8986>
[#9050] <https://github.com/ocaml/ocaml/issues/9050>
[#9076] <https://github.com/ocaml/ocaml/issues/9076>
[#9144] <https://github.com/ocaml/ocaml/issues/9144>
[#9180] <https://github.com/ocaml/ocaml/issues/9180>
[#9128] <https://github.com/ocaml/ocaml/issues/9128>
Cookie 0.1.6
════════════
Archive: <https://discuss.ocaml.org/t/ann-cookie-0-1-6/5346/1>
Ulrik Strid announced
─────────────────────
I recently released a cookie library. It can parse and create cookie
headers (`list((string, string)' which both Cohttp and Httpaf uses),
both `Set-Cookie' and `Cookie' so it works on both client and
server. It should be compliant with
<https://tools.ietf.org/html/rfc6265> and I have a pretty good test
suite for the parsing of cookies at least.
I couldn’t find a standalone library before this so I decided to
create one since I need it for my web framework, `Morph'.
The next step is to create and publish integrations with
[`ocaml-session'] which I have started.
• Repo: <https://github.com/ulrikstrid/ocaml-cookie>
• Docs: <https://ulrikstrid.github.io/ocaml-cookie>
[`ocaml-session'] <https://github.com/inhabitedtype/ocaml-session>
First release of lwt-pipeline
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-lwt-pipeline/4220/2>
Raphaël Proust announced
────────────────────────
A second release of `lwt-pipeline' (v0.2) is available through
`opam'. This new release makes no change to the code and only affects
the following:
• looser constraints on versions of `dune' dependency,
• tests,
• tests are executed in CI,
• minor documentation improvements.
Using Ocaml as scripting language - piping sh commands
══════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/using-ocaml-as-scripting-language-piping-sh-commands/5366/1>
Nicolas Tollenaere announced
────────────────────────────
I am trying to use ocaml to pipe the result of a command to another (I
would also be interested in feeding a string or a io stream into a sh
command). For example, I would like to do the equivalent of cat
foo.txt | grep thing, or pipe the result of one of my ocaml function
into grep.
Quite surprinsingly, neither the Stdlib or Batteries Sys modules
expose any way to handle the output of Sys.command directly (I would
have thought there would be optional input and output arguments
defaulting to stdin and stdout, or something along that). Batteries IO
module does expose a pipe function but it's not clear for me how it
would interact with the Sys module. Any ideas or other modules/package
I could use ?
Nicolás Ojeda Bär suggested
───────────────────────────
I think you may be interested by
<https://github.com/janestreet/shexp>.
Nicolas Tollenaere then said
────────────────────────────
@grayswandyr @nojb Thanks for the suggestion. I just found shcaml
<http://tov.github.io/shcaml/doc/> and I was going to give it a try,
do you know how it compares to shexp ?
David Chemouil replied
──────────────────────
AFAIK shcaml is unmaintained, but the approach is very nice indeed.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26314 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-17 11:04 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-03-17 11:04 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12110 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 10 to 17,
2020.
Table of Contents
─────────────────
Unicode 13.0.0 update for Uucd, Uucp, Uunf and Uuseg
Introducing dune describe
Introducing Model_quickcheck. Quickcheck for stateful, imperative code
Odig 0.0.5
Suggestions for ocaml documentation
Introducing Gopcaml mode - structural OCaml editing
Try OCaml 2.0 (beta)
jose 0.2.0
Old CWN
Unicode 13.0.0 update for Uucd, Uucp, Uunf and Uuseg
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/unicode-13-0-0-update-for-uucd-uucp-uunf-and-uuseg/5298/1>
Daniel Bünzli announced
───────────────────────
Unicode 13.0.0 was released on the 10th of march.
It adds 5390 characters to the standard including graphic symbols for
legacy computing. If you were looking for characters representing
seven-segment decimal digits, now you [have them]. For the curious,
the [encoding proposal] has the motivation and source of these new
symbols. For more information about all the other additions, see [this
page].
Accordingly the libraries mentioned at the end of this message had to
be updated, consult the individual release notes for details. Both
Uucd and Uucp are incompatible releases sinces new script and block
enumerants had to be added.
Uucp has a new Emoji module with the new emoji properties introduced
in 13.0.0 which are now used by Uuseg to improve emoji
segmentation. The overall compiled size of Uucp shrinked a bit; here
uucp.cmxs went from 7.8Mo to 4.6Mo. Further reduction can likely be
achieved with more work. Thanks to David Kaloper Meršinjak for helping
on this.
A periodic reminder, if Unicode still puzzles you, read an absolute
minimal Unicode introduction and OCaml Unicode tips on [this page]
(also available via `odig doc uucp').
Happy retro computing,
Daniel
P.S. The OCaml compiler [detected] an obsolete rule in the 13.0.0
update of the Unicode line breaking algorithm.
—
Uucd 13.0.0 Unicode character database decoder for OCaml.
<http://erratique.ch/software/uucd>
Uucp 13.0.0 Unicode character properties for OCaml.
<http://erratique.ch/software/uucp>
Uunf 13.0.0 Unicode text normalization for OCaml.
<http://erratique.ch/software/uunf>
Uuseg 13.0.0 Unicode text segmentation for OCaml.
<http://erratique.ch/software/uuseg>
[have them] <https://www.unicode.org/charts/PDF/U1FB00.pdf>
[encoding proposal]
<https://www.unicode.org/L2/L2019/19025-terminals-prop.pdf>
[this page]
<http://blog.unicode.org/2020/03/announcing-unicode-standard-version-130.html>
[this page] <https://erratique.ch/software/uucp/doc/unicode.html>
[detected]
<https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.html>
Introducing dune describe
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-dune-describe/5300/1>
Jérémie Dimino announced
────────────────────────
Just a quick post to introduce the new `dune describe' command in Dune
2.4.0. If you'd like to write a tool that needs to understand the
structure of a dune project, figure out where the cmt files are
located, etc…, this is the command to look at.
The command is not production ready yet, but the infrastructure is in
place. If you are interested in releasing tools that rely on it,
please let us know so that we can discuss what information you need
out of dune and also so that we can stabilise it.
<https://dune.build/blog/dune-describe/>
Introducing Model_quickcheck. Quickcheck for stateful, imperative code
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-model-quickcheck-quickcheck-for-stateful-imperative-code/5301/1>
suttonshire announced
─────────────────────
I'm sharing a small project I've been working on that I hope will be
interesting or useful to the community. [Model_quickcheck] is a
model-based testing system that allows you to validate the
"properties" of stateful, imperative OCaml programs. It's built on
Jane Street's Base_quickcheck.
I just started learning OCaml and one of the first projects I've been
working on is a user-space reliable transport protocol. Writing tests
for this system became unwieldy because I was trying to validate
certain properties of the protocol by thinking up very specific
sequences of actions that would invoke behaviors that relied on that
property. I got tired of it and got curious if there was a way to
generate these interesting sequences. My research turned up frameworks
like [QCSTM] and [PropEr] for state machine property-based
testing. This seemed to be exactly what I needed so I started building
something similar.
To use Model_quickcheck you specify a set of actions to apply to your
program, a model that describes the state of you program and a set of
predicates that define the properties of you system. The model is
hopefully a simpler representation of your system e.g. a map instead
of a key-value database, or a queue instead of a reliable network
protocol. Model_quickcheck then generates a random sequences of
actions applies them to your system and verifies the properties.
This has been an exciting and useful project. I've learned a bunch
about the Base library, Quickcheck, first class modules, and inline
tests. I'm just getting started, but I just wanted to share the
project with the community since I've learned a lot by lurking here.
[Model_quickcheck] <https://github.com/suttonshire/model_quickcheck>
[QCSTM] <https://github.com/jmid/qcstm>
[PropEr] <https://propertesting.com/book_state_machine_properties.html>
Odig 0.0.5
══════════
Archive: <https://discuss.ocaml.org/t/ann-odig-0-0-5/5304/1>
Daniel Bünzli announced
───────────────────────
`odig' has a new release. See the [release notes] for details.
Installation: `opam install ocaml-manual odig'
Tutorial: <https://erratique.ch/software/odig/doc/manual.html>
odig is a command line tool to lookup documentation of installed OCaml
packages. It shows package metadata, readmes, change logs, licenses,
cross-referenced `odoc' API documentation and manuals.
[release notes]
<https://github.com/b0-system/odig/blob/v0.0.5/CHANGES.md#v005-2019-03-11-la-forclaz-vs>
Suggestions for ocaml documentation
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504/50>
sanette announced
─────────────────
The "OCaml API", which is the documentation for the standard library,
is now complete for all versions 4.00–4.10, with a quick search field,
on the demo site:
<https://sanette.github.io/ocaml-api/>
Introducing Gopcaml mode - structural OCaml editing
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310/1>
Kiran Gopinathan announced
──────────────────────────
Hi all, I am pleased to announce the first release of Gopcaml-mode, a
new emacs library that aims to extend the existing OCaml editing
experience with structural editing capabilities.
A picture is worth a thousand words, so I'll cut to the chase, and
start with a few demonstrations:
Examples
╌╌╌╌╌╌╌╌
• AST-based code navigation - `C-M-n, C-M-p, C-M-u, C-M-d, C-M-f,
C-M-b'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_move_expression_example.gif>
• AST-based code transformation -`C-M-N, C-M-P, C-M-F, C-M-B'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_move_function_example.gif>
• Mark exp - `C-M-SPC'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_mark_sexp.gif>
• Extract expression into letdef - `C-c C-e'
<https://gitlab.com/gopiandcode/gopcaml-mode/-/raw/master/images/gopcaml_extraction_expressions.gif>
This is just a small sample of the features - a full listing is
provided at the project readme, which can be found at the [project
page].
[project page] <https://gitlab.com/gopiandcode/gopcaml-mode>
Notes
╌╌╌╌╌
This plugin is quite faithful to the OCaml specification and doesn't
reimplement a separate OCaml parser as some other plugins do - instead
I use the Ecaml package (which allows interfacing with Emacs from
OCaml code) to allow delegating to the OCaml parser (from
Ocaml-compiler-libs) directly.
It's in the process of being published to opam, and should be
available to download soon.
Try OCaml 2.0 (beta)
════════════════════
Archive: <https://discuss.ocaml.org/t/ann-try-ocaml-2-0-beta/5325/1>
Louis Gesbert announced
───────────────────────
OCamlPro is happy to announce the release of a new version of the
venerable [Try OCaml tool].
This tool allows you to quickly test OCaml snippets from anywhere,
directly from your browser. It's still in beta, so any issues or
comments are welcome below.
The new version is a complete refactor and redesign, based on the
backend of Learn-OCaml.
Original announcement:
<http://www.ocamlpro.com/2020/03/16/new-version-of-try-ocaml-in-beta/>
[Try OCaml tool] <https://try.ocamlpro.com>
jose 0.2.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-jose-0-2-0/5328/1>
Ulrik Strid announced
─────────────────────
I recently released a JavaScript Object Signing and Encryption library
to opam.
The main usecase for JOSE is JWT and JWK and is a comprehensive
library for both unlike some other libraries that currently exist in
the ecosystem. It uses mirage-crypto and supports RSA and OCT keys
currently and will support EC when mirage-crypto does.
I have not really implemented the encryption part yet but if anyone
needs JWE I'll gladly do the work or accept PRs.
The project was initially developed in Reason but I changed over to
OCaml at some point because of limitations in Reason at the time but
the repo still has the old name.
The docs can be found here:
<https://ulrikstrid.github.io/reason-jose/>
The repo can be found here:
<https://github.com/ulrikstrid/reason-jose/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 25657 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-10 14:28 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-03-10 14:28 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 23566 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of March 03 to 10,
2020.
Table of Contents
─────────────────
Non opam workflows
First release of metapp
OCaml 4.10 released
Transept 0.1.0: Generalised Parser Combinators
Multicore OCaml: Feb 2020 update
owl 0.8.0 and 0.9.0 released
Parser combinators vs. parser preprocessors?
Dune 2.4.0
Tyxml 4.4.0
first release of oplsr: an OCaml wrapper to the pls R package - Partial Least Squares (PLS) regression
Old CWN
Non opam workflows
══════════════════
Archive: <https://discuss.ocaml.org/t/non-opam-workflows/5232/1>
Manas asked
───────────
Very recently, I learnt that there is a significant chunk of users in
the OCaml community that does not use opam to install packages. As a
small initiative to contribute to tooling, I want to ensure what I
build is compatible with these workflows - workflows I'm not familiar
with myself.
I'd love to learn more - what does it look like? How do you setup your
compiler, dune and merlin (and/or soon ocamllsp)? How do you configure
your editor to find them and what would make it easier to do so?
I'm told of Duniverse as one tool that being used in these non-opam
workflows. Are there any more popular ones out there?
Théo Zimmermann replied
───────────────────────
I am one of these people. I mostly rely on Nix, whose package
repository nixpkgs provides package sets for all (relatively recent)
versions of OCaml. These package sets are not generally as complete as
what you can find on opam, so it sometimes happens that I open a PR on
the nixpkgs repository to add a new package (and in the meantime I use
my local updated copy of the nixpkgs repo).
You can see the list of available OCaml packages at:
<https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=ocamlPackages>
(This is for the default OCaml version, currently 4.07 in
nixpkgs-unstable. Other package sets are called
`ocaml-ng.ocamlPackages_4_0X' but are not shown in this web search.)
Most OCaml packages are available at a single version in nixpkgs (even
though you can choose your version of OCaml). To gain more flexibility
on the exact version I use in one of my project, I am planning to test
Duniverse. At that point, I would rely on Duniverse for library
dependencies, but I would still rely on Nix to install OCaml, findlib,
Dune, Duniverse (I'll have to take care of packaging it), utop,
merlin, or ocamlformat.
Nix is pretty straightforward to use. You generally provide a
`default.nix' at the root of your repository, and it will list the
dependencies that you use. When you want to go develop your project,
you just enter a special shell (with the `nix-shell' command) and you
are in an environment where the tools you need are in `PATH' and the
libraries you need are in `OCAMLPATH'.
There's just one tool that I needed special configuration for:
`ocamlformat' (especially because some projects use it and some do
not). When I use it, my `default.nix' contains:
┌────
│ shellHook = ''
│ export OCAMLFORMAT_LOCATION=${ocamlformat}
│ '';
└────
which will export an environment variable when I enter the shell.
And my `.emacs' contains:
┌────
│ (setq ocamlformat-location (getenv "OCAMLFORMAT_LOCATION"))
│ (when (> (length ocamlformat-location) 0)
│ (add-to-list 'load-path (concat ocamlformat-location "/share/emacs/site-lisp"))
│ (require 'ocamlformat)
│ (add-hook 'tuareg-mode-hook
│ (lambda () (add-hook 'before-save-hook 'ocamlformat-before-save))))
└────
I want to ensure what I build is compatible with these
workflows
If you mean as a library author, then all you have to ensure is that
you use Dune as the build system (makes the Duniverse workflow better,
and makes it easier to package your library in nixpkgs,
cf. `buildDunePackage' documented at
<https://nixos.org/nixpkgs/manual/#sec-language-ocaml>).
Rwmjones also replied
─────────────────────
You might want to check out the Fedora OCaml packages.
Unfortunately I don't have a convenient way to link to the whole list,
but if you look at all the OCaml packages here:
<https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=ocaml>*
and then if you substitute the `ocaml-<packagename>' in two places in
this URL:
<https://src.fedoraproject.org/rpms/ocaml-re/blob/master/f/ocaml-re.spec>
(example showing `ocaml-re' package), you can see how we build and
package them in the `%prep', `%build' and `%install' sections.
And yes, please make sure your software doesn't depend on opam.
Building everything in your home directory is not suitable for
enterprise software distribution.
First release of metapp
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-metapp/5250/1>
Thierry Martinez announced
──────────────────────────
I am happy to announce the first release of `metapp', yet another
preprocessor for OCaml. Similarly to [`ppx_optcomp'], `metapp' is a
PPX rewriter. But instead of introducing a specific DSL for
preprocessor directives, `metapp' provides a `[%meta ...]' extension,
where the dots `...' are arbitrary OCaml expressions that are
substituted at compile-time by the AST nodes they evaluate into. These
expressions build AST nodes either by (anti-)quoting some code
directly, or by using `compiler-libs' ([`Parsetree'], [`Ast_helper'],
…).
In particular, this preprocessor is easy to use for conditional
compilation, and is an alternative to [`cppo'] and [`ppx_optcomp'].
┌────
│ let option_get o =
│ [%meta if Sys.ocaml_version >= "4.08.0" then
│ [%e Option.get o]
│ else
│ [%e match o with
│ | None -> invalid_arg "option_get"
│ | Some x -> x]]
└────
In this example, the code between `[%e ... ]' is "anti-quoted": it is
the code that is inserted (conditionally) in the rewritten module. Of
course, the anti-quoted code can contain itself some `[%meta ...]'
code. `[%meta ...]' can even itself contain other levels of `[%meta
...]' code for multi-stage programming.
An example of usage of `metapp' is the [`metaquot'] package, which
implements the same quoters as `ppx_tools.metaquot': `[%expr ...]',
`[%type: ...]', etc. These quoters are implemented by
meta-programming: the meta-code introspects `Parsetree.cmi' from
`compiler-libs' to generate the code matching the current OCaml
version.
[`ppx_optcomp'] <https://github.com/janestreet/ppx_optcomp>
[`Parsetree']
<https://caml.inria.fr/pub/docs/manual-ocaml/compilerlibref/Parsetree.html>
[`Ast_helper']
<https://caml.inria.fr/pub/docs/manual-ocaml/compilerlibref/Ast_helper.html>
[`cppo'] <https://github.com/ocaml-community/cppo>
[`metaquot'] <https://github.com/thierry-martinez/metaquot>
Raphaël Proust added
────────────────────
To potentially save a few second to the next readers:
<https://github.com/thierry-martinez/metapp> seems to be the repo
where it is hosted.
Thierry Martinez then said
──────────────────────────
Thanks, @raphael-proust! The package is also available via opam: `opam
install metapp' (and `metaquot' is available via opam as well).
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/5>
octachron continued this thread
───────────────────────────────
The Merlin team has just released a preview version of Merlin which is
compatible with 4.10.0 (Merlin is an editor service that provides
modern IDE features for OCaml) .
This is a preview version:
• the support for short-path is disabled
• only OCaml 4.10.0 is supported in this preview
It can be installed via opam with the usual
┌────
│ opam install merlin
└────
Transept 0.1.0: Generalised Parser Combinators
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-transept-0-1-0-generalised-parser-combinators/5262/1>
Didier Plaindoux announced
──────────────────────────
I’m happy to announce the first release of Transept an OCaml
implementation of generalized parsers combinators.
This implementation has been inspired by a 19 years old paper -
written by Daan Leijen and Erik Meijer - titled “Parsec: Direct Style
Monadic Parser Combinators For The Real World” [1]. The current
implementation provides basic combinators dedicated to char, chars
recognition but also conjunction, sequence, repetition and more. Since
the current design relies on the abstract definition of manipulated
element most of the parsers are generic and can be used with streams
of chars or something else.
Finally, with this library, I wanted to share my love of OCaml modules
🤗
Opam: <https://opam.ocaml.org/packages/transept/transept.0.1.0/>
[1]
<https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/parsec-paper-letter.pdf>
Didier Wenzek then said
───────────────────────
It good to see yet another parser combinator for OCaml, even if this
makes more difficult the choice of one of them. I believe this
highlights how well OCaml shines for this kind of applications where
both high-level expressiveness and performance matter.
[`angstrom'] is one the alternatives and provides a comparison with
others. It would be good to position `transept' here.
There is also a more recent article with a radically new approach: [A
Typed, Algebraic Approach to Parsing] by Neelakantan R. Krishnaswami
and Jeremy Yallop - PLDI 2019. This paper proposes a [library of
parser combinators] for context-free expressions, an algebraic
presentation of the context-free languages. The key points are
• the use of types to statically reject any language which cannot be
parsed unambiguously and linearly;
• the use of staging, with OcamlBER, to produce parsers which
performance are close to those of hand-written code.
[`angstrom'] <https://github.com/inhabitedtype/angstrom>
[A Typed, Algebraic Approach to Parsing]
<https://www.cl.cam.ac.uk/~nk480/parsing.pdf>
[library of parser combinators] <https://github.com/yallop/ocaml-asp/>
Multicore OCaml: Feb 2020 update
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227/3>
Continuing this thread, Rwmjones asked
──────────────────────────────────────
Hi Anil (or anyone!). Is there a place I can find more about breaking
changes that might be made to C extensions? As you may know we have a
lot of C code which interfaces with OCaml, both as ordinary extensions
written in C, but also embedding OCaml in C programs (although that's
much more rare), and I'd like a heads up about what's likely to
change.
Anil Madhavapeddy replied
─────────────────────────
Hi @rwmjones! In a nutshell: no breaking C changes. The longer version
is that we implemented two different minor collectors in order to
evaluate various tradeoffs systematically:
• a concurrent minor collector that requires a read barrier and some C
API changes in order to create more safe points
• a stop-the-world minor collector that doesn't require a read barrier
and no extra C API changes, but would probably cause longer pauses
The good news is that our STW collector scales up much better than we
expected (tested to 24 cores), and so our first domains patchset will
almost certainly use that version now. We expect to shift to a
concurrent (and possibly pauseless) collection algorithm at some
future point, but in terms of upstreaming it looks like we should be
able to delay any C API changes until after the first version of
multicore has landed.
Do you have any nice standalone candidate programs using the C FFI we
could add to Sandmark?
owl 0.8.0 and 0.9.0 released
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-owl-0-8-0-and-0-9-0-released/5281/1>
Marcello Seri announced
───────────────────────
We are happy to announce *two* new releases of `owl': a dedicated
system for scientific and engineering computing in OCaml.
Since our previous announcement in July last year, there has been an
[enormous amount of work] going on to cleanup and extend owl's
internals and its interfaces.
In this period we have been trying to release often and keep
disruption to a minimum. Owl 0.8.0 and 0.9.0 are exceptional in this
respect:
• `owl.0.8.0':
• the discrepancy between `owl-base' (pure ocaml) and `owl' (links
cblas/lapacke) interfaces started becoming a problem in few
places. In this release many interfaces have been unified and
reused. The algodiff module has undergone a similar
refactoring. Although most users should be shielded from these
changes, they may break existing code, requiring an upper bound on
owl and some localized updates. This should mostly boil down to
changes like
┌────
│ -module CGraph_D = Owl_computation_engine.Make_Graph (Owl_computation_cpu_device.Make (Dense.Ndarray.D))
│ +module CGraph_D = Owl_computation_engine.Make_Graph (Owl_computation_cpu_device.Make (Owl_algodiff_primal_ops.D))
└────
• this is the last edition supporting OCaml compiler versions <
4.10.0 (more on this later).
• `owl.0.9.0': the main difference between `0.8.0' and `0.9.0' is that
owl now requires OCaml 4.10.0. This release of OCaml introduces
*extended indexing operators*. With them we can now write things
like `x.%{0;3}' (for indexing) and `x.${[0:2];[2;4]}' (for slicing)
instead of the more cumbersome `x.%{[|0;3|]}' and
`x.${[[0:2];[2;4]]}'.
The project is thoroughly documented at [ocaml.xyz ] where you can
find multiple examples of use.
A lot of work has (and is) been going into improving the
documentation, you can find the results in the new [owl book]:
<https://ocaml.xyz/book/toc.html>. This is currently targeting the
development version of owl, so using `master' or `0.9.0' is the best
bet if you want to try the examples out.
One of the issue of the old documentation was that it was getting
stale very fast: the book is reusing some of the infrastructure of
RWO, so all examples get recompiled and retested continuously to
ensure their correctness.
As a final note, we would like to send a huge thank to the [OCaml
Software Foundation], see also the [announcement made on this forum],
which has given us some funding that will support a retreat of the
maintainers and a development sprint that will take place at the end
of March.
We meant to announce the retreat and sprint for some time now, but the
size and publicity of the event may depend on updates to the various
governmental and institutional recommendation in regards to COVID-19
spreading. If a public event will be possible, we will make a
separate announce on this forum.
We want to also thank all the contributors for the increasing number
of comments, fixes and discussions that are helping us shape the next
releases of owl.
The Owl Dev Team
[enormous amount of work]
<https://github.com/owlbarn/owl/blob/master/CHANGES.md>
[ocaml.xyz ] <http://ocaml.xyz>
[owl book] <https://ocaml.xyz/book/toc.html>
[OCaml Software Foundation] <http://ocaml-sf.org/>
[announcement made on this forum]
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476>
Parser combinators vs. parser preprocessors?
════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/parser-combinators-vs-parser-preprocessors/5263/4>
Continuing this thread, yallop said
───────────────────────────────────
Gasche said:
Combinators also describe a grammar; they can build a
representation that is then processed. I think it would be
perfectly reasonable to provide combinators to describe a
L(AL)R grammar, and then a function from such a grammar to
a parsing automaton, along with the result of various
analyses. This would solve the “additional tooling”
problem of typical parser generators, and also the “lack
of conflict analysis” problem of typical parser combinator
libraries. But it may require support for staging for
performance reasons.
Readers of this thread may be interested in the [asp] (*algebraic
staged parsing*) library (also described in the [Transept post] linked
above), which is built on an approach along the lines @gasche
describes:
• combinators that describe a grammar (using context-free expressions)
• an analysis (formulated as a type system) that ensures deterministic
parsing
• staging to eliminate performance overhead
The interface is pretty standard, with combinators for alternation,
sequencing, etc., and performance is quite good (better than
`ocamlyacc' on our benchmarks).
There's a paper, [A typed algebraic approach to parsing], that
describes the design in more detail.
Chet_Murthy said:
Also, I’m personally a massive LL(1) (over LALR) bigot
Grammars built using `asp' are essentially LL(1). (The weasel word
"essentially" isn't hiding much here, but the paper has the details.)
[asp] <https://github.com/yallop/ocaml-asp/>
[Transept post]
<https://discuss.ocaml.org/t/ann-transept-0-1-0-generalised-parser-combinators/5262>
[A typed algebraic approach to parsing]
<https://www.cl.cam.ac.uk/~jdy22/papers/a-typed-algebraic-approach-to-parsing.pdf>
Dune 2.4.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-4-0/5288/1>
Rudi Grinberg announced
───────────────────────
On behalf of the dune team, I'm pleased to announce the release of
dune 2.4.0. This releases features support for [mdx], an interesting
take on the notebook paradigm by the RWO team. This release also
includes a crucial fix to polling mode which makes it usable in
environments with finite memory :slight_smile:.
Happy hacking!
[mdx] <https://github.com/realworldocaml/mdx>
2.4.0 (06/03/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Add `mdx' extension and stanza version 0.1 (#3094, @NathanReb)
• Allow to make Odoc warnings fatal. This is configured from the `(env
...)' stanza. (#3029, @Julow)
• Fix separate compilation of JS when findlib is not
installed. (#3177, @nojb)
• Add a `dune describe' command to obtain the topology of a dune
workspace, for projects such as ROTOR. (#3128, @diml)
• Add `plugin' linking mode for executables and the
`(embed_in_plugin_libraries ...)' field. (#3141, @nojb)
• Add an `%{ext_plugin}' variable (#3141, @nojb)
• Dune will no longer build shared objects for stubs if
`supports_shared_libraries' is false (#3225, fixes #3222,
@rgrinberg)
• Fix a memory leak in the file-watching mode (`dune build -w')
(#3220, @snowleopard and @aalekseyev)
Tyxml 4.4.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-tyxml-4-4-0/5290/1>
Gabriel Radanne announced
─────────────────────────
I have the pleasure to announce the release of [TyXML 4.4.0], with
special Reason support!
[TyXML] is a library for building statically correct HTML and SVG
documents. TyXML provides a set of combinators which use the OCaml
type system to ensure the validity of the HTML. TyXML is now a stable
library and this release comes with a few newly supported elements and
attributes (such as ARIA elements) and associated bug fixes. However,
the main novelty of this release is a long awaited feature: the
support for [Reason’s JSX syntax] in the brand new `tyxml-jsx'
package.
See the complete announcement for code examples and details:
<https://drup.github.io/2020/03/06/tyxml440/>
[TyXML 4.4.0] <https://github.com/ocsigen/tyxml/releases/tag/4.4.0>
[TyXML] <https://github.com/ocsigen/tyxml>
[Reason’s JSX syntax] <https://reasonml.github.io/docs/en/jsx.html>
first release of oplsr: an OCaml wrapper to the pls R package - Partial Least Squares (PLS) regression
══════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-oplsr-an-ocaml-wrapper-to-the-pls-r-package-partial-least-squares-pls-regression/5293/1>
UnixJunkie announced
────────────────────
It is my great pleasure to release one more hackish wrapper to use
some R package from within OCaml:
<https://github.com/UnixJunkie/oplsr>
For some background:
<https://en.wikipedia.org/wiki/Partial_least_squares_regression>
Cf. test.ml in the sources for a usage example.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 39431 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-03-03 8:00 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-03-03 8:00 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 12736 bytes --]
Here is the latest OCaml Weekly News, for the week of February 25 to
March 03, 2020.
Table of Contents
─────────────────
OCaml 4.10 released
Summary of the Dune retreat 2020
Multicore OCaml: Feb 2020 update
Oplot 0.50
soupault: a static website generator based on HTML rewriting
Old CWN
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/4>
Contnuing this thread, Anil Madhavapeddy said
─────────────────────────────────────────────
Indeed, many thanks to everyone who leapt in to make 4.10 ready in
opam in such record time! Just a note that the CI Docker images are
now also rebuilt for x86_64, arm32/64 and ppc64le to reflect the 4.10
release, so feel free to start using
them. <https://hub.docker.com/r/ocaml/opam2/tags>
Summary of the Dune retreat 2020
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/summary-of-the-dune-retreat-2020/5224/1>
Jérémie Dimino announced
────────────────────────
We recently organised the second Dune retreat. If you'd like to see
what is happening in the Dune world at the moment, please find a
summary of what we discussed and work on in this blog post!
<https://dune.build/blog/dune-retreat-2020/>
Multicore OCaml: Feb 2020 update
════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the February 2020 news update from the Multicore OCaml
team, spread across the UK, India, France and Switzerland! This
follows on from [last month's] update, and has been put together by
@shakthimaan and @kayceesrk.
The [release of OCaml 4.10.0] has successfully pushed out some
prerequisite features into the upstream compiler. Our work in
February has focussed on getting the multicore OCaml branch "feature
complete" with respect to the complete OCaml language, and doing
extensive benchmarking and stress testing to test our two minor heap
implementations.
To this end, a number of significant patches have been merged into the
[Multicore OCaml trees] that essentially provide complete coverage of
the language features. We encourage you to test the same for
regressions and provide any improvements or report shortcomings to
us. There are ongoing OCaml PRs and issues that are also under review,
and we hope to complete those for the 4.11 release cycle. A new set of
parallel benchmarks have been added to our [Sandmark benchmarking
suite] (live instance [here]), including enhancements to the build
setup.
[last month's]
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090>
[release of OCaml 4.10.0]
<https://discuss.ocaml.org/t/ocaml-4-10-released/5194>
[Multicore OCaml trees]
<https://github.com/ocaml-multicore/ocaml-multicore>
[Sandmark benchmarking suite] <https://github.com/ocaml-bench/sandmark>
[here] <http://bench2.ocamllabs.io>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Completed
The following PRs have been merged into Multicore OCaml:
• [ocaml-multicore/ocaml-multicore#281] Introduce `Forcing_tag' to fix
concurrency bug with lazy values
A `Forcing_tag' is used to implement lazy values to handle a
concurrency bug. It behaves like a locked bit, and any concurrent
access by a mutator will raise an exception on that domain.
• [ocaml-multicore/ocaml-multicore#282] Safepoints
A preliminary version of safe points has been merged into the
Multicore OCaml trees. [ocaml-multicore/ocaml-multicore#187] also
contains more discussion and background about how coverage can be
improved in future PRs.
• [ocaml-multicore/ocaml-multicore#285] Introduce an 'opportunistic'
major collection slice
An "opportunistic work credit" is implemented in this PR which forms
a basis for doing mark and sweep work while waiting to synchronise
with other domains.
• [ocaml-multicore/ocaml-multicore#286] Do fflush and variable args in
caml_gc_log
The caml_gc_log() function has been updated to ensure that `fflush'
is invoked only when GC logging is enabled.
• [ocaml-multicore/ocaml-multicore#287] Increase EVENT_BUF_SIZE
During debugging with event trace data it is useful to reduce the
buffer flush times, and hence the `EVENT_BUF_SIZE' has now been
increased.
• [ocaml-multicore/ocaml-multicore#288] Write barrier optimization
This PR closes the regression for the `chameneos_redux_lwt'
benchmarking in Sandmark by using `intnat' to avoid sign extensions
and cleans up `write_barrier' to improve overall performance.
• [ocaml-multicore/ocaml-multicore#290] Unify sweep budget to be in
word size
The PR updates the sweep work units to all be in word size. This is
to handle the differences between the budget for setup, sweep and
for large allocations in blocks.
[ocaml-multicore/ocaml-multicore#281]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/281>
[ocaml-multicore/ocaml-multicore#282]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/282>
[ocaml-multicore/ocaml-multicore#187]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/187>
[ocaml-multicore/ocaml-multicore#285]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/285>
[ocaml-multicore/ocaml-multicore#286]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/286>
[ocaml-multicore/ocaml-multicore#287]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/287>
[ocaml-multicore/ocaml-multicore#288]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/288>
[ocaml-multicore/ocaml-multicore#290]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/290>
◊ Ongoing
• A lot of work is ongoing for the implementation of a synchronised
minor garbage collector for Multicore OCaml, including benchmarking
for the stop-the-world (stw) branch. We will publish the results of
this in a future update, as we are assembling a currently
comprehensive evaluation of the runtime against the mainstream
runtime.
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
[Sandmark] now has support to run parallel benchmarks. We can also now
about GC latency measurements for both stock OCaml and Multicore OCaml
compiler.
• [ocaml-bench/sandmark#73] More parallel benchmarks
A number of parallel benchmarks such as N-body, Quick Sort and
matrix multiplication have now been added to Sandmark!
• [ocaml-bench/sandmark#76] Promote packages. Unbreak CI.
The Continuous Integration build can now execute after updating and
promoting packages in Sandmark.
• [ocaml-bench/sandmark#78] Add support for collecting information
about GC pausetimes on trunk
The PR now helps process the runtime log and produces a `.bench'
file that captures the GC pause times. This works on both stock
OCaml and in Multicore OCaml.
• [ocaml-bench/sandmark#86] Read and write Irmin benchmark
A test for measuring Irmin's merge capabilities with Git as its
filesystem is being tested with different read and write rates.
• A number of other parallel benchmarks like Merge sort,
Floyd-Warshall matrix, prime number generation, parallel map, filter
et. al. have been added to Sandmark.
[Sandmark] <http://bench2.ocamllabs.io/>
[ocaml-bench/sandmark#73]
<https://github.com/ocaml-bench/sandmark/pull/73>
[ocaml-bench/sandmark#76]
<https://github.com/ocaml-bench/sandmark/pull/76>
[ocaml-bench/sandmark#78]
<https://github.com/ocaml-bench/sandmark/pull/78>
[ocaml-bench/sandmark#86]
<https://github.com/ocaml-bench/sandmark/pull/86>
Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌
• Examples using domainslib and modifying Domains are currently being
worked upon for a chapter on Parallel Programming for Multicore
OCaml. We will release an early draft to the community for your
feedback.
OCaml
╌╌╌╌╌
One PR opened to OCaml this month, which fixes up the marshalling
scheme to be multicore compatible. The complete set of [upstream
multicore prerequisites] are labelled in the compiler issue tracker.
• [ocaml/ocaml#9293] Use addrmap hash table for marshaling
The hash table (addrmap) implementation from Multicore OCaml has
been ported to upstream OCaml to avoid using GC mark bits to
represent visitedness.
[upstream multicore prerequisites]
<https://github.com/ocaml/ocaml/labels/multicore-prerequisite>
[ocaml/ocaml#9293] <https://github.com/ocaml/ocaml/pull/9293>
Acronyms
╌╌╌╌╌╌╌╌
• CTF: Common Trace Format
• CI: Continuous Integration
• GC: Garbage Collector
• PR: Pull Request
As always, many thanks to our fellow OCaml developers and users who
have reviewed our code, reported bugs or otherwise assisted this
month.
Oplot 0.50
══════════
Archive: <https://discuss.ocaml.org/t/ann-oplot-0-50/5235/1>
sanette announced
─────────────────
I'm happy to annouce the revival of the `oplot' library.
If you ever wanted to quickly draw the graph of an intriguing
mathematical function, animate it by varying a parameter, or explore a
3D surface, without leaving your favorite programming language, then
`oplot' is for you.
If you're familiar with LaTeX and want to produce nice mathematical
graphics decorated with LaTeX formulas, that you can view onscreen,
export to images or vector graphics (pdf, eps) then `oplot' is even
more for you!
• Installation: `opam install oplot'
• documentation:
<https://sanette.github.io/oplot/oplot/Oplot/index.html>
• source code, issues, etc: <https://github.com/sanette/oplot>
Drawing is hardware accelerated (opengl) thanks to the venerable
`ocamlsdl' and `lablgl' libraries. I'm glad they still work perfectly.
Happy plotting.
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/12>
Daniil Baturin announced
────────────────────────
[1.9.0] release is now available.
• `--index-only' option that makes soupault dump the site metadata to
JSON and stop at that
• Metadata extraction and index generation can now be limited to
specific pages/section/path regexes, just like widgets
• The `preprocess_element' widget now supports a list of selectors,
e.g. `selector = ["code", "pre code"]'.
• Plugin API now has functions for running external programs, and some
more element tree access functions.
• CSS selector parse errors are now handled gracefully ([lambdasoup
PR#31]).
• The `title' widget now correctly removes HTML tags from the supposed
title string and doesn't add extra whitespace (fixes by [Thomas
Letan]).
[1.9.0] <https://soupault.neocities.org/blog/soupault-1.9.0-release/>
[lambdasoup PR#31] <https://github.com/aantron/lambdasoup/pull/31>
[Thomas Letan] <https://soap.coffee/~lthms/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 25154 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-25 8:51 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-02-25 8:51 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 6517 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 18 to 25,
2020.
Table of Contents
─────────────────
Dune 2.3.0
What's the OCaml equivalent for HLint?
Training Sessions for "Expert OCaml" in Paris
OCaml 4.10 released
Old CWN
Dune 2.3.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-3-0/5184/1>
Rudi Grinberg announced
───────────────────────
On behalf of the dune team, I'm proud to announce the 2.3.0 release of
dune. This release is particularly relevant for users of coq that use
dune to build their theories, developers of coq that use dune to build
their favorite theorem prover. I'd like to thank @ejgallego for all
the hard work to improve dune in this regard.
I'd also like to point out the `(strict_package_deps)' option that is
now available in project files. This option will now ask dune to
validate the package dependencies specified in the `package' stanzas
in your dune-project files.
Here's the full change list, and as always, happy hacking!
2.3.0 (15/02/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Improve validation and error handling of arguments to `dune init'
(#3103, fixes #3046, @shonfeder)
• `dune init exec NAME' now uses the `NAME' argument for private
modules (#3103, fixes #3088, @shonfeder)
• Avoid linear walk to detect children, this should greatly improve
performance when a target has a large number of dependencies (#2959,
@ejgallego, @aalekseyev, @Armael)
• [coq] Add `(boot)' option to `(coq.theories)' to enable bootstrap of
Coq's stdlib (#3096, @ejgallego)
• [coq] Deprecate `public_name' field in favour of `package' (#2087,
@ejgallego)
• Better error reporting for "data only" and "vendored" dirs. Using
these with anything else than a strict subdirectory or `*' will
raise an error. The previous behavior was to just do nothing (#3056,
fixes #3019, @voodoos)
• Fix bootstrap on bytecode only switches on windows or where `-j1' is
set. (#3112, @xclerc, @rgrinberg)
• Allow `enabled_if' fields in `executable(s)' stanzas (#3137, fixes
#1690 @voodoos)
• Do not fail if `ocamldep', `ocamlmklib', or `ocaml' are absent. Wait
for them to be used to fail (#3138, @rgrinberg)
• Introduce a `strict_package_deps' mode that verifies that
dependencies between packages in the workspace are specified
correctly. (@rgrinberg, #3117)
• Make sure the `@all' alias is defined when no `dune' file is present
in a directory (#2946, fix #2927, @diml)
What's the OCaml equivalent for HLint?
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/whats-the-ocaml-equivalent-for-hlint/5167/3>
Continuing this thread, Stéphane Lavergne said
──────────────────────────────────────────────
Aside from Mascot and `ppx_js_style', it seems that [ocp-lint] is
actively maintained by the folks at OcamlPro. I personally only use
`ocamlformat' so I can't vouch for it, but it seems promising.
[ocp-lint] <https://github.com/OCamlPro/typerex-lint>
Training Sessions for "Expert OCaml" in Paris
═════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-02/msg00032.html>
Laurène Gibaud announced
────────────────────────
OCamlPro organizes a cross-company training in French for developers
who already use OCaml. The "Expert OCaml" training mixes theory and
practice and will allow you to master OCaml's advanced features such
as its type-system, OCaml's open source tools and libraries, and how
to write compact and efficient code.
When? The next session is scheduled for March 3-4, 2020, the second
will be on April 7-8, 2020.
Where? Paris 14, at our office
If interested, contact us at contact@ocamlpro.com or register on:
<http://www.ocamlpro.com/forms/preinscriptions-formation-ocaml/>. We
can also organize custom and on-site sessions upon request.
More info on: <http://www.ocamlpro.com/training-ocamlpro/>
OCaml 4.10 released
═══════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-released/5194/1>
octachron announced
───────────────────
We have the pleasure of celebrating the birthday of Francis Ronalds by
announcing the release of OCaml version 4.10.0.
Some of the highlights in this release are:
• A new best-fit allocator for the major heap which reduces both GC
cost an memory usage.
• Some preliminary runtime work for OCaml multicore
• Immutable strings are now enforced at configuration time
• User-defined indexing operators for multidimensional arrays
• Coming soon: statmemprof, a new statistical memory profiler. The
external API will be release next version.
• Various improvements to the manual
• More precise exhaustiveness check for GADTs
• Many bug fixes
Merlin, the OCaml editor service, is not yet available for this
release. We will publish a follow-up announcement when Merlin is
ready.
This release is (or soon will be) available as a set of OPAM switches,
and as a source download here:
<https://caml.inria.fr/pub/distrib/ocaml-4.10/>
Editor note: please follow the archive link for the full changelog
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18280 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-18 8:18 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-02-18 8:18 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 14952 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of February 11 to 18,
2020.
Table of Contents
─────────────────
Logical 0.3.0
OCaml 4.10.0, first release candidate
New release of Menhir, including bug fixes
First release of data-encoding, JSON and binary serialisation
Opam package popularity?
What's the OCaml equivalent for HLint?
New release of naboris 0.1.1
Category theory for Programmers book - OCaml flavor
Call for Speakers: Build Meetup New York April 2020
Old CWN
Logical 0.3.0
═════════════
Archive: <https://discuss.ocaml.org/t/ann-logical-0-3-0/5150/1>
Tóth Róbert announced
─────────────────────
I proud to announce that I published Logical 0.3.0 and it's available
in opam. I'm also not to proud to announce that I did a bunch of
breaking changes in this release. :D
During development of this release, I realized that I made the biggest
mistake I could do as a library maintainer, which is that I didn't use
my own library, so I made a bunch of stupid design mistakes, which I
hopefully fixed in this release.
Changelog:
• Added both_multi goal
• Removed set from the type system
• Moved type system to separate module
• Re-factored state to be a map instead of an association list
• Added bunch of examples to the bin folder
One of my main goal with Logical was to solve the puzzles that I found
in this entertaining article:
<https://xmonader.github.io/prolog/2018/12/21/solving-murder-prolog.html>
and it became a reality so hurray. Another important thing to mention
is that I can proudly say that Logical is capable of solving a mystery
murder, so it's at least a mystery murder complete
language/framework. :D
Future plans(0.4.0 release):
• I want to introduce conditions or validations (I need to find a good
name for it) on the variables, which would basically be a function,
which is run when the variable gets it's value, so it's possible to
assess if the value is a good one or not. I think this feature is
extremely general, flexible and powerful, so I have to be careful
how I implement it(if I will). :D It also means that implementing
negation in Logical will become a breeze, so that's it for being
negation free.
• I'm thinking of creating a Variable module, which will by more like
a syntactic sugar for creating variables. I'm not sure about this,
because this would make Goal.equal "obsolete".
• I will hide Base's datatypes behind ours, so the user don't have to
depend on base to use the library.
Let me know if you have any suggestion or comment about Logical.
Github: <https://github.com/StrykerKKD/Logical>
Docs: <https://strykerkkd.github.io/Logical>
OCaml 4.10.0, first release candidate
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-4-10-0-first-release-candidate/5137/2>
octachron announced
───────────────────
We have released a second release candidate to integrate a bug fix for
32-bit users of the new best-fit allocator:
<https://github.com/ocaml/ocaml/pull/9292>
The fix should be transparent for other users, the release is mostly
here to try to minimize the difference between the candidate and final
binaries.
New release of Menhir, including bug fixes
══════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-02/msg00023.html>
François Pottier announced
──────────────────────────
Dear users of OCaml & Menhir,
It is my pleasure to announce a new release of Menhir.
┌────
│ opam update
│ opam upgrade menhir
└────
This release fixes two bugs in our implementation of Pager's
algorithm. Menhir relies on this algorithm to build an LR automaton
and to decide which states can safely be merged, where "safely" means
"without creating unexplainable conflicts". One bug (which had been
known for a long time, but not fixed) would cause Menhir to sometimes
make an unsafe merge decision, thereby creating an unexplainable
conflict. The other bug (which had never been discovered until now)
would cause Menhir to sometimes miss a safe merge decision, thereby
creating an automaton with needlessly many states.
In summary, after upgrading to this version, you may find (in some
cases) that the parser produced by Menhir for your grammar has
changed. It may have slightly more or slightly fewer states than the
parser produced by previous versions of Menhir. Even in cases where
the parser hasn't changed, the numbering of the states can be
different.
Feedback is welcome.
Happy parsing,
François Pottier
francois.pottier@inria.fr
<http://cambium.inria.fr/~fpottier/>
2020/02/11
╌╌╌╌╌╌╌╌╌╌
• Re-implement Menhir's default algorithm for constructing LR(1)
automata, namely Pager's algorithm. This closes issue #21 (reported
by Andrej Bauer), a bug that would sometimes cause unexplainable
conflicts to appear, because states were merged too
aggressively. This also removes an unreported bug that would cause
the automaton to have too many states, because states were *not*
merged aggressively enough. In summary, the old and new construction
algorithms differ: in many cases, the resulting automaton is
unchanged, but in some cases, the automaton produced by the new
algorithm may have slightly more or slightly fewer states.
• Re-implement Menhir's algorithm for constructing automata in
`--no-pager' mode. In this (undocumented) mode, Menhir does not
merge any states, but allows itself to redirect a transition from a
state `s' to a *larger* state `s''. This method yields an automaton
whose states form a subset of the states of the canonical LR(1)
automaton. It usually has significantly fewer states than the
canonical automaton, and significantly more states than the
automaton produced by Pager's algorithm. The new construction method
removes an unreported bug that would cause the automaton to have too
many states. The automaton produced by the new algorithm will
usually have significantly fewer states than the automaton produced
by the previous algorithm.
• Re-implement Menhir's algorithms for constructing automata in
`--lalr' and `--canonical' modes. The previous algorithms were
correct, as far as we know, so the output of the new algorithms is
the same, up to a possible renumbering of the states. The new
algorithms are slightly faster.
• Increase the maximum length of a production, which used to be 127,
up to 1023. Display a polite error message if this length is
exceeded. (Problem reported by Andreas Abel.)
• The new switch `--timings-to <filename>' causes internal timing
information to be written to the file `<filename>'.
• A version of the library `fix' is now vendored (included) inside
Menhir. This should have no impact for end users, but implies that
`dune' 2.2.0 or later is required.
First release of data-encoding, JSON and binary serialisation
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-data-encoding-json-and-binary-serialisation/4444/8>
Raphaël Proust announced
────────────────────────
The newly released version (0.2) addresses this. All the binary
reading/writing primitives use `result' by default and have `_opt' and
`_exn' variants.
The JSON primitives are not yet changed because they rely on an
external library that has more idiosyncratic error management. (This
will eventually be fixed in a future version.)
Opam package popularity?
════════════════════════
Archive: <https://discuss.ocaml.org/t/opam-package-popularity/5159/1>
Chet Murthy asked
─────────────────
Is there someplace a database of opam packages and their popularity?
Obviously it'd be inaccurate, but it'd still be interesting to see
which packages are most-often downloaded via opam …..
Levi Roth replied
─────────────────
The listing at <https://opam.ocaml.org/packages/index-popularity.html>
has the download counts (I think for the latest month, not sure if
that means past 30 days or since the start of the current calendar
month) as title attributes on the table rows.
What's the OCaml equivalent for HLint?
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/whats-the-ocaml-equivalent-for-hlint/5167/1>
Fangyi Zhou asked
─────────────────
I've been using OCaml for quite a while and one thing I've been
looking for is a good linter, ideally something like the Haskell
[HLint].
I found [this] which seems quite old - latest release in 2012.
Sorry if this has been raised previously.
[HLint] <https://github.com/ndmitchell/hlint>
[this] <http://mascot.x9c.fr/index.html>
"Aaron L. Zeng
──────────────
Something similar, but not as featureful, is [ppx_js_style]. It's
somewhat opinionated, but the checks aren't Jane Street-specific.
[ppx_js_style] <https://github.com/janestreet/ppx_js_style>
New release of naboris 0.1.1
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-new-release-of-naboris-0-1-1/5173/1>
Shawn McGinty announced
───────────────────────
<https://github.com/shawn-mcginty/naboris>
• *(much)* Better performance
• API improvements
Category theory for Programmers book - OCaml flavor
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/category-theory-for-programmers-book-ocaml-flavor/3905/4>
Anton Kochkov announced
───────────────────────
Thanks to @Arul the book was finished, and now is available for
download here -
<https://github.com/hmemcpy/milewski-ctfp-pdf/releases/tag/v1.4.0-rc1>
Please, enjoy and report a feedback.
Call for Speakers: Build Meetup New York April 2020
═══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/call-for-speakers-build-meetup-new-york-april-2020/5174/1>
Jérémie Dimino announced
────────────────────────
On April 7th and 8th, [Jane Street], [Bloomberg] and [Google] will be
hosting a Build Meetup at the [Jane Street offices] in New York City.
As we begin shaping our schedule, we are reaching out to a number of
communities to find people who would like to participate in the
event. Speaker sign-ups are now live [here].
We are excited to announce that the keynote will be presented by the
authors of the research paper “[From Laptop to Lambda: Outsourcing
Everyday Jobs to Thousands of Transient Functional Containers]” which
examines the exciting possibilities for build through the use of cloud
functions.
The entire event will be themed around all things build and test:
Bazel, Buck, BuildStream, CMake, Dune, Goma, Pants, Recc and Remote
Execution. In addition to this, we are interested in the growing
surrounding ecosystems, such as editor integration and developer build
experience as a whole.
The meetup will run as follows: on day one, a series of talks will be
presented along with breakfast, lunch and refreshments. This will be
followed by an evening social at a nearby venue to continue the
discussions from throughout the day.
On the second day there will be an opportunity for broader community
collaboration and discussion during our all day code sprint.
We are looking for insightful and engaging talks and presentations on
topics focused around build systems. Have you worked tirelessly for
the past 6 months on a new feature for project foo you would like to
showcase? Have you and your team spent the last year integrating the
tool bar at your workplace? Do you have some comparisons to make
between qux and quux that the community could benefit from?
If so, we would love to [hear from you]!
We welcome proposals for talks across the entire ecosystem. Each talk
should ideally last 30 minutes, followed by time for questions.
Keep your eyes out for meetup registration information, which will be
sent separately over the next few weeks!
[Jane Street] <https://www.janestreet.com/>
[Bloomberg] <https://www.techatbloomberg.com/>
[Google] <http://www.google.com/>
[Jane Street offices] <https://www.janestreet.com/contact-us/nyc/>
[here]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>
[From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of
Transient Functional Containers]
<http://stanford.edu/~sadjad/gg-paper.pdf>
[hear from you]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 28180 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-04 8:47 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-02-04 8:47 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 16468 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 28 to
February 04, 2020.
Table of Contents
─────────────────
Multicore OCaml: January 2020 update
Use Case for Ephemerons?
`json-data-encoding' version 0.8 (was `ocplib-json-typed')
Developer position at Abacus Medicine, Copenhagen
Camlp5 version 7.11 release (4.10 compatibility)
Old CWN
Multicore OCaml: January 2020 update
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090/1>
Anil Madhavapeddy announced
───────────────────────────
Welcome to the January 2020 news update from the Multicore OCaml team!
We're going to summarise our activites monthly to highlight what we're
working on throughout this year. This update has kindly been assembled
by @shakthimaan and @kayceesrk.
The most common question we get is how to contribute to the overall
multicore effort. As I [noted last year], we are now in the process of
steadily upstreaming our efforts to mainline OCaml. Therefore, the
best way by far to contribute is to test for regressions or
opportunities for improvements in the patches that are outstanding in
the main OCaml repository.
A secondary benefit would be to review the PRs in the [multicore
repository], but those tend to be more difficult to evaluate
externally as they are being spotted as a result of stress testing at
the moment. A negative contribution would be to raise discussion of
orthogonal features or new project management mechanisms – this takes
time and effort to reply to, and the team has a very full plate
already now that the upstreaming has begun. We don't want to prevent
those discussions from happening of course, but would appreciate if
they were directed to the general OCaml bugtracker or another thread
on this forum.
We'll first go over the OCaml PRs and issues, then cover the multicore
repository and our Sandmark benchmarking infrastructure. A new
initiative to implement and test new parallel algorithms for Multicore
OCaml is also underway.
[noted last year]
<https://discuss.ocaml.org/t/multicore-prerequisite-patches-appearing-in-released-ocaml-compilers-now/4408>
[multicore repository]
<https://github.com/ocaml-multicore/ocaml-multicore/pulls>
OCaml
╌╌╌╌╌
◊ Ongoing
• [ocaml/ocaml#9082] Eventlog tracing system
Eventlog is a proposal for a new tracing facility for OCaml runtime
that provides metrics and counters, and uses the Binary Trace Format
(CTF). The next step to get this merged is to incubate the tracing
features in separate runtime variant, so it can be selected at
application link time.
• [ocaml/ocaml#8984] Towards a new closure representation
A new layout for closures has been proposed for traversal by the
garbage collector without the use of a page table. This is very much
useful for Multicore OCaml and for performance improvements. The PR
is awaiting review from other developers, and can then be rebased
against trunk for testing and merge.
• [ocaml-multicore/ocaml-multicore#187] Better Safe Points
A patch to regularly poll for inter-domain interrupts to provide
better safe points is actively being reviewed. This is to ensure
that any pending interrupts are notified by the runtime system.
• Work is underway on improving the marshaling (runtime/extern.c) in
upstream OCaml to avoid using GC mark bits to represent visitedness,
and to use a hash table (addrmap) implementation.
[ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>
[ocaml/ocaml#8984] <https://github.com/ocaml/ocaml/pull/8984>
[ocaml-multicore/ocaml-multicore#187]
<https://github.com/ocaml-multicore/ocaml-multicore/issues/187>
◊ Completed
The following PRs have been merged to upstream OCaml trunk:
• [ocaml/ocaml#8713] Move C global variables to a dedicated structure
This PR moves the C global variables to a "domain state"
table. Every domain requires its own table of domain local
variables, and hence this is required for Multicore runtime.
This uncovered a number of [compatability issues] with the C header
files, which were all included in the recent OCaml 4.10.0+beta2
release via the next item.
• [ocaml/ocaml#9253] Move back `caml_*' to thematic headers
The `caml_*' definitions from runtime/caml/compatibility.h have been
moved to provide a compatible API for OCaml versions 4.04 to
4.10. This change is also useful for Multicore domains that have
their own state.
[ocaml/ocaml#8713] <https://github.com/ocaml/ocaml/pull/8713>
[compatability issues] <https://github.com/ocaml/ocaml/issues/9205>
[ocaml/ocaml#9253] <https://github.com/ocaml/ocaml/pull/9253>
Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The following PRs have been merged into the Multicore OCaml trees:
• [ocaml-multicore/ocaml-multicore#275] Fix lazy behaviour for
Multicore
A `caml_obj_forward_lazy()' function is implemented to handle lazy
values in Multicore Ocaml.
• [ocaml-multicore/ocaml-multicore#269] Move from a global
`pools_to_rescan' to a domain-local one
During stress testing, a segmentation fault occurred when a pool was
being rescanned while a domain was allocating in to it. The rescan
has now been moved to the domain local, and hence this situation
will not occur again.
• [ocaml-multicore/ocaml-multicore#268] Fix for a few space leaks
The space leaks that occurred during domain spawning and termination
when performing the stress tests have been fixed in this PR.
• [ocaml-multicore/ocaml-multicore#272] Fix for DWARF CFI for
non-allocating external calls
The entry to `caml_classify_float_unboxed' caused a corrupted
backtrace, and a fix that clearly specifies the boundary between
OCaml and C has been provided.
• An effort to implement a synchronized minor garbage collector for
Multicore OCaml is actively being researched and worked
upon. Benchmarking for a work-sharing parallel stop-the-world branch
against multicore trunk has been performed along with clearing
technical debt, handling race conditions, and fixing segmentation
faults. The C-API reversion changes have been tested and merged into
the stop-the-world minor GC branch for Multicore OCaml.
[ocaml-multicore/ocaml-multicore#275]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/275>
[ocaml-multicore/ocaml-multicore#269]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/269>
[ocaml-multicore/ocaml-multicore#268]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/268>
[ocaml-multicore/ocaml-multicore#272]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/272>
Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌
• The [Sandmark] performance benchmarking infrastructure has been
improved for backfilling data, tracking branches and naming
benchmarks.
• Numerical parallel benchmarks have been added to the Multicore
compiler.
• An [Irmin] macro benchmark has been included in Sandmark. A test for
measuring Irmin's merge capabilities with Git as its filesystem is
being tested with different read and write rates.
• Work is also underway to implement parallel algorithms for N-body,
reverse-complement, k-nucleotide, binary-trees, fasta,
fannkuch-redux, regex-redux, Game of Life, RayTracing, Barnes Hut,
Count Graphs, SSSP and from the MultiMLton benchmarks to test on
Multicore OCaml.
[Sandmark] <http://bench2.ocamllabs.io/>
[Irmin] <https://irmin.org>
Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌
• A chapter on Parallel Programming in Multicore OCaml is being
written and an early draft will be made available to the community
for their feedback. It is based on Domains, with examples to
implement array sums, Pi approximation, and trapezoidal rules for
definite integrals.
Acronyms
╌╌╌╌╌╌╌╌
• API: Application Programming Interface
• CTF: Common Trace Format
• CFI: Call Frame Information
• DWARF: Debugging With Attributed Record Formats
• GC: Garbage Collector
• PR: Pull Request
• SSSP: Single Source Shortest Path
Nicolas Tollenaere asked
────────────────────────
If I may ask a question, I am curious about the status of integration
of effects into the type system. According to this page
<https://ocamlverse.github.io/content/future_ocaml.html#typed-algebraic-effects>,
original plan was to merge an untyped version of effect, before it was
decided to integrate them into the system. I have seen this
presentation of leo white on this matter
<https://www.janestreet.com/tech-talks/effective-programming/> along
with this one <https://www.youtube.com/watch?v=ibpUJmlEWi4> (from
2016). My understanding was that, at the time of the last
presentation, there was still some theoretical issues to be solved
(although the speaker did not seem too worried about finding some way
around eventually). I have no idea about the current status of the
project. Reading your post it seems that you are now in an integration
phase (PR reviews and all) that would imply that you're done with
(most) theoretical questions. But that could either mean that you are
integrating an untyped version of effects (and the type system is let
for future development) or that you have indeed settled on a
design. Which one is it ? Anyway, thanks for the post and the work in
general, this project seems awesome (even if I did not dive into it
too much until now)
Anil Madhavapeddy replied
─────────────────────────
Good question; our current focus in getting the runtime components
upstreamed (the "Domains" API) and some of the mechanisms that could
be used by an effect system. We haven't yet settled on a final design
for an effect extension to OCaml, but the general preference is to
skip integrating an untyped effect system if a typed version lands in
the right timescales. This will happen after all the runtime pieces
are upstreamed, which will allow everyone to use multicore parallelism
via the lower-level Domains API.
Use Case for Ephemerons?
════════════════════════
Archive: <https://discuss.ocaml.org/t/use-case-for-ephemerons/2838/3>
Continuing this old thread, Yawar Amin said
───────────────────────────────────────────
[Here's another use] (disclaimer: this is my project).
What's happening here is that I'm using an 'ephemeral cache' (i.e. a
cache backed by an ephemeron hash table, [here]) to store subscribers
to a 'topic', i.e. a pub-sub bus. You get a subscription token when
you subscribe to a topic, and part of that token is the cache key. The
cache is 'ephemeral' so as soon as the subscription token goes out of
scope, it and its corresponding subscription (concretely, the stream
and its push function) are automatically deleted from the cache.
Hence, there's no 'unsubscribe' or 'close topic' functionality–it's
assumed that you want to unsubscribe if you let the subscription token
go out of scope.
[Here's another use]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Topic.ml>
[here]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Cache.ml#L41>
`json-data-encoding' version 0.8 (was `ocplib-json-typed')
══════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-json-data-encoding-version-0-8-was-ocplib-json-typed/5095/1>
Raphaël Proust announced
────────────────────────
I'm happy to announce that Nomadic Labs is now in charge of the
development, maintenance and release of `json-data-encoding' – the
library previously known as `ocplib-json-typed'. Even though we are
changing to a more descriptive name, we are maintaining continuity of
version numbers. As a result, this is an announce for the version
`0.8'.
The library `json-data-encoding' lets you define encodings for a given
OCaml type, and use that encoding to encode values of that type into
JSON or decode JSON into values of that type. The library supports
multiple JSON backends: `Ezjsonm', `Yojson', native browser
representation (for `js_of_ocaml', via the package
`json-data-encoding-browser') and `BSON' (via the package
`json-data-encoding-bson').
It is available via `opam' (`opam install json-data-encoding') and
hosted on <https://gitlab.com/nomadic-labs/json-data-encoding/>
Changes from the version v0.7 include:
• extensive tests using `Crowbar' (adapted from similar tests on
`data-encoding' originally by @gasche)
• minor documentation improvements
• improved self documentation capabilities for unions' cases (work by
@smondet)
• improved schema equality (work by @rbardou)
Developer position at Abacus Medicine, Copenhagen
═════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/developer-position-at-abacus-medicine-copenhagen/5119/1>
mokn announced
──────────────
Abacus Medicine has an open developer position. We do parallel
distribution of medicine in EU and for that we have developed a system
to handle the trading. A part of this system is developed in OCaml.
Unfortunately the job description is only in danish, but we do accept
applications in english: [Job description]
[Job description]
<https://www.jobindex.dk/jobannonce/351439/software-developer>
Camlp5 version 7.11 release (4.10 compatibility)
════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-camlp5-version-7-11-release-4-10-compatibility/5121/1>
Chet Murthy announced
─────────────────────
New release 7.11 of Camlp5. Compatible with all OCaml versions >=
4.00.0, latest OCaml version 4.10+beta2 included.
Main improvement: compatible with 4.10's blank module names and
generative functors.
Home page, including downloading and documentation at:
<https://camlp5.github.io/>
Enjoy!
N.B. I'm new to helping out with camlp5, so might have made some
mistakes; any users who find problems should contact me either
directly, or (better) thru issues on
<https://github.com/camlp5/camlp5/releases> and I'll be sure to get
right on it.
N.B.#2: There are still lots of gaps between current Ocaml, and
Camlp5's support; I'm working on fixing that, and there'll soon be a
release that brings camlp5 as up-to-date as possible with Ocaml.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 29138 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-28 10:53 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-01-28 10:53 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 8910 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 21 to 28,
2020.
Table of Contents
─────────────────
New release of Menhir (20200123)
Ocaml cross compiler?
Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
Proper way to allocate an OCaml string from C code in OCaml 4.10?
OCaml 4.10.0, second beta
Old CWN
New release of Menhir (20200123)
════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00040.html>
François Pottier announced
──────────────────────────
It is my pleasure to announce a new release of Menhir, the LR(1)
parser generator.
┌────
│ opam update
│ opam install menhir
│ opam install coq-menhirlib # if you wish to use menhir --coq
└────
There are no new features, only a significant change in the manner in
which Menhir is built:
• Menhir is now built and installed by dune. This should make life
easier for Menhir's developers: in particular, `make test' and `make
speed' can be run straight away and do not requiring installing
Menhir first. This should also make compilation much faster on
multi-core machines. (Contributed by Nicolás Ojeda Bär, to whom many
thanks are due.)
• There used to be a distinction between two slightly different ways
of installing Menhir, namely with and without `ocamlfind'. This
distinction disappears. The command line switch
`--suggest-ocamlfind' is deprecated and causes Menhir to print
`false'.
We hope that these changes do not break any of the code that relies on
Menhir today. Please report any problems that you might
encounter. Happy hacking!
Ocaml cross compiler?
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-cross-compiler/1494/7>
Deep in this thread, Dmitry Ponyatov asked
──────────────────────────────────────────
What about embedded targets like Cortex-M (STM32F3/F4)? How much
memory should it have to have to run OCaml-compiled programs?
Ivan Gotovchits replied
───────────────────────
You may find this [page] interesting. To summarize, with _a lot of
work_ you can make a subset of OCaml programs runnable on a
microcontroller. You will also need to rewrite OCaml's runtime and
develop a new GC for it.
In real life, no, you can't run OCaml on a microcontroller. You need
at least a couple of megabytes of normal RAM with MMU.
[page] <http://www.algo-prog.info/ocapic/web/index.php?id=ocapic>
Ivan Gotovchits then added
──────────────────────────
Hmm, found this [project], that is also quite relevant to you, it is
quite alive, so maybe you have chances :)
[project] <https://github.com/stevenvar/OMicroB>
Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/two-master-internship-proposals-to-explore-social-and-technical-aspects-of-the-creation-of-the-ocaml-and-coq-platforms/5073/1>
Théo Zimmermann announced
─────────────────────────
We are looking for candidates for the following two internships
intended to prefigure the creation of the OCaml and Coq platforms:
• a first internship is focused on exploring technical aspects:
<https://www.irif.fr/_media/users/theo/internship_proposal_platform_tech.pdf>
• a second internship is focused on exploring social and policy
aspects:
<https://www.irif.fr/_media/users/theo/internship_proposal_platform_social.pdf>
Please feel free to forward this announcement. Interested students
should send their resume and cover letter at
[yrg@irif.fr](<mailto:yrg@irif.fr>) and
[theo@irif.fr](<mailto:theo@irif.fr>).
Yann Régis-Gianas (Inria, IRIF, OCaml Foundation) and Théo Zimmermann
(Inria, IRIF, Coq development team)
Proper way to allocate an OCaml string from C code in OCaml 4.10?
═════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/proper-way-to-allocate-an-ocaml-string-from-c-code-in-ocaml-4-10/5075/1>
Rwmjones asked
──────────────
Previously to allocate a string with explicit length (ie. one which
may contain \0 characters) in C code we have used:
┌────
│ strv = caml_alloc_string (count);
│ memcpy (String_val (strv), str, count);
└────
In OCaml 4.10 this doesn't compile because String_val returns a `const
char *'.
I could change String_val to Bytes_val, but that feels wrong. The
runtime seems to use `&Byte_u (strv, 0)'.
It's a shame there's not a caml_copy_string_len function, but what is
the proper way to do this for OCaml 4.10+, especially a way that won't
break in future and will be compatible with multicore?
yallop suggested
────────────────
You can use [`caml_alloc_initialized_string']:
┌────
│ CAMLextern value caml_alloc_initialized_string (mlsize_t len, const char *);
└────
[`caml_alloc_initialized_string']
<https://github.com/ocaml/ocaml/blob/d408e58ea15ec890a2c6d98441d261db51a6735d/runtime/caml/alloc.h#L38~>
OCaml 4.10.0, second beta
═════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-second-beta/5083/1>
octachron announced
───────────────────
The release of OCaml 4.10.0 is near. We have released a second beta
version to help you adapt your softwares and libraries to the new
features ahead of the release.
This new beta contains an update to the internal runtime API that
should make it easier to maintain compatibility across version for
expert users; and a small fix for the analysis of recursive values.
The source code is available at these addresses:
<https://github.com/ocaml/ocaml/archive/4.10.0+beta2.tar.gz>
<https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta2.tar.gz>
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these:
• afl
• flambda
• fp
• fp+flambda
For a better experience, you can use the opam alpha repository
provided by:
┌────
│ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
└────
This repository contains a handful of temporary patched packages, that
you can use while waiting for the packages to be properly patched.
This repository should not be used in production and you probably want
to install it only for the beta switch.
We want to know about all bugs. Please report them here:
<https://github.com/ocaml/ocaml/issues>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 21596 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-21 14:08 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-01-21 14:08 UTC (permalink / raw)
To: lwn, cwn, caml-list, comp
[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 14 to 21,
2020.
Table of Contents
─────────────────
How does the compiler check for exhaustive pattern matching?
resto 0.2 released
opam 2.0.6 release
soupault: a static website generator based on HTML rewriting
Spin: Project scaffolding tool and set of templates for Reason and OCaml
Old CWN
How does the compiler check for exhaustive pattern matching?
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-does-the-compiler-check-for-exhaustive-pattern-matching/5013/1>
Dylan Irlbeck asked
───────────────────
Hi all. I'm relatively new to OCaml, and I was curious on how the
compiler is able to give a warning when a case list is non-exhaustive
- both from a high-level and, if possible, the implementation of this
check. I have some ideas about how one could do this, but none of my
ideas seem like they'd be nearly as efficient as the OCaml compiler
is.
gasche replied
──────────────
The canonical reference for exhaustivity-checking in OCaml is the
scientific publication
[Warnings for pattern matching] Luc Maranget 2007
The general idea is to consider all the patterns of a given
pattern-matching at once, generalize this structure to a "matrix" of
patterns (matching on several values in parallel), and devise an
algorithm to "explore" these pattern matrices in such a way that you
eventually tell if a given pattern-matrix is exhaustive, or can
propose a counter-example.
(I guess we should write a high-level/accessible blog post about
this.)
[Warnings for pattern matching]
<http://moscova.inria.fr/~maranget/papers/warn/index.html>
resto 0.2 released
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/1>
Raphaël Proust announced
────────────────────────
On behalf on Nomadic Labs, I'm happy to announce the release of
version 0.2 of `resto', a library to create type-safe HTTP/JSON
services.
The library is available through opam (`opam install resto'),
distributed under LGPL, and hosted on
<https://gitlab.com/nomadic-labs/resto>.
`resto' was previously released as `ocplib-resto' maintained by
OCamlPro. The project is now maintained by Nomadic Labs.
Along with many bugfixes and a few added features, the main change of
this release is that the library is split into multiple packages with
fine-grained dependencies.
opam 2.0.6 release
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-opam-2-0-6-release/5038/1>
R. Boujbel announced
────────────────────
We are pleased to announce the minor release of [opam 2.0.6].
This new version contains mainly build update & fixes. You can find
more information in this [blog post].
_opam is a source-based package manager for OCaml. It supports
multiple simultaneous compiler installations, flexible package
constraints, and a Git-friendly development workflow._
[opam 2.0.6] <https://github.com/ocaml/opam/releases/tag/2.0.6>
[blog post] <https://opam.ocaml.org/blog/opam-2-0-6>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/11>
Daniil Baturin announced
────────────────────────
soupault 1.8.0 is [released] along with Lua-ML 0.9.1.
Lua-ML now raises `Failure' when Lua code execution fails. There's
much room for improvement in that area, for now I've just done
something that is better than just displaying errors on stderr but
otherwise allowing syntax and runtime errors pass silently.
If you have any ideas how perfect interpreter error reporting _should_
work, please share!
As of improvements in soupault itself, there's now:
• A way for plugins to specify their minimum supported soupault
version like `Plugin.require_version("1.8.0")'
• `TARGET_DIR' environment variable and `target_dir' Lua global that
contains the directory where the rendered page will be written, to
make it easier for plugins/scripts to place processed assets
together with pages.
• "Build profiles": if you add `profile = "production"' or similar to
widget config, that widget will be ignored unless you run `soupault
--profile production'.
• A bunch of new utility functions for plugins.
[released] <https://soupault.neocities.org/blog/soupault-1.8.0-release/>
Spin: Project scaffolding tool and set of templates for Reason and OCaml
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/spin-project-scaffolding-tool-and-set-of-templates-for-reason-and-ocaml/5047/1>
Mohamed Elsharnouby announced
─────────────────────────────
<https://github.com/tmattio/spin>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 18137 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-14 14:16 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-01-14 14:16 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 24944 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of January 07 to 14,
2020.
Table of Contents
─────────────────
Calling a single function on every member of a GADT?
OCamlPro's opam cheat sheet, with a new theme!
OCaml 4.10.0, first beta
Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
Release of naboris 0.1.0 a simple http server
esy@0.6.0 release
Old CWN
Calling a single function on every member of a GADT?
════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00007.html>
Ivan Gotovchits asked
─────────────────────
I'm basically trying to do the equivalent of this simple `fold'
function:
┌────
│ module Simple =
│ struct
│ type term =
│ | Int of int
│ | Add
│ | App of term * term
│
│ let rec fold i f = function
│ | Int _ as t -> f i t
│ | Add -> f i Add
│ | App (x, y) as t -> f (fold (fold i f x) f y) t
│ end
└────
… but using a GADT:
┌────
│ module Gadt =
│ struct
│ type _ term =
│ | Int : int -> int term
│ | Add : (int -> int -> int) term
│ | App : ('b -> 'a) term * 'b term -> 'a term
│
│ let rec fold : type a. 'r -> ('r -> _ term -> 'r) -> 'r = fun i f -> function
│ | Int _ as t -> f i t
│ | Add -> f i Add
│ (*
│ ^ Error: This pattern matches values of type (int -> int -> int) term
│ but a pattern was expected which matches values of type int term
│ Type int -> int -> int is not compatible with type int
│ *)
│ | App (x, y) as t -> f (fold (fold i f x) f y) t
│ end
└────
I've tried other variants of the syntax and got many encouragements
but no green flag from the type-checker. Why is the compiler
expecting an int term in there? I though the whole point of the `type
a. ...' syntax was to allow the matched type to vary from one pattern
to the next? Is there a way to do this?
Ivan Gotovchits replied
───────────────────────
It is the limitation of the let-bound polymorphism. A parameter of a
function is monomorphic in its body. The classical example doesn't
even reference any GADT,
┌────
│ let example f = f "hello", f 42
└────
It won't compile even though we can provide a polymorphic function
that can applied both to integers and to strings, e.g., `exampe (fun x
-> x)' should be possible, but not, because of the let-bounded
polymorphism. There are a few solutions available in OCaml, the
simplest is to use records, e.g.,
┌────
│ type app = {apply : 'a. 'a -> 'a}
│
│ let example {apply} = apply "hello", apply 42;;
│
│ val example : app -> string * int = <fun>
└────
Now we have `app' that is polymorphic. In your case, I would define a
visitor type, e.g.,
┌────
│ type 'r visitor = {visit : 'a. 'a term -> 'r -> 'r}
│
│ let rec fold : type a. 'r -> 'r visitor -> a term -> 'r =
│ fun i f t -> match t with
│ | Int _ as t -> f.visit i t
│ | Add as t -> f.visit i t
│ | App (x,y) as t ->
│ let i = fold i f x in
│ let i = fold i f y in
│ f.visit i t
└────
Jacques Garrigue also replied
─────────────────────────────
Actually, this is a rare case where using a polymorphic method may be
handy too:
┌────
│ let rec fold : type a r. r -> <v : 'b. r -> 'b term -> r> -> a term -> r =
│ fun i f -> function
│ | Int _ as t -> f#v i t
│ | Add -> f#v i Add
│ | App (x, y) as t -> f#v (fold (fold i f x) f y) t
│
│ let v =
│ object method v : type a. _ -> a Gadt.term -> _ =
│ fun x -> function
│ | Int n -> x+n
│ | Add -> x+1
│ | App _ -> x+2
│ end
│
│ let r = Gadt.fold 0 v (App (App (Add, Int 3), Int 5))
└────
The point being that to match on a Gadt you will anyway need to use
the (type a) construct to allow refinement.
rixed asked and Ivan Gotovchits replied
───────────────────────────────────────
So there is no lighter syntax to specify that `f' should
accept any member of a GADT than the syntax to specify
that `f' should accept any type at all?
Only three methods of introducing rank-2 polymorphism are known to me:
1. records
2. objects
3. first-class modules
Jacques has demonstrated the solution with objects, which might be a
little bit more lightweight, at least as you don't need to define a
new data type beforehand. But the invocation is more verbose and
requires an annotation from the caller side, which could be
confusing. The third solution relies on first-class modules and is
even more verbose, at least on the definition side. Just for the sake
of completeness,
┌────
│ module type Visitor = sig
│ type t
│ val term : t -> 'a term -> t
│ end
│
│ let rec fold : type a r. r -> (module Visitor with type t = r) -> a term
│ -> r =
│ fun i ((module Visit) as f) t -> match t with
│ | Int _ as t -> Visit.term i t
│ | Add as t -> Visit.term i t
│ | App (x,y) as t ->
│ let i = fold i f x in
│ let i = fold i f y in
│ Visit.term i t
│
│ let s = fold 0 (module struct
│ type t = int
│ let term x _ = x + 1
│ end)
└────
And again, it is not about GADT. GADT act as a red herring here. As
I've demonstrated earlier, using a simple pair will suffice to display
the limitation of the prenex polymorphism. Even no ADT is required,
just apply one term to another two and you will get them unified,
e.g.,
┌────
│ let f g x y : unit = g x; g y
└────
will have type
┌────
│ val f : ('a -> unit) -> 'a -> 'a -> unit
└────
because 'a is quantified on the scope of `f' not `g', in other words,
it has type (not an OCaml syntax)
┌────
│ val f : forall 'a. ('a -> unit) -> 'a -> 'a -> unit
└────
while we would like to have a type
┌────
│ val f : forall 'b, 'c. (forall 'a. 'a -> unit) -> 'b -> 'c -> unit
└────
OCaml doesn't allow us to define types like `('a. 'a -> 'a)' and the
reason is not that it is hard to extend the parser it is…
I wonder, is this just a limitation of the OCaml parser or
is there some deep reason for these work-around (like is
the case, from my understanding, for the value
restriction)?
Yep, good catch! It is because of the impurity. Indeed, Haskell has
the Rank2Types extension that lets us write types like `(forall a. a
-> ()) -> b -> c -> ()', with no extra syntactic burden (modulo having
to provide the type annotation). But functions in Haskell are pure,
therefore it is possible. To make the story short and obvious, let me
do a simple demonstration of how things can go wrong in a language
with side-effects. Let's go back to the simple example of pairs and
the identity function. Consider the following nasty identity
function,
┌────
│ let bad_id () =
│ let cache = ref None in
│ fun x -> match cache.contents with
│ | None -> cache := Some x; x
│ | Some cache -> cache
└────
It has type `unit -> 'a -> 'a' therefore, if we would have the rank-1
polymorphism enabled for functions, we could apply it to the function
┌────
│ let map2 : fun ('a. 'a -> 'a) -> 'b -> 'c -> 'b * 'c = fun f (x,y) -> f x, f y
└────
as
┌────
│ let x,y : string * int = map2 (bad_id ()) "hello", 42
└────
and will get a segmentation fault, as `y' will now have type int but
hold a string.
And here comes the syntax as a savior as it lets us specify functions
that are guaranteed to be syntactic values. Indeed, all three
solutions syntactically guarantee that the provided argument is a
function, not a closure. Indeed, let's introduce the universal
identity via a record,
┌────
│ type id = { f : 'a. 'a -> 'a}
└────
and we can see that our `bad_id' is not accepted due to the value
restriction, while good_id, defined as,
┌────
│ let good_id x = x
└────
is perfectly fine, e.g.,
┌────
│ let id1 = {f = good_id} (*accepted *)
│ let id2 = {f = bad_id} (* rejected *)
└────
moreover, even a fine, but not syntactic, identity is also rejected
┌────
│ let fine_id () x = x
│ let id3 = {f = fine_id ()} (* rejected *)
└────
with the message
┌────
│ This field value has type 'b -> 'b which is less general than 'a. 'a -> 'a
└────
The same is true with modules,
┌────
│ module type Id = sig
│ val f : 'a -> 'a
│ end
│ module Id1 : Id = struct let f = good_id end (* accepted *)
│ module Id2 : Id = struct let f = bad_id () end (* rejected *)
│ module Id3 : Id = struct let f = fine_id () end (* rejected *)
└────
and with objects (left as an exercise).
To summarize, in order to enable rank2 polymorphism we need a special
kind of values to bear universal functions, as we can't rely on
ordinary functions, which could be constructed using partial
application. OCaml already had objects and records, which serve as a
fine media for universally quantified functions. Later first class
modules were introduced, which could also be used for the same
purpose. Probably, one could devise a special syntax (or rely on the
new attributes and extensions syntax, e.g., `map2 [%rank2 : fun x ->
x] ("hello",42)' but probably this will lead to an unnecessary
bloating of the language and the implementation, especially since we
already have three solutions with a more or less tolerable syntax (and
are in the base language, not an extension). Besides, if we will use
the `[@@unboxed]' annotation, or visitor will have the same
representation as a function, e.g.,
┌────
│ type 'r visitor = {visit : 'a. 'r -> 'a term -> 'r} [@@unboxed]
│ let count x _ = x + 1
│ let counter = {visit=count}
└────
and
┌────
│ # Core_kernel.phys_same count counter;;
│ - : bool = true
└────
Concerning rank-n polymorphism, in OCaml is is achieved using
functors. Yes, they are a little bit syntactically heavy and force us
to write signatures, but this is necessary anyway as rank-n is
undecidable (non-inferrable). Finally, as a real-world example [1] of
rank-2 polymorphism consider the universal WAVL tree that is a binary
tree with each element having a different type (aka heterogeneous
map). We use it in BAP as a backing store. You might find a few tricks
there, especially using continuation-passing in the recursive cases.
Cheers, Ivan
[1]:
<https://github.com/BinaryAnalysisPlatform/bap/blob/b40689e636607b977758af048b79d65684ce48c3/lib/knowledge/bap_knowledge.ml#L847-L1693>
Malcolm Matalka asked and Ivan Gotovchits replied
─────────────────────────────────────────────────
Why is type checking creating a record different than type
checking a function argument?
If we had the syntax (or something like it):
let map2 : ('a. 'a -> 'a) -> ('b * 'c) -> ('b * 'c)
Why would the type checker not be able to see that
map2 good_id ("hi", 42)
is valid but
map2 (fine_id ()) ("hi", 32)
is not, using the same logic that is verifying creating
the "id" record is not valid?
I believe it is possible, as it is possible in Haskell (with
RankNTypes and ScopedTypeVariables). The main (theoretical) difference
is that in OCaml we need to check whether an expression is expansive
and use a specialized generalization in case if it is (for the relaxed
value restriction). It will, however, complicate the type inference
engine a lot, but most importantly, changing the typing rule of
functions will have a tremendous impact on the language. So this would
be a very impractical solution. Especially, since we don't have the
mechanism of language extensions, enabling RankNTypes will make a lot
of programs untypeable, as they will now require type annotations
(recall that RankN is undecidable in general). It could probably be
implemented as a compiler command line parameter, like `-rectypes' but
this will be still quite impractical since more often code like `fun f
-> f 1, f true' is a programmer error, rather than a true request for
universal polymorphism (the same as with rectypes, recursive types a
more often an error rather than a deliberate attempt). Therefore,
enabling RankN(^1) polymorphism will type too many programs (not that
it is unsound, just many programs won't have sense) at the cost of
even more obscure type errors. On the other hand, we have three
syntactic constructs that let us express non-prenex polymorphism of
the necessary rank(^2) without breaking anything else. So it looks
like a good deal - we can have rankN polymorphism and decidable type
checker at the same time. Just think of polymorphic records/methods as
an embedded DSL for rankN polymorphism.
`==========' Footnotes:
1) An important point, that I forgot to notice, is that enabling
scoped
type variables, will inevitably enable rankN polymorphism, e.g., since
now any type could be a polytype, then suppose we have type
`'a. ('b.'b -> 'a) -> 'a' could be instantiated to 'a = 'd. ('c. ->
'd) -> 'd, so that our type is now `'d. ('b. 'b -> ('c. 'c -> 'd) ->
'd) -> ('c. 'c -> 'd) -> 'd' which is now rank3. Therefore, enabling
arbitrary quantification in the arrow type will lead to rankN and
immediately make undecidable most of the type checker.
1) We can craft arbitrary rank using records with universally
quantified
type variables, e.g., here is an example of rank3 polymorphism:
┌────
│ type 'a rank1 = {f1 : 's. 's -> 'a}
│ type 'a rank2 = {f2 : 'r. 'r -> 'a rank1}
└────
Indeed, `f2' has type `'a.('r. 'r -> ('s. 's -> 'a)'
OCamlPro's opam cheat sheet, with a new theme!
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rfc-ocamlpros-opam-cheat-sheet-with-a-new-theme/4689/3>
Thomas Blanc announced
──────────────────────
The opam cheat-sheet is now published in its final form.
You can get the [colored] and [black-and-white] versions from our
website.
Happy hacking!
[colored]
<http://www.ocamlpro.com/wp-content/uploads/2019/11/ocaml-opam.pdf>
[black-and-white]
<http://www.ocamlpro.com/wp-content/uploads/2020/01/ocaml-opam-bw.pdf>
OCaml 4.10.0, first beta
════════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-first-beta/4989/1>
octachron announced
───────────────────
The release of OCaml 4.10.0 is approaching. We have published a first
beta version to help you adapt your software to the new features ahead
of the release.
During our preliminary tests for this new beta, we discovered that the
recent work towards a multicore-ready OCaml runtime introduced
compatibility issues within some opam packages, that were tweaking the
runtime internals. Most of those opam packages have been fixed, or
will be soon. Nevertheless, if you are affected by such compatibility
issue, please speak up.
The source code is available at these addresses:
<https://github.com/ocaml/ocaml/archive/4.10.0+beta1.tar.gz>
<https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta1.tar.gz>
The compiler can also be installed as an OPAM switch with one of the
following commands.
┌────
│ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
or
┌────
│ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where you replace <VARIANT> with one of these:
• afl
• flambda
• fp
• fp+flambda
We want to know about all bugs. Please report them here:
<https://github.com/ocaml/ocaml/issues>
Happy hacking.
Kate added
──────────
For the people wanting to give OCaml 4.10.0beta1 a shot, here is an
opam overlay which adds fixes to major packages for them to work with
this beta: <https://github.com/kit-ty-kate/opam-alpha-repository>
To use it, simple call:
┌────
│ $ opam switch 4.10
│ $ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
└────
Obviously, this repository should not be used in production and
probably contains a few bugs, but at least it allows everyone to have
almost as many packages available as with OCaml 4.09. Only 60ish
packages are still not available, but apart from the notable exception
of `merlin' all the essential packages and dependencies are there.
This work has been part of the release-readyness effort founded by the
OCaml Software Foundation as announced here:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>
The rest of the effort is going to be put towards having `merlin'
available for OCaml 4.10 and upstreaming all the fixes from
opam-alpha-repository (most of them have PRs associated already). I'm
hopeful for them be all upstreamed and available before the stable
release of OCaml 4.10.
Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/job-data-engineer-positions-at-elastic-us-canada-western-europe-proximate-to-na-timezones/4991/1>
Hezekiah Carty announced
────────────────────────
Our team here at [Elastic] has positions open for a few security data
engineers (aka wranglers of data and all the systems involved). We
are a distributed company so you don't have to be close to an office
to be considered. Infosec industry experience is _not_ required,
though of course welcome. We're surrounded by experts in the field so
you'll have lots of opportunities to learn as you go!
The official postings are available here (both have the same text and
only differ in title/seniority):
• Security data engineer -
<https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-data-engineer/2005140#/>
• Senior security data engineer -
<https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-senior-data-engineer/2005152#/>
Language-wise, OCaml/Reason makes up most of the code you’ll be
working on. Python makes up most of the rest, in particular taking
advantage of the machine learning and natural language processing
goodies that ecosystem provides. Most of the tools and service we
develop are internally focused, supporting security research and
improvements to security protections for our users. For those
so-inclined, there are lots of opportunities to present at and attend
conferences, present work in blog posts, contribute to open source
software projects and otherwise engage the community.
The positions are very similar to our [last hiring announcement],
though we had a different name at that point!
Please reach out to me if you have any questions. I’m available on the
OCaml or Reason Discord servers or by email at
hezekiah.carty@elastic.co.
[Elastic] <https://www.elastic.co/>
[last hiring announcement]
<https://discuss.ocaml.org/t/filled-posting-is-no-longer-open-threat-research-engineer-job-endgame-us/1937>
Release of naboris 0.1.0 a simple http server
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/release-of-naboris-0-1-0-a-simple-http-server/4994/1>
Shawn McGinty announced
───────────────────────
<https://github.com/shawn-mcginty/naboris>
I could use input on the API and the documentation. Working on trying
to improve both at the moment.
The goal was to create a very simple library for building RESTful type
of web servers. Make it _very_ easy to manage handle request/response
lifecycle and sessions.
In my opinion this type of web server is a great entry point for new
developers looking to explore the OCaml/Reason world.
Recently I have fallen in love with OCaml and Reason, and as a mostly
web centered developer I've found this area quite lacking. I'm still
new to the language and eco system so any guidance would be highly
appreciated!
Yawar Amin replied
──────────────────
Wow! It seems we had much the same idea–OCaml/Reason more accessible
to web developers new to the ecosystem :-D I've been working on
something very similar: <https://github.com/yawaramin/re-web/>
Ulrik Strid said
────────────────
There is also opium <https://github.com/rgrinberg/opium>
And morph <https://github.com/reason-native-web/morph> that has
similar goals.
It would be nice if we could either create a shared core that all
could build from or collaborate on one.
esy@0.6.0 release
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-esy-0-6-0-release/5010/1>
Andrey Popp announced
─────────────────────
We've just released a new version of esy. You can install it with npm:
┌────
│ $ npm install -g esy@0.6.0
└────
[esy] is a package.json driven workflow for native development with
Reason/OCaml (and even C/C++). It provides per-project build
environments which are isolated from each other but share underlying
build caches so creating new environments is cheap.
While 0.6.0 is mainly about "quality-of-life" improvements it also got
few new features including a basic support for garbage collection of
unused build artifacts.
For more info see a [blog post] by @prometheansacrifice which
highlights important updates in 0.6.0.
[esy] <https://esy.sh>
[blog post] <https://esy.sh/blog/2020/01/12/0.6.0.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 53238 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-07 13:43 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2020-01-07 13:43 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 23631 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 31, 2019
to January 07, 2020.
Table of Contents
─────────────────
ocaml-lsp preview
Mkocaml Release - Project generator
Garbage Collection, Side-effects and Purity
A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
Release of owl-symbolic 0.1.0
Static lifetime
Old CWN
ocaml-lsp preview
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/15>
Continuing this thread, Edwin Török said
────────────────────────────────────────
Here is an example with ALE and Neovim (tested with v0.3.8):
• Install the [Ale] plugin. If your Vim has support for packages (Vim
8+ or Neovim) you can simply clone it in the correct subdir, no need
for a plugin manager: `git clone https://github.com/w0rp/ale.git
.vim/pack/my-plugins/start/ale'
• Add this to your .vimrc:
┌────
│ " only invoke merlin to check for errors when
│ " exiting insert mode, not on each keystroke.
│ let g:ale_lint_on_text_changed="never"
│ let g:ale_lint_on_insert_leave=1
│
│ " enable ALE's internal completion if deoplete is not used
│ let g:ale_completion_enabled=1
│
│ " only pop up completion when stopped typing for ~0.5s,
│ " to avoid distracting when completion is not needed
│ let g:ale_completion_delay=500
│
│ " see ale-completion-completeopt-bug
│ set completeopt=menu,menuone,preview,noselect,noinsert
│
│ if has('packages')
│ packloadall
│
│ " This should be part of ALE itself, like ols.vim
│ call ale#linter#Define('ocaml',{
│ \ 'name':'ocaml-lsp',
│ \ 'lsp': 'stdio',
│ \ 'executable': 'ocamllsp',
│ \ 'command': '%e',
│ \ 'project_root': function('ale#handlers#ols#GetProjectRoot')
│ \})
│
│ " remap 'gd' like Merlin would
│ nmap <silent><buffer> gd <Plug>(ale_go_to_definition_in_split)<CR>
│
│ " go back
│ nnoremap <silent> <LocalLeader>gb <C-O>
│
│ " show list of file:line:col of references for symbol under cursor
│ nmap <silent><buffer> <LocalLeader>go :ALEFindReferences -relative<CR>
│
│ " Show documentation if available, and type
│ nmap <silent><buffer> <LocalLeader>hh <Plug>(ale_hover)<CR>
│
│ " So I can type ,hh. More convenient than \hh.
│ nmap , <LocalLeader>
│ vmap , <LocalLeader>
│ endif
└────
[Ale] <https://github.com/dense-analysis/ale>
Mkocaml Release - Project generator
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/mkocaml-release-project-generator/4949/1>
Chris Nevers announced
──────────────────────
I recently created a tool to generate OCaml projects. I constantly
have difficulties with dune commands and setting up opam files,
etc. Mkocaml generates a dune project with inline tests, opam file,
git repository, git ignore, and a Makefile with easy commands. This
tool can be of great help to newcomers, allowing them to get up and
running faster!
<https://github.com/chrisnevers/mkocaml>
Garbage Collection, Side-effects and Purity
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/garbage-collection-side-effects-and-purity/4737/1>
Gerard asked
────────────
GC = Garbage Collection
GC, in a pure program, is a point that's always confused me. I always
understood that freeing memory from a program was impure and would
create side-effects but it seems it doesn't matter if the program is
remove from all consequences of those impure acts and side-effects.
Basically, if any memory block has no remaining references in the
program, then freeing that block will have no consequences on the
running program so its allowed to happen behind the scenes..
Is this correct reasoning?
Guillaume Munch-Maccagnoni replied
──────────────────────────────────
To answer your question “does de-allocation creates a side-effect?”:
To state the obvious: if you care about the memory consumption of your
program, then you care about the side-effect of de-allocation, and
this indeed voids purity.
A language like OCaml lets you reason about de-allocation. Memory is
collected when values are no longer reachable. Like in other
languages, 1) a value that does not escape and goes out of scope will
get collected, and 2) you can reason about when a value escapes and
goes out of scope thanks to OCaml respecting the strict evaluation
order of value types. OCaml (like other compiled languages) is in fact
more precise: it ties the dynamic notion of reachability to the
lexical notion of variable occurrence. For instance, in the following:
┌────
│ let x = get_huge_data () in
│ let z = long_running_function x in
│ f z
└────
OCaml will be able to collect the value in `x' before `x' goes out of
scope, and thus if possible before `long_running_function'
returns. Indeed, OCaml performs liveness analysis during compilation,
and records the information about variable occurrences in frame
descriptors, for consumption by the GC when it scans for roots. In
fact, you can rely on call-by-value operational semantics to (loosely)
reason that a value no longer appears in a program, and therefore that
the corresponding memory will be collected by the GC¹ ([Morrisett,
Felleisen and Harper, "Abstract Models of Memory Management"]). Of
course, using lazy or higher-order interfaces (when closures escape;
with many idioms they do not) will make it harder to reason about the
lifetime of values.
(¹: For OCaml, this is a conjecture I make, for subsets which could be
given such operational semantics, and only for native
compilation. Morrisett, Felleisen and Harper's semantics obviously
assumes that the results of liveness analysis are made available to
the GC, but this is not written, nor is there any mention of the link
between liveness analysis and accuracy of garbage collection in
Appel's "Modern Compiler Implementation in C". I assume that it was
part of folklore at the time, though recently I mentioned it to some
functional PL researcher and they seemed surprised. I only found it
explicitly mentioned in later papers from the OOP community. I checked
that everything seems in place for OCaml to allow such reasoning, but
only the authors of the original code, @xavierleroy and
@damiendoligez, can tell us if this is intended to be part of the
language semantics.)
Furthermore, memory is not collected immediately when a value becomes
unreachable. Instead:
• Short-lived values are allocated contiguously and deallocated in a
batch, so that allocating and deallocating short-lived values is
very cheap, with additional benefits in terms of cache
locality. This replaces stack allocation from languages with
explicit memory management.
• Longer-lived values are moved to a heap that is scanned
incrementally, to ensure a bounded latency. In contrast, naive
reference-counting and unique pointers from C++/Rust make you pay
the cost of deallocation up-front.
While this is essential for understanding the performance of OCaml
programs, from the point of view of deallocation-as-an-effect, the
delaying of the collection of unreachable memory can be seen as a
runtime optimisation, that does not change the effectful status of
deallocation (the memory still gets freed). [The intuition is that an
effect can support some degree of reordering without requiring purity,
as illustrated by strong monads which can be commutative without being
idempotent, one possible definition of purity for semanticists.]
But is de-allocation an effect _in practice_? Faced with the
scepticism and misunderstandings from this thread, I emit two
hypotheses:
1) Memory consumption is not an issue in functional programming, for
application areas that interest functional programmers.
2) Memory management in OCaml is efficient in such a way that
programmers do not need to think about it in their day-to-day
programming activities in those terms.
Hypothesis 2) could be explained for instance if OCaml programmers are
already dealing with effects and thinking about the order in which
their code executes (my experience), and are only used to deal with
deallocation as an afterthought, e.g. when chasing leaks with a
profiler.
Let us turn towards two programming language experiments from the
1990's that allow me to reject hypothesis 1). Both show what happens
when one denies the status of deallocation as an effect controlled by
the programmer.
• Region-based memory management consisted in allocating in a stack of
memory _regions_ deallocated at once, and determined by a
whole-program static analysis. Now regarded as a failed idea but
successful experiment (i.e. good science!), it taught us a lot about
the structure of functional programs in relationship to memory
management ([see this retrospective]). There were some good
performance results, but also pathological cases _“where lifetimes
were not nested or where higher-order functions were used
extensively”_, sometimes requiring them to be altered to be _“region
friendly”_, which was _“time-consuming”_ and required knowledge of
the inference algorithm. In addition, the regions changed
unpredictably when the programs evolved, and memory leaks appeared
when the compiler inferred too wide regions.
• Haskell was (at the time) an experiment with lazy functional
programming. Pervasive laziness prevents reasoning about the
lifetime of values, and purity is a central assumption used by the
compiler for program transformations, which is antithetical with
reasoning about deallocation as an effect. It is well-known that
naive Haskell code has issues with memory leaks, and that realistic
Haskell programs have to follow "best practices" to avoid leaks, by
making extensive use of strictness annotations (e.g. bang
patterns). Unfortunately, I found it hard to find reliable academic
sources about lessons drawn from the experiment like the RBMM
retrospective. The best I could find on the topic of memory leaks is
the following blog post:
<https://queue.acm.org/detail.cfm?id=2538488>, from a Haskell
programmer who wrote in another post (linked from that one) _“My
suspicion is that many (most?) large Haskell programs have space
leaks, but they often go unnoticed”_. This is consistent with
comments I received from people with Haskell experience (first-hand,
one academic and one industrial) and about an industrial Haskell
consultant (second-hand) who reportedly commented that their main
job was to fix memory leaks (but maybe in jest). Of course, take
this with a grain of salt. At least, I believe that the Haskell
academic community has accumulated empirical evidence of the extent
and manner in which deallocation voids purity assumptions. Having an
authoritative source about it would be pretty important to me, given
the initial promises of functional programs being more tractable
mathematically specifically via “referential transparency” and
independence of execution order, whose theoretical justification
already looks shaky to me from a semantic point of view. Some parts
of the literature continues to promise far-reaching consequences of
equational reasoning, without clear statements of limitation of the
application domain. I have the impression that the Haskell which is
practiced in the real world is very different from what you can read
in some academic papers.
The hypothesis that deallocation matters as an effect, and that ML
makes it easy to program and reason about effects, seems to me a
strong argument explaining OCaml's predictable and competitive
performance.
So, thank you for your healthy scepticism.
[Morrisett, Felleisen and Harper, "Abstract Models of Memory
Management"] <https://dash.harvard.edu/handle/1/3293156>
[see this retrospective]
<https://link.springer.com/article/10.1023/B:LISP.0000029446.78563.a4>
Xavier Leroy replied
────────────────────
Concerning the "don't scan local variables that are dead" trick:
• Technically it is not "intended to be part of the language
semantics" because the bytecode compiler (ocamlc) doesn't implement
it, only the native-code compiler (ocamlopt).
• As far as I remember, I reinvented this trick circa 1993, but it
seems it was used earlier in the Lazy ML compiler by Augustsson and
Johnsson. See Appel and Shao's paper "An Empirical and Analytic
Study of Stack vs. Heap Cost for Languages with Closures", JFP,
1996, end of section 5.
Guillaume Munch-Maccagnoni the asked
────────────────────────────────────
TL;DR: the paper mentioned by @xavierleroy provides additional
references regarding the importance of liveness analysis for GC,
including a demonstration by Appel that this actually matters for
space complexity (thanks!). I find that a link is still missing with
an abstract semantics à la Morrisett, Felleisen & Harper. This seems
important to me because more theoretical works about time & space
complexity in the lambda-calculus seem to take for granted that
garbage collection implements something like the latter (i.e., how
does one specify and certify that a compiler is sound for space
complexity?).
Xavier Leroy replied
────────────────────
See for example [Closure Conversion is Safe for Space], by Zoe
Paraskevopoulou and Andrew W. Appel, ICFP 2019.
[Closure Conversion is Safe for Space]
<https://www.cs.princeton.edu/~appel/papers/safe-closure.pdf>
A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/a-lightweight-ocaml-webapp-tutorial-using-opium-caqti-and-tyxml/4967/1>
Shon announced
──────────────
The tutorial is [hosted on gitlab pages], out of [this repository].
I put this together in response to some requests for introductory
material on the topic (here and on [/r/ocaml]. I don't have much
expertise to offer in this area, but I had hacked together some simple
servers based on Opium in the past few months, so it seemed like I
should be able to memorialize some of what I learned for the benefit
of others. I received some critical guidance by the Opium maintainers,
rgrinberg and anuragsoni, and from other resources online (mentioned
at the end of the tutorial).
Any feedback or improvements are welcome: this is my first time
writing such lengthy instructional material, and I'm sure there's lots
of room to make it better.
[hosted on gitlab pages] <https://shonfeder.gitlab.io/ocaml_webapp/>
[this repository] <https://gitlab.com/anuragsoni/ocaml_webapp>
[/r/ocaml] <https://www.reddit.com/r/ocaml/>
Release of owl-symbolic 0.1.0
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/2>
jrzhao42 announced
──────────────────
The Owl tutorial book URL address is now changed to:
<https://ocaml.xyz/book/symbolic.html>.
Static lifetime
═══════════════
Archive: <https://discuss.ocaml.org/t/static-lifetime/4908/19>
André asked and Guillaume Munch-Maccagnoni replied
──────────────────────────────────────────────────
> Is it possible to “statically” allocate a value? By this I mean mark
a value such that it gets ignored by the GC and lives until the
program exits?
This is indeed the purpose of Ancient, which comes with limitations
and does not allow you to reclaim the memory until you exit the
program. (I am curious to know how well it works with recent OCaml
versions.)
> it would be really interesting to learn whether Ocaml forbids blocks
outside the heap.
The OCaml runtime has two modes (chosen at compilation) for dealing
with so-called "out-of-heap" pointers. In the legacy one that Chet
remembers, the GC uses a page table when scanning to be able to tell
which pointers it possesses. In the "no-naked-pointers" mode devised
more recently for efficiency reasons, the page table is replaced by
looking at the colour in the header of the dereferenced
value. Out-of-heap values must be preceded by a header with colour
black. The no-naked-pointer mode is more restricted, because once a
static value is referenced, it can no longer be deallocated, as you
never know whether it is still reachable by the GC. This should be
enough to support Ancient.
> One should verify such intuitions experimentally, before trying to
fix them, but I’m not familiar with what OCaml profilers can do…
Excluding large long-lived data from the GC is an old idea. Among
recent developments, Nguyen et al. [1] distinguish a "control path"
(where the generational hypothesis is assumed to hold) from a "data
path" (where values are assumed to follow an "epochal" behaviour
(long-lived, similar lifetimes, benefit from locality), and are
excluded from GC). They give as motivation so-called "big data" and as
figures of pathological GC usage up to 50% of total runtime. I
remember reading similar figures from blog posts about large data sets
in OCaml. In reality this indeed depends on knobs you can turn on your
GC that can result in increased peak memory usage among
others. (Assuming infinite available memory, it is even possible to
let the GC share drop to 0%.)
@ppedrot reported to me that in a recent experiment with Coq, using an
Ancient-like trick to exclude some large, long-lived and
rarely-accessed values from being scanned (namely serialising them
into bigarrays), they saw an 8% performance improvement across the
board in benchmarks.
Multicore, if I understood correctly, aims to support only the
no-naked-pointer mode, and I am not sure what the page table will
become. Coq currently does some out-of-heap allocation in the VM, and
has been adapted to be compatible with the no-naked-pointer mode by
wrapping out-of-heap pointers into custom blocks. For scanning its
custom stack (which mixes in-heap and out-of-heap values), Coq sets up
a custom root-scanning function (`caml_scan_roots_hook`), which still
relies on the page table.
Note that having to wrap out-of-heap pointers in custom blocks is
(much!) less expressive: for instance with Ancient you can call
`List.filter` on a statically-allocated list (and correctly get a
GC-allocated list of statically-allocated values). With custom blocks
you cannot mix in-heap and out-of-heap values in this way.
For a type system to deal with "statically" allocated values, have a
look at Rust, which: 1) prevents cycles of reference-counting schemes
thanks to uniqueness, 2) can treat GC roots as resources to deal with
backpointers at the leaves of the value (cf. the interoperability with
SpiderMonkey's GC in Servo). A point of view that I like is that
tracing GCs and static allocation differ fundamentally by how they
traverse values for collection: traversing live values for the first
one, and traversing values at the moment of their death for the
other. This gives them distinct advantages and drawbacks so one can
see them as complementary. (See notably [2,3].) Static allocation is
interesting for performance in some aspects (no tracing, no read-write
barrier, reusability of memory cells, avoids calling the GC at
inappropriate times), but I find it even more interesting for
interoperability (e.g. exchanging values freely with C or Rust, or
[applications from that other thread]). It is natural to want to mix
them in a language.
As far as I understand, developing the runtime capabilities for OCaml
to deal with out-of-heap pointers without resorting to an expensive
page table is an engineering problem, not a fundamental one. If anyone
is interested in this, please contact me.
[1] Nguyen et al., [Yak : A High-Performance Big-Data-Friendly Garbage
Collector], 2016
[2] Bacon, Cheng and Rajan, [A Unified Theory of Garbage Collection],
2004
[3] Shahriyar, Blackburn and Frampton, [Down for the Count? Getting
Reference Counting Back in the Ring], 2012
[applications from that other thread]
<https://discuss.ocaml.org/t/using-a-bigarray-as-a-shared-memory-for-parallel-programming/4841/19>
[Yak : A High-Performance Big-Data-Friendly Garbage Collector]
<https://www.usenix.org/system/files/conference/osdi16/osdi16-nguyen.pdf>
[A Unified Theory of Garbage Collection]
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.439.1202&rep=rep1&type=pdf>
[Down for the Count? Getting Reference Counting Back in the Ring]
<https://dl.acm.org/citation.cfm?doid=2258996.2259008>
UnixJunkie also replied
───────────────────────
If you can store your long-leaved data into a bigarray, I think you
would reach the effect that you were looking for (no more GC scanning
of this data).
This was once advised to me by Oleg, for some performance-critical
section of some code.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35507 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-31 9:18 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-12-31 9:18 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1: Type: text/plain, Size: 14554 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 17 to 31,
2019.
Sorry for the hiatus last week, I was away with no internet
access. Happy new year!
Table of Contents
─────────────────
Internships at Be Sport (OCaml, Ocsigen)
ocaml-lsp preview
Reproducible builds with OCaml / opam and MirageOS
the OCaml Software Foundation
soupault: a static website generator based on HTML rewriting
Release of owl-symbolic 0.1.0
Old CWN
Internships at Be Sport (OCaml, Ocsigen)
════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00023.html>
Be Sport announced
──────────────────
Be Sport currently has several open internship positions for OCaml
developers.
Keywords: OCaml, Ocsigen, Mobile app development, Web, Database,
Sport, Social networks
Be Sport develops the first global platform dedicated to sport, in
collaboration with prominent actors of sport in France and in the
world. All our development is done in OCaml. Our Web and mobile apps
(iOS, Android) are developed as a multi-tier app using the Ocsigen
framework. Our premises are located in the center of Paris.
Please contact me for more information.
ocaml-lsp preview
═════════════════
Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/1>
Rudi Grinberg announced
───────────────────────
I'm excited to announce [ocaml-lsp]. This project contains an
implementation of an LSP server for the OCaml language. The current
implementation piggy backs on the widely successful [merlin] tool to
provide completion & type inference. In the future, we'd like to use
all other essential tools such as ocamlformat, odoc, dune to provide
more functionality in your editors.
For now, the project isn't yet available on opam as we're still
polishing some rough edges in the release process. Nevertheless, I
invite all brave souls who are ready to experiment to give this lsp
server a try. Your feedback & contributions are most welcome
:slight_smile:
[ocaml-lsp] <https://github.com/ocaml/ocaml-lsp>
[merlin] <https://github.com/ocaml/merlin>
UnixJunkie asked and Anton Kochkov replied
──────────────────────────────────────────
This project looks nice.
If I am an Emacs or Vi user, can I take advantage of an
LSP server?
Or, is this only for some new editors like Atom or VScode?
@UnixJunkie of course! That's the whole point of this tooling.
For Vim you can choose between:
• [Coc.nvim] - most powerful of all, but written in TypeScript and
heaviest of all
• [Ale] - pure VimL
• [vim-lsp] - pure VimL
• [LanguageClient-neovim] - written in Rust
• Some other implementations
I am not an Emacs expert, but there is amazing LSP integration too:
• [lsp-mode]
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/b/b8acd745527e801fef1eb3d4e8722d49c5c2ed1a.png>
[Coc.nvim] <https://github.com/neoclide/coc.nvim>
[Ale] <https://github.com/dense-analysis/ale>
[vim-lsp] <https://github.com/prabirshrestha/vim-lsp>
[LanguageClient-neovim]
<https://github.com/autozimu/LanguageClient-neovim>
[lsp-mode] <https://github.com/emacs-lsp/lsp-mode>
Pau Ruiz Safont said
────────────────────
Neovim 0.5.0 (now pre-released) has native LSP support as well:
<https://github.com/neovim/neovim/pull/11336>
Not sure how well integrated is it going to be with various plugins
([example])
[example] <https://github.com/Shougo/deoplete-lsp>
Anton Kochkov added
───────────────────
NeoVim 0.5.0 will also include the [tree-sitter] parser for syntax
highlighting, which will allow way better coloring. And tree-sitter
already has [OCaml grammar], so implementing semantics-aware syntax
highlighter will be easier. But I expect the support more or less
ready for external contributions only in 0.6.0, sadly. Integrating the
tool with something like [GitHub Semantic] (*Haskell alert*) will
greatly improve OCaml experience on GitHub too, see the [corresponding
issue].
[tree-sitter] <https://tree-sitter.github.io/tree-sitter/>
[OCaml grammar] <https://github.com/tree-sitter/tree-sitter-ocaml>
[GitHub Semantic] <https://github.com/github/semantic>
[corresponding issue] <https://github.com/github/semantic/issues/138>
Pieter Goetschalckx said
────────────────────────
The next step for Semantic support is documented [here], but I'm
working on some [improvements] of the tree-sitter parser first.
[here]
<https://github.com/tree-sitter/haskell-tree-sitter/blob/master/docs/codegen.md>
[improvements]
<https://github.com/tree-sitter/tree-sitter-ocaml/pull/36>
Carlos D'Agostino said
──────────────────────
For Emacs there is also `eglot': <https://github.com/joaotavora/eglot>
– As the README says, it's quite minimalist compared to `lsp-mode'.
Reproducible builds with OCaml / opam and MirageOS
══════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/reproducible-builds-with-ocaml-opam-and-mirageos/4877/1>
Hannes Mehnert announced
────────────────────────
I wrote up recent developments about reproducible builds with opam –
including some tooling <https://hannes.nqsb.io/Posts/ReproducibleOPAM>
Thanks to everyone involved in the effort to get OCaml and opam
deterministic
• Nov 2015 [I collected downstream patches and asked kindly to get
them upstream] (temporary flle names in binaries, timestamps)
• Dec 2017 [BUILD_PATH_PREFIX_MAP support] (and further patches for
that)
• Dec 2018 Paris summit [opam reproducibility] [MirageOS]
• [`orb'] tool for reproducibility testing (so much better than the
shell scripts I used in the meantime)
• Dec 2019 [Marrakesh summit]
The journey is not yet finished, we're in a pretty good shape, but
further testing and tooling is needed to expose the information "is my
library reproducible?" to OCaml developers.
I'm interested in feedback, please let us discuss this further here in
case you're interested. :D
[I collected downstream patches and asked kindly to get them upstream]
<https://github.com/ocaml/ocaml/issues/7037>
[BUILD_PATH_PREFIX_MAP support]
<https://github.com/ocaml/ocaml/pull/1515>
[opam reproducibility]
<https://reproducible-builds.org/events/paris2018/report/#Toc11410_331763073>
[MirageOS]
<https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>
[`orb'] <https://github.com/rjbou/orb>
[Marrakesh summit]
<https://reproducible-builds.org/events/Marrakesh2019/>
Anil Madhavapeddy added
───────────────────────
An absolutely amazing cross-layer effort; well done on pushing all
this through @hannes! I really enjoyed reading the minutes of the
Paris summit last year:
<https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>
the OCaml Software Foundation
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>
Continuing this thread, gasche announced
────────────────────────────────────────
A small report on the actions that we launched since my initial
posting.
(There was also some progress on the "enabling individual donations"
front, maybe something will be possible in the next few months. Don't
start holding your breath yet.)
• We are funding the "Leafs" research project in Lisbon to develop
teaching material for theoretical-computer-science courses (automata
and stuff) in OCaml, with interactive visualization components, some
of which will hopefully be integrated in the [Learn-OCaml] platform
over the course of 2020/2021.
• We provide funding for the [Gallium/Cambium] research team at INRIA
Paris (France), an active place for OCaml-related fundamental
research (some of the team members are also very active on the
implementation front, for example Xavier Leroy, Damien Doligez,
Florian @octachron Angeletti, and Sébastien Hinderer).
• We sponsor the [SWERC] programming contest for 2019-2020, and in
return the contest added OCaml to the list of available
languages. Most participants to these competitive-programming events
use C++, but we talked to past and active participants who said they
would be interested in using OCaml on some problems with more
symbolic computation.
• Over the course of the 4.10 release process, we are funding work by
@kit-ty-kate to have a wide look at the ecosystem and improve
compatibility with the upcoming release. (I believe that the
upstream PR [#9176] is a first result of this effort.)
• In reaction to the Discourse thread [Suggestions for OCaml
documentation], we are planning to fund further work by @sanette to
experiment with the HTML rendering of the OCaml manual, in
coordination with @octachron to try to upstream improvements when
reasonably possible.
• We got in touch with the [Owl] project to sponsor a development
sprint in 2020.
[Learn-OCaml] <http://ocaml-sf.org/learn-ocaml.html>
[Gallium/Cambium] <http://cambium.inria.fr/>
[SWERC] <https://swerc.eu/2019/about/>
[#9176] <https://github.com/ocaml/ocaml/pull/9176>
[Suggestions for OCaml documentation]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
[Owl]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>
soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/10>
Daniil Baturin announced
────────────────────────
Made a [1.7.0 release].
First improvement is that you now can pipe the content of any element
through any external program with `preprocess_element' widget (PR by
Martin Karlsson). For example, insert inline SVG versions of all
graphviz graphs from `<pre class="language-graphviz">' and also
highlight the Dot source itself with [highlight] (or any other tool of
your choice):
┌────
│ [widgets.graphviz-svg]
│ widget = 'preprocess_element'
│ selector = 'pre.language-graphviz'
│ command = 'dot -Tsvg'
│ action = 'insert_after'
│
│ [widgets.highlight]
│ after = "graphviz-svg"
│ widget = "preprocess_element"
│ selector = '*[class^="language-"]'
│ command = 'highlight -O html -f --syntax=$(echo $ATTR_CLASS | sed -e "s/language-//")'
│ action = "replace_content" # default
└────
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a4d8cc05d65634de0faf3c05b16e0de8d27a78a3.png>
Two other improvements are multiple index "views" and default value
option for custom index fields, like
┌────
│ [index.custom_fields]
│ category = { selector = "span#category", default = "Misc" }
└────
[1.7.0 release]
<https://soupault.neocities.org/blog/soupault-1.7.0-release>
[highlight] <http://andre-simon.de>
Release of owl-symbolic 0.1.0
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/1>
jrzhao42 announced
──────────────────
We are please to release [owl-symbolic 0.1.0]. It fully supports
defining a computation graph and running on accelerators (TPU/GPU) via
[ONNX] specification. It also aims to support converting an Owl
computation graph into symbolic representation and then to ONNX
model. The module also has some cool features like converting a
computation graph into LaTeX string, and then showing the result in a
web UI, etc.
We implements a full neural network module atop of it (the interface
of which is basically identical to that in Owl's core). It turns out
that the design of `owl-symbolic' is so nice that the DNN module only
has 179 LOC! You can easily define popular DNN architectures such as
Inception, ResNet, VGG, etc. just like in Owl.
This is still an on-going project and a lot remains to be
done. Despite its name, `owl-symbolic' does not do any useful computer
algebra (CAS) stuff at the moment, but CAS is indeed on our TODO.
For more information, please check out the related section in [Owl
tutorial book].
[owl-symbolic 0.1.0] <https://opam.ocaml.org/packages/owl-symbolic/>
[ONNX] <https://onnx.ai/>
[Owl tutorial book] <https://ocaml.xyz/owl_tutorials/symbolic.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 26832 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-17 8:52 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-12-17 8:52 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 6972 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 10 to 17,
2019.
Table of Contents
─────────────────
Is there a good way to encode linear types in OCaml?
Arch Linux installer written in OCaml
batteries batteries.2.11.0
Old CWN
Is there a good way to encode linear types in OCaml?
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/is-there-a-good-way-to-encode-linear-types-in-ocaml/1292/7>
Continuing this old thread, Konstantin Olkhovskiy said
──────────────────────────────────────────────────────
I've stumbled upon a library that implements linear types for OCaml,
using monads, lens and some ppx to make it more lightweight. Might be
of interest: <https://github.com/keigoi/linocaml>
Anton Kochkov added
───────────────────
It is the part of even more interesting system - [OCaml MPST]
(Multiparty Session Types) See the [slides].
[OCaml MPST] <https://github.com/keigoi/ocaml-mpst>
[slides]
<https://www.slideshare.net/keigoi/ocamlmpst-global-protocol-combinators-175519214>
Guillaume Munch-Maccagnoni then said
────────────────────────────────────
(The paper linked on that page is dated 2011/2014. In case anyone
wonders whether the authors have found a time machine in a barn to be
able to cite papers from 2018, there just seems to be an error in the
preparation. It is freshly published, and a PDF with correct dates is
available [here].)
[here]
<https://www.jstage.jst.go.jp/article/ipsjjip/27/0/27_431/_article>
Arch Linux installer written in OCaml
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/arch-linux-installer-written-in-ocaml/4388/12>
Darren announced
────────────────
I'm doing a short update here as Oali has seen some significant
changes. This update is also the last one here to avoid being too
annoying, and also since I won't be add too much new stuff to Oali in
foreseeable future.
Major changes since last time
• SaltStack files and script files (or profiles) now live in a
separate [repo]
• Oali accepts custom profile repo URL to facilitate using your own
SaltStack files without forking Oali itself
• Semi self-documentation
• Added mechanism to facilitate inline documentation inside
`oali.ml' itself
• The generated markdown doc is stored as [OALI_DOC] in repo, it
lists all the steps (or tasks) Oali does, along with descriptions
• Added LVM support
• Works with all 3 disk layouts, and encryption
• See [here] for details on added logical volumes
• Answer remembering of dialogues when appropriate
• Relatively static answers (e.g. hostname, whether to use
encryption, LVM) are stored in `oali_answers' directory, with a
JSON file for each task
• The "answer store" can be used in new session of Oali. The old
answer store is wiped accordingly if user changes their answer.
• Added SSH server setup and public key transfer code (ported from old
server bash script)
• See [here] for details
• Mainly useful for when you have (virtual) console access to live
CD/Oali install screen, and want to add needed public key to the
user's `.ssh/authorized_keys' via network instead of loading from
physical medium
I've used Oali to install in various configurations in past couple of
days, and have yet to notice major defects. That being said, exercise
caution as you would for installing an OS.
[repo] <https://github.com/darrenldl/oali-profiles>
[OALI_DOC] <https://github.com/darrenldl/oali/blob/master/OALI_DOC.md>
[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#20-set-up-disk>
[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#54-transfer-ssh-public-keys>
batteries batteries.2.11.0
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-batteries-batteries-2-11-0/4871/1>
UnixJunkie announced
────────────────────
The latest 2.x release of batteries is available in opam. OCaml
batteries included is a community maintained extended standard
library.
<https://github.com/ocaml-batteries-team/batteries-included>
The API documentation is hosted here:
<https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>
Here is the changelog:
┌────
│ v2.11.0 (minor release)
│
│ This minor release fixes a few bugs or interface mismatch with OCaml stdlib,
│ and is compatible with BER MetaOCaml.
│
│ This is the last planned release of the v2 series.
│ Next planned release (v3.0.0) will introduce some API changes.
│
│ Notable changes:
│
│ Add Unix.with_locked_file
│ #904
│ (Simon Cruanes, Cedric Cellier, review by Francois Berenger)
│
│ Build with -strict-sequence
│ #927
│ (Armaël Guéneau, review by Francois Berenger)
│
│ Add Legacy.Result for OCaml >= 4.8.0
│ #913
│ (Cedric Cellier, review by Francois Berenger)
│
│ Remove BatOo
│ #915
│ (Cedric Cellier, review by Francois Berenger)
│
│ Add BatFilename
│ #910
│ (Cedric Cellier, review by Francois Berenger)
│
│ Make batteries usable with BER MetaOCaml
│ #909
│ (Cedric Cellier, review by Francois Berenger and Gabriel Scherer)
│
│ Unix.sleepf is provided across all OCaml versions;
│ previously it was only for OCaml >= 4.03.0
│ #930
│ (Francois Berenger, review by Cedric Cellier)
└────
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].
If you also wish to receive it every week by mail, you may subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 18093 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-10 8:21 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-12-10 8:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 4145 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of December 03
to 10,
2019.
Table of Contents
─────────────────
Internships at Nomadic-labs
Interesting OCaml Articles
Next OUPS meetup December 18th 2019
Old CWN
Internships at Nomadic-labs
═══════════════════════════
Archive:
<https://discuss.ocaml.org/t/internship-at-nomadic-labs/4819>
Julien Tesson announced
───────────────────────
Nomadic Labs is currently looking for students with an interest
in
functional programming for internships that would take place in
our
offices in Paris or Grenoble.
We have a catalog of internships topics available at [1] The
internships topics are mainly addressed to master student but
other
well motivated application will be considered.
A first selection phase on received résumé will occur on
december
15th. Please contact us at contact@nomadic-labs.com by
specifying
which topics in the catalog you're interested in.
[1]: <https://nomadic-labs.com/download/internship_catalog.pdf>
Please, feel free to redistribute widely.
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/57>
james woodyatt announced
────────────────────────
Found on *Lobste.rs*: Mark Karpov writes yet another [Haskell
vs. OCaml] for old time's sake. I found it worth a read and a
mention
here.
p.s. He spends a bit of time in the intro lamenting the lack of
a
conventional Unicode string library for OCaml, and I feel that
pain
acutely, especially since I'm the author of an *unconventional*
one,
i.e. the [Ucs_text] module in my [Orsetto] project.
[Haskell vs. OCaml]
<https://markkarpov.com/post/haskell-vs-ocaml.html>
[Ucs_text]
<https://bitbucket.org/jhw/orsetto/src/default/src/ucs/ucs_text.mli>
[Orsetto] <https://bitbucket.org/jhw/orsetto>
Next OUPS meetup December 18th 2019
═══════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00009.html>
Bruno Bernardo announced
────────────────────────
The OUPS meetup is back. The next one will take place on
Wednesday,
December 18, 7pm at IRILL on the Jussieu campus. As usual, we
will
have a few talks, followed by pizzas and drinks.
The talks will be the following:
• Nathan Rebours, The future of OCaml-PPX
• Guillaume Claret, coq-of-ocaml
(<https://clarus.github.io/coq-of-ocaml/>)
And possibly a third talk. Contact us if you want to present
something, especially if you have a small project you want to
show in
10-15min.
To register, or for more information, go here:
<https://www.meetup.com/ocaml-paris/events/267019458>
*Registration is required! Access is not guaranteed after 7pm if
you're not registered.* (It also helps us to order the right
amount of
food.)
Access map:
IRILL - Université Pierre et Marie Curie (Paris VI)
Barre 15-16 1er étage
4 Place Jussieu
75005 Paris
<https://www.irill.org/pages/access.html>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 15372 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-03 15:42 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-12-03 15:42 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 22620 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 26
to
December 03, 2019.
Table of Contents
─────────────────
Irmin 2.0.0 release
How viable is delivering binaries linked to Cygwin to Windows
customers?
Dune 2.0.0
Advanced C binding using ocaml-ctypes and dune
Upcoming breaking change in Base/Core v0.14
CI/CD Pipelines: Monad, Arrow or Dart?
Use of functors to approximate F# statically resolved type
parameters
Old CWN
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/5>
Continuing this thread, samoht announced
────────────────────────────────────────
And there is now a follow-up blog post, explaining how to use
the new
GraphQL API available in Irmin2:
<https://tarides.com/blog/2019-11-27-introducing-irmin-graphql>.
How viable is delivering binaries linked to Cygwin to Windows
customers?
════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/how-viable-is-delivering-binaries-linked-to-cygwin-to-windows-customers/4775>
mbacarella asked
────────────────
I’m in the early stages of planning a deliverable binary product
that
will run on Linux, Mac and Windows.
My brief sniff of the air around the OCaml ecosystem says I
should
expect to target Cygwin to get Windows going (although there’s
impressive work to get native Windows stuff done that can become
the
preferred approach in a few years).
My experience using Cygwin as an operating environment is that
it’s
pretty darn sluggish compared to Linux on the same computer.
Why is this? There’s an anecdote that says Cygwin can only fork
at
about 30-50x a second on Windows, due to how it has to adapt it
to
work within Windows’ task spawning model. (For contrast, Linux
can
achieve thousands of forks per second if you play around with
it).
I understand from another product developer that when they build
binaries to deliver to Windows/Cygwin, they actually
cross-compile on
Linux because of how slowly the toolchain runs on Cygwin.
That sounds like bad news if you want to do UNIXy things, but
for a
single standalone application this might not be so bad? I assume
if I
ship a deliverable to Windows/Cygwin, the end user may enjoy
good
performance, so long as I’m not spawning tons of processes or
relying
on fork for multi-programming. Is this a safe assumptions?
Any other gotchas when it comes to OCaml on Cygwin w.r.t.
performance?
The app pretty much has real-time gaming requirements (though
it’s not
a game so can side-step worrying about access to GPUs and
what-not). Stated another way, although my application will
depend on
the POSIX layer offered by Cygwin, I expect it not to crunch
POSIX
related stuff in the main loop.
How has your experience gone?
John Whitington replied
───────────────────────
I have been shipping commercial binaries for Linux (32 and 64
bit),
Windows (32 and 64bit) and OS X for years. For example:
<https://github.com/coherentgraphics/cpdf-binaries>
And even static or shared libraries in binary form:
<https://github.com/coherentgraphics/cpdflib-binary>
On OS X, you need to use MACOSX_DEPLOYMENT_TARGET or similar to
make
sure your builds will run on older systems. And, in fact, you
need to
use MACOSX_DEPLOYMENT_TARGET when asking OPAM to compile the
OCaml
compiler itself. And, you will need to deal with codesigning and
notarization. But it’s all doable.
For linux, you may need to build under older linux versions, to
make
sure that the glibc in use is old enough. This is not an
ocaml-specific problem. I have a 64 bit and 32 bit VM with
old-ish
glibc versions for this purpose.
Under Windows, there are no such backward-compatibility
problems. I
use the new OCaml for windows system, which comes with OPAM, and
is
mingw-based. No cygwin remains in the final binary.
For more obscure systems (AIX, HPUX, Sparc etc) customers
compile from
source (with help from me). Not once in more than ten years has
anyone
cared that it was written in OCaml.
dbuenzli also replied
─────────────────────
remember that on the Windows native port, the Unix module
distributed
with OCaml is your POSIX compatibility layer. There are a few
entry
points to avoid though, the list is at the bottom of [this
page].
[this page]
<https://caml.inria.fr/pub/docs/manual-ocaml/libunix.html>
nojb also replied
─────────────────
At LexiFi our main application is developed and shipped on
Windows. We
use the msvc port of OCaml. This means that you need Cygwin to
develop, but the resulting application is fully native and does
not
depend on the Cygwin DLL. As @dbuenzli mentioned, the Unix
module *is*
the POSIX compatibility layer.
Compilation speed is slower on Windows because process creation
is
slower on Windows as a general rule, but it is manageable (our
application has around 2000 modules + Js_of_ocaml + C bindings +
C#
component).
We don’t have any issues with runtime performance. The `Unix'
library
mentioned above implements Windows support directly without
going
through any compatibility layer and is quite efficient.
BikalGurung also replied
────────────────────────
There is an editor being built in ocaml/reasonml which currently
targets windows, linux and macos -
<https://github.com/onivim/oni2>. However, the binary is native
windows rather than cygwin derivative. So if you don’t have to
use
cygwin dependencies then native windows binary could be the way
to go.
Also esy - <https://github.com/esy/esy> makes developing
ocaml/reasonml on windows viable.
keleshev also replied
─────────────────────
*TLDR*: Install the [Mingw port of OCaml 4], freely use most
opam
libraries, and compile to native Windows binaries, without
licensing
issues.
I recommend you read the “Release notes for Windows”:
<https://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc>
To summarise, there are three Windows ports:
• Native Microsoft port,
• Native Mingw port,
• Cygwin port.
All three require Cygwin for development purposes. I recommend
using
the Native Mingw, as:
• it *doesn’t* require Visual Studio (it uses a mingw fork of
GCC that
“cross-compiles” native Windows executables),
• it *doesn’t* rely on the dreaded cygwin.dll
• it has good opam support with opam-repository-mingw:
<https://github.com/fdopen/opam-repository-mingw>
• it has a convenient installer:
<https://fdopen.github.io/opam-repository-mingw/> 5.
To contrast, Native Microsoft requires Visual Studio, and
doesn’t have
opam. You can still vendor pure OCaml packages, but as soon as
you
want to use some C bindings you’re in trouble, because of the
“minor”
differences between Visual C and GCC. And everything assumes GCC
nowadays.
Cygwin port is the one I don’t have experience with, but
re-reading
the “Release notes for Windows” above it strikes me that it
mentions
that Cygwin was re-licensed from GPL to LGPL with static linking
exception. So it looks like the Cygwin port could be viable for
commercial use, but I never tried to statically linked
`cygwin.dll',
and I’m not sure what are the benefits of Cygwin port over the
Mingw
port.
[Mingw port of OCaml 4]
<https://fdopen.github.io/opam-repository-mingw/>
dmbaturin also replied
──────────────────────
With [soupault 4], I decided to ship prebuilt binaries for all
platforms including Windows. Mostly to see if I can, all its
users I
know of are on UNIX-like systems and know how to build from
source,
but that’s beside the point. :wink:
I can confirm everything @keleshev says: fdopen’s package just
works,
opam works exactly like it does on UNIX, pure OCaml libraries
are
trivial to install, and the binaries don’t depend on cygwin.
Note
that “opam switch create” also just works, you can install
either
MinGW or MSVC compiler versions as opam switches. I only ever
start
the Windows VM to make release builds, and the workflow is
exactly the
same as on Linux where I’m actually writing code.
My only obstacle on that path was that FileUtils lost its
Windows
compatibility, but I wanted to use it, so I worked with
@gildor478 to
make it cross-platform again. Uncovered a bug in the
implementation of
Unix.utimes in the process, but it’s hardly a commonly used
function.
You can also setup AppVeyor builds. It’s not as simple as I wish
it
would be, but there are projects doing it that you can steal the
setup
from.
There’s also opam-cross-windows, but it’s very incomplete and
needs
work to be practical. There are no big obstacles, it just needs
work. While files in opam-repository-mingw are normally
identical to
the default opam repository, the cross one needs small
adjustments in
every package to specify the toolchain to use, so the required
work is
mostly a lot of trivial but manual actions. I hope eventually it
reaches parity with fdopen’s one and we’ll be able to easily
build for
Windows without ever touching Windows.
As of static Linux builds, @JohnWhitington’s approach can work,
but
there’s a better option if you don’t need anything from glibc
specifically and don’t link against any C libs: build statically
with
musl. There’s a `+musl+static+flambda' compiler flavour. You
need musl
and gcc-musl to install it, but after that, just build with
`-ccopt
-static' flag and you get a binary that doesn’t depend on
anything.
[soupault 4] <https://soupault.neocities.org/>
Dune 2.0.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
rgrinberg announced
───────────────────
On behalf of the dune team, I’m delighted to announce the
release of
dune 2.0. This release is the culmination of 4 months of hard
work by
the dune team and contains new features, bug fixes, and
performance
improvements . Here’s a selection of new features that I
personally
find interesting:
• New boostrap procedure that works in low memory environments
• (`deprecated_library_name' ..) stanza to properly deprecate
old
library names
• (`foreign_library' ..) stanza to define C/C++ libraries.
• C stubs directly in OCaml executables
Refer to the change log for an exhaustive list.
We strive for a good out of the box experience that requires no
configuration, so we’ve also tweaked a few defaults. In
particular, `$
dune build' will now build `@all' instead of `@install', and
ocamlformat rules are setup by default.
Lastly, dune 2.0 sheds all the legacy related to jbuilder and
will no
longer build jbuilder projects. This change is necessary to ease
maintenance and make it easier to add new features down the
line. There are a few other minor breaking changes. Refer to the
change log for the full list. We apologize in advance for any
convenience this might cause.
[Changelog]
[Changelog] <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>
Advanced C binding using ocaml-ctypes and dune
══════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/advanced-c-binding-using-ocaml-ctypes-and-dune/4805>
toots announced
───────────────
I worked on a socket.h binding last summer and had a great
experience
integrating ocaml-ctypes with dune, I thought that might be of
interest to other developers so I wrote about it:
<https://medium.com/@romain.beauxis/advanced-c-binding-using-ocaml-ctypes-and-dune-cc3f4cbab302>
rgrinberg replied
─────────────────
This is a good article. I encourage anyone who writes C bindings
with
ctypes to study it carefully.
A little bit of advice to shorten your dune files:
┌────
│ (deps (:gen ./gen_constants_c.exe))
└────
This line isn’t necessary. Dune is smart enough to know that
running a
binary in a rule incurs a dependency on it.
dune has a truly amazing [support for cross-compiling],
which we do not cover here, but, unfortunately, its
primitives for building and executing binaries do not yet
cover this use case.
Indeed, we don’t have any primitives for running binaries on the
target platform. Perhaps we should add some. However, we do in
fact
have some features in dune to solve this concrete cross
compilation
problem. As far as I understand, the goal is to obtain some
compile
time values such as #define constants and field offsets for the
target
platform. This does not in fact require to run anything on the
cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end result is
that
these configurator scripts are completely compatible with cross
compilation.
Perhaps this could be generalized to work with ctypes generators
as
well?
Funny bit of trivia: The hack in configurator required to do
this is
in fact something I extracted from ctypes itself. The original
author
is [whitequark], who in turn wrote it to make ctypes itself
amendable
to cross compilation.
[support for cross-compiling]
<https://dune.readthedocs.io/en/latest/cross-compilation.html>
[whitequark] <https://github.com/whitequark>
emillon then added
──────────────────
This does not in fact require to run anything on the cross
compilation target. In configurator, we have a primitive
`C_define.import' to extract this information. The end
result is that these configurator scripts are completely
compatible with cross compilation.
If anybody wants to know more about this bit, I wrote an article
about
this last year:
<https://dune.build/blog/configurator-constants/>
Upcoming breaking change in Base/Core v0.14
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/upcoming-breaking-change-in-base-core-v0-14/4806>
bcc32 announced
───────────────
We’re changing functions in Base that used to use the
polymorphic
variant type `[ `Fst of 'a | `Snd of 'b ]' to use `('a, 'b)
Either.t'
instead. As well as enabling the use of all of the functions in
the
Either module, this makes the functions consistent with other
functions that already use `Either.t', (currently just
`Set.symmetric_diff')
The following functions’ types will change:
• `Result.ok_fst'
• `List.partition_map'
• `Map.partition_map', `Map.partition_mapi'
• `Hashtbl.partition_map', `Hashtbl.partition_mapi'
The type of List.partition3_map will not change:
┌────
│ val partition3_map
│ : 'a t
│ -> f:('a -> [ `Fst of 'b | `Snd of 'c | `Trd of 'd ])
│ -> 'b t * 'c t * 'd t
└────
We don’t have a generic ternary variant, and it doesn’t seem
worth it
to mint one just for this purpose.
Since this change is pretty straightforward, we expect that a
simple
find/replace will be sufficient to update any affected call
sites.
CI/CD Pipelines: Monad, Arrow or Dart?
══════════════════════════════════════
Archive:
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Thomas Leonard announced
────────────────────────
In this post I describe three approaches to building a language
for
writing CI/CD pipelines. My first attempt used a monad, but this
prevented static analysis of the pipelines. I then tried using
an
arrow, but found the syntax very difficult to use. Finally, I
ended up
using a light-weight alternative to arrows that I will refer to
here
as a dart (I don’t know if this has a name already). This allows
for
static analysis like an arrow, but has a syntax even simpler
than a
monad.
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
Use of functors to approximate F# statically resolved type
parameters
═════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/use-of-functors-to-approximate-f-statically-resolved-type-parameters/4782>
cmxa asked
──────────
I am learning OCaml coming from F#. In F#, to calculate the
average of
an array whose element type supports addition and division, one
can
write
┌────
│ let inline average (arr: 'a[]) : 'a
│ when ^a : (static member DivideByInt : ^a * int -> ^a)
│ and ^a : (static member (+) : ^a * ^a -> ^a)
│ and ^a : (static member Zero : ^a)
│ =
│ if Array.length arr = 0 then
(LanguagePrimitives.GenericZero) else
│ LanguagePrimitives.DivideByInt (Array.fold (+)
(LanguagePrimitives.GenericZero) arr) (Array.length arr)
└────
My understanding is that in OCaml, one would have a module type
like
so:
┌────
│ module type Averagable = sig
│ type 'a t
│
│ val divide_by_int : 'a -> int -> 'a
│ val plus : 'a -> 'a -> 'a
│ val zero : 'a
│ end
└────
My question is how the corresponding function would be written:
┌────
│ let average arr =
│ ???
└────
smolkaj replied
───────────────
First, `Averagable' should look like this:
┌────
│ module type Averagable = sig
│ type t
│ val divide_by_int : t -> int -> t
│ val plus : t -> t -> t
│ val zero : t
│ end
└────
Then average will look something like this:
┌────
│ let average (type t) (module A : Averagable with type t = t)
(arr : t array) : t =
│ Array.fold ~init:A.zero ~f:A.plus arr
└────
(The code above uses Jane Street’s Base/Core library.)
ivg then added
──────────────
While @smolkaj’s answer is a correct and direct implementation
of your
F# code, it might be nicer if your code can interplay with
existing
abstractions in the OCaml infrastructure. For example,
┌────
│ open Base
│
│ let average (type a) (module T : Floatable.S with type t = a)
xs =
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
and now it could be used with any existing numeric data in
Base/Core
┌────
│ average (module Int) [|1;2;3;4|];;
│ - : Base.Float.t = 2.5
└────
and even adapted to non-numbers,
┌────
│ let average_length = average (module struct
│ include String
│ let to_float x = Float.of_int (String.length x)
│ let of_float _ = assert false
│ end)
└────
The latter example shows that we requested more interface than
need, a
cost that we have to pay for using an existing definition. In
cases
when it matters, you can specify the specific interface, e.g.,
┌────
│ module type Floatable = sig
│ type t
│ val to_float : t -> float
│ end
│
│ let average (type a) (module T : Floatable with type t = a) xs
=
│ Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
│ Float.of_int (Array.length xs)
└────
But we reached the point where using first class modules is
totally
unnecessary. Our interface has only one function, so the
following
definition of average, is much more natural
┌────
│ let average xs ~f =
│ Array.fold ~init:0. ~f:(fun s x -> s +. f x) xs /.
│ Float.of_int (Array.length xs)
└────
it has type `'a array -> f:('a -> float) -> float' and computes
an
average of `f x_i' for all elements in the array.
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 41191 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-26 8:33 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-11-26 8:33 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 28861 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 19
to 26,
2019.
Table of Contents
─────────────────
tiny_httpd 0.1
printbox.0.3
v0.13 release of Jane Street packages
opam2nix (v1)
GitHub Actions for OCaml / opam now available
OCurrent 0.1 (CI/CD pipeline eDSL)
New pages for OCaml API
Irmin 2.0.0 release
Tail cascade: a new indentation style for some OCaml constructs
Old CWN
tiny_httpd 0.1
══════════════
Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727/1>
Simon Cruanes announced
───────────────────────
Hello and good morning, I'm pleased to announce that
[tiny_httpd] 0.1
has been released and is on opam.
The goal is to emulate python's standard `http.server' by
providing a
0-dependencies, minimalist, simple HTTP server for embedding in
applications that are not primarily a website, with very basic
routing
(thanks to `Scanf'). A binary `http_of_dir' is also distributed
and
can be used to serve a directory, with optional upload of files.
[tiny_httpd] <https://github.com/c-cube/tiny_httpd>
printbox.0.3
════════════
Archive: <https://discuss.ocaml.org/t/ann-printbox-0-3/4731/1>
Simon Cruanes announced
───────────────────────
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/8/8e7c55c5ab69c12f53a7862d2f84dd6e0cfc0dc0.png>
┌────
│ let b =
│ let open PrintBox in
│ PrintBox_unicode.setup();
│ frame @@ grid_l [
│ [text "subject"; text_with_style Style.bold "announce:
printbox 0.3"];
│ [text "explanation";
│ frame @@ text {|PrintBox is a library for rendering nested
tables,
│ trees, and similar structures in monospace text or
HTML.|}];
│ [text "github";
│ text_with_style Style.(bg_color Blue)
"https://github.com/c-cube/printbox/releases/tag/0.3"];
│ [text "contributors";
│ vlist_map (text_with_style Style.(fg_color Green))
["Simon"; "Guillaume"; "Matt"]];
│ [text "dependencies";
│ tree empty
│ [tree (text "mandatory")
│ [text "dune"; text "bytes"];
│ tree (text "optional")
│ [text "uutf"; text "uucp"; text "tyxml"]]];
│ [text "expected reaction"; text "🎉"];
│ ]
│
│ let () = print_endline @@ PrintBox_text.to_string b
└────
([actual link to the release])
[actual link to the release]
<https://github.com/c-cube/printbox/releases/tag/0.3>
v0.13 release of Jane Street packages
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735/1>
Xavier Clerc announced
──────────────────────
We are pleased to announce the v0.13 release of Jane Street
packages!
This release comes with 14 new packages, and a number of fixes
and
enhancements. The documentation for this release is available on
our
website:
<https://ocaml.janestreet.com/ocaml-core/v0.13/doc/>
The remainder of this mail highlights the main changes since the
v0.12
release; we hope it will be useful to developers in the process
of
migrating to the new version. A comprehensive changelog is
available
at the end.
Notable changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Changed `Base', `Core_kernel', and `Core' functions to raise
`Not_found_s' instead of `Not_found'. `Hashtbl.find_exn' and
`Map.find_exn' now include the key in their error message.
• Changed `Core' and `Core_kernel' to export `int' comparison
rather
than polymorphic comparison.
• Removed the "robust" float comparison operators (`>.', `=.',
…)
from the default namespace.
• Replaced `sexp_*' types (`sexp_list', `sexp_option',
`sexp_opaque',
…) with preprocessor attributes (`[@sexp.list]',
`[@sexp.option]',
`[@sexp.opaque]', …).
• Changed `let%map' syntax from `let%map.Foo.Let_syntax' to
`let%map.Foo'.
• Added to `match%optional' support for specifying a path, so
you can
write `match%optional.Foo foo_option' rather than `let open
Foo.Optional_syntax in match%optional foo_option'.
• Improved `Base.Backtrace' so that it enables recording of
backtraces
in more situations, specifically when `OCAMLRUNPARAM' is
defined but
doesn't mention the backtrace flag, `b'.
• Added javascript support for `Zarith', `Bigint', `Bignum', and
`Bigdecimal'.
• Changed `Hashtbl.create''s default `size' from 128 to 0.
• Changed `Core_kernel.Command' so that all commands accept
double
dash flags: `--help', `--version', and `--build-info'.
New packages
╌╌╌╌╌╌╌╌╌╌╌╌
• async_udp (<https://github.com/janestreet/async_udp>): UDP
support
for Async.
• async_websocket
(<https://github.com/janestreet/async_websocket>): A
library that implements the websocket protocol on top of
Async.
• bonsai (<https://github.com/janestreet/bonsai>): A library for
building dynamic webapps, using Js_of_ocaml.
• postgres_async
(<https://github.com/janestreet/postgres_async>):
OCaml/async implementation of the postgres protocol (i.e.,
does not
use C-bindings to libpq).
• ppx_cold (<https://github.com/janestreet/ppx_cold>): Expands
`[@cold]' into `[@inline never][@specialise never][@local
never]'.
• ppx_pattern_bind
(<https://github.com/janestreet/ppx_pattern_bind>):
A ppx for writing fast incremental bind nodes in a pattern
match.
• ppx_python (<https://github.com/janestreet/ppx_python>):
`[@@deriving]' plugin to generate Python conversion functions.
• ppx_yojson_conv
(<https://github.com/janestreet/ppx_yojson_conv>):
`[@@deriving]' plugin to generate Yojson conversion functions.
• ppx_yojson_conv_lib
(<https://github.com/janestreet/ppx_yojson_conv_lib>): Runtime
lib
for `ppx_yojson_conv'.
• pythonlib (<https://github.com/janestreet/pythonlib>): A
library to
help writing wrappers around OCaml code for python.
• sexp_select (<https://github.com/janestreet/sexp_select>): A
library
to use CSS-style selectors to traverse sexp trees.
• timezone (<https://github.com/janestreet/timezone>): Time-zone
handling.
• toplevel_backend
(<https://github.com/janestreet/toplevel_backend>):
Shared backend for setting up toplevels.
• zarith_stubs_js
(<https://github.com/janestreet/zarith_stubs_js>):
Javascript stubs for the Zarith library.
Deprecations / Removals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
`Async_kernel':
• Deprecated monadic `ignore' functions in favor of `ignore_m'.
`Base':
• Deleted `Array.replace' and `replace_all' functions, which
have been
deprecated since before the last public release.
• Deprecated `Result.ok_unit'; use `Ok ()'.
• Removed the `Monad' and `Applicative' interfaces' `all_ignore'
function; it was previously deprecated and replaced by
`all_unit'.
• Removed `List.dedup', which has been deprecated since 2017-04.
• Removed `String' mutation functions, which have been
deprecated in
favor of `Bytes' since 2017-10.
• Deprecated `Array.truncate', `Obj_array.unsafe_truncate', and
`Uniform_array.unsafe_truncate'.
• Deprecated `Sys.argv', which has been superseded by
`get_argv',
which is a function, reflecting the fact that `argv' can
change (as
of OCaml 4.09).
`Core_kernel':
• Removed `Core_kernel.Std', which had been deprecated for a
year.
• Deprecated type `Command.Spec.param' in favor of
`Command.Param.t'.
• Removed `Hashtbl' functions that had been deprecated for
years.
• Removed `Float.to_string_round_trippable', which has been
deprecated
in favor of `to_string' since 2017-04.
• Deprecated `Fqueue' functions where one should use `Fdeque'
instead:
`bot', `bot_exn', and `enqueue_top'.
• Deleted `Bus.unsubscribes', which will be obviated by a
performance
improvement to `Bus.unsubscribe'.
`Timing_wheel':
• Removed the `alarm_upper_bound' function, which has been
deprecated
for 6 months, and superseded by `max_allowed_alarm_time'.
Moves
╌╌╌╌╌
`Core_kernel':
• Moved `Bounded_int_table' to a standalone library.
• Moved the `Pool' and `Tuple_type' modules to a standalone
library,
`Tuple_pool'.
`Async_unix':
• Moved `Unix.Fd.replace' into a `Private' submodule.
Changelog
╌╌╌╌╌╌╌╌╌
Please visit
<https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>
opam2nix (v1)
═════════════
Archive: <https://discuss.ocaml.org/t/ann-opam2nix-v1/4741/1>
Tim Cuthbertson announced
─────────────────────────
Anouncing opam2nix (v1)
[opam2nix] generates [nix] expressions from the [opam] OCaml
package
repository. It works similarly to [bundix], [node2nix], etc:
You run an (impure) command to resolve all transitive dependency
versions using the current opam repository, generating a .nix
file
that locks down the exact package sources and versions. Then
this file
can be imported to provide `buildInputs' for building your ocaml
project in nix.
*What is nix and why would I care?* Well, that's a long story
but the
headline benefits of nix are:
• reproducible builds (if it builds for me, it builds for you)
• stateless (you don't set up switches and then install
packages, each
expression specifies everything it needs, and anything you
don't
have is fetched/built on demand)
• language agnostic (takes care of non-ocaml dependencies)
It's sadly not a shallow learning curve, but those benefits are
hard
to find elsewhere, so I obviously think it's worthwhile. So if
you use
nix (or would like to), please give it a try and provide
feedback. I'll (slowly) start working on upstreaming it into
nixpkgs.
[opam2nix] <https://github.com/timbertson/opam2nix>
[nix] <https://nixos.org/>
[opam] <https://opam.ocaml.org/>
[bundix] <https://github.com/nix-community/bundix>
[node2nix] <https://github.com/svanderburg/node2nix>
GitHub Actions for OCaml / opam now available
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745/1>
Anil Madhavapeddy announced
───────────────────────────
I was in the [GitHub Actions] beta program and forward ported my
code
to the latest version that just went public. It's a pretty
simple way
to get your OCaml code tested on Linux, macOS and Windows,
without
requiring an external CI service. The action attempts to
provide a
homogenous interface across all three operating systems, so
invoking
'opam' from subsequent actions should "just work".
You can find it here:
• In the GitHub Marketplace at
<https://github.com/marketplace/actions/setup-ocaml>
• Source code on <https://github.com/avsm/setup-ocaml/>
• Hello World usage on
<https://github.com/avsm/hello-world-action-ocaml>
• Usage in ocaml-yaml:
•
<https://github.com/avsm/ocaml-yaml/blob/master/.github/workflows/test.yml>
• An [example ocaml-yaml run]
This should be considered fairly experimental as GH Actions is
so new.
If you do use it, then consider [updating this issue with your
usage].
It does not current supporting caching yet, but is pretty fast
to
bootstrap (~4minutes).
It also doesn't have any higher level purpose other than to set
up an
opam environment, since most of the additional functionality
such as
revdeps testing is planned for addition to the [ocurrent DSL].
Nevertheless, this GH feature will hopefully be useful for
smaller
projects without a lot of computational requirements. Let me
know how
it goes!
Windows is currently supported through @fdopen's excellent fork
that
uses Cygwin. As Windows support is being mainlined into opam
itself
at the moment, I'm hoping that we will gradually move over to
that.
That should eventually remove the need for two separate
opam-repositories, so I won't be adding any features that are
Linux or
macOS-specific and do not work on the Cygwin version.
[GitHub Actions] <https://github.com/actions>
[example ocaml-yaml run]
<https://github.com/avsm/ocaml-yaml/runs/314055554>
[updating this issue with your usage]
<https://github.com/avsm/setup-ocaml/issues/4>
[ocurrent DSL]
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/2>
OCurrent 0.1 (CI/CD pipeline eDSL)
══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/1>
Thomas Leonard announced
────────────────────────
[OCurrent] 0.1 has just been released to opam-repository.
OCurrent is an OCaml eDSL intended for writing build/test/deploy
pipelines. It is being used as the engine for [ocaml-ci] and the
[docker-base-images] builder (used to build the OCaml Docker
images,
such as `ocurrent/opam:alpine-3.10-ocaml-4.08'). Other good uses
might
be building and redeploying a Docker service or a unikernel
whenever
its source repository changes. It can be run locally as a single
Unix
process.
An OCurrent pipeline is written as an OCaml program, but the
OCurrent
engine ensures that it is kept up-to-date by re-running stages
when
their inputs change. A web UI is available so you can view your
pipeline and see its current state.
OCurrent can statically analyse the pipelines before they have
run,
allowing it to run steps in parallel automatically and to
display the
whole pipeline. It does this using a light-weight alternative to
arrows, which doesn't require programming in an awkward
point-free
style. See [CI/CD Pipelines: Monad, Arrow or Dart?] for more
about
that.
The basic functionality can be extended using "plugins" (just
normal
OCaml libraries). Plugins are available for interacting with
Docker,
Git, GitHub and Slack. These are in separate packages
(e.g. `current_github') to avoid having the base package pull in
too
many dependencies).
There is also an optional Cap'n Proto RPC interface, in the
`current_rpc' opam package. This is used, for example, by
[citty] to
provide a TTY interface to ocaml-ci.
[The OCurrent wiki] contains examples, and documentation on the
various plugins.
Here's an example pipeline (from the base image builder):
<https://roscidus.com/blog/images/cicd/docker-base-images-thumb.png>
[OCurrent] <https://github.com/ocurrent/ocurrent>
[ocaml-ci] <https://github.com/ocurrent/ocaml-ci/>
[docker-base-images]
<https://github.com/ocurrent/docker-base-images>
[CI/CD Pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>
[citty] <https://github.com/ocurrent/citty>
[The OCurrent wiki] <https://github.com/ocurrent/ocurrent/wiki>
Anil Madhavapeddy then added
────────────────────────────
For those curious about the relation to the existing CI used in
opam-repository, then it is no coincidence that @talex5 is the
author
of both :-)
This DSL is the next iteration of the [datakit-ci], but
specialised to
be faster and simpler for extending with OCaml and more complex
workflows that our OCaml Platform tools need these days (like
ocamlformat linting, or dune expect promotion, or odoc
cross-referenced doc generation). We are planning a smooth
migration
next year over to the new system, but wanted to release this
early to
show you some of the pieces going into this new iteration. I am
particularly excited about the new tty-based interface that
saves an
awful lot of clicking around on web UIs for CI results…
[datakit-ci] <https://github.com/moby/datakit>
New pages for OCaml API
═══════════════════════
Archive:
<https://discuss.ocaml.org/t/new-pages-for-ocaml-api/4720/13>
Continuing this thread, sanette announced
─────────────────────────────────────────
I have uploaded a new version (same link
<https://sanette.github.io/ocaml-api/>)
• background color for links in the TOC @Maelan
• more indentation for value descriptions @Maelan, @grayswandyr
• word wrapping long `<pre>' codes @grayswandyr
• type table: remove `(*' and `*)', give more space to code wrt
comments, diminish comment's color @grayswandyr
searching is not ready yet… please wait suggestions for dark
theme
welcome
sanette later added
───────────────────
I have just uploaded a new version with a basic search engine.
• for each page, you can search values/modules
• in the general index page, the search includes also the
descriptions
• search results are ranked by relevance
the downside is that each page now comes with an index of about
570Kb
in the form of an index.js file. I'm kind of hoping that the
browser
will cache this, but I'm not sure. It would be maybe better to
only
load the index file on demand.
Irmin 2.0.0 release
═══════════════════
Archive:
<https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/1>
Thomas Gazagnaire announced
───────────────────────────
On behalf of the Irmin development team, I am very happy to
announce
the release of Irmin 2.0.0, a major release of the Git-like
distributed branching and storage substrate that underpins
[MirageOS]. We began the release process for all the components
that
make up Irmin [back in May 2019], and there have been close to
1000
commits since Irmin 1.4.0 released back in June 2018. To
celebrate
this milestone, we have a new logo and opened a dedicated
website:
[irmin.org].
More details here:
<https://tarides.com/blog/2019-11-21-irmin-v2>
[MirageOS] <https://mirage.io/>
[back in May 2019]
<https://tarides.com/blog/2019-05-13-on-the-road-to-irmin-v2>
[irmin.org] <https://irmin.org/>
Tail cascade: a new indentation style for some OCaml constructs
═══════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/tail-cascade-a-new-indentation-style-for-some-ocaml-constructs/4736/1>
gasche announced
────────────────
I recently decided to change my indentation style for certain
OCaml
constructs in a way that I'm going to describe below. I just
coined a
name for this approach, "tail cascade". I'm creating this topic
to
convince everyone that this is a cool idea you should adopt as
well. Or at least tolerate it when you review other people's
code.
Problem
╌╌╌╌╌╌╌
Programs that heavily use `match' often see a shift to the right
due
to nested indentation.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | Some z ->
│ ...
└────
Another problem with this style is that it suffers from the
"dangling
bar" issue: if you try to add a new case for one of the exterior
`match', it is parsed as belonging to the innermost `match'.
People
have been recommending (rightly) to use `begin match .. end' for
all
nested match constructs to avoid this issue.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ begin match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ begin match f y with
│ | None -> ...
│ | Some z ->
│ ...
│ end
│ (* now this is safe *)
│ | FooBlah -> ...
│ end
└────
But still the unpleasant shift to the right remains.
Proposal: cascading tail case
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We should in general use `begin match .. end' for nested
matches. But
the "cascading tail case" proposal is to *not* do it for the
*last*
case of the pattern-matching, and instead *de-indent* (dedent)
this
last case – tail case.
┌────
│ match foo with
│ | Foo -> ...
│ | Bar x ->
│ match bar x with
│ | FooBar -> ...
│ | Blah y ->
│ match f y with
│ | None -> ...
│ | Some z ->
│ ...
└────
Note that with this indentation style, the "dangling match"
problem is
also avoided: unlike with the original, non `end'-protected
program,
the indentation makes it immediately obvious that any further
case
will be attached to the innermost match, and not any of the
exterior
ones.
A program using this "cascading tail" approach should always use
`begin match .. end' for nested matches, except for a nested
match
returned within the last branch of an outer match, which can
(optionally) be dedented instead.
The choice to dedent the last case corresponds to encouraging a
sequential reading of the program, where the other cases are
"auxiliary cases" checked first and dispatched quickly, and the
last
case is the "main part" where the "rest" of the logic of the
program
lies. This pattern is typical of nested pattern-matching on the
`option' or `result' type for example:
┌────
│ match foo x with
│ | Error err ->
│ fail_foo_error err
│ | Ok y ->
│ match bar y with
│ | Error err ->
│ fail_bar_error err
│ | Ok () ->
│ ...
└────
Remark: it is *not* always the case that the `Error' constructor
is
the auxiliary case, and the `Ok' constructor is the main case;
sometimes we implement fallback logic like "if `foo' work then
we are
good, but otherwise we have to do this and that", and the error
case
is the most salient (and longer) part of the program logic. I
would
recommend being mindful, when you write code, of whether there
is a
most convincing way to "sequentialize" it (distinguish auxiliary
and
main/tail case), and avoid using cascading tails when there is
no
clear sequentialization choice.
Remark: some cases of tail cascades can be linearized by using a
good
definition of "bind" and a monadic style. This tends to be very
limited however: it fixes one of the constructors to always be
the
"tail" constructor (always `Some', always `Ok'), and it only
works
when the handling of the other constructors is very homogeneous
(typically: return directly). In real code, many situations
occur
where the monadic style doesn't fit the problem, but tail
cascade does
help writing a readable program.
Generalization: tail cascade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
While I have never seen cascading tail cases in real-world OCaml
code
before (I'm happy to be given pointers; I think that the idea is
not
new, but I'm not aware of previous attempts to give it a catchy
name
and spread the cascade love), this is in fact a new (to me)
instance
of a common technique that is used for other OCaml constructs:
┌────
│ if foo x then ...
│ else if bar x then ...
│ else ... (* this `tail else` was dedented *)
│
│ let x = foo in
│ let y = bar in (* this `tail let` was dedented *)
│ ... (* and the rest as well *)
│
│ bind foo @@ fun x ->
│ bind bar @@ fun y -> (* this "tail function body" was dedented
*)
│ ... (* and the rest as well *)
└────
I would call "tail cascade" (or maybe: "cascading tail") the
idea of
dedenting the "rest" of an OCaml expression (compared to a
strict
tree-nesting-based approach) when it morally describes the
"rest" of
the expression. I use the name "tail" because those expressions
are
almost always in tail-position in the sense of tail-calls.
This general approach legitimizes some styles that I have seen,
and
sometimes used, in the wild, while at the same time considering
that I
may have been doing something improper, for example:
┌────
│ if foo then blah else
│ ... (* dedented *)
│
│
│ Fun.protect
│ ~finally:(...)
│ @@ fun () ->
│ ... (* dedented *)
│
│
│ try simple_approach with exn ->
│ ... (* dedented *)
│
│
│ 1 +
│ 2 + (* dedented *)
│ ... (* dedented *)
└────
Remark: after a `then' or `else', many people share the
reasonable
view that any expression containing imperative constructs (`foo;
bar')
should be enclosed in a `begin .. end' block to avoid
surprising-precedence issue. Just as for nested `match', this
recommendation should be lifted for "tail else" constructs.
Remark: The last example is a case where the dedented
expressions are
*not* in tail-position from a runtime-evaluation point of view.
I am
not sure as whether the two notions should be made to coincide
more
strongly, but in any case I'm not fond of the style in this
particular
example, I prefer to move the infix operator to the beginning of
the
next line instead, following a different style and
justification.
The possibility this "cascading tail" style today crucially
relies on
the nesting properties of open-ended syntactic constructs,
notably
`let' (commonly cascaded), and now `match' and `if
... else'. Proposals to transition to a syntax where `match' and
`else' are forced to take a closing marker are incompatible with
the
cascading style. I have not made my mind on whether this should
be
considered a blocker for those proposals, but at least it shows
that
having the open-ended form available has value for certain
programs.
Louis Gesbert then said
───────────────────────
@gasche I prototyped a dedicated option in `ocp-indent', if
you're
interested in trying it out :)
┌────
│ opam pin
git+https://github.com/OCamlPro/ocp-indent#match-tail-cascade
│ echo "match_tail_cascade=true" >> ~/.ocp-indent
└────
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 50844 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-12 13:21 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-11-12 13:21 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 2875 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of November 05
to 12,
2019.
Table of Contents
─────────────────
Mirage 3.7.1 released
Old CWN
Mirage 3.7.1 released
═════════════════════
Archive:
<https://discuss.ocaml.org/t/mirage-3-7-1-released/4634/1>
Hannes Mehnert announced
────────────────────────
MirageOS 3.7.1 is released to opam repository now.
Breaking change:
• The hooks previously defined in
OS.Main.at_enter/at_enter_iter/at_exit/at_exit_iter are now
part of
Mirage_runtime (only used by mirage-entropy)
<https://github.com/mirage/mirage/pull/1010>
Behaviour changes of MirageOS unikernels:
• A unikernel now always calls the Mirage_runtime.at_exit
registered
hooks – once a unikernel succesfully executed its `start' in
`Lwt_main.run', `exit 0' is called to ensure this behaviour
<https://github.com/mirage/mirage/pull/1011>
• Top-level exceptions are no longer caught (there used to be in
mirage-unix/mirage-xen/mirage-solo5 custom handlers). The
OCaml
runtime prints the exception and backtrace on stdout and calls
exit
2 (from 4.10.0, abort() will be called).
Deprecations (being removed from Mirage 4.0)
• All Mirage_YYY_lwt are deprecated, Mirage_YYY interfaces are
no
longer astracted over 'a io and buffer. This reduces the
amount of
opam packages - mirage-yyy-lwt are no longer part of the
release
(each mirage-yyy package provides a Mirage_yyy_lwt module for
backwards compatibility). Motivation was discussed in
<https://github.com/mirage/mirage/issues/1004>
• mirage-types and mirage-types-lwt are deprecated, please use
the
Mirage_YYY signatures directly instead.
Other observable changes
• `mirage configure' now deletes all exising opam files
Most reverse dependencies are already released to opam, have a
look at
<https://github.com/mirage/mirage/issues/1012> for progress (and
the
temporary <https://github.com/mirage/mirage-dev.git#easy> opam
overlay).
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 13405 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-05 6:55 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-11-05 6:55 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1700 bytes --]
Here is the latest OCaml Weekly News, for the week of October 29
to
November 05, 2019.
Table of Contents
─────────────────
vim-ocaml - new home
Old CWN
vim-ocaml - new home
════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-vim-ocaml-new-home/4615/1>
Rudi Grinberg announced
───────────────────────
Dear Vim & Neovim users,
I would like to announce that I've officially moved the
[vim-ocaml]
repository under the control of the OCaml organization on
github. Please direct your bug reports and pull requests to this
repository. This move is done not because vim-ocaml is being
neglected, on the contrary, there's an active team of
maintainers that
recently expanded. I simply want to take this opportunity to
draw more
Vim & Noevim users to this project, as I suspect many users
aren't
aware of recent efforts.
[vim-ocaml] <https://github.com/ocaml/vim-ocaml>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 11877 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-10-15 7:28 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-10-15 7:28 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 5627 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 08
to 15,
2019.
Table of Contents
─────────────────
capnp-rpc 0.4.0
Ocaml-protoc.plugin.1.0.0
Old CWN
capnp-rpc 0.4.0
═══════════════
Archive:
<https://discuss.ocaml.org/t/ann-capnp-rpc-0-4-0/4524/1>
Thomas Leonard announced
────────────────────────
I'm pleased to announce the release of [capnp-rpc 0.4.0], an
OCaml
implementation of the Cap'n Proto RPC specification.
If you haven't used the library before, please see the
[documentation
and tutorial]. Cap'n Proto RPC aims to provide secure,
efficient,
typed communications between multiple parties.
This library is now being used to build [ocaml-ci], where it is
used
for all communication between the web frontend and backend
services,
and to provide a command-line client.
[capnp-rpc 0.4.0]
<https://github.com/mirage/capnp-rpc/releases/tag/v0.4.0>
[documentation and tutorial]
<https://github.com/mirage/capnp-rpc/blob/master/README.md>
[ocaml-ci] <https://github.com/ocaml-ci/ocaml-ci>
Main changes since v0.3
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Breaking changes:
• Wrap errors with the ``Capnp' tag to make it easier to compose
with
other types of error.
• Prefix all command-line options with `capnp-'.
e.g. `--listen-address' is now `--capnp-listen-address'. The
old
names were confusing for applications that supported other
protocols
too (e.g. a web server).
New features:
• Add `Capability.with_ref' convenience function. This
automatically
calls `dec_ref' when done.
• Add Unix `Cap_file' module to load and save `Sturdy_refs'. In
particular, this ensures that saved cap files get a mode of
`0o600',
since they contain secrets.
• Export cmdliner network address parsing. This is useful if
you
don't want to use the default option parsing. For example, if
you
want to make Cap'n Proto an optional feature of your program.
• Upgrade from `uint' (which is deprecated) to the newer
`stdint'.
The latest version of `uint' is just a wrapper around
`stdint', so
this shouldn't break anything if you are using the latest
version.
• Put cmdliner options in their own man-page section. Use
`Capnp_rpc_unix.manpage_capnp_options' to control where in
your
man-page they appear.
• Enable `SO_KEEPALIVE' for TCP connections. For use with
Docker's
libnetwork, try something like this in your `stack.yml':
┌────
│ sysctls:
│ - 'net.ipv4.tcp_keepalive_time=60'
└────
Ocaml-protoc.plugin.1.0.0
═════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-1-0-0/4535/1>
Anders Fugmann announced
────────────────────────
I'm happy to announce the second release of
[ocaml-protoc-plugin].
Ocaml-protoc-plugin is a plugin to googles `protoc' compiler
which
generates type idiomatic to ocaml from `.proto' files including
full
compliant serialization and deserialization functions.
[ocaml-protoc-plugin]
<https://github.com/issuu/ocaml-protoc-plugin>
Most noteworthy changes in this release:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Full proto2 support.
• The list of dependencies has been slimmed way down, and now
only
depends on `conf-protoc' (the `protoc' compiler and googles
*well
known types*).
• Buckescript support.
• Added options to change the ocaml (type for scalar types (int,
int64
or int32).
Many thanks to Wojtek Czekalski for helping trimming
dependencies and
for Buclescript support.
Full changelog:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Support enum aliasing
• Avoid name clash with on 'name'
• Fix code generation when argument contains a path
• Refactor internal types to make serialization and
deserialization
type spec symmetrical.
• Optimize deserialization for messages with max_id < 1024
• Don't depend on Base in runtime
• Slim runtime dependencies: Remove need for base, ocplib-endian
and
ppx_let
• Honor [packed=…] flag.
• Make fixed scalar types default to int32 and int64
• Support proto2 specification
• Add options to switch between int64|int32 and int
• Fix name clash problem with special enum names
• Refactor serialization and deserialization to simplify emitted
code
• Eagerly evaluate serialization (for speed).
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 16446 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-09-03 7:35 Alan Schmitt
0 siblings, 0 replies; 236+ messages in thread
From: Alan Schmitt @ 2019-09-03 7:35 UTC (permalink / raw)
To: lwn, cwn, caml-list
[-- Attachment #1.1.1: Type: text/plain, Size: 1966 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of August 27 to
September 03, 2019.
Table of Contents
─────────────────
Ocaml-multicore: report on a June 2018 development meeting in
Paris
Interesting OCaml Articles
Old CWN
Ocaml-multicore: report on a June 2018 development meeting in
Paris
═══════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202/10>
Deep in this thread, sid announced
──────────────────────────────────
As a small step towards multicore, its interesting to note that
<https://github.com/ocaml/ocaml/pull/8713> just got merged to
master!
Interesting OCaml Articles
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/46>
Yotam Barnoy announced
──────────────────────
<https://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>
Old CWN
═══════
If you happen to miss a CWN, you can [send me a message] and
I'll mail
it to you, or go take a look at [the archive] or the [RSS feed
of the
archives].
If you also wish to receive it every week by mail, you may
subscribe
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives]
<http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #1.1.2: Type: text/html, Size: 12394 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 236+ messages in thread
end of thread, other threads:[~2025-04-15 9:51 UTC | newest]
Thread overview: 236+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-24 9:17 [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Alan Schmitt
-- strict thread matches above, loose matches on Subject: below --
2025-04-15 9:51 Alan Schmitt
2025-04-08 13:14 Alan Schmitt
2025-04-01 9:12 Alan Schmitt
2025-03-25 8:06 Alan Schmitt
2025-03-18 10:18 Alan Schmitt
2025-03-11 15:00 Alan Schmitt
2025-03-04 14:01 Alan Schmitt
2025-02-25 10:36 Alan Schmitt
2025-02-18 14:33 Alan Schmitt
2025-02-11 7:17 Alan Schmitt
2025-02-04 12:05 Alan Schmitt
2025-01-28 13:24 Alan Schmitt
2025-01-21 15:47 Alan Schmitt
2025-01-14 8:20 Alan Schmitt
2025-01-07 17:26 Alan Schmitt
2024-12-31 8:03 Alan Schmitt
2024-12-24 8:55 Alan Schmitt
2024-12-17 13:05 Alan Schmitt
2024-12-10 13:48 Alan Schmitt
2024-12-03 14:44 Alan Schmitt
2024-11-26 8:30 Alan Schmitt
2024-11-19 6:52 Alan Schmitt
2024-11-12 15:00 Alan Schmitt
2024-11-05 13:22 Alan Schmitt
2024-10-29 13:30 Alan Schmitt
2024-10-22 12:42 Alan Schmitt
2024-10-15 13:31 Alan Schmitt
2024-10-08 10:56 Alan Schmitt
2024-10-01 13:37 Alan Schmitt
2024-09-24 13:18 Alan Schmitt
2024-09-17 14:02 Alan Schmitt
2024-09-10 13:55 Alan Schmitt
2024-09-03 8:24 Alan Schmitt
2024-08-27 9:02 Alan Schmitt
2024-08-20 9:29 Alan Schmitt
2024-08-13 13:21 Alan Schmitt
2024-08-06 9:00 Alan Schmitt
2024-07-30 13:26 Alan Schmitt
2024-07-23 13:30 Alan Schmitt
2024-07-16 6:24 Alan Schmitt
2024-07-09 9:19 Alan Schmitt
2024-07-02 7:30 Alan Schmitt
2024-06-25 13:58 Alan Schmitt
2024-06-18 13:05 Alan Schmitt
2024-06-11 15:04 Alan Schmitt
2024-06-04 13:26 Alan Schmitt
2024-05-28 9:07 Alan Schmitt
2024-05-21 13:07 Alan Schmitt
2024-05-14 13:25 Alan Schmitt
2024-05-07 7:30 Alan Schmitt
2024-04-30 7:22 Alan Schmitt
2024-04-23 12:17 Alan Schmitt
2024-04-16 12:00 Alan Schmitt
2024-04-09 9:15 Alan Schmitt
2024-04-02 14:31 Alan Schmitt
2024-03-26 6:32 Alan Schmitt
2024-03-19 15:09 Alan Schmitt
2024-03-12 10:31 Alan Schmitt
2024-03-05 14:50 Alan Schmitt
2024-02-27 13:53 Alan Schmitt
2024-02-20 9:12 Alan Schmitt
2024-02-13 8:42 Alan Schmitt
2024-02-06 15:14 Alan Schmitt
2024-01-30 14:16 Alan Schmitt
2024-01-23 9:45 Alan Schmitt
2024-01-16 10:01 Alan Schmitt
2024-01-09 13:40 Alan Schmitt
2024-01-02 8:59 Alan Schmitt
2023-12-26 10:12 Alan Schmitt
2023-12-19 10:10 Alan Schmitt
2023-12-12 10:20 Alan Schmitt
2023-12-05 10:13 Alan Schmitt
2023-11-28 9:09 Alan Schmitt
2023-11-21 7:47 Alan Schmitt
2023-11-14 13:42 Alan Schmitt
2023-11-07 10:31 Alan Schmitt
2023-10-31 10:43 Alan Schmitt
2023-10-17 7:46 Alan Schmitt
2023-10-10 7:48 Alan Schmitt
2023-10-03 13:00 Alan Schmitt
2023-09-19 8:54 Alan Schmitt
2023-09-12 13:21 Alan Schmitt
2023-09-05 9:00 Alan Schmitt
2023-08-29 13:04 Alan Schmitt
2023-08-22 9:20 Alan Schmitt
2023-08-15 16:33 Alan Schmitt
2023-08-08 8:53 Alan Schmitt
2023-08-01 7:13 Alan Schmitt
2023-07-25 8:45 Alan Schmitt
2023-07-11 8:45 Alan Schmitt
2023-07-04 9:18 Alan Schmitt
2023-06-27 8:38 Alan Schmitt
2023-06-20 9:52 Alan Schmitt
2023-06-13 7:09 Alan Schmitt
2023-06-06 14:22 Alan Schmitt
2023-05-30 15:43 Alan Schmitt
2023-05-23 9:41 Alan Schmitt
2023-05-16 13:05 Alan Schmitt
2023-05-09 11:49 Alan Schmitt
2023-05-02 8:01 Alan Schmitt
2023-04-25 9:25 Alan Schmitt
2023-04-18 8:50 Alan Schmitt
2023-04-11 12:41 Alan Schmitt
2023-04-04 8:45 Alan Schmitt
2023-03-28 7:21 Alan Schmitt
2023-03-21 10:07 Alan Schmitt
2023-03-14 9:52 Alan Schmitt
2023-03-07 9:02 Alan Schmitt
2023-02-28 14:38 Alan Schmitt
2023-02-21 10:19 Alan Schmitt
2023-02-14 8:12 Alan Schmitt
2023-02-07 8:16 Alan Schmitt
2023-01-31 6:44 Alan Schmitt
2023-01-24 8:57 Alan Schmitt
2023-01-17 8:37 Alan Schmitt
2022-11-29 14:53 Alan Schmitt
2022-09-27 7:17 Alan Schmitt
2022-09-20 14:01 Alan Schmitt
2022-09-13 8:40 Alan Schmitt
2022-08-23 8:06 Alan Schmitt
2022-08-16 8:51 Alan Schmitt
2022-08-09 8:02 Alan Schmitt
2022-08-02 9:51 Alan Schmitt
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-25 7:30 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox