https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make
File make/lilypond-vars.make (right):
https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make#newcode54
make/lilypond-vars.make:54: -dgs-never-embed-fonts -b
Is there a conceivable application for using -b wi
On 2017/09/24 10:05:43, trueroad wrote:
On 2017/09/24 00:25:17, knupero wrote:
> > If I understand correctly, `--bigpdfs` / `-b` has two effects.
> > One is to embed full set (non-subset) font.
> > The other is to define and use some encodings for Emmentaler.
>
> It also changes the way emmentale
On 2017/09/25 12:13:34, knupero wrote:
kill --bigpdfs, introduce --use-encodings, remove code not needed by
ghostscript
9.20+
On my system (Ubuntu Aarkvard) I have Ghostscript 9.21 which is fine.
Usually we try to support the last LTS versions of Ubuntu, possibly
RedHat (and Debian unstable ?
On 2017/09/25 12:54:24, knupero wrote:
A bit more far-reaching.
As newer versions of gs
- don't need the helpemmentaler functions and
- don't need the real inclusion of all font data and
- don't need some other details and
- don't work properly with our old code
we might well decid
Why are we still navigating the bleeding edge? LilyPond is more than 20
years old.
On 2017/09/25 16:38:16, knupero wrote:
> > --use-encodings switches emmentaler glyph generation from
"glyphshow" to
> > "show"+encodings and might be combined width
-dgs-never-embed-fonts.
>
> That sounds goo
Reviewers: carl.d.sorensen_gmail.com, thomasmorley651,
Message:
On 2017/09/25 21:28:50, thomasmorley651 wrote:
Very nice, i.e LGTM
Not sure whether this should be reflected by a reg-test, but currently
there is
no case in it triggering the warning like:
warns = {
\override NoteHead.co
On 2017/09/25 22:17:41, knupero wrote:
On 2017/09/25 17:33:47, dak wrote:
> I see. Still using -dgs-never-embed-fonts _without_
> --use-encodings seems like the most unusual combination, so I'd
> prefer if one had to explicitly switch encodings _off_ rather than
> _o
On 2017/09/26 20:26:36, knupero wrote:
> Regarding the naming of the option, I'd prefer to have something
> oriented around the actual use characteristics rather than the
> internal details.
>
> Does that sound like something you can agree with?
Yes. That sounds reasonable.
If you know a b
On 2017/09/27 09:38:21, knupero wrote:
> Bikeshedding done for the day.
Let me continue.
"lilypond --help" and "lilypond -dhelp" gives perfect help to all
users. I doubt
that there are a lot of people who know which parameters to use for a
non-trivial case even after reading the help text
On 2017/09/27 11:49:51, knupero wrote:
> How about just --pdf= ? One option less to remember. This
is going
to
> be double the fun once we can generate PDF bypassing PS altogether.
Yes, even better.
> Sounds like a good strategy. Just not in time for 2.20.
I tend to agree.
Well, s
On 2017/09/28 10:26:05, knupero wrote:
> While we are at it, it may make sense not to refer to the no longer
> existing Gmane page for bug reports.
I changed the message, but there are 58 more places where post.gmane
is
referenced in the tree.
And there 113 mor place that reference othere pl
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely#newcode67
Documentation/changes.tely:67: hyphenated;
A few remarks after the fact (sorry for that
On 2017/10/01 17:11:41, pkx166h wrote:
On 2017/10/01 10:57:31, dak wrote:
>
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely
> File Documentation/changes.tely (right):
>
>
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.te
On 2017/10/06 08:12:23, Malte Meyn wrote:
Thanks for the suggestions, I’ll apply these fixes, test them, and add
a
regression test.
There’s another issue (already present in the “old”
Merge_rests_engraver):
Single-bar or non-compressed MMRs in 4/2 time are positioned
incorrectly because
On 2017/10/06 08:42:55, Malte Meyn wrote:
On 2017/10/06 08:19:46, dak wrote:
> Stupid question: is there no way to (re-)use the default callbacks
which know
> about all those little details? Set `direction` to neutral and call
them for
> advice?
I’m not sure what you mean:
https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
File python/convertrules.py (right):
https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#newcode3963
python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|po
On 2017/10/06 22:28:38, thomasmorley651 wrote:
One could probably do something at the lines of:
Accordion registers missing. Should we consider them a separate name
space?
(pretty-print
(sort
(map car
(filter
(lambda (x)
(let* ((predicates (markup-command-
https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/three-sided-box.ly
File Documentation/snippets/three-sided-box.ly (right):
https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/three-sided-box.ly#newcode7
Documentation/snippets/three-sided-box.ly:7
On 2017/10/07 10:48:14, dak wrote:
Run makelsr.py for fixing a few \version statements
Oops. Actually I also fixed up the docs in scm/accreg.scm .
https://codereview.appspot.com/331820043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I think this approach is a rather bad tradeoff between additional
context properties and actual flexibility: it still only allows for a
very limited subset of metronome marks.
I think it would make sense to check all forms a \tempo mark currently
can take and then see what principal forms those c
https://codereview.appspot.com/331860043/diff/20001/Documentation/snippets/keyboard-headword.ly
File Documentation/snippets/keyboard-headword.ly (right):
https://codereview.appspot.com/331860043/diff/20001/Documentation/snippets/keyboard-headword.ly#newcode31
Documentation/snippets/keyboard-head
-headword.ly:31: \override #'((direction
. 1) (baseline-skip . 2)) {
On 2017/10/11 10:19:25, dak wrote:
On 2017/10/08 15:19:44, thomasmorley651 wrote:
> One {}-bracket-pair could be deleted as well.
Two, actually (all except the innermost one). I'll take a look.
The {} reduction was
On 2017/10/11 21:08:49, thomasmorley651 wrote:
On 2017/10/11 10:19:25, dak wrote:
>
https://codereview.appspot.com/331860043/diff/20001/scm/define-markup-commands.scm#newcode4026
> scm/define-markup-commands.scm:4026: \\override-lines
#'(multi-measure-rest .
> #t)
> On
On 2017/10/12 06:22:22, Malte Meyn wrote:
On 2017/10/10 18:47:14, Malte Meyn wrote:
> > I think it would make sense to check all forms a \tempo mark
currently can
> take
> > and then see what principal forms those can assume.
>
> […]
>
> I’m not sure what you mean by “principal forms”. Could yo
On 2017/10/12 08:19:52, Malte Meyn wrote:
On 2017/10/12 08:04:49, Malte Meyn wrote:
> And I really would like to have the tempoShowParentheses context
property
> because it’s really common to see tempo both with and without
parentheses and
> IMHO it’s weird to have to write
> \set Score.t
On 2017/10/12 08:27:51, Malte Meyn wrote:
How would that reflect that parentheses are shown if and only if text
is
present? And how could you then change this behaviour?
Pass. For more extensive changes, we'd need a markup function.
Basically, where we can go from some reasonably easy
\temp
On 2017/10/15 09:31:37, Malte Meyn wrote:
Maybe we should think about another subproperty for text like "M. M."
that is
placed before the note but after the opening parenthesis if there is
one. This
can be neither in the tempo text (\tempo "Allegro M. M." 4 = 120 would
put it
before the par
On 2017/10/16 03:23:04, kieren_macmillan_sympatico.ca wrote:
Hi Harm (et al.),
> On the tracker I posted a more elaborated code.
> https://sourceforge.net/p/testlilyissues/issues/5215/#e472
Hmmm… That's not at *all* what I was hoping that would look like.
I was hoping it could be more li
On 2017/10/22 19:26:12, benko.pal wrote:
if it's really the same, can't it be used without copying? or if
separate
classes are absolutely needed, can't the common part be gathered in a
common
base class?
You mean, like with Slur/PhrasingSlur? Well, for one thing, then
someone needs to tak
On 2017/10/24 08:34:13, thomasmorley651 wrote:
I tried to make both engravers as equal as I could, to make it easy
for a follow
up to create a common base class for both.
My own naive attempts to introduce something like 'semi-tie-event'
failed,
though.
This looks really similar. I worked
https://codereview.appspot.com/336240043/diff/40001/scripts/lilypond-invoke-editor.scm
File scripts/lilypond-invoke-editor.scm (right):
https://codereview.appspot.com/336240043/diff/40001/scripts/lilypond-invoke-editor.scm#newcode1
scripts/lilypond-invoke-editor.scm:1:
#!/home/knut/sources/lilyb
Reviewers: Malte Meyn,
https://codereview.appspot.com/335270043/diff/1/input/regression/post-events-from-scheme.ly
File input/regression/post-events-from-scheme.ly (right):
https://codereview.appspot.com/335270043/diff/1/input/regression/post-events-from-scheme.ly#newcode11
input/regression/pos
Reviewers: Dan Eble,
Message:
On 2018/01/17 00:18:54, Dan Eble wrote:
https://codereview.appspot.com/333500043/diff/1/lily/key-performer.cc
File lily/key-performer.cc (right):
https://codereview.appspot.com/333500043/diff/1/lily/key-performer.cc#newcode71
lily/key-performer.cc:71: key_do.neg
On 2018/02/05 00:04:22, thomasmorley651 wrote:
On 2018/02/04 21:36:17, thomasmorley651 wrote:
> Works with my guilev2 setup and compiling
input/regression/markup-partial.ly
> directly.
> make doc (with guilev2) fails at different place now, while using
-j5.
> I'll redo with single thread and
On 2018/02/07 06:34:32, lemzwerg wrote:
Very nice idea!
> On the other hand, \goTo seems unlikely to resemble whatever
> we settle on for the grob name… unless everyone likes GoToScript.
What about \jumpTo? Note that I like \goTo also, and I don't mind if
the
low-level stuff uses `depart
https://codereview.appspot.com/338540043/diff/1/lily/include/stream-event.hh
File lily/include/stream-event.hh (right):
https://codereview.appspot.com/338540043/diff/1/lily/include/stream-event.hh#newcode51
lily/include/stream-event.hh:51: extern void
Using "extern" for function prototypes is we
Reviewers: thomasmorley651,
Message:
On 2018/03/16 19:19:15, thomasmorley651 wrote:
Can't review this one.
Though, from description, I'd like to suggest to put up an entry in
`changes'.
Well, yeah. Doesn't make a lot of sense without documentation and
regtest either. I'll likely get them don
On 2018/03/16 19:19:15, thomasmorley651 wrote:
Can't review this one.
Though, from description, I'd like to suggest to put up an entry in
`changes'.
Ugh. Documentation for \etc is sort-of sparse, and the main problem for
"Changes" is "which Changes"? \etc in general is a 2.20 feature and
this
https://codereview.appspot.com/339390043/diff/1/input/regression/textetc.ly
File input/regression/textetc.ly (right):
https://codereview.appspot.com/339390043/diff/1/input/regression/textetc.ly#newcode5
input/regression/textetc.ly:5: event functions for \\samp{TextScript}
events with sequences
O
https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly#newcode833
ly/music-functions-init.ly:833: #(define-music-function (label)
((integer-or-markup?))
On 2018
https://codereview.appspot.com/341150043/diff/1/lily/context.cc
File lily/context.cc (right):
https://codereview.appspot.com/341150043/diff/1/lily/context.cc#newcode723
lily/context.cc:723: find_top_context (Context &where)
What problem are you trying to fix here? find_top_context worked given
https://codereview.appspot.com/341150043/diff/1/lily/context.cc
File lily/context.cc (right):
https://codereview.appspot.com/341150043/diff/1/lily/context.cc#newcode723
lily/context.cc:723: find_top_context (Context &where)
On 2018/04/22 13:19:45, Dan Eble wrote:
On 2018/04/21 20:58:32,
On 2018/04/22 13:56:01, Dan Eble wrote:
On 2018/04/22 13:37:50, dak wrote:
> So again I don't see what problem you are trying to solve.
1. find_something(...)->blahblah()
I have no idea whether that will call blahblah() with a valid instance
of
something.
C++ does not allow &qu
On 2018/04/25 06:33:19, knupero wrote:
Please test & review the proposed syntax change.
I don't see the point in starting a formal review after this has already
been discussed on the mailing list. In particular since this differs
from your originally proposed patch (where you did not switch to
On 2018/04/25 08:36:05, dak wrote:
We don't state "please don't use that syntax in the following way or
LilyPond
will be silently confused into producing nonsense" in other respects
so it is
irrelevant that LilyPond can parse _some_ input correctly with that
change
On 2018/04/23 23:55:44, Dan Eble wrote:
David, would you accept a template class wrapping a non-null pointer,
perhaps
non_null_ptr? Conversion to a raw pointer would be implicit, but
construction from a raw pointer would be explicit. The person
constructing such
a pointer is responsible for
On 2018/04/25 12:22:18, knupero wrote:
> I don't see the point in starting a formal review after this has
already been
> discussed on the mailing list.
I was hoping, apparently in vain, that the formal process would lead
to a more
reasonable discussion.
You make it appear like "reasonabl
On 2018/04/25 23:05:08, Dan Eble wrote:
On 2018/04/25 10:44:22, dak wrote:
> It still has the disadvantage of adding a new class as baggage,
making it harder
> for newcomers interpreting code. In particular the necessity of
overloading *,
> &, and -> operators raises the amo
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
Documentation/learning/fundamental.itely:465
On 2018/05/01 20:14:34, thomasmorley651 wrote:
in the light of your findings and David's reply (#17) I changed my
mind about
those "-"-signs and now agree we should not make them a topic here.
Anyway, I found the discussion very instructive, helping me to get a
deeper
understanding. I hope i
Reviewers: mtasaka,
Message:
On 2018/05/09 15:07:04, mtasaka wrote:
I checked the patch and it looks good. Also I've confirmed that
applying this
patch actually prevents abort for reported rest-pitched-beam.ly and
as-the-deer.ly (as-the-deer.ly was on RedHat bugzilla).
Thanks, I'll take that
https://codereview.appspot.com/347770043/diff/1/stepmake/stepmake/c++-vars.make
File stepmake/stepmake/c++-vars.make (right):
https://codereview.appspot.com/347770043/diff/1/stepmake/stepmake/c++-vars.make#newcode14
stepmake/stepmake/c++-vars.make:14: CC_FILES := $(sort $(call
src-wildcard,*.cc)
Reviewers: thomasmorley651, carl.d.sorensen_gmail.com,
Message:
On 2018/05/22 21:05:59, thomasmorley651 wrote:
From description and regtest: very nice.
Will it work for below as well?
#(define frac (inexact->exact (/ 3.0 4.0)))
{ r1*/frac }
As written no, but it depends on what you real
At any rate:
LGTM
I think that covariant return types predate C++11, right?
https://codereview.appspot.com/341320043/diff/20001/lily/system.cc
File lily/system.cc (right):
https://codereview.appspot.com/341320043/diff/20001/lily/system.cc#newcode449
lily/system.cc:449: dynamic_cast (c[j])->se
On 2018/06/08 09:54:29, knupero wrote:
Please review.
When you say "will not pass make check", you mean that there are visual
differences, not that the test aborts, right? Since the latter would
not be ok.
https://codereview.appspot.com/347870043/
https://codereview.appspot.com/342060043/diff/20001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/342060043/diff/20001/lily/stencil-integral.cc#newcode1132
lily/stencil-integral.cc:1132: Stencil *q = unsmob
(s->smobbed_copy ());
Once you create a
https://codereview.appspot.com/341140043/diff/20001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/341140043/diff/20001/lily/stencil-integral.cc#newcode393
lily/stencil-integral.cc:393: for (vsize i = 0; i < (vsize) points.size
() - 1; i++)
Why wo
https://codereview.appspot.com/341350043/diff/1/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/341350043/diff/1/lily/stencil-integral.cc#newcode1132
lily/stencil-integral.cc:1132: SCM new_s = s->smobbed_copy ();
This does not work: the compiler wi
On 2018/06/12 10:49:11, Be-3 wrote:
On 2018/06/12 10:05:17, dak wrote:
> However, cough cough, all this is an unnecessary complication.
Sorry for
> overlooking this. Just write
>
> Stencil q = *s;
> […]
Just to mention it:
How about the definition of ly:stencil-rotate i
On 2018/06/12 10:49:11, Be-3 wrote:
On 2018/06/12 10:05:17, dak wrote:
> However, cough cough, all this is an unnecessary complication.
Sorry for
> overlooking this. Just write
>
> Stencil q = *s;
> […]
Just to mention it:
How about the definition of ly:stencil-rotate i
On 2018/06/13 03:24:02, dan_faithful.be wrote:
On Jun 12, 2018, at 18:18, mailto:carl.d.soren...@gmail.com wrote:
>
> The tradeoff of having people know about dynamic casting and using
it
> properly needs to be matched with people not needing to know about
> dynamic casting and being able to ig
Reviewers: Dan Eble,
Message:
On 2018/06/13 21:11:38, Dan Eble wrote:
LGTM and I would not fault you if you chose to push this immediately
after
receiving independent confirmation that it builds.
Shrug. I have no dependencies on this one. It can sit in its branch
until the shoe drops. I j
https://codereview.appspot.com/346080043/diff/1/lily/acceptance-set.cc
File lily/acceptance-set.cc (right):
https://codereview.appspot.com/346080043/diff/1/lily/acceptance-set.cc#newcode34
lily/acceptance-set.cc:34: if (!scm_is_null (default_))
Why do you prioritize the default child?
The only
Reviewers: Be-3,
Message:
On 2018/06/16 12:33:50, Be-3 wrote:
First of all: thanks for taking care of this issue!
But the resulting skylines don't quite work as expected yet (see
attached image
in the issue tracker). Seems to be a problem with the centre of
rotation
co-ordinates.
Greeting
Reviewers: Be-3,
https://codereview.appspot.com/344970043/diff/1/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/344970043/diff/1/lily/stencil-integral.cc#newcode1099
lily/stencil-integral.cc:1099: Offset center (robust_scm2double
(scm_cadr (rot),
On 2018/06/17 10:54:38, dak wrote:
Right. I haven't rebased this patch yet, but I naturally will have to
load up
another version for review now that the fix is in master.
I actually lean towards doing this in a manner similar to your original
approach, namely just using the stencil rot
On 2018/06/17 13:27:39, Dan Eble wrote:
On 2018/06/17 12:52:01, Dan Eble wrote:
> Stop uniquifying \accepts; clarify copying
I also spent time trying to find input that would "let \with blocks
destructively change global context defs." I was surprised that I
couldn't make
it happen even aft
On 2018/06/17 17:56:06, Dan Eble wrote:
On 2018/06/17 17:51:34, Dan Eble wrote:
> test that \with \denies ... has local effect
Thanks for the clue. The new test passes with the code I've submitted
and fails
if Acceptance_set::assign_copy is modified not to make a copy.
I must be getting s
https://codereview.appspot.com/346100043/diff/1/lily/paper-column.cc
File lily/paper-column.cc (right):
https://codereview.appspot.com/346100043/diff/1/lily/paper-column.cc#newcode105
lily/paper-column.cc:105: SCM m = me->get_property ("when");
How much sense does this make? get_property on ca
https://codereview.appspot.com/342170043/diff/1/lily/spacing-determine-loose-columns.cc
File lily/spacing-determine-loose-columns.cc (right):
https://codereview.appspot.com/342170043/diff/1/lily/spacing-determine-loose-columns.cc#newcode255
lily/spacing-determine-loose-columns.cc:255: cols->swa
On 2018/06/19 11:37:46, Dan Eble wrote:
On 2018/06/19 06:32:55, dak wrote:
>
https://codereview.appspot.com/342170043/diff/1/lily/spacing-determine-loose-columns.cc
> File lily/spacing-determine-loose-columns.cc (right):
>
>
https://codereview.appspot.com/342170043/diff/1/
On 2018/06/19 22:05:24, Dan Eble wrote:
On 2018/06/19 12:51:46, dak wrote:
> If you are interested in solving this mystery, be sure to record the
gist of
it
> in comments to save the next person the effort. If not, I guess the
swap is
> probably fine. It's just awkw
ote:
On 2018/06/19 06:08:56, dak wrote:
> How much sense does this make? get_property on callbacks will
execute various
> sorts of callbacks the first time a property is accessed and store a
cached
> result. So the grob is only "const" because accessing its
properties ha
On 2018/06/19 23:44:57, Dan Eble wrote:
On 2018/06/19 23:15:42, dak wrote:
> evaluation. Due to the significant timing constraints caching of
values is
not
> really conceptually const: in fact, a number of properties are
evaluated
solely
OK, well if get_property() is not even log
https://codereview.appspot.com/344970043/diff/40001/lily/include/transform.hh
File lily/include/transform.hh (right):
https://codereview.appspot.com/344970043/diff/40001/lily/include/transform.hh#newcode52
lily/include/transform.hh:52: Transform (Offset p0)
On 2018/06/20 22:30:07, Dan Eble wrot
On 2018/06/21 08:48:32, dak wrote:
A constructor/function from Transform * seems like a side track when
the only
use case is conversion from SCM. A constructor avoids an extra copy
(but I
think C++19(?) or so already states that returned classes are to be
considered
initializers rather
Well, you basically anticipated all considerations I could have brought
up and dealt with them exhaustively.
LGTM
https://codereview.appspot.com/365730043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/l
In summary: at the current point of time the added complexity because of
the employed constructs does not make the impression of being a good
tradeoff for understanding and maintaining the code.
I think you need to define the goals you want to achieve, then focus on
the simplest way of implementi
On 2018/07/01 13:21:45, dak wrote:
NLGTM
Man, I use this stuff too rarely. Maybe
PTAL
https://codereview.appspot.com/344050043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
::warning_cannot_find (origin,
to_type,
to_id);
On 2018/07/01 13:21:43, dak wrote:
> Having a separate function for each different warning text seems
clumsy. Can
> this be factored into a more generic warning function and possibly
something
> formatting to_type and to_id?
I'm willing to ch
“cannot find or create
context”
which is part of what I was trying to avoid. I wouldn’t stake this
whole patch
on getting it my way, but let’s mull it over while I work on the other
revisions.
We currently have
dak@lola:/usr/local/tmp/lilypond$ git grep "find or create" lily
lily/cont
: return score;
On 2018/07/01 13:21:42, dak wrote:
> So if there already is a Score context, it will be returned in lieu
of _any_
> request for creating any kind of context? That sounds weird.
The missing information is that this method is called to create an
immediate
child after accepta
On 2018/07/02 00:16:31, dan_faithful.be wrote:
On Jul 1, 2018, at 16:40, mailto:d...@gnu.org wrote:
>
> Premature optimization is the root of all evil. I'm going to
> pontificate now in the hope that you'll have some opportunity in
your
> work life to take karmatic revenge by passing this kind
Overall, I consider the problem you are trying to address here real:
allocation of the relevant values seems like completely overblown and it
does appear that the allocation/indirection is mainly being used in lieu
of a flag.
The "boring" way for that would be just to actually add the flag in
que
On 2018/07/05 21:32:25, Dan Eble wrote:
On 2018/07/05 12:20:27, dak wrote:
> I'd like to see some rationale for the amount of
semi-general-purpose tooling
to
> get there, and more current or future uses of it may go a long way
towards
that.
The rationale is that std::optional
LGTM
https://codereview.appspot.com/359770043/diff/20001/lily/grob.cc
File lily/grob.cc (left):
https://codereview.appspot.com/359770043/diff/20001/lily/grob.cc#oldcode325
lily/grob.cc:325: *dim_cache_[a].offset_ += y;
This is more an "as you like it" suggestion: operator priority of * as
oppo
, dak wrote:
> This is more an "as you like it" suggestion: operator priority of *
as opposed
> to [] . -> is not always clear to everybody, so
*(dim_cache_[a].offset_) += y;
> might be a consideration. On the other hand, it's ugly. And it's
not like
I would ha
Reviewers: Dan Eble, benko.pal,
Message:
On 2018/07/10 17:10:53, benko.pal wrote:
LGTM; just by looking I can't see how it can make make fail.
using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to
me, but
YMMV.
Since the whole point is to do the operation in-place, rp[-2] may
On 2018/07/10 17:49:33, dak wrote:
On 2018/07/10 17:10:53, benko.pal wrote:
> LGTM; just by looking I can't see how it can make make fail.
> using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to
me, but
> YMMV.
Since the whole point is to do the operation in-pla
https://codereview.appspot.com/357760043/diff/20001/make/lilypond-book-rules.make
File make/lilypond-book-rules.make (right):
https://codereview.appspot.com/357760043/diff/20001/make/lilypond-book-rules.make#newcode33
make/lilypond-book-rules.make:33: mv $@ $(outdir)/$*.tmp.pdf
This appears to
On 2018/07/14 08:22:49, trueroad wrote:
Unfortunately, we cannnot specify an output filename for LaTeX.
I thought -jobname works for that. It also affects all temporary files,
however.
https://codereview.appspot.com/357760043/
___
lilypond-devel
Reviewers: thomasmorley651,
https://codereview.appspot.com/363740043/diff/1/lily/prob.cc
File lily/prob.cc (right):
https://codereview.appspot.com/363740043/diff/1/lily/prob.cc#newcode36
lily/prob.cc:36: equality; e.g., that two probs are equal iff they can
be
On 2018/07/27 09:32:55, thomasmorl
Reviewers: lemzwerg,
Message:
On 2018/08/03 03:24:40, lemzwerg wrote:
LGTM. I suggest that you do such trivial clean-ups directly in the
git
repository, not wasting your time with setting up an issue.
If Han-Wen did not see fit to remove the line but instead went to the
trouble of adding a
On 2018/08/03 08:25:32, hanwenn wrote:
LGTM
Thanks. For the record, I am currently renaming get_property and
set_property for grobs since I want to change their internals in a
manner not compatible with the existing get_property macro (which does
not get to know what kind of class it is being
Reviewers: Dan Eble,
https://codereview.appspot.com/363750043/diff/1/lily/include/lily-guile-macros.hh
File lily/include/lily-guile-macros.hh (right):
https://codereview.appspot.com/363750043/diff/1/lily/include/lily-guile-macros.hh#newcode95
lily/include/lily-guile-macros.hh:95: value;
I'd use scm_func_cast (actual_func)
in order to mimic what reinterpret_cast does, but the implementation
looks awfully heavy-handed and GCC-8 specific.
Any chance that an implementation via a double cast (with something like
void * in between) will work? Strictly speaking that's worse than
casti
Does not help with the other problems we had with fontsize mismatches
(out of multiple calls of set-global-staff-size), right?
What would a correct solution look like?
https://codereview.appspot.com/341450043/
___
lilypond-devel mailing list
lilypond-
On 2018/08/13 12:29:46, Dan Eble wrote:
On 2018/08/13 07:11:38, dak wrote:
> I'd use scm_func_cast (actual_func)
I'll do that.
> Any chance that an implementation via a double cast (with something
like void
*
> in between) will work? Strictly speaking that's wors
le-word sentence that definitely makes more sense than
"\abs-fontsize."
I'll see to it, thanks.
Apart from that: I just wonder if there's another possibility to
change
output_scale other than by #set-global-staff-size. If so, as DAK
implied, we'd
better go for a more co
On 2018/08/14 02:12:59, Dan Eble wrote:
Compile with -Wno-cast-function-type
Sorry for noticing this late in the game, but one thing worth noting
here is that in Guile 1.8 the comments would appear to indicate that we
are defining scm_t_subr ourselves in lily/include/lily-guile-macros.hh
as
/*
201 - 300 of 1900 matches
Mail list logo
