Re: Blockers for Guile 2.2

[Jean Abou Samra]

[Han-Wen]
> On Tue, Feb 22, 2022 at 12:05 PM Jean Abou Samra<jean@abou-samra.fr>  wrote:
> > Friends,
> >
> > I don't see this thread coming to a conclusion if it stays between the same 
> > three people, and the topic is somewhat important to LilyPond's future. More 
> > voices would be helpful.
> Here are my thoughts:



Thanks for sharing your thoughts. The quote is actually from
an off-list message BBCed to you, but never mind.



[Jonas]
> My understanding of Guile's development is that certain developers have
> ideas in their mind, and they eventually end up fully implemented in
> the repository. There is no such thing as (public) plans.



My understanding of Guile's development is that there is
one developer, Andy Wingo, who has lots of fun experimenting
with compilers, then Ludovic Courtès, who appears more receptive
to our needs but more focused on Guix and lacking time for Guile,
and a number other contributors who cannot participate very
seriously because patches stall for months or years without
getting looked at. Guile is being developed in solo. Andy
Wingo never writes to mailing lists except to announce releases,
does not appear to read neither patches, nor bug reports,
nor proposals, and criticism like
https://lists.gnu.org/archive/html/guile-devel/2022-02/msg00031.html
does not publicly look taken into account either.

So the bus factor of Guile is essentially 1 and as long
as this will be the model, we will continue to see more
funny Scheme compiler optimizations, less C accessibility,
and less usability. An good example is
https://lists.gnu.org/archive/html/guile-devel/2022-02/msg00030.html
Now, even without macros, you can get mysterious issues related
to bytecode having been compiled for an outdated version
of another file, if you naively use the default optimization
level. (And all in a patch release.)

Obviously I am not exactly optimistic about Guile's future,
and even less about the attractivity of newer Guile versions
for LilyPond's use case. By the way, have you watched

https://archive.fosdem.org/2020/schedule/event/guile2020/

That is an interesting insight into how Guile evolves.
Especially the recurring debate about "Is it OK to lose
users?".

Anyway.



> > I read over this thread, but I don't understand what you mean by
> > "downstreams" here.
>
>
> In my understanding, it's about "downstreams" packaging LilyPond,
> including Linux distributions and parties like HomeBrew and MacPorts.
> But please ask Jean what exactly is required now:
> https://lists.gnu.org/archive/html/lilypond-devel/2022-02/msg00123.html 



GUILE_AUTO_COMPILE=1 is not just for us. The user can have it set
in their environment as a system configuration for all software that
happens to use Guile as well. If that causes LilyPond to try to
let Guile write bytecode in a directory where they don't have
write access, things will go wrong. (I seem to remember that this
would not be an issue with HomeBrew because it lets the user
chown its "Cellar" but I am not sure and don't have macOS to test.)

That's the sort of thing I was referring to. Again, I don't think
it should block starting to make releases exclusively with Guile 2.
What I am uncomfortable with is actively removing Guile 1-specific
code before this is sorted out.



> Seehttps://gitlab.com/hahnjo/lilypond/-/commits/guile2-bytecode  Let me
> know if this is miraculously sufficient to make people happy and I can
> open a merge request.


I was going to write a longer reply before this came, but
this mostly obviates it. Am I understanding it correctly that
you can copy the bytecode from Linux binaries to cross-compiled
MingW ones even if this is not automated for now? If so, that
clears my concerns.

Jean