-
Notifications
You must be signed in to change notification settings - Fork 234
Public dev‐meetings
- Ulysse (@voodoos)
- Xavier (@xvw)
- Pizzie (@PizieDust
- Sonja (@pitag-ha)
- Florian Angeletti (@octachron)
- Nicolas Ojeda Bär (@nojb)
- Edwin Ansari
- Kento Okura (@kentookura)
- Lucas Menou
- Manas Jayanth (@ManasJayanth)
- Guillaume Huysmans
- Introduction / Tour de table
- Florian talks about structured compiler output
- Nojb presents typed-grep
- Issues/PR dicussion
- Ulysse, Sonja, Xavier, Pizie, Tarides, editors team
- Florian, Inria Paris, works mostly on the compiler (typer and error messages)
- Edwin, Lexifi, software engineer doing OCaml
- Kento contributor to a math-oriented language implemented in OCaml (Forester) they are interested in adding editor support
- Nicolas, Lexifi, contributes to various parts of the ecosystem
- Lucas: newcomer in the ecosystem, curious
- Manas, worked on esy, interested in dev tools
Florian presentation RFC
- Goal: output structured compiler diagnostics that other tools can read
- Example: F(X)(Y)(Z) the error is on the whole expr, should be on Z. The compiler uses colors for that ! This does not translate to lsp message
- Text format is not the right way to communicate this kind of information
- A multi-year effort for the compiler to output a structured format
- First effort in JSON done by an intern: it was a bit too centered on the JSON format and concerns about evolution
- Florian has a solution he likes quite a lot, he emits structured formatting information in sexp or json
- For more information there is a rfc: Structured diangostics for the compiler
- Will be part of a future release (not 5.3). Subtyping rules are used for minor updates.
Q: Your format is a symbolic repr. of a sequence of actions in format. You then need to interpret it ?
A: You can call the existing interpreters in Syntax_doc or do simple things tailored for your use case
Q: Is it only for errors ?
A: It is for everything outputted by the compiler
Q: What about tools called by the compiler that output to stdout
A: We should redirect these to a file
Q: Availability as a library
A: Will be in compiler-libs (and later in an independent library)
Q: What about a "more simpler output" instead of a format-based one
A: Open to discussion ;)
Q: How many more tools do you plan to add to support users adapt to this new format?
A: compiler only need a serializer. No plans to ship a deserializer.
Q) Is there some notion of unique ID's for the errors
A) No, we only have a list of error messages and not a tree.
Q) Is it planned for 5.3?
A) No, after. There is a worry about PR review time at the moment.
- A grep tool they use at lexify
grep_svnthat is able to grep into the cmt files (and iterates on the Typedtree) - Semantic search of OCaml values, can find values/expressions of a particular type
Examples:
grep_svn -cmt 'List.filter'grep_svn -cmt '(__ (__ : floatarray): float array)'grep_svn -cmt 'List.rev __ @ __'grep_svn -cmt 'match __ with None -> __ | Some __1 -> Some __1'grep_svn -cmt 'List.fold_left __ __ (List.map __ __)'grep_svn -cmt 'Stdlib.max (__:float) __'
Q) Can flags be added to restrict the search size to a particular directory or list of files?
A) The possibilities are endless, can be easily modified for new functionality.
Q) Can we use this tool (is it opensource)?
A) Not at the moment, mostly used at LexiFi and quite specific. Probably open-sourcable. But would also be fairly simple to re-implement.
Q) Does the tool reconstructs the path of identifiers?
A) No it doesn't. Does a path comparison.
Q) While working on the compiler, there is a lot of instances of longident comparisons. Could grep_svn fine these instances?
A) Yes, probably
Q) Is it only a grep-like? What about sed? Can it be used to edit the code/rewrite?
A) Not implemented "yet". Should be possible to extend grep_svn with rewriting capabilities.
We reached the end of the meeting slot at the end, so we did not tackle the last agenta item.
- Ulysse (@voodoos)
- Xavier (@xvw)
- Pizzie (@PizieDust)
- Sonja (@pitag-ha)
- Florian Angeletti (@octachron)
- Darius Foo (@dariusf)
- Andrey Popp (@andreypopp)
- Nicolas Ojeda Bär (@nojb).
- Introduction / Tour de table
- Ongoing projects
- project-wide occurrences demo
- Issues/PR dicussion
- Ulysse: Lead maintainer on Merlin, contributes to OCaml LSP
- Pizzie: Formerly intern in editor's team, now also a contributor
- Sonja: Used to work on other OCaml tools, mostly
ppxlib, has also worked on Merlin in the past, now does less technical work - Xavier: Has joined Tarides this year and is working on Merlin and OCaml LSP
- Florian: Works on the compiler, particularly improving the error messages, also on tooling and integration
- Andrey: Used to work on esy, has also worked on OCaml LSP. Thinks OCaml editor support is very good and is looking forward to contributing to some of the features.
- Darius: PhD student in Singapore, generally interested in what's going on in the OCaml editors development. "It's in a very good state, much better state than a couple of years ago". Also seeing how to contribute.
- Nicolas: Works at Lexify, where they are heavy users of OCaml, so they're interested in everything in OCaml.
- LSP is mostly primarily targeted on visual editors, but could also be very nice for text-based editors thanks to asynchronously and nice features.
- However some UX work is required for this experience to be similar as the classic Merlin plugins, parts of the Merlin server API is more suitable for text-based editor's atm.
- We want to enhance OCaml LSP to bridge that gap and eventually have extensions for the LSP plug-ins for Emacs and Vim, so that everyone can benefit from LSP.
- Demo and presentation
- Including the details that are still missing to implement a project-wide renaming feature.
- We really encourage people to start using it! -
dune build @build-index -w
More info can be found in the announce and wiki.
Q&A summary:
Q: What's the performance of building the index? Why does it not form part of the default build target?
A: We don't have extensive benchmarks. In the projects where we've benchmarked, there's no major performance issue. What makes it resource heavy: For every change, you don't only need to rebuild the unit's index, but also all its transitive dependency indexes. Planned: On running the occurrences query, Merlin could ask dune to rebuild.
Q: Big codebases: Dune takes about 20-30 secs to build, our monorepo about 5 min.
A: We are very interested on usability feedback for very large codebases!
Q: Does the shape result keep type information?
A: No
Q: What's the state of project-wide occurrences in Emacs?
A: The Merlin plug-ins have very basic support right now. merlin-project-occurrences in emacs and :MerlinOccurrencesProjectWide in vim.
What kind of features are people interested in?
Florian: Suggestion for next meeting: focus on structured compiler diagnostics
{
"metadata" :
{ "version" : [1, 0], "valid" : "Invalid", "invalid_paths" : [[]]},
"compiler_log" :
{
"error" :
{
"kind" : "Report_error",
"main" :
{
"msg" :
[["Open_box", ["V", 0]], ["Open_box", ["B", 0]],
["Text", "This expression has type"],
["Simple_break", [1, 2]], ["Open_tag", "Inline_code"],
["Open_box", ["B", 0]], ["Text", "float"], "Close_box",
Sonja: Which part of the editor stack are Andrey and Darius intersted in contributing?
-
Andrey: At Ahrefs, we have both backend and frontend in OCaml, some of the code is shared between the two, Melange builds frontend, OCaml builds backend. We'd love the editor tooling to understand which modality we're in. We've already done some work on dune's configuration on this. We've currently built an OCaml extension. Works very nicely with the whole Merlin stack. However, there are a few concrete feature use cases that fail. So I'd like to understand Merlin better to understand what's failing.
-
Darius: I'm interested in improving the interactions between editor support and toplevel. Also interested in the interaction with the debugger.
Ulysse: What do you think about these meetings?
-
Xavier: Very useful. Learned a lot about project-wide occurrences.
-
Florian: Yes, very nice, I'd like to see more of them. ( ❤️ )