Re: Integration of Guilev2 branches into master

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>> Han-Wen Nienhuys <address@hidden> writes:
>>
>>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup <address@hidden> wrote:
>>>
>>>> I propose that I am going to pick up the pieces of
>>>> not-actually-formally-reviewed patches making up the bulk of them and
>>>> put them, Guilev2-guarded (so that they don't affect Guilev1
>>>> compilations) into staging->master without going through the formal
>>>> processes.
>>>>
>>>> The reason to do that is that the current state already likely wasted
>>>> considerable time of Han-Wen by finding solutions for problems that were
>>>> already previously turned into non-showstoppers although not necessarily
>>>> in the cleanest manner.  But it would seem that even if part of them is
>>>> likely to eventually be superseded, giving Han-Wen a better starting
>>>> place would make him work and plan more effectively.
>>>>
>>>
>>> Thanks, David!
>>>
>>> Can you mark the commits with some prefix ("GUILE2: blah") so they stand
>>> out?
>>
>> Oh good grief, I remember now.  The commit I sent in the review of yours
>> already had stopped working with some Guile version, and the recommended
>> fix by Guile developers was in a different commit.  Cough cough.
>>
>> Most of the off-branch Guilev2 work was done by Antonio Ospite but
>> without Guilev2 guards and collected by Harm who is not a C++ programmer
>> and thus was not in a position to place guards.  Some of that work is,
>> well, not meant for eternity.
>>
>> Nevertheless, with guards in it, it may still provide a reasonable bit
>> of headstart.

Ok, there are still 3 unmerged patches marked XXX in the (now rebased)
branch dev/guile-v2-work .  They are unmerged because they are marked
XXX .  Here is the list:

commit ad1ff054835fa7940307d9c5bbb7e1b55ee7ebbe (HEAD -> guile-v2-work, 
origin/dev/guile-v2-work)
Author: Antonio Ospite <address@hidden>
Date:   Tue Nov 22 16:25:01 2016 +0100

    XXX reset the locale when building index.html
    
    It looks like resetting the locale is still needed to produce index.html
    
    TO be hones, I am NOT sure if this is needed, it is possible than I had
    a dirty build when I come up with this workaround for a build failure.

commit f3c8caf0cc3576b333d57bde02d939898ba77a02
Author: Antonio Ospite <address@hidden>
Date:   Tue Nov 22 16:25:01 2016 +0100

    XXX don't override LANG globally in the build process
    
    For now lilypond depends on a UTF-8 locale to produce correct results
    when using guile-2.0, so don't override LANG globally to give lilypond
    a chance to use the UTF-8 locale from the environment when building the
    documentation.

commit cc2c1084f24017f1bb6194d46be44099bd19fc7f
Author: Antonio Ospite <address@hidden>
Date:   Tue Nov 22 12:59:14 2016 +0100

    XXX add support for itexi files to the vim config

commit 6970872939f4bb716151645b92762ae4cf9d030d
Author: Antonio Ospite <address@hidden>
Date:   Thu Nov 10 11:17:18 2016 +0100

    XXX Avoid the lockup in ly_scm_write_string
    
    Sometimes when calling ly_scm_write_string (in particular from
    print_scm_val, called by type_check_assignment) the scm_call_2 function
    never returns.
    
    Add a dirty hack to avoid the lockup.


The vim config file actually has nothing to do with Guilev2 as far as I
can see: we should likely make this a regular issue and pass it in that
way.

"Avoid the lockup" is not even a "hack": it just stomps dead some
message call that for unfathomable reasons locks up.  I'd say we stay
away from that until the problem is triggered, then try finding a real
solution.

The build process changes look like a can of worms: if we could make
LilyPond switch itself into an UTF-8 environment reliably without
looking at the actual environment, that would likely be preferable.
Though I am not too sure about it.

When in doubt, cherry-pick one from those (though I'll probably back out
the vim thing soonish from the branch and give it its own issue).

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".