Re: [RFC] Automatic 'make check' in CI

[David Kastrup]

Jonas Hahnfeld <hahnjo@hahnjo.de> writes:

> Am Sonntag, den 22.11.2020, 22:49 +0100 schrieb David Kastrup:
>> 
>> To me that seems crazy.  Instead \footnote should not modify the
>> stencil generated from its argument in place.  If it needs something
>> with different dimensions, it needs to create a new stencil, copying
>> the stencil expression and changing the dimensions.
>
> Yes indeed, this seems to be the contract for stencils: Make a copy
> whenever a Stencil is passed in from Scheme.

And/or is not being generated from scratch.

> I managed to find the code path for Balloon grobs that violate this
> rule, here's a fix:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/522 (Note that
> the test case shows that this was already broken before this unstable
> series, at least 2.20.0 but probably older versions too).
>
> If possible, I'd like to merge this rather sooner than later so I can
> finally post the MR to enable 'make check'...
>
>> ly:stencil-set-extent! has been removed in 2.5.17.  Extents are not
>> intended to be mutable as far as I can discern, so if our C++ code
>> does violate that assumption, it is that code we should fix instead
>> of giving up on behavior guaranteed from the Scheme side of things.
>
> In fact, the C++ code does and many methods of the Stencil class modify
> the object, but this is ok as long as we stick to the rule above.

Well, basically the rule should be that as soon as a Stencil is exposed
to the Scheme layer, it is immutable.  Stencils are of type Simple_smob,
so one could stipulate that the result of any call to smobbed_copy () is
off-limits for further modification.  It's not the absolute point after
which things come crashing down, but it's close.

In particular, anything that we access via unsmob<Stencil> should be
considered off-limits for modification.

I have no idea whether there is a sane C++ way of ensuring that
automagically.

> I'd be happy to assert in some way that stencil representations coming
> from Scheme are not altered, but I can't think of a good way to do
> this...
>

-- 
David Kastrup