Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(588)

Issue 576540043: Axis_group_engraver + Scheme engraver for staff combining

Can't Edit
Can't Publish+Mail
Start Review
Created:
4 months, 1 week ago by lilypond-pkx
Modified:
4 months ago
Reviewers:
dak, thomasmorley651
CC:
lilypond-devel_gnu.org, saul.james.tobin
Visibility:
Public.

Description

Axis_group_engraver + Scheme engraver for staff combining It provides an intuitive user interface to control whether shared or separate staves are printed, and should work for combinations of 4 or more parts. Currently, Axis_group_engraver reads keepAliveInterfaces into an internal variable during process-music, then uses the stored value during acknowledge-grob. In this patched it waits to read keepAliveInterfaces during acknowledge-grob.

Patch Set 1 #

Total comments: 4
Unified diffs Side-by-side diffs Delta from patch set Stats (+128 lines, -12 lines) Patch
M lily/axis-group-engraver.cc View 6 chunks +1 line, -12 lines 0 comments Download
A ly/divisi_engraver.ly View 1 chunk +127 lines, -0 lines 4 comments Download

Messages

Total messages: 8
lilypond-pkx
Passes make, make check and a full make doc.
4 months, 1 week ago (2019-03-13 16:31:39 UTC) #1
thomasmorley651
Can't review C++-code. Some concerns in the ly-file: https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly File ly/divisi_engraver.ly (right): https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly#newcode3 ly/divisi_engraver.ly:3: % ...
4 months, 1 week ago (2019-03-13 21:22:59 UTC) #2
saul.james.tobin
Thanks, Thomas. As you can probably tell, the Scheme code as currently submitted is more ...
4 months, 1 week ago (2019-03-17 01:45:49 UTC) #3
thomasmorley651
On 2019/03/17 01:45:49, saul.james.tobin wrote: > Re cdr is not a predicate — the list ...
4 months ago (2019-03-18 21:49:27 UTC) #4
dak
thomasmorley65@gmail.com writes: > On 2019/03/17 01:45:49, saul.james.tobin wrote: > >> Re cdr is not a ...
4 months ago (2019-03-18 22:26:15 UTC) #5
saul.james.tobin
Will play around with AnnounceNewContext — looks like it does what I'm looking for. Thanks! ...
4 months ago (2019-03-18 22:45:23 UTC) #6
thomasmorley651
On 2019/03/18 22:26:15, dak wrote: > mailto:thomasmorley65@gmail.com writes: > > > On 2019/03/17 01:45:49, saul.james.tobin ...
4 months ago (2019-03-18 22:55:37 UTC) #7
dak
4 months ago (2019-03-18 23:05:02 UTC) #8
thomasmorley65@gmail.com writes:

> On 2019/03/18 22:26:15, dak wrote:
>
>> The silence of the lambdas (almost):
>
>> #(define (divide-true-cdr ls)
>>    "Split @var{ls} into those elements which don't and do have a tail of
>>    value @code{#f}"
>>    (call-with-values (lambda () (partition cdr ls)) list))
>
>> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
>> => (((2 . #t)) ((1 . #f) (3 . #f)))
>
>> --
>> David Kastrup
>
>
> Aargh, replacing `(lambda (a b) (list a b))´ with `list´ is ofcourse far
> better.
> I considered to use simple `cdr´ instead of `(lambda (x) (eq? #t (cdr
> x)))´, though one would need to ensure the `cdr´ is always a boolean,
> otherwise our procedures would return differently sometimes.  Saul said
> so, though I thought better be paranoid than sorry ...

I have problems understanding how comparing with #t rather than #f is in
any sense better for a value presumed to be boolean.  Why do you think
it is a good idea to consider 3.14 (say) equivalent to #f rather than #t
?  I mean, nothing wrong with paranoia but to me this looks like bolting
the lampshade rather than some window.

> https://codereview.appspot.com/576540043/

-- 
David Kastrup
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b