On 2024-11-19 14:57, David Wright wrote:
On Tue 19 Nov 2024 at 09:05:00 (-0800), Stu McKenzie wrote:
Reply to David Wright (et al):
On 2024-11-18 10:40, Stu McKenzie wrote:
[ recapitulation of OP snipped ]
In reply to your post:
It's typical that an error occurs before the "outdated" message
is issued. But your OP reads as if the message appeared out of
the blue, without any previous error having occurred. Is that
correct, and if not, what was the error that you didn't report?
The above [snipped] is the original post that I sent.
My original score was complicated, so I came up with the post that you
replied to (with 1 error and the message).
The message "Note: compilation failed and \version outdated, did you
update input syntax with convert-ly? ", was the only message that was
reported to that score.
OK, out of the blue then. I've not had that happen to me, and don't
know why it would occur without at least a warning about the syntax
that provoked it.
Posts can get a bit out of context when read separately, but many
users seem to prefer to do that (including myself).
I'm trying to solve my original issue, which was that I couldn't
determine which \include caused the error message in my original
score.
In your OP, you found the direct source of the message itself in
lily-library.scm. (The other hits were the derived .go version,
and the copies in the translation .mo files.) The function that
causes the message appears to be suggest-convert-ly-message.
If you then look at ly/init.ly, you can see:
((ly:parser-has-error?)
(suggest-convert-ly-message version-seen)))
which would appear to show that if the parser has seen any error
anywhere in the input files, it will emit your message at the end.
Bearing in mind that the parser (and everything else in LP, it seems)
doesn't stop unless an error is fatal, but grinds on as best it can
to the end, there's no easy way of telling where the error was,
unless it emits its own diagnostic message.
I was hoping that someone who knows the internals of LilyPond would
suggest that the source code could be changed to identify which file
and line was causing the error.
Maybe there's someone out there who can help?
My methodology would be the same as for generating a MWE: excising
entire include files, or parts thereof, while tracking whether the
failure message still appears, in order to localise where the
problem lies.
Cheers,
David.
Thanks for your reply David.
Due to having to get other scores done, I've had to leave that one for now.
I'll return to it on another day, and try removing includes one at a
time to see if I can isolate the problem.
