Re: Fixes slope errors from incorrect X extents in Beam::print. (issue 5293060)

[Keith OHara]

On Mon, 24 Oct 2011 22:19:41 -0700, m...@apollinemike.com 
 wrote:



Before this patch, the x_span of beams was only ever calculated between the 
first normal stem and last normal stem of a beam (omitting any trailing beamage 
on the left or right coming from breaks and/or stemlets).  If it has a 
consistent slope, however, the x_span of a broken part of a beam should be the 
whole length, as the trailing beamage on the right and/or left are part of the 
length between two stems.  This is where the difference comes from.



I see.
When a beam is broken, and we ask for consistent-broken-slope, you are 
imagining an extra stem at the breakpoint.
Then Beam::set_stem_lengths() returns the end-point of that imaginary stem, instead of 
the last real stem, for use in "quantized-positions", because that made it 
easier to match the heights of the broken beam.


When you say "what use-case will break when we choose consistent-broken-slope after 
this patch ?", I'm not sure what you mean.



I saw that 'consistent-broken-slope changed the return value of x_span() for broken 
beams, which was used in conjunction with "quantized-positions" for 
Beam::print().  From that I concluded that either :
(a) the old return value was wrong, in which case I wondered why you corrected 
it only sometimes, or
(b) the change would break something that used to work, and we would only 
notice when 'consistent-broken-slope=#t.
I did not consider the possibility that
(c) you made a compensating change to "quantized-positions"


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

Re: convert-ly rules to destencil Flags

[m...@apollinemike.com]

On Oct 25, 2011, at 8:36 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>> 
>>> "m...@apollinemike.com"  writes:
>>> 
 On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
 
> git fetch
> git rebase origin/dev/staging
> git push origin HEAD:dev/staging
 
 From the rebase command on my local branch, I got:
 
 fatal: Needed a single revision
 invalid upstream origin/dev/staging
 
 Any hints on what to do?
>>> 
>>> Seems like you don't have the branch.  Is it listed when doing
>>> git branch -r
>>> ?
>> 
>> No.
>> 
>>> If not, can you fetch it explicitly?
>>> 
>> 
>> How would I go about this?
> 
> How about just
> 
> git fetch --all
> 

Same problem.

mikesol@mikesol-laptop:~/lilypond-git$ git fetch --all
Fetching origin
Fetching originl

git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
fatal: Needed a single revision
invalid upstream origin/dev/staging

Cheers,
MS


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

Re: convert-ly rules to destencil Flags

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Oct 25, 2011, at 8:36 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com"  writes:
>> 
>>> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>>> 
 "m...@apollinemike.com"  writes:
 
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> 
>> git fetch
>> git rebase origin/dev/staging
>> git push origin HEAD:dev/staging
> 
> From the rebase command on my local branch, I got:
> 
> fatal: Needed a single revision
> invalid upstream origin/dev/staging
> 
> Any hints on what to do?
 
 Seems like you don't have the branch.  Is it listed when doing
 git branch -r
 ?
>>> 
>>> No.
>>> 
 If not, can you fetch it explicitly?
 
>>> 
>>> How would I go about this?
>> 
>> How about just
>> 
>> git fetch --all
>
> Same problem.
>
> mikesol@mikesol-laptop:~/lilypond-git$ git fetch --all
> Fetching origin
> Fetching originl
>
> git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
> fatal: Needed a single revision
> invalid upstream origin/dev/staging

git branch -r lists nothing?  Anyhow: I tried rebasing, deleting and
pushing the branch about an hour ago, and pushing did not work.  I had
to add it manually to the remote again (but then my git database was
somewhat out of whack due to btrfs not behaving nicely on power fail).
So there was a time window of about 30 minutes where it just was not
there.  Don't ask me why.

If I found a way to configure this branch such that it allows rewriting
rather than having to delete and repush, I'd be glad.  But it is likely
a setting in the repository.

-- 
David Kastrup


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

Re: convert-ly rules to destencil Flags

[Graham Percival]

On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:
> "m...@apollinemike.com"  writes:
> 
> > git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
> > fatal: Needed a single revision
> > invalid upstream origin/dev/staging
> 
> git branch -r lists nothing?  Anyhow: I tried rebasing, deleting and
> pushing the branch about an hour ago, and pushing did not work.

I just (well, 30-90 minute ago, can't remember) merged dev/staging
to master using your formula.  That may have impacted things.

Mike: try the old instructions here to get the branch:
http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches

I will work at simplifying these, since we're suggesting that
people go with git clone and those instructions were written in
the pre-clone era.

- Graham

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

Re: convert-ly rules to destencil Flags

[David Kastrup]

Graham Percival  writes:

> On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:
>> "m...@apollinemike.com"  writes:
>> 
>> > git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
>> > fatal: Needed a single revision
>> > invalid upstream origin/dev/staging
>> 
>> git branch -r lists nothing?  Anyhow: I tried rebasing, deleting and
>> pushing the branch about an hour ago, and pushing did not work.
>
> I just (well, 30-90 minute ago, can't remember) merged dev/staging
> to master using your formula.  That may have impacted things.

Don't think so: I think I rebased dev/staging before that.  Afterwards,
the merge should have just been a painless fast-forward.  Weird, all in
all.

> Mike: try the old instructions here to get the branch:
> http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches
>
> I will work at simplifying these, since we're suggesting that
> people go with git clone and those instructions were written in
> the pre-clone era.

I see that my git config contains
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/lilypond.git
fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging

Maybe references in a subdirectory don't get found automagically?  On
the other hand, git branch -r lists a whole lot here.  No idea.


-- 
David Kastrup

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

Re: Uses convert-ly to update changes stemming from the creation of a Flag grob. (issue 5309059)

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Oct 24, 2011, at 11:41 PM, d...@gnu.org wrote:
>
>> Seems like my suggestion to update the version numbers of files with
>> manual fixes (in a separate commit) in order not to get them updated
>> again got lost, as well as the bit about rereading the diff for
>> problems.
>> 
>> 
>
> I'll redo the patch - I did read the diff for updates, and I have no
> clue why these didn't show up (maybe I was reading it from the wrong
> directory - I read what came out from git diff).
> I didn't realize that the international snippets would not get
> regenerated from scratch with the new updated snippets before having
> the convert-ly rules applied to them.  All of the offending examples
> come from them.
> As for the versioning, I am not sure how to do manual updating and run
> the conversion scripts at the same time.

You don't.  When you manually update a file, update it complete _and_
edit its version string to indicate it has been updated.

After that, the conversion scripts will not touch it.

-- 
David Kastrup

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

Patch-needs_work vs. others

[Graham Percival]

On Tue, Oct 25, 2011 at 10:08:34AM +, lilyp...@googlecode.com wrote:
> I think that "Needs-evidence" is sufficient for indicating the need
> for discussion.  The patch status would remain Patch-review (meaning
> that the patch may or may not be acceptable in his current form but
> is not going forward).

Let's move discussion to -devel.  And the answer is "no".

I do not want to require that the patch meister, much less Patchy,
understand the difference between various types of Patch-review
items.  Patch-review should mean "no known problems, and it can go
on a countdown".

I'm ok with having two "non-review, non-new" types if you want,
although I don't see the point of introducing that much
granularity.  We could have Patch-discuss vs. Patch-needs_work.

> Once Mike gets through with making master or dev/staging
> convert-ly-clean, I'll likely prepare a single-commit version (as a
> merge with the results of the convert-ly run) and put it to
> dev/staging for final review/countdown.

No.  dev/staging means "merge and push ASAC" (as soon as
convenient).  It should only contain patches that have completed a
countdown, and/or patches that the author wishes to skip the
review process.

- Graham

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

the latest convert-ly fiasco

[Graham Percival]

I've lost track of where we are with convert-ly.

I have just ran update-with-convert-ly.  I saw a flag change from
2.15.10.  I have pushed that.

I know that there are other syntax changes that people want to
make.  Somebody make a patch with all those changes, for version
2.15.16.  Once that patch is pushed, I'll release 2.15.16, so that
we can start with a clean slate from 2.15.17 onwards.


I am not going to try to make any general guidelines for
convert-ly at the present time.  When I am feeling better, we will
resume GOP, and we'll get a definite set of instructions for
syntax changes.  Until then, just do whatever works, and if it's
useful to have a couple of extra releases just to avoid combining
multiple syntax changes in the same version number, so be it.

- Graham

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

Re: Patch-needs_work vs. others

[Graham Percival]

On Tue, Oct 25, 2011 at 01:20:33PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > convenient).  It should only contain patches that have completed a
> > countdown, and/or patches that the author wishes to skip the
> > review process.
> 
> Shrug.  That means to me that this patch is dead.  There is no
> conceivable reason that anybody should change its status to anything
> else.

I already changed the status back to Patch-new when I removed my
objection.

> We have its current state "Patch-new" -> Patch has received no obvious
> checks Of course, I checked the patch.  But even if I decide to put the
> "Patch-review" state on myself, this will merely mean: "Patch has passed
> obvious checks, and needs review".  Well, it is under review.  Who
> should decide to change its need of review, and why?

- if somebody reviews the patch and finds problems (ideally solid
  technical problems), they change it to patch-needs_work.
- if it's still patch-review when Colin makes the next countdown,
  it becomes patch-countdown.

> And in any case, it is _impossible_ to let the patch series get checked
> before having a plan for which version the convertrules.py needs to be.
> After applying the reviewed patch, one needs to autoconvert before a
> check can be made.

Right.  This is a special case of having a collective convert-ly
clustermao.  I started a new email thread for that.  Short answer:
just make a patch that combines all your rules, we'll ram that
through (quite possibly avoiding the review process), and get on
with life because this has become a farce.

- Graham

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

Re: the latest convert-ly fiasco

[mike]

On Tue, 25 Oct 2011 12:25:56 +0100, Graham Percival wrote:

I've lost track of where we are with convert-ly.

I have just ran update-with-convert-ly.  I saw a flag change from
2.15.10.  I have pushed that.

I know that there are other syntax changes that people want to
make.  Somebody make a patch with all those changes, for version
2.15.16.  Once that patch is pushed, I'll release 2.15.16, so that
we can start with a clean slate from 2.15.17 onwards.


I am not going to try to make any general guidelines for
convert-ly at the present time.  When I am feeling better, we will
resume GOP, and we'll get a definite set of instructions for
syntax changes.  Until then, just do whatever works, and if it's
useful to have a couple of extra releases just to avoid combining
multiple syntax changes in the same version number, so be it.

- Graham



Graham,

Thanks for adding this to GOP.  I have some ideas for how to avoid 
convert-ly problems, and I'm looking forward to airing them.
I'll have some time later this afternoon to take care of the current 
convert-ly shenanigans.


Cheers,
MS

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

Re: convert-ly rules to destencil Flags

[mike]

On Tue, 25 Oct 2011 11:49:58 +0200, David Kastrup wrote:

Graham Percival  writes:


On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:

"m...@apollinemike.com"  writes:

> git mikesol@mikesol-laptop:~/lilypond-git$ git rebase 
origin/dev/staging

> fatal: Needed a single revision
> invalid upstream origin/dev/staging

git branch -r lists nothing?  Anyhow: I tried rebasing, deleting 
and

pushing the branch about an hour ago, and pushing did not work.


I just (well, 30-90 minute ago, can't remember) merged dev/staging
to master using your formula.  That may have impacted things.


Don't think so: I think I rebased dev/staging before that.  
Afterwards,
the merge should have just been a painless fast-forward.  Weird, all 
in

all.


Mike: try the old instructions here to get the branch:

http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches

I will work at simplifying these, since we're suggesting that
people go with git clone and those instructions were written in
the pre-clone era.


I see that my git config contains
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/lilypond.git
fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging

Maybe references in a subdirectory don't get found automagically?  On
the other hand, git branch -r lists a whole lot here.  No idea.


Hey all,

I tried:

git remote add -ft dev/staging -m dev/staging staging 
git://git.sv.gnu.org/lilypond.git/


And then

git branch foo staging/dev/staging
git checkout foo
git apply foo.diff (where foo.diff are all of my changes)
git commit -a (with the appropriate commit message)
git push

and I get


fatal: The remote end hung up unexpectedly

Any ideas what I did wrong?

Cheers,
MS

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

Re: the latest convert-ly fiasco

[David Kastrup]

Graham Percival  writes:

> I've lost track of where we are with convert-ly.
>
> I have just ran update-with-convert-ly.  I saw a flag change from
> 2.15.10.  I have pushed that.

There is a bunch of duplicate Flag overrides/reverts now.  I suppose
Mike and/or translators will have to clean those up manually.  Does not
make for a pretty history, but not a deal-breaker.

> I know that there are other syntax changes that people want to make.

There are several independent ones.  Since their respective pushability
depends on the order in which they will get applied, I don't see that
changing their status to Patch-push or Patch-countdown would be
appropriate.

You vetoed using dev/staging for preparation of a mergeable sequence of
independent patches with corresponding automatic convert-ly updates.

Since the automatic updates need to be combined with their respective
patches for disruptive syntax changes (changes that don't work without
running convert-ly), I don't see a sensible way around stepping the
version number in between the patches.

I don't see Rietveld up to the task of reviewing all that suitably.
I'll prepare such a sequence, but I have no idea how it can make it
through the policies.

> I am not going to try to make any general guidelines for convert-ly at
> the present time.  When I am feeling better, we will resume GOP, and
> we'll get a definite set of instructions for syntax changes.  Until
> then, just do whatever works, and if it's useful to have a couple of
> extra releases just to avoid combining multiple syntax changes in the
> same version number, so be it.

As I said: that will be the cleanest sequence.

-- 
David Kastrup


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

Re: the latest convert-ly fiasco

[David Kastrup]

Graham Percival  writes:

> I've lost track of where we are with convert-ly.
>
> I have just ran update-with-convert-ly.  I saw a flag change from
> 2.15.10.  I have pushed that.
>
> I know that there are other syntax changes that people want to
> make.  Somebody make a patch with all those changes, for version
> 2.15.16.  Once that patch is pushed, I'll release 2.15.16, so that
> we can start with a clean slate from 2.15.17 onwards.
>
>
> I am not going to try to make any general guidelines for
> convert-ly at the present time.  When I am feeling better, we will
> resume GOP, and we'll get a definite set of instructions for
> syntax changes.  Until then, just do whatever works, and if it's
> useful to have a couple of extra releases just to avoid combining
> multiple syntax changes in the same version number, so be it.

I know why I prefer to do patches that are upwards-compatible in
syntax...

-- 
David Kastrup


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

Re: the latest convert-ly fiasco

[Graham Percival]

On Tue, Oct 25, 2011 at 01:44:46PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > I have just ran update-with-convert-ly.  I saw a flag change from
> > 2.15.10.  I have pushed that.
> 
> There is a bunch of duplicate Flag overrides/reverts now.

Really?  huh.  I glanced at the patch and it looked decent... I
mean, it sets the Stem, then it sets the Flag.  I thought that was
the whole point.

> I suppose Mike and/or translators will have to clean those up
> manually.

Yep.

> You vetoed using dev/staging for preparation of a mergeable sequence of
> independent patches with corresponding automatic convert-ly updates.

I am entirely in favor of using some other branch for that,
though.  I mean, you can call it whatever you want, as long as
it's not release/unstable or dev/staging or dev/somebody's_name.

- Graham

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

Re: the latest convert-ly fiasco

[David Kastrup]

Graham Percival  writes:

> On Tue, Oct 25, 2011 at 01:44:46PM +0200, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > I have just ran update-with-convert-ly.  I saw a flag change from
>> > 2.15.10.  I have pushed that.
>> 
>> There is a bunch of duplicate Flag overrides/reverts now.
>
> Really?  huh.  I glanced at the patch and it looked decent... I
> mean, it sets the Stem, then it sets the Flag.  I thought that was
> the whole point.

Quite often it sets the Stem, then it sets the Flag, then it sets the
Flag again.

>> I suppose Mike and/or translators will have to clean those up
>> manually.
>
> Yep.

Probably less work than "doing it right" would have been, with the same
result.

>> You vetoed using dev/staging for preparation of a mergeable sequence of
>> independent patches with corresponding automatic convert-ly updates.
>
> I am entirely in favor of using some other branch for that,
> though.  I mean, you can call it whatever you want, as long as
> it's not release/unstable or dev/staging or dev/somebody's_name.

There goes dev/dak.

-- 
David Kastrup

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

Fixes all duplicate declarations of Flag #'transparent (issue 5312056)

[percival . music . ca]

remove the version number change to 2.15.11, then please push.


http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly
File Documentation/snippets/new/guitar-slides.ly (right):

http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly#newcode1
Documentation/snippets/new/guitar-slides.ly:1: \version "2.15.11"
why this change?

http://codereview.appspot.com/5312056/

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

Re: Fixes all duplicate declarations of Flag #'transparent (issue 5312056)

[m...@apollinemike.com]

On Oct 25, 2011, at 2:11 PM, percival.music...@gmail.com wrote:

> remove the version number change to 2.15.11, then please push.
> 
> 
> http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly
> File Documentation/snippets/new/guitar-slides.ly (right):
> 
> http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly#newcode1
> Documentation/snippets/new/guitar-slides.ly:1: \version "2.15.11"
> why this change?
> 
> http://codereview.appspot.com/5312056/


Hey Graham,

I'll be able to push once I get the dev/staging thing figured out.  Sorry that 
that's taking me some time, but I'm not well versed enough in git to know how 
to get it right w/o help.

If you have any ideas on how to get that up and running (I sent out an e-mail a 
bit ago w/ the steps I took and where I wound up), I'd appreciate it!

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

Re: Horizontal spacing change between 2.15.9 and 2.15.10 (regression?)

[Graham Percival]

On Mon, Oct 24, 2011 at 10:13:14PM +0200, m...@apollinemike.com wrote:
> If you use git bisect, you can track it down to an individual
> commit.  This'll help us figure out how to fix the problem.

+1

instructions in the CG.

- Graham

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

Re: the latest convert-ly fiasco

[Colin Campbell]

On 11-10-25 05:44 AM, David Kastrup wrote:

There are several independent ones.  Since their respective pushability
depends on the order in which they will get applied, I don't see that
changing their status to Patch-push or Patch-countdown would be
appropriate.

You vetoed using dev/staging for preparation of a mergeable sequence of
independent patches with corresponding automatic convert-ly updates.

Since the automatic updates need to be combined with their respective
patches for disruptive syntax changes (changes that don't work without
running convert-ly), I don't see a sensible way around stepping the
version number in between the patches.

I don't see Rietveld up to the task of reviewing all that suitably.
I'll prepare such a sequence, but I have no idea how it can make it
through the policies.


In the interests of 'get it done and make the paper work agree', would 
you and Graham let me know which issues/patches are going through 
slightly different channels?  I gather that most or all of this would be 
Rietveld only, so it's essentially invisible to the policy weeny, but if 
I can stay out of the way, I'd be glad to turn the blind eye.


Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

Re: convert-ly rules to destencil Flags

[Colin Campbell]

On 11-10-25 05:40 AM, m...@apollinemike.com wrote:

Hey all,

I tried:

git remote add -ft dev/staging -m dev/staging staging 
git://git.sv.gnu.org/lilypond.git/


And then

git branch foo staging/dev/staging
git checkout foo
git apply foo.diff (where foo.diff are all of my changes)
git commit -a (with the appropriate commit message)
git push

and I get


fatal: The remote end hung up unexpectedly

Any ideas what I did wrong?

Cheers,
MS




Isn't the unexpected hangup a function of ssh security?  It was plaguing 
me until I finally got my keys in synch between my home machine and 
savannah.


HTH,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

Re: convert-ly rules to destencil Flags

[m...@apollinemike.com]

On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:

> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
>> Hey all,
>> 
>> I tried:
>> 
>> git remote add -ft dev/staging -m dev/staging staging 
>> git://git.sv.gnu.org/lilypond.git/
>> 
>> And then
>> 
>> git branch foo staging/dev/staging
>> git checkout foo
>> git apply foo.diff (where foo.diff are all of my changes)
>> git commit -a (with the appropriate commit message)
>> git push
>> 
>> and I get
>> 
>> 
>> fatal: The remote end hung up unexpectedly
>> 
>> Any ideas what I did wrong?
>> 
>> Cheers,
>> MS
>> 
> 
> 
> Isn't the unexpected hangup a function of ssh security?  It was plaguing me 
> until I finally got my keys in synch between my home machine and savannah.
> 
> HTH,
> Colin
> 

I had similar issues when I was starting out with Savannah.  They went away, 
and I believe I can still push to current master - its just dev/staging that's 
giving me problems.
Colin - if you have any insight into how to get a working dev/staging going, 
please don't hesitate to share!

Cheers,
MS


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

Re: convert-ly rules to destencil Flags

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:
>
>> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
>>> Hey all,
>>> 
>>> I tried:
>>> 
>>> git remote add -ft dev/staging -m dev/staging staging
>>> git://git.sv.gnu.org/lilypond.git/

That adds a separate remote "staging" if I understand.  You don't want a
separate remote.  origin should be just fine.

>>> fatal: The remote end hung up unexpectedly
>>> 
>>> Any ideas what I did wrong?

Non-existing remote would be my guess.

-- 
David Kastrup


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

Re: convert-ly rules to destencil Flags

[m...@apollinemike.com]

On Oct 25, 2011, at 3:12 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:
>> 
>>> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
 Hey all,
 
 I tried:
 
 git remote add -ft dev/staging -m dev/staging staging
 git://git.sv.gnu.org/lilypond.git/
> 
> That adds a separate remote "staging" if I understand.  You don't want a
> separate remote.  origin should be just fine.
> 
 fatal: The remote end hung up unexpectedly
 
 Any ideas what I did wrong?
> 
> Non-existing remote would be my guess.
> 

Tried:

mikesol@mikesol-laptop:~/lilypond-git$ git remote add -ft dev/staging -m 
dev/staging origin/dev/staging git://git.sv.gnu.org/lilypond.git/
Updating origin/dev/staging
>From git://git.sv.gnu.org/lilypond
 * [new branch]  dev/staging -> origin/dev/staging/dev/staging
mikesol@mikesol-laptop:~/lilypond-git$ git branch -r
  origin/dev/staging/HEAD -> origin/dev/staging/dev/staging
  origin/dev/staging/dev/staging
  origin/master
  staging/HEAD -> staging/dev/staging

then, realized this was not what I wanted either, so

mikesol@mikesol-laptop:~/lilypond-git$ git branch -Dr 
origin/dev/staging/dev/staging 
Deleted remote branch origin/dev/staging/dev/staging (was 1cef8d5).
mikesol@mikesol-laptop:~/lilypond-git$ git branch -r
  origin/dev/staging/HEAD -> origin/dev/staging/dev/staging
  origin/master
  staging/HEAD -> staging/dev/staging

And now I have two extra branches (staging/HEAD and origin/dev/staging/HEAD) 
that I can't seem to get rid of.  Any suggestions?

Cheers,
MS


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

Re: convert-ly rules to destencil Flags

[David Kastrup]

"m...@apollinemike.com"  writes:

> And now I have two extra branches (staging/HEAD and origin/dev/staging/HEAD) 
> that I can't seem to get rid of.  Any suggestions?

Use an editor on .git/config to clean up, and find and delete those
files from .git/refs that represent the bad branches.

Sometimes the hardcore solutions are easiest.

-- 
David Kastrup

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

Re: convert-ly rules to destencil Flags

[m...@apollinemike.com]

On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> And now I have two extra branches (staging/HEAD and origin/dev/staging/HEAD) 
>> that I can't seem to get rid of.  Any suggestions?
> 
> Use an editor on .git/config to clean up, and find and delete those
> files from .git/refs that represent the bad branches.
> 
> Sometimes the hardcore solutions are easiest.
> 

Works like a charm.

My question still stands about how to establish the remote branch.

git remote add -ft dev/staging -m dev/staging origin/dev/staging 
git://git.sv.gnu.org/lilypond.git/
does not seem to do the trick

Any takers?

Cheers,
MS

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

Re: convert-ly rules to destencil Flags

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:
>
> "m...@apollinemike.com"  writes:
> 
> And now I have two extra branches (staging/HEAD and
> origin/dev/staging/HEAD) that I can't seem to get rid of.  Any
> suggestions?
> 
>
> Use an editor on .git/config to clean up, and find and delete
> those
> files from .git/refs that represent the bad branches.
> 
> Sometimes the hardcore solutions are easiest.
> 
> 
>
> Works like a charm.
>
> My question still stands about how to establish the remote branch.
>
> git remote add -ft dev/staging -m dev/staging
> origin/dev/staging git://git.sv.gnu.org/lilypond.git/
> does not seem to do the trick
>
> Any takers?

Well, my .git/config has
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/lilypond.git
fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging

in it.  I have no idea why the third line is needed on top of the first
line, but maybe you can't delete and repush otherwise since after the
deletion, git has forgotten how to get there.

Anyway, try making .git/config similar, and the do git fetch origin, and
then git branch -r really should do that.

There will be some magical git "user interface" command line for writing
the !@#$@!$ fetch line, but I forgot which one I used.

-- 
David Kastrup

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

Re: convert-ly rules to destencil Flags

[m...@apollinemike.com]

On Oct 25, 2011, at 3:46 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:
>> 
>>"m...@apollinemike.com"  writes:
>> 
>>And now I have two extra branches (staging/HEAD and
>>origin/dev/staging/HEAD) that I can't seem to get rid of.  Any
>>suggestions?
>> 
>> 
>>Use an editor on .git/config to clean up, and find and delete
>>those
>>files from .git/refs that represent the bad branches.
>> 
>>Sometimes the hardcore solutions are easiest.
>> 
>> 
>> 
>> Works like a charm.
>> 
>> My question still stands about how to establish the remote branch.
>> 
>> git remote add -ft dev/staging -m dev/staging
>> origin/dev/staging git://git.sv.gnu.org/lilypond.git/
>> does not seem to do the trick
>> 
>> Any takers?
> 
> Well, my .git/config has
> [remote "origin"]
>   fetch = +refs/heads/*:refs/remotes/origin/*
>   url = ssh://git.sv.gnu.org/srv/git/lilypond.git
>   fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging
> 
> in it.  I have no idea why the third line is needed on top of the first
> line, but maybe you can't delete and repush otherwise since after the
> deletion, git has forgotten how to get there.
> 
> Anyway, try making .git/config similar, and the do git fetch origin, and
> then git branch -r really should do that.
> 
> There will be some magical git "user interface" command line for writing
> the !@#$@!$ fetch line, but I forgot which one I used.
> 

This I did, and it fetched everything under the sun except dev/staging:

mikesol@mikesol-laptop:~/lilypond-git$ git fetch
>From ssh://git.sv.gnu.org/srv/git/lilypond
 * [new branch]  cvs/master -> origin/cvs/master
 * [new branch]  dev/jmandereau -> origin/dev/jmandereau
 * [new branch]  dev/jneem  -> origin/dev/jneem
 * [new branch]  dev/jneeman -> origin/dev/jneeman
 * [new branch]  dev/kainhofer -> origin/dev/kainhofer
 * [new branch]  dev/patrick -> origin/dev/patrick
 * [new branch]  dev/rlittle -> origin/dev/rlittle
 * [new branch]  dev/rune   -> origin/dev/rune
 * [new branch]  dev/stringtuning -> origin/dev/stringtuning
 * [new branch]  dev/syntax -> origin/dev/syntax
 * [new branch]  dev/waf-> origin/dev/waf
 * [new branch]  lilypond/translation -> origin/lilypond/translation
 * [new branch]  macos-lilypad -> origin/macos-lilypad
 * [new branch]  release/unstable -> origin/release/unstable
 * [new branch]  stable/0.0 -> origin/stable/0.0
 * [new branch]  stable/1.0 -> origin/stable/1.0
 * [new branch]  stable/1.2 -> origin/stable/1.2
 * [new branch]  stable/1.4 -> origin/stable/1.4
 * [new branch]  stable/1.6 -> origin/stable/1.6
 * [new branch]  stable/1.8 -> origin/stable/1.8
 * [new branch]  stable/2.0 -> origin/stable/2.0
 * [new branch]  stable/2.10 -> origin/stable/2.10
 * [new branch]  stable/2.12 -> origin/stable/2.12
 * [new branch]  stable/2.14 -> origin/stable/2.14
 * [new branch]  stable/2.2 -> origin/stable/2.2
 * [new branch]  stable/2.4 -> origin/stable/2.4
 * [new branch]  stable/2.6 -> origin/stable/2.6
 * [new branch]  stable/2.8 -> origin/stable/2.8
 * [new branch]  tarball/master -> origin/tarball/master
 * [new branch]  web-> origin/web
 * [new branch]  web-gop-> origin/web-gop

Who said git was supposed to be easy?!?

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

Re: convert-ly rules to destencil Flags

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Oct 25, 2011, at 3:46 PM, David Kastrup wrote:
>> 
>> Well, my .git/config has
>> [remote "origin"]
>>  fetch = +refs/heads/*:refs/remotes/origin/*
>>  url = ssh://git.sv.gnu.org/srv/git/lilypond.git
>>  fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging
>> 
>> in it.  I have no idea why the third line is needed on top of the first
>> line, but maybe you can't delete and repush otherwise since after the
>> deletion, git has forgotten how to get there.
>> 
>> Anyway, try making .git/config similar, and the do git fetch origin, and
>> then git branch -r really should do that.
>> 
>> There will be some magical git "user interface" command line for writing
>> the !@#$@!$ fetch line, but I forgot which one I used.
>> 
>
> This I did, and it fetched everything under the sun except dev/staging:
>
> mikesol@mikesol-laptop:~/lilypond-git$ git fetch
> From ssh://git.sv.gnu.org/srv/git/lilypond
>  * [new branch]  cvs/master -> origin/cvs/master
>  * [new branch]  dev/jmandereau -> origin/dev/jmandereau
>  * [new branch]  dev/jneem  -> origin/dev/jneem
>  * [new branch]  dev/jneeman -> origin/dev/jneeman
>  * [new branch]  dev/kainhofer -> origin/dev/kainhofer
>  * [new branch]  dev/patrick -> origin/dev/patrick
>  * [new branch]  dev/rlittle -> origin/dev/rlittle
>  * [new branch]  dev/rune   -> origin/dev/rune
>  * [new branch]  dev/stringtuning -> origin/dev/stringtuning
>  * [new branch]  dev/syntax -> origin/dev/syntax
>  * [new branch]  dev/waf-> origin/dev/waf
>  * [new branch]  lilypond/translation -> origin/lilypond/translation
>  * [new branch]  macos-lilypad -> origin/macos-lilypad
>  * [new branch]  release/unstable -> origin/release/unstable
>  * [new branch]  stable/0.0 -> origin/stable/0.0
>  * [new branch]  stable/1.0 -> origin/stable/1.0
>  * [new branch]  stable/1.2 -> origin/stable/1.2
>  * [new branch]  stable/1.4 -> origin/stable/1.4
>  * [new branch]  stable/1.6 -> origin/stable/1.6
>  * [new branch]  stable/1.8 -> origin/stable/1.8
>  * [new branch]  stable/2.0 -> origin/stable/2.0
>  * [new branch]  stable/2.10 -> origin/stable/2.10
>  * [new branch]  stable/2.12 -> origin/stable/2.12
>  * [new branch]  stable/2.14 -> origin/stable/2.14
>  * [new branch]  stable/2.2 -> origin/stable/2.2
>  * [new branch]  stable/2.4 -> origin/stable/2.4
>  * [new branch]  stable/2.6 -> origin/stable/2.6
>  * [new branch]  stable/2.8 -> origin/stable/2.8
>  * [new branch]  tarball/master -> origin/tarball/master
>  * [new branch]  web-> origin/web
>  * [new branch]  web-gop-> origin/web-gop
>
> Who said git was supposed to be easy?!?

Likely you already had dev/staging fetched.

git branch -r

-- 
David Kastrup

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

Re: the latest convert-ly fiasco

[David Kastrup]

David Kastrup  writes:

> Graham Percival  writes:
>
>> I've lost track of where we are with convert-ly.
>>
>> I have just ran update-with-convert-ly.  I saw a flag change from
>> 2.15.10.  I have pushed that.
>>
>> I know that there are other syntax changes that people want to
>> make.  Somebody make a patch with all those changes, for version
>> 2.15.16.  Once that patch is pushed, I'll release 2.15.16, so that
>> we can start with a clean slate from 2.15.17 onwards.
>>
>>
>> I am not going to try to make any general guidelines for
>> convert-ly at the present time.  When I am feeling better, we will
>> resume GOP, and we'll get a definite set of instructions for
>> syntax changes.  Until then, just do whatever works, and if it's
>> useful to have a couple of extra releases just to avoid combining
>> multiple syntax changes in the same version number, so be it.
>
> I know why I prefer to do patches that are upwards-compatible in
> syntax...

Ok, whichever of the outstanding reviews with syntax changes gets its
approval first, gets its conversion rule updated to 2.15.16 (did not
notice the bump of PATCH_LEVEL in VERSION, but it's pointless redoing
the reviews because of that), then pushed to dev/staging in a form
suitable for bijection.  Then I wait for the official version bumb to
2.15.17, and do the next ruleset if it gets approved until then.

Lost about two days of work in trying to figure out procedures and
adhering to them.

-- 
David Kastrup


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

Re: Fixes all duplicate declarations of Flag #'transparent (issue 5312056)

[m...@apollinemike.com]

On Oct 25, 2011, at 2:17 PM, m...@apollinemike.com wrote:

> On Oct 25, 2011, at 2:11 PM, percival.music...@gmail.com wrote:
> 
>> remove the version number change to 2.15.11, then please push.
>> 
>> 
>> http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly
>> File Documentation/snippets/new/guitar-slides.ly (right):
>> 
>> http://codereview.appspot.com/5312056/diff/1/Documentation/snippets/new/guitar-slides.ly#newcode1
>> Documentation/snippets/new/guitar-slides.ly:1: \version "2.15.11"
>> why this change?
>> 
>> http://codereview.appspot.com/5312056/
> 
> 
> Hey Graham,
> 
> I'll be able to push once I get the dev/staging thing figured out.  Sorry 
> that that's taking me some time, but I'm not well versed enough in git to 
> know how to get it right w/o help.
> 
> If you have any ideas on how to get that up and running (I sent out an e-mail 
> a bit ago w/ the steps I took and where I wound up), I'd appreciate it!
> 
> Cheers,
> MS

Re-hay Graham,

None of these changes apply on top of dev/staging.  I'm not sure why, but to 
not lose time, I'm doing a full doc build on master right now with the patch 
applied.  If it goes through, do you want me to push the patch?  Otherwise, 
I'll reset my HEAD on master back a notch and investigate what's going on in 
dev/staging.

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

Re: Fixes all duplicate declarations of Flag #'transparent (issue 5312056)

[David Kastrup]

"m...@apollinemike.com"  writes:

> Re-hay Graham,
>
> None of these changes apply on top of dev/staging.  I'm not sure why,
> but to not lose time, I'm doing a full doc build on master right now
> with the patch applied.  If it goes through, do you want me to push
> the patch?  Otherwise, I'll reset my HEAD on master back a notch and
> investigate what's going on in dev/staging.

dev/staging is at the moment identical to master.

-- 
David Kastrup


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

Get rid of most of the insane string-tunings API (issue 5318046)

[Carl . D . Sorensen]

LGTM.

Thanks, David.  Nicely done.

Carl



http://codereview.appspot.com/5318046/diff/12002/input/regression/tablature-letter.ly
File input/regression/tablature-letter.ly (right):

http://codereview.appspot.com/5318046/diff/12002/input/regression/tablature-letter.ly#newcode32
input/regression/tablature-letter.ly:32: stringTunings = \stringTuning
\notemode {  }
Why not just

stringTunings = \stringTuning 

?

http://codereview.appspot.com/5318046/

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

Re: Fixes all duplicate declarations of Flag #'transparent (issue 5312056)

[m...@apollinemike.com]

On Oct 25, 2011, at 5:51 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> Re-hay Graham,
>> 
>> None of these changes apply on top of dev/staging.  I'm not sure why,
>> but to not lose time, I'm doing a full doc build on master right now
>> with the patch applied.  If it goes through, do you want me to push
>> the patch?  Otherwise, I'll reset my HEAD on master back a notch and
>> investigate what's going on in dev/staging.
> 
> dev/staging is at the moment identical to master.
> 

Indeed it is.
Doc changes pushed.

Cheers,
MS


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

Re: Get rid of most of the insane string-tunings API (issue 5318046)

[dak]

Reviewers: carl.d.sorensen_gmail.com,


http://codereview.appspot.com/5318046/diff/12002/input/regression/tablature-letter.ly
File input/regression/tablature-letter.ly (right):

http://codereview.appspot.com/5318046/diff/12002/input/regression/tablature-letter.ly#newcode32
input/regression/tablature-letter.ly:32: stringTunings = \stringTuning
\notemode {  }
On 2011/10/25 15:55:34, Carl wrote:

Why not just



stringTunings = \stringTuning 



?


Music functions parse their arguments in the current mode.  Context
modifications are delivered in "initial mode" that knows no notenames
but can deal with identifiers containing hyphens, something which is not
possible in "note mode".

Why it would be a good idea to define identifiers for context variables
that can't be entered in notemode escapes me, but there you are.

Oh, and switching on notename conversions just in case is too expensive
anyway: whenever you switch on notemode, the current notename alist is
translated into a hashtable again.

At some point of time, I plan to permit mode-switching while scanning
music function argument lists.

At some point of time, I plan to decrease the necessity for all those
stupid different modes.

This point of time is not there.  Hence the example with \notemode to
avoid tripping users up all too bad.

Description:
Get rid of most of the insane string-tunings API

convert-ly rules are there.  Translations should compile again after
applying convert-ly, but of course the changes to text and examples
should be propagated eventually with the usual processes.

This is intended for dev/staging as soon as staging contains a
convert-ly-clean tree.

Please review this at http://codereview.appspot.com/5318046/

Affected files:
  M Documentation/de/notation/fretted-strings.itely
  M Documentation/es/notation/fretted-strings.itely
  M Documentation/fr/notation/fretted-strings.itely
  M Documentation/included/display-predefined-string-tunings.ly
  M Documentation/notation/fretted-strings.itely
  D input/regression/context-string-tuning.ly
  M input/regression/tablature-letter.ly
  M input/regression/tablature-string-tunings.ly
  M ly/string-tunings-init.ly
  M python/convertrules.py



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

Re: lily-guile updates and CG: "Scheme->C interface" section. (issue 4917044)

[bordage . bertrand]

Hi David,

Could you make your own patch for the doc changes?
And, as you mentionned, the unused function should be removed.  Do you
want me to commit this change?

Bertrand

http://codereview.appspot.com/4917044/

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

Doc: NR Added new node for Custom Footnotes (issue 5315053)

[pkx166h]

Reviewers: ,

Message:
There are a few non-standard indents to show more clearly the footnote
syntax in the @lilypond examples.

Description:
Doc: NR Added new node for Custom Footnotes

This is for Tracker issue 1567

Please review this at http://codereview.appspot.com/5315053/

Affected files:
  M Documentation/notation/input.itely



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

Re: Doc: NR Added new node for Custom Footnotes (issue 5315053)

[mtsolo]

Thanks for your work on this James!

Cheers,
MS


http://codereview.appspot.com/5315053/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

http://codereview.appspot.com/5315053/diff/1/Documentation/notation/input.itely#newcode1025
Documentation/notation/input.itely:1025: All grobs, top-level
@code{\markup} and chorded notes and can be
and chorded notes can be

http://codereview.appspot.com/5315053/diff/1/Documentation/notation/input.itely#newcode1026
Documentation/notation/input.itely:1026: annotated.  When annotating
grobs the command that you use must come
When annotating grobs,

http://codereview.appspot.com/5315053/diff/1/Documentation/notation/input.itely#newcode1033
Documentation/notation/input.itely:1033:
This is not entirely accurate - it is the center only if the offset is
0.  If the offset is negative it is DOWN/LEFT, and if positive it is
UP/RIGHT.

http://codereview.appspot.com/5315053/diff/1/Documentation/notation/input.itely#newcode1097
Documentation/notation/input.itely:1097:
I believe they can (sorry if I ever indicated anything to the
contrary!).  Try \auto-footnote.

http://codereview.appspot.com/5315053/

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

Re: lily-guile updates and CG: "Scheme->C interface" section. (issue 4917044)

[David Kastrup]

bordage.bertr...@gmail.com writes:

> Hi David,
>
> Could you make your own patch for the doc changes?

Pushed.  I have enough pending reviews, commits and patches that I don't
have the nerve to do yet another hoop-jumping exercise in parallel.

> And, as you mentionned, the unused function should be removed.  Do you
> want me to commit this change?

That would be the smart thing to do.  Broken unused code does not help
anybody.

-- 
David Kastrup

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

Markup parsing question

[Bertalan Fodor (LilyPondTool)]

Dear LilyPond devs,

I have a problem with the LilyPond markup parsing, which prevents me to
finish my new release of LilyPondTool.
Could you help me a bit on that?

I have this ly file
--
dot = \markup {
  "q" \musicglyph #"accordion.dot"
}

{ c^\dot }
--

When the markup is parsed, it will become:
( "q" (musicglyph "accordion.dot"))
through the rules: markup_braced_list -> markup_list -> markup_top ->
full_markup -> identifier_init

This really makes sense, but please correct me if I'm wrong.

Now when I'm referring to it in c^\dot, the following code is run:

if (Text_interface::is_markup (sid)) {

return MARKUP_IDENTIFIER;
} else if (Text_interface::is_markup_list (sid)) {

return MARKUPLINES_IDENTIFIER;
}

The result of this must be MARKUP_IDENTIFIER (as only those can be used as
direction_reqd_event -> gen_text_def -> full_markup

But if I look in Text_interface.isMarkup, it will just do the following:

return (scm_is_string (x)
  || (scm_is_pair (x)
  && SCM_BOOL_F
  != scm_object_property (scm_car (x),
  ly_symbol2scm ("markup-signature";
}
So my value, ( "q" (musicglyph "accordion.dot")) will not be considered as a
markup, but instead a markup list, so I'm getting a parse error.

Can you help me where I misunderstand the code?

Thank you,

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

damn small lilypond

[Federico Bruni]

What would you do if you had to install lilypond v2.14.2 on computers 
running Ubuntu 10.04 (where lilypond is still v2.12), with the following 
limitations:


- only the standard packages distributed by Ubuntu can be installed on /
- the maximum space available in each /home directory is 50 MB

Lilypond sh package decompressed is around 60 MB.

I guess that the best solution is bringing a bunch of USB drives and 
copying the executables there.


But I wonder if there's any other solution...
I don't know ho many USB drives I'll need.

What happens if I remove usr/lib/python2.4 (22,4 MB)?

Thanks,
Federico

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

PATCH: Countdown to 20111027

[Colin Campbell]

For 23:00 MDT Thursday October 27

Issue 1980 : 
Patch: Sketch for in-notes. - R5293053 



Issue 1981 : 
Patch: Adds Scheme function for spring constructor. - R5306050 



Issue 1989 : 
Patch: Website: use external $LILYPOND_WEB_MEDIA_GIT - R5319043 



Issue 1990 : 
Patch: Uses convert-ly to update changes stemming from the creation of a 
Flag grob - R5309059 


Issue 1992 : 
Patch: Fixes all duplicate declarations of Flag #'transparent - R5312056 




Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: PATCH: Countdown to 20111027

[m...@apollinemike.com]

On Oct 26, 2011, at 6:20 AM, Colin Campbell wrote:

> For 23:00 MDT Thursday October 27
> 
> Issue 1980: Patch: Sketch for in-notes. - R 5293053
> 
> Issue 1981: Patch: Adds Scheme function for spring constructor. - R 5306050
> 
> Issue 1989: Patch: Website: use external $LILYPOND_WEB_MEDIA_GIT - R5319043
> 
> Issue 1990: Patch: Uses convert-ly to update changes stemming from the 
> creation of a Flag grob - R5309059
> 
> Issue 1992: Patch: Fixes all duplicate declarations of Flag #'transparent - 
> R5312056
> 

Hey Colin & Graham,

Procedural question - fixes for 1990 and 1992 are in dev/staging and may or may 
not be in master (I haven't checked yet this morning).  When a patch is finally 
pushed to master, will the original author get a notification so that she can 
mark it as fixed on the tracker, or does the author have to check from time to 
time to see if it was pushed?

Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCH: Countdown to 20111027

[Graham Percival]

On Wed, Oct 26, 2011 at 06:26:01AM +0200, m...@apollinemike.com wrote:
>Procedural question - fixes for 1990 and 1992 are in dev/staging and may
>or may not be in master (I haven't checked yet this morning).

If they're in staging, then that means that you want them pushed
immediately.  They shouldn't be in staging until they've completed
the countdown.

>  When a
>patch is finally pushed to master, will the original author get a
>notification so that she can mark it as fixed on the tracker, or does the
>author have to check from time to time to see if it was pushed?

Original author should mark the tracker issues "fixed" when he
pushes them to staging.

- Graham

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

Re: Markup parsing question

[David Kastrup]

"Bertalan Fodor (LilyPondTool)"  writes:

> Dear LilyPond devs,
>
> I have a problem with the LilyPond markup parsing, which prevents me
> to finish my new release of LilyPondTool.
> Could you help me a bit on that?
>
> I have this ly file
> --
> dot = \markup {
>   "q" \musicglyph #"accordion.dot"
> }
>
> { c^\dot }
> --
>
> When the markup is parsed, it will become:
> ( "q" (musicglyph "accordion.dot"))
> through the rules: markup_braced_list -> markup_list -> markup_top ->
> full_markup -> identifier_init
>
> This really makes sense, but please correct me if I'm wrong.

You are wrong.  \markuplines (soon to become \markuplist) takes this
markup list verbatim.  \markup, however, wraps it in a line-markup.  Put
the following after your assignment:

#(begin)
#(display dot)

This produces:

(# (  q (# accordion.dot)))

> Now when I'm referring to it in c^\dot, the following code is run:
>
> if (Text_interface::is_markup (sid)) {
> 
>         return MARKUP_IDENTIFIER;
>     } else if (Text_interface::is_markup_list (sid)) {
> 
>         return MARKUPLINES_IDENTIFIER;
> } 
>
> The result of this must be MARKUP_IDENTIFIER (as only those can be
> used as direction_reqd_event -> gen_text_def -> full_markup
>
> But if I look in Text_interface.isMarkup, it will just do the
> following:
>
> return (scm_is_string (x)
>       || (scm_is_pair (x)
>       && SCM_BOOL_F
>       != scm_object_property (scm_car (x),
>                   ly_symbol2scm ("markup-signature";
> } 
> So my value, ( "q" (musicglyph "accordion.dot")) will not be
> considered as a markup, but instead a markup list, so I'm getting a
> parse error.
>
> Can you help me where I misunderstand the code?

Have you actually tried your code?  Works fine here.

-- 
David Kastrup


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

Re: damn small lilypond

[Alex Austin]

mkdir $HOME/lilypond
mount none -t tmpfs $HOME/lilypond
cd $HOME/lilypond
wget /url/of/lilypond.sh
./lilypond.sh
Figure out what packages you don't need, delete them and the .sh package,
and copy everything else into a different, non-tmpfs directory in your home
folder.
On Oct 25, 2011 5:45 PM, "Federico Bruni"  wrote:

> What would you do if you had to install lilypond v2.14.2 on computers
> running Ubuntu 10.04 (where lilypond is still v2.12), with the following
> limitations:
>
> - only the standard packages distributed by Ubuntu can be installed on /
> - the maximum space available in each /home directory is 50 MB
>
> Lilypond sh package decompressed is around 60 MB.
>
> I guess that the best solution is bringing a bunch of USB drives and
> copying the executables there.
>
> But I wonder if there's any other solution...
> I don't know ho many USB drives I'll need.
>
> What happens if I remove usr/lib/python2.4 (22,4 MB)?
>
> Thanks,
> Federico
>
> __**_
> 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: Markup parsing question

[Bertalan Fodor (LilyPondTool)]

Thank you David, this explains me what I didn't understand.
It turned out that somehow I was looking at a bad parser.yy.

Actually I'm not running/debugging the C code, but instead only reading it
(and porting some of the parsing code to Java).

Bertalan

On Wed, Oct 26, 2011 at 7:26 AM, David Kastrup  wrote:

> "Bertalan Fodor (LilyPondTool)"  writes:
>
> > Dear LilyPond devs,
> >
> > I have a problem with the LilyPond markup parsing, which prevents me
> > to finish my new release of LilyPondTool.
> > Could you help me a bit on that?
> >
> > I have this ly file
> > --
> > dot = \markup {
> >   "q" \musicglyph #"accordion.dot"
> > }
> >
> > { c^\dot }
> > --
> >
> > When the markup is parsed, it will become:
> > ( "q" (musicglyph "accordion.dot"))
> > through the rules: markup_braced_list -> markup_list -> markup_top ->
> > full_markup -> identifier_init
> >
> > This really makes sense, but please correct me if I'm wrong.
>
> You are wrong.  \markuplines (soon to become \markuplist) takes this
> markup list verbatim.  \markup, however, wraps it in a line-markup.  Put
> the following after your assignment:
>
> #(begin)
> #(display dot)
>
> This produces:
>
> (# (  q (#  musicglyph-markup (layout props glyph-name)> accordion.dot)))
>
> > Now when I'm referring to it in c^\dot, the following code is run:
> >
> > if (Text_interface::is_markup (sid)) {
> > 
> > return MARKUP_IDENTIFIER;
> > } else if (Text_interface::is_markup_list (sid)) {
> > 
> > return MARKUPLINES_IDENTIFIER;
> > }
> >
> > The result of this must be MARKUP_IDENTIFIER (as only those can be
> > used as direction_reqd_event -> gen_text_def -> full_markup
> >
> > But if I look in Text_interface.isMarkup, it will just do the
> > following:
> >
> > return (scm_is_string (x)
> >   || (scm_is_pair (x)
> >   && SCM_BOOL_F
> >   != scm_object_property (scm_car (x),
> >   ly_symbol2scm ("markup-signature";
> > }
> > So my value, ( "q" (musicglyph "accordion.dot")) will not be
> > considered as a markup, but instead a markup list, so I'm getting a
> > parse error.
> >
> > Can you help me where I misunderstand the code?
>
> Have you actually tried your code?  Works fine here.
>
> --
> David Kastrup
>
>
> ___
> 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: Markup parsing question

[David Kastrup]

"Bertalan Fodor (LilyPondTool)"  writes:

> Thank you David, this explains me what I didn't understand. 
> It turned out that somehow I was looking at a bad parser.yy.

Interesting.  Where did you get it?

-- 
David Kastrup


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