Re: guilev1/2 musing

2019-01-25 Thread Thomas Morley
Am Fr., 25. Jan. 2019 um 15:46 Uhr schrieb Paul Morris : > > On 1/24/19 3:08 PM, Thomas Morley wrote: > > > From my point of view (and limited knowledge) other newly implemented > > guilev2-procedures are not _that_ important. > Since guile2 appears to work well enough at this point, aside from

Re: grand copyright replacement

2019-01-25 Thread Werner LEMBERG
>> Assuming we are running `grand-replace' next year again this would >> be (in almost all cases) a one-time job. > > Would there be a way to automate it so the first build run in a new > year updates all the copyrights? Well, the *proper* way IMHO would be to use gnulib's `update-copyright'

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Matthias Kilian writes: > On Fri, Jan 25, 2019 at 07:43:10AM +0100, Werner LEMBERG wrote: >> I'm going to run `scripts/build/grand-replace' to update all copyright >> years. > > I'm not completely sure, but shouldn't the copyright year(s) in a work > only cover the years when the work was

Re: grand copyright replacement

2019-01-25 Thread Matthias Kilian
On Fri, Jan 25, 2019 at 07:43:10AM +0100, Werner LEMBERG wrote: > I'm going to run `scripts/build/grand-replace' to update all copyright > years. I'm not completely sure, but shouldn't the copyright year(s) in a work only cover the years when the work was originally written or modified? Ciao,

Re: guilev1/2 musing

2019-01-25 Thread Jan-Peter Voigt
Hi there, just a few words on my work on musicxml export: There is an openlilylib project that provides an export command. It is based on an engraver that collects all events and builds an abstract structure that can be serialized by an export module. One of them writes MusicXML. Alex Roitman

Re: guilev1/2 musing

2019-01-25 Thread David Kastrup
Paul Morris writes: > On 1/24/19 3:08 PM, Thomas Morley wrote: > >> From my point of view (and limited knowledge) other newly implemented >> guilev2-procedures are not _that_ important. > > One area where guile2 (and upcoming guile3) would be useful is for > MusicXML export.  David Garfinkle's

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

2019-01-25 Thread Masamichi Hosoda
>>> Is dir guaranteed to be a relative path? >> >> It seems that there is no guarantee. >> But, `make check` invokes `output-distance` with relative paths. >> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=GNUmakefile.in;h=da1f6f64e088756e07d20f8e1603ccc3a102053e;hb=HEAD#l340 >> >>

Re: guilev1/2 musing

2019-01-25 Thread Paul Morris
On 1/24/19 3:08 PM, Thomas Morley wrote: From my point of view (and limited knowledge) other newly implemented guilev2-procedures are not _that_ important. One area where guile2 (and upcoming guile3) would be useful is for MusicXML export.  David Garfinkle's summer of code project (mentored

Re: grand copyright replacement

2019-01-25 Thread James Lowe
Hello, On Fri, 25 Jan 2019 12:48:51 +0100, David Kastrup wrote: > Werner LEMBERG writes: > > >>> I'm going to run `scripts/build/grand-replace' to update all > >>> copyright years. However, my test run shows that there are a bunch > >>> of files that aren't covered, for example > >>>

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Werner LEMBERG writes: >>> I'm going to run `scripts/build/grand-replace' to update all >>> copyright years. However, my test run shows that there are a bunch >>> of files that aren't covered, for example >>> `lily/part-combine-part-iterator.cc', which has the following >>> copyright notice:

Re: grand copyright replacement

2019-01-25 Thread Karlin High
On 1/25/2019 5:16 AM, Werner LEMBERG wrote: Assuming we are running `grand-replace' next year again this would be (in almost all cases) a one-time job. Would there be a way to automate it so the first build run in a new year updates all the copyrights? -- Karlin High Missouri, USA

Re: grand copyright replacement

2019-01-25 Thread Carl Sorensen
On 1/25/19, 4:16 AM, "lilypond-devel on behalf of Werner LEMBERG" wrote: So is it OK to simply update the missing cases? Assuming we are running `grand-replace' next year again this would be (in almost all cases) a one-time job. In my opinion, yes. Thanks for looking at this.

Re: grand copyright replacement

2019-01-25 Thread Werner LEMBERG
>> I'm going to run `scripts/build/grand-replace' to update all >> copyright years. However, my test run shows that there are a bunch >> of files that aren't covered, for example >> `lily/part-combine-part-iterator.cc', which has the following >> copyright notice: >> >> Copyright (C) 2015

Re: guilev1/2 musing

2019-01-25 Thread Thomas Morley
Am Fr., 25. Jan. 2019 um 10:53 Uhr schrieb Valentin Villenave : > > On 1/25/19, Thomas Morley wrote: > > Over the years some people worked on the topic - speaking only for > > myself, I think all low hanging fruits are done. > > Indeed. Lily-guile2 actually works pretty well (if you don’t mind

Re: guilev1/2 musing

2019-01-25 Thread David Kastrup
Valentin Villenave writes: > On 1/25/19, Thomas Morley wrote: >> Over the years some people worked on the topic - speaking only for >> myself, I think all low hanging fruits are done. > > Indeed. Lily-guile2 actually works pretty well (if you don’t mind the > noticeable performance hit); I

Re: guilev1/2 musing

2019-01-25 Thread Valentin Villenave
On 1/25/19, Thomas Morley wrote: > Over the years some people worked on the topic - speaking only for > myself, I think all low hanging fruits are done. Indeed. Lily-guile2 actually works pretty well (if you don’t mind the noticeable performance hit); I think I’ve been using it nearly-daily for

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Werner LEMBERG writes: > I'm going to run `scripts/build/grand-replace' to update all copyright > years. However, my test run shows that there are a bunch of files > that aren't covered, for example `lily/part-combine-part-iterator.cc', > which has the following copyright notice: > >