PATCH: Countdown to 20120311

[Colin Campbell]

For 20:00 MDT Sunday March 11, 2012

Defect:
Issue 2376 
: Automatic 
footnotes on \null markups causes unexpected results - R 5755058 




Enhancement:
Issue 2348 
: Patch: 
Handling of open strings in tablature - R 5695058 




Cheers,
Colin

--
... it is not enough to show that a situation is bad; it is also 
necessary to be reasonably certain that the problem has been properly 
described, fairly certain that the proposed remedy will improve it, and 
virtually certain that it will not make it worse.
 - Robert Conquest, (As quoted in _Basic Economics, A Citizen's Guide 
to the Economy_ by Thomas Sowell)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Cross-staff stem engraver (was: New frog in an empty pond?)

[Carl Sorensen]

On 3/8/12 2:44 PM, "Pavel Roskin"  wrote:

>Hello, Janek!
>
>Quoting Janek Warchoł :
>
>>> I'm attaching the Scheme code with a convoluted example (3 staves with
>>> 3 voices on each).
>>
>> I don't have the time to dive into details, but the output looks good!
>> Be sure to post it on Rietveld for a review when you come back.
>
>Thank you for your appreciation!  Sorry for delay - too little time
>and slow Internet here.  Could you please explain how I can put a
>standalone file to Rietveld?  I guess you mean that it should be added
>to Lilypond source?  You mean the ly directory or some place in the
>documentation?

Ordinarily something like this would go in the regression tests:

input/regression/cross-staff-stem-engraver.ly

And then you would add it to your git repository, and post it on Rietveld
for a review.

HTH,

Carl


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

Re: Cross-staff stem engraver (was: New frog in an empty pond?)

[Pavel Roskin]

Hello, Janek!

Quoting Janek Warchoł :


I'm attaching the Scheme code with a convoluted example (3 staves with
3 voices on each).


I don't have the time to dive into details, but the output looks good!
Be sure to post it on Rietveld for a review when you come back.


Thank you for your appreciation!  Sorry for delay - too little time  
and slow Internet here.  Could you please explain how I can put a  
standalone file to Rietveld?  I guess you mean that it should be added  
to Lilypond source?  You mean the ly directory or some place in the  
documentation?


--
Regards,
Pavel Roskin

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

Re: Git problem

[Graham Percival]

On Thu, Mar 08, 2012 at 05:24:51PM -, Phil Holmes wrote:
> One thought.  Some issues are best verified by checking lily output
> - http://code.google.com/p/lilypond/issues/detail?id=2246 for
> example.  Can we break a normal rule and check these against a newly
> made binary?  What we'd then be doing is saying "it was in the GUB
> binary and is still in master, so I'm going to verify".

I can make a binary despite the existing issues to verify in this
case.

- Graham

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

Re: Git problem

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 
To: "Peekay" ; "Colin Hall" ; 
"Eluze" ; "Marek Klein" ; "Ralph 
Palmer" 

Cc: "Graham Percival" ; 
Sent: Thursday, March 08, 2012 4:46 PM
Subject: Git problem


If you read .devel, you will have seen that there was a major problem with 
git.  As a result, we're not 100% sure that all the fixes verified for 
15.31 and 15.32 are still in the build.  I'm going through all the 
possible problem issues reverting Verified to Fixed.  The safest was to 
re-verify will be to check the source as pulled from master to ensure that 
the text shown as changed in the patch has actually appeared in the source 
code.  If you're not comfortable doing this, please leave them as "fixed" 
status and those of us who are can work our way through.


Graham - you may want to hold a further release just because of the 
uncertainty, but give us a while to work through these.



One thought.  Some issues are best verified by checking lily output - 
http://code.google.com/p/lilypond/issues/detail?id=2246 for example.  Can we 
break a normal rule and check these against a newly made binary?  What we'd 
then be doing is saying "it was in the GUB binary and is still in master, so 
I'm going to verify".


--
Phil Holmes



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

Re: Please stop pushing to the translation branch until further notice

[David Kastrup]

James  writes:

> On 8 March 2012 11:08, David Kastrup  wrote:
> ...
>
>>
>> In any case: I think you should merge (merge!) more often, master to
>> translation, translation to staging.  It does not make all that much
>> sense if translations come 2 versions later into master than they have
>> been written.  And when things go wrong, they go wrong in smaller
>> portions, and fewer stuff needs to get verified after cleaning up.
>
> Is this something 'we' could add easily to patchy? Then I could be
> doing that as part of what I am doing already?

I would not want that.  I have made it a point to make sure that Patchy
does not ever do anything except fast forwarding.  Merges are a
potentially complex operation and should be done under human control.
Only a human will know when a merge has been straightforward or not, and
how much attention to spend on its result.  Most merges will be a thing
done in a minute without thinking, but there may be some that require
more attention.  And a tool like Patchy would not know when.

-- 
David Kastrup

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

Re: Please stop pushing to the translation branch until further notice

[James]

Hello,

On 8 March 2012 11:08, David Kastrup  wrote:
...

>
> In any case: I think you should merge (merge!) more often, master to
> translation, translation to staging.  It does not make all that much
> sense if translations come 2 versions later into master than they have
> been written.  And when things go wrong, they go wrong in smaller
> portions, and fewer stuff needs to get verified after cleaning up.

Is this something 'we' could add easily to patchy? Then I could be
doing that as part of what I am doing already?


-- 
--

James

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

Re: Please stop pushing to the translation branch until further notice

[David Kastrup]

Francisco Vila  writes:

> 2012/3/8 David Kastrup :
>> The situation should now be under control again.  The translation branch
>> has been merged with a helper branch that should bring in all the
>> changes from commits that the merge history suggests to be present.
>
> Thank you, David. I apologize. I feel bad for your (and other's) loss
> of valuable time.
> Yes, I tried to be clever, autonomous, do not cause troubles to
> others, etc.

Well, git is powerful.  And yes: the translation work is something that
works "behind the scenes" to an astonishing degree and for me means
stuff that I don't need to worry about since it will "somehow happen"
(TM).  The downside to this magic is that you are working a lot on your
own, and figuring stuff on your own, and you are the one in the
translation team doing the "ugly" things like branch merges.

> I was not clever enough in the first place, judging from the
> results. I obviously did not check all that needed to be checked.  The
> checklist size is ever growing.

And partly because the translation team is operating rather silently, I
have my doubts that we have really good instructions for them in CG or
elsewhere.

> To avoid this in the future, I will not do push or merge when
> something looks suspicious.  That's what I have done in the past few
> months, when -- besides well-known pack/dist problems -- all has gone
> more or less smoothly, but this time I failed rather catastrophically.

Well, let's see it realistically.  The mainline has seen one really bad
commit (with diverging history and work tree), and one commit faking
history to bring both into line again.  We'll need to reverify every
issue after 2.15.30 to be on the safe side, but chances are pretty good
that there will be only few to no permanent problems.  Once we have
merged master back into the translation branch, all of the commits and
fake commits will be present in both branches.  That makes it likely
that any reverts we need to be doing on material in the affected commits
will actually work.  Development was locked up for a day, tension was
there for a day, I put in a day's work, the sidebranch history is messed
up for a while but now in synch again.  Translators will have to check
that my fixup work did not cause work of them to get lost.

And going by my usual standards, I did not even blow up.  It was bad
coincidence that this happened just when I had lots of other stuff to
do.

> This could easily be the worst disaster since Erik Sandberg lost his
> laptop.

No.  This is git.  One could have just reverted the merge commit into
the mainline, reset the translation branch to master, and cherrypicked
every change done in the translation branch since the last merge to
master manually into a new translation branch.  Every translator would
have had to reset his repository and work.  Maybe that would have been
the saner way to proceed, but it would have made a new mess in case some
translator would not have reset his branch.

I chose a fix that required no reset of either master or translation.
That was more complex for me, but it will hopefully be less complex to
others.  Perhaps I was being too clever here.  Which is a problem when
working with git.  Ok, probably I _was_ being too clever.  Easy to make
this mistake with git.  The solution with a full revert and a junking
and recreation of the translation branch would not have required the bug
squad to verify everything after 2.15.30 again.

Tough.  It was the best I was able to come up with on short notice.  On
the other hand, there were merges _from_ master into the translation
branch in the mean time, and that would have complicated that approach
as well.

> Thankfully we had backups, Erik had not.

He should have taken a lesson from Linux Torvalds (who does not bother
with backups either I seem to remember).  Just make sure that your
important work is spread across enough repositories.

To put some cosmic balance to it: last fall I had a fatal headcrash on
my previous computer.  Disk dead 100%, backups about 2 years old (the
ones I could access at first were actually more like 8 years).  When I
reinstalled a new system, I did not reinstall my Usenet access, and
passwords to a number of web forums.  Basically I took the opportunity
to let a lot of my internet identity die.

That was the point of time when my work on LilyPond seriously commenced.

In any case: I think you should merge (merge!) more often, master to
translation, translation to staging.  It does not make all that much
sense if translations come 2 versions later into master than they have
been written.  And when things go wrong, they go wrong in smaller
portions, and fewer stuff needs to get verified after cleaning up.

When you feel insecure about pushing something to staging, you can
always try pushing to some branch like

git push origin HEAD:refs/heads/dev/staging-test

instead and ask for opinions.  I don't think that we have much of a
chance teaching Patchy to figure out _

Re: Thinking about putting together a grant to support development on LilyPond

[Jan Nieuwenhuizen]

David Kastrup writes:

> Jan Nieuwenhuizen  writes:
>
>> Reinhold Kainhofer writes:
>>
 A) Development of ly2xml
>>>
>>> Reviewers would probably argue that this is not really scientific
>>> research and should be funded by an industry partner instead.
>>
>> Some may even note that the hardest part of this has already been
>> prototyped as part of schikkers list and argue Possible === Trivial
>> === Worthless ;-)
>
> Proven possible ==> not a research item.  Worthless?  Just ask Microsoft
> and Apple how worthless it is to repackage existing possibilities and
> prototypes.

Possibly, but then you'd have to apply for a marketing/branding oriented
grant?

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

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

Re: Please stop pushing to the translation branch until further notice

[Francisco Vila]

2012/3/8 David Kastrup :
> The situation should now be under control again.  The translation branch
> has been merged with a helper branch that should bring in all the
> changes from commits that the merge history suggests to be present.

Thank you, David. I apologize. I feel bad for your (and other's) loss
of valuable time.
Yes, I tried to be clever, autonomous, do not cause troubles to
others, etc. I was not clever enough in the first place, judging from
the results. I obviously did not check all that needed to be checked.
The checklist size is ever growing.

To avoid this in the future, I will not do push or merge when
something looks suspicious. That's what I have done in the past few
months, when -- besides well-known pack/dist problems -- all has gone
more or less smoothly, but this time I failed rather catastrophically.

This could easily be the worst disaster since Erik Sandberg lost his
laptop. Thankfully we had backups, Erik had not.

-- 
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: Thinking about putting together a grant to support development on LilyPond

[David Kastrup]

Jan Nieuwenhuizen  writes:

> Reinhold Kainhofer writes:
>
>>> A) Development of ly2xml
>>
>> Reviewers would probably argue that this is not really scientific
>> research and should be funded by an industry partner instead.
>
> Some may even note that the hardest part of this has already been
> prototyped as part of schikkers list and argue Possible === Trivial
> === Worthless ;-)

Proven possible ==> not a research item.  Worthless?  Just ask Microsoft
and Apple how worthless it is to repackage existing possibilities and
prototypes.

-- 
David Kastrup


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

Re: Thinking about putting together a grant to support development on LilyPond

[Jan Nieuwenhuizen]

Reinhold Kainhofer writes:

>> A) Development of ly2xml
>
> Reviewers would probably argue that this is not really scientific
> research and should be funded by an industry partner instead.

Some may even note that the hardest part of this has already been
prototyped as part of schikkers list and argue Possible === Trivial
=== Worthless ;-)

Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

Hey all,

An update on this patch.
After having correctly skylined dynamics, I'm realizing that serifed fonts and 
italicized fonts are posing a problem for snug vertical alignment.  Joe and I 
have been back and forth about a solution and he has graciously accepted to 
tag-team the problem with me, but it'll likely require several rounds of back 
and forth  between he and I to get it up to snuff.  So, you won't be seeing a 
new patch for a bit, but when you do, it'll lead to better results.

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