lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convert-ly rule for beams


From: address@hidden
Subject: Re: convert-ly rule for beams
Date: Mon, 17 Oct 2011 09:54:56 +0200

On Oct 17, 2011, at 9:11 AM, David Kastrup wrote:

"address@hidden" <address@hidden> writes:

Hey all,

Before I push the beam slope patch, I wanted to touch base regarding
convert-ly rules for it so I avoid the problems I ran into with flags.
In this patch, I am eliminating several Scheme callbacks (but not the
properties for which these callbacks are used - namely, the positions
property for Beam).

Would the elimination of callback functions count as a change in input
syntax?  My crude understanding of what "syntax" means says no, but
I'd rather err on the side of caution.  If a rule needs to be written,
I'll write a NOT_SMART rule for the defunct functions.

IIRC, convert-ly did not forage into Scheme.  If you remove the
functions, is it because they stopped doing something useful?


It's not that the functions didn't do useful things (ly:beam::calc-least-squares-positions, ly:beam::slope-damping, ly:beam::shift-region-to-valid), but rather they require tons of code duping for the calculations when consistent-broken-slope is set to #t in http://codereview.appspot.com/4961041.  Even in their current form they have a fair bit of code duping.  Furthermore, it seems that everywhere in the code, all of these functions were chained together before beam-quanting.  There was/is nothing justifying their separate utility - in fact, their separateness was the cause for one bug (disagreements over common refpoints for collision grobs in beam quanting) that 4961041 fixes as a happy side effect.  So, for all these reasons, I rolled all of these functions into the Beam_scoring_problem class as methods.

Anyway, if previously working code now fails complaining about undefined
functions, it might be worth mentioning in an obvious place where the
offended user might look first.

changes.tely?  Or is that too user-level?


changes.tely makes sense - I doubt any developer will have any doubt about where these functions went, as they exist in the same part of beam-quanting.cc but are not callbacks anymore.

Cheers,
MS

reply via email to

[Prev in Thread] Current Thread [Next in Thread]