https://codereview.appspot.com/248470043/diff/1/scm/autochange.scm
File scm/autochange.scm (right):
https://codereview.appspot.com/248470043/diff/1/scm/autochange.scm#newcode38
scm/autochange.scm:38: (m1 (make-non-relative-music (context-spec-music
music 'Voice one)))
On 2015/06/29 09:03:56,
https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh
File lily/include/lily-modules.hh (right):
https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh#newcode39
lily/include/lily-modules.hh:39: Scm_module (const char *name);
On 2015/06/29
On 2015/06/28 12:30:21, Dan Eble wrote:
On 2015/06/28 11:17:58, thomasmorley651 wrote:
Let me clearify, I don't insist in keeping those properties, though
I'd like
to
keep the possibility to simply write \autochange { ... } _and_ to
have the
possibility to set the clefs in both staves.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Here is the current patch countdown list. The next countdown will be
on July 2nd.
You can always view the most current countdown list here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On 29/06/15 00:48, tisimst wrote:
Got it. That's the file data I saw that made me wonder. Makes
perfect sense now!
On Saturday, June 27, 2015, Masamichi Hosoda [via Lilypond]
ml-node+s1069038n178256...@n5.nabble.com wrote:
Some remarks.
Not related to your changes, though, why not fix them, when you're
already on it?
https://codereview.appspot.com/248470043/diff/1/scm/autochange.scm
File scm/autochange.scm (right):
https://codereview.appspot.com/248470043/diff/1/scm/autochange.scm#newcode2
scm/autochange.scm:2:
I don’t see any differences in the regression tests when I remove
make-non-relative-music from this code. If it’s really necessary, can anyone
suggest or provide a new regression test that covers it? I’d be happy to see
it through the review process. Thanks.
(define-public
I'd like to study this more, but I don't think I have the time to spend.
https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh
File lily/include/lily-modules.hh (right):
https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh#newcode39
On 2015/06/30 00:30:15, dak wrote:
I don't understand what you are trying to say here. Apparently you
are arguing
for the explicit keyword. We don't use any C++11 feature elsewhere
in
LilyPond.
Explicit constructors were a feature before C++11. It's explicit
conversion methods that are
On 2015/06/30 00:49:33, Dan Eble wrote:
On 2015/06/30 00:30:15, dak wrote:
I don't understand what you are trying to say here. Apparently you
are
arguing
for the explicit keyword. We don't use any C++11 feature
elsewhere in
LilyPond.
Explicit constructors were a feature before C++11.
On 2015/06/30 01:02:31, dak wrote:
I vaguely remember that stuff could become a nuisance in connection
with numeric
promotion rules because promotion might get combined with implicit
conversion
Aha. One past experience involved a number-like class which could be
initialized by a double, and
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc#newcode62
lily/stencil-integral.cc:62: void create_path_cap (vectorBox boxes,
vectorDrul_arrayOffset
Oh, I haven't meant that you should reformat everything but just the
code you are actually modifying! But thanks anyway.
For long names I suggest a formatting like this
Grob::maybe_pure_internal_simple_skylines_from_extents(
foo arg1,
bar arg2,
...)
to avoid exactly the problem
LGTM
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc#newcode62
lily/stencil-integral.cc:62: void create_path_cap (vectorBox boxes,
14 matches
Mail list logo
