Allow number as MarkEvent.label (issue 316360043 by d...@gnu.org)

[lemzwerg]

LGTM

https://codereview.appspot.com/316360043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCHES - Countdown for Wednesday March 22nd

[David Nalesnik]

On Thu, Mar 23, 2017 at 3:17 PM, James  wrote:
> Hello,
>
>
> On 22/03/17 15:32, Phil Holmes wrote:
>>
>> - Original Message - From: "David Nalesnik"
>> 
>> To: "James" 
>> Cc: "Dev" 
>> Sent: Wednesday, March 22, 2017 1:11 PM
>> Subject: Re: PATCHES - Countdown for Wednesday March 22nd
>>
>>
>>> Hi James,
>>>
>>> On Wed, Mar 22, 2017 at 2:27 AM, James  wrote:

 Hello,

 Here is the current patch countdown list. The next countdown will be on
 March 25th


 A quick synopsis of all patches currently in the review process can be
 found here:

 http://philholmes.net/lilypond/allura/

 

>>>
>>> Just remembered to update an issue for which I supplied a patch to
>>> "Started" (https://sourceforge.net/p/testlilyissues/issues/5097/).
>>> Checking the philholmes site, it's been associated with a Rietveld
>>> issue not mine.  The Allura link points to the right patchset, however
>>> (http://codereview.appspot.com/317460043).
>>>
>>> David
>>
>>
>>
>> My page was designed as a helper for James and it obviously struggles to
>> parse which is the correct Rietveld cited on that issue.  I tried to edit
>> Thomas's post but the edit wasn't successful.  Don't really know what to do
>> but bring it to James's attention and ignore it apart from that.
>
>
> OK I just edited the 'main description' part (I don't know what that field
> is officially called) so that the correct Rietveld is seen right at the
> start.
>
> This is good enough for Phil's scraper.
>
> I'll watch out for that in future.
>
> Thanks
>

Appreciate it!

Thank you,
David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCHES - Countdown for Wednesday March 22nd

[James]

Hello,


On 22/03/17 15:32, Phil Holmes wrote:
- Original Message - From: "David Nalesnik" 


To: "James" 
Cc: "Dev" 
Sent: Wednesday, March 22, 2017 1:11 PM
Subject: Re: PATCHES - Countdown for Wednesday March 22nd



Hi James,

On Wed, Mar 22, 2017 at 2:27 AM, James  wrote:

Hello,

Here is the current patch countdown list. The next countdown will be on
March 25th


A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/





Just remembered to update an issue for which I supplied a patch to
"Started" (https://sourceforge.net/p/testlilyissues/issues/5097/).
Checking the philholmes site, it's been associated with a Rietveld
issue not mine.  The Allura link points to the right patchset, however
(http://codereview.appspot.com/317460043).

David



My page was designed as a helper for James and it obviously struggles 
to parse which is the correct Rietveld cited on that issue.  I tried 
to edit Thomas's post but the edit wasn't successful.  Don't really 
know what to do but bring it to James's attention and ignore it apart 
from that.


OK I just edited the 'main description' part (I don't know what that 
field is officially called) so that the correct Rietveld is seen right 
at the start.


This is good enough for Phil's scraper.

I'll watch out for that in future.

Thanks

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Hans Åberg]

> On 23 Mar 2017, at 11:18, Andrew Bernard  wrote:

> My understanding of copyright is that the date range applies to the
> published work as a whole, and does not operate on the granularity of
> individual components.

I am told there should be all years it has been published.

> Furthermore, there is no legal requirement to
> actually have a copyright notice at all, as works are naturally copyright
> nowadays, and the notice is really only as a partial, and not critical,
> piece of backup evidence used if cases go to court.

Only in some legislations, so add it to be sure.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Degenerate file access patterns

[Trevor]

Downloaded binary.

On Thu, Mar 23, 2017 at 2:38 PM Han-Wen Nienhuys  wrote:

> Trevor, did you compile it from scratch or are you using the packaged
> binary?
>
>
> On Thu, Mar 23, 2017 at 11:42 AM, Trevor  wrote:
> > I don't know enough to be very helpful, but I can report that on Ubuntu,
> I
> > also see  "9925953   90234" from strace.
> >
> > On Tue, Mar 21, 2017 at 10:33 AM Han-Wen Nienhuys 
> wrote:
> >>
> >> the repeating syscall is the read, on the same file descriptor. If
> >> fontconfig failed a cache, you'd more likely see
> >>
> >>  open() = 6
> >>  read(6, .. )
> >>  close(6)
> >>  open() = 6
> >>  read(6, .. )
> >>  close(6)
> >>
> >> I think.
> >>
> >> I'll have a look again tonight. Maybe I can attach a debugger (my
> >> machine has long lost the ability to compile lilypond. Sigh.)
> >>
> >> On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG  wrote:
> >> >
> >> >>> "The culprit is that the lilypond binary has a bit sub-optimal file
> >> >>> access pattern (opening the same file thousands of times and
> >> >>> reading it byte by byte, causing a syscall flood - nearly 500K
> >> >>> lseek and read operations).  On a local machine, because of this
> >> >>> issue, it will spend about 1s in I/O syscalls, which is half of the
> >> >>> total execution time. This currently does not play nice with our
> >> >>> systems, getting it from 1s to over half a minute."
> >> >
> >> > Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
> >> >
> >> >> The font support is reading the same section of some font file over
> >> >> and over again.
> >> >>
> >> >> $ cat f.ly
> >> >> { c }
> >> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> >> 9925953   90234
> >> >
> >> > On my box this is
> >> >
> >> >   1   6  88
> >> >
> >> >> $ grep OTTO log|head -10
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >>
> >> >> the number of calls is apparently proportional to the number of
> glyphs
> >> >> in the file:
> >> >>
> >> >> $ cat f.ly
> >> >> \repeat unfold 100 { c }
> >> >>
> >> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> >> 40929  245575 3724501
> >> >
> >> > For me, it is again
> >> >
> >> >   1   6  88
> >> >
> >> >> Werner may have better hunches than I which code is really
> >> >> responsible for this.
> >> >
> >> > Maybe a problem with fontconfig?  Where is the location of
> >> > fontconfig's database of available fonts on your system?  This must be
> >> > created in advance so that lilypond can access it.  If it is missing,
> >> > fontconfig tries to build it (which makes e.g. the first invocation of
> >> > lilypond very slow on a Windows box since there is no global
> >> > fontconfig database).
> >> >
> >> > Is it possible that fontconfig always fails so that it tries again and
> >> > again?
> >> >
> >> >
> >> > Werner
> >>
> >>
> >>
> >> --
> >> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
>
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Degenerate file access patterns

[Han-Wen Nienhuys]

Trevor, did you compile it from scratch or are you using the packaged binary?


On Thu, Mar 23, 2017 at 11:42 AM, Trevor  wrote:
> I don't know enough to be very helpful, but I can report that on Ubuntu, I
> also see  "9925953   90234" from strace.
>
> On Tue, Mar 21, 2017 at 10:33 AM Han-Wen Nienhuys  wrote:
>>
>> the repeating syscall is the read, on the same file descriptor. If
>> fontconfig failed a cache, you'd more likely see
>>
>>  open() = 6
>>  read(6, .. )
>>  close(6)
>>  open() = 6
>>  read(6, .. )
>>  close(6)
>>
>> I think.
>>
>> I'll have a look again tonight. Maybe I can attach a debugger (my
>> machine has long lost the ability to compile lilypond. Sigh.)
>>
>> On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG  wrote:
>> >
>> >>> "The culprit is that the lilypond binary has a bit sub-optimal file
>> >>> access pattern (opening the same file thousands of times and
>> >>> reading it byte by byte, causing a syscall flood - nearly 500K
>> >>> lseek and read operations).  On a local machine, because of this
>> >>> issue, it will spend about 1s in I/O syscalls, which is half of the
>> >>> total execution time. This currently does not play nice with our
>> >>> systems, getting it from 1s to over half a minute."
>> >
>> > Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
>> >
>> >> The font support is reading the same section of some font file over
>> >> and over again.
>> >>
>> >> $ cat f.ly
>> >> { c }
>> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
>> >> 9925953   90234
>> >
>> > On my box this is
>> >
>> >   1   6  88
>> >
>> >> $ grep OTTO log|head -10
>> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>> >>
>> >> the number of calls is apparently proportional to the number of glyphs
>> >> in the file:
>> >>
>> >> $ cat f.ly
>> >> \repeat unfold 100 { c }
>> >>
>> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
>> >> 40929  245575 3724501
>> >
>> > For me, it is again
>> >
>> >   1   6  88
>> >
>> >> Werner may have better hunches than I which code is really
>> >> responsible for this.
>> >
>> > Maybe a problem with fontconfig?  Where is the location of
>> > fontconfig's database of available fonts on your system?  This must be
>> > created in advance so that lilypond can access it.  If it is missing,
>> > fontconfig tries to build it (which makes e.g. the first invocation of
>> > lilypond very slow on a Windows box since there is no global
>> > fontconfig database).
>> >
>> > Is it possible that fontconfig always fails so that it tries again and
>> > again?
>> >
>> >
>> > Werner
>>
>>
>>
>> --
>> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043by g...@ursliska.de)

[Werner LEMBERG]

> A question I have is then: how can we ensure this is actually done
> *every* year? It actually *is* embarrassing that the released
> versions give a wrong year in the output of lilypond --version.

This is a different issue.  Right now, the version number shown in
`--version' must be updated manually, since it is not a file's
copyright notice.

> Can running make grand-replace (and committing the results) be made
> part of the release process?

The basic question is whether `grand-replace' actually handles the
`--version' messages also...  IMHO, it should.  Then it is fully
sufficient to run it manually at the beginning of new year.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043by g...@ursliska.de)

[Urs Liska]

Am 23.03.2017 um 12:04 schrieb Phil Holmes:
> - Original Message - From: "Andrew Bernard"
> 
> To: "Urs Liska" ; "Devel" 
> Sent: Thursday, March 23, 2017 10:18 AM
> Subject: Re: Update copyright for 2016/17 files, and script (issue
> 320390043by g...@ursliska.de)
>
>
>> Hi Urs,
>>
>> My understanding of copyright is that the date range applies to the
>> published work as a whole, and does not operate on the granularity of
>> individual components. Furthermore, there is no legal requirement to
>> actually have a copyright notice at all, as works are naturally
>> copyright
>> nowadays, and the notice is really only as a partial, and not critical,
>> piece of backup evidence used if cases go to court.
>>
>> I speak from my knowledge of copyright in Australia, which is bound
>> to be
>> different to Germany, as copyright law is inconsistent across regions.
>>
>> Andrew
>
> I think the copyright notice is a requirement of the GNU Ts and Cs:
>
> "Whichever license you plan to use, the process involves adding two
> elements to each source file of your program: a copyright notice (such
> as "Copyright 1999 Terry Jones"), and a statement of copying
> permission, saying that the program is distributed under the terms of
> the GNU General Public License (or the Lesser GPL)."
>
> https://www.gnu.org/licenses/gpl-howto.html
>

Yes, but this doesn't change the question of whether all files should
have the latest year or their individual "latest year".

I think it's clear by now that we don't need the individual updates.

A question I have is then: how can we ensure this is actually done
*every* year? It actually *is* embarrassing that the released versions
give a wrong year in the output of lilypond --version.

Can running make grand-replace (and committing the results be made part
of the release process? I think in all cases where no new files (with
copied wrong years) are added to the code base this should actually not
introduce any changes.

Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043by g...@ursliska.de)

[Phil Holmes]

- Original Message - 
From: "Andrew Bernard" 

To: "Urs Liska" ; "Devel" 
Sent: Thursday, March 23, 2017 10:18 AM
Subject: Re: Update copyright for 2016/17 files, and script (issue 
320390043by g...@ursliska.de)




Hi Urs,

My understanding of copyright is that the date range applies to the
published work as a whole, and does not operate on the granularity of
individual components. Furthermore, there is no legal requirement to
actually have a copyright notice at all, as works are naturally copyright
nowadays, and the notice is really only as a partial, and not critical,
piece of backup evidence used if cases go to court.

I speak from my knowledge of copyright in Australia, which is bound to be
different to Germany, as copyright law is inconsistent across regions.

Andrew


I think the copyright notice is a requirement of the GNU Ts and Cs:

"Whichever license you plan to use, the process involves adding two elements 
to each source file of your program: a copyright notice (such as "Copyright 
1999 Terry Jones"), and a statement of copying permission, saying that the 
program is distributed under the terms of the GNU General Public License (or 
the Lesser GPL)."


https://www.gnu.org/licenses/gpl-howto.html

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Degenerate file access patterns

[Trevor]

I don't know enough to be very helpful, but I can report that on Ubuntu, I
also see  "9925953   90234" from strace.

On Tue, Mar 21, 2017 at 10:33 AM Han-Wen Nienhuys  wrote:

> the repeating syscall is the read, on the same file descriptor. If
> fontconfig failed a cache, you'd more likely see
>
>  open() = 6
>  read(6, .. )
>  close(6)
>  open() = 6
>  read(6, .. )
>  close(6)
>
> I think.
>
> I'll have a look again tonight. Maybe I can attach a debugger (my
> machine has long lost the ability to compile lilypond. Sigh.)
>
> On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG  wrote:
> >
> >>> "The culprit is that the lilypond binary has a bit sub-optimal file
> >>> access pattern (opening the same file thousands of times and
> >>> reading it byte by byte, causing a syscall flood - nearly 500K
> >>> lseek and read operations).  On a local machine, because of this
> >>> issue, it will spend about 1s in I/O syscalls, which is half of the
> >>> total execution time. This currently does not play nice with our
> >>> systems, getting it from 1s to over half a minute."
> >
> > Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
> >
> >> The font support is reading the same section of some font file over
> >> and over again.
> >>
> >> $ cat f.ly
> >> { c }
> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> 9925953   90234
> >
> > On my box this is
> >
> >   1   6  88
> >
> >> $ grep OTTO log|head -10
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >>
> >> the number of calls is apparently proportional to the number of glyphs
> >> in the file:
> >>
> >> $ cat f.ly
> >> \repeat unfold 100 { c }
> >>
> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> 40929  245575 3724501
> >
> > For me, it is again
> >
> >   1   6  88
> >
> >> Werner may have better hunches than I which code is really
> >> responsible for this.
> >
> > Maybe a problem with fontconfig?  Where is the location of
> > fontconfig's database of available fonts on your system?  This must be
> > created in advance so that lilypond can access it.  If it is missing,
> > fontconfig tries to build it (which makes e.g. the first invocation of
> > lilypond very slow on a Windows box since there is no global
> > fontconfig database).
> >
> > Is it possible that fontconfig always fails so that it tries again and
> > again?
> >
> >
> > Werner
>
>
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Andrew Bernard]

Hi Urs,

My understanding of copyright is that the date range applies to the
published work as a whole, and does not operate on the granularity of
individual components. Furthermore, there is no legal requirement to
actually have a copyright notice at all, as works are naturally copyright
nowadays, and the notice is really only as a partial, and not critical,
piece of backup evidence used if cases go to court.

I speak from my knowledge of copyright in Australia, which is bound to be
different to Germany, as copyright law is inconsistent across regions.

Andrew



On 23 March 2017 at 18:13, Urs Liska  wrote:

>
>
> Finally, if my initial assumption about the copyright notice is correct,
> this script should not be run manually at the beginning of each year
> (which obviously doesn't always happen anyway) but at regular intervals,
> e.g. before/after each merge to master (probably too noisy for the
> history) or at least before each release.
>
> Opinions?
> Urs
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Werner LEMBERG]

> So if we do have a script that automatically updates only changed
> files nothing speaks against using it, isn't it?

Well, yes, but I don't see an advantage.  Today, using gitk or
something similar, you can very easily track changes.  Having
identical copyright notices in all files of lilypond is more appealing
to me.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Urs Liska]

Am 23.03.2017 um 08:19 schrieb Werner LEMBERG:
>> Unfortunately I don't find a link right now, but it is my
>> understanding that the copyright notice should only be updated to
>> files that have actually been modified.
> AFAIK, this is not correct.  The copyright is applied to the *package*
> lilypond, so if *any* file changes, the copyright notice of all files
> should be updated.
>
>   https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

Thanks, this might have saved me some work.

Concretely the page says "it is not required to keep track of which
files have seen significant changes in the new year and which have not.
It is recommended and simpler to add the new year to all files in the
package, and be done with it for the rest of the year."

So if we do have a script that automatically updates only changed files
nothing speaks against using it, isn't it? I would say "recommended and
simpler" is actually meaning "recommended because it simpler" ...

Urs

>
> Werner

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Werner LEMBERG]

> Unfortunately I don't find a link right now, but it is my
> understanding that the copyright notice should only be updated to
> files that have actually been modified.

AFAIK, this is not correct.  The copyright is applied to the *package*
lilypond, so if *any* file changes, the copyright notice of all files
should be updated.

  https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

[Urs Liska]

Am 23.03.2017 um 01:50 schrieb gra...@percival-music.ca:
> Could you separate the "Run script xyz" changes from the changes to
> script(s)?  That would help to see exactly what's happening here.

Yes, I'll do so, but this patch isn't really intended to be merged as-is
anyway.

>
>
> https://codereview.appspot.com/320390043/diff/1/scripts/auxiliar/update-copyright.sh
>
> File scripts/auxiliar/update-copyright.sh (right):
>
> https://codereview.appspot.com/320390043/diff/1/scripts/auxiliar/update-copyright.sh#newcode3
>
> scripts/auxiliar/update-copyright.sh:3: echo "Update copyright dates in
> LilyPond sources"
> Sorry I didn't notice this earlier.  

Yes, this would have made my take a different approach when I had
initially asked about the copyright statement issue.

> How does this differ from
>
> make grand-replace
>
> ?
> http://lilypond.org/doc/v2.19/Documentation/contributor/unsorted-policies

The main difference (in intention, regardless of any coding flaws that
may be in my script) is that my script updates the copyright message
only if the file has been changed in the "target" year ("now" by
default). Unfortunately I don't find a link right now, but it is my
understanding that the copyright notice should only be updated to files
that have actually been modified. My script still gives false positives,
as for example recently some files have been renamed, which is not a
copyrightable modification but causes a change to Git's view of the
file, but I think it is still better than globally changing *all* files.

What I didn't know (and therefore failed to implement) is the idea of
filtering external files.

So what I basically should do now is drop my shell script and
incorporate the "last updated" logic into the grand-replace.py script.
Maybe I can do some more vetting of the individual files, e.g. to filter
out trivial changes (like updating the copyright string or file renaming).

In addition I'd like to bring up the concern that Hans Åberg has raised:
what about files that are *generated* from Flex or Bison sources,
shouldn't such files be regenerated too? And how to find them?

Finally, if my initial assumption about the copyright notice is correct,
this script should not be run manually at the beginning of each year
(which obviously doesn't always happen anyway) but at regular intervals,
e.g. before/after each merge to master (probably too noisy for the
history) or at least before each release.

Opinions?
Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel