Re: [RFC] Move GitLab testing to Ubuntu 22.04

Hi Jonas, Hi all, I mentioned this during the transition to Guile 3.0, and now I had the time to prepare the required changes to move the base of our GitLab testing to Ubuntu 22.04. The merge request to do so is here: https://gitlab.com/lilypond/lilypond/-/merge_requests/2318 Many thanks for

Re: [RFC] Transition to Guile 3.0

Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld: Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth

Re: [RFC] Transition to Guile 3.0

Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld: [snip] Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may

Re: [RFC] Transition to Guile 3.0

Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond development: This is now up for review in the following merge request: https://gitlab.com/lilypond/lilypond/-/merge_requests/2293 As pointed out by Han-Wen in November, this is actually fairly little code that gets

Re: LilyPond 2.25.14

Am 24.03.2024 um 11:50 schrieb Jonas Hahnfeld: Just out of interest, do we tweak the JIT_THRESHOLD somewhere or do we use the default value? I don't think we change it from LilyPond, so likely using the default value. I did a test with the opposite extremes. Again, 10 subsequent runs with

Re: LilyPond 2.25.14

Hi Jonas, thanks for working on this! Windows build with Guile JIT: https://cloud.hahnjo.de/s/Ek5x9rybpiPNtoj This turns on just-in-time compilation that was added in Guile 3.0, but we had to keep disabled on Windows until now. Please test, especially on larger scores where this should provide

Re: unwanted randomness while generating LilyPond output

Hello Werner, thanks for your reply! Just to make sure we're on the same page: You don't assume that there is variability across different runs of the same LilyPond build on the same machine? (Aka some kind of "non-deterministic behaviour") That would be my understanding of "randomness", which I

Re: unwanted randomness while generating LilyPond output

Hi Werner, I would like to help debugging the problem. Which exact invocation do I have to use to replicate the EPS files you sent? If I do `lilypond --eps input.ly` I get a much bigger EPS file, that seemingly has the fonts attached as binary data. Michael Am 09.02.2024 um 09:11 schrieb Werner

Re: Partial version numbers in master

Am 22.03.2022 um 12:57 schrieb Jean Abou Samra: Hi, With https://gitlab.com/lilypond/lilypond/-/merge_requests/1187, I introduced a change that I didn't notice: something like \version "2.23" is now an error. It is accepted with current released versions. On the other hand, convert-ly has

Re: Could something be done about the way the list of MIDI instrument names is presented?

Am 01.01.2022 um 14:30 schrieb Petr Pařízek: Michael wrote: > are you familiar with GitLab or do you have an account at least? > It would be nice if you could summarize your enhancement proposal and > add it to the issue tracker directly: > https://gitlab.com/lilypond/lilypond/-/issues I

Re: Could something be done about the way the list of MIDI instrument names is presented?

Petře, are you familiar with GitLab or do you have an account at least? It would be nice if you could summarize your enhancement proposal and add it to the issue tracker directly: https://gitlab.com/lilypond/lilypond/-/issues Št'astný nový rok přeje Michael Am 31.12.2021 um 14:14 schrieb Petr

Re: Problems with mingw build

Am 16.12.2021 um 10:24 schrieb Jonas Hahnfeld: Am Donnerstag, dem 16.12.2021 um 09:48 +0100 schrieb Michael Käppler: Am 16.12.2021 um 08:43 schrieb Jonas Hahnfeld: Am Mittwoch, dem 15.12.2021 um 23:17 +0100 schrieb Michael Käppler: Am 15.12.2021 um 19:26 schrieb Jonas Hahnfeld

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 15.12.2021 um 14:38 schrieb Michael Käppler: Am 15.12.2021 um 14:25 schrieb Jonas Hahnfeld: Am Montag, dem 13.12.2021 um 22:09 +0100 schrieb Jonas Hahnfeld: Am Mittwoch, dem 08.12.2021 um 21:51 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: If that still doesn't work

Re: Problems with mingw build

Am 16.12.2021 um 08:43 schrieb Jonas Hahnfeld: Am Mittwoch, dem 15.12.2021 um 23:17 +0100 schrieb Michael Käppler: Am 15.12.2021 um 19:26 schrieb Jonas Hahnfeld: No, the static libfribidi.a should define them without the __imp_ prefix which is special to shared Dlls. The compiler generates

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 16.12.2021 um 08:00 schrieb Jonas Hahnfeld via Discussions on LilyPond development: Am Donnerstag, dem 16.12.2021 um 00:11 +0100 schrieb Robin Bannister: A few hours ago I wrote (re 2.23.5fixed) Well, initially I ran into irrelevancies because my .ly file (for 2.22) has #on-the-fly, which

Re: Problems with mingw build

Am 15.12.2021 um 19:26 schrieb Jonas Hahnfeld: Am Mittwoch, dem 15.12.2021 um 15:36 +0100 schrieb Michael Käppler: Hi all and Jonas in particular, I would like to understand why building for mingw with your scripts does not work for me. I'm on Ubuntu Focal. A linux build worked flawlessly

Problems with mingw build

Hi all and Jonas in particular, I would like to understand why building for mingw with your scripts does not work for me. I'm on Ubuntu Focal. A linux build worked flawlessly. During linking of the lilypond binary it fails with usr/bin/x86_64-w64-mingw32-ld:

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 15.12.2021 um 14:25 schrieb Jonas Hahnfeld: Am Montag, dem 13.12.2021 um 22:09 +0100 schrieb Jonas Hahnfeld: Am Mittwoch, dem 08.12.2021 um 21:51 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: If that still doesn't work, there are two more possibilities: 1. We're

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 07.12.2021 um 21:13 schrieb Jonas Hahnfeld: Am Montag, dem 06.12.2021 um 23:05 +0100 schrieb Michael Käppler: Am 06.12.2021 um 20:47 schrieb Jonas Hahnfeld: How did you extract the archive? I tried both the Windows Explorer "Extract All..." and 7zip. Is there another popular prog

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 08.12.2021 um 07:49 schrieb Petr Pařízek via Discussions on LilyPond development: [Lots of different hashs removed] The SHA256 hash d82aaee8dc73b4ca5d9b4c6d89330cb1dc6b53d5c593e50d209a48b30604314c is the same on my machine. But I think unzipping applies some sort of checksum anyway? To be

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 06.12.2021 um 20:47 schrieb Jonas Hahnfeld: Am Sonntag, dem 05.12.2021 um 23:09 +0100 schrieb Michael Käppler: Am 03.12.2021 um 19:17 schrieb Jonas Hahnfeld via Discussions on LilyPond development: Under Windows 10 x64, even the simplest file ``` \version "2.23.5" { c4 } ``

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 03.12.2021 um 19:17 schrieb Jonas Hahnfeld via Discussions on LilyPond development: Hi all, here are the binaries of LilyPond 2.23.5 with Guile 2.2, created exactly with the scripts contained in the official source tar: https://gitlab.com/hahnjo/lilypond/-/packages/4049140 (For now I've

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 05.12.2021 um 23:09 schrieb Michael Käppler: Under Windows 10 x64, even the simplest file ``` \version "2.23.5" { c4 } ``` crashes with ;;; note: source file D:/Lilypond-generic/2.23.5-hahnjo/lilypond-2.23.5/share/guile/2.2/ice-9/eval.scm ;;;   newer than compiled D:/Lilypo

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

Am 03.12.2021 um 19:17 schrieb Jonas Hahnfeld via Discussions on LilyPond development: Hi all, here are the binaries of LilyPond 2.23.5 with Guile 2.2, created exactly with the scripts contained in the official source tar: https://gitlab.com/hahnjo/lilypond/-/packages/4049140 (For now I've

Re: Question on LilyDev3 mkosi/debian/mkosi.postinst script

Hi John, I am responsible for changing the line you mentioned in 'mkosi.postinst'. See https://github.com/fedelibre/LilyDev/pull/14 tl;dr; It did not work the way it was intended before this change (but for you it did work as you copied and pasted it instead of piping it through `cat`) The

Re: Proposing commit access for Lukas-Fabian Moser

Absolutely seconded. Am 06.10.2021 um 21:21 schrieb Jean Abou Samra: Hi all, Rebasing and merging Lukas' \after patch this morning, I had a wonder moment — wait, he still doesn't have commit access? Seeing his recent patches, which all required substantial discussion and refinement as well as

Re: [RFC] Add set of scripts to build static binaries on Linux

Am 05.08.2021 um 21:51 schrieb Jonas Hahnfeld via Discussions on LilyPond development: I just posted the first version of completely rewritten scripts to build static binaries for LilyPond: https://gitlab.com/lilypond/lilypond/-/merge_requests/864 Hi Jonas, thank you very much for your work!

Re: Cairo: Please test mingw installer

Hi Knut, thank you very much for your work! Am 29.07.2021 um 01:13 schrieb Knut Petersen: Here are installers for lilypond with the  cairo backend after a significant remix by Han-Wen. GUB has been changed to use a cairo version that fixes three bugs relevant for lilypond, a test would be nice.

Re: Segmentation fault during `make check'

Hi Jonas, I do not know if the stack trace of the optimized binary is useful, but: #0  0x7780aa1c in scm_dapply (proc=0x404, arg1=, args=0x7fffec751010) at eval.c:4989 #1  0x55669b84 in Engraver::internal_make_grob(scm_unused_struct*, scm_unused_struct*, char const*,

Re: Segmentation fault during `make check'

Am 15.03.2021 um 12:03 schrieb Michael Käppler: Unfortunately, it seems somehow related to optimization, because the identical setup with an unoptimized lilypond binary (compiled in a different tree from same 'master') does not fail. Pretty hard to track it down... Ouch, I cannot reproduce

Segmentation fault during `make check'

Hi all, I encountered a segmentation fault that happens sporadically during a 'make check' run. See https://gitlab.com/lilypond/lilypond/-/merge_requests/683 for some context. It is not reproducable with a specific snippet, but I could reproduce it on top of a failed 'make check' run by running

Re: running `make grand-replace`

Am 17.02.2021 um 14:11 schrieb Dan Eble: On Feb 17, 2021, at 02:25, Werner LEMBERG wrote: We should run `make grand-replace` to update all copyright years. Since this is a completely mechanical thing to do, I suggest to submit the MR, wait until a build was successful, then immediately merging

Policy concerning 'Patch::review'

Hi all, I'm not sure if I missed some policy change, but I noticed that recently some MRs were set to 'Review' without posting the test results. I assume that in such cases the tests were unchanged, but it would be good to clarify this. Have a nice day everyone, Michael

Re: convert-ly for note/rest-markup

Am 11.02.2021 um 23:39 schrieb Aaron Hill: On 2021-02-11 2:04 pm, David Kastrup wrote: Short of special-patterning the known exceptions...  a bit of a nightmare. Does the pattern matching need to be so particular about context? Consider a primitive approach:   re.sub(r'\\note\s*#"([^"]+)"',

Re: convert-ly for note/rest-markup

Am 03.02.2021 um 09:05 schrieb Michael Käppler: Hi Harm, Am 02.02.2021 um 22:52 schrieb Thomas Morley: Hi, with e35b7959dfe the note-markup-command was changed to need a duration-argument, before it was a string. With, MR 627 "Revisit rest-markup-commands" https://gitlab.com/lilypon

Re: convert-ly for note/rest-markup

Hi Harm, Am 02.02.2021 um 22:52 schrieb Thomas Morley: Hi, with e35b7959dfe the note-markup-command was changed to need a duration-argument, before it was a string. With, MR 627 "Revisit rest-markup-commands" https://gitlab.com/lilypond/lilypond/-/merge_requests/627 I attempt to do similar for

Re: who needs script `update-patch-version`?

Am 01.02.2021 um 12:39 schrieb Jonas Hahnfeld: Am Montag, dem 01.02.2021 um 12:11 +0100 schrieb Werner LEMBERG: Right now I'm completely revising `programming-work.itexi`, so I can take care of that, too. It would be great if you can structure the revision as incremental updates and not as a

Re: probable guile-1.8.9 release

Am 11.01.2021 um 10:58 schrieb Thomas Morley: Hi, please have a look at https://lists.gnu.org/archive/html/guile-user/2021-01/msg00026.html Cheers, Harm Could this probably include Han-Wen's recent fix regarding GC? Cheers, Michael

Re: design decision needed - how to render "Used properties" for markup-(list-)commands

Am 03.01.2021 um 19:44 schrieb Thomas Morley: Am So., 3. Jan. 2021 um 18:28 Uhr schrieb Michael Käppler : Am 03.01.2021 um 16:34 schrieb Thomas Morley: ailing file with us? :) Attached. Although not really familar with texinfo I aimed at doing it as minimal as possible. Likely I miss something

Re: design decision needed - how to render "Used properties" for markup-(list-)commands

Am 03.01.2021 um 16:34 schrieb Thomas Morley: ailing file with us? :) Attached. Although not really familar with texinfo I aimed at doing it as minimal as possible. Likely I miss something ... '\input texinfo' at the beginning? Cheers, Michael

Re: Releasing 2.22.0

Am 03.01.2021 um 12:05 schrieb Jonas Hahnfeld: Hi all and happy new year 2021 to everyone! Wishing you the same and thanks for your work on LilyPond! There were no bug reports for 2.21.82 and no other Critical issue that I'm aware of. While there are a few changes that could be backported (I

Re: Releasing 2.22.0

Am 03.01.2021 um 14:22 schrieb Han-Wen Nienhuys: On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote: There were no bug reports for 2.21.82 and no other Critical issue that I'm aware of. While there are a few changes that could be backported (I tried to label the MRs at GitLab), What is the

Re: design decision needed - how to render "Used properties" for markup-(list-)commands

Am 03.01.2021 um 10:19 schrieb Thomas Morley: Hi, Hi Harm, currently https://gitlab.com/lilypond/lilypond/-/merge_requests/588 is tagged 'needs design', because there are proposals to change the style how the "Used properties" for markup-(list-)commands should print in NR. I've manually [*]

Re: state of the ’Pond for earnest tadpoles

Hi Kieren, Hi Jonas (et al.), I would claim that the contributor experience has been pretty stable since the initial switch to GitLab. Enabling CI and the recent work to also run 'make check' automatically shouldn't change much from a contributor's point of view, I hope. I can't promise to

Re: snippets manual is not rebuilt

Hi Federico, try to delete out-www/it/usage.texi and run 'make doc' again. Cheers, Michael Am 15.12.2020 um 06:51 schrieb Federico Bruni: It's not just the snippets manual. It just happened with the usage manual. I fixed an error in a menu, re-run 'make doc' and I keep getting the same error

Re: Advancing to Patch::review

Am 03.12.2020 um 12:46 schrieb Michael Käppler: [snip] No, that step remains manually, if I'm not mistaken. IIUC, a patch that fails 'make check' ('fails' in the sense of 'errors out') would have failed 'make test' already. As I understood the (old) process, setting a patch to 'Review' should

Re: Advancing to Patch::review

Am 03.12.2020 um 12:06 schrieb James: Hello, On 02/12/2020 20:57, Michael Käppler wrote: Am 02.12.2020 um 18:16 schrieb Jonas Hahnfeld: [snip] Circling back to my original proposal: My gut feeling is that this should be somebody else than the MR author Do I interpret your actions that you

Re: Advancing to Patch::review

Am 02.12.2020 um 18:16 schrieb Jonas Hahnfeld: [snip] Circling back to my original proposal: My gut feeling is that this should be somebody else than the MR author Do I interpret your actions that you disagree with this? To elaborate a bit, this tries to keep the pleasant effect that somebody

Re: Advancing to Patch::review

Am 02.12.2020 um 12:27 schrieb Michael Käppler: Am 02.12.2020 um 07:36 schrieb James Lowe: On 01/12/2020 19:10, Jonas Hahnfeld wrote: FYI: 'make check' is running in pipelines for merge requests since this morning  One thing I forgot in that lengthy email two weeks ago was how MRs get

Re: Advancing to Patch::review

Am 02.12.2020 um 07:36 schrieb James Lowe: On 01/12/2020 19:10, Jonas Hahnfeld wrote: FYI: 'make check' is running in pipelines for merge requests since this morning  One thing I forgot in that lengthy email two weeks ago was how MRs get to Patch::review. Traditionally James posted "Passes

Re: incomplete tuplets in non-standard time signatures

Am 02.12.2020 um 11:24 schrieb Michael Käppler: Am 02.12.2020 um 09:26 schrieb Michael Käppler: Am 30.11.2020 um 09:20 schrieb Michael Käppler: Am 30.11.2020 um 08:29 schrieb Lukas-Fabian Moser: Hi Michael, I just filed a bug report http://lilypond.1069038.n5.nabble.com/Wrongly-read

Re: incomplete tuplets in non-standard time signatures

Am 02.12.2020 um 09:26 schrieb Michael Käppler: Am 30.11.2020 um 09:20 schrieb Michael Käppler: Am 30.11.2020 um 08:29 schrieb Lukas-Fabian Moser: Hi Michael, I just filed a bug report http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html

Re: incomplete tuplets in non-standard time signatures

Am 30.11.2020 um 09:20 schrieb Michael Käppler: Am 30.11.2020 um 08:29 schrieb Lukas-Fabian Moser: Hi Michael, I just filed a bug report http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html 2c2908c905ba822ef656b06b1cc4f0ca33960c9c is the first bad

Re: incomplete tuplets in non-standard time signatures

Am 30.11.2020 um 08:29 schrieb Lukas-Fabian Moser: Hi Michael, I just filed a bug report http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html 2c2908c905ba822ef656b06b1cc4f0ca33960c9c is the first bad commit commit

Re: incomplete tuplets in non-standard time signatures

Am 29.11.2020 um 21:09 schrieb Lukas-Fabian Moser: Hi Harm, Hi Harm and Lukas, I just filed a bug report http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html 2c2908c905ba822ef656b06b1cc4f0ca33960c9c is the first bad commit commit

Re: [RFC] Automatic 'make check' in CI

Am 18.11.2020 um 21:25 schrieb Jonas Hahnfeld: Hi all, Hi Jonas, I'd like to present a first workable version of 'make check' for use in our CI pipelines. I've pushed the necessary commits to my personal fork and created two merge requests to demonstrate the results: Great! 1. Run 'make

Re: Laptop 'broken' - make check no possible at this time

Am 18.11.2020 um 18:18 schrieb James: Hello, On 11/11/2020 17:38, Jonas Hahnfeld wrote: Hi James, all, Am Mittwoch, den 11.11.2020, 10:48 + schrieb James: Hello, Last night my laptop's CPU fan stopped working (in quite spectacular and noisy fashion!). Looks like I am back in action -

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Am 15.11.2020 um 12:36 schrieb Werner LEMBERG: I will be the first responder and say that, of the options in the pdf, I think Gould is the most appropriate. Yep. +1 Werner

Re: regtest not catched by make check

Am 07.11.2020 um 13:23 schrieb Thomas Morley: Hi, it would be nice to have a regression test for https://gitlab.com/lilypond/lilypond/-/merge_requests/497 I think I found some way to display differently with and without the fix. See the attached file. Though, I can't convince 'make check' to

Re: Stop issue verification?

Am 02.11.2020 um 19:47 schrieb Jean Abou Samra: Le 02/11/2020 à 18:18, Jean Abou Samra a écrit : Thanks. I'm going ahead to change the labels right now. Merge request put up at https://gitlab.com/lilypond/lilypond/-/merge_requests/493 and labels renamed and deleted as appropriate, except for

Re: Anybody to take care of !447?

Am 29.10.2020 um 20:22 schrieb Jean Abou Samra: Greetings everybody, So you know, I am becoming completely unavailable for LilyPond development. That's sad news. It was great to have you here. Maybe you can join the team again some day. All the best, Michael Anybody willing to take

Re: Texinfo - manual line breaks in URLs?

Am 29.10.2020 um 15:45 schrieb Werner LEMBERG: See new diffs against master here: https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing I don't know. Some bad examples are gone, while new ones appeared. Yes. It looks as if the URL code needs new implementation.

Re: CI failure

Am 27.10.2020 um 11:51 schrieb Michael Käppler: Hi all, I cannot reproduce the failing CI 'test' stage on shared runners in my project. As Jean pointed out, it is very likely that we have a problem on 'frog'. Right now I'm testing a commit on top of !449 to get debugging output. If that succeeds

Re: CI failure

Am 27.10.2020 um 12:03 schrieb Michael Käppler: Am 27.10.2020 um 11:51 schrieb Michael Käppler: Hi all, I cannot reproduce the failing CI 'test' stage on shared runners in my project. As Jean pointed out, it is very likely that we have a problem on 'frog'. Right now I'm testing a commit on top

CI failure

Hi all, I cannot reproduce the failing CI 'test' stage on shared runners in my project. As Jean pointed out, it is very likely that we have a problem on 'frog'. Right now I'm testing a commit on top of !449 to get debugging output. If that succeeds in my project, I would like to test it on

Re: I made a Android porting demo for Lilypond

Am 24.10.2020 um 15:47 schrieb K.L.: Hello guys. It seems nobody has built lilypond for android yet. I made an experimental demo myself. Demo video: https://www.youtube.com/watch?v=ay13Dk6D60M My blog: https://findlab.github.io/2020/10/23/lilypond-android/ Source:

Re: Old build environments

Am 17.10.2020 um 10:08 schrieb Jonas Hahnfeld: Am Freitag, den 16.10.2020, 14:30 -0600 schrieb Carl Sorensen: On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote: Hi all, a few days ago I wanted to try how some functionality in LilyPond worked, when it was added long time ago. (about 15

Old build environments

Hi all, a few days ago I wanted to try how some functionality in LilyPond worked, when it was added long time ago. (about 15 years ago, around 2.7.x or 2.8.x) Not very surprisingly I could not even get the code to compile with my current build setup. That made we wonder if it would be a good

Re: @url vs. @uref

Am 16.10.2020 um 15:52 schrieb Jonas Hahnfeld: Am Freitag, den 16.10.2020, 15:46 +0200 schrieb Michael Käppler: Am 15.10.2020 um 23:03 schrieb Werner LEMBERG: we're using both `@url` and `@uref` commands in our documentation, the overwhelming majority is `@uref`. michael] ~/lilypond

Re: @url vs. @uref

Am 15.10.2020 um 23:03 schrieb Werner LEMBERG: we're using both `@url` and `@uref` commands in our documentation, the overwhelming majority is `@uref`. michael] ~/lilypond/Documentation/en (master)]> git grep '@url' | wc -l 9 michael] ~/lilypond/Documentation/en (master)]> git grep '@uref' | wc

Re: plan for branching

Am 16.10.2020 um 01:41 schrieb Dan Eble: On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote: Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below): - bump

@url vs. @uref

Hi all, we're using both `@url` and `@uref` commands in our documentation, the overwhelming majority is `@uref`. michael] ~/lilypond/Documentation/en (master)]> git grep '@url' | wc -l 9 michael] ~/lilypond/Documentation/en (master)]> git grep '@uref' | wc -l 622 The functionality is exactly

Re: plan for branching

Am 15.10.2020 um 15:26 schrieb Jonas Hahnfeld: Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below):  - bump master to 2.23.0, in preparation for the next

Re: Texinfo - manual line breaks in URLs?

Am 13.10.2020 um 22:16 schrieb Michael Käppler: Running a doc build now with the new texinfo.tex version. See new diffs against master here: https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing I don't know. Some bad examples are gone, while new ones appeared

Re: Texinfo - manual line breaks in URLs?

Am 13.10.2020 um 11:55 schrieb Werner LEMBERG: We could restore the old behaviour with a hack like @tex \gdef\urefallowbreak{% \allowbreak } @end tex in common-macros.itexi, I did not test this with the complete docs, at least with your test example it does work, though. I've just written an

Re: plan for branching

Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld: With the localization issues hopefully resolved and no objecting comments to the last thread, I think we should go ahead and create stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. After creating the branch, I will (unless

Re: Texinfo - manual line breaks in URLs?

Am 13.10.2020 um 07:35 schrieb Werner LEMBERG: * Both versions, however, correctly justify the paragraph in the example,[*] while exactly the same code in the NR does not. This makes me believe that we have a problem with our texinfo macro setup that prevents correct justification of

Re: Texinfo - manual line breaks in URLs?

Am 09.10.2020 um 09:22 schrieb Werner LEMBERG: Did a make doc with updated texinfo.tex today and compared the pdfs against master. The result is uploaded here: https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing Green is master, red is current texinfo.tex from

Re: lilypond.pot broken (SCM missing)

Am 08.10.2020 um 13:35 schrieb Jonas Hahnfeld: Am Mittwoch, den 07.10.2020, 22:49 +0200 schrieb Michael Käppler: Hi all, while adding gettext calls to all warning and error messages I noticed that the strings from all SCM files are missing in lilypond.pot. Bisecting yielded that commit

lilypond.pot broken (SCM missing)

Hi all, while adding gettext calls to all warning and error messages I noticed that the strings from all SCM files are missing in lilypond.pot. Bisecting yielded that commit 5e092ee0d9b84d1948dc90e95488e8c9b58576d1 Author: Han-Wen Nienhuys Date:   Sat Mar 21 23:46:14 2020 +0100     Inline scm

Re: on branching...

Am 05.10.2020 um 13:49 schrieb Jonas Hahnfeld: Hi all, Hi Jonas, tomorrow marks exactly one month since Han-Wen's proposal to have a freeze of 3 or 4 weeks for stabilizing [1]. While not everybody agreed with that plan, I think it has worked pretty well in practice and there has been no big

Re: Use of ly:expect-warning in regtests

Am 02.10.2020 um 14:38 schrieb Dan Eble: Mostly they set it to #f: git grep "(ly:set-option 'warning-as-error #f" input/regression/* | wc -l 39 I don't know the history behind that, but it doesn't seem useful. It could be a mistake. I think I got it. At first there were neither

Re: Message localization

Am 02.10.2020 um 14:40 schrieb Dan Eble: On Oct 2, 2020, at 07:36, Michael Käppler wrote: Hi all, I noticed that some program messages are localized, others are not and I struggle to see some kind of logic begind. The CG says: "Do not localize/gettextify: * ‘programming_error

Use of ly:expect-warning in regtests

Hi all, while fixing the issue Dan brought up (ottavation markups and MIDI output) and looking through the existing regtest ottavation-markups.ly, I noticed that it does output a warning (as intended). Other regtests, however, use ly:expect-warning to suppress these warnings and output a new

Message localization

Hi all, I noticed that some program messages are localized, others are not and I struggle to see some kind of logic begind. The CG says: "Do not localize/gettextify: * ‘programming_error ()’s * ‘programming_warning ()’s * debug strings * output strings (PostScript, TeX, etc.)" Fair enough,

Re: strange replacement 100 → hundred in NR

Am 01.10.2020 um 12:24 schrieb Jonas Hahnfeld via Discussions on LilyPond development: So I think it's more likely that the issue got exposed by commit 5a957021a3 which runs lilypond once per document passed to lilypond-book instead of per included file. This increases the chance of being

Re: Could not find ottavation markup

Am 01.10.2020 um 00:23 schrieb Dan Eble: On Sep 30, 2020, at 15:56, Michael Käppler wrote: Am 29.09.2020 um 14:38 schrieb Dan Eble: ... I lean toward removing the warning. Hi Dan, what about this: (only tested with your MWE, though) Thanks & LGTM. Are you willing to put that in a m

Re: Could not find ottavation markup

Am 29.09.2020 um 14:38 schrieb Dan Eble: Using the latest version of master, I'm seeing the warning "Could not find ottavation markup for 1 octaves up" in a number of my scores when MIDI output is enabled. This warning was added about a year ago in commit

Re: Texinfo - manual line breaks in URLs?

Hi Werner et al., I hope it is okay to resurrect this old thread. Did a make doc with updated texinfo.tex today and compared the pdfs against master. The result is uploaded here: https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing Green is master, red is current

Re: Compiling Japanese snippets.pdf fails

Am 28.09.2020 um 23:50 schrieb Michael Käppler: Hi all, I'd like to resume my work regarding upgrading texinfo.tex [1] from June. However, one problem leads to another (as usually :-)) and the peacefully failing XeTeX without comprehensible error messages is not exactly helpful für debugging

Compiling Japanese snippets.pdf fails

Hi all, I'd like to resume my work regarding upgrading texinfo.tex [1] from June. However, one problem leads to another (as usually :-)) and the peacefully failing XeTeX without comprehensible error messages is not exactly helpful für debugging. Anyway, I got the latest texinfo.tex from the

Re: Lilypond build

Am 18.09.2020 um 16:05 schrieb Federico Bruni: [snip] (./Documentation/out-www/it/web.texi (/usr/share/texlive/texmf-dist/tex/texinfo/texinfo.tex Loading texinfo [version 2019-09-20.22]: pdf, fonts, markup, glyphs, page headings, tables, conditionals, indexing, sectioning, toc, environments,

Re: issue verification

Am 18.09.2020 um 23:56 schrieb Jean Abou Samra: Hi, Le 18/09/2020 à 11:15, Phil Holmes a écrit : I don't know if this isn't clear, but just to state the original point of verifying issues. If the change is claimed to fix a bug, we compile the previously buggy code with the release in which

Re: issue verification

Am 18.09.2020 um 13:07 schrieb Michael Käppler: Am 18.09.2020 um 11:15 schrieb Phil Holmes: I don't know if this isn't clear, but just to state the original point of verifying issues. If the change is claimed to fix a bug, we compile the previously buggy code with the release in which the bug

Re: issue verification

for 2.21.2 today. Cheers, Michael -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Michael Käppler" ; "Jean Abou Samra" ; "lilypond-devel" Sent: Friday, September 18, 2020 7:57 AM Subject: Re: issue verification

Re: Lilypond build

Am 18.09.2020 um 00:49 schrieb Federico Bruni: Il giorno mer 16 set 2020 alle 15:39, Michael Käppler ha scritto: Am 16.09.2020 um 13:45 schrieb Michael Käppler: Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right

Re: issue verification

Am 18.09.2020 um 08:57 schrieb Jonas Hahnfeld: Am Donnerstag, den 17.09.2020, 23:01 +0200 schrieb Michael Käppler: From my point of view, if an issue is 1. closed 2. marked as "Status::Fixed" 3. assigned to milestone x.y.z one can be sure that it is fixed in release x.y.z What

Re: issue verification

Am 17.09.2020 um 23:01 schrieb Michael Käppler: From my point of view, if an issue is 1. closed 2. marked as "Status::Fixed" 3. assigned to milestone x.y.z one can be sure that it is fixed in release x.y.z What I meant was: 'that the commit with the purpose of fixing the issu

Re: issue verification

Am 17.09.2020 um 21:32 schrieb Jonas Hahnfeld: Am Donnerstag, den 17.09.2020, 20:58 +0200 schrieb Jean Abou Samra: What I do not yet understand is when milestones should be assigned to issues and MRs. So far Jonas has done this from time to time. That was after each release, right? Yes, mostly

Re: issue verification

Am 17.09.2020 um 09:47 schrieb Jonas Hahnfeld: Hi all, unless I'm missing something, there has been no activity on this since the community effort in May [1][2] and issues since version 2.21.2 don't yet have Status::Verified labels. As I'm currently updating CG to mention our use of

  1   2   3   >