Re: Woodwind diagrams: Recorder

[Wols Lists]

On 11/01/17 17:54, Francisco Vila wrote:
>  Before starting, I have a question just in case anyone can answer:
> Should I create a Recorder entry into the tin-whistle family in
> scm/display-woodwinds-diagrams.scm, or better create a new Recorder
> family?

My reaction is that the recorder actually belongs to the flute family,
so it would make sense to give it its own family.

My other reaction is that there's a whole bunch of recorders, so again,
grouping them on their own makes sense.

If there's a whole bunch of common code, you could note at the start
that the recorder is similar to and calls out to the tin-whistle family,
or you could just try factoring it out.

Not being a wind player, I get the impression that flute, clarinet and
sax fingerings are all very similar, and are they all bunched together
into one family?

Cheers,
Wol

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Nalesnik]

On Wed, Jan 11, 2017 at 1:52 PM, David Kastrup  wrote:
> David Nalesnik  writes:
>
>> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
>>>
>>> It's nicer to _remove_ the patch from staging instead of adding the
>>> revert on top.  However, that requires more skills.  I can offer to do
>>> this, but you'll still need to remove the patch on your side before
>>> trying to push anything else.
>>>
>>
>> Before this email arrived, I already pushed the revert to staging.
>> Staging hasn't caught up with master yet.  If it's still reasonable to
>> remove the commit and revert, that would be appreciated.  I could do
>> with one fewer blot on the project history in my name!
>
> I've removed commit and revert from staging.  Now you just need to make
> sure that you don't repush them on your next attempt to push something:
> you probably need some invocation of git reset --hard in order to do so.
>

Thank you so much, David!

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Kastrup]

David Nalesnik  writes:

> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
>>
>> It's nicer to _remove_ the patch from staging instead of adding the
>> revert on top.  However, that requires more skills.  I can offer to do
>> this, but you'll still need to remove the patch on your side before
>> trying to push anything else.
>>
>
> Before this email arrived, I already pushed the revert to staging.
> Staging hasn't caught up with master yet.  If it's still reasonable to
> remove the commit and revert, that would be appreciated.  I could do
> with one fewer blot on the project history in my name!

I've removed commit and revert from staging.  Now you just need to make
sure that you don't repush them on your next attempt to push something:
you probably need some invocation of git reset --hard in order to do so.

-- 
David Kastrup

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Nalesnik]

On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
> David Nalesnik  writes:
>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
 Ok, so I will probably do

 git revert HEAD

 in my staging branch

 and push it to origin/staging.

 ---

 I won't attempt to clear the LSR queue in preparation for my patch
 update (as I did) by running makelsr.py again.

 When I update my issue, I'll simply add my snippet to snippets/new,
 and leave updating the LSR to the future (when the frenched-score
 snippet and my proposed snippet and whatever else appears will be
 integrated)
>>>
>>> Sorry my recipe caused a problem in this case.  Normally clearing
>>> the old LSR queue first with makelsr.py would be fine.  But what
>>> you suggest is also OK, as long as someone fixes the problem and
>>> runs makelsr.py reasonably soon - before the next new snippet is
>>> added (I can't run it myself - on my Windows Vista it always tries
>>> to change all the \ to / or vice versa.)
>>>
>>
>> I think the only problem is that @{MarkLines} should be replaced with
>> @code{MarkLines}.
>>
>> I'm stuck in the middle of a make doc checking the change.  When I'm
>> through that, I'll revert the update.
>>
>> Then I can push an update of the snippet to staging.  (But I'll save
>> the makelsr for later as James says.)
>>
>> No problem, it's all a learning experience for me!
>
> It's nicer to _remove_ the patch from staging instead of adding the
> revert on top.  However, that requires more skills.  I can offer to do
> this, but you'll still need to remove the patch on your side before
> trying to push anything else.
>

Before this email arrived, I already pushed the revert to staging.
Staging hasn't caught up with master yet.  If it's still reasonable to
remove the commit and revert, that would be appreciated.  I could do
with one fewer blot on the project history in my name!

Thanks,
David N

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Kastrup]

David Nalesnik  writes:

> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>>
>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>
>>
>>> Ok, so I will probably do
>>>
>>> git revert HEAD
>>>
>>> in my staging branch
>>>
>>> and push it to origin/staging.
>>>
>>> ---
>>>
>>> I won't attempt to clear the LSR queue in preparation for my patch
>>> update (as I did) by running makelsr.py again.
>>>
>>> When I update my issue, I'll simply add my snippet to snippets/new,
>>> and leave updating the LSR to the future (when the frenched-score
>>> snippet and my proposed snippet and whatever else appears will be
>>> integrated)
>>
>> Sorry my recipe caused a problem in this case.  Normally clearing
>> the old LSR queue first with makelsr.py would be fine.  But what
>> you suggest is also OK, as long as someone fixes the problem and
>> runs makelsr.py reasonably soon - before the next new snippet is
>> added (I can't run it myself - on my Windows Vista it always tries
>> to change all the \ to / or vice versa.)
>>
>
> I think the only problem is that @{MarkLines} should be replaced with
> @code{MarkLines}.
>
> I'm stuck in the middle of a make doc checking the change.  When I'm
> through that, I'll revert the update.
>
> Then I can push an update of the snippet to staging.  (But I'll save
> the makelsr for later as James says.)
>
> No problem, it's all a learning experience for me!

It's nicer to _remove_ the patch from staging instead of adding the
revert on top.  However, that requires more skills.  I can offer to do
this, but you'll still need to remove the patch on your side before
trying to push anything else.

-- 
David Kastrup

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

Re: Staging Broken with last makelsr - incorrect TexInfo command format

[David Kastrup]

James  writes:

> Hello,
>
> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent
> makelsr commit
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
>
> contains a malformed TexInfo command
>
> @{Markdown}
>
> Which breaks make doc and so cannot be merged into master.
>
> See my last email about testing patches with new snippets.
>
> Unless you are going to make doc, I suggest that you don't push
> makelsr updates as makelesr doesn't check for incorrect TexInfo
> formats, and while 'make' often catches a lot of these TexInfo issues,
> it wouldn't in this case because this snippet isn't 'checked' until
> the makedoc stage.

The snippets get converted to Texinfo (without graphics) just when doing
"make", so while "make" does not capture LilyPond errors within @texinfo
constructs, it usually balks on Texinfo errors.

-- 
David Kastrup

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Nalesnik]

On Wed, Jan 11, 2017 at 10:59 AM, James  wrote:
> Hello,
>
>
>
> On 11/01/17 16:44, David Nalesnik wrote:
>>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels 
>> wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
 Ok, so I will probably do

 git revert HEAD

 in my staging branch

 and push it to origin/staging.

 ---

 I won't attempt to clear the LSR queue in preparation for my patch
 update (as I did) by running makelsr.py again.

 When I update my issue, I'll simply add my snippet to snippets/new,
 and leave updating the LSR to the future (when the frenched-score
 snippet and my proposed snippet and whatever else appears will be
 integrated)
>>>
>>> Sorry my recipe caused a problem in this case.  Normally clearing
>>> the old LSR queue first with makelsr.py would be fine.  But what
>>> you suggest is also OK, as long as someone fixes the problem and
>>> runs makelsr.py reasonably soon - before the next new snippet is
>>> added (I can't run it myself - on my Windows Vista it always tries
>>> to change all the \ to / or vice versa.)
>>>
>> I think the only problem is that @{MarkLines} should be replaced with
>> @code{MarkLines}.
>>
>> I'm stuck in the middle of a make doc checking the change.  When I'm
>> through that, I'll revert the update.
>>
>> Then I can push an update of the snippet to staging.  (But I'll save
>> the makelsr for later as James says.)
>>
>> No problem, it's all a learning experience for me!
>
>
> The staging merge runs every 4 hours - on my own server - so depending on
> when you eventually push to staging again, if you still see that staging
> hasn't been merged after (obviously) 4 hours it means something is wrong (or
> I suppose there could be a networking issue between the servers doing the
> merge and our git repo).
>
> I deliberately don't configure my machine to send the merge success/fail
> emails because ... corp. IT reasons as you can tell these scripts to post
> something when they do fail, but I usually check manually in the mornings
> anyway and I can see on my server if the merge has failed. But obviously I
> failed to notice yesterday (it was 35 hours between staging update and
> merge) so it isn't an infallible system.
>

OK--just pushed the revert to staging.  Will wait till staging catches
up with master before proceeding.

Thanks for the help and explanations!

David

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

Woodwind diagrams: Recorder

[Francisco Vila]

Hello,

I'd like to create recorder key diagrams like other woodwind
instruments have (thanks to the impressive work Mike Solomon did in
2010).

Recorder diagrams are very simple and the nearest existent instrument
is tin-whistle, just recorders have seven holes, the seventh being
usually drawn with an offset to the left, plus an Octave hole at top
right.

 Before starting, I have a question just in case anyone can answer:
Should I create a Recorder entry into the tin-whistle family in
scm/display-woodwinds-diagrams.scm, or better create a new Recorder
family?

Should I first try making a stand-alone file with uses the existent
functions, or is better to directly modify
display-woodwinds-diagrams.scm?

Thanks. I wonder what is the IDE of choice when developing such
complex Scheme code.


-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[James]

Hello,


On 11/01/17 16:44, David Nalesnik wrote:

On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM



Ok, so I will probably do

git revert HEAD

in my staging branch

and push it to origin/staging.

---

I won't attempt to clear the LSR queue in preparation for my patch
update (as I did) by running makelsr.py again.

When I update my issue, I'll simply add my snippet to snippets/new,
and leave updating the LSR to the future (when the frenched-score
snippet and my proposed snippet and whatever else appears will be
integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries
to change all the \ to / or vice versa.)


I think the only problem is that @{MarkLines} should be replaced with
@code{MarkLines}.

I'm stuck in the middle of a make doc checking the change.  When I'm
through that, I'll revert the update.

Then I can push an update of the snippet to staging.  (But I'll save
the makelsr for later as James says.)

No problem, it's all a learning experience for me!


The staging merge runs every 4 hours - on my own server - so depending 
on when you eventually push to staging again, if you still see that 
staging hasn't been merged after (obviously) 4 hours it means something 
is wrong (or I suppose there could be a networking issue between the 
servers doing the merge and our git repo).


I deliberately don't configure my machine to send the merge success/fail 
emails because ... corp. IT reasons as you can tell these scripts to 
post something when they do fail, but I usually check manually in the 
mornings anyway and I can see on my server if the merge has failed. But 
obviously I failed to notice yesterday (it was 35 hours between staging 
update and merge) so it isn't an infallible system.


Regards

James

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[David Nalesnik]

On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>
> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>
>
>> Ok, so I will probably do
>>
>> git revert HEAD
>>
>> in my staging branch
>>
>> and push it to origin/staging.
>>
>> ---
>>
>> I won't attempt to clear the LSR queue in preparation for my patch
>> update (as I did) by running makelsr.py again.
>>
>> When I update my issue, I'll simply add my snippet to snippets/new,
>> and leave updating the LSR to the future (when the frenched-score
>> snippet and my proposed snippet and whatever else appears will be
>> integrated)
>
> Sorry my recipe caused a problem in this case.  Normally clearing
> the old LSR queue first with makelsr.py would be fine.  But what
> you suggest is also OK, as long as someone fixes the problem and
> runs makelsr.py reasonably soon - before the next new snippet is
> added (I can't run it myself - on my Windows Vista it always tries
> to change all the \ to / or vice versa.)
>

I think the only problem is that @{MarkLines} should be replaced with
@code{MarkLines}.

I'm stuck in the middle of a make doc checking the change.  When I'm
through that, I'll revert the update.

Then I can push an update of the snippet to staging.  (But I'll save
the makelsr for later as James says.)

No problem, it's all a learning experience for me!

David

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[Trevor Daniels]

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM


> Ok, so I will probably do
> 
> git revert HEAD
> 
> in my staging branch
> 
> and push it to origin/staging.
> 
> ---
> 
> I won't attempt to clear the LSR queue in preparation for my patch
> update (as I did) by running makelsr.py again.
> 
> When I update my issue, I'll simply add my snippet to snippets/new,
> and leave updating the LSR to the future (when the frenched-score
> snippet and my proposed snippet and whatever else appears will be
> integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries 
to change all the \ to / or vice versa.)

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

Re: Staging Broken with last makelsr - incorrect TexInfo command format

[David Nalesnik]

On Wed, Jan 11, 2017 at 9:00 AM, James  wrote:
> David
>
>
>
> On 11/01/17 14:31, David Nalesnik wrote:
>>
>> On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
>>  wrote:
>>>
>>> On Wed, Jan 11, 2017 at 5:19 AM, James  wrote:

 Hello,

 The snippet 'using-marklines-in-a-frenched-score.ly' in the recent
 makelsr
 commit


 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433

 contains a malformed TexInfo command

 @{Markdown}

 Which breaks make doc and so cannot be merged into master.

 See my last email about testing patches with new snippets.

 Unless you are going to make doc, I suggest that you don't push makelsr
 updates as makelesr doesn't check for incorrect TexInfo formats, and
 while
 'make' often catches a lot of these TexInfo issues, it wouldn't in this
 case
 because this snippet isn't 'checked' until the makedoc stage.

 My testing would have captured this.

 I'll wait until this is resolved before I bother with my Patch countdown
 email. Else we'll just make staging even more problematic if devs who
 can
 push their patches don't see these emails.

>>> Sorry about this.  I assumed that the snippet was good to go from
>>> finding its way into the code base, and that makelsr would have caught
>>> anything in any case.
>>>
>>> The problem is pretty easy to fix on my end, but I'm extremely wary of
>>> messing (further) with origin/staging as all I've done to this point
>>> are simple pushes.  A revert would be bad for the project history, so
>>> what would you propose that I do in this case?
>>
>> Is this a case where pushing an amended commit would be super obnoxious?
>
>
> Well if you did do that, then we would have a commit in master that you
> cannot technically build from, so I think you should remove/revert the
> commit and then repush it (or whatever the git terminology is). However I am
> not a dev so cannot give your more of an idea than that.
>

Ok, so I will probably do

git revert HEAD

in my staging branch

and push it to origin/staging.

---

I won't attempt to clear the LSR queue in preparation for my patch
update (as I did) by running makelsr.py again.

When I update my issue, I'll simply add my snippet to snippets/new,
and leave updating the LSR to the future (when the frenched-score
snippet and my proposed snippet and whatever else appears will be
integrated)

Best,
David

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

Re: Staging Broken with last makelsr - incorrect TexInfo command format

[James]

David


On 11/01/17 14:31, David Nalesnik wrote:

On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
 wrote:

On Wed, Jan 11, 2017 at 5:19 AM, James  wrote:

Hello,

The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
commit

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433

contains a malformed TexInfo command

@{Markdown}

Which breaks make doc and so cannot be merged into master.

See my last email about testing patches with new snippets.

Unless you are going to make doc, I suggest that you don't push makelsr
updates as makelesr doesn't check for incorrect TexInfo formats, and while
'make' often catches a lot of these TexInfo issues, it wouldn't in this case
because this snippet isn't 'checked' until the makedoc stage.

My testing would have captured this.

I'll wait until this is resolved before I bother with my Patch countdown
email. Else we'll just make staging even more problematic if devs who can
push their patches don't see these emails.


Sorry about this.  I assumed that the snippet was good to go from
finding its way into the code base, and that makelsr would have caught
anything in any case.

The problem is pretty easy to fix on my end, but I'm extremely wary of
messing (further) with origin/staging as all I've done to this point
are simple pushes.  A revert would be bad for the project history, so
what would you propose that I do in this case?

Is this a case where pushing an amended commit would be super obnoxious?


Well if you did do that, then we would have a commit in master that you 
cannot technically build from, so I think you should remove/revert the 
commit and then repush it (or whatever the git terminology is). However 
I am not a dev so cannot give your more of an idea than that.


Regards

James

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

Re: adding a snippet to a patch

[David Nalesnik]

On Wed, Jan 11, 2017 at 3:27 AM, James  wrote:
> Hello,
>
>
> On 11/01/17 08:08, Mark Knoop wrote:
>>
>> At 15:51 on 09 Jan 2017, David Nalesnik wrote:
>>>
>>> On Mon, Jan 9, 2017 at 2:00 PM, David Nalesnik
>>>  wrote:

 Hi,

 I'm adding a snippet to a patch dealing with hairpins, and I'm not
 sure what I need to do.

 I've added the snippet to Documentation/snippets/new.

 Do I then need to run scripts/auxiliar/makelsr.py and add the
 resulting files to my patch for upload to Rietveld?
>
>  For testing/code review uploading a patch that also contains a makelsr.py
> run can sometimes end up affecting a lot of other files that are not really
> part of the review.
>
> So, what others have done in the past which I think is more convenient, is
> to upload the patch to Rietveld *with* the snippet change but *without* the
> makelsr.py run.
>
> In the 'olden' days when I had a script to download and run the tests (i.e.
> without any need for any kind of intervention from me other than to check
> the reg test output for anything unusual) I would in the cases of snippets
> in patches, run the tests manually and include a makelsr.py as part of the
> workflow for testing the patch.
>
> This is one of the benefits of having flexible patch testing methods by the
> way.
>
> Then once the patch was approved the general consensus was to apply the
> patch 'as is', then, in a separate commit the makelsr.py, that way it was
> easier to backout something that one massive patch+makelsr.py checkin.
>
> So if you prefer to do that - let the patch test include the makelsr.py -
> then just make sure that is stated in the Tracker (in case the patch tester
> - which is usually me) doesn't notice a snippet being added/modified.
>
> I hope that helps.
>

Thank you, James.  I will follow your recommended procedure when it
comes time to put my newer patch set up.

David

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

Re: Staging Broken with last makelsr - incorrect TexInfo command format

[David Nalesnik]

On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
 wrote:
> On Wed, Jan 11, 2017 at 5:19 AM, James  wrote:
>> Hello,
>>
>> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
>> commit
>>
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
>>
>> contains a malformed TexInfo command
>>
>> @{Markdown}
>>
>> Which breaks make doc and so cannot be merged into master.
>>
>> See my last email about testing patches with new snippets.
>>
>> Unless you are going to make doc, I suggest that you don't push makelsr
>> updates as makelesr doesn't check for incorrect TexInfo formats, and while
>> 'make' often catches a lot of these TexInfo issues, it wouldn't in this case
>> because this snippet isn't 'checked' until the makedoc stage.
>>
>> My testing would have captured this.
>>
>> I'll wait until this is resolved before I bother with my Patch countdown
>> email. Else we'll just make staging even more problematic if devs who can
>> push their patches don't see these emails.
>>
>
> Sorry about this.  I assumed that the snippet was good to go from
> finding its way into the code base, and that makelsr would have caught
> anything in any case.
>
> The problem is pretty easy to fix on my end, but I'm extremely wary of
> messing (further) with origin/staging as all I've done to this point
> are simple pushes.  A revert would be bad for the project history, so
> what would you propose that I do in this case?

Is this a case where pushing an amended commit would be super obnoxious?

David

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

Re: Staging Broken with last makelsr - incorrect TexInfo command format

[David Nalesnik]

On Wed, Jan 11, 2017 at 5:19 AM, James  wrote:
> Hello,
>
> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
> commit
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
>
> contains a malformed TexInfo command
>
> @{Markdown}
>
> Which breaks make doc and so cannot be merged into master.
>
> See my last email about testing patches with new snippets.
>
> Unless you are going to make doc, I suggest that you don't push makelsr
> updates as makelesr doesn't check for incorrect TexInfo formats, and while
> 'make' often catches a lot of these TexInfo issues, it wouldn't in this case
> because this snippet isn't 'checked' until the makedoc stage.
>
> My testing would have captured this.
>
> I'll wait until this is resolved before I bother with my Patch countdown
> email. Else we'll just make staging even more problematic if devs who can
> push their patches don't see these emails.
>

Sorry about this.  I assumed that the snippet was good to go from
finding its way into the code base, and that makelsr would have caught
anything in any case.

The problem is pretty easy to fix on my end, but I'm extremely wary of
messing (further) with origin/staging as all I've done to this point
are simple pushes.  A revert would be bad for the project history, so
what would you propose that I do in this case?

Again, sorry for the trouble I've caused.

David

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

Re: why title of manual Changes is not translated?

[Francisco Vila]

2017-01-10 21:35 GMT+01:00 Federico Bruni :
> Ok, I figured it out. I forgot to append -it to some links.
>
> Francisco, you forgot it too in community.itexi, in these two links (in fact
> only the last link is correct in the spanish page below):
>
> @item
> @docLinkSplit{Cambios,changes,@manualDevelChangesSplit}
> @tab
> @docLinkBig{Cambios,changes,@manualDevelChangesBig}
> @tab
> @docLinkPdf{Cambios,changes,@manualDevelChangesPdf-es}

Thank you. Will fix.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Fontconfig cache file update fails on Windows (also Cygwin)

[Masamichi Hosoda]

>> I've created a patch and reported it to fontconfig Bugzilla.
>> https://bugs.freedesktop.org/show_bug.cgi?id=99360
> 
> I notice that Behdad is mentioned on this bugzilla page as the contact
> person.  However, he is no longer the maintainer of fontconfig, so I
> ask you to also write an e-mail to the fontconfig mailing list,
> telling them that you have provided a fix just to be sure that the
> right persons see your patch.

done
https://lists.freedesktop.org/archives/fontconfig/2017-January/005898.html

Thanks

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

Re: Fontconfig cache file update fails on Windows (also Cygwin)

[Werner LEMBERG]

> I've created a patch and reported it to fontconfig Bugzilla.
> https://bugs.freedesktop.org/show_bug.cgi?id=99360

I notice that Behdad is mentioned on this bugzilla page as the contact
person.  However, he is no longer the maintainer of fontconfig, so I
ask you to also write an e-mail to the fontconfig mailing list,
telling them that you have provided a fix just to be sure that the
right persons see your patch.


Werner

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

Fontconfig cache file update fails on Windows (also Cygwin)

[Masamichi Hosoda]

I've found an issue of fontconfig on Windows.
If you have an old cache file and need updating,
the updating fails on Windows (both MinGW and Cygwin).

I've created a patch and reported it to fontconfig Bugzilla.
https://bugs.freedesktop.org/show_bug.cgi?id=99360

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

Staging Broken with last makelsr - incorrect TexInfo command format

[James]

Hello,

The snippet 'using-marklines-in-a-frenched-score.ly' in the recent 
makelsr commit


http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433

contains a malformed TexInfo command

@{Markdown}

Which breaks make doc and so cannot be merged into master.

See my last email about testing patches with new snippets.

Unless you are going to make doc, I suggest that you don't push makelsr 
updates as makelesr doesn't check for incorrect TexInfo formats, and 
while 'make' often catches a lot of these TexInfo issues, it wouldn't in 
this case because this snippet isn't 'checked' until the makedoc stage.


My testing would have captured this.

I'll wait until this is resolved before I bother with my Patch countdown 
email. Else we'll just make staging even more problematic if devs who 
can push their patches don't see these emails.


Regards


James


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

Re: adding a snippet to a patch

[James]

Hello,


On 11/01/17 08:08, Mark Knoop wrote:

At 15:51 on 09 Jan 2017, David Nalesnik wrote:

On Mon, Jan 9, 2017 at 2:00 PM, David Nalesnik
 wrote:

Hi,

I'm adding a snippet to a patch dealing with hairpins, and I'm not
sure what I need to do.

I've added the snippet to Documentation/snippets/new.

Do I then need to run scripts/auxiliar/makelsr.py and add the
resulting files to my patch for upload to Rietveld?
 For testing/code review uploading a patch that also contains a 
makelsr.py run can sometimes end up affecting a lot of other files that 
are not really part of the review.


So, what others have done in the past which I think is more convenient, 
is to upload the patch to Rietveld *with* the snippet change but 
*without* the makelsr.py run.


In the 'olden' days when I had a script to download and run the tests 
(i.e. without any need for any kind of intervention from me other than 
to check the reg test output for anything unusual) I would in the cases 
of snippets in patches, run the tests manually and include a makelsr.py 
as part of the workflow for testing the patch.


This is one of the benefits of having flexible patch testing methods by 
the way.


Then once the patch was approved the general consensus was to apply the 
patch 'as is', then, in a separate commit the makelsr.py, that way it 
was easier to backout something that one massive patch+makelsr.py checkin.


So if you prefer to do that - let the patch test include the makelsr.py 
- then just make sure that is stated in the Tracker (in case the patch 
tester - which is usually me) doesn't notice a snippet being added/modified.


I hope that helps.

James

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

Re: adding a snippet to a patch

[Mark Knoop]

At 15:51 on 09 Jan 2017, David Nalesnik wrote:
>On Mon, Jan 9, 2017 at 2:00 PM, David Nalesnik
> wrote:
>> Hi,
>>
>> I'm adding a snippet to a patch dealing with hairpins, and I'm not
>> sure what I need to do.
>>
>> I've added the snippet to Documentation/snippets/new.
>>
>> Do I then need to run scripts/auxiliar/makelsr.py and add the
>> resulting files to my patch for upload to Rietveld?
>>
>> The reason I ask is that there is a snippet not my own which is
>> getting written to Documentation/snippets/ when I run the script:
>> using-marklines-in-a-frenched-score.ly.  This leads to changes in
>> Documentation/snippets/staff-notation.snippet-list as well.
>>
>> I don't want these changes jumbled in with my patch.  
>
>Looking over several older patches affecting snippets, I see that I
>should run the makelsr script and add the resulting files.
>
>This, however, was not done in the last patch adding a snippet:
>
>commit 5944d20489bb5b8e4c4907fa3b3bcae9ec275ccb
>Author: Mark Knoop 
>Date:   Thu Sep 8 18:56:16 2016 +0100

I suppose this is simply because I was also unsure what to do. I thought
I followed the CG for this at the time, but probably missed a step or
something.

-- 
Mark Knoop

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