\shape can crash Lilypond
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). Best Urs -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. shapeCanCrash.ly Description: ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \shape can crash Lilypond
Hi Urs, On Tue, May 22, 2012 at 9:07 AM, Urs Liska li...@ursliska.de 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 lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \shape can crash Lilypond
Hi again, 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!! OK, the solution is pretty straightforward: simply replace (function (assoc-get 'control-points (cdr (ly:grob-basic-properties grob with (function (assoc-get 'control-points (reverse (ly:grob-basic-properties grob Crisis averted! :) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \shape can crash Lilypond
Thank you very much! Seems to work perfectly (so far - until we find something new ;-) ) Best Urs Am 22.05.2012 17:28, schrieb David Nalesnik: Hi again, 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!! OK, the solution is pretty straightforward: simply replace (function (assoc-get 'control-points (cdr (ly:grob-basic-properties grob with (function (assoc-get 'control-points (reverse (ly:grob-basic-properties grob Crisis averted! :) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
