http://codereview.appspot.com/5023044/diff/22001/scm/ly-syntax-constructors.scm
File scm/ly-syntax-constructors.scm (right):
http://codereview.appspot.com/5023044/diff/22001/scm/ly-syntax-constructors.scm#newcode52
scm/ly-syntax-constructors.scm:52: (format #f (_ "~a function can't
return ~a")
O
http://codereview.appspot.com/5023044/diff/22001/scm/ly-syntax-constructors.scm
File scm/ly-syntax-constructors.scm (right):
http://codereview.appspot.com/5023044/diff/22001/scm/ly-syntax-constructors.scm#newcode52
scm/ly-syntax-constructors.scm:52: (format #f (_ "~a function can't
return ~a")
(
Pushed as b4ff85a2416e4b80deb9eef8329cd230ee4dc944 and preceding.
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests and docs are there. The last upload, however, seems to have
influences from a few unrelated commits. Rietveld is too complicated
for me.
On the plus side, a working version (compiles the docs as far as I can
tell) has been pushed to dev/staging.
http://codereview.appspot.com/5023044/
Pushed as 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Not sure what tracker (if any) issue this is but it now passes make and
reg tests.
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
carl.d.soren...@gmail.com writes:
> I'd be lying if I said I understood everything going on here, but I
> think I get the gist.
Same here.
> I like moving this way!
>
> I like the approach of simplifying things.
>
> I like having optional predicates, and optional predicates with
> defaults.
>
>
I'd be lying if I said I understood everything going on here, but I
think I get the gist.
I like moving this way!
I like the approach of simplifying things.
I like having optional predicates, and optional predicates with
defaults.
I will trust you that it is O(n) and that all the shift-reduce
Next round. Getting past shift/reduce conflicts required adding
precendences to every terminal token that can start the last
non-optional argument.
But the resulting grammar is O(n): adding more elements to it is quite
straightforward.
http://codereview.appspot.com/5023044/
___
ianhuli...@gmail.com writes:
> Looks pretty cool, apart from some involved Scheme which I couldn't
> really unravel totally (see below).
>
> Will this patch allow us to get rid of the abomination of
> \afterGraceFraction by recasting \afterGrace to have an optional
> parameter
> \afterGrace {note}
On 2011/09/15 21:29:20, dak wrote:
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm#newcode33
scm/document-identifiers.scm:33: (format $f "(~a)"
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm#newcode33
scm/document-identifiers.scm:33: (format $f "(~a)" (type-name pred)
On 2011/09/15 19:
Fails make
--snip--
Backtrace:
In unknown file:
?: 0* [primitive-load-path "documentation-generate.scm"]
In
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/documentation-generate.scm:
72: 1* [display ...
73: 2* [identifiers-doc-string]
In
/home/jlowe/lilypond-git/build/out
Looks pretty cool, apart from some involved Scheme which I couldn't
really unravel totally (see below).
Will this patch allow us to get rid of the abomination of
\afterGraceFraction by recasting \afterGrace to have an optional
parameter
\afterGrace {note} {gracenotes} [spacing-fraction]
e.g.
c1 \
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm
File scm/music-functions.scm (right):
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode792
scm/music-functions.scm:792: "
On 2011/09/15 10:45:11, Reinhold wrote:
Here you should add a descripti
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy#newcode1184
lily/parser.yy:1184: | EXPECT_MARKUP EXPECT_OPTIONAL function_arglist
function_markup_argument {
On 2011/09/15 10:45:11, Reinhold
Reviewers: Reinhold,
Message:
On 2011/09/15 10:45:11, Reinhold wrote:
Also, does this work for cases like
\relative c' c
Yes, it does. Parameters following non-present optional parameters are
more restricted than those following present optional parameters.
While you can't write \myrelati
Regtest is missing (doesn't need to be a useful example, it just needs
to break if that functionality ever breaks!)
Also, does this work for cases like
\relative c' c
Also, I suppose things like
\myfunction [optional-pitch] pitch music
does not work due to the lookahead not looking too far,
18 matches
Mail list logo
