Re: preliminary GLISS discussions

[Jan Nieuwenhuizen]

David Kastrup writes:

> Using LilyPond for reading LilyPond files (as opposed to parsers written
> in Python) has the advantage of being rather thorough, and the
> disadvantage to be tied into a single version (not all that helpful if
> you want to write something like convert-ly).

Maybe the time has finally come to drop convert-ly and implement and
fully supported conversions using LilyPond on music stream level.

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: preliminary GLISS discussions

[Jan Nieuwenhuizen]

Han-Wen Nienhuys writes:

> I have become convinced that optional, unnamed arguments are not a
> happy design decision, in any language. In Lily it's particularly
> problematic, since we don't group function parameters.

If we start doing this, that would solve the several of the issues
raised.  It would move a bit away from the `lets remove all red tape'
path that we (I?) embarked on previously.

There are two commonly used ways of grouping function parameters,
instead of

\relative { a \parenthesize b c }

we could have something* like

(relative { a (parenthesize b) c })
relative ({a parenthesize (b) c})

I don't think there are easy ways to combine or drop ( and }, ie have
something like

   {relative a b c}
   foo = relative
   {foo a b c}

Or the C-style equivalents.

Jan

 () will probably not work of course because they're slur events

-- 
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: slides-in-tablature.ly snippets: string numbers of hided notes arevisible

[Phil Holmes]

- Original Message - 
From: "Federico Bruni" 

To: "Lily-Devel List" 
Sent: Saturday, September 01, 2012 4:40 PM
Subject: slides-in-tablature.ly snippets: string numbers of hided notes 
arevisible




I've just realized that in this snippet the hidden notes, used to make
the grace slides, have a string number which is printed (and it 
shouldn't).

I think that we should just remove /3 from the notes in the grace blocks
(see file attached).

All the examples in the doc using Staff + TabStaff show the string
numbers. I don't know if it's desirable, but removing all the string
numbers in this example putting this in a \layout block wouldn't be
consistent with the rest of the doc:

\context {
  \Staff
  \override StringNumber #'stencil = ##f
}

Can a LSR editor fix it?
Thanks
--
Federico



Well - I've done that, but it appears that the snippet actually only works 
properly on 2.16.  Using the LSR and on my own machine with 2.14 I get no 
numerals over the normal staff, and little zeros on the tabstaff.  If you 
know how to fix that, please let me know.


--
Phil Holmes 



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

Re: slides-in-tablature.ly snippets: string numbers of hided notes arevisible

[Federico Bruni]

Il 02/09/2012 12:13, Phil Holmes ha scritto:

Well - I've done that, but it appears that the snippet actually only
works properly on 2.16.  Using the LSR and on my own machine with 2.14 I
get no numerals over the normal staff, and little zeros on the
tabstaff.  If you know how to fix that, please let me know.


Yes, it works properly only in 2.16.

Little zeros on tabstaff is because \hideNote didn't include 
TabNoteHead, see issue 2480 (fixed 2.15.38).

The strange signs on tabstaff (in 2.14.2) are related to issue 1459.

About no numerals over normal staff in 2.14.2, see previous messages 
from Patrick and David.


In 2.14.2 I used the following snippet to get this kind of grace slides:
http://lsr.dsi.unimi.it/LSR/Snippet?id=633

I think it can be removed once LSR upgrades to 2.16.
Or maybe you can leave it but you'd better add a comment saying that 
it's just an hack for versions below 2.16


Thanks
--
Federico

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

Hard-coded version numbers updated (issue 6492072)

[PhilEHolmes]

Reviewers: Graham Percival,

Description:
I've checked Google and it is now indexing the 2.17 pages and returning
hundreds of results - so we should update the search boxes.  There's no
issue tracker for this because my finger slipped when entering my google
credentials.

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

Affected files:
  M Documentation/de/search-box.ihtml
  M Documentation/es/search-box.ihtml
  M Documentation/fr/search-box.ihtml
  M Documentation/hu/search-box.ihtml
  M Documentation/it/search-box.ihtml
  M Documentation/nl/search-box.ihtml
  M Documentation/search-box.ihtml
  M Documentation/zh/search-box.ihtml
  M scripts/build/website_post.py


Index: Documentation/de/search-box.ihtml
diff --git a/Documentation/de/search-box.ihtml  
b/Documentation/de/search-box.ihtml
index  
1322170b71d91fe67a717dadead3391a638c9f8f..452f275938a829b2fc40a61dd604410c00f5e628  
100644

--- a/Documentation/de/search-box.ihtml
+++ b/Documentation/de/search-box.ihtml
@@ -16,11 +16,11 @@ search for a while and have a redirection from "v2.15"  
to "v2.17".

 http://google.com/search";
   method="get"
   name="search"
-  onSubmit="search.q.value='site:lilypond.org/doc/v2.15 '
+  onSubmit="search.q.value='site:lilypond.org/doc/v2.17 '
+ search.brute_query.value"
-  onMouseMove="search.q.value='site:lilypond.org/doc/v2.15 '
+  onMouseMove="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value"
-  onKeyUp="search.q.value='site:lilypond.org/doc/v2.15 '
+  onKeyUp="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value">
   
   value="Suche">

Index: Documentation/es/search-box.ihtml
diff --git a/Documentation/es/search-box.ihtml  
b/Documentation/es/search-box.ihtml
index  
43ac87b84cebabdcfc3261fd73e5991b2d0eb96f..56fb87f9457b5e96038d06ff1c15df2959fdfda7  
100644

--- a/Documentation/es/search-box.ihtml
+++ b/Documentation/es/search-box.ihtml
@@ -14,11 +14,11 @@ search for a while and have a redirection from "v2.15"  
to "v2.17".

 http://google.com/search";
   method="get"
   name="search"
-  onSubmit="search.q.value='site:lilypond.org/doc/v2.15 '
+  onSubmit="search.q.value='site:lilypond.org/doc/v2.17 '
+ search.brute_query.value"
-  onMouseMove="search.q.value='site:lilypond.org/doc/v2.15 '
+  onMouseMove="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value"
-  onKeyUp="search.q.value='site:lilypond.org/doc/v2.15 '
+  onKeyUp="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value">
   
   value="Buscar">

Index: Documentation/fr/search-box.ihtml
diff --git a/Documentation/fr/search-box.ihtml  
b/Documentation/fr/search-box.ihtml
index  
0017b60ffc90c07846dd352c27feb630e79965fe..8a667800599398ca64b1b9e08d41f046ab83d999  
100644

--- a/Documentation/fr/search-box.ihtml
+++ b/Documentation/fr/search-box.ihtml
@@ -16,11 +16,11 @@ search for a while and have a redirection from "v2.15"  
to "v2.17".

 http://google.com/search";
   method="get"
   name="search"
-  onSubmit="search.q.value='site:lilypond.org/doc/v2.15 '
+  onSubmit="search.q.value='site:lilypond.org/doc/v2.17 '
+ search.brute_query.value"
-  onMouseMove="search.q.value='site:lilypond.org/doc/v2.15 '
+  onMouseMove="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value"
-  onKeyUp="search.q.value='site:lilypond.org/doc/v2.15 '
+  onKeyUp="search.q.value='site:lilypond.org/doc/v2.17 '
   + search.brute_query.value">
   
   value="Rechercher">

Index: Documentation/hu/search-box.ihtml
diff --git a/Documentation/hu/search-box.ihtml  
b/Documentation/hu/search-box.ihtml
index  
fb526ad72c6dc41455b47cc8272cac69c94beaa2..6dc413f820c2a06d230636c9fbab2f5fea990b31  
100644

--- a/Documentation/hu/search-box.ihtml
+++ b/Documentation/hu/search-box.ihtml
@@ -1,11 +1,11 @@
 http://google.com/search";
   method="get"
   name="search"
-  onSubmit="search.q.value='site:lilypond.org +v2.12 '
+  onSubmit="search.q.value='site:lilypond.org +v2.17 '
+ search.brute_query.value"
-  onMouseMove="search.q.value='site:lilypond.org +v2.12 '
+  onMouseMove="search.q.value='site:lilypond.org +v2.17 '
   + search.brute_query.value"
-  onKeyUp="search.q.value='site:lilypond.org +v2.12 '
+  onKeyUp="search.q.value='site:lilypond.org +v2.17 '
   + search.brute_query.value">
   
   value="Keresés">

Index: Documentation/it/search-box.ihtml
diff --git a/Documentation/it/search-box.ihtml  
b/Documentation/it/search-box.ihtml
index  
cc7ddf3824c53d0369c0d835cb596d396ade1909..a393fd89443d962d37da02916ec07702b50c5294  
100644

--- a/Documentation/it/search-box.ihtml
+++ b/Documentation/it/search-box.ihtml
@@ -15,11 +15,11 @@ search for a while and have a redirection

Re: preliminary GLISS discussions

[David Kastrup]

Jan Nieuwenhuizen  writes:

> Han-Wen Nienhuys writes:
>
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group function parameters.
>
> If we start doing this, that would solve the several of the issues
> raised.

What issues were raised?

> It would move a bit away from the `lets remove all red tape' path that
> we (I?) embarked on previously.
>
> There are two commonly used ways of grouping function parameters,
> instead of
>
> \relative { a \parenthesize b c }
>
> we could have something* like
>
> (relative { a (parenthesize b) c })
> relative ({a parenthesize (b) c})
>
> I don't think there are easy ways to combine or drop ( and }, ie have
> something like
>
>{relative a b c}
>foo = relative
>{foo a b c}
>
> Or the C-style equivalents.

Who do we think to be doing a favor with that?

-- 
David Kastrup

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

Re: preliminary GLISS discussions

[David Kastrup]

Jan Nieuwenhuizen  writes:

> David Kastrup writes:
>
>> Using LilyPond for reading LilyPond files (as opposed to parsers written
>> in Python) has the advantage of being rather thorough, and the
>> disadvantage to be tied into a single version (not all that helpful if
>> you want to write something like convert-ly).
>
> Maybe the time has finally come to drop convert-ly and implement and
> fully supported conversions using LilyPond on music stream level.

You still need a parser of the appropriate version at the front end.

-- 
David Kastrup


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

Re: preliminary GLISS discussions

[Jan Nieuwenhuizen]

David Kastrup writes:

> What issues were raised?

Janek and Graham raised the `what is a music function / let's make
everything postfix' issue.  Han-Wen raised the issue of [nameless]
optional arguments.

>> instead of
>>
>> \relative { a \parenthesize b c }
>>
>> we could have something* like
>>
>> (relative { a (parenthesize b) c })
>> relative ({a parenthesize (b) c})
>>
>> I don't think there are easy ways to combine or drop ( and }, ie have
>> something like
>>
>>{relative a b c}
>>foo = relative
>>{foo a b c}
>>
>> Or the C-style equivalents.
>
> Who do we think to be doing a favor with that?

Well, that's the question.  This is also a good chance to, ahum,
once and for all decide on leaving things as they are.

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: preliminary GLISS discussions

[Jan Nieuwenhuizen]

David Kastrup writes:

>> Maybe the time has finally come to drop convert-ly and implement and
>> fully supported conversions using LilyPond on music stream level.
>
> You still need a parser of the appropriate version at the front end.

We have perfectly fine ly parsers of each available version available in
executable form from lilypond.org.  What we do not yet have, is a handy
or integrated way of dumping the music tree with the original binary
[read: a nice web service -- this could possibly be integrated with a
mutopia revival, I'll be looking into this] reading the music tree with
the current version and a perfect ly-dump function.  Eg, I think we may
want to preserve %-comments in the music tree, or other stuff the user
does not want to lose?

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

Allow digits in identifiers (issue 6493072)

[dak]

All in all, a large step backwards for making the lexer behave
predictably across modes regarding word and command syntax, connected
with several timing problems when parsing.

It looks like some _severe_ doctoring around with regard to notenames
was done to make regtests pass without an actual understanding of the
failure modes, introducing some half-baked in-between modes that don't
have a purpose apart from papering over the fact that this patch causes
the lexer to be in the wrong mode due to parser lookahead at several
points of time.

Regtests that showed themselves to be impervious to this papering over
got some gratuitous braces added until passing.

This is more a demonstration how to game our automated patch submission
and regtest evaluation system than a serious proposal.


http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly
File input/regression/page-spacing-nonstaff-lines-independent.ly (left):

http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly#oldcode11
input/regression/page-spacing-nonstaff-lines-independent.ly:11:
\addlyrics { high \skip2 }
Clear case of "existing use".  In previous syntax discussions, there was
some agreement on formatting durations to follow directly their note,
like c4.  \skip2 would be consistent with that.  It is also not clear
why c5 should not be a valid identifier when ce5 is.

http://codereview.appspot.com/6493072/diff/14/input/regression/phrasing-slur-multiple.ly
File input/regression/phrasing-slur-multiple.ly (left):

http://codereview.appspot.com/6493072/diff/14/input/regression/phrasing-slur-multiple.ly#oldcode21
input/regression/phrasing-slur-multiple.ly:21: c4\(\(\sp1\( d4\)\(\sp1\(
e4\) f\) |
This particular way of calling things is probably not important enough
to preserve, but \sp1 is basically a modifier on the following \( and
the spacier formatting proposed in the change does not have quite the
same expressive power.

http://codereview.appspot.com/6493072/diff/14/input/regression/ragged-bottom-one-page.ly
File input/regression/ragged-bottom-one-page.ly (right):

http://codereview.appspot.com/6493072/diff/14/input/regression/ragged-bottom-one-page.ly#newcode13
input/regression/ragged-bottom-one-page.ly:13: \repeat unfold 16 { c'4 }
Why are the braces needed here?

http://codereview.appspot.com/6493072/diff/14/input/regression/skiptypesetting-show-first-and-last.ly
File input/regression/skiptypesetting-show-first-and-last.ly (right):

http://codereview.appspot.com/6493072/diff/14/input/regression/skiptypesetting-show-first-and-last.ly#newcode11
input/regression/skiptypesetting-show-first-and-last.ly:11:
showLastLength = { R1*2 }
And here?

http://codereview.appspot.com/6493072/diff/14/lily/include/lily-lexer.hh
File lily/include/lily-lexer.hh (right):

http://codereview.appspot.com/6493072/diff/14/lily/include/lily-lexer.hh#newcode101
lily/include/lily-lexer.hh:101: void push_maybe_note_state ();
Uh oh...  "maybe_note_state" sounds like a real can of worms.

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll
File lily/lexer.ll (left):

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#oldcode397
lily/lexer.ll:397: {RESTNAME}/[-_]  |  // pseudo
backup rule
Did you check that r-. does still work as intended when removing this
rule?

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode34
lily/lexer.ll:34: flex -b 
Did you do this?

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode476
lily/lexer.ll:476: {A}+ {
So words no longer correspond to commands regarding their syntax in note
mode?  Doesn't that mean that things like
\layout { \tempo "Allegro" some-variable = 17 }
stop working again?

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode859
lily/lexer.ll:859: push_note_state (nn);
What is this supposed to do?  INITIAL state is not supposed to have
pitchnames defined.

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy#newcode1190
lily/parser.yy:1190: '{' { parser->lexer_->push_maybe_note_state (); }
music_list '}'
Pushing a separate "maybe_note_ state for _every_ braced music list?
Seriously?

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy#newcode1834
lily/parser.yy:1834: } function_arglist {
This spells the death knell for having functions decide on their
syntactic role based on their _return_ value when every music function
needs to get parsed in a special state.

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy#newcode1837
lily/parser.yy:1837: parser->lexer_->pop_state ();
You are aware that in general a music function call boundary will be
determined by looking at a lookahead token?  That means that the
lookahead token will, in general, have been parsed in the wron

Re: preliminary GLISS discussions

[David Kastrup]

Jan Nieuwenhuizen  writes:

> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front end.
>
> We have perfectly fine ly parsers of each available version available in
> executable form from lilypond.org.  What we do not yet have, is a handy
> or integrated way of dumping the music tree with the original binary
> [read: a nice web service -- this could possibly be integrated with a
> mutopia revival, I'll be looking into this] reading the music tree with
> the current version and a perfect ly-dump function.  Eg, I think we may
> want to preserve %-comments in the music tree, or other stuff the user
> does not want to lose?

For an emergency conversion web service of an archive in case of
convert-ly failure, a Scheme-written package diverting all required
hooks like toplevel-book-handler, toplevel-bookpart-handler,
toplevel-score-handler, toplevel-music-handler, toplevel-text-handler
could likely be written.  The meaning of spacing variables would need
conversion, some overrides likely as well, context definitions and stuff
would be a bit tricky to properly detect (but one could just start out
with empty context/output defs and consider every change as relevant),
but as an emergency measure, I consider the likelihood of getting at
least something useful out for a majority of scores when run on the
respective original version of LilyPond reasonably high.

It would work at the music expression level, not at the stream event
level: the latter has already lost too much information.

All the input syntax/music function folderol would not be an issue since
those have already done their work at the time of calling the handlers.

Markup functions might be more tricky.

-- 
David Kastrup

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

Re: preliminary GLISS discussions

[David Kastrup]

Jan Nieuwenhuizen  writes:

> David Kastrup writes:
>
>> What issues were raised?
>
> Janek and Graham raised the `what is a music function / let's make
> everything postfix' issue.

That's rather vague as an issue description.  Sort of the "What is a
preposition / let's make everything a case" issue converting modern
English into Protoindoeuropean.  The answer "try learning your grammar
before replacing it by something even more complex" is sort of
inevitable.

> Han-Wen raised the issue of [nameless] optional arguments.
>
>>> instead of
>>>
>>> \relative { a \parenthesize b c }
>>>
>>> we could have something* like
>>>
>>> (relative { a (parenthesize b) c })
>>> relative ({a parenthesize (b) c})
>>>
>>> I don't think there are easy ways to combine or drop ( and }, ie have
>>> something like
>>>
>>>{relative a b c}
>>>foo = relative
>>>{foo a b c}
>>>
>>> Or the C-style equivalents.
>>
>> Who do we think to be doing a favor with that?
>
> Well, that's the question.  This is also a good chance to, ahum,
> once and for all decide on leaving things as they are.

I repeat myself: as long as "as they are" is not obeying a documented
and coherent definition, that's rather pointless as well.

The conservative approach is rather moving towards a consistent state
from the current starting point in the least damaging manner.

-- 
David Kastrup


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

Removes echoed information from make doc (issue 6496074)

[PhilEHolmes]

Reviewers: John Mandereau,

Message:
Please check.

Description:
I've tested this with a full make, make doc, make test and diffed the
files created with make doc - all is exactly the same.  Think this
should be good to go, but just want confirmation.

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

Affected files:
  M Documentation/GNUmakefile


Index: Documentation/GNUmakefile
diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile
index  
aafcb0bc65455f61c1e9be7135a25de85c35c8d0..a3ef4bb6e7c6640249ed9244139374a09a5a2de1  
100644

--- a/Documentation/GNUmakefile
+++ b/Documentation/GNUmakefile
@@ -167,8 +167,6 @@ extra-local-help:
@echo

 info: $(INFO_FILES)
-   @echo export LILYPOND_DATADIR=$(LILYPOND_DATADIR)
-   @echo export PYTHONPATH=$(PYTHONPATH)

 xml: $(outdir)/notation/notation.xml $(outdir)/internals/internals.xml




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

Trying to work out at what point patchy fails during make test

[James]

John,

I'm still finding my way round the new layout/organization of where
Patchy puts the output and test results, however it is not clear
sometimes what is failing, while I can just run reject patchy and say
'where' in the cycle it fails (make, make test etc.). It does help the
devs if I can be a bit more specific.

So in today's case:

I run ./test-patchy.py as normal..

--snip--
..
Trying issue 2801
Found patch: 
2801,/home/jlowe/lilypond-extra/patches/issue6498077_5001.diff,Patch:
Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines.
Fetching, cloning, compiling master.
(UTC) Begin LilyPond compile, previous commit at
6ce800445921f6f32eeb60bfbf7acf1cdba2f9c1
Success: No new commits in master
Git revision has not changed but checksum of test baseline has, must rebuild.
Success: ./autogen.sh --noconfigure
Success: /tmp/lilypond-autobuild/configure --disable-optimising
Success:nice make clean
Success:nice make -j7 CPU_COUNT=7
Success:nice make test-baseline -j7 CPU_COUNT=7
Issue 2801: Patch: Approximates cross-staff slurs in VerticalAxisGroup
vertical-skylines.
Issue 2801: Testing patch issue6498077_5001_diff
Success:git apply --index
/home/jlowe/lilypond-extra/patches/issue6498077_5001.diff
Success:./autogen.sh --noconfigure
Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
Success:nice make clean
Success:nice make -j7 CPU_COUNT=7
*** FAILED BUILD ***
nice make check -j7 CPU_COUNT=7
Previous good commit:   6ce800445921f6f32eeb60bfbf7acf1cdba2f9c1
Current broken commit:  6ce800445921f6f32eeb60bfbf7acf1cdba2f9c1
Error: issue 2801: Problem encountered
Traceback (most recent call last):
  File "/home/jlowe/lilypond-extra/patches/projecthosting_patches.py",
line 275, in do_check
results_url = autoCompile.test_issue (issue_id, patch)
  File "/home/jlowe/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 273, in test_issue
self.build (patch_test=True, issue_id=issue_id)
  File "/home/jlowe/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 315, in build
issue_id)
  File "/home/jlowe/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
(command, this_logfilename))
FailedCommand: Failed runner: nice make check -j7 CPU_COUNT=7
See the log file log-2801-nice-make-check--j7-CPU_COUNT=7.txt

Issue 2801: Cleaning up
Success:nice make test-clean
Success:nice make clean
Issue 2801: Done.
--snip--

So I locate 'log-2801-nice-make-check--j7-CPU_COUNT=7.txt' in
/tmp/lilypond-log/.. and get

--snip--
more log-2801-nice-make-check--j7-CPU_COUNT\=7.txt
For tracking crashes: use
grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed s
/log/ly/g`

make --no-builtin-rules -C input/regression out=test local-test
make[1]: Entering directory `/tmp/build-lilypond-autobuild/input/regression'
mkdir -p ./out-test
touch ./out-test/dummy.dep
echo '*' > ./out-test/.gitignore
... [lots of logs]

etc.

... [lots of logs]

"/tmp/build-lilypond-autobuild/
out/lybook-testdb/snippet-names-892580628.ly"
Child returned 1
Error ignored by lilylib
Error trapped by lilypond-book

Please see /tmp/build-lilypond-autobuild/out/lybook-testdb/snippet-names-8925806
28.log

... etc.

... [end of log]

--snip--

Now if I look for
'/tmp/build-lilypond-autobuild/out/lybook-testdb/snippet-names-8925806
28.log' it doesn't exist or rather because there is a make clean the
dir '/tmp/build-lilypond-autobuild/out/..' doesn't exist.

However there is one in

/tmp/show-2801

--snip--

jlowe@jlowe26vm /tmp/lilypond-log$ more
/tmp/show-2801/out/lybook-testdb/snippet-names-892580628.log
GNU LilyPond 2.17.2

Forking into jobs:  (30244 30243 30242 30241 30240 30239 30238)


job 5 terminated with signal: 6
fatal error: Children (5) exited with errors.
jlowe@jlowe26vm /tmp/lilypond-log$

--snip--

ok so far so good. Doesn't give me much but onwards and upwards.

If I look in the *.ly file corresponding to the log I get this:

--snip--
jlowe@jlowe26vm /tmp/show-2801/out$ more
/tmp/show-2801/out/lybook-testdb/snippet-names-892580628.ly

snippet-map-892580628.ly
84/lily-0f7c4871.ly
aa/lily-4858d0b7.ly
0f/lily-cdc1d94e.ly
8b/lily-ee7f7e54.ly
53/lily-64dfb2d0.ly
b2/lily-1922a761.ly
de/lily-4483657e.ly
3c/lily-14a6ed53.ly
ae/lily-838f2675.ly

... [lots more lines like this]

b0/lily-7821c23e.ly
68/lily-12d29b6a.ly
dc/lily-5d81e32b.ly
8a/lily-3250e012.ly
jlowe@jlowe26vm /tmp/show-2801/out$

--snip--

Now I can find all of those *.ly files but which one can I assume is
the problematic one of this list? The first one or the second one or
could it be any in between. That is does the list get appended to
before each test?

Th

Re: Trying to work out at what point patchy fails during make test

[Phil Holmes]

- Original Message - 
From: "James" 

To: "John Mandereau" 
Cc: "Devel" 
Sent: Sunday, September 02, 2012 3:31 PM
Subject: Trying to work out at what point patchy fails during make test



John,

I'm still finding my way round the new layout/organization of where
Patchy puts the output and test results, however it is not clear
sometimes what is failing, while I can just run reject patchy and say
'where' in the cycle it fails (make, make test etc.). It does help the
devs if I can be a bit more specific.


[snip]

When lilypond forks a number of jobs, it puts the output into some logfiles 
something like multirun-0.log.  If you cab find those, multirun-5 should 
help.


--
Phil Holmes 



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

Re: wrong beam positions in LilyPond

[Han-Wen Nienhuys]

On Sun, Sep 2, 2012 at 5:04 AM, Jan Nieuwenhuizen  wrote:
> Janek Warchoł writes:
>
>> thanks!  Is there any explanation to these numbers other than digging
>> it myself from beam-quanting.cc?  I've skimmed over it, but didn't
>> find it immediately helpful.
>
> I've compiled with -DDEBUG_BEAM_SCORING=1
this is the default already; see include/main.hh

-- 
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: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[dak]

http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode390
lily/axis-group-interface.cc:390: /*
Where is the point in putting a whole callback inside of a comment?  Is
this a TODO "make callback work again"?  Or what?  Of course, using /*
*/ for outcommenting the whole callback relies on no single comment ever
appearing inside of the whole function since comments don't nest.

I have no doubt that this is the predominant coding style in LilyPond,
and a syntax error is a small punishment for violating this convention,
but the usual (and nestable) way of outcommenting a part of source is to
use #if 0.  As well as an explanatory comment just _why_ things are
outcommented instead of removed.

http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode419
lily/axis-group-interface.cc:419: */
See above.

http://codereview.appspot.com/6498077/diff/21/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/page-layout-problem.cc#newcode1004
lily/page-layout-problem.cc:1004: if (is_spaceable (staves[i]))
This indentation is simply wrong and does not match the program
structure.

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc
File lily/phrasing-slur-engraver.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode119
lily/phrasing-slur-engraver.cc:119: if (slur_stubs_.find (slurs_[j]) ==
slur_stubs_.end ())
It is quite nonsensical to have slur_stubs be a map indexed via
slurs_[j] rather than just an array indexed through j.

That is inefficient use of time, memory, and complexity.

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode332
lily/phrasing-slur-engraver.cc:332: map vag_to_slur;
Again: why a map here?

http://codereview.appspot.com/6498077/diff/21/lily/script-column.cc
File lily/script-column.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/script-column.cc#newcode49
lily/script-column.cc:49: ? 1
? 1 : 0 is totally unnecessary since || already returns 1 or 0.

http://codereview.appspot.com/6498077/diff/21/lily/script-column.cc#newcode60
lily/script-column.cc:60: if (unsmob_grob (i1->get_object ("slur")) &&
unsmob_grob (i2->get_object ("slur")))
If both scripts have a field "slur" that is a grob, return #t is the
avoid-slur property of the second script is "outside" or "around" while
that of the first is neither.

Why don't you write this in a comment?  Why this complex code?  And what
is the ultimate purpose?

http://codereview.appspot.com/6498077/diff/21/lily/slur-engraver.cc
File lily/slur-engraver.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/slur-engraver.cc#newcode56
lily/slur-engraver.cc:56: map > slur_stubs_;
see comments in phrasing slur engraver.

http://codereview.appspot.com/6498077/diff/21/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/slur.cc#newcode623
lily/slur.cc:623: "thickness "
No entry for "surrogate"?

http://codereview.appspot.com/6498077/

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

Dynamics do not unnecessarily horizontal shift for stems. (issue 6493073)

[dak]

http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):

http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213
lily/self-alignment-interface.cc:213: vector_sort (vais, less ());
Seriously?  If dir is UP, you are interested in the minimum, and if it
is DOWN, you are interested in the maximum.  And you create a vector and
sort it for that?

Totally inefficient as well as incomprehensible.

http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode280
lily/self-alignment-interface.cc:280: "potential-X-colliding-grobs "
Does normal-stems need to be here?

http://codereview.appspot.com/6493073/

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

[GLISS] verbifying music functions

[Graham Percival]

On Sat, Sep 01, 2012 at 10:58:31PM +0200, Nicolas Sceaux wrote:
> Le 1 sept. 2012 à 18:25, Graham Percival a écrit :
> 
> > Continuing to brainstorm on the problem of it not being obvious to
> > which note a particular \command refers to, what if we used:
> 
> If a prefix music function is consistently named according to some rule
> (e.g. a verb, as was proposed), and variables to that other rule, then
> the reading problem is solved.
...
> That's not a syntax/parser issue, imho.

Sure; GLISS is about the language as a whole, not just the parser.
Let's have a look at verbifying music functions.


gperciva@kuro:~/src/lilypond (master)
$ grep "=$" ly/music-functions-init.ly | cut -d \  -f 1

I'll add suggested names for that list.  The As mostly look good.

acciaccatura  => \addAcciatura ?  not nice
addInstrumentDefinition
addQuote
afterGrace=> \addAfterGrace ?  not nice
allowPageTurn
alterBroken
appendToTag
applyContext
applyMusic
applyOutput
appoggiatura => \addAppoggiatura ?  not nice
assertBeamQuant
assertBeamSlope
autochange

% so far most of the music functions are already verbs, although
% I'm not wild about changing the remaining ones to be verbs.  So
% maybe it would be good to have a few exceptions to the "music
% functions are verbs" idea.

balloonGrobText   => \addBalloonGrobText
balloonText   => \addBalloonText
bar   => \addBar ; maybe special-case it?
barNumberCheck=> \addBarNumberCheck ; maybe special-case it?
bendAfter
bookOutputName% special-case to remain as-is?
bookOutputSuffix  % special-case to remain as-is?
breathe

% it's true that the word "balloon" can be a verb in English, but
% that's fairly rare usage, i.e. "his stomach ballooned after
% eating Thanksgiving dinner".  Similarly, "book him" can be a
% verb, but "book" is not used as a verb in this context.

clef
compoundMeter
crossStaff
cueClef
cueClefUnset
cueDuring
cueDuringWithClef

% as it happens, none of the Cs are verbs.  (again, words such as
% "cue" can be both a verb and a noun, but the thing that a
% conductor does is a verb-cue, whereas the thing in the score is
% a noun-cue.)   However, I think it would be really awkward to
% change to something like \addClef.


I won't go through the rest of the music functions right now, but
I think that the rule for naming music functions needs to be
complicated than previously thought.  A few alternate rules spring
to mind:
- if a music function affects a note, it always begins with \add,
  or ends with an \...After; if a music function does not affect a
  note (i.e. \clef) then it doesn't change.
- if it affects a note, the name begins with a capital letter,
  otherwise it doesn't.  (or vice-versa)
- if it affects a note, a - is appended to the name, i.e.
  \afterGrace-

As with previous brainstorming lists, I'm deliberately not
filtering out bad ideas.

- Graham

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

Re: preliminary GLISS discussions

[Graham Percival]

On Sun, Sep 02, 2012 at 12:58:47AM +0200, Janek Warchoł wrote:
> For what it's worth, i'm ok with this discussion (and similar ones)
> happening on devel, as long as we won't loose track of concrete
> proposals (when they will appear, ofc.).

I think the direction we're moving in is to have unstructured
discussions for a few days/weeks, then when there's an actual
concerete proposal, it goes lilypond-extra:gliss/gliss.texi.  I'll
schedule those similar to GOP proposals, i.e. at least two weeks
of discussions after we have a fixed proposal.

During the "unstructured discussion" portion, I'm not taking
responsibility for keeping track of ideas.  Unless there's a
volunteer for that, I suggest that whoever floats each idea keeps
track of how it progresses.

- Graham

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

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[mtsolo]

Thanks for the review!


http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode419
lily/axis-group-interface.cc:419: */
On 2012/09/02 15:59:00, dak wrote:

See above.


Removed - was old code I needed to read to make sure I waas getting
stuff right.  Forgot it waas there.

http://codereview.appspot.com/6498077/diff/21/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/page-layout-problem.cc#newcode1004
lily/page-layout-problem.cc:1004: if (is_spaceable (staves[i]))
On 2012/09/02 15:59:00, dak wrote:

This indentation is simply wrong and does not match the program

structure.

Cruft. Fixed.

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc
File lily/phrasing-slur-engraver.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode119
lily/phrasing-slur-engraver.cc:119: if (slur_stubs_.find (slurs_[j]) ==
slur_stubs_.end ())
On 2012/09/02 15:59:00, dak wrote:

It is quite nonsensical to have slur_stubs be a map indexed via

slurs_[j] rather

than just an array indexed through j.



That is inefficient use of time, memory, and complexity.


It is sensical because:
--) It avoids having two vectors (slur_stubs_ and end_slur_stubs_ would
be needed), thus making the code easier to read and maintain.
--) It has a "find" method built into it.

Unless people are crunching scores with thousands of slurs on Strong
Bad's original Tandy 400, I'm not too worried about the tradeoff.

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode332
lily/phrasing-slur-engraver.cc:332: map vag_to_slur;
On 2012/09/02 15:59:00, dak wrote:

Again: why a map here?


find method, see above.
I know that find exists for vectors in algorithm, but I think this is
easier to read and more consistent.

http://codereview.appspot.com/6498077/diff/21/lily/script-column.cc
File lily/script-column.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/script-column.cc#newcode60
lily/script-column.cc:60: if (unsmob_grob (i1->get_object ("slur")) &&
unsmob_grob (i2->get_object ("slur")))
On 2012/09/02 15:59:00, dak wrote:

If both scripts have a field "slur" that is a grob, return #t is the

avoid-slur

property of the second script is "outside" or "around" while that of

the first

is neither.



Why don't you write this in a comment?  Why this complex code?  And

what is the

ultimate purpose?


I didn't put it in a comment because it can be understood by reading it,
as you explain with your eloquent prose :-)

This exists to avoid the situation where a grob has a lower slur
priority than another but is typeset outside a slur whereas the other is
put inside, leading to a contradiction. Priority is given to the slur
directive.

http://codereview.appspot.com/6498077/diff/21/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/slur.cc#newcode623
lily/slur.cc:623: "thickness "
On 2012/09/02 15:59:00, dak wrote:

No entry for "surrogate"?


scm/define-grob-interfaces.scm

http://codereview.appspot.com/6498077/

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

Re: Dynamics do not unnecessarily horizontal shift for stems. (issue 6493073)

[mtsolo]

Reviewers: dak,

Message:
Thanks for the review!


http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):

http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213
lily/self-alignment-interface.cc:213: vector_sort (vais, less ());
On 2012/09/02 16:06:30, dak wrote:

Seriously?  If dir is UP, you are interested in the minimum, and if it

is DOWN,

you are interested in the maximum.  And you create a vector and sort

it for

that?



Totally inefficient as well as incomprehensible.


Good catch - changed to Interval_t

Description:
Dynamics do not unnecessarily horizontal shift for stems.

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

Affected files:
  A input/regression/dynamics-avoid-cross-staff-stem-2.ly
  M lily/self-alignment-interface.cc


Index: input/regression/dynamics-avoid-cross-staff-stem-2.ly
diff --git a/input/regression/dynamics-avoid-cross-staff-stem-2.ly  
b/input/regression/dynamics-avoid-cross-staff-stem-2.ly

new file mode 100644
index  
..e549646f75df457d18513c7b0bc5f9f24adcad1b

--- /dev/null
+++ b/input/regression/dynamics-avoid-cross-staff-stem-2.ly
@@ -0,0 +1,23 @@
+\version "2.17.2"
+
+\header {
+  texidoc = "Dynamics do not horizontally shift when attached to
+an axis-group extremal cross staff grob that's extremal side
+(UP or DOWN) is the same as its direction.
+"
+}
+
+\new PianoStaff <<
+  \new Staff = "up" {
+s1 |
+  }
+  \new Staff = "down" {
+\clef bass
+\stemDown
+% keep staff alive
+8 [ 8_\f
+\change Staff = "up"
+g' g' ]
+r2 |
+  }
+>>
Index: lily/self-alignment-interface.cc
diff --git a/lily/self-alignment-interface.cc  
b/lily/self-alignment-interface.cc
index  
a37b5871007eec8ef9368976958997b6a4c84a98..2a033340ff27c283350c43cb3fc7ffba7cedf2d6  
100644

--- a/lily/self-alignment-interface.cc
+++ b/lily/self-alignment-interface.cc
@@ -199,7 +199,24 @@ Self_alignment_interface::avoid_colliding_grobs (Grob  
*me, Axis a, Real offset)


   Interval iv = me->extent (me, a) + offset;
   for (vsize i = 0; i < colls.size (); i++)
-ivs.push_back (colls[i]->extent (refp, a));
+{
+  int my_vai = Grob::get_vertical_axis_group_index (colls[i]);
+  Direction dir = get_grob_direction (colls[i]);
+  // if coll is cross staff but extremal and poiting in the
+  // direction of the extrema, we don't take it into consideration
+  if (Grob *beam = unsmob_grob (colls[i]->get_object ("beam")))
+{
+  Interval_t vais;
+  extract_grob_set (beam, "normal-stems", stems);
+  for (vsize j = 0; j < stems.size (); j++)
+vais.add_point (Grob::get_vertical_axis_group_index  
(stems[j]));

+  // ugh...up and down are different for VerticalAxisGroup order...
+  if ((my_vai == vais[DOWN] && dir == UP)
+  || (my_vai == vais[UP] && dir == DOWN))
+continue;
+}
+  ivs.push_back (colls[i]->extent (refp, a));
+}

   Interval_minefield minefield (Interval (iv.center (), iv.center ()),  
iv.length ());

   for (vsize i = 0; i < ivs.size (); i++)



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

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[dak]

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc
File lily/phrasing-slur-engraver.cc (right):

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode119
lily/phrasing-slur-engraver.cc:119: if (slur_stubs_.find (slurs_[j]) ==
slur_stubs_.end ())
On 2012/09/02 16:45:14, MikeSol wrote:

On 2012/09/02 15:59:00, dak wrote:
> It is quite nonsensical to have slur_stubs be a map indexed via

slurs_[j]

rather
> than just an array indexed through j.
>
> That is inefficient use of time, memory, and complexity.



It is sensical because:
--) It avoids having two vectors (slur_stubs_ and end_slur_stubs_

would be

needed), thus making the code easier to read and maintain.
--) It has a "find" method built into it.


I don't see that a "find" method is advantageous over just indexing.
And typical scores _have_ thousands of slurs.

Since you don't bother writing even a single comment, it is rather hard
to figure out what you are doing, and you are doing it in complicated
way.

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode332
lily/phrasing-slur-engraver.cc:332: map vag_to_slur;
On 2012/09/02 16:45:14, MikeSol wrote:

On 2012/09/02 15:59:00, dak wrote:
> Again: why a map here?



find method, see above.
I know that find exists for vectors in algorithm, but I think this is

easier to

read and more consistent.


You are apparently going to a lot of effort of getting your map entries
out again when you could just keep arrays with an identical structure to
the slurs_ and end_slurs_ arrays.  Again, since you don't bother writing
any comment regarding what you are trying to do, it is hard to figure
out what the purpose is.

http://codereview.appspot.com/6498077/

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

Re: Allow digits in identifiers (issue 6493072)

[k-ohara5a5a]

Reviewers: dak,


http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly
File input/regression/page-spacing-nonstaff-lines-independent.ly (left):

http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly#oldcode11
input/regression/page-spacing-nonstaff-lines-independent.ly:11:
\addlyrics { high \skip2 }
On 2012/09/02 11:52:46, dak wrote:

It is also not clear why c5 should not be
a valid identifier when ce5 is.


Both /can/ be valid identifiers, if we want.
c4 = {...}   at top-level defines a variable, then inside any braces for
music-entry:
c4  is a quarter note on do.
\c4  references the variable.

More simple than today, when I may use 'recs' as an identifier name,
unless I speak Spanish.

http://codereview.appspot.com/6493072/diff/14/input/regression/ragged-bottom-one-page.ly
File input/regression/ragged-bottom-one-page.ly (right):

http://codereview.appspot.com/6493072/diff/14/input/regression/ragged-bottom-one-page.ly#newcode13
input/regression/ragged-bottom-one-page.ly:13: \repeat unfold 16 { c'4 }
On 2012/09/02 11:52:46, dak wrote:

Why are the braces needed here?


Maybe not strictly needed here, but showing the concept of always
putting music-with-durations inside at least one level of bracing.

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll
File lily/lexer.ll (left):

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#oldcode397
lily/lexer.ll:397: {RESTNAME}/[-_]  |  // pseudo
backup rule
On 2012/09/02 11:52:46, dak wrote:

Did you check that r-. does still work as intended when removing this

rule?

The syntax never allowed new identifier definitions in
sequential/simultaneous music.
 \relative c' { new-variable-name = { c d e f } } % never valid
So there lexer need not look ahead for un-escaped WORDs while scanning
note and rest entries.

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode34
lily/lexer.ll:34: flex -b 
On 2012/09/02 11:52:46, dak wrote:

Did you do this?


A long while ago; I haven't checked it lately,

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode476
lily/lexer.ll:476: {A}+ {
On 2012/09/02 11:52:46, dak wrote:

So words no longer correspond to commands regarding their syntax in

note mode?

COMMAND is still \WORD so they strictly correspond.

Only COMMAND is a token in note-mode, not WORD, because we are not
defining new identifiers here.

Previously, WORD was matching note-names, but that was wrong because in
{ c d e_sharp f } 'e_sharp' is a valid WORD, but not a valid note-name.

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#newcode859
lily/lexer.ll:859: push_note_state (nn);
On 2012/09/02 11:52:46, dak wrote:

What is this supposed to do?  INITIAL state is not supposed to have

pitchnames

defined.


To fully-bake this implementation, I would want INITIAL to have
pitchnames defined, so I can use INITIAL at top level to recognize the
pitch in  \relative do' {}.

Then entry into note-mode would not need to push onto
pitchname_tab_stack_

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/6493072/diff/14/lily/parser.yy#newcode1190
lily/parser.yy:1190: '{' { parser->lexer_->push_maybe_note_state (); }
music_list '}'
On 2012/09/02 11:52:46, dak wrote:

Pushing a separate "maybe_note_ state for _every_ braced music list?

Seriously?

For every nested level of braces.

Description:
Allow digits in identifiers

Set lexer state to INITIAL for top-level expressions,
 switching to 'notes' mode inside music-expressions

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

Affected files:
  A input/regression/identifiers-with-digits.ly
  M input/regression/page-spacing-nonstaff-lines-independent.ly
  M input/regression/phrasing-slur-multiple.ly
  M input/regression/ragged-bottom-one-page.ly
  M input/regression/skiptypesetting-show-first-and-last.ly
  M input/regression/skiptypesetting-show-first.ly
  M input/regression/skiptypesetting-show-last.ly
  M input/regression/slur-multiple.ly
  M lily/include/lily-lexer.hh
  M lily/lexer.ll
  M lily/lily-lexer.cc
  M lily/parser.yy
  M scripts/musicxml2ly.py



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

Re: Allow digits in identifiers (issue 6493072)

[k-ohara5a5a]

On 2012/09/02 11:52:46, dak wrote:


It looks like some _severe_ doctoring around with regard to notenames

was done

to make regtests pass without an actual understanding of the failure

modes,

introducing some half-baked in-between modes that don't have a purpose

apart

from papering over the fact that this patch causes the lexer to be in

the wrong

mode due to parser lookahead at several points of time.


My desire is for just one in-between mode, which I want for scanning
top-level. That desired mode is to have pitch-names loaded, but without
the scanner accepting music with durations. I want to talk about it
while it is un-baked.

The difficulty in putting the lexer in the correct mode, after music
functions with variable argument lists, is related to the mailing list
discussion on "GLISS".

This is the version that allows digits at the *end* of identifiers,
which might not be wise.  See the tracker

The regression test changes demonstrate its conflict with
possibly-useful syntax; I was surprised how few changes were needed.

I have been waiting with this for over a year, so of course I will not
try to push anything forward until this "GLISS" dicussion is done.


http://codereview.appspot.com/6493072/

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

Re: Removes echoed information from make doc (issue 6496074)

[benko . pal]

LGTM

http://codereview.appspot.com/6496074/

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

Re: Allow digits in identifiers (issue 6493072)

[dak]

All in all, this creates so many loose ends and problems of the kind I
have been working to get tied up that I can basically start from scratch
with lexer/parser work.  I am very strongly opposed to this, and it is
easy to come up with examples that fail for inexplicable reasons because
of the interaction of parser lookahead and lexer mode switching.

This is a large step towards making LilyPond behave unpredictable in a
number of corner cases as well as existing usage as witnessed by the
large number of regression tests needing modifications without a
documented or user-discernible reason.

Numbers in identifiers _will_ have drawbacks (clearly \skip4 is not
fitting well with various naming schemes allowing numbers in names).
But I think that the drawbacks of this patch are quite more than what
would be unavoidable.  It is a bad idea for more reasons than the
reasons making the general idea of numbers in words/commands a bad idea.


http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll
File lily/lexer.ll (left):

http://codereview.appspot.com/6493072/diff/14/lily/lexer.ll#oldcode397
lily/lexer.ll:397: {RESTNAME}/[-_]  |  // pseudo
backup rule
On 2012/09/02 17:59:53, Keith wrote:

On 2012/09/02 11:52:46, dak wrote:
> Did you check that r-. does still work as intended when removing

this rule?


The syntax never allowed new identifier definitions in

sequential/simultaneous

music.


That is not an answer to my question.


  \relative c' { new-variable-name = { c d e f } } % never valid


But \relative c' c new-variable-name = { c d e f }
has been valid and will no longer be because new is seen by the lexer
while still in music mode.

http://codereview.appspot.com/6493072/

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

Re: preliminary GLISS discussions

[Keith OHara]

Janek Warchoł  gmail.com> writes:

> On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup  gnu.org> wrote:
> > Graham Percival  percival-music.ca> writes:
> >> So far I don't feel that the discussion has been very fruitful.
> >
> > And it will not be fruitful in the near future.  One reason is that I am
> > basically the only one seriously working on the parser right now, and I
> > am learning while I am working on it, both about the work flow for
> > getting Bison where you want it, and about the complications.  This is
> > work that is really hard to do, but it can't be done except, basically,
> > incrementally.
> 
> For what it's worth, i'm ok with this discussion (and similar ones)
> happening on devel, as long as we won't loose track of concrete
> proposals (when they will appear, ofc.).
> 

I posted a patch for the numbers-in-identifiers enhancement


It might help a little as a concrete example, showing the challenges of 
supporting LilyPond's very lenient syntax.

(I can't really tell for sure, but I think maybe David likes the patch.)


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

Re: preliminary GLISS discussions

[David Kastrup]

Keith OHara  writes:

> Janek Warchoł  gmail.com> writes:
>
>> On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup  gnu.org> wrote:
>> > Graham Percival  percival-music.ca> writes:
>> >> So far I don't feel that the discussion has been very fruitful.
>> >
>> > And it will not be fruitful in the near future.  One reason is that I am
>> > basically the only one seriously working on the parser right now, and I
>> > am learning while I am working on it, both about the work flow for
>> > getting Bison where you want it, and about the complications.  This is
>> > work that is really hard to do, but it can't be done except, basically,
>> > incrementally.
>> 
>> For what it's worth, i'm ok with this discussion (and similar ones)
>> happening on devel, as long as we won't loose track of concrete
>> proposals (when they will appear, ofc.).
>> 
>
> I posted a patch for the numbers-in-identifiers enhancement
> 
>
> It might help a little as a concrete example, showing the challenges of 
> supporting LilyPond's very lenient syntax.
>
> (I can't really tell for sure, but I think maybe David likes the patch.)

Just shows what an abysmal communicator I am.

-- 
David Kastrup


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

Re: [GLISS] verbifying music functions

[Keith OHara]

Graham Percival  percival-music.ca> writes:

> Let's have a look at verbifying music functions.
> [and special-cases that look just like music functions to the user]

Most pre-fix functions do seem to be verbs expressing what we want LilyPond
to do to the following music.   The exceptions

> appoggiatura => \addAppoggiatura ?  not nice

> clef

are nouns because they are themselves the notation. 

The implementation is that \appogiatura transforms the following music into
an appogiatura, but we think of the appogiatura as the main concept, and
the pitches describing the appogiatura.  

Similarly the \clef "treble_8"

The ones with obvious changes to verbs, really should be verbs to help 
us remember that they do something to the following music

> balloonText   => \addBalloonText

I would go so far as

bookOutputName =>  setBookOutputName

So I like your original concept of verbifying prefix functions, tempered 
by letting those that create notation unattached to any notes, be the nouns 
that name the notation.

I might be biased being a native English speaker.  However, when I work 
in other languages I am *more* conscious of which words are nouns, verbs, 
particles, etc.  


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

Re: [GLISS] verbifying music functions

[David Kastrup]

Keith OHara  writes:

> Graham Percival  percival-music.ca> writes:
>
>> Let's have a look at verbifying music functions.
>> [and special-cases that look just like music functions to the user]
>
> Most pre-fix functions do seem to be verbs expressing what we want LilyPond
> to do to the following music.   The exceptions
>
>> appoggiatura => \addAppoggiatura ?  not nice
>
>> clef
>
> are nouns because they are themselves the notation. 
>
> The implementation is that \appogiatura transforms the following music into
> an appogiatura, but we think of the appogiatura as the main concept, and
> the pitches describing the appogiatura.  
>
> Similarly the \clef "treble_8"
>
> The ones with obvious changes to verbs, really should be verbs to help 
> us remember that they do something to the following music
>
>> balloonText   => \addBalloonText

I think that those commands basically retaining their last argument with
extras could be

\withBalloon

\withFootnote

\withTag

\withTweak

...

but I am not particularly convinced that this really makes things easier
for people.

> I would go so far as
>
> bookOutputName =>  setBookOutputName

Actually, I have code allowing

\bookOutputName = ...

to be used (\bookOutputName itself then referencing it).  It just does
not make all that much sense without a few other changes in music
functions.

-- 
David Kastrup


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

Re: bar-line interface part 2/2 (issue 6498052)

[thomasmorley65]

More nit-picking:


http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py
File python/convertrules.py (right):

http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py#newcode3395
python/convertrules.py:3395: @rule ((2, 17, 2), r"New bar line
interface")

There's no converting rule for the old "|s"
(Note the small `s')

I'd suggest to do:
"|s" -> "|-s"
and to add
#(define-bar-line "|-s" "" "|" "|")
to /scm/bar-line.scm

http://codereview.appspot.com/6498052/

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

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[k-ohara5a5a]

On 2012/09/02 06:25:58, MikeSol wrote:


It's not a copy of the original slur because it is using
pure heights and offsets.


I saw you interrogating SlurStub regarding its purity, but did not
notice that SlurStub took any different shape based on 'pure' estimates.

The SlurStubs in the regtest were shaped just like the printed Slurs,
but now I see the difference in the Chopin prelude, with

 \layout { \context { \Score
   \override SlurStub #'color = #green
   \override SlurStub #'transparent = ##f
   \override Slur #'color = #darkgreen
   \override PhrasingSlur #'color = #darkgreen }}

The SlurStubs are not sufficiently accurate to help, and they cost me
time.

Chopin op45:patch   'skylines'  2.16
real0m21.666s   0m16.245s   0m12.862s
user0m20.814s   0m15.573s   0m12.232s
sys 0m0.240s0m0.254s0m0.217s


http://codereview.appspot.com/6498077/

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

gerrit - does it allow writing commits using a web interface?

[Janek Warchoł]

Hi John,

i remember that you are investigating whether we could be using Gerrit
for Lily work.  I may've asked this question already, but i don't
remember whether there was a definitive answer: does gerrit have a web
interface that allows to create new commits using only a web browser?
I've skimmed over
http://qt-project.org/wiki/Gerrit-Introduction
but didn't find any answer.

The reason i'm so concerned about this is simple: it would enable
hordes of LilyPond users (;-)) to participate in Lily development.
The following situation happened to me several times: a user had a
problem, i've explained how to fix it (or simply sent a link to
appropriate section in manuals), and i asked "how could we improve the
manuals so that you had found this information easier/understood it
better?".  Unfortunately, the responses are usually too vague to be
turned to a patch on the spot, and i don't have time to think about
them myself (and it doesn't make sense to ask the user to install
Lilydev and learn how to make a patch just for this).  With a web
interface, this would become massively simpler.
Also, Graham's catchphrase "patches appreciated" would become much
more powerful :)

cheers,
Janek

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

PATCH: Countdown to 20120904

[Colin Campbell]

For 20:00 MST Tuesday September 4

Critical:
Issue 2783 
: wrong 
placement of timesignature - R 6494071 

Issue 1290 
: Skyline 
compaction is going overboard sometimes - R 6503057 



Enhancement:
Issue 2805 
: Patch: 
Dynamics do not unnecessarily horizontal shift for stems - R 6493073 

Issue 2758 
: 
ly_module_lookup caused deprecation warnings when LilyPond running with 
Guile V2.06 - R 6458159 


Build:
Issue 2804 
: Patch: 
Removes echoed information from make doc - R 6496074 



Ugly:
Issue 2795 
: Vertical 
skylines problems - R 6498070 




Note that as mentioned Thursday, I won't have 'net access from Tuesday 
'til Sunday, as I'll be in Ottawa on a course. I'd be delighted to meet 
& greet any lilyponders in the area, but I won't be able to do the patch 
batches on Tuesday, Thursday and Sunday.


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: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

[pnorcks]

LGTM

http://codereview.appspot.com/6458159/

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

Re: Removes echoed information from make doc (issue 6496074)

[pnorcks]

LGTM

http://codereview.appspot.com/6496074/

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

Re: [GLISS] differentiating pre/post/neutral commands

[Han-Wen Nienhuys]

On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
 wrote:

> The meta-target is "after spending 5 years very publicly telling
> people *not* to talk about changing the syntax because we would do
> so 'in a year or two', I think I should encourage such
> discussions.".  I mean, people trusted me when I said that there

I have been trying for years on end to dissuade anyone from discussing
or proposing syntax changes. Look how successful I was. Whatever you
have been saying in the past is irrelevant.

I predict that a lot of discussions will be had, and we will end up
with virtually no changes. I guess that such is life.

> Of course many of our ideas will not be good.  That's fine!
> That's how creative thinking works!

No; syntax discussions without understanding how the lilypond parser
works is just blowing around hot air and discussing bike shed colors.

-- 
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: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[mtsolo]

On 2012/09/02 20:38:28, Keith wrote:

On 2012/09/02 06:25:58, MikeSol wrote:



> It's not a copy of the original slur because it is using
> pure heights and offsets.



I saw you interrogating SlurStub regarding its purity, but did not

notice that

SlurStub took any different shape based on 'pure' estimates.



The SlurStubs in the regtest were shaped just like the printed Slurs,

but now I

see the difference in the Chopin prelude, with



  \layout { \context { \Score
\override SlurStub #'color = #green
\override SlurStub #'transparent = ##f
\override Slur #'color = #darkgreen
\override PhrasingSlur #'color = #darkgreen }}



The SlurStubs are not sufficiently accurate to help, and they cost me

time.


Chopin op45:patch   'skylines'  2.16
 real   0m21.666s   0m16.245s   0m12.862s
 user   0m20.814s   0m15.573s   0m12.232s
 sys0m0.240s0m0.254s0m0.217s


I'm working on a new version of the patch.  There is no way to improve
accuracy of the curve, but the Y-offset is often wrong and that can be
improved.

The time hike seems awfully expensive - there must be a way to optimize
it.  I'll post something that works when I have it and then we can
figure out how to optimize it.

http://codereview.appspot.com/6498077/

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

Re: [GLISS] differentiating pre/post/neutral commands

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
>  wrote:
>
>> The meta-target is "after spending 5 years very publicly telling
>> people *not* to talk about changing the syntax because we would do so
>> 'in a year or two', I think I should encourage such discussions.".  I
>> mean, people trusted me when I said that there
>
> I have been trying for years on end to dissuade anyone from discussing
> or proposing syntax changes.

Well, I am proposing syntax changes on a regular schedule...  Most of
them don't affect the bulk of existing LilyPond files, while often
changing the set of valid files significantly.  It is often in the
"wait, you mean _this_ was valid LilyPond code before?" area.

> Look how successful I was. Whatever you have been saying in the past
> is irrelevant.

Hardly.  We have a continuity of developers and expectations, and that
is what Graham has to work with.

> I predict that a lot of discussions will be had, and we will end up
> with virtually no changes. I guess that such is life.
>
>> Of course many of our ideas will not be good.  That's fine!
>> That's how creative thinking works!
>
> No; syntax discussions without understanding how the lilypond parser
> works is just blowing around hot air and discussing bike shed colors.

The LilyPond parser toolkit is rather powerful, and one can do a lot
with it.  Partly by tricking around and doing some things manually when
they are definitely worth doing.  Most of the proposals are a bad idea
without actually having to look at implementability because they
introduce ambiguities that are hard to resolve not just in LilyPond's
parser (which can be fiddled to be able to do a lot of fine
distinctions), but generally in the grammar.  Usually when it is hard to
teach LilyPond's parser fine distinctions, it means that it is hard
teaching its users the fine distinctions as well, and hard to teach
convert-ly the fine distinctions, and hard to teach programs writing and
reading LilyPond the fine distinctions.  And many proposals are of the
kind one can't even resolve with fine distinctions since they are
inherently contradictory or ambiguous.

The problem is not that the parser would not warrant some changes.  The
problem is that the discussion tends to focus on lines leading nowhere
for various reasons, and that causes a state of panic for those actually
working on the parser, and frustration for those who feel that their
proposals are not taken seriously by those "in power", namely actually
working with and on the parser code.

-- 
David Kastrup

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

Re: preliminary GLISS discussions

[Han-Wen Nienhuys]

On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen  wrote:
> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front end.
>
> We have perfectly fine ly parsers of each available version available in
> executable form from lilypond.org.  What we do not yet have, is a handy
> or integrated way of dumping the music tree with the original binary
> [read: a nice web service -- this could possibly be integrated with a
> mutopia revival, I'll be looking into this] reading the music tree with
> the current version and a perfect ly-dump function.  Eg, I think we may
> want to preserve %-comments in the music tree, or other stuff the user
> does not want to lose?

The tree is not what people want, though?  The tree has no information
about identifier subsitutions, and you only get the output of each
music function application.

You could argue that you could use the LilyPond parser to understand
the file for the rewrites. Unfortunately, due to how LilyPond works
(eg. the funky way music functions are parsed), you have to run the
full parse to know how to interpret something:

  #(set! identifier (..complicated expression .. ))
  \relative \identifier { a b }

you have to know the value (ie. the type) of \identifier, to know if {
a b } is the music relativized (yay for optional arguments). That in
turn implies running all the inline scheme. At this point, you are no
longer just "parsing" the input, you are actually processing it.

Since the output of the parser is not good enough (remember, we're
applying destructive operations during the parse), you have to modify
the parser to store all kinds of intermediate state about how tokens
are interpreted.

I am not saying it is impossible, but it is a lot of work, and you
don't get this type of thing "for free" by any measure.

I think it shows one of the fundamental weaknesses of how we
implemented the parser. The traditional model is the following:

1. Parse entire program into abstract syntax tree
2. Process tree to execute/compile the program.

Syntax transformations are easy: you can have a simple parser to read
the program into a tree, do some rearrangements on the tree, and the
serialize the tree back to a program. Successful examples of this are
Python (the AST package) and Go (packages go/parser and go/ast)

In LilyPond both phases are intertwined, since at any point during the
parse, we escape to Scheme to do execution, and the results of the
execution affect how the rest of the .ly file is parsed. This makes it
very difficult to do any kind of syntactic transformations
programmatically.

To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
creating a syntax that strictly separates parsing and interpretation.
This implies not only rethinking  a lot of syntax, but also it means
letting go of some of the flexibility and conciseness of the current
format.

--
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: gerrit - does it allow writing commits using a web interface?

[David Kastrup]

Janek Warchoł  writes:

> Hi John,
>
> i remember that you are investigating whether we could be using Gerrit
> for Lily work.  I may've asked this question already, but i don't
> remember whether there was a definitive answer: does gerrit have a web
> interface that allows to create new commits using only a web browser?
> I've skimmed over
> http://qt-project.org/wiki/Gerrit-Introduction
> but didn't find any answer.
>
> The reason i'm so concerned about this is simple: it would enable
> hordes of LilyPond users (;-)) to participate in Lily development.
> The following situation happened to me several times: a user had a
> problem, i've explained how to fix it (or simply sent a link to
> appropriate section in manuals), and i asked "how could we improve the
> manuals so that you had found this information easier/understood it
> better?".  Unfortunately, the responses are usually too vague to be
> turned to a patch on the spot, and i don't have time to think about
> them myself (and it doesn't make sense to ask the user to install
> Lilydev and learn how to make a patch just for this).  With a web
> interface, this would become massively simpler.
> Also, Graham's catchphrase "patches appreciated" would become much
> more powerful :)

Frightening rather.  I don't spend enough time defending LilyPond
against awful patches as it is.  An automated system should likely
reject any patch not containing at least 25% of comment lines in code
areas (would be nice if this was the case for every submission).  Our
quality of code is terrible, and part of the reason is that submitters
just can't be bothered being interested in producing maintainable code.
Part of the reason is that the existing code base is not really a
shining example.  There is a lot of code that works because of fine
points and underlying designs that are not documented, and so this code
is useless as a template for how to write code that does not explode
around everyone's ears eventually.

It is also a timebomb for maintenance since changes might violate
underlying assumptions.

And that is just talking about code that actually works for good
reasons.  Quite a bit of code works since it has been prodded into not
failing under those circumstances that tend to be tested.

It is easy to make it easier to meddle with LilyPond code.  The low
number of contributors is not due to our toolchains.  It is because few
people are comfortable poking around in the dark.  And for good reason.

-- 
David Kastrup


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

Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

[dak]

On 2012/09/03 03:41:39, Patrick McCarty wrote:

LGTM


Let's not get this merged.  ly_lily_module_constant ("module-variable")
is available in _both_ Guile 1.8 as well as Guile 2.0.  It may cause a
slight cell count hit in Guile 1.8, but we don't want Guile 1 to stick
around until the end of 2.17 anyway.

http://codereview.appspot.com/6458159/

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

Re: [GLISS] differentiating pre/post/neutral commands

[Han-Wen Nienhuys]

On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup  wrote:
>> I predict that a lot of discussions will be had, and we will end up
>> with virtually no changes. I guess that such is life.
>>
>>> Of course many of our ideas will not be good.  That's fine!
>>> That's how creative thinking works!
>>
>> No; syntax discussions without understanding how the lilypond parser
>> works is just blowing around hot air and discussing bike shed colors.
>
> The LilyPond parser toolkit is rather powerful, and one can do a lot
> with it.  Partly by tricking around and doing some things manually when
> they are definitely worth doing.  Most of the proposals are a bad idea
> without actually having to look at implementability because they
> introduce ambiguities that are hard to resolve not just in LilyPond's
> parser (which can be fiddled to be able to do a lot of fine
> distinctions), but generally in the grammar.  Usually when it is hard to
> teach LilyPond's parser fine distinctions, it means that it is hard
> teaching its users the fine distinctions as well, and hard to teach
> convert-ly the fine distinctions, and hard to teach programs writing and
> reading LilyPond the fine distinctions.  And many proposals are of the
> kind one can't even resolve with fine distinctions since they are
> inherently contradictory or ambiguous.

> The problem is not that the parser would not warrant some changes.  The
> problem is that the discussion tends to focus on lines leading nowhere
> for various reasons, and that causes a state of panic for those actually
> working on the parser, and frustration for those who feel that their
> proposals are not taken seriously by those "in power", namely actually
> working with and on the parser code.

I think we are in violent agreement.

I would much rather see patches to the parser rather than proposals
that show examples. Examples always show how things would work in
obvious situations, but the problem is not in the obvious cases. The
problem is in all the ambiguities that have to be resolved. Without
working on the parser, it is difficult to appreciate the subtleties of
specifying a grammar unambiguously and maintaining backward
compatibility.

Rather than proposing something by way of example, I would like to see
all proposals in the form of a parser patch that does not introduce
extra shift/reduce or reduce/reduce conflicts, and maintains general
backward compatibility. If a proposer manages to get that far, I
promise I will take a serious look at it.

--
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: preliminary GLISS discussions

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen  wrote:
>> David Kastrup writes:
>>
 Maybe the time has finally come to drop convert-ly and implement and
 fully supported conversions using LilyPond on music stream level.
>>>
>>> You still need a parser of the appropriate version at the front end.
>>
>> We have perfectly fine ly parsers of each available version available in
>> executable form from lilypond.org.  What we do not yet have, is a handy
>> or integrated way of dumping the music tree with the original binary
>> [read: a nice web service -- this could possibly be integrated with a
>> mutopia revival, I'll be looking into this] reading the music tree with
>> the current version and a perfect ly-dump function.  Eg, I think we may
>> want to preserve %-comments in the music tree, or other stuff the user
>> does not want to lose?
>
> The tree is not what people want, though?  The tree has no information
> about identifier subsitutions, and you only get the output of each
> music function application.

It is not the preferred form for modification.  Unless its
distinguishing feature is that it works at all and you lack the
expertise for modifying the original source code in a manner making it
work under newer LilyPond versions.

For the users of things like Mutopia, more often than not the desire is
not to see interesting source code, but rather the ability to tweak
paper dimensions and scale and transposition, fix single typos, and
rearrange material.  Not having to cut a \relative call into several
parts for which you have to hand-recalculate the starting pitch might
actually be an advantage.

For the majority of people interested in scores, LilyPond is
gobbledygook.  They still want to pull scores from it.

-- 
David Kastrup


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

Re: [GLISS] differentiating pre/post/neutral commands

[Werner LEMBERG]

> Rather than proposing something by way of example, I would like to
> see all proposals in the form of a parser patch that does not
> introduce extra shift/reduce or reduce/reduce conflicts, and
> maintains general backward compatibility. If a proposer manages to
> get that far, I promise I will take a serious look at it.

You are exaggerating, aren't you?  With this prerequisite, very useful
stuff like `q' would have never been implemented.  It took David a
long time to generalize it, but IMHO it was worth the trouble.

Perhaps we should start differently: Instead of making ad-hoc syntax
suggestions, let's collect experienced user reports about the most
annoying LilyPond syntax issues.  The stress lies on *user*, not
developer.  Then parser experts can have a look whether changes are
possible and useful.


Werner

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

Re: exact placement rules for volta brackets?

[ArnoldTheresius]

Hello Marc,

I think to base the volta brackets on the bar line horizontal origin (where
differnt sized bar lines in different staves are aligned together) is the
best solution.
I expect, based on this a 'linear transformation' can do the rest of the
job.

I just started my trials with a callback to shift the volta brackets
depending on the current context.
In an alist 'my-volta-bracket-horizontal-adjustments' I setup the 'linear
transformation values', which are evaluated by
my-volta-bracket-shorten-pair, which is defined as callback for
'VoltaBracket #'shorten-pair'. There are 4 'tranformation value lists' per
bar type - for left and for right hook, and for begin/end of line and for
middle of line.
I hope, you can use much of this code to include in scm/bar-line.scm.
In my trials I observerd some more 'future work':
- If you modify the bar line size properties, some (especially the segno)
may run out of shape
- I got diffent volta brackets at the same time (in different staves) -
perhaps a new detected bug.

Here is my test example:
http://lilypond.1069038.n5.nabble.com/file/n132047/volta-hook-alignment.ly
volta-hook-alignment.ly 

ArnoldTheresius



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/exact-placement-rules-for-volta-brackets-tp131790p132047.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: Allow digits in identifiers (issue 6493072)

[ArnoldTheresius]

It's an undocumented feature:
I'm using digits in lilypond since version 2.10.33, because I'm not using
the ASCII digits!
All superscript and subscript digits work, additionaly I use the superscript
and subscript variants of '+' and '-', and the double underscore.
This selection give me the most benefit, and they work without quoting.
Off course, only UTF-8 input.
Ubuntu offers most of them in the /international/ keyboard layouts.
On Windows I expanded the dead char tables of 'accent acute' and 'accent
grave' by using the MSKLC.

ASCII-Digits?
As you usually have to define them using quotes, it would be consequent if
you need quotes to recall them, e.g. \\"u_x-32" (because '\"' is allready
special).

ArnoldTheresius



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Allow-digits-in-identifiers-issue-6493072-tp131975p132048.html
Sent from the Dev mailing list archive at Nabble.com.

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