lilypond-user
[Top][All Lists]
Advanced

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

Re: adding to the LSR


From: Carl D. Sorensen
Subject: Re: adding to the LSR
Date: Tue, 28 Apr 2009 21:24:36 -0600



On 4/28/09 4:42 PM, "Jonathan Kulp" <address@hidden> wrote:

> Carl D. Sorensen wrote:
>>>> 
>>> Thanks for the offer, Chip.  I've just finished a preliminary run
>>> through all of the snippets.  I downloaded the tarball of the entire
>>> repo and ran them through the convert-ly script, then did a looping
>>> script that ran lilypond on each updated snippet using 2.12.2 and saved
>>> the terminal output for each in a text file.
>> 
>> Cool -- I didn't know you were up enough on scripting to do that kind of
>> work!  I think such a script should be added to scripts/auxiliar so that we
>> have it to use the next time we want to do an update.  (And you just
>> demonstrated that you have two of Larry Wall's attributes of a good
>> programmer: laziness and hubris.  Good for you!)
>> 
> 
> This was a very simple script.  I learned a good bit of scripting with
> the help of Patrick Horgan a while back when I was writing my lily2image
> script.  Here's the script for any interested folks (first I did
> "convert-ly -e *.ly" on the whole directory):
> 
> #!/bin/bash
> 
> #*****************************************#
> # Run Lilypond on a lot of files and save #
> # the terminal output in text files       #
> #*****************************************#
> 
> for LILYFILE in *.ly
> do
>    STEM=$(basename "$LILYFILE" .ly)
>    echo "running $LILYFILE..."
>    lilypond --format=png "$LILYFILE" >& "$STEM".txt
>    rm "$STEM".ps
> done
> 
> ---------------------------
> 
> I chose png format b/c the ristretto image viewer on xubuntu allows for
> very quick paging through all of the images in a directory, much quicker
> than going through a bunch of pdfs.
> 
> After running the script on the directory with all the snippets in it, I
> run this command to find snippets that didn't compile:
> 
>    grep failed *.txt
> 
> It reads the terminal output from all the files and brings back the ones
>   that failed.

Cool!  I still think that you ought to put it all (including the grep part)
into a single script and store it in the source tree.  And it ought to be
added to the CG so that we have it tracked for the next time we release a
stable version (I assume it will happen quickly, once Graham gets home from
Singapore -- although maybe going to Scotland doesn't qualify as "home").

> 
>>> The results were pretty good, really.  About 95% of the snippets
>>> compiled and look the same as they did in 2.10.  Two snippets didn't
>>> compile at all, but I've already taken care of one of them
>>> (adding-octaves-automatically) because I've had to fix that one on some
>>> of my own files before.  The convert-ly script took the \octaves command
>>> as if it were an octave check instead of a user-defined macro.  I've
>>> changed the \octaves command in the original LSR code to \makeOctaves,
>>> which will survive the convert-ly update intact.
>> 
>> This probably also indicates a need to change the convert-ly rule for
>> \octave.  If it doesn't work for \octaves, it also wouldn't work for
>> \octaveAdjustFunction, or some other user-defined variable that starts with
>> \octave.  This should be either fixed or added to the issue tracker to get
>> fixed.
>> 
> 
> Yes, I was thinking the same thing but I don't know how to change the
> convert-ly rules.  It was easier for me just to change \octaves to
> \makeOctaves.

Any Frog willing to take on this convert-ly rule fix?  You have a file that
you can use to see if you have fixed the rule.

> 
> 
>> There are also some snippets that work but should be changed to reflect
>> changes in 2.12.  I know of two snippets that have to do with lead sheets
>> (Chords, Fret Diagrams, melody, and lyrics) that should be changed to use
>> \predefinedFretboards and a FretBoards context, instead of using \markup
>> \fret-diagram.
>> 
>> I'm not sure if there are others.  There may be one related to auto-beaming.
>> I'm not sure what a good process on this is, but I think at a minimum, we
>> should look at NEWS for 2.12 and see if there are any NEWS items related to
>> each of the snippets.
>> 
>> That's why I estimated 15 minutes per snippet (I wasn't thinking of
>> automation, which I should have).  We should check each of the snippets and
>> see if the snippet is made obsolete or should be changed to reflect new
>> features added, not just check to see if the syntax is right.
>> 
> 
> Yes, to do it properly we'll need to examine each one more carefully.
> My idea with this is simply to find out which snippets are broken in
> 2.12 and get them at least to compile, so that the LSR could be switched
>   to 2.12 and then the snippets can be checked out more carefully after
> that.  Is that a good strategy?

No, it's a *great* strategy.  Get the easy work done quickly, so there's
nothing us keeping from moving the LSR, then do the careful work at our
leisure.

Thanks for taking the lead on this.

Chip, are you still willing to do some work reviewing the converted
snippets?

Carl





reply via email to

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