Re: Integration of Guilev2 branches into master

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Feb 8, 2020 at 11:43 AM David Kastrup <address@hidden> wrote:
>
>> 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:
>>
>
> can you push the branch? I can't find some of the sha1s you mention.

Probably because I rebased a few times.  But the branch sticks around.


>> 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
>>
>
> this is changes the texi2html call, so it looks irrelevant for guile2.

Sure: it's complimentary to the next one:

> 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.
>>
>>
> any call that uses the locale settings to change a string conversion is
> wrong within LilyPond, by definition. We should remove them.
>
>
> 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
>>
>
>
> I fixed this in
>
> commit 0f046f4f3398de4b1bcc3f1fdc09b1ba65fcbf8c

Ah, very good.  I'll back out this particular abomination from the
branch then.

>> 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.
>>
>
> Yes, I agree.

It's basically all due to the (setlocale "") call (or what it was) that
switches on the local locale.  If we had any dependable locale name to
put there, we would not need to rely on the external locale being
suitable for utf-8.

Of course it would be even better if we could work with utf-8 internally
but converse externally in the specified locale, but I think that is
likely overoptimistic.

-- 
David Kastrup