Re: Assertion !is_empty() failed - yet again

[David Kastrup]

Andrew Bernard <address@hidden> writes:

> Thanks David.
>
> I built 2.21.0 on Ubuntu 19.04. Running gdb, sure enough, it's the familiar
> tuple bracket issue:
>
> Drawing systems...lilypond:
> /home/andro/lilypond-git/flower/include/interval.hh:227: T
> Interval_t<T>::center() const [with T = double]: Assertion `!is_empty ()'
> failed.
>
> Program received signal SIGABRT, Aborted.
> __GI_raise (address@hidden) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) backtrace
> #0  0x00007ffff76bfed7 in __GI_raise (address@hidden) at
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff76a1535 in __GI_abort () at abort.c:79
> #2  0x00007ffff76a140f in __assert_fail_base
>     (fmt=0x7ffff782f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=0x55555594ab94 "!is_empty ()", file=0x55555594abb8
> "/home/andro/lilypond-git/flower/include/interval.hh", line=227,
> function=<optimised out>) at assert.c:92
> #3  0x00007ffff76b1012 in __GI___assert_fail
>     (address@hidden "!is_empty ()",
> address@hidden
> "/home/andro/lilypond-git/flower/include/interval.hh", address@hidden,
> address@hidden <Interval_t<double>::center()
> const::__PRETTY_FUNCTION__> "T Interval_t<T>::center() const [with T =
> double]") at assert.c:101
> #4  0x00005555556d93c7 in Interval_t<double>::center() const
> (this=<optimised out>) at
> /home/andro/lilypond-git/lily/include/lily-guile-macros.hh:70
> #5  0x00005555556d93c7 in Tuplet_number::calc_x_offset(scm_unused_struct*)
> (smob=<optimised out>) at /home/andro/lilypond-git/lily/tuplet-number.cc:293
>
> Last time this arose Aaron provided this code for me:
>
>     \override TupletBracket.X-positions = #(lambda (grob)
>    (let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
>      (if (> (car xpos) (cdr xpos))
>        (let ((mid (/ (+ (car xpos) (cdr xpos)) 2)))
>          (format #t "\nwarning: Fixing invalid X-positions ~a" xpos)
>          (cons mid mid))
>        xpos)))
>
> Adding that prints a warning, and works around the issue, and I can,
> thankfully go on.
>
> But since this keeps coming up, is it something that should be reported as
> a bug, so as to eventually get fixed?

I am looking at this code right now and it is not clear to me that
break-overshoot is used consistently.  Its usual settings are something
like

     (break-overshoot ,number-pair? "How much does a broken spanner
stick out of its bounds?")

Examples of this property are
Documentation/ly-examples/cary-layout.ily:    \override Beam.break-overshoot = 
#'(-0.5 . 1.0)
input/regression/beam-outside-beamlets.ly:  \override Beam.break-overshoot = 
#'(-0.5 . 0.5) 
input/regression/spanner-break-overshoot.ly:  \override Beam.break-overshoot = 
#'(1.0 . 2.0)
input/regression/spanner-break-overshoot.ly:  \override 
TupletBracket.break-overshoot = #'(1.0 . 2.0)

so it's sometimes positive, sometimes negative.  The default code in
lily/tuplet-bracket.cc does

      if (connect_to_other[d])
        {
          Interval overshoot (robust_scm2drul (me->get_property 
("break-overshoot"),
                                               Interval (-0.5, 0.0)));

          if (d == RIGHT)
            x_span[d] += d * overshoot[d];
          else
            x_span[d] = (bounds[d]->break_status_dir ()
                         ? Axis_group_interface::generic_bound_extent 
(bounds[d], commonx, X_AXIS)[-d]
                         : robust_relative_extent (bounds[d], commonx, 
X_AXIS)[-d])
                        - overshoot[LEFT];
        }

so the default value is negative which moves the left end of the span to
the _right_ since the left overshoot is subtracted.

The comparable code for beams does

                  if (on_line_bound
                      && me->get_bound (event_dir)->break_status_dir ())
                    {
                      current.horizontal_[event_dir]
                        = (Axis_group_interface::generic_bound_extent 
(me->get_bound (event_dir),
                                                                       commonx, 
X_AXIS)[RIGHT]
                           + event_dir * break_overshoot[event_dir]);
                    }

which again puts in a factor of -1 for the left bound, also using a
default value of -0.5 .

Is this negative break_overshoot (which reduces the extent on the left
side, possibly until the interval becomes empty) as intended or is this
a consequence of confusion?

-- 
David Kastrup