date:20111107


On 2011/11/07 09:15:04, dak wrote:

Uh, yes?  See line 1313: the argument list consists of an arbitrary

number of _pairs_.

Right - it's comparing (baseline, check) pairs.  I didn't introduce the
modulo, I just made it explicit which is more legible than relying on
Python's interpretation of 0 as False and 1 as True.

http://codereview.appspot.com/5342042/

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

Re: changes in chord names formatting (1503, 1572) (issue 4981052)

On 2011/11/07 00:15:48, Graham Percival wrote:

On Sun, Nov 06, 2011 at 03:52:15PM +, mailto:adam.spi...@gmail.com

wrote:

> I've done a corresponding patch for changes.tely but I don't have
> permissions to upload it to this issue

that's because Janek uploaded the original issue.  Could you just
make a new one?  just ignore the old codereview issue.

Uploading a new patch with git-cl, and associate it with issue
tracker 1503 or 1572.

- Graham

Whoops, I forgot that Carl already created a separate issue for the new
version of this patch series:

http://codereview.appspot.com/5320074

So this one (4981052) should be ignored entirely now, and closed/deleted
when Janek gets back.

http://codereview.appspot.com/4981052/

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

Re: Fixes to jazz chord displays (issue 5320074)


Thanks Carl, I've made these changes, and I've also made a corresponding
patch for changes.tely, but I don't think I have permission to upload
new patch sets for either to this issue since it says "Can't Edit" at
the top-left - can you give me permission?  (If not, this is yet another
reason Rietveld sucks.  It all seems way too locked down to me.)

In lieu of a patch set, the amended patch series is available here
(freshly rebased on master):

https://github.com/aspiers/lilypond/commits/jazz


http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly
File input/regression/chord-additional-pitch-prefix.ly (right):

http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly#newcode1
input/regression/chord-additional-pitch-prefix.ly:1: \version "2.15.16"
On 2011/11/05 14:33:32, Carl wrote:

Will need to be adjusted when it's ready to commit.  Right now, it

should be

2.15.17.



Version of new snippets is always one greater than the current release

version.

Done.

http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):

http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm#newcode380
scm/define-context-properties.scm:380: (minorChordModifier ,markup? "How
should minor chords be formatted
On 2011/11/05 14:33:32, Carl wrote:

I'd prefer "Markup displayed following the root for a minor chord."


Done.

http://codereview.appspot.com/5320074/

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote:
> Thanks Carl, I've made these changes, and I've also made a corresponding
> patch for changes.tely, but I don't think I have permission to upload
> new patch sets for either to this issue since it says "Can't Edit" at
> the top-left - can you give me permission?

I doubt it.  Just upload a new issue.

> (If not, this is yet another
> reason Rietveld sucks.  It all seems way too locked down to me.)

It's not build for collaborate patch editing.  The idea is that
you have a patch, you upload it.  Make a few small modifications,
go ahead and upload it to the same rietveld number... but anything
major and you should just make a new rietveld number.  Numbers are
cheap, after all.

Note that problems like this are fairly rare.  If we had an active
"frog meister", he'd be taking care rieveld for any inexperienced
contributors.  And experienced developers like you would be
directed to git-cl, so nobody would have uploaded any patches for
you anyway.

- Graham

___
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)


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

> I guess because we are not indicating a grob i.e.
> 
> c-\autoFootnote #'(1 . -1.25)
> 
> vs
> 
> \autoFootnote #'NoteHead #'(1 . -1.25)
> c4
> 
> Which does the same thing.
> 
> Mike any comment on this?
> 
>
> Yup - exactly.  The postfix operator only ever works in chords and
> will apply to NoteHeads.
> {  }
>
> 
> It seems to infer, now that Graham has phrased it like this, that
> note
> head grobs in this case are 'assumed' and not needed to be
> specified
> like a slur or beam grob etc.
> 
> 
>
> It'd be nice if this were more robust so that it could apply to other
> things like scripts, but for now, it only works with notes.  This
> could be a known issue if you'd like.

It is not clear to me whether this "known issue" is due to limitations
of music functions.  Would a changed behavior of music functions help?
I still have to tackle music functions inside of chords in order to make
the music function set reasonably orthogonal, so if you have suggestions
in that area...

-- 
David Kastrup

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival
 wrote:
> On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote:
>> Thanks Carl, I've made these changes, and I've also made a corresponding
>> patch for changes.tely, but I don't think I have permission to upload
>> new patch sets for either to this issue since it says "Can't Edit" at
>> the top-left - can you give me permission?
>
> I doubt it.  Just upload a new issue.

So then we would have *three* Rietveld issues tracking the
same thing.

>> (If not, this is yet another
>> reason Rietveld sucks.  It all seems way too locked down to me.)
>
> It's not build for collaborate patch editing.  The idea is that
> you have a patch, you upload it.  Make a few small modifications,
> go ahead and upload it to the same rietveld number... but anything
> major and you should just make a new rietveld number.  Numbers are
> cheap, after all.
>
> Note that problems like this are fairly rare.  If we had an active
> "frog meister", he'd be taking care rieveld for any inexperienced
> contributors.  And experienced developers like you would be
> directed to git-cl, so nobody would have uploaded any patches for
> you anyway.

Understood, but I still think this workflow is fundamentally flawed.
However I'm aware this is not the time nor place to discuss this
further.

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

Re: Fixes to jazz chord displays (issue 5320074)

2011-11-07 Thread Carl Sorensen



On Nov 7, 2011, at 5:34 AM, "Adam Spiers"  wrote:

> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival
>  wrote:
>> On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote:
>>> Thanks Carl, I've made these changes, and I've also made a corresponding
>>> patch for changes.tely, but I don't think I have permission to upload
>>> new patch sets for either to this issue since it says "Can't Edit" at
>>> the top-left - can you give me permission?
>> 
>> I doubt it.  Just upload a new issue.
> 
> So then we would have *three* Rietveld issues tracking the
> same thing.
> 
>>> (If not, this is yet another
>>> reason Rietveld sucks.  It all seems way too locked down to me.)
>> 
>> It's not build for collaborate patch editing.  The idea is that
>> you have a patch, you upload it.  Make a few small modifications,
>> go ahead and upload it to the same rietveld number... but anything
>> major and you should just make a new rietveld number.  Numbers are
>> cheap, after all.
>> 
>> Note that problems like this are fairly rare.  If we had an active
>> "frog meister", he'd be taking care rieveld for any inexperienced
>> contributors.  And experienced developers like you would be
>> directed to git-cl, so nobody would have uploaded any patches for
>> you anyway.
> 
> Understood, but I still think this workflow is fundamentally flawed.
> However I'm aware this is not the time nor place to discuss this
> further.

I'll get the update posted today. For this patch, I'm serving as adam's frog 
meister since last Thursday. 

Thanks,

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 07, 2011 at 12:34:15PM +, Adam Spiers wrote:
> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival
>  wrote:
> > I doubt it.  Just upload a new issue.
> 
> So then we would have *three* Rietveld issues tracking the
> same thing.

The google code issue is our pointer.  Rietveld is our memory.  We
have one object in memory (the rietveld issue you're going to
upload), and two objects which have been de-referenced (Janek's
and Carl's uploads).

Our machine has infinite memory (because it's run on google
servers, and they have more bandwidth than god, and also more
processing power than the NSA [1]).  Garbage collection happens
whenever Carl and Janek get around to it.

Stop wasting time -- both mine and yours -- trying to handle the
memory manually.  Unless you're writing kernel or DSP code,
programmers outgrew that in the 90s.  We're not going to lose the
de-referenced pointers, so it's not a memory leak.

capiche?

[1] this is almost certainly false, but it's such a nice pithy
quote that I couldn't resist inventing it.

- Graham

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 07, 2011 at 12:44:42PM +, Carl Sorensen wrote:
> 
> I'll get the update posted today. For this patch, I'm serving as
> adam's frog meister since last Thursday. 

Adam is a very experienced developer, and he already knows how to
use git-cl.  He's even patched it!  He's not a frog, so he doesn't
need a frog meister.

Waiting for you to upload stuff adds a completely unnecessary
delay and annoyance to the process.  With anybody else, your
assistance would be extremely valuable and appreciated, but in
this case I don't see it adding any value.

- Graham

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival
 wrote:
> On Mon, Nov 07, 2011 at 12:34:15PM +, Adam Spiers wrote:
>> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival
>>  wrote:
>> > I doubt it.  Just upload a new issue.
>>
>> So then we would have *three* Rietveld issues tracking the
>> same thing.
>
> The google code issue is our pointer.  Rietveld is our memory.  We
> have one object in memory (the rietveld issue you're going to
> upload), and two objects which have been de-referenced (Janek's
> and Carl's uploads).
> Our machine has infinite memory (because it's run on google
> servers, and they have more bandwidth than god, and also more
> processing power than the NSA [1]).  Garbage collection happens
> whenever Carl and Janek get around to it.
>
> Stop wasting time -- both mine and yours -- trying to handle the
> memory manually.  Unless you're writing kernel or DSP code,
> programmers outgrew that in the 90s.

Sure, but it's the de-referencing which worries me for two reasons:

1. These older review issues contain potentially useful history about
   the review process, so allowing them to be garbage collected
   doesn't sound safe to me.

2. It's not always clear that they have been de-referenced, which can
   easily cause confusion.  Case in point - I accidentally updated an
   old issue within the last 24 hours because I forgot a new one had
   superceded it.  And I was directly involved with the creation of
   both!  This could have been avoided by closing the old issue except
   for Rietveld's inflexible ACL model.  I suppose a workaround could
   be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE
   ISSUE 12345".  I'll do that from now on.

> We're not going to lose the de-referenced pointers, so it's not a
> memory leak.

Your analogy was working quite nicely until this point, but I don't
know what you mean by "de-referenced pointers".  I'm guessing you
meant "de-referenced objects", but then what would the garbage
collection you refer to actually do?

> capiche?

Almost.  It's still an over-complex system though.  Ultimately I think
it boils down to (a) Rietveld having a lowest common denominator
approach to revision control systems rather than properly supporting
git/mercurial, and (b) having two sub-par systems (Rietveld and Google
Code) when one comprehensive integrated system would be much better
(not sure that such a beast exists yet, but github looks pretty damn
good these days, maybe also Gerrit).

> [1] this is almost certainly false, but it's such a nice pithy
> quote that I couldn't resist inventing it.

:-)  Actually I suspect it's true.

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 7, 2011 at 2:13 PM, Graham Percival
 wrote:
> On Mon, Nov 07, 2011 at 12:44:42PM +, Carl Sorensen wrote:
>> I'll get the update posted today. For this patch, I'm serving as
>> adam's frog meister since last Thursday.
>
> Adam is a very experienced developer, and he already knows how to
> use git-cl.  He's even patched it!  He's not a frog, so he doesn't
> need a frog meister.
>
> Waiting for you to upload stuff adds a completely unnecessary
> delay and annoyance to the process.  With anybody else, your
> assistance would be extremely valuable and appreciated, but in
> this case I don't see it adding any value.

Yeah, thanks a lot Carl for your help so far but it probably is
simpler at this stage if I just do a git cl upload into a fresh
ticket.  Hopefully this time everyone will have run out of ideas for
how to improve the patch series and it can be pushed to staging soon :)

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

Re: Fixes to jazz chord displays (issue 5320074)

On Mon, Nov 07, 2011 at 02:44:01PM +, Adam Spiers wrote:
> On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival
>  wrote:
> > The google code issue is our pointer.  Rietveld is our memory.  We
> 
> Sure, but it's the de-referencing which worries me for two reasons:
> 
> 1. These older review issues contain potentially useful history about
>the review process, so allowing them to be garbage collected
>doesn't sound safe to me.

True, although our entire review kind-of sucks when people have
large-ish new features.

But this is also a fairly rare: we had a race condition between
uploading of patches and your knowledge of our development
process.  Or maybe it's a starving philosopher problem...
beginners need a waiter to allocate and pick up forks for them,
while developers are encouraged to look around the table and
decide which forks to use for themselves.

> 2. It's not always clear that they have been de-referenced, which can
>easily cause confusion.  
> I suppose a workaround could
>be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE
>ISSUE 12345".  I'll do that from now on.

We've done stuff like that occasionally.

> > We're not going to lose the de-referenced pointers, so it's not a
> > memory leak.
> 
> Your analogy was working quite nicely until this point, but I don't
> know what you mean by "de-referenced pointers".  I'm guessing you
> meant "de-referenced objects",

oops, yes.

> but then what would the garbage
> collection you refer to actually do?

Since not everybody is using the new git-cl, and since the new
git-cl isn't bullet-proof in any case, we tend to lose
approximately 5% of our patches.

... I'll pause a moment while you get over your shock.

Done?  ok, great.  The traditional solution is to manually click
on people's names, i.e.
http://codereview.appspot.com/user/dak

and look at all the patches under the "Created by dak".  19 times
out of 20, between 20% - 80% of those patches are still actively
discussed or being worked on.
(yes, that's a large range, but I wanted to keep my 95% confidence
interval)
Up to 60% of those patches have been pushed and can be "garbage
collected" (i.e. dak logs in and clicks the round "x" beside the
patch), and up to 30% of those patches were forgotten about.  A
few reminders, a quick round of reviewing later, that patch can be
pushed, and we've got one more bugfix or new feature.

The benefit of running garbage collection is to reduce the number
of patches that have already been pushed.  That should make it
easier to spot the forgotten patches.  (in practice, of course we
run garbage collection and lost-resource finding algorithms at the
same time, since that means that we only traverse our list once)

There's also patches that people attach to comments on the google
code issue tracker.  Those are even easier to lose.

> > capiche?
> 
> Almost.  It's still an over-complex system though.

Other than GOP, we haven't put any serious effort into scaling up
development.  Back in 2009, we had a huge technical debt (lots of
regressions blocking a stable release).  It took over a year of
dedicated work just to reach the stability of 2.12.

We still have tons of technical debt, but at the moment I think
our "social debt" is even worse.  We don't have a good workflow
for dealing with the amount and skills of developers.  At the
moment we're stumbling forward with hack on top of hack.

GOP is an attempt to systematically clear up that social debt,
until we get to a level at which we can move back to tackling the
technical debt.  And somewhere in this mix, we have people
clamoring for systematic revamping and committment to our input
syntax, i.e. GLISS.  I'm actually beginning to think that we
should cut GOP short; just institute a few more hacks to keep
development rolling forward, then run GLISS for half a year or
something to take some of that pressure off.

The bottleneck in this whole process is my absolute committment to
working for 10 hours a week on lilypond; no more, no less.  I've
spent multiple weeks working more than 50 hours on lilypond, and
that just isn't sensible for my career.

- Graham

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

Re: Improve HTML output of regression tests (issue 5342042)

2011-11-07 Thread julien . rioux


Only stylistic comments:


http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py
File scripts/build/output-distance.py (right):

http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode8
scripts/build/output-distance.py:8: from cgi import escape
Since the style within lilypond's python sources is to import the module
into the namespace, it would be nice to keep to that style, e.g. "import
cgi" here, and then...

http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode462
scripts/build/output-distance.py:462: str = '%s' % escape(str)
...use "cgi.escape (str)" here. The space before the parenthesis is also
to keep the consistent style.

http://codereview.appspot.com/5342042/

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

make doc failure on fresh build tree

The below error was caused by 'make -j2 doc' on a fresh build tree -
any ideas?

/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/extending.texi
The style file:
/home/adam/music/software/lilypond.git/Documentation/lily-bib.bst
Database file #1:
/home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib
/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/snippets.texi
extract_texi_filenames.py: Processing out-www/extending.texi
extract_texi_filenames.py: Processing out-www/snippets.texi
Traceback (most recent call last):
  File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 304, in 
Traceback (most recent call last):
  File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 304, in 
(lang_suffix, sections) = extract_sections (filename)
  File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 142, in extract_sections
f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/extending.texi'
(lang_suffix, sections) = extract_sections (filename)
  File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 142, in extract_sections
f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi'
make[2]: *** 
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map]
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** 
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map]
Error 1
make[2]: Leaving directory
`/home/adam/.GIT/3rd-party/lilypond/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build'
make: *** [doc-stage-1] Error 2

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

Re: make doc failure on fresh build tree

2011-11-07 Thread Phil Holmes

- Original Message - 
From: "Adam Spiers" 

To: 
Sent: Monday, November 07, 2011 5:00 PM
Subject: make doc failure on fresh build tree



The below error was caused by 'make -j2 doc' on a fresh build tree -
any ideas?

/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/extending.texi
The style file:
/home/adam/music/software/lilypond.git/Documentation/lily-bib.bst
Database file #1:
/home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib
/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/snippets.texi
extract_texi_filenames.py: Processing out-www/extending.texi
extract_texi_filenames.py: Processing out-www/snippets.texi
Traceback (most recent call last):
 File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",

line 304, in 
Traceback (most recent call last):
 File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",

line 304, in 
   (lang_suffix, sections) = extract_sections (filename)
 File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",

line 142, in extract_sections
   f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/extending.texi'
(lang_suffix, sections) = extract_sections (filename)
 File 
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",

line 142, in extract_sections
   f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi'
make[2]: *** 
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map]

Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** 
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map]

Error 1
make[2]: Leaving directory
`/home/adam/.GIT/3rd-party/lilypond/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build'
make: *** [doc-stage-1] Error 2



Have you run make first?

--
Phil Holmes



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

Re: make doc failure on fresh build tree

2011-11-07 Thread Peekay Ex

Hello,

On Mon, Nov 7, 2011 at 5:14 PM, Phil Holmes  wrote:
> - Original Message - From: "Adam Spiers"
> 
> To: 
> Sent: Monday, November 07, 2011 5:00 PM
> Subject: make doc failure on fresh build tree
>
>
>> The below error was caused by 'make -j2 doc' on a fresh build tree -
>> any ideas?
>>
>>
>> /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
>> -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
>> -I /home/adam/music/software/lilypond.git/Documentation -o
>> /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
>> out-www/extending.texi
>> The style file:
>> /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst
>> Database file #1:
>>
>> /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib
>>
>> /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
>> -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
>> -I /home/adam/music/software/lilypond.git/Documentation -o
>> /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
>> out-www/snippets.texi
>> extract_texi_filenames.py: Processing out-www/extending.texi
>> extract_texi_filenames.py: Processing out-www/snippets.texi
>> Traceback (most recent call last):
>>  File
>> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
>> line 304, in 
>> Traceback (most recent call last):
>>  File
>> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
>> line 304, in 
>>       (lang_suffix, sections) = extract_sections (filename)
>>  File
>> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
>> line 142, in extract_sections
>>   f = open (filename, 'r')
>> IOError: [Errno 2] No such file or directory: 'out-www/extending.texi'
>> (lang_suffix, sections) = extract_sections (filename)
>>  File
>> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
>> line 142, in extract_sections
>>   f = open (filename, 'r')
>> IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi'
>> make[2]: ***
>> [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map]
>> Error 1
>> make[2]: *** Waiting for unfinished jobs
>> make[2]: ***
>> [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map]
>> Error 1
>> make[2]: Leaving directory
>> `/home/adam/.GIT/3rd-party/lilypond/build/Documentation'
>> make[1]: *** [WWW-1] Error 2
>> make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build'
>> make: *** [doc-stage-1] Error 2
>
>
> Have you run make first?
>

and if you have - I've noticed that since I last did a make doc there
have been some translation merges, so what I do is roll back git to
before they were added and at least see if you can make doc there

The last known good commit that I did a full make doc on was

4bc910c81829ce9ae0a8c44d339bcdcf12d03802 about 2 days ago.

regards

-- 
--
James

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

Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)

2011-11-07 Thread ianhulin44


On 2011/11/06 21:30:18, adam.spiers wrote:

I disagree - there is no way to be sure that the cause of the

StopIteration

really was the user failing to run make test-baseline first.  For

example he

could have run it but then something else accidentally (or

deliberately) deleted

those directories.  That's why I deliberately phrased it as a question

- it's

intended to prompt the user into switching their brain into

diagnostics mode.

If they choose to ignore the warnings, well, that's their problem :-)


Hmmm... If you're giving a warning, just state the facts, making it a
question is bad "headology" as they may interpret it as *you* being
unsure of what you're reporting.
It's a detail, and doesn't need to be a deal-breaker.


You're right, though, if they can't RTFW (Read The Finely-crafted
Warning (:==:)), they deserve everything they get.
Having the diagnostic LGTM.
Ian

http://codereview.appspot.com/5361042/

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

Re: make doc failure on fresh build tree

2011-11-07 Thread Phil Holmes

- Original Message - 
From: "Peekay Ex" 
To: "Phil Holmes" ; "Adam Spiers" 


Cc: 
Sent: Monday, November 07, 2011 5:26 PM
Subject: Re: make doc failure on fresh build tree


Hello,

On Mon, Nov 7, 2011 at 5:14 PM, Phil Holmes  wrote:

- Original Message - From: "Adam Spiers"

To: 
Sent: Monday, November 07, 2011 5:00 PM
Subject: make doc failure on fresh build tree



The below error was caused by 'make -j2 doc' on a fresh build tree -
any ideas?


/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/extending.texi
The style file:
/home/adam/music/software/lilypond.git/Documentation/lily-bib.bst
Database file #1:

/home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib

/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames
-I ./out-www -I /home/adam/music/software/lilypond.git/Documentation
-I /home/adam/music/software/lilypond.git/Documentation -o
/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps
out-www/snippets.texi
extract_texi_filenames.py: Processing out-www/extending.texi
extract_texi_filenames.py: Processing out-www/snippets.texi
Traceback (most recent call last):
File
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 304, in 
Traceback (most recent call last):
File
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 304, in 
(lang_suffix, sections) = extract_sections (filename)
File
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 142, in extract_sections
f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/extending.texi'
(lang_suffix, sections) = extract_sections (filename)
File
"/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
line 142, in extract_sections
f = open (filename, 'r')
IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi'
make[2]: ***
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map]
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: ***
[/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map]
Error 1
make[2]: Leaving directory
`/home/adam/.GIT/3rd-party/lilypond/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build'
make: *** [doc-stage-1] Error 2



Have you run make first?



and if you have - I've noticed that since I last did a make doc there
have been some translation merges, so what I do is roll back git to
before they were added and at least see if you can make doc there

The last known good commit that I did a full make doc on was

4bc910c81829ce9ae0a8c44d339bcdcf12d03802 about 2 days ago.




Latest master makes doc clean on my system.

--
Phil Holmes


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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

On Sun, 06 Nov 2011 23:34:37 -0800, wrote:

http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc#newcode96
lily/pure-from-neighbor-interface.cc:96: && (grace == LEFT ? has_grace :
!has_grace))
On 2011/11/07 01:25:30, Keith wrote:

In fact, why even use a loop over grace-ness if the actions within the

loop

occur only for one of two passes through ?

I'm not sure what you mean...the actions apply for both passes.

Well, the condition we are commenting on is inside an if() that protects the
only action in the loop over grace.
The loop takes action for just the one value of 'grace = (has_grace? LEFT :
RIGHT);'.
The other statements inside the loop over 'grace' look to be loop-invariants.

I realize that do{}while(flip()!=LEFT) is a LilyPond idiom, but in this case it
seems more clear to update array element that needs it, without looping over
the other case.

This is saying "if the closest column is a grace-note-column, include
the next-closest column as well." This gets rid of any accidental
overlap problems at the expense of potentially adding a little extra
vertical space to the page-spacer calculations, but this extra space
seems to be so minimal as to not be a problem (not unlike pure heights
for beamed stems, which could also slightly overshoot their actual
height).

I had not realized that the results of the pure-from-neighbor system influence
the page-spacing. This is inconvenient. Now I have some idea why there is so
much effort to increase the height only as much as needed.

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

Re: Fixes to jazz chord displays (issue 5320074)


Please close this issue as it's now superceded by
http://codereview.appspot.com/5343050/ - thanks!

http://codereview.appspot.com/5320074/

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

Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)


New version attached.

http://codereview.appspot.com/5361042/

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

Re: Improve HTML output of regression tests (issue 5342042)


New patch set uploaded.


http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py
File scripts/build/output-distance.py (right):

http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode8
scripts/build/output-distance.py:8: from cgi import escape
On 2011/11/07 15:53:49, Julien Rioux wrote:

Since the style within lilypond's python sources is to import the

module into

the namespace, it would be nice to keep to that style, e.g. "import

cgi" here,

and then...


Done.

http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode462
scripts/build/output-distance.py:462: str = '%s' % escape(str)
On 2011/11/07 15:53:49, Julien Rioux wrote:

...use "cgi.escape (str)" here. The space before the parenthesis is

also to keep

the consistent style.


Done.

http://codereview.appspot.com/5342042/

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

Re: make doc failure on fresh build tree

On Mon, Nov 07, 2011 at 05:00:23PM +, Adam Spiers wrote:
> extract_texi_filenames.py: Processing out-www/snippets.texi
> Traceback (most recent call last):
>   File 
> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",
> line 304, in 
> Traceback (most recent call last):
>   File 
> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames",

I've honestly never seen that kind of a warning.

> IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi'

hmm.

First, it's possible that a change to a GNUmakefile could require
you to re-run autogen.sh and configure.

Second, it's just possible that your disk partition is out of
space.  (I lost half a day last week trying to track down an
apparent bug in imagemagick that just turned out to be my /tmp
being full)

Failing either of these, I guess we're into git bisect time, which
of course sucks for doc-building if you're not Phil or James.  I
know that Phil can build the docs, but hopefully James' computer
will fail in this same way?
(assuming it's not the autogen issue)

- Graham

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

Re: make doc failure on fresh build tree

2011-11-07 Thread Neil Puttock

On 7 November 2011 19:32, Graham Percival  wrote:

> Failing either of these, I guess we're into git bisect time, which
> of course sucks for doc-building if you're not Phil or James.  I
> know that Phil can build the docs, but hopefully James' computer
> will fail in this same way?

I've just finished building the docs without incident.

Cheers,
Neil

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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

2011-11-07 Thread m...@apollinemike.com

On Nov 7, 2011, at 10:46 AM, Keith OHara wrote:

> 
>> This is saying "if the closest column is a grace-note-column, include
>> the next-closest column as well."  This gets rid of any accidental
>> overlap problems at the expense of potentially adding a little extra
>> vertical space to the page-spacer calculations, but this extra space
>> seems to be so minimal as to not be a problem (not unlike pure heights
>> for beamed stems, which could also slightly overshoot their actual
>> height).
> 
> I had not realized that the results of the pure-from-neighbor system 
> influence the page-spacing.  This is inconvenient.  Now I have some idea why 
> there is so much effort to increase the height only as much as needed.
> 

I misspoke - in this case, it does not.  But it does potentially add unwanted 
horizontal space.
All pure heights influence page-spacing.  Try:

\relative c' {
 \override Staff . BarLine #'Y-extent =
   #(ly:make-unpure-pure-container '(-100 . 10) '(-2 . 2))
 \repeat unfold 52 { a b c d }
}

extra-spacing-height, which is what this current patch adds, has no influence 
on vertical spacing.  But there is so much effort to increase the height as 
needed for the following reason.

CASE 1
\new GrandStaff
<<
\new Staff \relative c {
   \override Staff . BarLine #'extra-spacing-height = #'(-1 . 1)
   \override TextScript #'extra-spacing-width = ##f
   \repeat unfold 52 { dis4 dis dis dis^"foo bar" }
}
\new Staff \repeat unfold 52 R1
>> 

Build this with current master and you'll see the span bar problem fixed but 
the text script elongating the measure.

CASE TWO
\new GrandStaff
<<
\new Staff \relative c {
   \override TextScript #'extra-spacing-width = ##f
   \repeat unfold 52 { dis4 dis dis dis^"foo bar" }
}
\new Staff \repeat unfold 52 R1
>> 

Build this with the most current version of my patch and the text script won't 
elongate the measure (it did with older versions of my patch, but your comments 
made me realize a flaw in the way the interface worked, so thank you!).

In a future patch, I can imagine the creation of a new grob, SpacingStub, that 
replaces extra spacing height.  Two would be attached to every grob, and they 
would allow for more fine-tuned break alignment.  For example, to achieve 
accidentals that don't cross over barlines but are allowed to get snug like the 
examples you added to the tracker, the SpacingStub could have a different 
spacing-alist than BarLine to allow this to happen.

Cheers,
MS

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

Re: make doc failure on fresh build tree

On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock  wrote:
> On 7 November 2011 19:32, Graham Percival  wrote:
>
>> Failing either of these, I guess we're into git bisect time, which
>> of course sucks for doc-building if you're not Phil or James.  I
>> know that Phil can build the docs, but hopefully James' computer
>> will fail in this same way?
>
> I've just finished building the docs without incident.

I ran it again without -j2 and it completed fine.  *shrug*

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

Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

2011-11-07 Thread Carl . D . Sorensen


I am not in favor of the tab-to-space change in
scm/chord-ignatzek-names.scm, since we don't yet have agreement on
removing tabs from .scm files, AFAICS.

However, if nobody else is worried about it, I won't complain.  I'd
prefer to have the tabs gone.  And if we can do it through the backdoor,
I'm OK with it.

Thanks,

Carl



http://codereview.appspot.com/5343050/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/5343050/diff/1/Documentation/changes.tely#newcode64
Documentation/changes.tely:64: Support for jazz-like chords has been
improved: Lydian and altered
Perhaps change "chords" to "chord-naming" in this line.

http://codereview.appspot.com/5343050/diff/1/input/regression/chord-additional-pitch-prefix.ly
File input/regression/chord-additional-pitch-prefix.ly (right):

http://codereview.appspot.com/5343050/diff/1/input/regression/chord-additional-pitch-prefix.ly#newcode4
input/regression/chord-additional-pitch-prefix.ly:4:
@code{additionalPitchPrefix}."
We may not want to have the syntax in the texidoc.  We try to avoid
"talking through the code" in the NR; I think it's probably a good idea
to keep the same policy in the regression tests.

http://codereview.appspot.com/5343050/diff/1/scm/chord-ignatzek-names.scm
File scm/chord-ignatzek-names.scm (right):

http://codereview.appspot.com/5343050/diff/1/scm/chord-ignatzek-names.scm#newcode47
scm/chord-ignatzek-names.scm:47: (car ps)
I don't think we should have the tab-to-space conversion in .scm files,
because we don't have an agreement on removing tabs from .scm files,
AFAICS.

I removed this change from your branch when I posted my review set.

If others are happy with it, given the time already spend on getting
this patch approved, I won't object.

http://codereview.appspot.com/5343050/

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)


Passes make but two reg test diffs - see

http://code.google.com/p/lilypond/issues/detail?id=1503#c32

James

http://codereview.appspot.com/5343050/

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

Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)


Passes Make and no reg test diffs.

James

http://codereview.appspot.com/5361042/

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

Re: Improve HTML output of regression tests (issue 5342042)


passes make and no reg test diffs.

james

http://codereview.appspot.com/5342042/

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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)


Passes make but lots of reg test diffs as usual

http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-7-Nov-2011-td4962666.html

Jame

http://codereview.appspot.com/5323062/

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote:
> I am not in favor of the tab-to-space change in
> scm/chord-ignatzek-names.scm, since we don't yet have agreement on
> removing tabs from .scm files, AFAICS.

True, but I assume that other parts of the patch set depend on
this, and high-quality work, so I vote for turning a blind eye to
this change and accepting the patch set.

> We may not want to have the syntax in the texidoc.  We try to avoid
> "talking through the code" in the NR; I think it's probably a good idea
> to keep the same policy in the regression tests.

We have either an official or semi-official policy that developers
can do whatever the mao they want in the regression tests.
They're not documentation, no user should ever see them, so as
long as it's clear what is being tested and what the output should
look like (if there's doubt), it's not worth fussing about their
texidocs.

- Graham

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival
 wrote:
> On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote:
>> I am not in favor of the tab-to-space change in
>> scm/chord-ignatzek-names.scm, since we don't yet have agreement on
>> removing tabs from .scm files, AFAICS.
>
> True, but I assume that other parts of the patch set depend on
> this, and high-quality work, so I vote for turning a blind eye to
> this change and accepting the patch set.

Thanks - I tried removing it and rebasing, but it was more work than
I have time for.  I'm already about 1000% over budget on all this.

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

Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)

2011-11-07 Thread Carl . D . Sorensen


New patchset uploaded

http://codereview.appspot.com/4941041/

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

Adam Spiers  writes:

> On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival
>  wrote:
>> On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote:
>>> I am not in favor of the tab-to-space change in
>>> scm/chord-ignatzek-names.scm, since we don't yet have agreement on
>>> removing tabs from .scm files, AFAICS.
>>
>> True, but I assume that other parts of the patch set depend on
>> this, and high-quality work, so I vote for turning a blind eye to
>> this change and accepting the patch set.
>
> Thanks - I tried removing it and rebasing, but it was more work than
> I have time for.

Which is _exactly_ the reason why gratuitous spacing changes are a bad
idea.  Because it makes rebasing more work than people have time for.
In this case, the damage is already done, so there seems little point in
investing the effort for trying to get back again.

> I'm already about 1000% over budget on all this.

Welcome to the club.

-- 
David Kastrup

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

On Mon, Nov 7, 2011 at 10:11 PM, David Kastrup  wrote:
> In this case, the damage is already done, so there seems little point in
> investing the effort for trying to get back again.

Especially considering my first patch submission did *not* have
gratuitous whitespace changes, and I only put them in after I was
asked to during a review.  It's probably cost me more time than it has
anyone else.  Let's not waste any more time on the matter now.

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

Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)


Make passes but make check fails on

\sourcefilename
"/home/jlowe/lilypond-git/input/regression/beamlet-point-toward-beat.ly"
\sourcefileline 0
\version "2.15.17"

\header {
  \texidoc = "
Beamlets should point in the direction of the beat to which they
belong.
"
}


\relative c' {
b16. b32 b32 b16.
b16.[ b32 b   b b b16.]
}

James

http://codereview.appspot.com/4941041/

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

Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)

2011-11-07 Thread Carl . D . Sorensen


New patch set

http://codereview.appspot.com/4941041/

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

Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)

2011-11-07 Thread Carl Sorensen

On 11/7/11 2:48 PM, "Adam Spiers"  wrote:

>On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival
> wrote:
>> On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com
>>wrote:
>>> I am not in favor of the tab-to-space change in
>>> scm/chord-ignatzek-names.scm, since we don't yet have agreement on
>>> removing tabs from .scm files, AFAICS.
>>
>> True, but I assume that other parts of the patch set depend on
>> this, and high-quality work, so I vote for turning a blind eye to
>> this change and accepting the patch set.
>
>Thanks - I tried removing it and rebasing, but it was more work than
>I have time for.  I'm already about 1000% over budget on all this.

As I mentioned earlier, I agree with this decision.

However, I should mention that I rebased things to take that whitespace
change out, and if Graham had let me finish serving as frog-meister for
this patch (I got the assignment to do so last Thursday), we'd have a
patch set up without the whitespace changes.

I don't want to revisit any of these decisions for this time -- let's just
get the bugfix in the maoing source tree.  But I *am* a bit frustrated
that my work was all in vain.

Thanks,

Carl

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

Re: Internals questions - \include and LilyPond assignments

2011-11-07 Thread Han-Wen Nienhuys

On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin  wrote:
> Hi all,
>
> A couple of questions in case someone with more internal code-fu than me
> can save me rummaging around in the guts of the C++ code, just so I can
> get a handle on some behaviour I've noted trying to get LilyPond to fire
> up with Guile V2.0.3.
>
> 1.  Does processing a file via \include cause a new LilyPond scope ->
>    generating a new "anonymous" Guile module for that file?

no.

> 2.  How and when does a LilyPond assignment
>    blah = { lily-statements... }
>    get compiled down in to a scheme (define blah  )?
>    Guile V2 complains about stuff like
>    ignatzekExceptionMusic = { blah blah2 blah3}

this happens when the parser decides it can reduce the input to an assignment,

assignment:
assignment_id '=' identifier_init  {
PARSER->lexer_->set_identifier ($1, $3);
}


the actual work is in the function

  scm_module_define (mod, sym, val);

there is some trickiness with ordering. The parser may do look ahead
up to the #( .. ) you have before it decide to do the reduction.

In doubt, you can force it by inserting a dummy scheme statement in
between both assignments.


-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: Fixes to jazz chord displays (issue 5320074)

2011-11-07 Thread Colin Campbell


On 11-11-07 12:08 PM, adam.spi...@gmail.com wrote:

Please close this issue as it's now superceded by
http://codereview.appspot.com/5343050/ - thanks!

http://codereview.appspot.com/5320074/

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



Adam, you are the creator of the Rietveld issue, so you need to log on 
and edit the issue. You should see a "closed" button and be sure to 
update the issue.  I share your frustration with the pair of band-aids 
we are using, BTW!


Cheers,
Colin Campbell
Rank and file patch nanny


--
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: Internals questions - \include and LilyPond assignments

Han-Wen Nienhuys  writes:

> On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin  wrote:
>> Hi all,
>>
>> A couple of questions in case someone with more internal code-fu than me
>> can save me rummaging around in the guts of the C++ code, just so I can
>> get a handle on some behaviour I've noted trying to get LilyPond to fire
>> up with Guile V2.0.3.
>>
>> 1.  Does processing a file via \include cause a new LilyPond scope ->
>>    generating a new "anonymous" Guile module for that file?
>
> no.
>
>> 2.  How and when does a LilyPond assignment
>>    blah = { lily-statements... }
>>    get compiled down in to a scheme (define blah  )?
>>    Guile V2 complains about stuff like
>>    ignatzekExceptionMusic = { blah blah2 blah3}
>
> this happens when the parser decides it can reduce the input to an assignment,
>
> assignment:
> assignment_id '=' identifier_init  {
> PARSER->lexer_->set_identifier ($1, $3);
> }
>
>
> the actual work is in the function
>
>   scm_module_define (mod, sym, val);
>
> there is some trickiness with ordering. The parser may do look ahead
> up to the #( .. ) you have before it decide to do the reduction.
>
> In doubt, you can force it by inserting a dummy scheme statement in
> between both assignments.

I currently have a patch in review (will submit a regtest-passing
version in the next hour) that makes $... take over the job of
#(ly:export ...) in general instead just half-bakedly in #{ ... #}.
Once ly:export is retired, # can be made to just _read_ a Scheme
expression in the lexer, and let the _parser_ evaluate it when it is
used (this is not possible while ly:export is functional).

That should seriously decrease the potential for Premature Evaluation.

Until then, #(begin) is a good interjaculation.

-- 
David Kastrup


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

Re: The value of LilyPond, according to Ohloh

2011-11-07 Thread Han-Wen Nienhuys

I think the number is way off.  AFAICS at
http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all
stable branches as separate.

Last time I looked lilypond was around 100k lines of code (a quick
look says it 200k now; I suspect the GNU headers as a cause). 390 man
years looks exaggeratedl, since I wrote most of it (at least before
2007), and it took me much less than 300 years. Realistically,
lilypond may represent 20-40 man years, considering I must have put in
well over 10 personally.

On Sat, Nov 5, 2011 at 12:01 AM, Carl Sorensen  wrote:
> So I was googling for yaffut to see what I could learn about it, and I
> found that ohloh has a rating system for the projects in its database.
>
> I looked up LilyPond, and found it:
>
> http://www.ohloh.net/p/lilypond
>
>
> The factoids about it are very complimentary.
>
> One interesting point -- the estimated value of LilyPond is $16,000,000
>
> Over 1 million lines of code.
>
> The estimated developer time is 309 man years
>
> LilyPond is a *real* software project.
>
> Just an interesting fact.
>

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: make doc failure on fresh build tree

2011-11-07 Thread Colin Campbell


On 11-11-07 12:46 PM, Adam Spiers wrote:

On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock  wrote:

On 7 November 2011 19:32, Graham Percival  wrote:


Failing either of these, I guess we're into git bisect time, which
of course sucks for doc-building if you're not Phil or James.  I
know that Phil can build the docs, but hopefully James' computer
will fail in this same way?

I've just finished building the docs without incident.

I ran it again without -j2 and it completed fine.  *shrug*

___




ISTR there's a long standing problem with forking make doc, although the 
initial make to [roduce the binaries seems not to mind.


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: The value of LilyPond, according to Ohloh

Han-Wen Nienhuys  writes:

> I think the number is way off.  AFAICS at
> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all
> stable branches as separate.
>
> Last time I looked lilypond was around 100k lines of code (a quick
> look says it 200k now; I suspect the GNU headers as a cause). 390 man
> years looks exaggeratedl, since I wrote most of it (at least before
> 2007), and it took me much less than 300 years.

Your output is likely not average for the industry.  Writing and
committing a half-hour change took you just half an hour instead of five
hours of red tape from you and three hours of red tape each from three
other persons.  We are getting there, but that's not what you have been
working with.

-- 
David Kastrup

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

Re: The value of LilyPond, according to Ohloh

2011-11-07 Thread Han-Wen Nienhuys

On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup  wrote:
>> I think the number is way off.  AFAICS at
>> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all
>> stable branches as separate.
>>
>> Last time I looked lilypond was around 100k lines of code (a quick
>> look says it 200k now; I suspect the GNU headers as a cause). 390 man
>> years looks exaggeratedl, since I wrote most of it (at least before
>> 2007), and it took me much less than 300 years.
>
> Your output is likely not average for the industry.  Writing and
> committing a half-hour change took you just half an hour instead of five
> hours of red tape from you and three hours of red tape each from three
> other persons.  We are getting there, but that's not what you have been
> working with.

In the early days (the "good old days") we didn't have a regression
test (I checked in the first version in may 2006). Beyond all kinds of
interesting stuff, I also committed several half hour changes that had
me staring at gdb for hours (and sometimes days) on end. They were
partly to blame on the nightly sessions with Jan that involved
drinking whiskey besides hacking, put some of them were really hard,
and I today I wonder how I ever kept things running without having any
sort of testing framework.

Let's not forget that some of the red tape we have today is there for
good reason.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: The value of LilyPond, according to Ohloh

Han-Wen Nienhuys  writes:

> On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup  wrote:
>>> I think the number is way off.  AFAICS at
>>> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all
>>> stable branches as separate.
>>>
>>> Last time I looked lilypond was around 100k lines of code (a quick
>>> look says it 200k now; I suspect the GNU headers as a cause). 390 man
>>> years looks exaggeratedl, since I wrote most of it (at least before
>>> 2007), and it took me much less than 300 years.
>>
>> Your output is likely not average for the industry.  Writing and
>> committing a half-hour change took you just half an hour instead of five
>> hours of red tape from you and three hours of red tape each from three
>> other persons.  We are getting there, but that's not what you have been
>> working with.
>
> Let's not forget that some of the red tape we have today is there for
> good reason.

There are always good reasons.  One reason is that single persons are
not a dependable resource.  As to "most of it": in the number of commits
(naturally misleading as changes tend to be larger in the starting
stage) it is about a third:

git shortlog -ns|awk '{n+=$1;if(NR<20)print};END{print n}'
  6381  Han-Wen Nienhuys
  3092  Graham Percival
  2474  Jan Nieuwenhuizen
  1270  John Mandereau
  1224  Francisco Vila
   910  Reinhold Kainhofer
   782  Joe Neeman
   574  Werner Lemberg
   526  Neil Puttock
   500  Trevor Daniels
   488  Carl D. Sorensen
   415  Heikki Junes
   409  Till Rettig
   379  Jean-Charles Malahieude
   352  Patrick McCarty
   286  Mats Bengtsson
   172  Valentin Villenave
   170  David Kastrup
   166  James Lowe
22101

I have to admit that I was surprised at the rather small contribution I
have made according to that metric.  Of course my own vanity wants to
ascribe some of that to red tape.

-- 
David Kastrup


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

Re: The value of LilyPond, according to Ohloh

Han-Wen Nienhuys  writes:

> On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup  wrote:
>>> I think the number is way off.  AFAICS at
>>> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all
>>> stable branches as separate.
>>>
>>> Last time I looked lilypond was around 100k lines of code (a quick
>>> look says it 200k now; I suspect the GNU headers as a cause). 390 man
>>> years looks exaggeratedl, since I wrote most of it (at least before
>>> 2007), and it took me much less than 300 years.
>>
>> Your output is likely not average for the industry.  Writing and
>> committing a half-hour change took you just half an hour instead of five
>> hours of red tape from you and three hours of red tape each from three
>> other persons.  We are getting there, but that's not what you have been
>> working with.
>
> In the early days (the "good old days") we didn't have a regression
> test (I checked in the first version in may 2006). Beyond all kinds of
> interesting stuff, I also committed several half hour changes that had
> me staring at gdb for hours (and sometimes days) on end.

I committed several changes recently that had me staring at bison output
tables for weeks.  Call me stupid, but argument scanning in the grammar
is specified from back to front while actually done front to back.
Which means that you need to invert time and causality when thinking
about the rules.  I think there was some jocular programming language
that had COMEFROM instead of GOTO.  Intercal or something?

Except that this is not a joke, and I don't think there is a better way.

-- 
David Kastrup

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

Let #{ ... #} pass its $ handling to environment cloning (issue 5340053)

2011-11-07 Thread dak


Reviewers: ,

Message:
I am replacing this review by a new one.

Description:
Let #{ ... #} pass its $ handling to environment cloning


Permit ly:parser-clone to receive an environment


lexer.ll: add $ for immediate export.

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

Affected files:
  M lily/include/lily-parser.hh
  M lily/lexer.ll
  M lily/lily-parser-scheme.cc
  M lily/lily-parser.cc
  M lily/parse-scm.cc
  M scm/parser-ly-from-scheme.scm



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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)


On Mon, 07 Nov 2011 11:36:09 -0800, m...@apollinemike.com 
 wrote:


On Nov 7, 2011, at 10:46 AM, Keith OHara wrote:


I had not realized that the results of the pure-from-neighbor system influence 
the page-spacing.


I misspoke - in this case, it does not.  But it does potentially add unwanted 
horizontal space.



\new GrandStaff <<
\new Staff \relative c {
   \override TextScript #'extra-spacing-width = ##f
   \repeat unfold 52 { dis4 dis dis dis^"foo bar" }
}
\new Staff \repeat unfold 52 R1 >>

Build this with the most current version of my patch and the text script won't 
elongate the measure (it did with older versions of my patch, but your comments 
made me realize a flaw in the way the interface worked, so thank you!).



Now, if someone overrides TextScript's 'extra-spacing-width like this, he 
probably /intends/ to change the horizontal spacing.  Do you plan to remove 
'extra-spacing-width in the near future?

The concept of what constitutes a "neighbor" is getting complicated.  
Horizontal spacing will change based on complicated details which will surprise me when I 
forget how it works (in about a week) :

\new GrandStaff <<
\new Staff \repeat unfold 5 R1
\new Staff {
   \override TextScript #'extra-spacing-width = ##f
   dis4 dis dis dis^"sliding-over" |
   dis4 dis dis dis^"sliding-over-not" |
   R1*2 f''1 } >>


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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)


Mike,
  Now that we understand that we can adjust 'extra-spacing-height
for note-spacing, without messing up line-breaking or page-spacing,
let's revisit the big picture.

On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com 
 wrote:


On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:


What is the overall plan for the new engravers?


Currently, LilyPond has no mechanism to calculate the Y-extents of Itemsin a relative 
way.  You can't say "make the height of grob X such thatit is always Y larger than 
that of grob Z."


So far, so good.


This is necessary for grobs (like barlines) that need to block certain grobs
that fall above and below them.   Idem for Staves, idem for time 
signatures.Currently, LilyPond accomplishes this through hardcoded values 
(check out
the extra-spacing-height for TimeSignature, for example), which potentially
catches unwanted fuzz (a text script with '(0 . 0) for  extra-spacing-width
and low padding will be shifted over numerical time signatures but notcommon 
time).


Well, it depends on /why/ we need the blocking.
If the goal is to avoid collisions, we use the extents plus extra-spacing-*
For horizontal spacing based on the meaning of the grobs, we have the 
'space-alist.
Grobs that need prominence relative to their non-colliding neighbors can benefit
 from your pure-from-neighbor-interface.

Span Bars need space to avoid collisions.

Separating SpanBars into segments, as you did for issue 910, seems wise because
in the case of issue 910 they can print as segments.
Using the "as tall as my neighbor" concept for SpanBarStubs, seems unwise.

\new PianoStaff <<
   \new Staff { R1*5 }
   \new Staff {
 e'1 |
 b'16 4.. r2 |
 e''16 4.. r2 |
 2 r2 |
 2 r2
   } >>



In general, I'd like to see the Pure_from_neighbor_engraver take care of 
theextra spacing heights for all grobs that are ordered by break alignments, 
asall of them should prevent overhang.  This patch already does a good chunk of
work for that.


But that is issue 1955.<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

2011-11-07 Thread m...@apollinemike.com

On Nov 7, 2011, at 8:19 PM, Keith OHara wrote:

> Mike,
> Now that we understand that we can adjust 'extra-spacing-height
> for note-spacing, without messing up line-breaking or page-spacing,
> let's revisit the big picture.
> 
> On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com 
>  wrote:
> 
>> On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
>> 
>>> What is the overall plan for the new engravers?
>>> 
>> Currently, LilyPond has no mechanism to calculate the Y-extents of Itemsin a 
>> relative way.  You can't say "make the height of grob X such thatit is 
>> always Y larger than that of grob Z."
> 
> So far, so good.
> 
>> This is necessary for grobs (like barlines) that need to block certain grobs
>> that fall above and below them.   Idem for Staves, idem for time 
>> signatures.Currently, LilyPond accomplishes this through hardcoded values 
>> (check out
>> the extra-spacing-height for TimeSignature, for example), which potentially
>> catches unwanted fuzz (a text script with '(0 . 0) for  extra-spacing-width
>> and low padding will be shifted over numerical time signatures but notcommon 
>> time).
> 
> Well, it depends on /why/ we need the blocking.
> If the goal is to avoid collisions, we use the extents plus extra-spacing-*
> For horizontal spacing based on the meaning of the grobs, we have the 
> 'space-alist.
> Grobs that need prominence relative to their non-colliding neighbors can 
> benefit
> from your pure-from-neighbor-interface.
> 
> Span Bars need space to avoid collisions.
> 
> Separating SpanBars into segments, as you did for issue 910, seems wise 
> because
> in the case of issue 910 they can print as segments.
> 

I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub 
stuff and just create several SpanBars instead of one SpanBar with gaps in its 
stencil.  I can reuse code I've already written, so it's not that bad.  But, my 
question is: was it ever a good idea to have the pure heights of span bars 
calculated the way they were?  SpanBars are inherently cross staff, so how can 
they estimate a correct Y-extent without triggering a VerticalAlignment?

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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)