bug-lilypond
[Top][All Lists]
Advanced

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

Re: Music function in LY file triggers error message


From: Jonas Hahnfeld
Subject: Re: Music function in LY file triggers error message
Date: Sat, 13 Feb 2021 18:18:15 +0100
User-agent: Evolution 3.38.3

Am Samstag, dem 13.02.2021 um 14:58 +0000 schrieb James:
> On Sat, 2021-02-13 at 13:29 +0100, Johannes Feulner wrote:
> > HI there,
> > 
> > updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected 
> > non-fatal error messages in LilyPonds output whenever a music
> > function 
> > is defined:
> > 
> > Analysieren...
> > Programmierfehler: Parsed object should be dead #<Prob: Music C++: 
> > Music((void . #t))((name . Music) (types)) >
> > 
> > This happens even if a defined music function is never called.
> > 
> > Minimal example:
> > 
> >     \version "2.23.1"
> >     myFunc =
> >     #(define-music-function (parser location m)
> >        (ly:music?)
> >        m)
> > 
> > By the way: Are parser and location though no necessary anymore 
> > deprecated/still allowed/make sense/bad style?
> > 
> > Cheers,
> > 
> > Johannes
> > 
> 
> I saw the other replies ... but just because I took the time ...
> 
> git bisect gives me this:
> 
> --snip--
> 
> 78225bc1b386e12dc1d03a5d2c7a017c0a52a22d is the first bad commit
> commit 78225bc1b386e12dc1d03a5d2c7a017c0a52a22d
> Author: Valentin Villenave <valentin@villenave.net>
> Date:   Mon Jan 14 19:02:13 2019 +0100
> 
>     Chord names clean-up; no more Banter, exceptionsPartial or
> \powerChords.

A couple of notes:
First the programming errors will only appear with --enable-checking
which you shouldn't have for production builds. Second as discussed in
https://gitlab.com/lilypond/lilypond/-/issues/6079 this warning may
trigger for any file with variables that produce one of the object
types that should be gone after parsing. Third, and most importantly,
the warning was incorrect until recently in a sense that it would only
trigger sometimes. Which also means that the bisection probably didn't
work as expected because deciding good/bad before Han-Wen's fix was
more or less a random function. In any case, I don't think Valentin's
commit has anything to do with it...

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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