RE: Evolutionary User Strategery

[Fairchild]

I wonder if the varied opinions represented in this thread are based in
differing interests and ways Lily is used.

The developer's interest is in usability of the latest stable version.

A composer's interest is in an elegant score presentation of a very few
scores, maybe never changing when 'finished'.

I have talent for neither.  I'm attempting to transcribe many public domain
compositions and make many of them publicly available.   A set of such
scores takes me months to years to complete.  I expect to provide both the
ly source and pdf result.  Without upward compatibility, these are obsolete
before they are ready for posting.  Mutopia suffers from such obsolescence.

I also use Lily to transpose published charts for my personal use, finding
ways to improve them as they are used.

So I represent a user quite different from a composer.  Spending time to
repetitively adapt many ly files is overly burdensome.

                                    - Bruce

-----Original Message-----
From: Simon Dahlbacka [mailto:address@hidden 
Sent: Monday, July 10, 2006 10:24 AM
To: Fairchild
Cc: address@hidden
Subject: Re: Evolutionary User Strategery


Bruce, sorry to be rude but:

Being forced to absolute backward compatibility sucks, and having to keep
compatibility with e.g. 2.4 2.6 and 2.8 sucks even more, and makes the code
base bloated, less maintainable and probably a lot of #ifdefs of what not
that leads to more bugs..

Put it another way, you don't want to write your .ly files in such a way
that you can use whatever lilypond version to "compile" them and get a
perfect result. The developers most certainly does not want absolute
backwards compatibility, and they even bother so much as to provide
convert-ly to make the transition forward easier. Whose arguments do you
thing weigh more? Most developers develop lilypond in their spare time just
for the fun of it for all I know..

After all, this is free software, if you like, you can make your own
"compatible-with-everything-even-all-the-bugs" fork project..

/S

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.
>
> 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:address@hidden
> Sent: Monday, July 10, 2006 3:12 AM
> To: Fairchild
> Cc: address@hidden
> Subject: Re: Evolutionary User Strategery
>
>
> On 7/9/06, Fairchild <address@hidden> 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
> address@hidden 
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>