Similarly to what the Eio team is doing, we’re now also making the Ppxlib dev meetings public. Ppxlib’s maintenance is mainly passive, so the meetings are monthly and tend to be small. Still, anyone who’s interested is invited to join!
In general, our meetings are every third Tuesday of the month at 6pm CET (third because three is the smallest prime number right after two ). However, we sometimes adapt the time to make sure that both @panglesd and I can join.
This month, the meeting will be the day after tomorrow, i.e. on Thursday, June 22nd at 4pm CET. I’ll post a link to that meeting in this thread on Thursday.
Some things that are on the agenda for this month’s meeting are:
Recap of ocaml.5.1.0 support
- What have been the main pain points for Ppxlib wrt the Parsetree change on value binding constraints?
- How can we handle those kinds of Parsetree changes better in the future?
Upcoming ocaml.5.1.0 feature support
- What structure do we want for the Ast_builder/Ast_pattern unstable submodules?
- When are we going to start the creation of the current PPX universe?
- How we will detect the potential semantic breakages of PPXs after the Parsetree bump.
trunk-support
- Let’s move trunk-support over to main!
- Possibly: Astlib
If you’d like to discuss anything else, you can answer here on the thread and we’ll add it to the agenda.
As a follow-up: It has been @panglesd, @Burnley and me in the meeting today. So nobody “from outside” has joined. Still, we think it’s good that the decision not to participate is taken by each community member, not by us. So we’ll keep the meetings open. You can add the monthly event to your Google calendar, and we will try to send a notification here on discuss each month.
Hello We’re having the monthly dev meeting today at 6pm CEST. It’s the same meeting link as always: https://meet.google.com/yxw-ejnu-cju and here’s our agenda so far:
0.31.0 release:
Good timing: OCaml 5.1 has just been released. Now our 5.1 support bug fix is due.
Also, as a side-note: If anyone thinks that two posts about the Ppxlib meetings per month -one with the agenda and the meeting link and one with the link to the notes- is too much spamming, do let me know.
Is it viable to try to stay in sync with OCaml trunk?
Open PRs on ppxlib.
(If there’s a lot of time left and nobody is in a hurry, we might also chat about ppxlib in general and meta-programming approaches in other languages.)
@octachron has come to the ppxlib dev meeting today, which has been a very nice surprise. It’s nice to discuss intersections between ppxlib and the compiler together with compiler maintainers. Thanks, @octachron!
Are there still use cases where the ppx driver is compiled on a different OCaml version than the project is compiled with? In those cases, that compiler change would affect us.
Change of philosophy for trunk-support branch.
As always, we’re happy to add anything to the agenda! And also, as always, we’re happy if anyone wants to join: https://meet.google.com/yxw-ejnu-cju . That’s true in general and particularly if you have insight about the use case question in point 2 from the agenda (also happy to hear about it here on discuss).
Hello I’ve been wondering how this thread is perceived: Do people appreciate that I keep on posting about the monthly dev meetings, first with the agenda and, later on, adding a link to the meeting notes? Or do some perceive it a bit as “spam”?
I’ve decided to make a quick poll to try to find that out. If you only have the slightest opinion, please participate.
And if you have a stronger and more formed opinion than captured by the poll, you’re of course also very welcome to post with your opinion. E.g. I could imagine things like “A link to the notes every month is good, but please summarize the notes more instead of so many low-level details”.
So, here’s the poll: Do you think it’s good to keep on posting about the ppxlib dev-meetings every month?
Yes. It’s nice to see the agenda and a link to the notes here on the forum every month.
Thanks everyone who has participated in the poll! It seems like a few people do appreciate the monthly posts, so I/we’ll keep on doing them. If anyone has any comment, just let us know. However, according to the current state of the poll, there’s also one person who finds this thread a bit spammy - and there might be more. I’ll leave the poll open for as long as discuss allows me, so that I can see if that number increases in the future. In the meantime: I’m sorry for the inconvenience for the very few who find the posts spammy!
This month, we’re having the meeting on Monday instead of Tuesday, same time as always: 2024-02-19T17:00:00Z . That’s also reflected in the public calendar event. Here’s our agenda. Remember that everyone is welcome to add things:
5.2 support
Let’s discuss the complicated compiler AST changes for 5.2, among others, if we’re testing their support enough.
Syntactic support for functions with arity > 1
Have there been more complicated AST changes this time?
The compiler ocaml.ppx.context change
This affects the PPX world iff people want to build their project with a different OCaml version than their PPX is built with. Do we want to keep on supporting that workflow?
Why was the change of ocaml.ppx.context in the compiler done in a breaking way? Is it worth for us to discuss that with them?
The ppxlib ~preview release with 5.2 support
Upcoming things to do on ppxlib
When to start with the work to bump ppxlib’s AST to 5.2?
When to start with the upstream Astlib efforts?
In case we have time, let’s also discuss how to improve the repo for people to get involved easier (issue labels, contribution guidelines etc)
Why was the change of ocaml.ppx.context in the compiler done in a breaking way?
Your post (thanks!) was my first time learning about this. In addition to whatever communication channel y’all have with @octachron, I think that you should not hesitate to open an issue on the compiler when you find such things. There is a chance that we can change things before the 5.2 release to make the ppxlib-side regression go away.
(I’m just following up on this post and the comments on the PR.)
Thanks a lot for following up on this!
I think that you should not hesitate to open an issue on the compiler when you find such things.
Thank you! That’s indeed very good to know. From our point of view, there was nothing you did wrong, as there’s no guarantee for formats such as the ppx context one to be kept stable. So our take on it was that we’ll just deal with it. Very nice to know that it was lack of communication from our side and you’d have done the effort to keep it stable for us if we had communicated about it (we’ve known ever since Add a `-H` flag, second attempt by ccasin · Pull Request #12246 · ocaml/ocaml · GitHub was merged). Next time, we’ll communicate, i.e. write an issue!
Your guess is exactly right: The new compiler -H flag has changed the ocaml.ppx.context format by changing its load_path field. In a “usual” set-up, where the PPX is built with the same compiler version as the project is built with that’s not a problem. It’s only a problem if the PPX is built with <5.2 and the project with >=5.2 or vice-versa. We introduced supporting the workflow of building the PPX with a different compiler than the project in an effort to support bucklescript. Nowadays, we don’t have information if that workflow is still needed by people.
PD:
In addition to whatever communication channel y’all have with @octachron
That “communication channel” was @octachron coming to our meeting :))
Very nice for us: Apart from NathanReb, panglesd and me, also Octachron and shonfeder joined spontaneously Thanks a lot, both! We very very much appreciate every external support and contribution!
This month’s meeting
About this month’s meeting: It’s taking place 2024-03-21T16:00:00Z.
The current agenda is:
Recap of the 5.2 support efforts.
What do we want to do next?
Bump the AST? If so, let’s discuss
if we’re going to create a PPX universe to send the patch PRs
or if are we going to make use of the opam-repo CI and only clone the PPXs that we break.
Or retake the work on upstreaming Astlib?
Or something else? There’s enough small improvements to do.
Can we take turns in running these dev-meetings?
If time: How to improve our repo hygiene to make it easier for external contributors to get involved.
The trunk-support branch was lagging behind before our recent
update following the 5.2.0~alpha releases of the compiler.
Now is a good time to document and improve how we maintain this
branch.
We lack documentation on how to add support for a new compiler version,
that’s something we might want to look into when adding support for the
latest trunk.
It seems that @hhugo already has a branch with 5.3 support, probably
worth looking into this.
Are we bumping the internal AST to 5.2
A quick update on ppx_deriving
6.0.0 release ongoing with standard derivers ported to ppxlib
ppx_deriving_yojson should be migrated as well
We should start deprecating the ppx_deriving API for writing
derivers as a next step
Refactoring the driver code that builds the list of AST transforms
Working on the dune driver mode brought to light that this part of the driver could use some simplification and clarification
). However, we sometimes adapt the time to make sure that both @panglesd and I can join.
The 
Thanks, both! The insight into compiler-related details, as well as the nice nudge towards the ppx_deriving plug-ins, have been very helpful and nice.