lilypond-user
[Top][All Lists]
Advanced

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

Re: Evolutionary User Strategery


From: Erik Sandberg
Subject: Re: Evolutionary User Strategery
Date: Mon, 10 Jul 2006 20:08:27 +0200

On 7/10/06, Fairchild <address@hidden> wrote:
Erik -

Thanks for contributing to this thread.  It is attempting to deal with an
important unresolved issue: seamless evolutionary transitioning of ly files.

Your suggested solution requires "n" versions residing entirely in the
user's machine, which would, as you point out, increase resident code by a
factor of "n".  The code switching option requires parallel code only for
features that are interpreted differently for different versions, only
marginally increasing the size of the newer versions - far less size, and
hassle, than retaining several versions.

Different lily versions use different data structures and interfaces internally.

If we would have n different versions of e.g. each engraver, and the
interface between iterators and engravers would change a tiny bit
(which it does now and then), then we would need to update n different
versions of each engraver, which is n times as much work as now; it
would also mean n times more testing, and n times more bugs. Keep in
mind also that the .ly grammar changes between versions, so you will
need to have a separate parser for each version.

That said, you are of course welcome to write a patch that makes lily
2.9 support 2.4 files. My guess is that Han-Wen won't accept the
patch, but if you really want the feature you can always fork the
lilypond project, and start a lilypond-legacy project.

BTW, if you're concerned about the extra size consumption that it
requires to have n different versions, you could consider compressing
your file system. If there is much code in common between lily
versions, then a smart compression algorithm might detect this and
reduce the extra space consumed.

Erik




reply via email to

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