anymore for anymore?
http://codereview.appspot.com/4273125/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
anymore for anymore?
http://codereview.appspot.com/4273125/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
From: d...@gnu.org
Personally, I think that an association with some respective
higher
context (aka inheritance) is such a common type of operation that
we
should rather try thinking about how to provide a general
mechanism for
this kind of thing rather than a one-shot special mechanism just
LGTM
http://codereview.appspot.com/4273125/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Apr 01, 2011 at 09:06:03AM -0700, Mark Polesky wrote:
Even if the discussion is fresh on the mailing
list, if you're starting a new thread, leave some
breadcrumbs. Someone from the outside wanting to help out
will be able to jump in more easily.
Yes. I just spent 2 weeks doing only
Reviewers: ,
Message:
Quick-n-dirty fix for segfault in issue 1585.
Cheers,
MS
Description:
Fixes segfault in beam quanting.
Please review this at http://codereview.appspot.com/4339047/
Affected files:
M lily/beam-quanting.cc
Index: lily/beam-quanting.cc
diff --git
maybe it should be unquanted_x instead? The output doesn't look like
anything remotely resembling the test case:
\version 2.13.56
{
\override Voice . NoteHead #'stencil = ##f
\repeat unfold 4 { d16 }
}
http://codereview.appspot.com/4339047/
___
There is no unquanted_x - the x span is calculated earlier upstream, and
the quanting acts purely on y values.
My guess is that Lily does not know how much room to put between stems
and just kinda gives up. If you look at:
{
\override Voice . NoteHead #'stencil = ##f
\autoBeamOff
\repeat
http://lsr.dsi.unimi.it/LSR/Snippet?id=445
I think it is impossible to have it working [ both in relative and
absolute mode]
i presume all possible tricks have been tried to achieve this!?
Well, here is a version of \makeOctaves, that seems to work in both relative
and absolute mode. It
Gilles THIBAULT wrote:
http://lsr.dsi.unimi.it/LSR/Snippet?id=445
I think it is impossible to have it working [ both in relative and
absolute mode]
i presume all possible tricks have been tried to achieve this!?
Well, here is a version of \makeOctaves, that seems to work in both
Ok, now that any doubts about my meta-april fool's joke are over,
I'd like to sound out opinions about 2.14.
GOOD NEWS
I think we've finally resolved our technical debt -- it's been a
while since I've seen Critical issues that were introduced over a
year ago. The remaining Critical issues are
On Sat, Apr 2, 2011 at 3:34 PM, mts...@gmail.com wrote:
Quick-n-dirty fix for segfault in issue 1585.
While this fix is prudent (I'd add a programming_error as well), it
does feel like a kludge. The only way there could be no
configuration at all is when generate_quants() rejects all of them
On Sat, Apr 2, 2011 at 10:37 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
Quick-n-dirty fix for segfault in issue 1585.
While this fix is prudent (I'd add a programming_error as well), it
does feel like a kludge. The only way there could be no
configuration at all is when
On Apr 2, 2011, at 21:49, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Sat, Apr 2, 2011 at 10:37 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
Quick-n-dirty fix for segfault in issue 1585.
While this fix is prudent (I'd add a programming_error as well), it
does feel like a kludge. The
On Sat, Apr 02, 2011 at 10:06:43PM -0400, m...@apollinemike.com wrote:
Weird...I'm not sure why ours would segfault in one place whereas yours
would hit an assertion error in another.
Well, I didn't enable debug stuff in configure, so I'm certain why
*I* didn't see any assertion errors.
15 matches
Mail list logo
