Re: convert-ly 2.17.6 does nothing

[Federico Bruni]

Il 17/11/2012 14:58, Noeck ha scritto:
> Thanks, but that's not directly the problem, because it doesn't occur
> with the lilypond version from the package repositories (ubuntu).
> So "which" surely points me to that one installed in /usr/bin. But the
> other two installations don't work.
>
> I looked at it a bit more closely and there are some things I don't
> understand:
>
> I have three versions 2.14 (from the repository), 2.16 and 2.17 (from
> the website):
>                 2.14            2.16            2.17
> installed in    /usr/bin        /home/.../sw/lilypond2.1x
> convert-ly      is a py-script  is a link to lilypond-wrapper.python
>
> This lilypond-wrapper then calls another convert-ly, which is then a
> python script.
>
> This led me to the conclusion that the "executables" in bin cannot be
> used in Frescobaldi, but the ones in lilypond/usr/bin have to be used.
> But that doesn't work either.

Just convert-ly of 2.17.x is not working in Frescobaldi.
If I use v2.17.7, I can compile scores but I can't update the input in 
Frescobaldi (while the terminal works).

It seems that Frescobaldi cannot run convert-ly, that's why it tells 
that the document has not been changed and the Ok button is greyed out.

I have no idea why this happens.

Maybe this recent change in convert-ly.py requires some change in 
Frescobaldi code:


commit 91f8d0ab0bfbd603b8f7801ef9f5c03529cbfa66
Author: Julien Rioux <address@hidden>
Date:   Fri Oct 5 18:09:48 2012 -0400

    convert-ly: Don't update \version when no rule is applied.

    Note that this is not the same as what the existing -d
    --diff-version-update command does. The behavior of convert-ly is
    unchanged when rules are being applied, and -d is still used in the
    same way. The change concerns itself only with the case that no rule
    applies, because the version of the file is already up-to-date. In
    this case, it used to be that the version in the file would be set to
    version of the last rule, which would sometimes mean that the version
    of the file upon output is lower than the version at input. This is
    what we avoid in this patch.

    This fixes issue 2670.