PATCHES - Countdown to September 7
Here is the current countdown report. The next countdown will begin on September 7th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1593 Add 'outsidecomma and 'upbow breath mark types - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1593 Countdown: !1609 Website maintenance - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1609 !1608 Update vendored Pygments - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1608 !1607 slur-configuration.cc: small cleanup - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1607 !1606 Replace (ice-9 curried-definitions) with a fixed version - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1606 !1604 Clean up unused stencil commands - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1604 !1603 Improve clang-format config - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1603 !1601 Grob: make data members private - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1601 !1600 Reduce dynamic casting - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1600 !1599 Web: update GSoC page - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1599 !1598 Add '\bp' (big point) as unit - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1598 !1596 doc: reference fixes and formatting - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1596 !1594 musicxml2ly: use \caesura command - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1594 !1591 Enforce at most one instance of a translator type per context - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1591 !1590 Define and use ly_list - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1590 !1588 Add list of bar lines in an NR appendix (redux) - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1588 !1587 In MIDI, render lyric underties using Unicode undertie U+203F - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1587 !1544 Misc. minor output-distance cleanups - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1544 Review: !1611 slur-configuration.cc: fine-tune penalty for dots - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1611 New: No patches in New at this time. Waiting: !1610 RFC: Require Cairo for building - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1610 !1578 New margins by default - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1578 Cheers, Colin
Re: "Hymn template" snippet
On Aug 9, 2022, at 10:07, Trevor wrote: > In more modern hymn books there is a movement to use thin double lines > throughout rather than commas to show how the lines of the verse map onto the > music, although settings of traditional hymns usually retain the commas (see > Common Praise). Thanks. For the record, here's evidence that both the comma and the double bar are not tied to line position in _Common Praise_: https://hymnary.org/hymn/CPAM2000/369 — Dan
Re: Making Cairo backend mandatory for building?
MR opened for this: https://gitlab.com/lilypond/lilypond/-/merge_requests/1610 Thanks, Jean
Re: Making Cairo backend mandatory for building?
Le 05/09/2022 à 22:38, Jonas Hahnfeld a écrit : On Mon, 2022-09-05 at 22:27 +0200, Jean Abou Samra wrote: Even though the Cairo backend is advertised as experimental, it is starting to get some use; see for example the message today on -user about a new OOoLilyPond release supporting it. This makes me wonder: now that the official binaries have Cairo, isn't it time to require it for the build and ditch --enable-cairo-backend so that everyone has it, including those who use distro packages? To be clear, this wouldn't be for 2.24, which is in build freeze mode, but we could do it in master after branching. Sounds reasonable, would have proposed the same. Probably already having it for 2.25.0 makes sense so that it's there "from the beginning". Agreed (of course). We're going to do it sooner or later in the 2.25 series anyway, as we eventually want Cairo to become the default. "eventually" yes, but not sure if during 2.25 (to be released as 2.26) is a good idea since moving away from the ps backend is quite a significant change (which I've argued before, would warrant a major version change aka 3.0). I think that even if Cairo doesn't become the default for PDF in 2.26, we will most probably want to make it the default for SVG output, since the current SVG backend is slow and suffers from rendering discrepancies.
Re: Making Cairo backend mandatory for building?
On Mon, 2022-09-05 at 22:27 +0200, Jean Abou Samra wrote: > Even though the Cairo backend is advertised as experimental, it is > starting to get some use; see for example the message today on -user > about a new OOoLilyPond release supporting it. This makes me wonder: > now that the official binaries have Cairo, isn't it time to require > it for the build and ditch --enable-cairo-backend so that everyone has > it, including those who use distro packages? To be clear, this wouldn't > be for 2.24, which is in build freeze mode, but we could do it in master > after branching. Sounds reasonable, would have proposed the same. Probably already having it for 2.25.0 makes sense so that it's there "from the beginning". > We're going to do it sooner or later in the 2.25 series > anyway, as we eventually want Cairo to become the default. "eventually" yes, but not sure if during 2.25 (to be released as 2.26) is a good idea since moving away from the ps backend is quite a significant change (which I've argued before, would warrant a major version change aka 3.0). signature.asc Description: This is a digitally signed message part
Making Cairo backend mandatory for building?
Even though the Cairo backend is advertised as experimental, it is starting to get some use; see for example the message today on -user about a new OOoLilyPond release supporting it. This makes me wonder: now that the official binaries have Cairo, isn't it time to require it for the build and ditch --enable-cairo-backend so that everyone has it, including those who use distro packages? To be clear, this wouldn't be for 2.24, which is in build freeze mode, but we could do it in master after branching. We're going to do it sooner or later in the 2.25 series anyway, as we eventually want Cairo to become the default.
Re: Moving most initialization to .scm files
Le 05/09/2022 à 21:22, Thomas Morley a écrit : Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via Discussions on LilyPond development : On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: This needs to be done for lots of code in lots of files, so it will be quite a major change to the source even though it is just a straightforward translation. I don't like this idea very much just two weeks before branching for a new stable release. No matter how "straightforward", I find the risk too high that something goes wrong, or that it turns out not to be a good idea for some other reason, or that we still find it insufficient and an entirely different solution is required... For me, this also means we should go without !1510 for the release. It's unfortunate, but not the end of the world; and I personally think it's worse to delay the entire release by weeks / months or even an undetermined amount of time. Jonas I think a stable release without meaningful error-messages as promised by !1510 is unusable for power-users. While working on zither-ly[*], I was tempted to trash a few weeks of coding work, because of shitty error messages, making it unpossible to proceed... Unless Jean pointed me to the possibility to port all (critical) scheme-codings in ly-files to scm-files and use GUILE_AUTO_COMPILE=1 I would not have reached the current state without it. I'm not sure it's the best way but currently it looks like the only one. For 2.24, I think that providing a -dcompile-scheme-code option for byte-compiling user code is a viable route. This could later become the default if it gets robust enough. In particular, since Guile doesn't support compiling more than ~2000 or ~8000 expressions (depending on the BDWGC configuration), we can't use it for make check, which is a strong reason IMHO not to make it the default. I don't think this Guile problem can be worked around. I do *believe* it can be fixed in Guile, but it will take time until Linux distros have the potential fix, and I don't know if the Guile maintainers will accept to backport it to Guile 2.2, which potentially means we'd have to switch to Guile 3 before making byte-compilation of user code the default. And, as we've experienced with the MRs I had to do to fix test failures when I was trying to make compilation the default (!1541, !1540, !1539), the switch could break certain user files that do things not allowed by the byte-compiler, like mutating quoted data. So it is safer not to do shortly before a stable release. Since we don't currently provide binaries of a stable release that work under 64-bit macOS, and it has been some time since 2.22, I also wish a stable release soon, so I think an option is best for the time being.
Re: Moving most initialization to .scm files
Am Mo., 5. Sept. 2022 um 21:34 Uhr schrieb Jonas Hahnfeld : > > On Mon, 2022-09-05 at 21:22 +0200, Thomas Morley wrote: > > Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via > > Discussions on LilyPond development : > > > > > > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: > > > > This needs to be done for lots of code in lots of files, so it will be > > > > quite a major change to the source even though it is just a > > > > straightforward > > > > translation. > > > > > > I don't like this idea very much just two weeks before branching for a > > > new stable release. No matter how "straightforward", I find the risk > > > too high that something goes wrong, or that it turns out not to be a > > > good idea for some other reason, or that we still find it insufficient > > > and an entirely different solution is required... > > > > > > For me, this also means we should go without !1510 for the release. > > > It's unfortunate, but not the end of the world; and I personally think > > > it's worse to delay the entire release by weeks / months or even an > > > undetermined amount of time. > > > > > > Jonas > > > > I think a stable release without meaningful error-messages as promised > > by !1510 is unusable for power-users. > > So we've had this discussion before: Indeed > If I follow the logic, we must not > have a stable release until the error messages are equally good / > better than they have been before. This problem has been known for two > years, with very little activity before Jean started working on it in > May (?). What I want to avoid is blocking the release for two more > years. (probably / hopefully exaggerating, but it *will* change the > schedule) Well, one could argue the current 2.23.12 without !1510 is as unusable as a new stable without !1510 Thus no need to postpone 2.24. For large scheme codings one can just go the route described above. Maybe document/recommend it somewhere? Not sure, though... Cheers, Harm
Re: Moving most initialization to .scm files
On Mon, 2022-09-05 at 21:22 +0200, Thomas Morley wrote: > Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via > Discussions on LilyPond development : > > > > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: > > > This needs to be done for lots of code in lots of files, so it will be > > > quite a major change to the source even though it is just a > > > straightforward > > > translation. > > > > I don't like this idea very much just two weeks before branching for a > > new stable release. No matter how "straightforward", I find the risk > > too high that something goes wrong, or that it turns out not to be a > > good idea for some other reason, or that we still find it insufficient > > and an entirely different solution is required... > > > > For me, this also means we should go without !1510 for the release. > > It's unfortunate, but not the end of the world; and I personally think > > it's worse to delay the entire release by weeks / months or even an > > undetermined amount of time. > > > > Jonas > > I think a stable release without meaningful error-messages as promised > by !1510 is unusable for power-users. So we've had this discussion before: If I follow the logic, we must not have a stable release until the error messages are equally good / better than they have been before. This problem has been known for two years, with very little activity before Jean started working on it in May (?). What I want to avoid is blocking the release for two more years. (probably / hopefully exaggerating, but it *will* change the schedule) Jonas signature.asc Description: This is a digitally signed message part
Re: Moving most initialization to .scm files
Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via Discussions on LilyPond development : > > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: > > This needs to be done for lots of code in lots of files, so it will be > > quite a major change to the source even though it is just a straightforward > > translation. > > I don't like this idea very much just two weeks before branching for a > new stable release. No matter how "straightforward", I find the risk > too high that something goes wrong, or that it turns out not to be a > good idea for some other reason, or that we still find it insufficient > and an entirely different solution is required... > > For me, this also means we should go without !1510 for the release. > It's unfortunate, but not the end of the world; and I personally think > it's worse to delay the entire release by weeks / months or even an > undetermined amount of time. > > Jonas I think a stable release without meaningful error-messages as promised by !1510 is unusable for power-users. While working on zither-ly[*], I was tempted to trash a few weeks of coding work, because of shitty error messages, making it unpossible to proceed... Unless Jean pointed me to the possibility to port all (critical) scheme-codings in ly-files to scm-files and use GUILE_AUTO_COMPILE=1 I would not have reached the current state without it. I'm not sure it's the best way but currently it looks like the only one. Cheers, Harm [*] If someone is interested: https://gitlab.com/Thomas_Morley/zither-ly/-/tree/development/
Re: Moving most initialization to .scm files
Le 05/09/2022 à 19:50, Jonas Hahnfeld a écrit : On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: This needs to be done for lots of code in lots of files, so it will be quite a major change to the source even though it is just a straightforward translation. I don't like this idea very much just two weeks before branching for a new stable release. No matter how "straightforward", I find the risk too high that something goes wrong, or that it turns out not to be a good idea for some other reason, or that we still find it insufficient and an entirely different solution is required... For me, this also means we should go without !1510 for the release. It's unfortunate, but not the end of the world; and I personally think it's worse to delay the entire release by weeks / months or even an undetermined amount of time. It's worth noting that moving the initialization to .scm files (or finding another solution to the startup time problem, probably via some kind of caching) is not strictly required to get !1510 in. However, in the case !1510 is done without it, functions defined in the init .ly files won't appear on the backtraces if something goes wrong while running them. For the next stable release, we could call it good enough to have at least an option running the user's code with compile, even if it's not done for the init code. (As I said on the MR, I have become weary of providing an option to byte-compile the init code, even for debugging purposes, since it looks like a maintenance pitfall.)
Re: Moving most initialization to .scm files
On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote: > This needs to be done for lots of code in lots of files, so it will be > quite a major change to the source even though it is just a straightforward > translation. I don't like this idea very much just two weeks before branching for a new stable release. No matter how "straightforward", I find the risk too high that something goes wrong, or that it turns out not to be a good idea for some other reason, or that we still find it insufficient and an entirely different solution is required... For me, this also means we should go without !1510 for the release. It's unfortunate, but not the end of the world; and I personally think it's worse to delay the entire release by weeks / months or even an undetermined amount of time. Jonas signature.asc Description: This is a digitally signed message part
Re: Fixes and updates for lilypond-invoke-editor script
Yes, incorrect reply a mistake. Unfortunately one cannot unsend! Thanks re gvim issue, good. But there is still the out by one error with geany, so I will submit a patch. Andrew On 6/09/2022 1:33 am, Jean Abou Samra wrote: Hi, (Was it unintentional to reply on an existing unrelated thread?) Le 05/09/2022 à 11:49, Andrew Bernard a écrit : In 2.23.12 at least, there is an error for gvim (missing comma in list) in the lilypond-invoke-editor script, and the column number for geany is wrong as it numbers columns from zero not one. While here, should we drop Atom from the list of editors as it is no longer supported and discontinued? I have fixed these issues. Am I allowed to submit a patch to get this incorporated? As Lukas said, of course yes. Note that the gvim problem has already been fixed by https://gitlab.com/lilypond/lilypond/-/merge_requests/1583 Best, Jean
Re: Fixes and updates for lilypond-invoke-editor script
Hi, (Was it unintentional to reply on an existing unrelated thread?) Le 05/09/2022 à 11:49, Andrew Bernard a écrit : In 2.23.12 at least, there is an error for gvim (missing comma in list) in the lilypond-invoke-editor script, and the column number for geany is wrong as it numbers columns from zero not one. While here, should we drop Atom from the list of editors as it is no longer supported and discontinued? I have fixed these issues. Am I allowed to submit a patch to get this incorporated? As Lukas said, of course yes. Note that the gvim problem has already been fixed by https://gitlab.com/lilypond/lilypond/-/merge_requests/1583 Best, Jean
Re: Fixes and updates for lilypond-invoke-editor script
Hi Andrew, Andrew Bernard schrieb am Mo., 5. Sept. 2022, 11:51: > In 2.23.12 at least, there is an error for gvim (missing comma in list) > in the lilypond-invoke-editor script, and the column number for geany is > wrong as it numbers columns from zero not one. > > While here, should we drop Atom from the list of editors as it is no > longer supported and discontinued? > > I have fixed these issues. Am I allowed to submit a patch to get this > incorporated? Without having looked into the problem itself: yes of course! Anyone can create merge requests on gitlab; if you don't want to set it up accordingly, you can also simply post a patch here or mail it to someone with the necessary privileges, i.e. most of the regulars on this list (myself included). Lukas
Fixes and updates for lilypond-invoke-editor script
In 2.23.12 at least, there is an error for gvim (missing comma in list) in the lilypond-invoke-editor script, and the column number for geany is wrong as it numbers columns from zero not one. While here, should we drop Atom from the list of editors as it is no longer supported and discontinued? I have fixed these issues. Am I allowed to submit a patch to get this incorporated?
NR: no working links in included PDFs
Look at the documention of `\with-url` in the PDF version of the NR:
The link in the included snippet (to 'lilypond.org') doesn't work.
This is a limitation of pdfTeX (or XeTeX), which drops all links and
annotations for included PDF files.
Masamichi-san, is it possible to extend `extractpdfmark` to cover
this, too? Looking around it seems that the tool 'pax'
('PDFAnnotExtractor') in TeXLive can do that. However, it is based on
Java...
https://github.com/bastien-roucaries/latex-pax
The reason why I ask is the planned inclusion of the Visual Grob Index
in the NR – all grobs shown have links to the corresponding
documentation. If these links are lost the value of the index is
reduced enormously, and it would be probably better to not include it
at all but to have a stand-alone, simple, two-page document instead.
Werner
