Re: DurationLine avoiding RehearsalMarks

[Thomas Morley]

Am Di., 12. Apr. 2022 um 12:34 Uhr schrieb Jean Abou Samra <jean@abou-samra.fr>:
>
> Le 12/04/2022 à 11:35, Thomas Morley a écrit :
> > Hi Jean,
> >
> > this one is about codings
> >
> > Am Mo., 11. Apr. 2022 um 18:04 Uhr schrieb Jean Abou Samra 
> > <jean@abou-samra.fr>:
> >
> >>>> How about adding a Scheme interface for 
> >>>> Axis_group_interface::staff_extent
> >>>> from lily/axis-group-interface.cc and using it in duration-line::print?

> > I would love to have it available as 
> > ly:axis-group-interface::selective-extent.
> > Though, I hesitate to upload a patch with the code below: it's your work!
>
>
>
> Well, there hasn't been agreement about adding Scheme interfaces that
> aren't used in the code base,

I know and I regret.
For me predefined functions are a toolchain for my own codings, and
some of them end up in patches...
If a so far not used tool is missing, i.e. present in C++, but not
available in scheme, I need to create it from scratch, if I'm able to
do so, and sometimes I'm not.

> so I hesitate to upload it alone ... If
> you use it in a patch, feel free to put it in a separate commit attributed
> to me (git commit --author="Jean Abou Samra <jean@abou-samra.fr>" ...).

Ok, currently it depends upon the final sollution for problem with
DurationLine whether I'll use your code or not.
Though, I seem to remember I had a similar problem some time ago where
it would have been helpful.

>
> > And a I have a small understanding problem:
> >
> >> diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc
> >> index ede8e9686c..a7ad87791c 100644
> >> --- a/lily/axis-group-interface.cc
> >> +++ b/lily/axis-group-interface.cc
> >> @@ -256,6 +256,25 @@ Axis_group_interface::staff_extent (Grob *me, Grob
> >> *refp, Axis ext_a, Grob *staf
> >>      return relative_group_extent (new_elts, refp, ext_a);
> >>    }
> >>
> >> +MAKE_DOCUMENTED_SCHEME_CALLBACK (Axis_group_interface,
> >> selective_extent, 5,
> >> +                                 R"(
> >> +Return the combined extent of elements from @var{grob} on @var{axis}
> >> +relative to @var{refpoint}.  Only retain those elements that are children
> >> +of @var{staff} on @var{parent-axis}.
> >> +                                 )");
> >> +SCM
> >> +Axis_group_interface::selective_extent (SCM grob, SCM refpoint, SCM
> >> axis, SCM staff, SCM parent_axis)
> >> +{
> >> +  auto *const g = LY_ASSERT_SMOB (Grob, grob, 1);
> >> +  auto *const r = LY_ASSERT_SMOB (Grob, refpoint, 2);
> >> +  LY_ASSERT_TYPE (is_scm<Axis>, axis, 3);
> >> +  Axis a = from_scm<Axis> (axis);
> >> +  auto *const s = LY_ASSERT_SMOB (Grob, staff, 4);
> >> +  LY_ASSERT_TYPE (is_scm<Axis>, parent_axis, 5);
> >> +  Axis pa = from_scm<Axis> (parent_axis);
> >> +  return to_scm (staff_extent (g, r, a, s, pa));
> >> +}
> >> +
> >>    MAKE_SCHEME_CALLBACK (Axis_group_interface, calc_pure_relevant_grobs, 
> >> 1);
> >>    SCM
> >>    Axis_group_interface::calc_pure_relevant_grobs (SCM smob)
> >> diff --git a/lily/include/axis-group-interface.hh
> >> b/lily/include/axis-group-interface.hh
> >> index 46f3369c05..4300e9a60a 100644
> >> --- a/lily/include/axis-group-interface.hh
> >> +++ b/lily/include/axis-group-interface.hh
> >> @@ -47,6 +47,7 @@ public:
> >>      DECLARE_SCHEME_CALLBACK (calc_pure_staff_staff_spacing, (SCM, SCM,
> >> SCM));
> >>      DECLARE_SCHEME_CALLBACK (calc_pure_relevant_grobs, (SCM));
> >>      DECLARE_SCHEME_CALLBACK (calc_pure_y_common, (SCM));
> >> +  DECLARE_SCHEME_CALLBACK (selective_extent, (SCM, SCM, SCM, SCM, SCM));
> >>      static SCM internal_calc_pure_relevant_grobs (Grob *, const
> >> std::string &);
> >>      static Interval relative_group_extent (std::vector<Grob *> const 
> >> &list,
> >>                                             Grob *common, Axis);
> >> @@ -72,4 +73,3 @@ public:
> >>    };
> >>
> >>    #endif /* AXIS_GROUP_INTERFACE_HH */
> >> -
> > Why is below needed?
> >
> >> diff --git a/lily/include/lily-guile-macros.hh
> >> b/lily/include/lily-guile-macros.hh
> >> index 59fdd9c497..1842d70bc8 100644
> >> --- a/lily/include/lily-guile-macros.hh
> >> +++ b/lily/include/lily-guile-macros.hh
> >> @@ -120,6 +120,12 @@ struct ly_scm_func_of_arity<4>
> >>      typedef SCM (*ptr_type) (SCM, SCM, SCM, SCM);
> >>    };
> >>
> >> +template <>
> >> +struct ly_scm_func_of_arity<5>
> >> +{
> >> +  typedef SCM (*ptr_type) (SCM, SCM, SCM, SCM, SCM);
> >> +};
> >> +
> >>    /*
> >>      Make TYPE::FUNC available as a Scheme function.
> >>    */
>
>
> Scheme macros are very powerful: they manipulate source expressions,
> which are plain data (lists of symbols, strings, numbers, etc.), so
> they can do any sort of programming on what they are fed with. (Modern
> Scheme even has lexically scoped macros with syntax-rules/syntax-case,
> see !1273.) C++ on the other hand has a very different macro story:
> a macro is a simple textual transformation -- think writing code with
> (format #f ...). The MAKE_SCHEME_CALLBACK macro takes an integer
> number of arguments, in this case 5, and needs to construct the function
> signature (SCM, SCM, SCM, SCM, SCM), where there are as many SCMs as
> the integer (here, 5). This isn't possible to do just with literal
> string templates, so the macro uses
>
> ly_scm_func_of_arity<5>::ptr_type
>
> where ly_scm_func_of_arity manually defines
> ly_scm_func_of_arity<0>::ptr_type -> (),
> ly_scm_func_of_arity<1>::ptr_type -> (SCM), ly_scm_func_of_arity<2> ->
> (SCM, SCM),
> etc. This is all manual. Up to now, there had never been a need for
> 5-argument Scheme callbacks, so the ptr_types were only defined up
> to 4.
>
>
> >> What do you mean with:
> >> (with whatever name: staff-extent, selective-extent, etc.)
>
>
> I mean that there are lots of options for naming the function:
> ly:axis-group-interface::staff-extent,
> ly:axis-group-interface::selective-extent,
> ly:axis-group-interface::extent-on-staff,
> ...

Many thanks for the detaild infos!

>
> > Probably unrelated:
> > ly:relative-group-extent accepts a grob-list, but errors if an empty
> > list provided.
> > Would it be feasible not to error but to return an empty-interval or '(0 . 
> > 0)?
>
>
>
> Ouch, it definitely shouldn't error.
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1306
> makes it return the empty interval. (I think that's the best choice,
> as the union of 0 intervals is empty and "ly:relative-group-extent"
> doesn't have "robust" in the name like "ly:grob-robust-relative-extent".
> It is also what the C++ function already does).

Already seen it. Many thanks again!

Best,
  Harm