[Top][All Lists]
[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
- Re: Evolutionary User Strategery, (continued)
- Re: Evolutionary User Strategery, Kieren MacMillan, 2006/07/08
- Re: Evolutionary User Strategery, Erik Sandberg, 2006/07/09
- RE: Evolutionary User Strategery, Fairchild, 2006/07/09
- Re: Evolutionary User Strategery, Kieren MacMillan, 2006/07/09
- RE: Evolutionary User Strategery, Fairchild, 2006/07/09
- Re: Evolutionary User Strategery, Kieren MacMillan, 2006/07/09
- Re: Evolutionary User Strategery, Erik Sandberg, 2006/07/10
- RE: Evolutionary User Strategery, Fairchild, 2006/07/10
- Re: Evolutionary User Strategery, Simon Dahlbacka, 2006/07/10
- RE: Evolutionary User Strategery, Fairchild, 2006/07/10
- Re: Evolutionary User Strategery,
Erik Sandberg <=
- Message not available
- Re: Evolutionary User Strategery, Erik Sandberg, 2006/07/12
Re: Evolutionary User Strategy - A Compromise, Colin Wilding, 2006/07/12
- RE: Evolutionary User Strategy - A Compromise, Anthony Youngman, 2006/07/12
- Re: Evolutionary User Strategy - A Compromise, Erik Sandberg, 2006/07/12
- Re: Evolutionary User Strategy - A Compromise, Simon Dahlbacka, 2006/07/12
- RE: Evolutionary User Strategy - A Compromise, Anthony Youngman, 2006/07/12
- Re: Evolutionary User Strategy - A Compromise, Erik Sandberg, 2006/07/12
- RE: Evolutionary User Strategy - A Compromise, Anthony Youngman, 2006/07/13
- Re: Evolutionary User Strategy - A Compromise, Mats Bengtsson, 2006/07/19
- Re: Evolutionary User Strategy - A Compromise, Erik Sandberg, 2006/07/22