Re: GUILE 2.2 progress

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> With https://codereview.appspot.com/551390047/

That patch is papering over a problem rather than fixing it.  It might
be a reoccurence of something like

commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
Author: Andy Wingo <address@hidden>
Date:   Thu Jun 23 11:47:42 2016 +0200

    Fix race between SMOB marking and finalization
    
    * libguile/smob.c (clear_smobnum): New helper.
      (finalize_smob): Re-set the smobnum to the "finalized smob" type
      before finalizing.  Fixes #19883.
      (scm_smob_prehistory): Pre-register a "finalized smob" type, which has
      no mark procedure.
    * test-suite/standalone/test-smob-mark-race.c: New file.
    * test-suite/standalone/Makefile.am: Arrange to build and run the new
      test.


> it looks like I can run LilyPond against GUILE 2.2 mostly:
>
>
> $ time lilypond input/regression/mozart-hrn-3.ly
> GNU LilyPond 2.21.0
> Import (ice-9 threads) to have access to `call-with-new-thread'.
> Import (ice-9 threads) to have access to `current-thread'.
> Processing `input/regression/mozart-hrn-3.ly'
> Parsing...
> input/regression/mozart-hrn-3.ly:31:9: error: not a markup
>
>         #(string-append  "It has been typeset and placed in the public "

Looks like it should be a markup.

> Interpreting 
> music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120]
> Preprocessing graphical objects...
> Interpreting music...
> Interpreting music...
> Interpreting music...[8][16][24][32][40][48]
> Preprocessing graphical objects...
> Interpreting music...
> Interpreting
> music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144]
> Preprocessing graphical objects...
> MIDI output to `mozart-hrn-3.midi'...
> MIDI output to `mozart-hrn-3-1.midi'...
> MIDI output to `mozart-hrn-3-2.midi'...
> Finding the ideal number of pages...
> Fitting music on 3 or 4 pages...
> Drawing systems...
> Layout output to `/tmp/lilypond-A2ssuI'...
> Converting to `mozart-hrn-3.pdf'...
> Deleting `/tmp/lilypond-A2ssuI'...
> fatal error: failed files: "input/regression/mozart-hrn-3.ly"
>
> real 0m7.239s
> user 0m8.637s
> sys 0m0.121s
>
> (this disables the GS step, as something is munging a string , causing
> GS to barf.)

Likely an encoding problem.

> 7.2 seconds end-to-end includes 1.7s of GC, and 2.0s of reading/compiling SCM.
>
> On guile 1.8, with GS disabled, the end to end runtime is
>
> 3.568s including 0.33s for GC and 0.32s for reading the SCM.
>
> These timings are internally consistent: if we can do byte-compilation
> on the .scm files (which would make the SCM reading instantaneous),
> and get the GC overhead down, we'd be at the same performance level of
> GUILE 1.8.
>
> What do folks think is more important? Reducing GC overhead is a win
> on large scores, while byte-compilation will make compile/edit/debug
> cycles faster.

Byte compilation is sort of a big thing since it needs to find places
for the .go files to go in a LilyPond installation/distribution without
messing up future compile/edit/debug cycles.

If you offer to do either, my vote would be on that as the clearly more
tedious one.

> Even if we wouldn't recoup all the overhead of GC, I think the reduced
> complexity of using BGC for GC might be worth it.
>
> I think it is clear that we should not be targeting GUILE 2.0, but
> GUILE 2.2.

Well, not much of a point in targeting an old stable version except
possibly for checking the new stable for regressions.

-- 
David Kastrup