Re: State of LilyPond with Guile 2.2

[Thomas Morley]

Am So., 18. Apr. 2021 um 16:41 Uhr schrieb Thomas Morley
<thomasmorley65@gmail.com>:
>
> Am So., 18. Apr. 2021 um 15:38 Uhr schrieb Jonas Hahnfeld via
> Discussions on LilyPond development <lilypond-devel@gnu.org>:
> >
> > Am Sonntag, dem 18.04.2021 um 13:11 +0000 schrieb Werner LEMBERG:
> > > > > For me, the speed of Guile 2.x without compiled Scheme bytecode
> > > > > would be too painful.
> > > >
> > > > Agreed for user installations, but we have a work-around there.  So
> > > > what about development? Do we *require* compiled bytecode to work
> > > > there?  [...]
> > >
> > > I don't know, really.  I have zero feeling for that.  Of course it
> > > would be nice if `make doc` doesn't become much slower.  Whether this
> > > can be easily done, I have no clue.
> > >
> > > > P.S.: This is getting a bit annoying, but I honestly have no clue
> > > > how I could ask the questions in a better way that you answer all
> > > > of
> > > > them in one reply...
> > >
> > > What exactly is unclear if I write "please proceed"?
> >
> > Originally the whole point of the thread was "where" to proceed:
> > Continue working on proper bytecode compilation (because that is a
> > requirement), or tackle the other topics such as how to build binaries.
> > This only got side-tracked by questioning if Guile 2.2 makes sense at
> > all, which I didn't anticipate in the beginning.
> >
> > By now I guess just nobody cares to tell me in advance and whatever I
> > choose to do, it will be questioned when I try to proceed to the next
> > steps...
> >
> > Jonas
>
> Currently I'm testing both. From a user's and a developer's point of view.
> I'll post about it in the (late) evening or tomorrow.
> Please have a little patience.
>
> Cheers,
>   Harm

Ok, here my experiences:

## Compiling .scm-files lasts a multiple of the former mentioned 2
minutes on my weak laptop, no surprise, though I thought I should
mention it.
## I noticed a plethora of messages like:
warning: possibly unbound variable `symbol-list-or-symbol?'
...
=======================
As a user
=======================
Jonas already provided some promising values for larger scores. Thus I
didn't test those again.
My typical use-case are fairly short scores, with lots and lots
compiling rounds in order to fine-tune things:
With compiled guile-code the startup-delay is close to unnoticable.
Compilation speed is close enough to guile-1.
I'd say the most important argument against switching to guile-2 is gone.
------------------ GREAT --------------
Well, now to the lesser important ones.
## Error-handling:
consider the typo in
{
  \override NoteHead.after-line-breaking =
  #(lambda (grob) (ly:grob-set-property! grob 'stencil poit-stencil))
  b1
}
with guile-1 one gets:

While evaluating arguments to ly:grob-set-property! in expression
(ly:grob-set-property! grob (quote stencil) ...):
atest-106.ly:1064:5: Unbound variable: poit-stencil

with guile-2.2:

Backtrace:
          11 (apply-smob/1 #<catch-closure 55e8bf0afb20>)
In 
/home/hermann/lilypond-git/build-guile-2-2-6/out/share/lilypond/current/scm/lily/lily.scm:
   917:16 10 (lilypond-main _)
    953:4  9 (lilypond-all _)
In srfi/srfi-1.scm:
    640:9  8 (for-each #<procedure 55e8c0a7f6f0 at /home/hermann/li…> …)
In 
/home/hermann/lilypond-git/build-guile-2-2-6/out/share/lilypond/current/scm/lily/lily.scm:
    963:9  7 (_ _)
In ice-9/boot-9.scm:
    829:9  6 (catch _ _ #<procedure 55e8c0aa44c0 at /home/hermann/l…> …)
In unknown file:
           5 (ly:parse-file "atest-106.ly")
           4 (ly:book-process #<Book> #< Output_def> #< Output_def> #)
           3 (ly:optimal-breaking #<Paper_book>)
In ice-9/eval.scm:
    163:9  2 (_ #(#(#<module (#{ g69}#) 55e8c0787960>) #<Grob Note…>))
   223:20  1 (proc #(#(#<module (#{ g69}#) 55e8c0787960>) #<Grob N…>))
In unknown file:
           0 (%resolve-variable (7 . poit-stencil) #<module (#{ g69}…>)

ERROR: In procedure %resolve-variable:
Unbound variable: poit-stencil

A little too heavy...Can this be reduced?

## User scheme-code
Obviously not compiled.
I speculated one could define some .scm-files containing the
scheme-codings and call it in a ly-file or via ly:load or maybe define
a module and use it via (use-modules (lily? custom-module)) or the
like.
Though, that's all brainstorming, I didn't investigate further.
We probably should first settle how to proceed...,

=======================
As a developer
=======================
For my newest MR
https://gitlab.com/lilypond/lilypond/-/merge_requests/732
I used the setup with compiled guile-2.
(This MR changes no .scm-files)

With this setup I did all of `make test-baseline/test/check/doc' and
local testings.
Even with guile-1 every single `make what-ever' lasts ages, thus I
don't care whether it lasts longer or not, I didn't take timing
values.

Some observations:
(1)
The whole cycle worked fine, no errors apart from my own.
Though, regtest-comparision shows:
WARNING: (lily song): imported module (lily song-util) overrides core
binding `compose'
For input/regression/song-melisma.log and others.
Which is new with guile-2.
No clue how to avoid this other then not to use taken identifiers.
(2)
If I switch to a different branch, with changed .scm-files, do some
work there and then switch back (NB in this branch the scm-files are
_not_ changed inbetween) I need to recompile guile, a real nuisance.
Could this be improved?

Conclusion:
IMHO, the most heavy arguments against dropping guile-1 and switching
to guile-2 for good are gone.
If the mentioned problems could be improved a bit I'd vote for moving
to guile-2.

So far...cheers,
  Harm

P.S.
I'd love to redo testings with guile-3, alas, while `make' succeeds,
GUILE_AUTO_COMPILE=1 failed. I didn't investigate further, though.