Now that there's a very significant level of activity on VsCoq 2, we'd like to set up a VsCoq weekly meeting. We will mainly talk about VsCoq 2 dev, but also the maintenance of the current VsCoq if relevant. We need to find a convenient time slot, though. Would monday afternoon work? @Enrico Tassi @Romain Tetley @Hjalte Sorgenfrei Mac Dalland @Simon Green Kristensen @Laurent Théry @Huỳnh Trần Khanh @Paolo Giarrusso
Tuesdays any time before 14:00 works better for @Hjalte Sorgenfrei Mac Dalland , @Jakob Israelsen and I.
So what about Tuesdays at 10:00, is it ok for the other folks interested?
OK for me as well
Sorry, I fear I'll miss this week, but the timeslot's fine
I posted some information for joining here: https://github.com/coq-community/vscoq/wiki/VsCoq-weekly-calls
Feel to add topics if you want them to be discussed.
this has probably been discussed already, but I worry a lot that we are going to experience even more fracturing in the Coq UI world going forward:
Is there a summary for us worriers what will/might happen?
(I wouldn't have much to say in meetings, but am interested in outcomes)
For VsCoq 1 & VsCoq 2, we are going to discuss it, but the plan will probably be something like maintaining both until the Coq versions supported by VsCoq 2 become old enough. Then phasing out VsCoq 1.
The STM & XML protocol deprecation is fairly consensual too, AFAIK.
Karl Palmskog said:
- STM and XML protocol deprecation, what happens to ProofGeneral
Note that ProofGeneral is still using coqtop (not XML)
Maybe it would be possibly to switch ProofGeneral over to vscoqtop when it matures with VsCoq2?
Coqtail is using the XML protocol. Once either vscoqtop or coq-lsp is considered mature enough, I think there should be an effort (coordinating UI maintainers and core devs) to migrate all the other widely used interfaces to use them. CoqIDE could then be either deprecated or migrated depending on what the long-term plan for it is (but as this stage, I believe that deprecating would be better, to avoid also having to handle other types of migrations, like to Gtk4).
I added notes of the meeting (https://github.com/coq-community/vscoq/wiki/VsCoq-weekly-calls), thanks to all participants!
Théo Zimmermann said:
Coqtail is using the XML protocol.
There's been some preliminary discussion about moving Coqtail to coq-lsp: https://github.com/whonore/Coqtail/issues/7.
relatedly to Proof General, does the vscoqtop roadmap already include replacing all PG/Company Coq features that they implement but shouldn't?
Maxime Dénès said:
I added notes of the meeting (https://github.com/coq-community/vscoq/wiki/VsCoq-weekly-calls), thanks to all participants!
is there a workflow for issues affecting both, like https://github.com/coq-community/vscoq/issues/134 , or do we just do sth ad-hoc?
would be good to make an item list of all the features that are in the PG/ide/Vscoq and put a tick if there is an equivalent in the current vscoq2
don't forget PG+CompanyCoq features in that case (not everyone uses CompanyCoq if they use PG)
what is the good tool to try to set up collaboratively this table?
you could just use Markdown tables in the VsCoq wiki?
I've tried to do something. Not sure it is accurate/or exhaustive, feel free to edit it
There was a request for a short intro to coq internals up to the proof/goals data structures. I plan to do it next Tuesday. Would that work?
Did you guys have the short intro? If so, can you update https://github.com/coq-community/vscoq/wiki/VsCoq-weekly-calls to mention it?
Yes, I'll update it
(great, thanks ! And sorry, I'm on vacations ;) )
I updated the wiki with notes from the meeting of today: https://github.com/coq-community/vscoq/wiki/VsCoq-weekly-calls
We seem to have no specific topic to discuss today. Should we skip this occurrence of the call? Or are there last minute things to discuss?
Cc @Enrico Tassi @Romain Tetley @Simon Green Kristensen @Hjalte Sorgenfrei Mac Dalland @Jakob Israelsen
We dont have anything in particular, so it is fine with us if we skip it.
Nothing on my side either
Hi there! Any last minute topic for this week's call?
I don't have much to report on my side, still working on https://github.com/coq/coq/pull/17331. In particular, investigating the small slowdown and preparing more overlays for downstream developments.
@Romain Tetley will be back with us next week, IIRC :)
I'm back but I'll be spectating this week :-)
If no topics, let's skip this one.
On our side, Hjalte is working on fixing state of sentences in the VSCoq document manager, Jakob is trying to unify types to make another heuristic, and I am making the test setup for testing our heuristics against each other via VSCode sorting and filtering of results
@Maxime Dénès I had a question, but I'll just ask it here: Do you have any suggestion on how we should checks if two types are able to unify? I found the unification module, which has w_unify, but that returns a evar_map which I am unsure of how to query for successful unification
That is the old unification. Use Evarconv
https://github.com/coq/coq/blob/9833a5160deb45e0750b40bb2e1a658071efa64e/pretyping/evarconv.mli#L56
Unification is somewhat imperative, it assigns values to variables, and this state is carried by the evarmap.
If the terms are not unifiable, then evarconv raises an exception.
The unify_flags
will let you choose the degree of unfolding (less unfolding, faster runtime)
@Enrico Tassi Thanks, I'll give it a shot.
@Enrico Tassi I got unification to work, although it will only work if it solved the current goal. Is it also unification if my goal is B and I want to apply a lemma of type A -> B? Is that a flag in the unifcation I need to set, or is it another function entirely?
I don't think there is a decent API for this, it is the job of the apply tactic to take a lemma f
and try f
, then f _
, then f _ _
...
This is what I use in srr: https://github.com/coq/coq/blob/master/plugins/ssr/ssrcommon.mli#L226 but you have to pass how many _ you want
I mean, it is not incremental, but you can get started
Enrico and Romain are not available this morning. @Jakob Israelsen @Hjalte Sorgenfrei Mac Dalland @Simon Green Kristensen any topics you'd like to discuss?
We would like to discuss invalidation of state on the backend
Hi all,
Any special topics for today's call ? I don't have anything to report this week.
A message was moved here from #VsCoq devs & users > VSCoq loading speed by Romain Tetley.
We dont have anything
We don't really have anything to talk about either
I'm off this week ;)
cool let's cancel this one then ! see you next week ! ;-)
Hi there! Any topics for this week? I was off last week so I don't have much. Did a bit of exploration of Rust Analyzer, semantic highlighting in LSP, nothing worth reporting yet.
It is the last week we'll be working on code, as we are doing a code freeze on Friday.
(though we might need to work on testing, remains to be seen)
So you plan to open a PR during the week?
With completion ranking and the likes?
no, not in that sense. We will need to decide which of the about 5 strategies makes the most sense to integrate into VSCoq
Hjalte has some open PRs which you could look at, though. Attempts at speeding up VSCoq and fixing deletions.
Yes, I'll look at them. We need to sync with @Romain Tetley , but the next step will surely be to consolidate the code & tests, so these patches will perfectly fit.
Will you still be available next week, if you want to discuss the integration strategies?
Sure, though what we can say will depend on tests of our strategies.
Yes, so let's discuss after you've experimented
We are a bit late today, the channel is now open but Romain and Maxime are not there yet
Is anyone else going to join?
Hi there! I'm travelling today, so won't be able to attend the call. @Enrico Tassi @Romain Tetley feel free to discuss any relevant topic, I'll catch up later.
I'm busy with the math-comp 2.0 sprint
Last updated: Jun 04 2023 at 23:30 UTC