-
Notifications
You must be signed in to change notification settings - Fork 98
Dev meeting 18 07 2023
- OMP:
- Do we “stop maintaining it” or do we add OCaml 5.1 support?
- Ppxlib - OCaml trunk compat:
- Currently, there’s no compatibility due to an ocaml-compiler-libs build problem. Who’s affected?
- Ppxlib’s general maintenance:
- OCaml 5.1 support: The bug fix around generative functor applications is being worked on.
- We’re not in a hurry to bump the AST this time.
- A few pending reviews on Ppxlib. What’s the best strategy for reviews / reacting to non-urgent issues now that we’re in “minimal maintenance mode”?
- Is there anything else that will come up before September?
- OCaml workshop 2023:
- Recap on why our talk proposal on Ppxlib has been rejected.
- Outreachy internship on Ppxlib:
- How is it going? ❤️
- Sonja
- Paul-Elliot
- Burnley
Burnley has worked on Ppxlib itself these weeks (as opposed to working on PPXs): on the error reporting of the driver. The PR is already opened and is being reviewed.
So there are already 2 clear achievements of the internship: The work on ppx_fields_conv and the one on the Ppxlib driver 🎉
Next: The PR that's opened on Ppxlib treats the exceptions on the basis of each rewriting phase. For the context-free phase, that can be re-fined by treating the exceptions on the basis of each context-free PPX. That's what Burnley is going to do next.
Side-note: While working on this, Paul-Elliot noticed that the PPXs don't seem to run in alphabetic order but in order of registration.
Action-point Burnley: He's going to find out what the order is in which the PPXs of one phase (e.g. all whole-file transformation) are applied. Possibly, we'll correct the manual.
Can we deprecate it already or do we need to add 5.1 support?
There are only a few packages whose last version still depends on OMP2:
- clamgml: hard dependency
- GT: hard dependency
- mel: hard dependency. no rev-deps
- gopcamlmode: no rev-deps and superseeded by gopcaml-mode-merlin which doesn't depend on OMP
- ppx_cstruct: dev dependency
- nsq: OMP1 or OMP2??
- pattern: OMP! or OMP2??
This is more than there used to be. Maybe we should have deprecated OMP a while ago.
Action-point Sonja (lost by rock-:scissors:-paper): She'll open issues on those repos asking if deprecating OMP would be ok.
Is there anyone relying on OMP?
Currently, there’s no compatibility due to an ocaml-compiler-libs build problem. Who’s affected?
- The Tarides benchmark team: They can't benchmark any project on
trunkthat uses a PPX. - The Tarides compiler frontend team: They can't fuzzy test
trunkon those projects. - The Tarides compiler backend team: They can't test their new features on those projects.
- Similarly: Nojb. And probably other compiler devs as well.
- Others: Also Avsm and Hhugo seem to be bitten when Ppxlib isn't compatible with
trunk. This time also the Irmin team who wanted to use the last TSAN features on Irmin.
Action-point Paul-Elliot: He'll spend 20 min looking into this to see if it's a very easy fix or not.
In general: Let's keep track of:
- How much time we spend fixing
trunksupport. - Who's affected when Ppxlib is incompatible.
Having a good overview will make it easier to write a good proposal for upstreaming Astlib.
We've submitted a proposal for a talk on Ppxlib, which got rejected. Recap on why we think it got rejected:
- "Outer" criteria: There were more submissions than usual this year. Also, the number of talks by people associated with Tarides has been capped, which has made it harder for us particularly.
- Ppxlib as a topic: Other proposals were around topics that are relatively new or have a lot of momentum at the moment, e.g. Eio, the OCaml Platform, ocaml.org, current-bench, kcas, TSan, or Merlin occurrences. Ppxlib has had little recent impact/changes/improvements.
- Our focus: Our proposal focuses on explaining the OCaml meta-programming situation, not on analyzing/judging it. One of the reviewers makes clear that they would have preferred a focus on analysis/judgment instead: "It would be helpful to readers and listeners to demonstrate the standard (ppxlib) choice is the right choice moving forward.".
- Our proposal: It also seems that the reviewers don't have time to read the proposal in detail, but only skim through it. We should have put the main effort into the introduction of each section. Also, it could have been a good thing to keep the bibliography we had at some point to give a good quick overview of the general scope without having to read the proposal.
The most interesting point is point 3. for us. People always assume that we, as the Ppxlib maintainers, are convinced that Ppxlib is the right choice. Are we? The opinion of the two maintainers present is that it's a good, powerful and solid solution and that it's really important for the OCaml community to have it, but that -depending on the criteria to judge on- there are most likely better solutions. Analyzing the pros and cons of potentially better solutions would be a super interesting talk indeed. That could be both around solutions in other languages and around OCaml-specific or new ideas. Such a talk would imply a lot more work, though, since it requires investigation. We're not going to give such a talk, but still:
Action-point for next dev meeting: Brain-storm around the question what potential/theoretical alternatives there are for Ppxlib and their pros and cons compared to Ppxlib.
- The bug fix around generative functor applications is being worked on.
- We’re not in a hurry to bump the AST this time.
There are a few pending reviews on Ppxlib. We're keeping maintenance time at minimum, but it's a pity to not even review good PRs.
Action-point for before next dev meeting: Before the meeting, one of us goes through the open PRs / unanswered issues to get an overview over the work. Then, during the meeting, we assign all of them. "Assign" means doing one fo the following two: Say we currently don't have time or review/respond properly.
We won't have a meeting in August, so the next meeting will be in September.