David Kastrup <d...@gnu.org> writes:
> David Kastrup <d...@gnu.org> writes:
>> Han-Wen Nienhuys <hanw...@gmail.com> writes:
>>
>>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup <d...@gnu.org> 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 <a...@ao2.it>
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 <a...@ao2.it>
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 <a...@ao2.it>
Date: Tue Nov 22 12:59:14 2016 +0100
XXX add support for itexi files to the vim config
commit 6970872939f4bb716151645b92762ae4cf9d030d
Author: Antonio Ospite <a...@ao2.it>
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".
