Re: Urs Liska

I second this. Michael Am 4. Januar 2025 23:31:44 MEZ schrieb "Janek Warchoł" : >sob., 4 sty 2025 o 12:44 Lukas-Fabian Moser via Discussions on LilyPond >development napisał(a): > >> git --shortlog --author=Urs shows 70 commits to LilyPond and literally >> hun

Re: Renaming baseMoment

Sounds reasonable. Michael Am 03.10.2024 um 01:48 schrieb Dan Eble: To follow up the replacement of make-moment by \musicLength [1], I think it would make sense to rename baseMoment to beatBaseLength. Are there any concerns or other suggestions?

Re: extremely slow build of guile3 sources

some of them will affect build time in a measurable way, but the main problem is the awfully slow bytecompilation process, which AFAICT won't be affected by the build options. Michael

Re: search for better regtest comparison algorithm

sophisticated it may be, will be mainly designed with the failure modes we're expecting in mind. However, a test system should be in a sense "objective" that it catches more frequent failure modes as well as strange and rare failure modes. Michael Am 29.07.2024 um 16:

Re: search for better regtest comparison algorithm

is is more of an advantage. IMHO, such an approach would also scale better - with the current approach we have low coverage e.g. for the SVG backend. To improve this, we would have to test all files in all backends, don't we? Let's imagine we add an MusicXML backend... Excited to hear yo

Segfault while running under gdb

meantime: https://github.com/ivmai/bdwgc/issues/409 https://github.com/ivmai/bdwgc/commit/c9b3ca8fab74673b8cf5d89cf6d2b5a4375c0732 So, just in case you encounter this, don't worry, set handle SIGSEGV pass nostop during initialization and go on. Happy debugging! Michael

Re: Intrusive instrumentation

Very cool stuff! Am 01.06.2024 um 21:29 schrieb Dan Eble: Note to composers: This thread is about software development. Check this out!   1. Save and unzip the attached JSON file.   2. Visit https://ui.perfetto.dev/ in a browser.   3. Click "Open trace file" and choose the JSON file.   4. Expl

Re: [RFC] Move GitLab testing to Ubuntu 22.04

he releases and Ubuntu 22.04 will have only 3.0.7. Michael

Re: [RFC] Transition to Guile 3.0

that need them, rather relying on loading all modules during startup one after another. Is this correct? That would explain that Guile fails to sort out the dependencies between the modules. Michael

Re: [RFC] Transition to Guile 3.0

our recent fixes for Guile on mingw64. Currently, it even segfaults for me. Michael

Re: [RFC] Transition to Guile 3.0

think. Michael

Re: LilyPond 2.25.14

sable JIT compilation) real    4m4.925s user    0m0.030s sys 0m0.136s So either the env variable is not working as intended, or there is only a very small effect. At least setting `GUILE_JIT_LOG` does work, but one would have to read the source to understand the output. Michael

Re: LilyPond 2.25.14

or do we use the default value? Michael

Re: unwanted randomness while generating LilyPond output

mal messages go to stderr. * run `lilypond --eps input.ly > epsdebug.log` * send me the resulting log files Michael Am 17.02.2024 um 08:05 schrieb Werner LEMBERG: Hello Michael, sorry for the late reply. I would like to help debugging the problem. Which exact invocation do I have to use to rep

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: clefs, time signatures, and key signatures

er bottom as it seems to be more balanced overall to me. Kind regards, Michael

Re: clefs, time signatures, and key signatures

I’ve just looked at the images and especially w/r to the Alto clef I strongly prefer the new spacing. For the others there are spots where I’m not sure it is too tight but overall the new spacing appears to be more balanced. I thus think the new spacing is better overall. Kind regards Michael

Re: LilyPond 2.23.8 released

derstand things. HTH, Michael -- Michael Gerdau email: m...@qata.de GPG-keys available on request or at public keyserver

Re: Partial version numbers in master

convert-ly has always rejected such version strings. Should we accept them or not, in LilyPond and in convert-ly? I see no benefit in accepting them. We do not have a version "2.23" and there would arise ambiguities. Does "2.23" mean: -works with 2.23.0 (as Dan suggested) or - works with every 2.23.x Michael

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

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

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: No, the

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

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

crosoft introduced during the last Windows editions that tend to annoy users more than their awareness for security risks could compensate. Michael

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 flawl

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: /home/michael/lilypond/re

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 missi

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 co

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 } ``` cr

Re: Binaries of LilyPond 2.23.5 with Guile 2.2

I used for building (but that obviously has stuff installed to compile LilyPond, so I might not have noticed if some library is missing...) Cheers Jonas Worked out-of-the-box with a simple score under Ubuntu 18.04. Thanks a lot for your work, Michael

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

lilypond-2.23.5/share/guile/2.2/ice-9/eval.scm ;;;   newer than compiled D:/Lilypond-generic/2.23.5-hahnjo/lilypond-2.23.5/lib/guile/2.2/ccache/ice-9/eval.go ERROR: In procedure apply-smob/1: Wrong number of arguments to # Michael

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

want. Instead it should evaluate it at runtime. So you should simply remove the backslash before $(declare ... All the best, Michael Am 19.11.2021 um 23:03 schrieb Dan Eble: On Nov 19, 2021, at 14:37, John Wheeler wrote: I have used the .bashrc script extracted from LilyDev3/mkosi/debi

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 d

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

f-build-option-for-features I could fix this by installing a current version from PyPI. Some questions: 1. Is it a deliberate decision to force the usage of Guile 2.2 or do you plan to make Guile 1.8 builds available, too? 2. Would it be possible to avoid rebuilds of dependencies already built, if the build process is interrupted? Thanks, Michael

Re: Cairo: Please test mingw installer

the mingw installer. A small nit: SVG files are the only ones having no additional 'cairo' file extension. Is this intended? All output formats compiled fine otherwise and look ok at a first glance. The cairo pdf file is twice as large as the 'normal' one: $ ls -l partitur*

Re: Segmentation fault during `make check'

, char const*) (this=, symbol=0x72fc4920, cause=cause@entry=0x404, file=0x558d2848 "/home/michael/lilypond/lily/paper-column-engraver.cc", line=73, fun=0x558d2f28 "make_columns") at /home/michael/lilypond/lily/engraver.cc:146 This is in the branch of

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 re

Segmentation fault during `make check'

his=, symbol=0x72fc4920, cause=cause@entry=0x404, file=0x558d2848 "/home/michael/lilypond/lily/paper-column-engraver.cc", line=73, fun=0x558d2f28 "make_columns") at /home/michael/lilypond/lily/engraver.cc:146 #2  0x55669ea7 in Engraver::internal_make_column(

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

on: note = { c4 } \markup \note #"4." #UP \note #"4." #UP %%%% I don't want to say it makes any sense, but it is valid input... Michael -- Aaron Hill

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

the regex 'matchfullmarkup' (see convertrules.py:3471) which is used in said commit assumes that \markup is followed by at least one set of braces. You can verify this by converting %% \version "2.18.2" \markup { \note #"4." #UP } %% which work

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

e you mentioned, we should also be careful not to scare off potential contributors (Trevor already gave an example) Cheers, Michael

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

l to build the binaries using GUB. Once they're uploaded, it may be prudent to test that they work the same as the previous release candidates before announcing the new stable version. Sounds good! Thanks, Michael

Re: Releasing 2.22.0

s the label to look for? Label = ~Backport. Cheers, Michael

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

he failing file with us? :) Cheers, Michael

Re: state of the ’Pond for earnest tadpoles

mentation/contributor/lilydev>: please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev instead. I adjusted some parts of this section last year. However, I would be happy to hear if something remains still unclear. Cheers, Michael 1. Download & install VirtualB

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 ke

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

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

7;review', because the frequency of somebody 'passing by' can vary to a great extent and sometimes shared responsibility is noone's responsibility :) James, what is your opinion on that? Would you still be willing to do this job? Cheers, Michael

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

Re: Advancing to Patch::review

lly test MR 531 as that seemed to have no quite made the cut. James Hmm... it seems that on #534 the 'test' stage was run, not 'check'. I'm completely lost, did I do something wrong? Michael

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

released on March 1, 2020 and Harm reported that 2.20.0 is fine. I think bisecting must start with 2.20.0., then. Cheers, Michael

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

The obvious solution is to mark all existing tests as success, but this requires a bit more thought to integrate into output-distance.py (or somewhere else). Despite these shortcomings, I think it would make sense to enable this first implementation in lilypond/lilypond. What do you think? Does definitely make sense, however, I would value James' opinion on that, too. Thanks for your work! Michael

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 - t

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

check' to catch the difference. Hi Harm, could you please try to run `lilypond -ddump-signatures' on your regtest, with and without the fix and compare the .signature files? Cheers, Michael Currently I'm at a loss. Any hints? Thanks, Harm

Re: Stop issue verification?

ority are unfinished patches, where it is often not clear if the original assignees did not have time to incorporate review comments or did not want to work further on the patch at all. But if anybody does want to work on one of them, he can assign himself (again). So I think it is fine to remove 'Status::started', as well. Cheers, Michael

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

Re: Texinfo - manual line breaks in URLs?

ught about extracting all @urefs (and their enclosing paragraphs) that we have in the docs with a sed script and making a test file from it. But as the fall semester starts, I have not much time now. Maybe you can give it a try? Michael Werner

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

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'

CI failure

ke to hear other opinions on that before running a job with this setting on 'frog'. Have a nice day everyone, Michael

Re: I made a Android porting demo for Lilypond

y the way, I made a Lilypond nodejs C++ addon, so now nodejs developers can access Lilypond in native API, avoiding disk I/O. Hope this helps. Impressive, thanks for sharing! Michael

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

, however. But surely there are concepts out there for long-term archivation (or better, long-term reproducibility) of software. What do you think? Michael

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] ~/lil

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)]>

Re: plan for branching

correctly, there will be some release candidates before 2.22, anyway and Jonas would cherry-pick fixes like yours into stable/2.22. So IMHO no urgent need for fast-tracking. Cheers, Michael

@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 62

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 cyc

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 app

Re: Texinfo - manual line breaks in URLs?

fully this will be enough but I wouldn't be surprised if another example came along where the formatting was again substandard. (I get my understanding of the line breaking process from chapter 19 of "TeX by Topic" by V. Eijkhout.) Running a doc build now with the new texinfo.tex version. Michael

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 someb

Re: Texinfo - manual line breaks in URLs?

lowbreak{% \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. Have a nice day, Michael

Re: Texinfo - manual line breaks in URLs?

t the same bad spacing as within the LilyPond doc build. Are you sure that current texinfo.tex really was used? Cheers, Michael

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)

stepmake templates caused the regression. It seems that the definition of $(SCM_FILES) in scm/GNUmakefile does not reach stepmake/stepmake/po-targets.make, where it would be needed to run xgettext on it. I do not know how to fix this correctly, any advice or MR appreciated. Cheers, Michael

Re: on branching...

Am 05.10.2020 um 15:17 schrieb Karlin High: On 10/5/2020 7:33 AM, Michael Käppler wrote: Sure, it may be that there are still lots of problems there, waiting to be uncovered. But debating whether we need more testing at first does not help, when we do not have enough people to do it. What

Re: on branching...

or bringing this topic up again. Cheers, Michael

Re: Use of ly:expect-warning in regtests

they are intended, add ly:expect-warning - run the regtests with 'warning-as-error to #t, if all snipped are fixed It seems that this topic has been around from time to time. Maybe James can tell us, why running the regtests with 'warning-as-error #t was never realized. Cheers, Michael

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

olicy, what is considered good practise for the regtests. (if there is any) Thanks in advance, Michael

Message localization

air enough, but: git grep '(ly:warning (_' scm | wc -l 54 git grep '(ly:warning "' scm | wc -l 25 Are there reasons for this inconsistency? Cheers, Michael

Re: strange replacement 100 → hundred in NR

set-option 'warning-as-error) (ly:expect-warning ...) construct in regtests? I vaguely remember a discussion about that some time ago on -devel...) Cheers, Michael

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

  (not (markup? ottavation-markup))) (ly:warning "Could not find ottavation markup for ~a octaves up." octavation)) (ly:set-middle-C! context Cheers, Michael

Re: Texinfo - manual line breaks in URLs?

texinfo.tex from the Savannah repo. I did have a look only on the English version now. It seems that the URL breaking is still worse in many cases. How should we proceed? Cheers, Michael

  1   2   3   4   5   >