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 only way there could be no
>> configuration at all is when generate_quants() rejects all of them
>>
>> if (!quant_range[d].contains (c->y[d]))
>>
>> I'm pretty sure using #f leads to infinity being used as a dimension
>> somewhere.
>>
>> I'd suggest not trying #f as stencil callback for noteheads; If the
>> head has no dimension, until where should its stem go?
>>
>
> I'm not sure what failure you guys are seeing. I'm getting warnings
> from the stem code, which does
>
> Real w = hed->extent (hed, X_AXIS)[dir];
>
> and then
>
> lilypond: skyline.cc:111: void Building::precompute(Real, Real, Real,
> Real): Assertion `!isinf (slope_) && !isnan (slope_)' failed.
> Aborted (core dumped)
>
Weird...I'm not sure why ours would segfault in one place whereas yours would
hit an assertion error in another.
You're right that the solution is to not use ##f as a stencil. My logic in
doing so was trying to create up and down headless stems that lined up
horizontally (a transparent notehead shifts these stems by the extent of the
notehead). I realize now that there are other ways to do this, so I changed my
piece. This bug is listed as critical under the assumption that there should be
no segfaults in lilypond resulting from 3 lines of code (lily segfaults all the
time when I accidentally feed her a PDF file instead of a .ly file, but I don't
consider this to be a bug). However, if you feel that it should be downgraded
to high, I could do that as well.
In this case, it seems that the ideal behavior would be to have the stems reach
down to the asymptotic point to which stems converge as their note heads get
smaller and smaller (try overriding the notehead stencil to be progressively
smaller boxes and you'll wee what I mean). I have no clue where in the code
this would need to be implemented, though. I can do this task if no one else
can, but I'm currently slammed w teaching, moving, and composing for a series
of gigs, so if someone else has the hour or two it'd take to propose a
non-kludgy solution (I agree that mine is a kludge), please do!
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
