Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-14 Thread Keith OHara 

On Mon, 14 May 2012 03:32:11 -0700,  wrote:


http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}   {
On 2012/05/13 02:43:23, Keith wrote:

Stupid question, but I can't figure it out.  Can we remove this

pattern from the

rules for individual starting states, now that it is matched globally

?




So the answer to this question is: no.  Maybe it has to do with the
starting state specific UNSIGNED rules firing with priority then.  I'll
try moving the FRACTION rule up, but am skeptical that this will work
out better, so just let's keep the unchanged countdown on.

http://codereview.appspot.com/6200068/



Oops.  All the start conditions are declared exclusive, so global rules
only match when we are in start condition 'INITIAL'.  <*> rules would
match in comments, which is not wanted, so no combining of rules until
the start conditions that don't need to be exclusive are made inclusive.



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

Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-14 Thread dak 

On 2012/05/14 10:32:11, dak wrote:


So the answer to this question is: no.  Maybe it has to do with the

starting

state specific UNSIGNED rules firing with priority then.  I'll try

moving the

FRACTION rule up, but am sceptical that this will work out better, so

just let's

keep the unchanged countdown on.


Did not work, either.  So reducing the number of rules is left as an
exercise for an ambitious reader.

http://codereview.appspot.com/6200068/

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

Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-14 Thread dak 


http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}   {
On 2012/05/13 02:43:23, Keith wrote:

Stupid question, but I can't figure it out.  Can we remove this

pattern from the

rules for individual starting states, now that it is matched globally

?

Well, now I tried.

GNU LilyPond 2.15.39
Changing working directory to: `./out-test'
Processing `quantize-duration-2.ly'
Parsing...
/usr/local/tmp/lilypond/input/regression/midi/quantize-duration-2.ly:47:10:
error: syntax error, unexpected '/'
  e'''4*41
  /192 r4*7/192 d4*41/192 r4*7/192 fis,4*89/192 r4*7/192
gis4*89/192
/usr/local/tmp/lilypond/input/regression/midi/quantize-duration-2.ly:47:19:
error: syntax error, unexpected '/'
  e'''4*41/192 r4*7
   /192 d4*41/192 r4*7/192 fis,4*89/192 r4*7/192
gis4*89/192

[...]

So the answer to this question is: no.  Maybe it has to do with the
starting state specific UNSIGNED rules firing with priority then.  I'll
try moving the FRACTION rule up, but am sceptical that this will work
out better, so just let's keep the unchanged countdown on.

http://codereview.appspot.com/6200068/

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

Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-13 Thread tdanielsmusic 

LGTM (with Janek's suggested change)

http://codereview.appspot.com/6200068/

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

Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-13 Thread janek . lilypond 

I don't know the parser stuff (and no time to figure it out), but docs
LGTM.


http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely#newcode321
Documentation/notation/rhythms.itely:321: @code{*L*M/N}.  Such
alterations become part of the duration as such; if
"as such" makes me scratch my head.  What about

"Multiplying factors may be combined: @code{*L*M/N}.  Such alterations
become part of the duration;"

?

http://codereview.appspot.com/6200068/

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

Re: Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-12 Thread dak 

Reviewers: Keith,


http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely#newcode331
Documentation/notation/rhythms.itely:331: a4*2/3 gis a
On 2012/05/13 02:43:23, Keith wrote:

Oh yes.  You had asked who were "some people" who use this

construction.  It's

not just me this time; I also see it in other people's scores on

mutopiaproject.


I'll admit that I used it to avoid the Lisp syntax in \scaleDurations

#'(2 . 3)

\scaleDurations 2/3 would have worked from version 2.15.17 on (fractions
in function arguments).  The necessity of parser changes to allow for
fractions in property initializations caught me on the wrong foot: I
would have imagined the first patch set to work already.  This was
supposed to be just a documentation change.

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
File
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
(right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly#newcode25
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly:25:
\scaleDurations 8/5 {
On 2012/05/13 02:43:23, Keith wrote:

Somehow, this worked before the patch.  Not a problem, just an

observation.

Yup.  As I said: 2.15.17 for function arguments (that's when \times 2/3
... became a regular function instead of a reserved word in the parser).

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}   {
On 2012/05/13 02:43:23, Keith wrote:

Stupid question, but I can't figure it out.  Can we remove this

pattern from the

rules for individual starting states, now that it is matched globally

?

I have not tried it.  We have separate rules for unsigned, possibly
because 3.5 can means something else in some modes.  One should probably
make sure that in special situations, like figured bass or chordmode,
the global parser change does not cause trouble.

I have not really given it any thought yet, relying on the regtests to
tell me if I was hitting on the syntax of existing constructs.

If one tried simplifying this, one should make sure that rules still
back up.

Description:
Use fractions rather than Scheme pairs for \scaleDuration,
timeSignatureFraction et al

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

Affected files:
  M Documentation/ly-examples/aucun-snippet.ly
  M Documentation/notation/rhythms.itely
  A  
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly

  M input/regression/chord-tremolo-scaled-durations.ly
  M input/regression/time-signature-settings-by-staff.ly
  M lily/lexer.ll
  M lily/parser.yy
  M ly/engraver-init.ly
  M ly/performer-init.ly



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

Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al (issue 6200068)

2012-05-12 Thread k-ohara5a5a 


http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythms.itely#newcode331
Documentation/notation/rhythms.itely:331: a4*2/3 gis a
Oh yes.  You had asked who were "some people" who use this construction.
 It's not just me this time; I also see it in other people's scores on
mutopiaproject.
I'll admit that I used it to avoid the Lisp syntax in \scaleDurations
#'(2 . 3)

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
File
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
(right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly#newcode25
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly:25:
\scaleDurations 8/5 {
Somehow, this worked before the patch.  Not a problem, just an
observation.

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}   {
Stupid question, but I can't figure it out.  Can we remove this pattern
from the rules for individual starting states, now that it is matched
globally ?

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode528
lily/lexer.ll:528: {FRACTION}   {
?

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode573
lily/lexer.ll:573: {FRACTION}   {
?

http://codereview.appspot.com/6200068/

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