Re: retrograding with convert-ly

[David Kastrup]

Colin Hall <address@hidden> writes:

> On Sun, Jul 15, 2012 at 01:47:21AM -0700, Eluze wrote:
>> 
>> 
>> dak-3 wrote:
>> > 
>> > Colin Hall <address@hidden> writes:
>> > 
>> >> On Sat, Jul 14, 2012 at 05:52:09AM -0700, Eluze wrote:
>> >>> 
>> >>> I just applied convert-ly to a file which contained \version
>> >>> "2.15.41" - now the version is "2.15.40"!
>
> That's not what I see with convert-ly version 2.15.41 on Linux x86 and
> Win7 SP2. For both operating systems, the \version string is left
> unmodified. This seems consistent to me, given that there have been no
> changes to the convert-ly rules between versions 2.15.40 and 2.15.41.
>
> http://git.savannah.gnu.org/cgit/lilypond.git/log/python/convertrules.py
>
> Here's the evidence. First, under Windows 7:
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> C:\colin\programs>
> C:\colin\programs>
> C:\colin\programs>more bug.ly
> \version "2.15.41"
>
> C:\colin\programs>"c:\Program Files
> (x86)\LilyPond-2.15.41\usr\bin\convert-ly.py" bug.ly
> convert-ly.py (GNU LilyPond) 2.15.41
>
> convert-ly.py: Processing `bug.ly'...
> Applying conversion:
>
> \version "2.15.40"
^^^^^^^^^^^^^^^^^^^^

You are aware that without the -e option, the file itself is not
modified, but instead the converted output is written to stdout?

> $ more bug.ly
> \version "2.15.41"
>
> $ convert-ly bug.ly
> convert-ly (GNU LilyPond) 2.15.41
>
> convert-ly: Processing `bug.ly'...
> Applying conversion:
>
> \version "2.15.40"
^^^^^^^^^^^^^^^^^^^^^^^^^


> I don't think there is a bug here.

Well, you reproduce the described behavior.  No idea whether to call it
a bug.

-- 
David Kastrup