On Tue, May 22, 2012 at 9:07 AM, Urs Liska
<address@hidden> wrote:
Hi David N,
Recently we experienced strange crashes in our Lilypond scores that could only be avoided by randomly changing the order of some function calls.
Now I sat down and pinned it down quite narrowly:
If I use your wonderful \shape function and afterwards override any property of the same grob it causes Lilypond to crash while 'creating systems'.
Attached you'll find a file with detailed observations.
My impression is that your function somehow messes up with the grob's variable/pointer or whatever, making a copy and not telling Lilypond or such kind of thing.
Anyone an idea what could be wrong here?
It doesn't make the function unusable (not at all), but it can cause very dubious errors that might be very hard to track (depending on the situation).
The problem happens when the variable "function" attempts to look up the procedure for 'control-points. Each override you do is tacked onto the front of the alist and so the key we're looking for-- 'control-points -- is pushed further back. You can see what I mean by changing cdr in the assignment for function (line 20?) to cddr for one override, cdddr for two overrides... This will "fix" the problem--provided the overrides come after \shape ... (The reason why cdr is used in the first place is that the current override of 'control-points would be there at the head of the list, and you'd get "calculation-in-progress" instead of ly:slur::calc-control-points or whatever.) I'll think about how to fix this and get back to you.
Thank you for noticing this!!
-David
Best
Urs
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user