"[email protected]" <[email protected]> writes: > On Apr 3, 2012, at 1:10 PM, Phil Holmes wrote: > >> >> We need to check what the script is doing and how it responds to >> failing snippets like this. I'm not in a position to do this right >> now, but let's not forget it's there. I've put it on the tracker as >> http://code.google.com/p/lilypond/issues/detail?id=2466 >> > > It's also important to establish if this is a critical regression or > not. The snippet dug into the bowels of LilyPond and used lots of > functionality that's not put into play often. So its failure to > compile may be pointing to an unexposed regression. Perhaps it'd be > wise to label this as critical now and then downgrade it once we > confirm that the compilation failure isn't coming from anything > directly involved in running the LilyPond executable.
There are things like bleedover. See <URL:http://code.google.com/p/lilypond/issues/detail?id=2449> for one example where a "user interface" was added that results in changes affecting the entire rest of a multi-file session. If a later snippet relies on a define-event-class in an earlier snippet, bleedover will make this reach into further sessions. git grep define-public Documentation/snippets returns several snippets that _export_ definitions (I have not checked whether this means that they will spill over, but I would not be surprised if it did). Any snippet that reaches into the bowels of LilyPond causing a _permanent_ change there surviving beyond the session is a mistake. It is possible that here one snippet depends on another snippet. What are the error messages in this particular case? -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
