Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
CoqIDE on lablgtk3 #9279
This is a version of CoqIDE building on top of lablgtk3. It
The following features are missing:
I don't know if the two first features are commonly used. Personally, I never used them.
The deactivation of the progression bar is a bit frustrating. The pixmap would need to be redone with cairo (with an extra compilation dependency as far as I understand - cairo-ocaml or ocaml-cairo). Do we want to go in this direction? And if yes, I would probably need help. @ppedrot do you have a particular opinion?
Another minor loss is the stippling ("pointillé") of an incomplete
Technically, it is unclear if we can make it for the next Debian freeze. In any case, @silene, @Zimmi48, depending on the schedule of 8.9, depending on what is possible with Debian, I'm ready to do a port of this PR on top of 8.8.2 and release an ad hoc version of 8.8 specifically for gtk3-based CoqIDE if this is the condition to have it in the next Debian stable.
By the way, I made nothing for dune either (but I know that @ejgallego is following this closely, and, lablgtk3 may eventually have a dune-based building).
I do all my Coq development in CoqIde. I haven't tried this new version (let me know if/when that would be helpful), but I can comment on the changes from the PR description:
I don't understand what you are hoping for / asking me exactly but Coq packages have always been completely outdated in Debian and there is no reason to hope that this would change. On the contrary, the best we can hope is that Debian maintainers actually remove the Coq package entirely so that there is no confusion anymore that Debian users should not install Coq using their distribution package manager, but prefer opam (or Nix) instead. Moreover, AFAICT the whole point of this PR was not so that we can have a Debian Coq package but so that CoqIDE continue to be buildable under Debian (otherwise, even with opam, it would have been a nightmare). If you are in contact with Debian maintainers, tell them it is important that opam 2.0 gets its way in before the freeze (maybe it's already the case, I have no idea). In any case, I am not fond of the idea of a new 8.8 release just for this.
This is an example of situation where the flexibility that developing CoqIDE in its own repository would bring would overcome the cost: it could allow to do a new CoqIDE major release, depending on gtk3 and possibly compatible with all recently released versions of Coq...
@Zimmi48: I feel rather powerless to answer your questions about Debian. I don't have a clear picture of how spread is Debian among Coq users nor how these Debian users install Coq. I don't have a clear picture of how important it is for Coq users in general to use the last version. I don't know how much opam or nix is used for installing.
I don't know why Coq is so outdated in Debian. If it is deliberate from Debian maintainers, it would be better to have a header on the Coq Debian page telling how to install Coq without Debian rather than giving the impression to Debian users that Coq is "dying" and to Coq users that Debian is "dying". Actually, Debian maintainers for OCaml have served for so long time that I would not be surprised if they say that they would be happy that a new team take over (and actually Ralf T. who is one of the maintainers, told me something like that). The coming freeze could be a good opportunity to upgrade testing at least to 8.8, if not to 8.9.
Yes, the ability to compile CoqIDE via gtk3 on the next Debian stable is already a, or even the, crucial step.
Note that opam 2.0.1 seems to be already in Debian testing.
About releasing CoqIDE separately, it seems actually that this is the case in Debian. So, maybe, [added: if ever, to start with, there is a Coq 8.8.2 Debian package, then] it is enough to have a package named, say, coqide-on-gtk3-8.8.2???
@jashug: Thanks for feedback.
Maybe can I just add a new color configuration item for incomplete Qed, with default solid light blue or grey background?
A digression: I heard that black background are recommended for the eyes. Would it be worth to develop a default style conceived on top of a black background? (Not that I'm competent though)
Even if it's not deliberate but is just a lack of commitment, this would be preferable. I don't get what makes Debian maintenance so hard. People managing other package managers are pretty capable of keeping up.
Releasing separately and having separate packages are two different things. We can generate many packages from a single release. This is the case in Debian, but also in opam, and someday it will probably be the case as well in Nix. However, having separate release cycles cannot be done while keeping the source of CoqIDE in the Coq repository, because this means that the version of CoqIDE and Coq are tied up together. In particular, what I was talking about was to release a CoqIDE version that would be compatible with lablgtk3 and a range of Coq versions.
Dec 24, 2018
Someone from Debian could tell more. Possible hypotheses which maybe are completely wrong are: 1) being a Debian maintainer is demanding and involves a high responsibility: there is continuous integration made on several platforms which you have to watch, you have to follow closely the bug trackers of the corresponding packages, etc. 2) when the ratio pleasure/duties goes too low, it is more difficult to be motivated, and this ratio tends to naturally decrease with routine 3) Debian is somehow now more an institution than a fresh innovative project and people liable to take over happen to be more interested for instance in Nix or opam.
Then, I'm not sure exactly how to do this with the current dependencies. For instance, there are currently 3 shared directories,
Sorry @gares, I did not have seen your message which was answering my speculations.
So, let's start from this assumption, i.e. that it is either finding someone to take over or removing the package. Then, how to decide?
What I have difficulties to evaluate is the importance of being present in Debian. In the absolute, if we except the question of lack of time, would it better for the "community" to be in or better not? It seems to me that the question of how to organize ourselves at the level of the community so that the "community" gets what it needs should only come afterwards. In particular, if it makes sense to be in, I'm pretty sure that we shall find someone in the community to take over.
Mar 19, 2019
7 of 9 checks passed
@ppedrot AFAICT you need to do the same as before but using Cairo [https://github.com/Chris00/ocaml-cairo]
TTBOMK the Cairo API should allow you to do quite interesting, and even fancy, stuff.
Note that indeed you may find that the lablgtk3 beta may want some better cairo interaction, but now you can do a quite interesting build setup, as all 3 cairo-ocaml, lablgtk3 and coq use Dune, you can just symlink the two libs into a vendor dir and hack the 3 projects at the same time [even getting merlin integration, but well I know you don't use merlin]