The lilypond git repository contains a couple of branches about the guile-2 porting: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/guilev2 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/guilev21 The commits in those branches mention some guile-2.0 bugs triggered by lilypond: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20209 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20200 It looks like these bugs have been fixed in guile 2.0.12: http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=f763f353e438de985577ef4b88b805bd4d4c9b77 http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=d574d96f879c147c6c14df43f2e4ff9e8a6876b9 So, now that guile-2.0 version 2.0.13 is available in Debian unstable (http://ftp.debian.org/debian/pool/main/g/guile-2.0/) I tried to summarize what the situation is to have at least a vague idea of what is missing to have lilypond working with guile-2.0 This is a report of what I tried to have "make doc-stage-1" complete successfully. Checkout the lilypond master branch: git clone git://git.sv.gnu.org/lilypond.git lilypond.git cd lilypond.git The janneke/wip-guile2 branch is not really necessary. Create a new test branch git checkout -b guile-v2-local-tests Do we still need the changes in the dev/guilev2 and dev/guilev21 branches? Cherry pick them: git cherry-pick 1001e63b2d54cc970374f5be98f7f31e26554c69 git cherry-pick 122525fbd9f95521b80487fe7567f3d38871ebc5 Update the changes from commit 122525f to follow what was done in commit 652f454 (Add lily/lily-modules.cc). ------------------------------------------------------------------------------- diff --git a/lily/include/lily-imports.hh b/lily/include/lily-imports.hh index d930f69..fa0c8b7 100644 --- a/lily/include/lily-imports.hh +++ b/lily/include/lily-imports.hh @@ -37,6 +37,7 @@ namespace Guile_user { extern Variable module_use_x; extern Variable symbol_p; extern Variable the_root_module; + extern Variable default_port_encoding; } namespace Display { diff --git a/lily/lily-imports.cc b/lily/lily-imports.cc index 62e58b6..794b8f3 100644 --- a/lily/lily-imports.cc +++ b/lily/lily-imports.cc @@ -33,6 +33,7 @@ namespace Guile_user { Variable module_use_x ("module-use!"); Variable symbol_p ("symbol?"); Variable the_root_module ("the-root-module"); + Variable default_port_encoding ("%default-port-encoding"); } namespace Display { diff --git a/lily/source-file.cc b/lily/source-file.cc index eaa5ee0..7a8d290 100644 --- a/lily/source-file.cc +++ b/lily/source-file.cc @@ -41,6 +41,7 @@ using namespace std; #include "international.hh" #include "misc.hh" #include "warn.hh" +#include "lily-imports.hh" void Source_file::load_stdin () @@ -160,7 +161,7 @@ Source_file::init_port () // particularly interested in sticking to its documentation. // scm_dynwind_begin ((scm_t_dynwind_flags)0); - scm_dynwind_fluid (ly_lily_module_constant ("%default-port-encoding"), SCM_BOOL_F); + scm_dynwind_fluid (Guile_user::default_port_encoding, SCM_BOOL_F); str_port_ = scm_open_bytevector_input_port (str, SCM_UNDEFINED); scm_dynwind_end (); #else ------------------------------------------------------------------------------- In order to fix building the man pages relative to the supplied scheme programs under scripts/ (namely scripts/lilypond-invoke-editor.scm), add support for guile-2.0 also for STEPMAKE_GUILE. ------------------------------------------------------------------------------- diff --git a/configure.ac b/configure.ac index 0a75332..cd6caf1 100644 --- a/configure.ac +++ b/configure.ac @@ -219,7 +219,12 @@ STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10) STEPMAKE_WINDOWS # guile executable for some scripts -STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) +if test "$GUILEv2" = "yes" +then + STEPMAKE_GUILE(OPTIONAL, 2.0.7, 2.2.0) +else + STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) +fi ------------------------------------------------------------------------------- Run ./autogen.sh enabling guile-2: ./autogen.sh --enable-guile2 --enable-debugging --disable-checking --disable-optimising --prefix=$PWD/build make Just to be sure, reset the locale (I had LANG=it_IT.utf8) when building the doc, otherwise the eps files might end up containing numbers formatted with commas as a decimal separator and that will make the conversion from eps to pdf fail with a message like this: ------------------------------------------------------------------------------- $ gs -q -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=/home/ao2/Proj/debian/Src/lilypond/lilypond.git/out/lybook-db/94/lily-32d78681.pdf -c.setpdfwrite -f/home/ao2/Proj/debian/Src/lilypond/lilypond.git/out/lybook-db/94/lily-32d78681.eps Error: /undefined in 7,3977 Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1983 1 3 %oparray_pop 1982 1 3 %oparray_pop --nostringval-- 1966 1 3 %oparray_pop 1852 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1207/1684(ro)(G)-- --dict:0/20(G)-- --dict:113/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 8634 GPL Ghostscript 9.19: Unrecoverable error, exit code 1 ------------------------------------------------------------------------------- I noticed this when running lilypond directly from the command line, but just to be safe and avoid that particular issue, reset the locale also when calling "make": LANG=C make doc-stage-1 The build starts and at some point it fails on this error: ------------------------------------------------------------------------------- Processing `/home/ao2/Proj/debian/Src/lilypond/lilypond.git/out/lybook-db/d2/lily-6e9bfc0d.ly' Parsing... Renaming input to: `measure-counter.ly' Interpreting music...[8] Preprocessing graphical objects... Calculating line breaks... Drawing systems... Backtrace: In ice-9/boot-9.scm: 160: 13 [catch #t # ...] In unknown file: ?: 12 [apply-smob/1 #] In ice-9/eval.scm: 411: 11 [eval # #] 432: 10 [eval # #] In srfi/srfi-1.scm: 616: 9 [for-each # #] In ice-9/eval.scm: 432: 8 [eval # #] In ice-9/boot-9.scm: 160: 7 [catch ly-file-failed ...] In unknown file: ?: 6 [ly:parse-file "d2/lily-6e9bfc0d.ly"] ?: 5 [ly:book-process-to-systems # #< Output_def> ...] ?: 4 [ly:side-position-interface::move-to-extremal-staff #] ?: 3 [ly:axis-group-interface::width #] ?: 2 [ly:grob::stencil-width #] In ice-9/eval.scm: 411: 1 [eval # #] In unknown file: ?: 0 [# "2"] ERROR: In procedure #: ERROR: Wrong type to apply: # ------------------------------------------------------------------------------- Which can be reproduced with: $ LANG=C ./out/bin/lilypond input/regression/measure-counter.ly This is triggered by scm/scheme-engravers.scm which uses MeasureCounter (defined in scm/define-grobs.scm) which uses measure-counter-stencil (defined in scm/output-lib.scm). A proper solution should probably go into scm/output-lib.scm, but for now I am just working around the ERROR with this patch: ------------------------------------------------------------------------------- diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index 6ca25b5..1085a85 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -1436,7 +1436,7 @@ (self-alignment-X . ,CENTER) (side-axis . ,Y) (staff-padding . 0.5) - (stencil . ,measure-counter-stencil) + ;;(stencil . ,measure-counter-stencil) (meta . ((class . Spanner) (interfaces . (font-interface measure-counter-interface ------------------------------------------------------------------------------- After that "make doc-stage-1" goes further but halts with a Segmentation Fault: ------------------------------------------------------------------------------- Processing `/home/ao2/Proj/debian/Src/lilypond/lilypond.git/out/lybook-db/57/lily-2c7e8231.ly' Parsing... Renaming input to: `markup-cyclic-reference.ly' ... Writing /home/ao2/Proj/debian/Src/lilypond/lilypond.git/out/lybook-db/57/lily-2c7e8231-systems.count...Errore di segmentazione ------------------------------------------------------------------------------- This can be reproduced with: $ LANG=C ./out/bin/lilypond input/regression/markup-cyclic-reference.ly Even by looking at the backtrace from gdb I could not find the root cause, however from an higher level I observed that the issue happens when a cyclic function is called _twice_. In fact, a patch like the following works around the segfault: ------------------------------------------------------------------------------- diff --git a/input/regression/markup-cyclic-reference.ly b/input/regression/markup-cyclic-reference.ly index 82bfe06..b94023d 100644 --- a/input/regression/markup-cyclic-reference.ly +++ b/input/regression/markup-cyclic-reference.ly @@ -23,4 +23,4 @@ not crash LilyPond with an endless loop" \markup { \cycle "a" } -\markup { \cycleI "a" } +%\markup { \cycleI "a" } ------------------------------------------------------------------------------- I realize that this is just like the old joke "Doctor, it hurts when I do this" and the Doctor says "Don't do that.", but I wanted to see what other issues there were. After that "make doc-stage-1" goes further, but stops with this message: ------------------------------------------------------------------------------- Renaming input to: `event-listener-output.ly' Interpreting music...Backtrace: In ice-9/boot-9.scm: 160: 16 [catch #t # ...] In unknown file: ?: 15 [apply-smob/1 #] In ice-9/eval.scm: 411: 14 [eval # #] 432: 13 [eval # #] In srfi/srfi-1.scm: 613: 12 [for-each # #] In ice-9/eval.scm: 432: 11 [eval # #] In ice-9/boot-9.scm: 160: 10 [catch ly-file-failed ...] In unknown file: ?: 9 [ly:parse-file "59/lily-22ec2080.ly"] ?: 8 [ly:book-process-to-systems # #< Output_def> ...] ?: 7 [apply-smob/1 # #] ?: 6 [apply-smob/2 # # #] ?: 5 [apply-smob/1 # #] In ice-9/eval.scm: 411: 4 [eval # #] 387: 3 [eval # #] 432: 2 [eval # #] 393: 1 [eval # (# . #)] In unknown file: ?: 0 [memoize-variable-access! # #] ERROR: In procedure memoize-variable-access!: ERROR: Unbound variable: unnamed-staff ------------------------------------------------------------------------------- This can be reproduced with: $ LANG=C ./out/bin/lilypond input/regression/event-listener-output.ly This time I think I get what the problem is: unescaped quotes in a string. This patch fixes the problem: ------------------------------------------------------------------------------- diff --git a/ly/event-listener.ly b/ly/event-listener.ly index a2a39bc..4627aaa 100644 --- a/ly/event-listener.ly +++ b/ly/event-listener.ly @@ -40,7 +40,7 @@ "Constructs a filename in the form @file{@var{original_filename}-@var{staff_instrument_name}.notes} if the staff has an instrument name. If the staff has no instrument -name, it uses "unnamed-staff" for that part of the filename." +name, it uses \"unnamed-staff\" for that part of the filename." (let* ((inst-name (ly:context-property context 'instrumentName))) (string-concatenate (list (substring (object->string (command-line)) ------------------------------------------------------------------------------- After this, it looks like "make doc-stage-1" goes on, no more guile errors on the console but at some point one lilypond invocation gets stuck: after more than one hour it would not finish yet. If I attach gdb to it and print the backtrace I get this: ------------------------------------------------------------------------------- (gdb) bt #0 0x00002abb762e2e13 in st_resize_port (pt=0x55b39540b4e0, new_size=0) at strports.c:111 #1 0x00002abb762e2f8d in st_flush (port=0x55b392370210) at strports.c:145 #2 0x00002abb762e30bb in st_write (port=0x55b392370210, data=0x2abb76342f7a, size=1) at strports.c:172 #3 0x00002abb762a6333 in scm_lfwrite (ptr=0x2abb76342f7a "(", size=1, port=0x55b392370210) at ports.c:1581 #4 0x00002abb7627059f in scm_puts (s=0x2abb76342f7a "(", port=0x55b392370210) at ../libguile/inline.h:132 #5 0x00002abb762ace1f in scm_iprlist (hdr=0x2abb76342f7a "(", exp=0x55b392a7d8e0, tlr=41, port=0x55b392370210, pstate=0x55b3923da780) at print.c:1348 #6 0x00002abb762ab01b in iprin1 (exp=0x55b392a7d8e0, port=0x55b392370210, pstate=0x55b3923da780) at print.c:617 #7 0x00002abb762aabae in scm_iprin1 (exp=0x55b392a7d8e0, port=0x55b392370210, pstate=0x55b3923da780) at print.c:546 #8 0x00002abb762abc5d in scm_prin1 (exp=0x55b392a7d8e0, port=0x55b392370210, writingp=1) at print.c:848 #9 0x00002abb762ad30d in scm_write (obj=0x55b392a7d8e0, port=0x55b392370210) at print.c:1461 #10 0x00002abb762f64f3 in vm_regular_engine (vm=0x55b391b80de0, program=0x55b391b71080, argv=0x7fff5a4f3a30, nargs=2) at vm-i-system.c:858 #11 0x00002abb76316f08 in scm_c_vm_run (vm=0x55b391b80de0, program=0x55b391b71080, argv=0x7fff5a4f3a20, nargs=2) at vm.c:761 #12 0x00002abb762464bb in scm_call_2 (proc=0x55b391b71080, arg1=0x55b392a7d8e0, arg2=0x55b392370210) at eval.c:493 #13 0x000055b38f6c6a14 in ly_scm_write_string[abi:cxx11](scm_unused_struct*) (s=0x55b392a7d8e0) at lily-guile.cc:59 #14 0x000055b38f6c8002 in print_scm_val[abi:cxx11](scm_unused_struct*) (val=0x55b392a7d8e0) at lily-guile.cc:392 #15 0x000055b38f6c8769 in type_check_assignment (sym=0x55b391dcf420, val=0x55b392a7d8e0, type_symbol=0x55b392540640) at lily-guile.cc:444 #16 0x000055b38f62a9f8 in Grob::internal_get_property_data (this=0x55b39474ea80, sym=0x55b391dcf420) at grob-property.cc:151 #17 0x000055b38f62add7 in Grob::internal_get_pure_property (this=0x55b39474ea80, sym=0x55b391dcf420, start=0, end=2147483647) at grob-property.cc:194 #18 0x000055b38f62aec4 in Grob::internal_get_maybe_pure_property (this=0x55b39474ea80, sym=0x55b391dcf420, pure=true, start=0, end=2147483647) at grob-property.cc:212 ... #88 ... ------------------------------------------------------------------------------- I can reproduce the issue and provide a more detailed backtrace if there is interest. MISC MINOR ISSUES. Some things I noticed during my journey: 1. scm/scheme-engravers.scm could use a run through scripts/auxiliar/fixscm.sh, the indentation is confusing right now. 2. lily/main.cc contains a conditional section guarded by GUILE2, but this code is never executed because the build system defines GUILEV2 (with the 'V'). 3. I don't remember the exact setup to reproduce the issue but one time I spotted a deprecation message: "`scm_take_str' is deprecated. Use scm_take_locale_stringn instead." And I see that there is one instance of "scm_take_str" in the code.