Accept GUILE 2 without extra configure options

Accept GUILE 2 without extra configure options

A run of the regression tests at "5f4cf7bd38 - Parse inline scheme
using per-expression port" shows the following issues compared to
GUILE 1.8

* changed interleaving of error and progress messages.

* floating point rounding differences.

* an encoding error in song-basic-nonenglish.ly

As of a19aed1 "GUILE2: Scale GC heap with the number of smobs",
performance for large scores with GUILE 2.2 is similar to GUILE 1.8.

For small scores, a 1.5 sec extra delay (due to byte-code compilation
of .scm files) remains, but this does not warrant the "highly
experimental" monniker.

[hanwenn, 2020-02-21 15:26:52]

guile-config after guile-config2.2

[dak, 2020-02-21 15:43:38]

https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4
File aclocal.m4 (right):

https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4#newcode760
aclocal.m4:760: guile2.2-config guile-2.2-config guile-config-2.2
guile-config2.2 \
I think that at the current point of time, guile1.8-config should be preferred
over guile2.2-config.  The main advantage that Guile2 offers currently is that
it is more likely to be the installed version.  If anybody goes to the pain
these days of actually installing a Guile-1.8 development package, it is pretty
safe to assume that it is for the sake of compiling LilyPond.

Also, I cannot imagine guile-1.9-config to be recommendable for anything (I
mean, it is somewhere between 1.8 and 2.0) and would not look explicitly for it.

Yes, this is old code, but when we touch it in order to update to current
realities, we should update to current realities.

Do we even have comparative speed and memory use measurements of Guile2 for make
all test doc and some large scores?

https://codereview.appspot.com/569390043/diff/551480043/configure.ac
File configure.ac (right):

https://codereview.appspot.com/569390043/diff/551480043/configure.ac#newcode204
configure.ac:204: case "$GUILE_MAJOR_VERSION" in
How is GUILE_MAJOR_VERSION determined?  A cursory read of aclocal.m4 did not
really help.  Guile executable and the Guile development library will not
necessarily be the same version, particularly since more than one Guile
executable can be installed at the same time.

[hahnjo, 2020-02-21 16:02:14]

guile-config since 2.0 has the following comment:
"This script has been deprecated. Just use pkg-config."

Mabye it makes sense to completely turn to pkg-config? My system has $ ll
/usr/lib/pkgconfig/guile-*
-rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
-rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
-rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc

So this would also work for Guile 1.8 (which should either be preferred as David
suggested or completely dropped; not sure if we're already there).

[lemzwerg, 2020-02-21 16:22:52]

> Mabye it makes sense to completely turn to pkg-config?

Sounds sensible.  In particular, it eases cross-compilation.


    Werner

[dak, 2020-02-21 16:25:02]

On 2020/02/21 16:02:14, hahnjo wrote:
> guile-config since 2.0 has the following comment:
> "This script has been deprecated. Just use pkg-config."

It is not something it outputs but rather a script-internal comment.

> Mabye it makes sense to completely turn to pkg-config? My system has $ ll
> /usr/lib/pkgconfig/guile-*
> -rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
> -rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
> -rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc
> 
> So this would also work for Guile 1.8 (which should either be preferred as
David
> suggested or completely dropped; not sure if we're already there).

How does it work?  With GUILE_CONFIG, I pass the executable as an environment
variable.  Admittedly, my non-system-wide Guile-1.8 (Ubuntu no longer has
guile-1.8-dev) contains a file
/usr/local/tmp/guile-1.8/lib/pkgconfig/guile-1.8.pc but I don't have an idea how
to use it.

[hahnjo, 2020-02-21 16:34:35]

On 2020/02/21 16:22:52, lemzwerg wrote:
> > Mabye it makes sense to completely turn to pkg-config?
> 
> Sounds sensible.  In particular, it eases cross-compilation.

Reading my mind ;-)

On 2020/02/21 16:25:02, dak wrote:
> > So this would also work for Guile 1.8 (which should either be preferred as
> David
> > suggested or completely dropped; not sure if we're already there).
> 
> How does it work?  With GUILE_CONFIG, I pass the executable as an environment
> variable.  Admittedly, my non-system-wide Guile-1.8 (Ubuntu no longer has
> guile-1.8-dev) contains a file
> /usr/local/tmp/guile-1.8/lib/pkgconfig/guile-1.8.pc but I don't have an idea
how
> to use it.

 $ man pkg-config
ENVIRONMENT
     PKG_CONFIG_PATH
             List of secondary directories where ‘.pc’ files are looked up.

     PKG_CONFIG_LIBDIR
             List of primary directories where ‘.pc’ files are looked up.

You'd want PKG_CONFIG_PATH, in your case add
/usr/local/tmp/guile-1.8/lib/pkgconfig/. Setting PKG_CONFIG_LIBDIR makes
pkg-config exclude the system-wide directories like /usr/lib/pkgconfig (which is
very convenient for cross-compilation!).

[hanwenn, 2020-02-21 16:35:31]

pkg-config

[hanwenn, 2020-02-21 16:36:57]

On 2020/02/21 16:02:14, hahnjo wrote:
> guile-config since 2.0 has the following comment:
> "This script has been deprecated. Just use pkg-config."
> 
> Mabye it makes sense to completely turn to pkg-config? My system has $ ll
> /usr/lib/pkgconfig/guile-*
> -rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
> -rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
> -rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc
> 
> So this would also work for Guile 1.8 (which should either be preferred as
David
> suggested or completely dropped; not sure if we're already there).

this is an excellent idea; see the latest patchset.

Unfortunately, 

[hanwen@localhost lilypond]$ make
Making lily/out/lilypond 
/usr/bin/ld: ./out/accidental-engraver.o: undefined reference to symbol
'pthread_getspecific@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from
command line
collect2: error: ld returned 1 exit status
make[1]: *** [out/lilypond] Error 1
make: *** [all] Error 2
[hanwen@localhost lilypond]$ pkg-config --libs guile-1.8
-lguile

[hanwenn, 2020-02-21 16:37:24]

On 2020/02/21 16:36:57, hanwenn wrote:
> On 2020/02/21 16:02:14, hahnjo wrote:
> > guile-config since 2.0 has the following comment:
> > "This script has been deprecated. Just use pkg-config."
> > 
> > Mabye it makes sense to completely turn to pkg-config? My system has $ ll
> > /usr/lib/pkgconfig/guile-*
> > -rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
> > -rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
> > -rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc
> > 
> > So this would also work for Guile 1.8 (which should either be preferred as
> David
> > suggested or completely dropped; not sure if we're already there).
> 
> this is an excellent idea; see the latest patchset.
> 
> Unfortunately, 
> 
> [hanwen@localhost lilypond]$ make
> Making lily/out/lilypond 
> /usr/bin/ld: ./out/accidental-engraver.o: undefined reference to symbol
> mailto:
> /usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing
from
> command line
> collect2: error: ld returned 1 exit status
> make[1]: *** [out/lilypond] Error 1
> make: *** [all] Error 2
> [hanwen@localhost lilypond]$ pkg-config --libs guile-1.8
> -lguile

$ guile1.8-config link
 -pthread  -lguile

[hahnjo, 2020-02-21 16:39:20]

On 2020/02/21 16:36:57, hanwenn wrote:
> On 2020/02/21 16:02:14, hahnjo wrote:
> > guile-config since 2.0 has the following comment:
> > "This script has been deprecated. Just use pkg-config."
> > 
> > Mabye it makes sense to completely turn to pkg-config? My system has $ ll
> > /usr/lib/pkgconfig/guile-*
> > -rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
> > -rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
> > -rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc
> > 
> > So this would also work for Guile 1.8 (which should either be preferred as
> David
> > suggested or completely dropped; not sure if we're already there).
> 
> this is an excellent idea; see the latest patchset.
> 
> Unfortunately, 
> 
> [hanwen@localhost lilypond]$ make
> Making lily/out/lilypond 
> /usr/bin/ld: ./out/accidental-engraver.o: undefined reference to symbol
> mailto:
> /usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing
from
> command line
> collect2: error: ld returned 1 exit status
> make[1]: *** [out/lilypond] Error 1
> make: *** [all] Error 2
> [hanwen@localhost lilypond]$ pkg-config --libs guile-1.8
> -lguile

$ pkg-config --cflags guile-1.8
-D_FORTIFY_SOURCE=2 -pthread

[hanwenn, 2020-02-21 16:42:21]

On 2020/02/21 15:43:38, dak wrote:
> https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4
> File aclocal.m4 (right):
> 
> https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4#newcode760
> aclocal.m4:760: guile2.2-config guile-2.2-config guile-config-2.2
> guile-config2.2 \
> I think that at the current point of time, guile1.8-config should be preferred
> over guile2.2-config.  The main advantage that Guile2 offers currently is that
> it is more likely to be the installed version.  If anybody goes to the pain
> these days of actually installing a Guile-1.8 development package, it is
pretty
> safe to assume that it is for the sake of compiling LilyPond.
> 
> Also, I cannot imagine guile-1.9-config to be recommendable for anything (I
> mean, it is somewhere between 1.8 and 2.0) and would not look explicitly for
it.
> 
> Yes, this is old code, but when we touch it in order to update to current
> realities, we should update to current realities.
> 
> Do we even have comparative speed and memory use measurements of Guile2 for
make
> all test doc and some large scores?

We did the carver score. See commit a19aed147bf1605b21cbe7b1909ff6cbf519fb64.
It's 52 sec with GUILE 2.2, and 40 sec (if memory serves) with GUILE 1.8.

I'll check the cost of "make test-baseline"

[lemzwerg, 2020-02-21 16:53:36]

LGTM.  However, the use of the pkgconfig environment variable(s) should be
documented.

[hanwenn, 2020-02-21 17:03:07]

make baseline:

1.8:
real	3m41.714s
user	6m52.414s
sys	0m36.662s

2.2:
real	6m8.344s
user	12m51.799s
sys	0m34.875s

I think this warrants some deeper look, though: I have the impression that the
lilypond-book regression tests aren't parallelized. They also suffer from the
higher start up costs (there are some 60 of them, so that's 90 seconds right
there).

[hanwenn, 2020-02-21 17:08:04]

stats

[hanwenn, 2020-02-21 17:08:34]

On 2020/02/21 16:39:20, hahnjo wrote:
> On 2020/02/21 16:36:57, hanwenn wrote:
> > On 2020/02/21 16:02:14, hahnjo wrote:
> > > guile-config since 2.0 has the following comment:
> > > "This script has been deprecated. Just use pkg-config."
> > > 
> > > Mabye it makes sense to completely turn to pkg-config? My system has $ ll
> > > /usr/lib/pkgconfig/guile-*
> > > -rw-r--r-- 1 root root 453 11. Jan 2019  /usr/lib/pkgconfig/guile-1.8.pc
> > > -rw-r--r-- 1 root root 849 10. Jan 2019  /usr/lib/pkgconfig/guile-2.0.pc
> > > -rw-r--r-- 1 root root 886 10. Jul 2019  /usr/lib/pkgconfig/guile-2.2.pc
> > > 
> > > So this would also work for Guile 1.8 (which should either be preferred as
> > David
> > > suggested or completely dropped; not sure if we're already there).
> > 
> > this is an excellent idea; see the latest patchset.
> > 
> > Unfortunately, 
> > 
> > [hanwen@localhost lilypond]$ make
> > Making lily/out/lilypond 
> > /usr/bin/ld: ./out/accidental-engraver.o: undefined reference to symbol
> > mailto:
> > /usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing
> from
> > command line
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [out/lilypond] Error 1
> > make: *** [all] Error 2
> > [hanwen@localhost lilypond]$ pkg-config --libs guile-1.8
> > -lguile
> 
> $ pkg-config --cflags guile-1.8
> -D_FORTIFY_SOURCE=2 -pthread

Done. (It's ugly to put CFLAGS into the LIBS variable, but it works)

[dak, 2020-02-21 17:13:57]

On 2020/02/21 17:03:07, hanwenn wrote:
> make baseline:
> 
> 1.8:
> real	3m41.714s
> user	6m52.414s
> sys	0m36.662s
> 
> 2.2:
> real	6m8.344s
> user	12m51.799s
> sys	0m34.875s
> 
> I think this warrants some deeper look, though: I have the impression that the
> lilypond-book regression tests aren't parallelized. They also suffer from the
> higher start up costs (there are some 60 of them, so that's 90 seconds right
> there).

I recently found some "could not contact jobserver" in the logs from make and
googling it suggested that this is a consequence of using $(MAKE) rather than
$$(MAKE) inside of macros (causing premature or too much expansion?).  I have
not investigated yet and don't know what counts as "macro" here.  Or whether
this is all nonsense.  Either way, it should affect Guile-2 just as much as
Guile-1.8, shouldn't it?

[hanwenn, 2020-02-21 17:24:48]

On Fri, Feb 21, 2020 at 6:13 PM <dak@gnu.org> wrote:

> > 1.8:
> > real  3m41.714s
> > user  6m52.414s
> > sys   0m36.662s
> >
> > 2.2:
> > real  6m8.344s
> > user  12m51.799s
> > sys   0m34.875s
> >
> > I think this warrants some deeper look, though: I have the impression
> that the
> > lilypond-book regression tests aren't parallelized. They also suffer
> from the
> > higher start up costs (there are some 60 of them, so that's 90 seconds
> right
> > there).
>
> I recently found some "could not contact jobserver" in the logs from
> make and googling it suggested that this is a consequence of using
> $(MAKE) rather than $$(MAKE) inside of macros (causing premature or too
> much expansion?).  I have not investigated yet and don't know what
> counts as "macro" here.  Or whether this is all nonsense.  Either way,
> it should affect Guile-2 just as much as Guile-1.8, shouldn't it?

The startup costs of parsing .scm files of 1.5 secs gets added to the
process 60 times. If you remove that,

>>> (368 - 90)  /221.
1.257918552036199

we're back to a 25% slowdown.


>
> https://codereview.appspot.com/569390043/



-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[hahnjo, 2020-02-21 17:31:40]

On 2020/02/21 17:08:34, hanwenn wrote:
> On 2020/02/21 16:39:20, hahnjo wrote:
> > $ pkg-config --cflags guile-1.8
> > -D_FORTIFY_SOURCE=2 -pthread
> 
> Done. (It's ugly to put CFLAGS into the LIBS variable, but it works)

Uh, we don't add CFLAGS when linking? That sounds ... dangerous.

[hahnjo, 2020-02-21 17:42:01]

A few nits on m4 escapes, but otherwise LGTM - works very well on my system with
three versions of Guile installed!

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4
File aclocal.m4 (right):

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode693
aclocal.m4:693: if [[ -n "$GUILE_FLAVOR" ]] ; then
I first thought this was bash syntax and not portable, but m4 substitution comes
into play here and removes one set of [ ]. Could we write this as
test -n "$GUILE_FLAVOR"
instead?

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode694
aclocal.m4:694: PKG_CHECK_MODULES(GUILE, $GUILE_FLAVOR, true, true)
Please escape all arguments with [ ... ], here and in other locations.

Additionally we should probably reset GUILE_FLAVOR in the false case to trigger
the error below.

https://codereview.appspot.com/569390043/diff/571710044/config.make.in
File config.make.in (right):

https://codereview.appspot.com/569390043/diff/571710044/config.make.in#newcode28
config.make.in:28: GUILE_LIBS = @GUILE_LIBS@ @GUILE_CFLAGS@
Can be $(GUILE_CFLAGS), already substituted above

https://codereview.appspot.com/569390043/diff/571710044/config.make.in#newcod...
config.make.in:129: GUILE_CONFIG = @GUILE_CONFIG@
Please remove these GUILE_CFLAGS (there's another declaration above) and
GUILE_CONFIG which should be unused now.

[hahnjo, 2020-02-21 17:48:54]

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4
File aclocal.m4 (right):

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode697
aclocal.m4:697: if [[ -z "$GUILE_FLAVOR" ]] ; then
You can actually make this a little nicer by putting the next check in the false
branch.

[hanwenn, 2020-02-21 19:12:13]

On 2020/02/21 17:31:40, hahnjo wrote:
> On 2020/02/21 17:08:34, hanwenn wrote:
> > On 2020/02/21 16:39:20, hahnjo wrote:
> > > $ pkg-config --cflags guile-1.8
> > > -D_FORTIFY_SOURCE=2 -pthread
> > 
> > Done. (It's ugly to put CFLAGS into the LIBS variable, but it works)
> 
> Uh, we don't add CFLAGS when linking? That sounds ... dangerous.

see stepmake/executable-rules.make

[hanwenn, 2020-02-21 19:15:00]

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4
File aclocal.m4 (right):

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode693
aclocal.m4:693: if [[ -n "$GUILE_FLAVOR" ]] ; then
On 2020/02/21 17:42:00, hahnjo wrote:
> I first thought this was bash syntax and not portable, but m4 substitution
comes
> into play here and removes one set of [ ]. Could we write this as
> test -n "$GUILE_FLAVOR"
> instead?

oh, of course

"[[" is recommended in the google bash style guide, for reasons that have to do
with (IIRC) wildcard expansion.

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode694
aclocal.m4:694: PKG_CHECK_MODULES(GUILE, $GUILE_FLAVOR, true, true)
On 2020/02/21 17:42:00, hahnjo wrote:
> Please escape all arguments with [ ... ], here and in other locations.
> 
> Additionally we should probably reset GUILE_FLAVOR in the false case to
trigger
> the error below.

done. Note that we don't use [ ] in most pkg_check_modules() calls elsewhere.

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode697
aclocal.m4:697: if [[ -z "$GUILE_FLAVOR" ]] ; then
On 2020/02/21 17:48:54, hahnjo wrote:
> You can actually make this a little nicer by putting the next check in the
false
> branch.

Done.

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode697
aclocal.m4:697: if [[ -z "$GUILE_FLAVOR" ]] ; then
On 2020/02/21 17:48:54, hahnjo wrote:
> You can actually make this a little nicer by putting the next check in the
false
> branch.

Done.

https://codereview.appspot.com/569390043/diff/571710044/config.make.in
File config.make.in (right):

https://codereview.appspot.com/569390043/diff/571710044/config.make.in#newcode28
config.make.in:28: GUILE_LIBS = @GUILE_LIBS@ @GUILE_CFLAGS@
On 2020/02/21 17:42:00, hahnjo wrote:
> Can be $(GUILE_CFLAGS), already substituted above

Done.

[hanwenn, 2020-02-21 19:15:59]

jonas' comments

[hanwenn, 2020-03-06 20:11:58]

commit 670e9f7b9660822f31144cbf07788bfc28de94cd
Author: Han-Wen Nienhuys <hanwen@lilypond.org>
Date:   Fri Feb 21 16:14:48 2020 +0100

    Accept GUILE 2 without extra configure options

[dak, 2020-03-07 01:20:00]

On 2020/02/21 16:34:35, hahnjo wrote:
> On 2020/02/21 16:22:52, lemzwerg wrote:
> > > Mabye it makes sense to completely turn to pkg-config?
> > 
> > Sounds sensible.  In particular, it eases cross-compilation.
> 
> Reading my mind ;-)
> 
> On 2020/02/21 16:25:02, dak wrote:
> > > So this would also work for Guile 1.8 (which should either be preferred as
> > David
> > > suggested or completely dropped; not sure if we're already there).
> > 
> > How does it work?  With GUILE_CONFIG, I pass the executable as an
environment
> > variable.  Admittedly, my non-system-wide Guile-1.8 (Ubuntu no longer has
> > guile-1.8-dev) contains a file
> > /usr/local/tmp/guile-1.8/lib/pkgconfig/guile-1.8.pc but I don't have an idea
> how
> > to use it.
> 
>  $ man pkg-config
> ENVIRONMENT
>      PKG_CONFIG_PATH
>              List of secondary directories where ‘.pc’ files are looked up.
> 
>      PKG_CONFIG_LIBDIR
>              List of primary directories where ‘.pc’ files are looked up.
> 
> You'd want PKG_CONFIG_PATH, in your case add
> /usr/local/tmp/guile-1.8/lib/pkgconfig/. Setting PKG_CONFIG_LIBDIR makes
> pkg-config exclude the system-wide directories like /usr/lib/pkgconfig (which
is
> very convenient for cross-compilation!).

Ok, I've been bitten now by this REALLY REALLY BAD, and there is absolutely NO
documentation to be found ANYWHERE with regard to how this is supposed to be
configured.  ./configure --help does not help, there is absolutely no mention of
anything anywhere.

I finally set
[configure_environment]
GUILE=/usr/bin/guile
GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config
PKG_CONFIG_PATH=/usr/local/tmp/guile-1.8/lib/pkgconfig

in my ./lilypond-patchy-config file but how are people supposed to figure that
out?  There is absolutely no useful documentation for getting there.  And as
long as Guile-2.2 crashes frequently with segfaults when used within LilyPond,
it is not really an option to leave integrators with no discernible option to
integrate a version of Guile-1.8 like Debian does.

[hanwenn, 2020-03-07 10:46:00]

On Sat, Mar 7, 2020 at 2:20 AM <dak@gnu.org> wrote:

> getting there.  And as long as Guile-2.2 crashes frequently with
> segfaults when used within LilyPond,

Can you file a bug report for any remaining Guile 2.2 crashes? I am
not aware of any.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[dak, 2020-03-07 11:41:54]

Han-Wen Nienhuys <hanwenn@gmail.com> writes:

> On Sat, Mar 7, 2020 at 2:20 AM <dak@gnu.org> wrote:
>
>> getting there.  And as long as Guile-2.2 crashes frequently with
>> segfaults when used within LilyPond,
>
> Can you file a bug report for any remaining Guile 2.2 crashes? I am
> not aware of any.

Just recently two segfaults in Patchy.  Since I don't get more than
"signal 11" in the log files, there is nothing worth filing.  And since
they occur intermittently and not reproducibly within the large runs of
make doc, they will be related to garbage collection and thus even core
dumps will be of comparatively little utility.  Since running Patchy on
Guile-2.2 takes a performance hit of about 40% (that's where my recent
prolonged doc run times were from) and ends up unreliable as well as not
representative for 1.8, still our main target, I am not too enthused
about running Patchy frequently on Guile-2.x with core dumps enabled
(set ulimit -c 1000000 or so).

How often do you run make doc?

-- 
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".

[hanwenn, 2020-03-07 16:13:39]

On Sat, Mar 7, 2020 at 12:41 PM David Kastrup <dak@gnu.org> wrote:
>
> Han-Wen Nienhuys <hanwenn@gmail.com> writes:
>
> > On Sat, Mar 7, 2020 at 2:20 AM <dak@gnu.org> wrote:
> >
> >> getting there.  And as long as Guile-2.2 crashes frequently with
> >> segfaults when used within LilyPond,
> >
> > Can you file a bug report for any remaining Guile 2.2 crashes? I am
> > not aware of any.
>
> Just recently two segfaults in Patchy.  Since I don't get more than
> "signal 11" in the log files, there is nothing worth filing.  And since
> they occur intermittently and not reproducibly within the large runs of
> make doc, they will be related to garbage collection and thus even core
> dumps will be of comparatively little utility.  Since running Patchy on

If you can capture a core dump and a back trace, that can at least give us

> Guile-2.2 takes a performance hit of about 40% (that's where my recent
> prolonged doc run times were from)

I would also be interested in more information about this. At what
commit are you seeing a 40% performance hit? AFAICT, it should be
roughly equivalent to guile 1.8 since

 commit e36b7c7ea986418bcfebfba6c6c971db05b77afb
 Author: Han-Wen Nienhuys <hanwen@lilypond.org>
 Date:   Tue Feb 25 21:39:10 2020 +0100

    GUILE2: Do not run GC after processing every file.

> and ends up unreliable as well as not
> representative for 1.8, still our main target, I am not too enthused
> about running Patchy frequently on Guile-2.x with core dumps enabled
> (set ulimit -c 1000000 or so).
>
> How often do you run make doc?

I've been running a fair number of times recently when I was trying to
look into the speed of the build, but I've been mainly waiting for
https://codereview.appspot.com/575750043/ to hit master, so I can
build the docs in Docker too.

Let me try to repro some more.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen