#5703 Run scripts/auxiliar/fixcc.py imminent

Hi, I've run scripts/auciliar/fixcc.py on the stable branch now. So that it is reasonably easy to cherry-pick new commits from master into the stable branch, it would make sense doing that in staging/master as well. This is a common base heeding our previously established coding style mostly.

Final 2.20.0 countdown to rollout (was: Doc-es done [Re: [translations] Uh, are we done yet for 2.20 ?])

Federico Bruni writes: > Il giorno ven 28 feb 2020 alle 20:31, Francisco Vila > ha scritto: >> El 28/2/20 a las 10:43, Francisco Vila escribió: >>> I have never made docs in this computer, maybe I should try now, >>> but my idea is to complete the translation first. >> I'm done. Zero diff lines

Re: output-distance: treat non-existent files as empty string (issue 583590043 by hanw...@gmail.com)

On 2020/02/28 23:31:17, Dan Eble wrote: > This does not look good. I expect this change to break the feature I added in > 0d72930e579a5784ecb26da2f9880d8c9da05e71 (Issue 5635). Well, a call to strip > (None) is possibly evidence that someone already broke it, but let's at least > avoid making it w

Re: ly:page-turn-breaking core dumps

On Fri, Feb 28, 2020 at 8:46 PM Pierre-Luc Gauthier wrote: > > The Page_turn_engraver interprets \bar "||" > > especially, allowing a page turn. This triggers a problem in the page > > breaking code, because the start of the score is treated separately. > > I see. Very interesting ! > I did looked

Re: page-turn-breaking core dumps

On Fri, Feb 28, 2020 at 8:20 PM Carl Sorensen wrote: > > > > This is not about a random addition. \bar "||" is normally never at > the start of a piece. The Page_turn_engraver interprets \bar "||" > especially, allowing a page turn. This triggers a problem in the page > breaking c

Re: How to report `FontForge` problems while creating LilyPond fonts

> I'll open up a ticket and upload a patch as soon as it's finished > (it already works, but I want a proper solution). Great, thanks! > *By the way:* how about TABs? Obviously, gitk, Rietveld et al. seem > to use 8 spaces per tab. I've just committed a patch that converts tabs to spaces in al

Add comments to code related to page breaking/layout (issue 563630043 by hanw...@gmail.com)

LGTM. Please feel free to ignore (most of) my remarks if you consider such nitpicking as unnecessary :-) https://codereview.appspot.com/563630043/diff/571770043/lily/include/page-breaking.hh File lily/include/page-breaking.hh (right): https://codereview.appspot.com/563630043/diff/571770043/lily

Re: ly:page-turn-breaking core dumps

Le ven. 28 févr. 2020 à 14:16, Han-Wen Nienhuys a écrit : > \bar "||" is normally never at > the start of a piece. -_-' Oops, I haven't even realized I had a "||" bar on bar 1. I guess it creeped up there from copy paste or structure changes… > The Page_turn_engraver interprets \bar "||" > espec

Re: page-turn-breaking core dumps

On 2/28/20, 12:17 PM, "lilypond-devel on behalf of Han-Wen Nienhuys" wrote: On Fri, Feb 28, 2020 at 8:03 PM Pierre-Luc Gauthier wrote: > > You can make the crash go away by removing the \bar "||" at the start > > of the score > > Same as above. > I know the p

Re: ly:page-turn-breaking core dumps

On Fri, Feb 28, 2020 at 8:03 PM Pierre-Luc Gauthier wrote: > > You can make the crash go away by removing the \bar "||" at the start > > of the score > > Same as above. > I know the problem can be avoided by e.g. writing some more music, > changing the Staff size, or any other random modification

Re: ly:page-turn-breaking core dumps

Hello Han-Wen, > On Fri, Feb 28, 2020 at 4:17 PM Han-Wen Nienhuys wrote: > > I have reduced to a tiny example. Great ! Very much tinier indeed. > > On Wed, Feb 26, 2020 at 10:02 AM Han-Wen Nienhuys wrote: > > > The problem happens on the first page of the bass part, where we have > > > to fit

Re: sources: fix handling of non-existent include files (issue 547700043 by hanw...@gmail.com)

i have this now: commit d8aaab93d8c640dc6343c3dfdcf18e69ccc6 (HEAD -> not-found) Author: Han-Wen Nienhuys Date: Fri Feb 28 19:03:23 2020 +0100 sources: fix handling of non-existent include files The following commit caused String::String to be called with a null pointer:

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

On 2020/02/28 17:57:06, hanwenn wrote: > On 2020/02/26 11:59:14, dak wrote: > > It doesn't state at all what happens in cases of contentions. Fixing > > contentions with a lock is a brute-force solution just not allowing for > > parallelism, but it is a solution to the contention problem. > > >

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

On 2020/02/26 11:59:14, dak wrote: > On 2020/02/26 08:28:33, hahnjo wrote: > > On 2020/02/26 08:19:39, hahnjo wrote: > > > > > On a philosophical level, it is a lilypond-book implementation detail > > > > that it can't deal with concurrent invocation, so the remediation for > > > > this problem sh

Re: dump lilypond-book log files in $(outdir) (issue 555330043 by hanw...@gmail.com)

Reviewers: lemzwerg, Message: commit dd4719211a0abe2399b5c17445989ffa68c7bef4 Author: Han-Wen Nienhuys Date: Fri Feb 21 18:29:22 2020 +0100 dump lilypond-book log files in $(outdir) https://sourceforge.net/p/testlilyissues/issues/5782 http://codereview.appspot.com/555330043

output-distance: treat non-existent files as empty string (issue 583590043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/583590043/

Re: Cleanup lilypond-book source (issue 583570043 by hanw...@gmail.com)

commit fa1ec0c100859f7490f524870743f03b54f89ab7 Author: Han-Wen Nienhuys Date: Mon Feb 24 09:40:08 2020 +0100 Reduce memory use of lilypond-book https://codereview.appspot.com/583570043/

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

commit bed9afff763d274af3a2608bdbbc61c807653dbd (origin/staging, origin/master, staging, lylog) Author: Han-Wen Nienhuys Date: Sat Feb 22 22:36:33 2020 +0100 Avoid interaction in tex invocations https://sourceforge.net/p/testlilyissues/issues/5784 http://codereview.appspot.com/

Re: ly:page-turn-breaking core dumps

On Fri, Feb 28, 2020 at 4:17 PM Han-Wen Nienhuys wrote: > > On Wed, Feb 26, 2020 at 10:02 AM Han-Wen Nienhuys wrote: > > > > On Tue, Feb 25, 2020 at 11:56 PM Pierre-Luc Gauthier > > wrote: > > > > > Well, my system is more than a file. Anywho, I will provide a working > > > bug… it sadly wont be

Re: ly:page-turn-breaking core dumps

On Wed, Feb 26, 2020 at 10:02 AM Han-Wen Nienhuys wrote: > > On Tue, Feb 25, 2020 at 11:56 PM Pierre-Luc Gauthier > wrote: > > > Well, my system is more than a file. Anywho, I will provide a working > > bug… it sadly wont be minimal though. > > > > You can send it by private mail. > > > > I'll pr

PATCHES - Countdown for February 28th

Hello, Here is the current patch countdown list. The next countdown will be on March 1st A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5792 .dir-locals.el: spell out nil settings - David Kastrup h

Re: [translations] Our language downloads are chaotic.

Federico Bruni writes: > Il giorno gio 27 feb 2020 alle 16:17, David Kastrup ha > scritto: >> The thing is a nightmare to diagnose since our web server settings >> tell >> the server to serve xxx.it.extension in preference of xxx.extension if >> your browser settings say that you prefer Italia

Re: [translations] Our language downloads are chaotic.

Il giorno gio 27 feb 2020 alle 16:17, David Kastrup ha scritto: Federico Bruni writes: Il giorno gio 27 feb 2020 alle 02:10, David Kastrup ha scritto: For example, try downloading any French documentation from if

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

On 2020/02/28 10:02:46, hanwenn wrote: > https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc > File lily/accidental-engraver.cc (left): > > https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 > lily/accidental-engraver.cc:3

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc File lily/accidental-engraver.cc (left): https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 lily/accidental-engraver.cc:338: (long) trans); On 2020/02/28 09:57:30, hahn

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc File lily/accidental-engraver.cc (left): https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 lily/accidental-engraver.cc:338: (long) trans); On 2020/02/28 09:54:16, hanw

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc File lily/accidental-engraver.cc (left): https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 lily/accidental-engraver.cc:338: (long) trans); ouch - this is terrible. co

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

On 2020/02/28 09:32:57, hahnjo wrote: > On 2020/02/28 09:23:44, benko.pal wrote: > > it may not matter, but actually long is 32 bit, void * is 64 bit on current > > native 64 bit platforms too, I believe. > > Only mingw, on Linux long is 64 bit AFAICT. See also > https://stackoverflow.com/a/384672

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, benko.pal, Message: On 2020/02/28 09:23:44, benko.pal wrote: > it may not matter, but actually long is 32 bit, void * is 64 bit on current > native 64 bit platforms too, I believe. Only mingw, on Linux long is 64 bit AFAICT. See also https://stackoverflow.com/a/384672/1060694

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

it may not matter, but actually long is 32 bit, void * is 64 bit on current native 64 bit platforms too, I believe. https://codereview.appspot.com/579340043/