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.
