Re: Integration of Guilev2 branches into master

[Thomas Morley]

Am Mo., 10. Feb. 2020 um 12:40 Uhr schrieb David Kastrup <address@hidden>:
>
> 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.

'setlocale' catched my eyes, hopefully below is not too much off-topic

Sometimes users name their files surprisingly. Thus for testings I use
two files both containing nothing else than:

%%%%%
file-name = #(ly:parser-output-name)

\header {
  title = \file-name
  subtitle = $(lilypond-version)
}

\markup \file-name

{ b^#(make-line-markup (list file-name)) }
%%%%

One is called 'filename.ly' the other 'filename_名字♯.ly'

Observations
(1)
With 2.19.84 both files are found and compiled.
'filename_名字♯.ly' needs approx double time for compilation, though.

(2)
A guile-2 build from current master is unable to find the file.
warning: cannot find file: `filename_?????????.ly'
fatal error: failed files: "filename_?????????.ly"

This is not new, thus I'm used to put in the attached patch, setting
locale to help ly:load
The file 'filename_名字♯.ly' is found now and compiled.
Alas, now the compilation time of 'filename.ly' is approx x4 (not surprising)
And the timing for 'filename_名字♯.ly' is approx shocking x16 (with a
huge halt at 'Layout output to ...'-stage)
Both compared to 2.19.84

Any way to improve?

Cheers,
  Harm

0002-Initialize-locale-in-lily.scm.patch
Description: Text Data