[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Dec 27 02:53:03 PST 2022
Hello
Here is the latest OCaml Weekly News, for the week of December 20 to 27,
2022.
Table of Contents
─────────────────
OCaml 4.14.1 released
Js_of_ocaml 5.0
CFP - JFLA 2023 - Journées Francophones des Langages Applicatifs
OCaml Job
Maintenance bottlenecks in the compiler distribution
Results of the OCaml User Survey 2022
Old CWN
OCaml 4.14.1 released
═════════════════════
Archive: <https://discuss.ocaml.org/t/ocaml-4-14-1-released/11007/1>
octachron announced
───────────────────
We have the pleasure of celebrating the birthday of Oronce Finé by
announcing the release of OCaml version 4.14.1.
This release is a collection of safe bug fixes, cherry-picked from the
OCaml 5.0.0 release. If you were using OCaml 4.14.0 and cannot yet
upgrade to OCaml 5, this release is for you.
The 4.14 branch is expected to receive more backported fixes during
the maturation of OCaml 5. Thus don’t hesitate to report any bugs on
the [OCaml issue tracker].
See the list of changes below for more details.
[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 4.14.1
└────
The source code for the release candidate is also directly available
on:
• [GitHub]
• [Inria archive]
[GitHub] <https://github.com/ocaml/ocaml/archive/4.14.1.tar.gz>
[Inria archive]
<https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.1.tar.gz>
Changes in OCaml 4.14.1 (20 December 2022)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Compiler User-Interface and Warnings:
• [#11184], [#11670]: Stop calling ranlib on created / installed
libraries (Sébastien Hinderer and Xavier Leroy, review by the same)
[#11184] <https://github.com/ocaml/ocaml/issues/11184>
[#11670] <https://github.com/ocaml/ocaml/issues/11670>
◊ Build System:
• [#11370], [#11373]: Don’t pass CFLAGS to flexlink during configure.
(David Allsopp, report by William Hu, review by Xavier Leroy and
Sébastien Hinderer)
• [#11487]: Thwart FMA test optimization during configure (William Hu,
review by David Allsopp and Sébastien Hinderer)
[#11370] <https://github.com/ocaml/ocaml/issues/11370>
[#11373] <https://github.com/ocaml/ocaml/issues/11373>
[#11487] <https://github.com/ocaml/ocaml/issues/11487>
◊ 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)
• [#11204]: Fix regression introduced in 4.14.0 that would trigger
Warning 17 when calling virtual methods introduced by constraining
the self type from within the class definition. (Nicolás Ojeda Bär,
review by Leo White)
• [#11263], [#11267]: caml/{memory,misc}.h: check whether `_MSC_VER'
is defined before using it to ensure that the headers can always be
used in code which turns on -Wundef (or equivalent). (David Allsopp
and Nicolás Ojeda Bär, review by Nicolás Ojeda Bär and Sébastien
Hinderer)
• [#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)
• [#11392], [#11392]: assertion failure with -rectypes and external
definitions (Gabriel Scherer, review by Florian Angeletti, report by
Dmitrii Kosarev)
• [#11417]: Fix regression allowing virtual methods in non-virtual
classes. (Leo White, review by Florian Angeletti)
• [#11468]: Fix regression from [#10186] (OCaml 4.13) detecting IPv6
on Windows for mingw-w64 i686 port. (David Allsopp, review by Xavier
Leroy and Sébastien Hinderer)
• [#11489], [#11496]: More prudent deallocation of alternate signal
stack (Xavier Leroy, report by @rajdakin, review by Florian
Angeletti)
• [#11516], [#11524]: Fix the `deprecated_mutable' attribute. (Chris
Casinghino, review by Nicolás Ojeda Bär and Florian Angeletti)
• [#11194], [#11609]: Fix inconsistent type variable names in “unbound
type var” messages (Ulysse Gérard and Florian Angeletti, review
Florian Angeletti and Gabriel Scherer)
• [#11622]: Prevent stack overflow when printing a constructor or
record mismatch error involving recursive types. (Florian Angeletti,
review by Gabriel Scherer)
• [#11732]: Ensure that types from packed modules are always
generalised (Stephen Dolan and Leo White, review by Jacques
Garrigue)
• [#11737]: Fix segfault condition in Unix.stat under Windows in the
presence of multiple threads. (Marc Lasson, Nicolás Ojeda Bär,
review by Gabriel Scherer and David Allsopp)
• [#11776]: Extend environment with functor parameters in
`strengthen_lazy'. (Chris Casinghino and Luke Maurer, review by
Gabriel Scherer)
• [#11533], [#11534]: follow synonyms again in #show_module_type (this
had stopped working in 4.14.0) (Gabriel Scherer, review by Jacques
Garrigue, report by Yaron Minsky)
• [#11768], [#11788]: Fix crash at start-up of bytecode programs in
no-naked-pointers mode caused by wrong initialization of
caml_global_data (Xavier Leroy, report by Etienne Millon, review by
Gabriel Scherer)
• [#11803], [#11808]: on x86, the destination of an integer comparison
must be a register, it cannot be a stack slot. (Vincent Laviron,
review by Xavier Leroy, report by Emilio Jesús Gallego Arias)
[#10768] <https://github.com/ocaml/ocaml/issues/10768>
[#11340] <https://github.com/ocaml/ocaml/issues/11340>
[#11204] <https://github.com/ocaml/ocaml/issues/11204>
[#11263] <https://github.com/ocaml/ocaml/issues/11263>
[#11267] <https://github.com/ocaml/ocaml/issues/11267>
[#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>
[#11392] <https://github.com/ocaml/ocaml/issues/11392>
[#11417] <https://github.com/ocaml/ocaml/issues/11417>
[#11468] <https://github.com/ocaml/ocaml/issues/11468>
[#10186] <https://github.com/ocaml/ocaml/issues/10186>
[#11489] <https://github.com/ocaml/ocaml/issues/11489>
[#11496] <https://github.com/ocaml/ocaml/issues/11496>
[#11516] <https://github.com/ocaml/ocaml/issues/11516>
[#11524] <https://github.com/ocaml/ocaml/issues/11524>
[#11194] <https://github.com/ocaml/ocaml/issues/11194>
[#11609] <https://github.com/ocaml/ocaml/issues/11609>
[#11622] <https://github.com/ocaml/ocaml/issues/11622>
[#11732] <https://github.com/ocaml/ocaml/issues/11732>
[#11737] <https://github.com/ocaml/ocaml/issues/11737>
[#11776] <https://github.com/ocaml/ocaml/issues/11776>
[#11533] <https://github.com/ocaml/ocaml/issues/11533>
[#11534] <https://github.com/ocaml/ocaml/issues/11534>
[#11768] <https://github.com/ocaml/ocaml/issues/11768>
[#11788] <https://github.com/ocaml/ocaml/issues/11788>
[#11803] <https://github.com/ocaml/ocaml/issues/11803>
[#11808] <https://github.com/ocaml/ocaml/issues/11808>
Js_of_ocaml 5.0
═══════════════
Archive: <https://discuss.ocaml.org/t/ann-js-of-ocaml-5-0/11008/1>
Hhugo announced
───────────────
I’m pleased to announce the release of js_of_ocaml 5.0. It should soon
be able 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.
This is the first release supporting OCaml 5 effects handlers. Thanks
to Jérôme Vouillon and Olivier Nicole for the contribution (based on
previous work from Armaël Guéneau and Patrick Ferris).
Js_of_ocaml supports for effect handlers can be enabled by passing the
`--enable=effects' flag. This is based on transformation of the whole
program to continuation-passing style. As a consequence, tail calls
are also fully optimized. This is not the default for now since the
generated code is slower, larger and less readable. The [performance]
impact is especially large for code that involves a lot of function
calls without allocation, since the transformation introduces many
intermediate continuation functions. We hope to improve on this by
transforming the code only partially to continuation-passing style,
and by trying alternative compilation strategies.
See <https://ocsigen.org/js_of_ocaml/latest/manual/effects> to learn
how to enable the support for effect handlers when using dune.
You can try it out in this
<https://ocsigen.org/js_of_ocaml/5.0.1/manual/files/toplevel/index.html>
running in the browser.
[performance]
<https://ocsigen.org/js_of_ocaml/latest/manual/performances>
CFP - JFLA 2023 - Journées Francophones des Langages Applicatifs
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/cfp-jfla-2023-journees-francophones-des-langages-applicatifs/10482/2>
Timothy Bourke announced
────────────────────────
/This message is intentionally written in French. It is a call for
registrations to, and extra information for, the “Francophone Days on
Functional Languages” to be held at the end of January. There are a
number of [submissions] involving OCaml, some written in English. The
PDFs will be available online in January./
Les inscriptions pour les JFLA 2023 sont ouvertes :
<http://jfla.inria.fr/jfla2023.html#inscription>
Grâce aux nombreuses soumissions de qualité, et à nos orateurs invités
— Sylvie Boldo, Cyril Cohen et Xavier Leroy —, le programme construit
avec le comité cette année s’annonce particulièrement engageant et
stimulant ! Les détails se trouvent sur le site web.
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 : 700 euros
• étudiant·e orateur·ice : 0 euro
Les inscriptions des étudiant·e·s orateur·ices sont financées par nos
sponsors académiques et industriels. Ces inscriptions (gratuites) sont
néanmoins nécessaires pour la réservation de l’hébergement.
Nous espérons que vous serez nombreux à participer à ces journées. La
finalisation des inscriptions, notamment le paiement, reste possible
jusqu’au 20 janvier, mais le nombre de places est limité :
inscrivez-vous donc maintenant !
[submissions] <http://jfla.inria.fr/jfla2023.html#articles-long>
OCaml Job
═════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2022-12/msg00009.html>
Christophe Raffalli announced
─────────────────────────────
We have a project involving OCaml, React-Rescript, postgresql,
distributed data (a.k.a. “cloud”). We may hire some people in February
of Mars, but to answer a call, we would like declarations of intent
from people that may be interested.
Important: the job will be in French Polynesia.
We are using the most advanced OCaml’s features (GADT, Effect, Domain,
…). Thus, candidates should really be skilled OCaml programmers. Prior
knowledge of posgresql, distributed data starage of React/Rescript
will be appreciated.
Maintenance bottlenecks in the compiler distribution
════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/maintenance-bottlenecks-in-the-compiler-distribution/11045/1>
gasche announced
────────────────
This is a public announcement that we are experiencing a maintenance
bottleneck with development of the OCaml compiler distribution (the
[github/ocaml/ocaml] repository).
Our development process naturally generates a fair amount of
maintenance work to, among other things, discuss and integrate
proposed patches, fix bugs, and react to feature requests. We don’t
have enough people doing this maintenance work; currently the vast
majority of this work is being done by about 5 people: David Allsopp,
Florian Angeletti, Nicolás Ojeda Bär, Xavier Leroy, and myself.
Despair not! Bug fixes tend to be prioritized and handled quickly; I
believe that the OCaml releases remain of satisfying quality. But
other aspects are affected negatively, for example:
• our ability to react to proposed changes in a timely manner,
• the experience of people trying to contribute to the compiler
codebase,
• various potential improvements that get stalled by lack of manpower
to work on them.
[github/ocaml/ocaml] <https://github.com/ocaml/ocaml>
Context
╌╌╌╌╌╌╌
The OCaml compiler distribution moved to Github in January 2014. Since
then, maintainers have been constantly complaining that there are more
people willing to submit changes/PRs than people willing to review
them, creating a bottleneck on the reviewing side. (We point this out
in the [first section] of our [CONTRIBUTING.md] document.)
But the effort to upstream Multicore OCaml has unfortunately made the
situation worse, for at least two reasons:
• Integrating the completely new Multicore runtime required a lot of
review, integration and documentation work. We onboarded experienced
Multicore developers as upstream maintainers and this helped smooth
out the process, but we have still been less available with other
maintenance tasks that piled up in the meantime.
• The [sequential glaciation] indirectly reduced the maintenance
workforce. In November 2021 we stopped merging non-multicore-related
features in the development version; as a result, various
maintainers and heavy contributors moved away from working on the
main development branch, to do their experiments in separate
repositories (which is completely fine), and also more or less
stopped following issues and performing maintenance on the main
branch (which aggravated the maintenance issue).
Now that OCaml 5 has been released, many contributors will be coming
back with many exciting change proposals to upstream. At the same
time, our users are playing with Multicore features and will soon find
countless bugs to fix, limitations to lift, etc. It’s not easy to play
OCaml maintainer right now.
[first section]
<https://github.com/ocaml/ocaml/blob/25d0fa9a70135288f45c403922e39e18c601777c/CONTRIBUTING.md#contribution>
[CONTRIBUTING.md]
<https://github.com/ocaml/ocaml/blob/25d0fa9a70135288f45c403922e39e18c601777c/CONTRIBUTING.md>
[sequential glaciation]
<https://discuss.ocaml.org/t/the-road-to-ocaml-5-0/8584#the-sequential-glaciation-3>
What can people do to help?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
◊ Contribute to the maintenance effort
Heavy contributors, in particular core developers but not only, should
be expected to participate to this collective maintenance effort. We
are having discussions right now about our expectations.
In my personal opinion, anyone who dedicates a substantial portion of
their time to working on code intended for eventual upstreaming should
dedicate a fraction of this time to collective maintenance of the
development branch. This is the most healthy way to ensure that the
volume of maintenance work scales with the volume of submissions.
(10%? 20%? Something like this.) (If you are paid by someone to work
on the compiler, please make sure that your pay cover this maintenance
fraction.)
Occasional contributors who would like to help with OCaml development
should also consider whether they can help with this. (No pressure!)
We have several instances of people helping with code reviews,
triaging, helping make decisions on design questions etc. (I remember
nice contributions in this direction from Daniel Bünzli, Gabriel
Radanne, Nathanaëlle Courant, Favonia, Guillaume Munch-Maccagnoni and
Kate for example.)
◊ Generate less maintenance work
If you interact with the compiler distribution as a software project,
please be mindful of the maintenance load that you generate. If you
send a Pull Request, make sure that its purpose/justification is
explained very clearly, that it is easy to review; that the benefits
of the change (explain those clearly) outweigh the long-term and also
the short-term costs of integrating it. Similarly for feature requests
or enhancement proposals: now is the time to focus on the
uncontroversial things that are clear improvements, and to justify,
explain them very clearly.
How?
╌╌╌╌
It may not be immediately clear to people what “participate to the
maintenance work” means concretely. Right now I see three obvious
approaches.
1. Subscribe to [github/ocaml/ocaml] notifications and jump in when
you want.
2. Look at our [issues] (258 open as I write this) and see whether you
think can help. Maybe some are out of date / irrelevant and could
be closed – say it. Maybe some bugs could be fixed, or some
enhancement requests could be fulfilled. If you can, give it a try.
It’s best to start with issues where the desired outcome is clear a
consensual (a clear bug to be fixed, with no immediate downside; a
small interface improvement that does not introduce much complexity
and is well-justified; etc.), rather than work on some weird syntax
proposal that will in turn require ample discussion and may be
turned down in the end. (If you find a wonky proposal that failed
to gather consensus and probably never will, it’s actually helpful
to suggest closing the issue.)
3. Look at our [pull requests] (246 open as I write this) and try to
see whether you can help. Again, it’s best to focus on PRs where
there is a clear motivation/need. Look at the code, feel free to
ask questions on things you don’t understand or comment on aspects
you don’t like so much. If the PR is stale, maybe it should be
rebased (would you like to give it a try?), or there isn’t much
that can be reused and it could be closed – feel free to say so.
We have received the feedback that those three approaches are still
confusing to some people. In the upcoming weeks (probably in January)
we will have more discussions about how to organize maintenance, to
find more focused processes that encourage people to contribute in
this way. I don’t think that there is a silver bullet, a magic process
that will make it much easier, so I would encourage anyone interested
to first some of the three basic approaches above and see if it works
for them.
In my experience people often self-censor and do not try to react to
PRs or issues that are not in their area of expertise. But most of the
compiler codebase is in only a very few people’s area of expertise,
the rest of us (myself included) just make do with their imperfect
understanding and try to help anyway. Do not hesitate to walk into
issues outside of your comfort zone, it is a great way to learn about
the compiler distribution codebase.
Happy maintaining!
[github/ocaml/ocaml] <https://github.com/ocaml/>
[issues] <https://github.com/ocaml/ocaml/issues>
[pull requests] <https://github.com/ocaml/ocaml/pulls>
Results of the OCaml User Survey 2022
═════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-results-of-the-ocaml-user-survey-2022/11056/1>
Kim Nguyễn announced
────────────────────
on behalf of the OCSF, I’m pleased to announce that the [report on the
OCaml User Survey 2022] is now available. Unfortunately, the results
are not as meaningful as we would have hoped, since this instance of
the survey attracted far less respondents than the previous one. On
the upside, this allowed us to discover that some members of the OCaml
community are expert in the fields, we hope to use their expertise to
improve the whole process next time. It still allowed the OCSF to draw
some preliminary conclusions, and highlight some pain points where the
OCSF can maybe help improve the OCaml ecosystem as a whole.
Last, I would like to apologies since it took me an inordinate amount
of time to process the results and release the report. While I have
already gotten in touch with some people regarding next year’s
iteration, if anyone would like to help (from proof reading to
publishing in a more modern way than producing a PDF with latex),
don’t hesitate to message me.
[report on the OCaml User Survey 2022]
<https://ocaml-sf.org/docs/2022/ocaml-user-survey-2022.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 at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20221227/ac0ae8cc/attachment-0001.html>
More information about the caml-news-weekly
mailing list