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.
Marginally increasing the single package size is not a concern. Through the
generations, memory and speed have increased to accommodate applications -
or maybe the other way around. The first computer I used had 2000
bi-quinary ten-digit words on a drum. Long-term memory was punched cards.
It was a fantastic improvement over its predecessor, the Card Programmed
Calculator.
Increasing processing time is a consideration, but testing a flag to select
from version-specific code segments would be barely measurable.
- Bruce
-----Original Message-----
From: Erik Sandberg [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 3:12 AM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
On 7/9/06, Fairchild <[EMAIL PROTECTED]> wrote:
> New scores could use new features and not have to work around the bugs
> of earlier versions. Older scores that have been carefully tuned,
> compensating for earlier bugs, would continue to produce the intended
> result without having to be overhauled. There would be no need to
> maintain multiple versions.
This basically implies that all old versions of lily must be included in the
new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6
and 2.4. Which means that the lilypond package grows by a factor 4. I think
a better solution would be that you create a script locally, which parses
the input ly file, reads the \version statement, and picks which lilypond
version to use to compile your ly file.
Erik
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
