Re: crash running translator

[Jan-Peter Voigt]

Hi David,

wow, thank you!
I will try to follow your explanations soon and read the mentioned code.

Jan-Peter


Am 17.09.2018 um 16:38 schrieb David Kastrup:
> Jan-Peter Voigt <address@hidden> writes:
> 
>> Dear all,
>>
>> I stumbled over something that looks like a bug.
>> If one uses ly:run-translator to process some music a dotted rest
>> crashes lilypond:
>>
>> \version "2.19.82"
>> #(ly:run-translator #{ r2. #} #{ \layout {} #})
>>
>> The error message is:
>> Wrong number of arguments to #<procedure lookup-font (node alist-chain)>
>>
>> Does anybody know a way to circumvent this?
> 
> Well, looking up the definition of ly:run-translator I read:
> 
> LY_DEFINE (ly_run_translator, "ly:run-translator",
>            2, 1, 0, (SCM mus, SCM output_def),
>            "Process @var{mus} according to @var{output-def}.  An"
>            " interpretation context is set up, and @var{mus} is"
>            " interpreted with it.  The context is returned in its"
>            " final state.\n"
>            "\n"
>            "Optionally, this routine takes an object-key to"
>            " to uniquely identify the score block containing it.")
> [...]
> 
> Which makes me barf.  The final paragraph is just gobbledygook.  It
> doesn't help that this mysterious optional object-key is _accepted_ but
> the function signature does not even contain a parameter declaration for
> it.
> 
> Ok, onward.  Running with -dverbose I get
> 
> -*- mode: compilation; default-directory: "/tmp/" -*-
> Compilation started at Mon Sep 17 15:45:07
> 
> lilypond -dverbose gok.ly
> GNU LilyPond 2.21.0
> ]
> ]
> ]
> ]
> ]
> [... we should probably do something about those, dozens more]
> Processing `gok.ly'
> Parsing...
> Interpreting music...Backtrace:
> In unknown file:
>    ?:  0* [lilypond-main ("gok.ly")]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1032:  1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
> 1032:  2* [lilypond-all ("gok.ly")]
> 1045:  3  (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...)
> 1057:  4* [for-each #<procedure #f (x)> ("gok.ly")]
> In unknown file:
>    ?:  5* [#<procedure #f (x)> "gok.ly"]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1059:  6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
> 1070:  7* [lilypond-file #<procedure #f (key failed-file)> "gok.ly"]
> 1105:  8  [catch ly-file-failed #<procedure #f ()> #<procedure #f (x . args)>]
> In unknown file:
>    ?:  9* [#<procedure #f ()>]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1106: 10* [ly:parse-file "gok.ly"]
> In gok.ly:
>    Now it's getting interesting:
> 
>    2: 11* [ly:run-translator # #]
> In unknown file:
>    ?: 12* [# #]
>    ?: 13* [# # #]
>    ?: 14* [#<Callback2_wrapper> #<Translator Dot_column_engraver > #<Grob 
> Rest > ...]
>    ?: 15* [ly:rest::width #<Grob Rest >]
>    ?: 16* [lookup-font #<undefined> ((# # # #) (# # # # ...) ())]
> 
> ERROR: In procedure lookup-font:
> ERROR: Wrong number of arguments to #<procedure lookup-font (node 
> alist-chain)>
> 
> Compilation exited abnormally with code 1 at Mon Sep 17 15:45:08
> 
> Ok, so we have
> SCM
> Rest::width (SCM smob)
> {
>   return generic_extent_callback (unsmob<Grob> (smob), X_AXIS);
> }
> 
> and
> 
> Rest::generic_extent_callback (Grob *me, Axis a)
> {
>   /*
>     Don't want ledgers: ledgers depend on Y position, which depends on
>     rest collision, which depends on stem size which depends on beam
>     slop of opposite note column.
> 
>     consequence: we get too small extents and potential collisions
>     with ledgered rests.
>   */
>   SCM m = brew_internal_stencil (me, a != X_AXIS);
>   return ly_interval2scm (unsmob<Stencil> (m)->extent (a));
> }
> 
> and
> 
> Rest::brew_internal_stencil (Grob *me, bool ledgered)
> {
>   SCM durlog_scm = me->get_property ("duration-log");
>   if (!scm_is_number (durlog_scm))
>     return Stencil ().smobbed_copy ();
> 
>   int durlog = scm_to_int (durlog_scm);
> 
>   string style = robust_symbol2string (me->get_property ("style"), "default");
> 
>   Font_metric *fm = Font_interface::get_default_font (me);
>   string font_char = glyph_name (me, durlog, style, ledgered, 0.0);
>   Stencil out = fm->find_by_name (font_char);
>   if (out.is_empty ())
>     me->warning (_f ("rest `%s' not found", font_char.c_str ()));
> 
>   return out.smobbed_copy ();
> }
> 
> 
> Actually, looking at the traceback it would seem like lookup-font is not
> actually called with the wrong number of arguments but something is
> confused by the first argument being *undefined*.  Which is a value that
> usually is used in the C API for signifying "there isn't a proper Scheme
> value here", so passing it around can lead to surprises.
> 
> This appears to be the problem from
> 
> Font_metric *
> Font_interface::get_default_font (Grob *me)
> {
>   Font_metric *fm = unsmob<Font_metric> (me->get_property ("font"));
>   if (!fm)
>     {
>       SCM chain = music_font_alist_chain (me);
> 
>       fm = select_font (me->layout (), chain);
>       me->set_property ("font", fm->self_scm ());
>     }
> 
>   return fm;
> }
> 
> And likely because of me->layout () being unsuitable.  Or not.
> 
> The problem only occurs with dotted rests.  Maybe the dots rely on work
> being done already by the rest itself but get typeset first?
> 
> I don't really know.  This is sort of as deep as I get right now.
>