Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, hanwenn, Message: On 2020/02/16 21:24:59, dak wrote: > It's also the only thing that we needed a C compiler (rather than C++) for. > Well, at least regarding native compilation. GUB of course needs a C compiler > for bootstrapping the cross-building environment. But that

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

On 2020/02/16 21:23:56, hanwenn wrote: > On Sun, Feb 16, 2020 at 9:57 PM wrote: > > > > In this commit, extra support for the case where command-and-args is > > empty was added, ie. > > > > That characterisation is completely wrong. The support is not for the > > cases

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

Han-Wen Nienhuys writes: > On Sun, Feb 16, 2020 at 9:57 PM wrote: > >> > In this commit, extra support for the case where command-and-args is >> empty was added, ie. >> >> That characterisation is completely wrong. The support is not for the >> cases "where command-and-args is empty" but

Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

please, for the love of god, do not use automake. It is slow and arcane, and generally a complete PITA to work with. We created stepmake after fighting with automake for a while. https://codereview.appspot.com/555300044/

Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

On 2020/02/16 21:12:50, lemzwerg wrote: > Good idea, thanks! LGTM. > > Apropos .lo files: We can remove STEPMAKE_LIBTOOL in `aclocal.m4` since it isn't > used. I think this change would probably fit into this issue, too. .lo files were likely needed for the midi module used in some Python

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

On Sun, Feb 16, 2020 at 9:57 PM wrote: > > In this commit, extra support for the case where command-and-args is > empty was added, ie. > > That characterisation is completely wrong. The support is not for the > cases "where command-and-args is empty" but rather where > command-and-args is not a

Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

Good idea, thanks! LGTM. Apropos .lo files: We can remove STEPMAKE_LIBTOOL in `aclocal.m4` since it isn't used. I think this change would probably fit into this issue, too. https://codereview.appspot.com/555300044/

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

> In this commit, extra support for the case where command-and-args is empty was added, ie. That characterisation is completely wrong. The support is not for the cases "where command-and-args is empty" but rather where command-and-args is not a list but a single symbol. Just like (define

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

On 2020/02/16 20:37:34, hanwenn wrote: > David, this goes on top of https://codereview.appspot.com/555300043/ > > maybe I am missing something, but the regtest completes successfully. Why did > you add this stuff? To allow for making aliases etc. A markup command definition involves a number of

Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

Reviewers: dak, Message: David, this goes on top of https://codereview.appspot.com/555300043/ maybe I am missing something, but the regtest completes successfully. Why did you add this stuff? Description: Simplify define-markup-[list-]command-internal, This reverts additions made in commit

Re: Master ahead of staging

On Sun, Feb 16, 2020 at 6:56 PM David Kastrup wrote: > >> Han-Wen Nienhuys writes: > >> > >> > sorry, my mistake (another reason to move to different tooling.) > >> > >> I very strongly disagree. We don't want to move to a tooling where > >> material that is untested in its context gets pushed

Re: Master ahead of staging

Han-Wen Nienhuys writes: > On Sun, Feb 16, 2020 at 5:23 PM David Kastrup wrote: > >> Han-Wen Nienhuys writes: >> >> > sorry, my mistake (another reason to move to different tooling.) >> >> I very strongly disagree. We don't want to move to a tooling where >> material that is untested in its

Re: Master ahead of staging

On Sun, Feb 16, 2020 at 5:23 PM David Kastrup wrote: > Han-Wen Nienhuys writes: > > > sorry, my mistake (another reason to move to different tooling.) > > I very strongly disagree. We don't want to move to a tooling where > material that is untested in its context gets pushed to the resource >

Re: Master ahead of staging

Han-Wen Nienhuys writes: > sorry, my mistake (another reason to move to different tooling.) I very strongly disagree. We don't want to move to a tooling where material that is untested in its context gets pushed to the resource everybody is dependent on. We have set up the staging system for

Re: Quarter Note Support for All Languages etc.

Wols Lists wrote > Don't forget that where you use the word "English", I believe the > standard is that you actually *mean* American. Does that have any impact > on your work? > > (For example, your very subject line is not English - if it were it > would read "Crotchet Support ..." :-) Hi Wol,

Express define-markup-list-command-internal using define-markup-command-internal (issue 555300043 by hanw...@gmail.com)

Not tested, but from reading: very nice. LGTM https://codereview.appspot.com/555300043/

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly File input/regression/multi-measure-rest-reminder.ly (right): https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26

Re: axis-group-interface: avoid some cast warnings (issue 583510045 by hanw...@gmail.com)

https://codereview.appspot.com/583510045/diff/559490043/lily/axis-group-interface.cc File lily/axis-group-interface.cc (right): https://codereview.appspot.com/583510045/diff/559490043/lily/axis-group-interface.cc#newcode277 lily/axis-group-interface.cc:277: Interval_t rank_span

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

Sorry being that late to the party. Though, I'm confused. Iiuc a new grob called MultiMeasureRestReminder should be created. Alas, if I try to insert \override Voice.MultiMeasureRestReminder.after-line-breaking = #'() I get: warning: not a grob name, `MultiMeasureRestReminder' What am I missing?

axis-group-interface: avoid some cast warnings (issue 583510045 by hanw...@gmail.com)

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

Issue 5766: fix various warnings (issue 583510043 by nine.fierce.ball...@gmail.com)

LGTM, thanks. https://codereview.appspot.com/583510043/

Re: Master ahead of staging

sorry, my mistake (another reason to move to different tooling.) It looks like savannah doesn't want people to do non-ff pushes; I've pushed staging to be at the same commit. [hanwen@localhost scm]$ git push origin HEAD:staging Total 0 (delta 0), reused 0 (delta 0) To

Master ahead of staging

Hello, Master is now ahead of staging - this will break patchy staging right? --snip-- input/regression/multi-measure-rest-reminder: a demo of user-defined grobs master author    Han-Wen Nienhuys     Mon, 10 Feb 2020 21:10:35 + (22:10 +0100) committer    Han-Wen Nienhuys     Sun, 16

Re: Inline assembler fallback for _FPU_SETCW() missing in x86 platforms (issue 575600043 by thomasmorle...@gmail.com)

On 2020/02/01 00:52:15, thomasmorley651 wrote: > This adds Masamichi-san's suggestions from > https://codereview.appspot.com/577450043/ > Comment #7 > Sorry, for the new issue, initiated by accident > > This does _not_ reflect the discussion of >

PATCHES - Countdown for February 16th

Hello, Here is the current patch countdown list. The next countdown will be on February 18th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5750 Drop support for multiple configurations - Jonas

Re: Quarter Note Support for All Languages etc.

On 15/02/20 17:54, Torsten Hämmerle wrote: > Rather than English names (Dutch, German, Italian...), we are using country > specific proper names (nederlands, deutsch, italiano, ...). Don't forget that where you use the word "English", I believe the standard is that you actually *mean* American.

Re: Quarter Note Support for All Languages etc.

El 15/2/20 a las 19:19, Joram Noeck escribió: FWIW, I remember when "français" was introduced. I could not find it in the archives. But I think the consensus was that a correct spelling is better than sticking to ascii and that is why español was added because it was obvious. So without finding