Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/11 23:49:23, dak wrote:
> [...]
> GNU LilyPond 2.21.0
> cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No
such file or
> directory
> test results in ./out/test-output-distance
> Traceback (most recent call last):
> File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1561, in
>
> main ()
> File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1546, in
> main
> run_tests ()
> File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1495, in
> run_tests
> test_compare_tree_pairs ()
> File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1330, in
> test_compare_tree_pairs
> system ('cp 19.sub{-*.signature,.ly,-1.eps,.log,.profile}
dir1/subdir/')
> File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1304, in
> system
> assert stat == 0, (stat, x)
> AssertionError: (256, 'cp
19.sub{-*.signature,.ly,-1.eps,.log,.profile}
> dir1/subdir/')
> make[1]: *** [/tmp/lilypond-autobuild/./scripts/build/GNUmakefile:19:
> local-test] Error 1
> make: *** [/tmp/lilypond-autobuild/GNUmakefile.in:328: test] Error 2
This looks like bash-ism which might explain why it works for Han-Wen
and me. I agree with him that disabling the local-test invocation in
GNUmakefile.in is probably the easiest solution for now. These tests
haven't run for years, so we'll definitely be fine without them for a
few more days.
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 08:01:03, hahnjo wrote:
> On 2020/03/11 23:49:23, dak wrote:
> > [...]
> > GNU LilyPond 2.21.0
> > cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No
such file
> or
> > directory
> > test results in ./out/test-output-distance
> > Traceback (most recent call last):
> > File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1561,
> in
> >
> > main ()
> > File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1546,
> in
> > main
> > run_tests ()
> > File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1495,
> in
> > run_tests
> > test_compare_tree_pairs ()
> > File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1330,
> in
> > test_compare_tree_pairs
> > system ('cp 19.sub{-*.signature,.ly,-1.eps,.log,.profile}
dir1/subdir/')
> > File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1304,
> in
> > system
> > assert stat == 0, (stat, x)
> > AssertionError: (256, 'cp
19.sub{-*.signature,.ly,-1.eps,.log,.profile}
> > dir1/subdir/')
> > make[1]: ***
[/tmp/lilypond-autobuild/./scripts/build/GNUmakefile:19:
> > local-test] Error 1
> > make: *** [/tmp/lilypond-autobuild/GNUmakefile.in:328: test] Error 2
>
> This looks like bash-ism which might explain why it works for Han-Wen
and me. I
> agree with him that disabling the local-test invocation in
GNUmakefile.in is
> probably the easiest solution for now. These tests haven't run for
years, so
> we'll definitely be fine without them for a few more days.
dak@lola:/usr/local/tmp/lilypond$ dash
$ echo {1,2,3}
{1,2,3}
$
Ah yes. Since /bin/sh defaults to dash on Ubuntu (or doesn't it any
more?), I wonder how this escaped testing.
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 09:22:09, dak wrote:
> On 2020/03/12 08:01:03, hahnjo wrote:
> > This looks like bash-ism which might explain why it works for
Han-Wen and me.
> I
> > agree with him that disabling the local-test invocation in
GNUmakefile.in is
> > probably the easiest solution for now. These tests haven't run for
years, so
> > we'll definitely be fine without them for a few more days.
>
> dak@lola:/usr/local/tmp/lilypond$ dash
> $ echo {1,2,3}
> {1,2,3}
> $
>
> Ah yes. Since /bin/sh defaults to dash on Ubuntu (or doesn't it any
more?), I
> wonder how this escaped testing.
It wasn't tested, that's the point: The initial patch only received a
'test-baseline' and no 'check' which didn't trigger the python tests.
'patchy-staging' only runs 'test' as far as I understand, so that patch
landed in master. Now this patch adds it to 'test' which means it's the
first time somebody runs it on Ubuntu.
I'm for disabling it again until it receives sufficient testing. Either
in current master removing 'local-check' from
'scripts/build/GNUmakefile' or taking the updated patchset from here
without the 'local-test' recursion in GNUmakefile.in
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
Hello
What exactly am I supposed to be testing?
With or without make check?
I am struggling with all this 'back and forth' and with patches getting
created and tested by different people (worksforme, doesn't work for me
etc.).
Could someone put something in the tracker to know what I am to expect?
Thanks.
James
On 12/03/2020 09:22, d...@gnu.org wrote:
On 2020/03/12 08:01:03, hahnjo wrote:
On 2020/03/11 23:49:23, dak wrote:
[...]
GNU LilyPond 2.21.0
cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No
such file
or
directory
test results in ./out/test-output-distance
Traceback (most recent call last):
File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1561,
in
main ()
File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1546,
in
main
run_tests ()
File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1495,
in
run_tests
test_compare_tree_pairs ()
File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1330,
in
test_compare_tree_pairs
system ('cp 19.sub{-*.signature,.ly,-1.eps,.log,.profile}
dir1/subdir/')
File "/tmp/lilypond-autobuild/scripts/build/output-distance.py",
line 1304,
in
system
assert stat == 0, (stat, x)
AssertionError: (256, 'cp
19.sub{-*.signature,.ly,-1.eps,.log,.profile}
dir1/subdir/')
make[1]: ***
[/tmp/lilypond-autobuild/./scripts/build/GNUmakefile:19:
local-test] Error 1
make: *** [/tmp/lilypond-autobuild/GNUmakefile.in:328: test] Error 2
This looks like bash-ism which might explain why it works for Han-Wen
and me. I
agree with him that disabling the local-test invocation in
GNUmakefile.in is
probably the easiest solution for now. These tests haven't run for
years, so
we'll definitely be fine without them for a few more days.
dak@lola:/usr/local/tmp/lilypond$ dash
$ echo {1,2,3}
{1,2,3}
$
Ah yes. Since /bin/sh defaults to dash on Ubuntu (or doesn't it any
more?), I wonder how this escaped testing.
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 09:33:43, hahnjo wrote:
> On 2020/03/12 09:22:09, dak wrote:
> > On 2020/03/12 08:01:03, hahnjo wrote:
> > > This looks like bash-ism which might explain why it works for
Han-Wen and
> me.
> > I
> > > agree with him that disabling the local-test invocation in
GNUmakefile.in is
> > > probably the easiest solution for now. These tests haven't run for
years, so
> > > we'll definitely be fine without them for a few more days.
> >
> > dak@lola:/usr/local/tmp/lilypond$ dash
> > $ echo {1,2,3}
> > {1,2,3}
> > $
> >
> > Ah yes. Since /bin/sh defaults to dash on Ubuntu (or doesn't it any
more?), I
> > wonder how this escaped testing.
>
> It wasn't tested, that's the point: The initial patch only received a
> 'test-baseline' and no 'check' which didn't trigger the python tests.
> 'patchy-staging' only runs 'test' as far as I understand, so that
patch landed
> in master. Now this patch adds it to 'test' which means it's the first
time
> somebody runs it on Ubuntu.
> I'm for disabling it again until it receives sufficient testing.
Either in
> current master removing 'local-check' from 'scripts/build/GNUmakefile'
or taking
> the updated patchset from here without the 'local-test' recursion in
> GNUmakefile.in
To be clear: I'm not blaming anyone, least of all James; 'test-baseline'
really was the best way possible to test the initial patch before
Han-Wen added compatibility code. IMO this just happens to be a bad
coincidence of two problems: The test not running from 'make test', but
only 'make check'; and the test not working on Ubuntu at all.
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 09:52:31, hahnjo wrote:
> On 2020/03/12 09:33:43, hahnjo wrote:
> > On 2020/03/12 09:22:09, dak wrote:
> > > On 2020/03/12 08:01:03, hahnjo wrote:
> > > > This looks like bash-ism which might explain why it works for
Han-Wen and
> > me.
> > > I
> > > > agree with him that disabling the local-test invocation in
GNUmakefile.in
> is
> > > > probably the easiest solution for now. These tests haven't run
for years,
> so
> > > > we'll definitely be fine without them for a few more days.
> > >
> > > dak@lola:/usr/local/tmp/lilypond$ dash
> > > $ echo {1,2,3}
> > > {1,2,3}
> > > $
> > >
> > > Ah yes. Since /bin/sh defaults to dash on Ubuntu (or doesn't it
any more?),
> I
> > > wonder how this escaped testing.
> >
> > It wasn't tested, that's the point: The initial patch only received
a
> > 'test-baseline' and no 'check' which didn't trigger the python
tests.
> > 'patchy-staging' only runs 'test' as far as I understand, so that
patch landed
> > in master. Now this patch adds it to 'test' which means it's the
first time
> > somebody runs it on Ubuntu.
> > I'm for disabling it again until it receives sufficient testing.
Either in
> > current master removing 'local-check' from
'scripts/build/GNUmakefile' or
> taking
> > the updated patchset from here without the 'local-test' recursion in
> > GNUmakefile.in
>
> To be clear: I'm not blaming anyone, least of all James;
'test-baseline' really
> was the best way possible to test the initial patch before Han-Wen
added
> compatibility code. IMO this just happens to be a bad coincidence of
two
> problems: The test not running from 'make test', but only 'make
check'; and the
> test not working on Ubuntu at all.
Well, there is not a whole lot to be gained from blaming anybody anyway
when there was no damage (not that the blame game makes a lot of sense
when there is damage). Patch needs work (whether it contains a problem
itself or triggers a preexisting one that needs to be fixed in order for
the patch to go ahead), but it was caught before the problem affected
everyone.
https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 10:03:22, dak wrote: > Patch needs work (whether it contains a problem itself or triggers a > preexisting one that needs to be fixed in order for the patch to go ahead), but > it was caught before the problem affected everyone. I think it already affects everyone: Current master fails 'make check' if you're building out-of-tree. That's a stopper for testing new patches. So we have to decide now to either a) give this updated patch a try with patchy or b) just disable the test by removing 'local-check' in scripts/build/GNUmakefile. If it's still broken when I come home, I'll do b). https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On Thu, Mar 12, 2020 at 10:37 AM wrote: > > Hello > > What exactly am I supposed to be testing? > > With or without make check? > > I am struggling with all this 'back and forth' and with patches getting > created and tested by different people (worksforme, doesn't work for me > etc.). This is exactly why I have been advocating tests based on docker containers, so we have a common understanding of when something passes tests and when not. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
Han-Wen Nienhuys writes: > On Thu, Mar 12, 2020 at 10:37 AM wrote: >> >> Hello >> >> What exactly am I supposed to be testing? >> >> With or without make check? >> >> I am struggling with all this 'back and forth' and with patches getting >> created and tested by different people (worksforme, doesn't work for me >> etc.). > > This is exactly why I have been advocating tests based on docker > containers, so we have a common understanding of when something passes > tests and when not. You'll find that a docker container also needs instructions of what exactly to test for. -- David Kastrup
Re: Added transition lines for lyrics (issue 565750043 by davidgrant...@gmail.com)
On 2020/03/12 12:06:06, davidsg wrote: > Rename to vowel-transition-event Trying again with the name 'vowel transition' (sustained consonants are mentioned explicitly in the docs). Perhaps this is an OK compromise? Updated docs accordingly and added a couple of regtests, including one documenting properties minimum-length-includes-bounds and minimum-length-includes-padding. https://codereview.appspot.com/565750043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 12/03/2020 10:32, Han-Wen Nienhuys wrote: On Thu, Mar 12, 2020 at 10:37 AM wrote: Hello What exactly am I supposed to be testing? With or without make check? I am struggling with all this 'back and forth' and with patches getting created and tested by different people (worksforme, doesn't work for me etc.). This is exactly why I have been advocating tests based on docker containers, so we have a common understanding of when something passes tests and when not. Actually, with all due respect, this is neither here nor there is it? I had said that tests for this (or other issues) had failed make check and was told - one case by yourself - that this was expected and not to run the make check. So this is why I put '...make test-baseline..' in my 'passes ...' note in the tracker. I think Jonas queried it once (which led to me learning how to make my set of tests more robust for build file patches). I don't hava a problem following instructions, and you developers make the final decisisons, so I have to assume there is a good reason I am told to ignore a test. Would docker give us this 'proverbial canary' or would it turn into 'worksforme' when someone tried to build their own version of LP on a vanilla base of Linux ;) James
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > Would docker give us this 'proverbial canary' or would it turn into > 'worksforme' when someone tried to build their own version of LP on a > vanilla base of Linux? > Docker would eliminate 'worksforme' type issues yes. >
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 2020/03/12 10:10:23, hahnjo wrote: > On 2020/03/12 10:03:22, dak wrote: > > Patch needs work (whether it contains a problem itself or triggers a > > preexisting one that needs to be fixed in order for the patch to go ahead), > but > > it was caught before the problem affected everyone. > > I think it already affects everyone: Current master fails 'make check' if you're > building out-of-tree. That's a stopper for testing new patches. So we have to > decide now to either a) give this updated patch a try with patchy or b) just > disable the test by removing 'local-check' in scripts/build/GNUmakefile. If it's > still broken when I come home, I'll do b). Pushed to staging: commit 92b75c19c78b426d453c1e8ec7cda39a0d552fb3 Author: Jonas Hahnfeld Date: Thu Mar 12 13:35:28 2020 +0100 Deactivate self-tests of output-distance.py This doesn't work for out-of-tree builds because the script is not copied over. Furthermore the test is broken on Ubuntu with dash due to bash-isms in the system() commands. diff --git a/scripts/build/GNUmakefile b/scripts/build/GNUmakefile index d406b38b59..8cdd6c22d7 100644 --- a/scripts/build/GNUmakefile +++ b/scripts/build/GNUmakefile @@ -14,6 +14,3 @@ include $(depth)/make/stepmake.make #INSTALLATION_OUT_FILES1=$(outdir)/lilypond-login $(outdir)/lilypond-profile all: $(INSTALLATION_FILES) - -local-check: - $(PYTHON) output-distance.py --test https://codereview.appspot.com/563730043/
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
Am Donnerstag, den 12.03.2020, 11:32 +0100 schrieb Han-Wen Nienhuys: > On Thu, Mar 12, 2020 at 10:37 AM < > pkx1...@posteo.net > > wrote: > > Hello > > > > What exactly am I supposed to be testing? > > > > With or without make check? > > > > I am struggling with all this 'back and forth' and with patches getting > > created and tested by different people (worksforme, doesn't work for me > > etc.). > > This is exactly why I have been advocating tests based on docker > containers, so we have a common understanding of when something passes > tests and when not. In this case, it would have been strictly worse: It would have passed patchy-staging and master would still be broken for native Ubuntu. Unless you propose to test all possible setups in Docker which is impossible, I'd say. Jonas signature.asc Description: This is a digitally signed message part
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On 12/03/2020 12:36, Kevin Barry wrote: Would docker give us this 'proverbial canary' or would it turn into 'worksforme' when someone tried to build their own version of LP on a vanilla base of Linux? Docker would eliminate 'worksforme' type issues yes And yet ... isn't this exactly what happend? It worked for Han-wen but not for me. So who is right? I'll defer you to Jonas' reply to this thread just after yours. I'm all for conistent build envs but at least make sure your testing is actually ... err testing what it should be testing. Containers don't protect against that. James
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On Thu, 12 Mar 2020 at 12:48, wrote: > I'll defer you to Jonas' reply to this thread just after yours. > > I'm all for conistent build envs but at least make sure your testing is > actually ... err testing what it should be testing. > > Containers don't protect against that. A docker container is the same everywhere; the underlying distribution or other differences in people's setups don't make any difference. So if there was an agreed dockerfile that would simplify discussions about 'worksforme'. Jonas's reply referred to native Ubuntu, which misses Han-Wen's point I think. The container provides a consistent and portable environment (providing you have docker installed, it's basically a single text file). If we had some kind of official docker/container image/file for these tests, then if something passes there, but not on someone's personalised distribution then it would be on that person to figure it out (or just use the docker container). And developers would have a single target for testing. Kevin
Re: a new way to build LilyPond binary releases
Il giorno mer 11 mar 2020 alle 16:56, Jonas Hahnfeld ha scritto: This is _not_ (yet) a proposal to switch over, but rather my ideas about a possible replacement. So take this as a request for feedback and testing as well as general discussion. I've just made a test and was able to build the Linux package in about half a hour. I think it took me years to be able to run GUB successfully :-) I have a suggestion: what about providing an install/uninstall script with a configurable prefix option? Did you test some real files? I've tried the full package and it works fine with minimal examples, but not with real project files. For example, here's an error (with both full and "slim" binaries): lilypond 2.21.0 [miniatura4.ly] in avvio... Processing `/home/fede/Documenti/spartiti/GammanossiM/miniatura4.ly' Parsing... Interpreting music... Interpreting music...[8][16][24] Preprocessing graphical objects...Backtrace: 9 (apply-smob/1 #) In ice-9/eval.scm: 293:34 8 (_ #(#(#) #)) 619:8 7 (_ #(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?)) In srfi/srfi-1.scm: 640:9 6 (for-each # ?) In ice-9/eval.scm: 619:8 5 (_ #(#(#(#(#(# ?) ?) ?) ?) ?)) In ice-9/boot-9.scm: 829:9 4 (catch _ _ # ?) In unknown file: 3 (ly:parse-file "/home/fede/Documenti/spartiti/Gammanoss?") 2 (ly:book-process # #< Output_def> #< Output_def> #) In ice-9/eval.scm: 259:9 1 (_ #(#(#(#) #) #)) In unknown file: 0 (ly:grob-array-length #) ERROR: In procedure ly:grob-array-length: In procedure ly:grob-array-length: Wrong type argument in position 1 (expecting Grob_array): #
Re: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 14:18 +0100 schrieb Federico Bruni:
> Il giorno mer 11 mar 2020 alle 16:56, Jonas Hahnfeld <
> hah...@hahnjo.de
> >
> ha scritto:
> > This is _not_ (yet) a proposal to switch over, but rather my ideas
> > about a possible replacement. So take this as a request for feedback
> > and testing as well as general discussion.
>
> I've just made a test and was able to build the Linux package in about
> half a hour. I think it took me years to be able to run GUB
> successfully :-)
>
> I have a suggestion: what about providing an install/uninstall script
> with a configurable prefix option?
The usage of plain archives has the advantage that the user can install
and move the files anywhere, without invoking any installer. That is by
design, but maybe there's a valid use case for installers that I'm
missing? Uninstalling is just as easy as deleting the files (the
scripts from GUB don't do more than that anyhow).
> Did you test some real files?
> I've tried the full package and it works fine with minimal examples,
> but not with real project files.
> For example, here's an error (with both full and "slim" binaries):
>
> lilypond 2.21.0 [miniatura4.ly] in avvio...
> Processing `/home/fede/Documenti/spartiti/GammanossiM/miniatura4.ly'
> Parsing...
> Interpreting music...
> Interpreting music...[8][16][24]
> Preprocessing graphical objects...Backtrace:
>9 (apply-smob/1 #)
> In ice-9/eval.scm:
>293:34 8 (_ #(#(#) #))
> 619:8 7 (_ #(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?))
> In srfi/srfi-1.scm:
> 640:9 6 (for-each # ?)
> In ice-9/eval.scm:
> 619:8 5 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
> 829:9 4 (catch _ _ # ?)
> In unknown file:
>3 (ly:parse-file "/home/fede/Documenti/spartiti/Gammanoss?")
>2 (ly:book-process # #< Output_def> #< Output_def> #)
> In ice-9/eval.scm:
> 259:9 1 (_ #(#(#(#) #) #))
> In unknown file:
>0 (ly:grob-array-length #)
>
> ERROR: In procedure ly:grob-array-length:
> In procedure ly:grob-array-length: Wrong type argument in position 1
> (expecting Grob_array): #
I did test some more advanced files than "{ c' }", but apparently not
complicated enough. I think this one actually has the same root case as
Karlin reported: I traced this back to the garbage collector freeing
objects prematurely. Apparently it's not really happy that I made it
unaware of threading...
I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 😉
Jonas
signature.asc
Description: This is a digitally signed message part
Re: a new way to build LilyPond binary releases
Am Mittwoch, den 11.03.2020, 19:17 +0100 schrieb Jonas Hahnfeld:
> Am Mittwoch, den 11.03.2020, 11:38 -0500 schrieb Karlin High:
> > On Wed, Mar 11, 2020 at 10:56 AM Jonas Hahnfeld <
> > hah...@hahnjo.de
> >
> > > wrote:
> > > Please let me know if something doesn't work at all
> >
> > That sounds like an interesting project. I tested the Windows version,
> > and it works. I got a PDF from compiling { c' } as a hello-world test.
> >
> > Now, is this supposed to be a 64-bit application? I can easily get
> > confused about 64-bit MinGW vs 64-bit applications on it. LilyPond's
> > 32-bit Windows version is susceptible to out-of-memory crashes.
>
> Yes, this is supposed to be a 64bit executable and I had really hoped
> that it puts an end to the out-of-memory crashes.
>
> > <
> > https://lists.gnu.org/archive/html/lilypond-user/2018-12/msg00408.html
> >
> >
> > I tried the test in that thread, on both the official LilyPond 2.19.84
> > and the binary you shared. Both crash, but with slightly different
> > error messages:
> >
> > Offical 2.19.84 says...
> > Preprocessing graphical objects...terminate called after throwing an
> > instance of 'std::bad_alloc'
> > what(): std::bad_alloc
> >
> > This binary from GitHub says...
> > Preprocessing graphical objects...Exception code=0xc005 flags=0x0
> > at 0x005056A5. Access violation - attempting to read data at
> > address 0x
>
> Hmm, that's not really better, is it? The good thing is that I can
> reproduce a crash with the binary for GNU/Linux, so it's got to do with
> the way the scripts build statically. I'll take a look.
As I just replied to Frederico, I found the issue with how the scripts
build bdw-gc. Now the linux version is able to compile a somewhat
reduced version of the linked example. The mingw executable now also
works under wine, but it'd be great if you could test the full version
(and possibly other large scores) on your system. The link is:
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Re: a new way to build LilyPond binary releases
On 2020-03-12 14:39, Jonas Hahnfeld wrote:
I did test some more advanced files than "{ c' }", but apparently not
complicated enough. I think this one actually has the same root case as
Karlin reported: I traced this back to the garbage collector freeing
objects prematurely. Apparently it's not really happy that I made it
unaware of threading...
I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 😉
I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a
reasonably large project (some 80+ page output string quartet score) and
it runs without any error messages and produces correct output, with the
exception of Unicode characters in titling that are completely garbled,
but that's perhaps a known issue.
When untarring the package, I happened to notice that the tar ball
contains a number of soft links to
/home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/...
/Mats
Re: a new way to build LilyPond binary releases
On 2020-03-12 16:17, Mats Bengtsson wrote:
On 2020-03-12 14:39, Jonas Hahnfeld wrote:
I did test some more advanced files than "{ c' }", but apparently not
complicated enough. I think this one actually has the same root case as
Karlin reported: I traced this back to the garbage collector freeing
objects prematurely. Apparently it's not really happy that I made it
unaware of threading...
I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 😉
I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on
a reasonably large project (some 80+ page output string quartet score)
and it runs without any error messages and produces correct output,
with the exception of Unicode characters in titling that are
completely garbled, but that's perhaps a known issue.
When untarring the package, I happened to notice that the tar ball
contains a number of soft links to
/home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/...
I just spotted another oddity towards the end of the log printouts that
probably also is related to the Guile updates:
"Finding the ideal number of pages...Omitting the destination on a call
to format is deprecated.
Pass #f as the destination, before the format string.
Fitting music on 84 or 85 pages..."
/Mats
Re: Re: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson:
> On 2020-03-12 14:39, Jonas Hahnfeld wrote:
> > I did test some more advanced files than "{ c' }", but apparently not
> > complicated enough. I think this one actually has the same root case as
> > Karlin reported: I traced this back to the garbage collector freeing
> > objects prematurely. Apparently it's not really happy that I made it
> > unaware of threading...
> > I've just finished building anew, please give
> > https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12
> > a
> > try. Or rebuild with the updated scripts 😉
>
> I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a
> reasonably large project (some 80+ page output string quartet score) and
> it runs without any error messages and produces correct output, with the
> exception of Unicode characters in titling that are completely garbled,
> but that's perhaps a known issue.
Works for me, at least title = "äöüß" works. But maybe that is related
to the problem below...
> When untarring the package, I happened to notice that the tar ball
> contains a number of soft links to
> /home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/...
Ouch, TIL: "cp -r" and "tar" preserve symlinks, at least on Linux. The
files are there in the packages for FreeBSD and zip archives can't
handle them, so mingw is also fine. As a temporary matter, I've
uploaded fontconfig-2.13.1-conf.tar.gz to the GitHub release. Could you
extract that to lilypond/etc/fonts/conf.d and overwrite the links?
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
Kevin Barry writes: > On Thu, 12 Mar 2020 at 12:48, wrote: >> I'll defer you to Jonas' reply to this thread just after yours. >> >> I'm all for conistent build envs but at least make sure your testing >> is actually ... err testing what it should be testing. >> >> Containers don't protect against that. > > A docker container is the same everywhere; the underlying distribution > or other differences in people's setups don't make any difference. So > if there was an agreed dockerfile that would simplify discussions > about 'worksforme'. Frankly, I am more sympathetic to "worksforme" discussions among developers than telling users "worksforme". Where is the point in being able to tell users that no developer will reproduce their problem? I'd rather have an error popping up for at least some developers than for none. -- 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".
Re: a new way to build LilyPond binary releases
On 2020-03-12 16:41, Jonas Hahnfeld wrote: Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson: I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a reasonably large project (some 80+ page output string quartet score) and it runs without any error messages and produces correct output, with the exception of Unicode characters in titling that are completely garbled, but that's perhaps a known issue. Works for me, at least title = "äöüß" works. But maybe that is related to the problem below... Sorry for the noise, I had managed to ruin the UTF-8 encoding in my input file by mistake. When untarring the package, I happened to notice that the tar ball contains a number of soft links to /home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/... Ouch, TIL: "cp -r" and "tar" preserve symlinks, at least on Linux. The files are there in the packages for FreeBSD and zip archives can't handle them, so mingw is also fine. As a temporary matter, I've uploaded fontconfig-2.13.1-conf.tar.gz to the GitHub release. Could you extract that to lilypond/etc/fonts/conf.d and overwrite the links? With a corrected input file, I get the correct output no matter if I keep the broken soft links or replace them by your new tar ball, at least I couldn't spot any difference. By the way, I have also tested the non-full version of your package with the same successful result, all on Ubuntu 18.04TLS. /Mats
Re: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 17:30 +0100 schrieb Mats Bengtsson: > On 2020-03-12 16:41, Jonas Hahnfeld wrote: > > Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson: > > > I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a > > > reasonably large project (some 80+ page output string quartet score) and > > > it runs without any error messages and produces correct output, with the > > > exception of Unicode characters in titling that are completely garbled, > > > but that's perhaps a known issue. > > Works for me, at least title = "äöüß" works. But maybe that is related > > to the problem below... > Sorry for the noise, I had managed to ruin the UTF-8 encoding in my > input file by mistake. Ah, thanks for letting me know. > > > When untarring the package, I happened to notice that the tar ball > > > contains a number of soft links to > > > /home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/... > > Ouch, TIL: "cp -r" and "tar" preserve symlinks, at least on Linux. The > > files are there in the packages for FreeBSD and zip archives can't > > handle them, so mingw is also fine. As a temporary matter, I've > > uploaded fontconfig-2.13.1-conf.tar.gz to the GitHub release. Could you > > extract that to lilypond/etc/fonts/conf.d and overwrite the links? > > With a corrected input file, I get the correct output no matter if I > keep the broken soft links or replace them by your new tar ball, at > least I couldn't spot any difference. Ok good. It's probably still better to have it corrected using "cp -RL" instead of "cp -r" (see latest commit). Jonas signature.asc Description: This is a digitally signed message part
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > Frankly, I am more sympathetic to "worksforme" discussions among > developers than telling users "worksforme". Where is the point in being > able to tell users that no developer will reproduce their problem? > > I'd rather have an error popping up for at least some developers than > for none. > This sounds like you are saying it's better for the situation to be a mess for developers so that they can better help users deal with the same mess, therefore we should leave things as they are. Installing docker and building an image is much easier than setting up a working build environment for LilyPond now. I think it would be a win for both devs and users. Kevin
Re: Re[2]: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
> Jonas, you wrote
> > I've just finished building anew, please give
> > https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
> > try. Or rebuild with the updated scripts 😉
> I've tried compiling several of my files running this version of yours inside
> Frescobaldi on my Windows 10 system. All worked fine except one. Here's
> a MWE which shows the fault I found:
>
> \version "2.20.0"
> %\version "2.21.0"
> { R1\fermataMarkup }
>
> The error is
>
> C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5:
>
> error: unknown escaped string: `\fermataMarkup'
> { R1
> \fermataMarkup }
>
>
> It works fine in Fresco with 2.20.0 and earlier releases.
Correct, because \fermataMarkup is no more in master / what will become
2.21.0 since the following commit:
commit 4424b153c016632e69a7cd7cae6425024cee49fb
Author: Malte Meyn
Date: Fri Apr 19 12:15:57 2019 +0200
Issue 5511/2: deprecate \fermataMarkup
This removes \fermataMarkup and adds a convert-ly rule.
The bad thing is that we don't have documentation on this yet without
an unstable release 😞
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
Kevin Barry writes: >> >> >> Frankly, I am more sympathetic to "worksforme" discussions among >> developers than telling users "worksforme". Where is the point in being >> able to tell users that no developer will reproduce their problem? >> >> I'd rather have an error popping up for at least some developers than >> for none. >> > > This sounds like you are saying it's better for the situation to be a mess > for developers so that they can better help users deal with the same mess, > therefore we should leave things as they are. I say that having a developer monoculture doesn't buy as anything since we still need to provide for a multitude of users. > Installing docker and building an image is much easier than setting up > a working build environment for LilyPond now. Get a LilyPond source .deb and do sudo apt build-deps on it. Afterwards you have a working build environment. > I think it would be a win for both devs and users. I don't really see the underlying logic. Users should consider it a win when the developers state "you are no longer allowed to run LilyPond natively, get a docker container", and you want to convince developers to stop using and developing LilyPond natively on their systems because it will be so much easier to maintain a virtual layer in between? We have had the LilyDev VM for a long time now. It has seen some use, but not overwhelmingly much, and the reasons for that are pretty much the same for newer virtualisation methods. -- David Kastrup
Re[2]: a new way to build LilyPond binary releases
Jonas, you wrote
I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 😉
I've tried compiling several of my files running this version of yours
inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:
\version "2.20.0"
%\version "2.21.0"
{ R1\fermataMarkup }
The error is
C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5
<0>:
error: unknown escaped string: `\fermataMarkup'
{ R1
\fermataMarkup }
It works fine in Fresco with 2.20.0 and earlier releases.
Trevor
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > I say that having a developer monoculture doesn't buy as anything since > we still need to provide for a multitude of users. > We are talking about testing builds right? If a user gets as far as "I need to test changes I made to the source code" then surely it would be better to have something to point them to than to say "let's see if one of the devs ever ran into the same problem you are having". It also means we could have some confidence when figuring out if a problem is environmental or not. Having some kind of official dockerfile isn't pushing a monoculture: it actually makes it easier for people to run whatever OS they want and not have to keep it in line with LilyPond build requirements. It would make building on Windows or MacOS easier since there are prepackaged docker apps for both. > > Installing docker and building an image is much easier than setting up > > a working build environment for LilyPond now. > > Get a LilyPond source .deb and do sudo apt build-deps on it. Afterwards > you have a working build environment. > That would not work on my system. Making everyone use .deb is another kind of monoculture. > I don't really see the underlying logic. Users should consider it a win > when the developers state "you are no longer allowed to run LilyPond > natively, get a docker container", and you want to convince developers > to stop using and developing LilyPond natively on their systems because > it will be so much easier to maintain a virtual layer in between? > I wouldn't ever suggest that we make running LilyPond require docker. I thought this discussion was about testing builds. > We have had the LilyDev VM for a long time now. It has seen some use, > but not overwhelmingly much, and the reasons for that are pretty much > the same for newer virtualisation methods. > I disagree. The docker image specification could be a simple text file that is kept in the LilyPond repo, and people can build it if they want. Tests could build it and use that image for testing, etc, etc. Kevin >
Re: Added transition lines for lyrics (issue 565750043 by davidgrant...@gmail.com)
LGTM now, thanks! https://codereview.appspot.com/565750043/diff/557620047/scm/define-music-types.scm File scm/define-music-types.scm (right): https://codereview.appspot.com/565750043/diff/557620047/scm/define-music-types.scm#newcode685 scm/define-music-types.scm:685: . ((description . "A transition between lyric syllables.") Maybe s/transition/vowel transition/ ? https://codereview.appspot.com/565750043/
Re: a new way to build LilyPond binary releases
On 3/12/2020 8:43 AM, Jonas Hahnfeld wrote: The mingw executable now also works under wine, but it'd be great if you could test the full version (and possibly other large scores) on your system. The link is: https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 I'll give it a try, thanks. It may go a day or so until I have a response. -- Karlin High Missouri, USA
Re: Re: Re[2]: a new way to build LilyPond binary releases
On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
I've tried compiling several of my files running this version of yours inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:
\version "2.20.0"
%\version "2.21.0"
{ R1\fermataMarkup }
The error is
C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5:
error: unknown escaped string: `\fermataMarkup'
{ R1
\fermataMarkup }
It works fine in Fresco with 2.20.0 and earlier releases.
Correct, because \fermataMarkup is no more in master / what will become
2.21.0 since the following commit:
commit 4424b153c016632e69a7cd7cae6425024cee49fb
Author: Malte Meyn
Date: Fri Apr 19 12:15:57 2019 +0200
Issue 5511/2: deprecate \fermataMarkup
This removes \fermataMarkup and adds a convert-ly rule.
The bad thing is that we don't have documentation on this yet without
an unstable release 😞
The good thing is that if you run convert-ly on the file, it will
automatically update to the new syntax! :-)
/Mats
Re[5]: a new way to build LilyPond binary releases
Mats wrote12/03/2020 19:35:09
On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
I've tried compiling several of my files running this version of yours inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:
\version "2.20.0"
%\version "2.21.0"
{ R1\fermataMarkup }
The error is
C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5:
error: unknown escaped string: `\fermataMarkup'
{ R1
\fermataMarkup }
It works fine in Fresco with 2.20.0 and earlier releases.
Correct, because \fermataMarkup is no more in master / what will become
2.21.0 since the following commit:
commit 4424b153c016632e69a7cd7cae6425024cee49fb
Author: Malte Meyn
Date: Fri Apr 19 12:15:57 2019 +0200
Issue 5511/2: deprecate \fermataMarkup
This removes \fermataMarkup and adds a convert-ly rule.
The bad thing is that we don't have documentation on this yet without
an unstable release 😞
The good thing is that if you run convert-ly on the file, it will automatically
update to the new syntax! :-)
Thanks Jonas and Mats.
I couldn't get convert-ly to work in Frescobaldi - not sure why yet.
I had tried that first and it (mis-)lead me to believe there was no
syntax change.
But at least I can see in the relevant documentation how to fix it.
(I still keep my LilyPond source repository more or less up to date,
even though
my days of hacking the docs are over. And having read the docs I do
remember
seeing the change now!)
Trevor
Re: Re[5]: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor:
>
> Mats wrote12/03/2020 19:35:09
> > On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
> > > Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
> > > > I've tried compiling several of my files running this version of yours
> > > > inside
> > > > Frescobaldi on my Windows 10 system. All worked fine except one. Here's
> > > > a MWE which shows the fault I found:
> > > >
> > > > \version "2.20.0"
> > > > %\version "2.21.0"
> > > > { R1\fermataMarkup }
> > > >
> > > > The error is
> > > >
> > > > C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5:
> > > > error: unknown escaped string: `\fermataMarkup'
> > > > { R1
> > > > \fermataMarkup }
> > > >
> > > >
> > > > It works fine in Fresco with 2.20.0 and earlier releases.
> > >
> > > Correct, because \fermataMarkup is no more in master / what will become
> > > 2.21.0 since the following commit:
> > > commit 4424b153c016632e69a7cd7cae6425024cee49fb
> > > Author: Malte Meyn <
> > > lilyp...@maltemeyn.de
> > > >
> > > Date: Fri Apr 19 12:15:57 2019 +0200
> > >
> > > Issue 5511/2: deprecate \fermataMarkup
> > > This removes \fermataMarkup and adds a convert-ly rule.
> > >
> > > The bad thing is that we don't have documentation on this yet without
> > > an unstable release 😞
> >
> > The good thing is that if you run convert-ly on the file, it will
> > automatically update to the new syntax! :-)
>
> Thanks Jonas and Mats.
>
> I couldn't get convert-ly to work in Frescobaldi - not sure why yet.
The mingw archive doesn't contain a Python interpreter, so you'd need
this separately on Windows. As far as I remember, GUB put it next to
lilypond.exe but there were no wrapper scripts or such. How exactly did
you try to run it?
signature.asc
Description: This is a digitally signed message part
Re[7]: a new way to build LilyPond binary releases
Jonas, you wrote 12/03/2020 20:57:00 Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor: I couldn't get convert-ly to work in Frescobaldi - not sure why yet. The mingw archive doesn't contain a Python interpreter, so you'd need this separately on Windows. As far as I remember, GUB put it next to lilypond.exe but there were no wrapper scripts or such. How exactly did you try to run it? I simply used the Frescobaldi "Tools/Update with convert-ly". It produces no messages - as it normally does if there is nothing to convert (I think - it's a long time since I last ran it). Trevor
Re: Re[7]: a new way to build LilyPond binary releases
Am Donnerstag, den 12.03.2020, 21:26 + schrieb Trevor: > > Jonas, you wrote 12/03/2020 20:57:00 > > > Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor: > > > I couldn't get convert-ly to work in Frescobaldi - not sure why yet. > > > > The mingw archive doesn't contain a Python interpreter, so you'd need > > this separately on Windows. As far as I remember, GUB put it next to > > lilypond.exe but there were no wrapper scripts or such. How exactly did > > you try to run it? > I simply used the Frescobaldi "Tools/Update with convert-ly". > It produces no messages - as it normally does if there is nothing to > convert (I think - it's a long time since I last ran it). Frescobaldi expects a Python interpreter distributed with LilyPond, see https://github.com/frescobaldi/frescobaldi/blob/master/frescobaldi_app/lilypondinfo.py#L398 So for now, I think it's enough to download for example an "Embedded Distribution" from python.org and extract into the bin/ folder. Not sure if I should add it to the archive directly... Jonas signature.asc Description: This is a digitally signed message part
Add #f to format in lilypond-book.itely (issue 553690043 by thomasmorle...@gmail.com)
Reviewers: , Description: Add #f to format in lilypond-book.itely In the defiition of oly:create-toc-file a simple string is wished for the local outfilename. Thus add #f after format in: (outfilename (format "~a.toc" output-name)) Please review this at https://codereview.appspot.com/553690043/ Affected files (+8, -8 lines): M Documentation/cs/usage/lilypond-book.itely M Documentation/de/usage/lilypond-book.itely M Documentation/es/usage/lilypond-book.itely M Documentation/fr/usage/lilypond-book.itely M Documentation/hu/usage/lilypond-book.itely M Documentation/it/usage/lilypond-book.itely M Documentation/ja/usage/lilypond-book.itely M Documentation/usage/lilypond-book.itely Index: Documentation/cs/usage/lilypond-book.itely diff --git a/Documentation/cs/usage/lilypond-book.itely b/Documentation/cs/usage/lilypond-book.itely index b1f7c11e31e99256d00cd6b2dce8d9f5aecf1808..01fb1f5635b1fca73439c9a7868c019ec37240dc 100644 --- a/Documentation/cs/usage/lilypond-book.itely +++ b/Documentation/cs/usage/lilypond-book.itely @@ -1222,7 +1222,7 @@ sich alle in der selben LilyPond-Datei befinden. (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) - (outfilename (format "~a.toc" output-name)) + (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) Index: Documentation/de/usage/lilypond-book.itely diff --git a/Documentation/de/usage/lilypond-book.itely b/Documentation/de/usage/lilypond-book.itely index 5c40607888bd94be8b4be78a4275e2972d921bc0..22e0e54e332999140d38abb774d29db8d6d4baf7 100644 --- a/Documentation/de/usage/lilypond-book.itely +++ b/Documentation/de/usage/lilypond-book.itely @@ -1357,7 +1357,7 @@ sich alle in der selben LilyPond-Datei befinden. (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) - (outfilename (format "~a.toc" output-name)) + (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) Index: Documentation/es/usage/lilypond-book.itely diff --git a/Documentation/es/usage/lilypond-book.itely b/Documentation/es/usage/lilypond-book.itely index bcfa83db246a1fbc108efe0184d69abd6714ef5a..f109b8695bf870b09cb436250aa8c4aca0d7ec1b 100644 --- a/Documentation/es/usage/lilypond-book.itely +++ b/Documentation/es/usage/lilypond-book.itely @@ -1430,7 +1430,7 @@ del mismo archivo de salida de lilypond. (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) - (outfilename (format "~a.toc" output-name)) + (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) Index: Documentation/fr/usage/lilypond-book.itely diff --git a/Documentation/fr/usage/lilypond-book.itely b/Documentation/fr/usage/lilypond-book.itely index 277242dfeafa0394ef6e816c64f34e71953f9ac2..f8023ff53f4cdc74dc28e43011630dc1fbf11569 100644 --- a/Documentation/fr/usage/lilypond-book.itely +++ b/Documentation/fr/usage/lilypond-book.itely @@ -1411,7 +1411,7 @@ comportant tous les mouvement de la partition. (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) - (outfilename (format "~a.toc" output-name)) + (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) Index: Documentation/hu/usage/lilypond-book.itely diff --git a/Documentation/hu/usage/lilypond-book.itely b/Documentation/hu/usage/lilypond-book.itely index 24268b3b054b7630864fe560321d918fdc4a884a..c32d316d4dea2b406e113ebbc11693d852bc0f6f 100644 --- a/Documentation/hu/usage/lilypond-book.itely +++ b/Documentation/hu/usage/lilypond-book.itely @@ -1181,7 +1181,7 @@ output file. (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) - (outfilename (format "~a.toc" output-name)) + (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) Index: Documentation/it/usage/lily
Re: a new way to build LilyPond binary releases
Am Do., 12. März 2020 um 16:22 Uhr schrieb Mats Bengtsson
:
>
>
> On 2020-03-12 16:17, Mats Bengtsson wrote:
> >
> > On 2020-03-12 14:39, Jonas Hahnfeld wrote:
> >> I did test some more advanced files than "{ c' }", but apparently not
> >> complicated enough. I think this one actually has the same root case as
> >> Karlin reported: I traced this back to the garbage collector freeing
> >> objects prematurely. Apparently it's not really happy that I made it
> >> unaware of threading...
> >> I've just finished building anew, please give
> >> https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
> >> try. Or rebuild with the updated scripts
> >
> > I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on
> > a reasonably large project (some 80+ page output string quartet score)
> > and it runs without any error messages and produces correct output,
> > with the exception of Unicode characters in titling that are
> > completely garbled, but that's perhaps a known issue.
> >
> > When untarring the package, I happened to notice that the tar ball
> > contains a number of soft links to
> > /home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/...
>
>
> I just spotted another oddity towards the end of the log printouts that
> probably also is related to the Guile updates:
>
> "Finding the ideal number of pages...Omitting the destination on a call
> to format is deprecated.
> Pass #f as the destination, before the format string.
Likely.
(format ...) nowadays always needs a destination-port.
>From the guile-manual
"
Scheme Procedure: format dest fmt arg …
Write output specified by the fmt string to dest. dest can be an
output port, #t for current-output-port (see Default Ports), or #f to
return the output as a string.
"
I just noticed such a missing #f in lilypond-book.itely:
https://sourceforge.net/p/testlilyissues/issues/5843/
Cheers,
Harm
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On Mar 12, 2020, at 08:36, Kevin Barry wrote: > >> Would docker give us this 'proverbial canary' or would it turn into >> 'worksforme' when someone tried to build their own version of LP on a >> vanilla base of Linux? >> > Docker would eliminate 'worksforme' type issues yes. The direction of this statement is correct, but the magnitude is not. The kernel is still provided by the host. Getting a crash report can be frustrating when the guest's behavior hinges on /proc features that the host OS has configured appropriately for the host, not the guest. Configurable security restrictions can make the debugging experience different from one installation to another. Et cetera. — Dan
