Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

LGTM special thanks for your well reasoned and extensive commit message. One thing to consider: since the mechanics are now very predictable, maybe we can name the property in after its mechanics? ie. french-correction -> stem-end-shorten or something?

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

LGTM. Very nice, thanks! Some minor nits only. https://codereview.appspot.com/557500043/diff/551490044/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/557500043/diff/551490044/Documentation/changes.tely#newcode67

Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

Reviewers: , Message: Deep breath---please review. Ta, Torsten Description: Issue 5788: New French Beamimg Approach Completely new approach to French beaming. This will automatically tackle all kinds of not-yet resolved positioning problems caused by the current French beaming implementation.

Re: Use $(MAKE) instead of 'make' in lilypond-book regtests (issue 569400043 by hanw...@gmail.com)

On 2020/02/23 00:10:31, dak wrote: > On 2020/02/22 23:56:23, hanwenn wrote: > > On Sun, Feb 23, 2020 at 12:29 AM wrote: > > > > > > On 2020/02/22 23:18:43, hanwenn wrote: > > > > On 2020/02/22 23:17:50, hanwenn wrote: > > > > > you were already potentially in a state where

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

LGTM, thanks! https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 2020/02/23 06:28:27, lemzwerg wrote: > > The proper fix here of course is not to close stdin > > but rather to run pdflatex with > > > > -interaction batchmode > > > > (where it prints nothing on output during the run, > > so you need to consult the log file in case of > > problems) or with >

How to report `FontForge` problems while creating LilyPond fonts

Some time ago I was asked to document how to prepare MWE for reporting FontForge problems with Emmentaler. Here it is. How to report `FontForge` problems while creating LilyPond fonts The output produced by the `mf2pt1` script

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 15:59:14, hahnjo wrote: > On 2020/02/23 15:54:54, hanwenn wrote: > > I think this is worth it because it simplifies the build system, and puts the > > locking in the place where we actually access the resource. > > Let me disagree: It complicates lilypond-book with something that no

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 16:29:20, dak wrote: > On 2020/02/23 16:23:34, hanwenn wrote: > > On 2020/02/23 16:05:08, dak wrote: > > > On 2020/02/23 15:54:54, hanwenn wrote: > > > > I think this is worth it because it simplifies the build system, and puts > > the > > > > locking in the place where we actually

Re: testing out Docker CI scripts?

Jean-Charles Malahieude writes: > Le 23/02/2020 à 16:38, David Kastrup a écrit : >> Why wouldn't either of you be using the CPU_COUNT= ... environment >> variable for letting lilypond-book run parallel jobs of lilypond ? >> > > I forgot to mention that I've a > Traduc (translation)]$ cat

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 16:23:34, hanwenn wrote: > On 2020/02/23 16:05:08, dak wrote: > > On 2020/02/23 15:54:54, hanwenn wrote: > > > I think this is worth it because it simplifies the build system, and puts > the > > > locking in the place where we actually access the resource. > > > > Is there any

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 16:05:08, dak wrote: > On 2020/02/23 15:54:54, hanwenn wrote: > > I think this is worth it because it simplifies the build system, and puts the > > locking in the place where we actually access the resource. > > Is there any indication that letting Make run multiple instances of >

Re: testing out Docker CI scripts?

Le 23/02/2020 à 16:38, David Kastrup a écrit : Why wouldn't either of you be using the CPU_COUNT= ... environment variable for letting lilypond-book run parallel jobs of lilypond ? I forgot to mention that I've a Traduc (translation)]$ cat local.make CPU_COUNT = 4

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 15:54:54, hanwenn wrote: > I think this is worth it because it simplifies the build system, and puts the > locking in the place where we actually access the resource. Is there any indication that letting Make run multiple instances of lilypond-book with every instance except one at

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 15:54:54, hanwenn wrote: > I think this is worth it because it simplifies the build system, and puts the > locking in the place where we actually access the resource. Let me disagree: It complicates lilypond-book with something that no (external) user of the script cares about. So

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

Reviewers: hahnjo, Message: I think this is worth it because it simplifies the build system, and puts the locking in the place where we actually access the resource. I take your point about dropped files; the best would be fcntl locks, but I am worried that they might not be supported on

Re: testing out Docker CI scripts?

Han-Wen Nienhuys writes: > This is because you did something, right? Yes, I created that worktree. >> to use a full clone it only failed after ~half an hour (full log >> attached) like so >> >> --8<---cut here---start->8--- >> configure: creating

Re: testing out Docker CI scripts?

Jean-Charles Malahieude writes: > Le 23/02/2020 à 15:56, Han-Wen Nienhuys a écrit : >> On Sun, Feb 23, 2020 at 11:44 AM Han-Wen Nienhuys wrote: >>> and initially it is working as expected (4 cpus.) >>> >>> 11:12:40 3.23 Making Documentation/out-www/music-glossary.pdf < texi >>> 11:12:41 3.30

Re: testing out Docker CI scripts?

Le 23/02/2020 à 15:56, Han-Wen Nienhuys a écrit : On Sun, Feb 23, 2020 at 11:44 AM Han-Wen Nienhuys wrote: and initially it is working as expected (4 cpus.) 11:12:40 3.23 Making Documentation/out-www/music-glossary.pdf < texi 11:12:41 3.30 Making Documentation/out-www/notation.pdf < texi

Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

The current change leaves a few questions unanswered: What should lilypond-book do if there happens to be an old .lock file around? Right now, it just sits there and does nothing which is not obvious to the user. Also, what's the benefit of doing this? Is it worth doing in terms of runtime?

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Sun, Feb 23, 2020 at 3:51 PM David Kastrup wrote: > We could, however, conceivably parallelize a lilypond-book job with PNG > backend and a lilypond-book job with PDF backend. I don't think that > those would share the same database (correct me if I am wrong). I have they share the same

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 11:44 AM Han-Wen Nienhuys wrote: > and initially it is working as expected (4 cpus.) > > 11:12:40 3.23 Making Documentation/out-www/music-glossary.pdf < texi > 11:12:41 3.30 Making Documentation/out-www/notation.pdf < texi > 11:12:47 3.43 Making

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Dan Eble writes: > On Feb 23, 2020, at 09:11, David Kastrup wrote: >> >>> "Sharing Job Slots with GNU make" >>> https://www.gnu.org/software/make/manual/html_node/Job-Slots.html >> >> But that still doesn't solve the problem that the database approach of >> lilypond-book does not work for

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Feb 23, 2020, at 09:11, David Kastrup wrote: > >> "Sharing Job Slots with GNU make" >> https://www.gnu.org/software/make/manual/html_node/Job-Slots.html > > But that still doesn't solve the problem that the database approach of > lilypond-book does not work for running multiple

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Sun, Feb 23, 2020 at 3:36 PM Dan Eble wrote: > > On Feb 23, 2020, at 09:04, Han-Wen Nienhuys wrote: > > > >> What would you recommend to a developer who doesn't want to run more than > >> J = M + N - 1 concurrent jobs due to lilypond development? What values of > >> M and N would serve

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Feb 23, 2020, at 09:04, Han-Wen Nienhuys wrote: > >> What would you recommend to a developer who doesn't want to run more than J >> = M + N - 1 concurrent jobs due to lilypond development? What values of M >> and N would serve best? > > Normally M=N= #cpus should be OK. A bit of extra

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 3:27 PM Jan Nieuwenhuizen wrote: > I found that reseed.sh fails early when lilypond is a work tree (log > attached). After doing This is because you did something, right? > to use a full clone it only failed after ~half an hour (full log > attached) like so > >

Re: testing out Docker CI scripts?

Han-Wen Nienhuys writes: > -james > > On Sun, Feb 23, 2020 at 1:42 PM Han-Wen Nienhuys wrote: >> >> On Sun, Feb 23, 2020 at 1:17 PM Jan Nieuwenhuizen wrote: >> > > Please pull and try again >> > > >> > >> test-git.sh: line 78: local_repo: unbound variable >> > > >> > > yeah, who tests the

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Dan Eble writes: > On Feb 23, 2020, at 06:08, Han-Wen Nienhuys wrote: >> I think we should do both: the lilypond runs in lp-book should be >> protected by some sort of lock, and we should use both CPU_COUNT=M and >> -jN. >> >> then worst case, you have M lilypond processes and N-1 other jobs.

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Sun, Feb 23, 2020 at 2:59 PM Dan Eble wrote: > > On Feb 23, 2020, at 06:08, Han-Wen Nienhuys wrote: > > I think we should do both: the lilypond runs in lp-book should be > > protected by some sort of lock, and we should use both CPU_COUNT=M and > > -jN. > > > > then worst case, you have M

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Feb 23, 2020, at 06:08, Han-Wen Nienhuys wrote: > I think we should do both: the lilypond runs in lp-book should be > protected by some sort of lock, and we should use both CPU_COUNT=M and > -jN. > > then worst case, you have M lilypond processes and N-1 other jobs. What would you recommend

Re: Unable to run make on older releases, while doing bug-reseach

Thomas Morley writes: > Am So., 23. Feb. 2020 um 13:50 Uhr schrieb Thomas Morley > : >> >> Am So., 23. Feb. 2020 um 13:14 Uhr schrieb David Kastrup : > >> > Ah that abomination. Sorry for seeing this only now. You'll need to >> > cherry-pick >> > >> > commit

Re: Unable to run make on older releases, while doing bug-reseach

Am So., 23. Feb. 2020 um 13:50 Uhr schrieb Thomas Morley : > > Am So., 23. Feb. 2020 um 13:14 Uhr schrieb David Kastrup : > > Ah that abomination. Sorry for seeing this only now. You'll need to > > cherry-pick > > > > commit 67cd07e55d5ec908c246ae543e480d367b61d6b3 > > Author: David Kastrup >

Re: Unable to run make on older releases, while doing bug-reseach

Am So., 23. Feb. 2020 um 13:14 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Hi, > > > > I'm currently trying to hunt down a possible bug (I wrote possible, > > because I may very well ne intended behaviour. I don't know yet) > > Using our prereleased installers I found it happened

Re: testing out Docker CI scripts?

-james On Sun, Feb 23, 2020 at 1:42 PM Han-Wen Nienhuys wrote: > > On Sun, Feb 23, 2020 at 1:17 PM Jan Nieuwenhuizen wrote: > > > Please pull and try again > > > > > >> test-git.sh: line 78: local_repo: unbound variable > > > > > > yeah, who tests the testers? :-) > > > > If I'm a tester, then

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 1:17 PM Jan Nieuwenhuizen wrote: > > Please pull and try again > > > >> test-git.sh: line 78: local_repo: unbound variable > > > > yeah, who tests the testers? :-) > > If I'm a tester, then I think that could be you ... :-) > > > (I don't test the whole setup start to

Re: testing out Docker CI scripts?

Han-Wen Nienhuys writes: > looks like you didn't read the docs (which is understandable). Oops! > Please pull and try again > >> test-git.sh: line 78: local_repo: unbound variable > > yeah, who tests the testers? :-) If I'm a tester, then I think that could be you ... :-) > (I don't test the

Re: Unable to run make on older releases, while doing bug-reseach

Thomas Morley writes: > Hi, > > I'm currently trying to hunt down a possible bug (I wrote possible, > because I may very well ne intended behaviour. I don't know yet) > Using our prereleased installers I found it happened between 2.19.25 > and 2.19.26. > > Then I switched to git, in order to

Re: Issue 5773: Quarter Tones for all Languages incl. MusicXML import (issue 577520043 by torsten.haemme...@web.de)

Reviewers: lemzwerg, Message: On 2020/02/19 08:05:57, lemzwerg wrote: > LGTM, thanks! > > https://codereview.appspot.com/577520043/diff/555310043/python/musicexp.py > File python/musicexp.py (left): > > https://codereview.appspot.com/577520043/diff/555310043/python/musicexp.py#oldcode365 >

Re: Unable to run make on older releases, while doing bug-reseach

Hello, On 23/02/2020 11:20, Thomas Morley wrote: Am So., 23. Feb. 2020 um 11:32 Uhr schrieb : Thomas, (I am top posting) While not very helpful to you other than clarifying what you might be seeing, while trying to find when an assertion started to be thrown between 2.18.2 and 2.19.83 (i.e.

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 12:25 PM Jonas Hahnfeld wrote: > > Am Sonntag, den 23.02.2020, 12:19 +0100 schrieb Han-Wen Nienhuys: > > On Sun, Feb 23, 2020 at 12:16 PM Jonas Hahnfeld < > > hah...@hahnjo.de > > > wrote: > > > This sounds contradicting to me: Either you want to use the ccache for > > >

Re: 2.20.0 release coordination with translation. Other showstoppers?

"Phil Holmes" writes: >> >> But it doesn't make sense to point VERSION_DEVEL to documentation that >> is actually older than that of 2.20, does it? >> >> I do not really know what is correct here with respect to our >> semi-automatic webpage update mechanism. I just remember that we had >>

Re: testing out Docker CI scripts?

Am Sonntag, den 23.02.2020, 12:19 +0100 schrieb Han-Wen Nienhuys: > On Sun, Feb 23, 2020 at 12:16 PM Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > This sounds contradicting to me: Either you want to use the ccache for > > multiple jobs or you're running it for every commit - not gaining > >

Re: Unable to run make on older releases, while doing bug-reseach

Am So., 23. Feb. 2020 um 11:32 Uhr schrieb : > > Thomas, > > (I am top posting) > > While not very helpful to you other than clarifying what you might be > seeing, while trying to find when an assertion started to be thrown > between 2.18.2 and 2.19.83 (i.e. a regression - that eventually became >

Re: 2.20.0 release coordination with translation. Other showstoppers?

But it doesn't make sense to point VERSION_DEVEL to documentation that is actually older than that of 2.20, does it? I do not really know what is correct here with respect to our semi-automatic webpage update mechanism. I just remember that we had problems last time round. -- David Kastrup

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 12:16 PM Jonas Hahnfeld wrote: > This sounds contradicting to me: Either you want to use the ccache for > multiple jobs or you're running it for every commit - not gaining > anything except for increased complexity. How does this reasoning work for the reg test? I guess

Re: testing out Docker CI scripts?

Am Sonntag, den 23.02.2020, 12:04 +0100 schrieb Han-Wen Nienhuys: > On Sun, Feb 23, 2020 at 11:55 AM Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > > But a CI should test the changes in every possible way we care about - > > exactly because "this change cannot possibly break". And here I

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Han-Wen Nienhuys writes: > On Sun, Feb 23, 2020 at 12:00 PM wrote: >> > to answer your original question: I think the \sourcefileline >> statements can >> > differ between snippets written from different lp-book instances, and >> this can >> > trigger a consistency check failure. >> >> So

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 11:39 AM Jan Nieuwenhuizen wrote: > > See https://github.com/hanwen/lilypond-ci > > > > I would be interested in your feedback. > > --8<---cut here---start->8--- > 11:36:56 janneke@dundal:~/src/lilypond > $ git clone

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On Sun, Feb 23, 2020 at 12:00 PM wrote: > > to answer your original question: I think the \sourcefileline > statements can > > differ between snippets written from different lp-book instances, and > this can > > trigger a consistency check failure. > > So wouldn't it appear that the way to

Re: 2.20.0 release coordination with translation. Other showstoppers?

"Phil Holmes" writes: > - Original Message - From: "David Kastrup" > To: "Federico Bruni" > Cc: ; ; "Phil > Holmes" > Sent: Saturday, February 22, 2020 10:54 PM > Subject: Re: 2.20.0 release coordination with translation. Other > showstoppers? >> >> One interesting consideration is

Re: testing out Docker CI scripts?

Han-Wen Nienhuys writes: > Maybe it's this statement in ly-rules.make > > # This allows -j make option while making sure only one lilypond-book instance > # is running at the same time, using GNU make's order-only prerequisites so > # as to not create superficial dependencies between unrelated

Re: testing out Docker CI scripts?

On Sun, Feb 23, 2020 at 11:55 AM Jonas Hahnfeld wrote: > But a CI should test the changes in every possible way we care about - > exactly because "this change cannot possibly break". And here I really > mean CI to be integrated into tooling and running without human > interaction, just as Patchy

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On 2020/02/23 10:29:53, hanwenn wrote: > On 2020/02/23 10:04:46, hanwenn wrote: > > On 2020/02/23 09:49:24, dak wrote: > > > Stupid question: does the database design of lilypond-book even allow for > > > uncoordinated parallel runs? > > > > It's not a stupid question; it's a good question. > >

Re: testing out Docker CI scripts?

Am Samstag, den 22.02.2020, 21:18 +0100 schrieb Han-Wen Nienhuys: > This will likely explode the time it takes > > to run it, but I think it's a good thing that patchy does it right now. > > When considering the long time for 'make doc', I wonder if saving on ~4 > > minutes of compile is worth the

Re: texinfo-rules: generate log files in $(outdir)/ (issue 557480043 by hanw...@gmail.com)

Reviewers: lemzwerg, Jean-Charles, Message: On 2020/02/23 10:38:19, Jean-Charles wrote: > Does this mean that, for example, > > Documentation/fr/learning.*.log and input/regression/collated-files.texilog.log > would respectively land in Documentation/fr/out/ and input/regression/out/ ? yes,

Re: testing out Docker CI scripts?

On Sat, Feb 22, 2020 at 11:43 PM David Kastrup wrote: > Clicking on the images in the HTML documentation leads you to the source > code of the respective snippet as generated by lilypond-book. Doing > this on corresponding images in different translations leads you to the > same source file. > >

Re: 2.20.0 release coordination with translation. Other showstoppers?

- Original Message - From: "David Kastrup" To: "Federico Bruni" Cc: ; ; "Phil Holmes" Sent: Saturday, February 22, 2020 10:54 PM Subject: Re: 2.20.0 release coordination with translation. Other showstoppers? Federico Bruni writes: Il giorno sab 22 feb 2020 alle 19:25, David

Re: testing out Docker CI scripts?

Han-Wen Nienhuys writes: > I've been working on a set of scripts that provides a reproducible > test environment for running LilyPond regtests. In addition to being > reproducible, it has some performance tweaks to speed up > recompilations. Yay for reproducible-builds! > See

Re: texinfo-rules: generate log files in $(outdir)/ (issue 557480043 by hanw...@gmail.com)

Does this mean that, for example, Documentation/fr/learning.*.log and input/regression/collated-files.texilog.log would respectively land in Documentation/fr/out/ and input/regression/out/ ? https://codereview.appspot.com/557480043/

Re: Unable to run make on older releases, while doing bug-reseach

Thomas, (I am top posting) While not very helpful to you other than clarifying what you might be seeing, while trying to find when an assertion started to be thrown between 2.18.2 and 2.19.83 (i.e. a regression - that eventually became issue 5651) I discovered that I could not make anything

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On 2020/02/23 10:04:46, hanwenn wrote: > On 2020/02/23 09:49:24, dak wrote: > > Stupid question: does the database design of lilypond-book even allow for > > uncoordinated parallel runs? > > It's not a stupid question; it's a good question. > > Writing files atomically (open temp file, write,

Re: testing out Docker CI scripts?

Werner LEMBERG writes: >> I think the download text would warrant correction. > > Yes. > >> I just naively assumed it to be automatically generated in >> correspondence with reality. > > This is an excellent suggestion. Not sure how to implement that > easily, but please open a tracker issue so

How to test 'stepmake' patch (was Re: Staging broken)

Hello, On 19/02/2020 19:52, David Kastrup wrote: pkx1...@posteo.net writes: Hello and sorry I am late to the table on this - been a busy week for me. On 19/02/2020 08:10, Jonas Hahnfeld wrote: Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup: James < pkx1...@posteo.net

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Reviewers: dak, Message: On 2020/02/23 09:49:24, dak wrote: > Stupid question: does the database design of lilypond-book even allow for > uncoordinated parallel runs? It's not a stupid question; it's a good question. Writing files atomically (open temp file, write, close, rename), seems a lot

Unable to run make on older releases, while doing bug-reseach

Hi, I'm currently trying to hunt down a possible bug (I wrote possible, because I may very well ne intended behaviour. I don't know yet) Using our prereleased installers I found it happened between 2.19.25 and 2.19.26. Then I switched to git, in order to identify the patch which causes the

Re: testing out Docker CI scripts?

> I think the download text would warrant correction. Yes. > I just naively assumed it to be automatically generated in > correspondence with reality. This is an excellent suggestion. Not sure how to implement that easily, but please open a tracker issue so that the idea is not lost.

Re: 2.20.0 release coordination with translation. Other showstoppers?

El 22/2/20 a las 19:25, David Kastrup escribió: So there is a bit of leeway for improvements in the 2.20 documentation even after the 2.20.0 line. Good. I am late, sorry. But I'll hopefully sync Doc-es in a few days. -- Francisco Vila, Ph.D. - Badajoz (Spain) paconet.org , lilypond.es

Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Stupid question: does the database design of lilypond-book even allow for uncoordinated parallel runs? https://codereview.appspot.com/547680043/

Re: testing out Docker CI scripts?

Werner LEMBERG writes: >> The download size for the notation manual comes out at 35MB which is >> about double than what we had for 2.16. I actually find that >> somewhat irritating. I'd have to check the old conversations about >> extractpdfmark and see whether this is indeed where our change