[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Music function in LY file triggers error message
From: |
David Kastrup |
Subject: |
Re: Music function in LY file triggers error message |
Date: |
Sat, 13 Feb 2021 15:21:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Johannes Feulner <johannes.feulner@scorio.com> writes:
> 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?
I'd consider them deprecated. The code implemented to support them does
so based on some heuristics. And they no longer convey meaning to any
#{...#} inside: previously something like
\version "2.23.1"
myFunc =
#(define-music-function (location parser m)
#{ #m #})
exploded round your ears since #{...#} implicitly relied on "parser"
being set to, well, the parser value. But #{...#} nowadays instead gets
its information via the %parser and %location fluids.
So unless you don't know what version of LilyPond will parse your code,
I'd strongly suggest omitting them. In particular, code preceded by
\version "2.23.1"
is more or less defined to not require their use.
When the function actually needs parser/location, it makes more sense to
get them via (*parser*) and (*location*) in almost all cases.
--
David Kastrup