LGTM
https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
File GNUmakefile.in (right):
https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
Many GNU packages auto-generate a ChangeLog file from the
LGTM
https://codereview.appspot.com/575870044/
LGTM
https://codereview.appspot.com/563780044/
commit e325a23887fd93e56da2a13dd59a8b82a8ce74a0
Author: Han-Wen Nienhuys
Date: Wed Mar 11 20:58:46 2020 +0100
Address output-distance problems:
* Run output-distance.py from srcdir
* Generate self-test HTML in out/
https://codereview.appspot.com/563730043/
covered by
commit f756cab383d91faa6430a1c7f1b041f7855721a9
Author: Jonas Hahnfeld
Date: Sat Mar 7 19:44:48 2020 +0100
Issue 5834/2: Use UTF-8 for all conversions to / from Scheme
https://codereview.appspot.com/577440043/
commit fd4021a3725cda2fe41079af8208a629dda39f1a
Author: Han-Wen Nienhuys
Date: Sat Mar 14 00:01:03 2020 +0100
Fix output-distance tests
https://codereview.appspot.com/569540043/
On Mar 21, 2020, at 11:26, David Kastrup wrote:
> it got a bit lost in other things, but I think I would want to run
> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
> conventions for template arguments but there are comparatively few of
> those).
OK here. Also, thanks
LGTM
https://codereview.appspot.com/577700043/
On Mar 21, 2020, at 08:25, hanw...@gmail.com wrote:
>
> For context: many projects that I contribute to keep harping about
> trailing whitespace
I recently started using the ws-butler package to limit whitespace changes to
lines that also have substantive changes. It has helped me.
Malte Meyn writes:
> Am 21.03.20 um 19:19 schrieb Han-Wen Nienhuys:
>> On Sat, Mar 21, 2020 at 6:12 PM Malte Meyn wrote:
>>>
>>> Hi list,
>>>
>>> first of all, I’d like thank those who made the make output less
>>> verbose, this makes errors much easier to find. Is there a reason for
>>>
Torsten Hämmerle writes:
> Hi David,
>
> No objections!
> Probably this is, directly after introduction of new stable, the best
> opportunity for tidying up and general re-formatting we'll have in years.
>
> I'm a bit confused though: starting off with fixcc, you are suddenly
> talking about
On Sat, Mar 21, 2020 at 8:10 PM wrote:
>
> On 2020/03/21 19:09:01, hanwenn wrote:
> > You suggested it yourself? I removed the lily/ and scm/ changes to
> > avoid conflicts.
>
> huh!? "maybe we can combine this with running fixcc.py?" doesn't sound
> like "please push immediately"!
"After a
Am 21.03.20 um 19:19 schrieb Han-Wen Nienhuys:
On Sat, Mar 21, 2020 at 6:12 PM Malte Meyn wrote:
Hi list,
first of all, I’d like thank those who made the make output less
verbose, this makes errors much easier to find. Is there a reason for
building every .o file every time a single .cc
On 2020/03/21 19:09:01, hanwenn wrote:
> You suggested it yourself? I removed the lily/ and scm/ changes to
> avoid conflicts.
huh!? "maybe we can combine this with running fixcc.py?" doesn't sound
like "please push immediately"!
https://codereview.appspot.com/547810043/
You suggested it yourself? I removed the lily/ and scm/ changes to
avoid conflicts.
On Sat, Mar 21, 2020 at 7:38 PM wrote:
>
> On 2020/03/21 18:20:09, hanwenn wrote:
> > As discussed, will push this without countdown.
>
> Discussed where? David proposed on lilypond-devel to run fixcc.py
>
On 2020/03/21 18:20:09, hanwenn wrote:
> As discussed, will push this without countdown.
Discussed where? David proposed on lilypond-devel to run fixcc.py
tomorrow, but I see no reference to this patch.
https://codereview.appspot.com/547810043/
LGTM, thanks! I have some nits here and there, though.
https://codereview.appspot.com/553750044/diff/561590043/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/553750044/diff/561590043/Documentation/changes.tely#newcode66
As discussed, will push this without countdown.
On Sat, Mar 21, 2020 at 3:36 PM wrote:
>
> On 2020/03/21 13:14:50, hahnjo wrote:
> > Sending to lilypond-devel for broader notice. This is likely to give
> conflicts,
> > maybe we can combine this with running fixcc.py?
>
> I've backed out scm and
On Sat, Mar 21, 2020 at 6:12 PM Malte Meyn wrote:
>
> Hi list,
>
> first of all, I’d like thank those who made the make output less
> verbose, this makes errors much easier to find. Is there a reason for
> building every .o file every time a single .cc file is changed? It’s
> very time-consuming
Hi list,
first of all, I’d like thank those who made the make output less
verbose, this makes errors much easier to find. Is there a reason for
building every .o file every time a single .cc file is changed? It’s
very time-consuming when you want to test little changes …
make[1]: Entering
Hi David,
No objections!
Probably this is, directly after introduction of new stable, the best
opportunity for tidying up and general re-formatting we'll have in years.
I'm a bit confused though: starting off with fixcc, you are suddenly
talking about fixscm. Is it about cc files, or scm
Hi,
it got a bit lost in other things, but I think I would want to run
fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
conventions for template arguments but there are comparatively few of
those).
It's been run on stable already; so running on master makes future
On 2020/03/21 13:14:50, hahnjo wrote:
> Sending to lilypond-devel for broader notice. This is likely to give
conflicts,
> maybe we can combine this with running fixcc.py?
I've backed out scm and lily so it won't give conflicts with fixcc and
fixscm.
https://codereview.appspot.com/547810043/
On 2020/03/21 14:17:03, dak wrote:
> On 2020/03/21 13:14:50, hahnjo wrote:
> > Sending to lilypond-devel for broader notice. This is likely to give
> conflicts,
> > maybe we can combine this with running fixcc.py?
>
> Ah right, that one was still pending anyway. I think it would take
care of
>
On 2020/03/21 13:14:50, hahnjo wrote:
> Sending to lilypond-devel for broader notice. This is likely to give
conflicts,
> maybe we can combine this with running fixcc.py?
Ah right, that one was still pending anyway. I think it would take care
of trailing spaces in the C++ files.
Sending to lilypond-devel for broader notice. This is likely to give
conflicts, maybe we can combine this with running fixcc.py?
https://codereview.appspot.com/547810043/
Hello,
Here is the current patch countdown list. The next countdown will be on
March 23rd
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
***
Push:
5703 Run scripts/auxiliar/fixcc.py - David Kastrup
commit 7ab9c8fa4faff7a513d0ecfbc7eecf7efd2b8ea8
Author: Han-Wen Nienhuys
Date: Sun Mar 1 17:47:53 2020 +0100
Add a FS lock to lilypond-book
https://codereview.appspot.com/555360043/
Reviewers: 周,
Message:
commit cf95c9a3ef8be6493f2b496b6e99ac708f4dcb68
Author: Han-Wen Nienhuys
Date: Wed Jan 29 07:40:35 2020 +0100
Remove unused declaration Score_performer::header
https://sourceforge.net/p/testlilyissues/issues/5819
http://codereview.appspot.com/571820044
Reviewers: 周,
Message:
commit cf95c9a3ef8be6493f2b496b6e99ac708f4dcb68
Author: Han-Wen Nienhuys
Date: Wed Jan 29 07:40:35 2020 +0100
Remove unused declaration Score_performer::header
https://sourceforge.net/p/testlilyissues/issues/5819
http://codereview.appspot.com/571820044
Reviewers: 周,
Message:
commit cf95c9a3ef8be6493f2b496b6e99ac708f4dcb68
Author: Han-Wen Nienhuys
Date: Wed Jan 29 07:40:35 2020 +0100
Remove unused declaration Score_performer::header
https://sourceforge.net/p/testlilyissues/issues/5819
http://codereview.appspot.com/571820044
commit cf95c9a3ef8be6493f2b496b6e99ac708f4dcb68
Author: Han-Wen Nienhuys
Date: Wed Jan 29 07:40:35 2020 +0100
Remove unused declaration Score_performer::header
https://sourceforge.net/p/testlilyissues/issues/5819
http://codereview.appspot.com/571820044
https://codereview.appspot.com/553700043/diff/545720043/mf/GNUmakefile
File mf/GNUmakefile (right):
https://codereview.appspot.com/553700043/diff/545720043/mf/GNUmakefile#newcode36
mf/GNUmakefile:36: $(call ly_progress,Making,$@,< mf)
On 2020/03/19 08:29:59, hahnjo wrote:
> Should be
commit bbc9f3a208d17670d729bfc08e4b28b0a590bf6f (origin/staging,
origin/master)
Author: Han-Wen Nienhuys
Date: Sun Mar 15 16:08:50 2020 +0100
Remove @BASH@.
Remove compat hack for Solaris7 and HP-UX (Solaris 7 reached EOL in
August 2008. Nobody runs HP-UX anymore.)
On 2020/03/21 11:22:15, hahnjo wrote:
> On 2020/03/21 11:16:12, hanwenn wrote:
> > PTAL
>
> Very please don't clutter diffs with unrelated whitespace changes. If
you think
> we should apply this, please do so independently. After a message to
> lilypond-devel they can probably go into staging ->
On 2020/03/21 11:16:12, hanwenn wrote:
> PTAL
Very please don't clutter diffs with unrelated whitespace changes. If
you think we should apply this, please do so independently. After a
message to lilypond-devel they can probably go into staging -> master
directly without much review.
Also please
PTAL
https://codereview.appspot.com/549740043/
Reviewers: hahnjo,
Message:
On 2020/03/21 08:56:20, hahnjo wrote:
> Could you please copy the comment to all places where you paste the
code?
sure.
Note that the comment is just paraphrasing the documentation for
gettext.install https://docs.python.org/3/library/gettext.html
Description:
Could you please copy the comment to all places where you paste the
code?
https://codereview.appspot.com/549740043/
https://codereview.appspot.com/575860044/diff/547790043/aclocal.m4
File aclocal.m4 (right):
https://codereview.appspot.com/575860044/diff/547790043/aclocal.m4#newcode625
aclocal.m4:625: AC_ARG_VAR(GUILE_FLAVOR, AS_HELP_STRING([],
On 2020/03/21 05:41:05, lemzwerg wrote:
> What about breaking the
40 matches
Mail list logo
