Re: GUB lilypond build fails
> It now fails with a different file not found, but essentially still > the same: [...] OK. > If I try to locate the file we get: [...] Are these files displayable? You could try gv -nosafedir -nosafer foo.eps > A curious other problem which I'd not remarked on before is that a > little higher in the output I get: > > Operand stack: > (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) > (r) > [...] > Last OS error: No such file or directory Does this file exist? > When I was building from git master (just a lily build, not GUB) I > had the same error until I nuked the build directory and started > from scratch. I haven't dived into doing partial builds at all... Right now I'm working on improving fontconfig support to not use fonts outside of gub. After this step I'm going to write a script to convert the absolute file paths in the `test-output' tarball to relative paths so that you don't need a `NewGub' user for a complete build. Werner PS: Thanks for merging the pull request. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Monday, December 24, 2018 9:39 PM Subject: Re: GUB lilypond build fails It may be of note that an earlier (i.e. 6 months' earlier) successful run doesn't have the "invoking GS" line in its output. What does locate merge-rests-engraver say? Are files containing this name actually present for the old version? And what about newer version? Maybe a log file was created that contains more information? Werner It now failes with a different file not found, but essentially still the same: invoking gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.64-1/share/lilypond/current -r101 -dAutoRotatePages=/None -dPrinted=false -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/rest-positioning.png -dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.64-1/rest-positioning.eps -c quit Traceback (most recent call last): File "/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/scripts/build/output-distance.py", line 1358, in ? main () If I try to locate the file we get: locate rest-positioning.eps /home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/rest-positioning.eps A curious other problem which I'd not remarked on before is that a little higher in the output I get: Operand stack: (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) (r) 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:1213/1684(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 518 GPL Ghostscript 9.21: Unrecoverable error, exit code 1 When I was building from git master (just a lily build, not GUB) I had the same error until I nuked the build directory and started from scratch. Hmm. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makelsr
Having trouble with quoting properly here, so selectively editing:
Why is always \version "2.20.0" inserted? Doing convert-ly manually
will make for "2.21.0"
No idea at this point - I'd have to look at the input to convert-ly and the
output from the program, and that's long gone. I don't think it's a real
problem though.
Looking at this diff:
diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
index c1a36ec..900167f 100644
--- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
+++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
Why is the user generated variable partCombineUp/Down changed to a
lower-case "c"?
Looks like an offshoot of
https://sourceforge.net/p/testlilyissues/issues/4603/ where the LSR did not
have its descriptions all updated?
This a renamed snippet. But anyway, I can't find any snippet in git
which uses \markuplines.
Where does it come from?
I'm guessing that if git realises two files are essentially the same, it
changes one to the other rather than deleting one and creating the other?
--
Phil Holmes
- Original Message -
From: "Thomas Morley"
To: "Phil Holmes"
Cc: "lilypond-devel" ; "Malte Meyn"
Sent: Saturday, December 29, 2018 6:31 PM
Subject: Re: makelsr
Am Sa., 29. Dez. 2018 um 18:40 Uhr schrieb Phil Holmes
:
- Original Message -
From: "Malte Meyn"
To:
Sent: Saturday, December 29, 2018 9:29 AM
Subject: Re: makelsr
>
>
> Am 28.12.18 um 21:33 schrieb Phil Holmes:
>> A little late to the party, but I am almost certain that running
>> makelsr
>> to create an LSR patch and then (after testing with at least make, make
>> doc) and pushing that patch, and then putting up the doc patch for
>> review
>> is a perfectly accestable way to go. I've rather got out of the habit,
>> but I regularly used to run makelsr, eyeball it carefully (as in the
>> CG)
>> then push it without review. Extra files in the patch won't break the
>> build, only missing ones.
>
> I think that this sounds like the easiest way. That way every single
> commit ‘make’s without problems, there is no makelsr output in the
> review
> of the then following doc patch and one doesn’t have to mess with
> different branches. (Ok, I have to admit that I simply didn’t understand
> exactly how the solution with separate commits and a merge should look
> like. But it seems as if I’m not the only one.)
>
> Could you, Phil, please push such a makelsr run as you described? As
> long
> as I don’t have permission/trust from some of you to do this without
> review, I’d have to go the ‘long’ Rietveld way.
>
> Of course, if there are objections against this way, I’ll try to figure
> out how exactly the ‘separate-branches-and-merge-commit’ thing works.
Pushed to staging and then patchy-ed to master.
--
Phil Holmes
Hi Phil,
I did my own experiments with makelsr locally, because I wanted to
become more familiar with it.
In my local testings I stumbled across some possible issues. They are
visible in your patch as well
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=00f0ca84dbb015617f8ce36dd13db59bbfef8f11
(1)
Why is always \version "2.20.0" inserted? Doing convert-ly manually
will make for "2.21.0"
(2)
Looking at this diff:
diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
index c1a36ec..900167f 100644
--- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
+++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
@@ -48,7 +48,7 @@ fis b,2 @}
}
}
-partCombineUp =
+partcombineUp =
#(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
@@ -66,7 +66,7 @@ in the output to use upward stems."
#})
-partCombineDown = #
+partcombineDown = #
(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
Why is the user generated variable partCombineUp/Down changed to a
lower-case "c"?
Is the convert-rule insufficient?
(3)
Looking at this diff:
diff --git a/Documentation/snippets/markup-lines.ly
b/Documentation/snippets/markup-list.ly
index 6ff040e..3015055 100644
--- a/Documentation/snippets/markup-lines.ly
+++ b/Documentation/snippets/markup-list.ly
@@ -10,11 +10,11 @@
lsrtags = "text"
texidoc = "
-Text that can spread over pages is entered with the
-@code{\\markuplines} command.
+Text that can spread over pages is entered with the @code{\\markuplist}
+command.
"
- doctitle = "Markup lines"
+ doctitle = "Markup list"
} % begin verbatim
%% updated/modified by P.P.Schneider on Feb. 2014
This a renamed snippet. But anyway, I can't find any snippet in git
which uses \markuplines.
Where does it come from?
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-deve
Re: makelsr
Am Sa., 29. Dez. 2018 um 18:40 Uhr schrieb Phil Holmes :
>
> - Original Message -
> From: "Malte Meyn"
> To:
> Sent: Saturday, December 29, 2018 9:29 AM
> Subject: Re: makelsr
>
>
> >
> >
> > Am 28.12.18 um 21:33 schrieb Phil Holmes:
> >> A little late to the party, but I am almost certain that running makelsr
> >> to create an LSR patch and then (after testing with at least make, make
> >> doc) and pushing that patch, and then putting up the doc patch for review
> >> is a perfectly accestable way to go. I've rather got out of the habit,
> >> but I regularly used to run makelsr, eyeball it carefully (as in the CG)
> >> then push it without review. Extra files in the patch won't break the
> >> build, only missing ones.
> >
> > I think that this sounds like the easiest way. That way every single
> > commit ‘make’s without problems, there is no makelsr output in the review
> > of the then following doc patch and one doesn’t have to mess with
> > different branches. (Ok, I have to admit that I simply didn’t understand
> > exactly how the solution with separate commits and a merge should look
> > like. But it seems as if I’m not the only one.)
> >
> > Could you, Phil, please push such a makelsr run as you described? As long
> > as I don’t have permission/trust from some of you to do this without
> > review, I’d have to go the ‘long’ Rietveld way.
> >
> > Of course, if there are objections against this way, I’ll try to figure
> > out how exactly the ‘separate-branches-and-merge-commit’ thing works.
>
> Pushed to staging and then patchy-ed to master.
>
> --
> Phil Holmes
Hi Phil,
I did my own experiments with makelsr locally, because I wanted to
become more familiar with it.
In my local testings I stumbled across some possible issues. They are
visible in your patch as well
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=00f0ca84dbb015617f8ce36dd13db59bbfef8f11
(1)
Why is always \version "2.20.0" inserted? Doing convert-ly manually
will make for "2.21.0"
(2)
Looking at this diff:
diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
index c1a36ec..900167f 100644
--- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
+++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
@@ -48,7 +48,7 @@ fis b,2 @}
}
}
-partCombineUp =
+partcombineUp =
#(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
@@ -66,7 +66,7 @@ in the output to use upward stems."
>>
#})
-partCombineDown = #
+partcombineDown = #
(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
Why is the user generated variable partCombineUp/Down changed to a
lower-case "c"?
Is the convert-rule insufficient?
(3)
Looking at this diff:
diff --git a/Documentation/snippets/markup-lines.ly
b/Documentation/snippets/markup-list.ly
index 6ff040e..3015055 100644
--- a/Documentation/snippets/markup-lines.ly
+++ b/Documentation/snippets/markup-list.ly
@@ -10,11 +10,11 @@
lsrtags = "text"
texidoc = "
-Text that can spread over pages is entered with the
-@code{\\markuplines} command.
+Text that can spread over pages is entered with the @code{\\markuplist}
+command.
"
- doctitle = "Markup lines"
+ doctitle = "Markup list"
} % begin verbatim
%% updated/modified by P.P.Schneider on Feb. 2014
This a renamed snippet. But anyway, I can't find any snippet in git
which uses \markuplines.
Where does it come from?
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makelsr
- Original Message - From: "Malte Meyn" To: Sent: Saturday, December 29, 2018 9:29 AM Subject: Re: makelsr Am 28.12.18 um 21:33 schrieb Phil Holmes: A little late to the party, but I am almost certain that running makelsr to create an LSR patch and then (after testing with at least make, make doc) and pushing that patch, and then putting up the doc patch for review is a perfectly accestable way to go. I've rather got out of the habit, but I regularly used to run makelsr, eyeball it carefully (as in the CG) then push it without review. Extra files in the patch won't break the build, only missing ones. I think that this sounds like the easiest way. That way every single commit ‘make’s without problems, there is no makelsr output in the review of the then following doc patch and one doesn’t have to mess with different branches. (Ok, I have to admit that I simply didn’t understand exactly how the solution with separate commits and a merge should look like. But it seems as if I’m not the only one.) Could you, Phil, please push such a makelsr run as you described? As long as I don’t have permission/trust from some of you to do this without review, I’d have to go the ‘long’ Rietveld way. Of course, if there are objections against this way, I’ll try to figure out how exactly the ‘separate-branches-and-merge-commit’ thing works. Pushed to staging and then patchy-ed to master. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makelsr
Am 29.12.18 um 18:21 schrieb Phil Holmes: - Original Message - From: "Malte Meyn" To: Sent: Saturday, December 29, 2018 9:29 AM Subject: Re: makelsr Am 28.12.18 um 21:33 schrieb Phil Holmes: A little late to the party, but I am almost certain that running makelsr to create an LSR patch and then (after testing with at least make, make doc) and pushing that patch, and then putting up the doc patch for review is a perfectly accestable way to go. I've rather got out of the habit, but I regularly used to run makelsr, eyeball it carefully (as in the CG) then push it without review. Extra files in the patch won't break the build, only missing ones. I think that this sounds like the easiest way. That way every single commit ‘make’s without problems, there is no makelsr output in the review of the then following doc patch and one doesn’t have to mess with different branches. (Ok, I have to admit that I simply didn’t understand exactly how the solution with separate commits and a merge should look like. But it seems as if I’m not the only one.) Could you, Phil, please push such a makelsr run as you described? As long as I don’t have permission/trust from some of you to do this without review, I’d have to go the ‘long’ Rietveld way. Of course, if there are objections against this way, I’ll try to figure out how exactly the ‘separate-branches-and-merge-commit’ thing works. Pushed to staging and then patchy-ed to master. Thanks! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makelsr
Malte Meyn writes:
> Am 28.12.18 um 21:33 schrieb Phil Holmes:
>> A little late to the party, but I am almost certain that running
>> makelsr to create an LSR patch and then (after testing with at least
>> make, make doc) and pushing that patch, and then putting up the doc
>> patch for review is a perfectly accestable way to go. I've rather
>> got out of the habit, but I regularly used to run makelsr, eyeball
>> it carefully (as in the CG) then push it without review. Extra
>> files in the patch won't break the build, only missing ones.
>
> I think that this sounds like the easiest way. That way every single
> commit ‘make’s without problems, there is no makelsr output in the
> review of the then following doc patch and one doesn’t have to mess
> with different branches. (Ok, I have to admit that I simply didn’t
> understand exactly how the solution with separate commits and a merge
> should look like. But it seems as if I’m not the only one.)
>
> Could you, Phil, please push such a makelsr run as you described? As
> long as I don’t have permission/trust from some of you to do this
> without review, I’d have to go the ‘long’ Rietveld way.
>
> Of course, if there are objections against this way, I’ll try to
> figure out how exactly the ‘separate-branches-and-merge-commit’ thing
> works.
Here is an example of the result:
$ git log --graph 50b7d56d80c5842ce9bce3bcebe6b0491e37cee3
* commit 50b7d56d80c5842ce9bce3bcebe6b0491e37cee3
|\ Merge: 61275ff8fa 65e12a858d
| | Author: David Kastrup
| | Date: Wed Aug 14 09:22:16 2013 +0200
| |
| | Merge branch 'issue3487'
| |
| | Done as a merge commit because of invalid intermediate stages before
| | running scripts/auxiliar/update-with-convert-ly.sh
| |
| * commit 65e12a858de67b4d061c9fb595b81024fe22c6cf
| | Author: David Kastrup
| | Date: Fri Aug 9 18:55:12 2013 +0200
| |
| | Make regtest for shorthands (Issue 3487)
| |
| * commit 48a57a1c8feb426029e059d9fbf8aaf1b14f0ff8
| | Author: David Kastrup
| | Date: Tue Aug 6 21:34:01 2013 +0200
| |
| | Run scripts/auxiliar/update-with-convert-ly.sh
| |
| * commit 5c58da93f8859c3f15760631db4e63590e073e1e
| | Author: David Kastrup
| | Date: Sun Aug 4 11:32:09 2013 +0200
| |
| | Issue 3487: Make several special characters with or without backslash
"shorthands"
| |
| | Single non-alphanumeric ASCII characters not requiring special
| | treatment in lexer or parser can now be redefined like escaped
| | identifiers. The same holds for escaped non-alphanumeric ASCII
| | characters. The identifying name you use for redefining them is the
| | string corresponding to the full shorthand, in contrast to escaped
| | identifiers where the identifying name omits the initial backslash.
| |
| | Notable shorthands not treated specially in the parser (some of them
| | newly so) can be seen in the following definitions from
| | scm/declarations-init.ly:
| |
| | "|" = #(make-music 'BarCheck)
| | "[" = #(make-span-event 'BeamEvent START)
| | "]" = #(make-span-event 'BeamEvent STOP)
| | "~" = #(make-music 'TieEvent)
| | "(" = #(make-span-event 'SlurEvent START)
| | ")" = #(make-span-event 'SlurEvent STOP)
| | "\\!" = #(make-span-event 'CrescendoEvent STOP)
| | "\\(" = #(make-span-event 'PhrasingSlurEvent START)
| | "\\)" = #(make-span-event 'PhrasingSlurEvent STOP)
| | "\\>" = #(make-span-event 'DecrescendoEvent START)
| | "\\<" = #(make-span-event 'CrescendoEvent START)
| | "\\[" = #(make-span-event 'LigatureEvent START)
| | "\\]" = #(make-span-event 'LigatureEvent STOP)
| | "\\~" = #(make-music 'PesOrFlexaEvent)
| | "" = #(make-music 'VoiceSeparator)
| |
| * commit a7c14a5a83ddf2926895aa40cfdf50e7dcebf53c
| | Author: David Kastrup
| | Date: Sun Aug 4 12:21:09 2013 +0200
| |
| | Replace staccatissimo shorthand -| with -!
| |
| | The bar line character is used too prominently, and ! seems more
appropriate.
| |
| * commit 51697e92e7deb4281b6602928f7bbd3e99ee7b36
|/ Author: David Kastrup
| Date: Sun Aug 4 11:36:34 2013 +0200
|
| Make tempo range \tempo 20~30 be input as \tempo 20-30 instead
|
| \tempo's use of ~ was rather untypical for LilyPond. Letting it
| rather use @code{-} for ranges leaves just a single use for ties,
| making it feasible to make @code{~} definable by the user in a later
| commit.
|
* commit 61275ff8fa4fa01422b4dd6dfc0f6372c7d9cd5e
| Author: Phil Holmes
| Date: Sun Aug 11 21:48:26 2013 +0100
|
| Release: bump VERSION.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change \partcombine (et al.) to \partCombine (issue 369930043 by v.villen...@gmail.com)
Valentin, On 28/12/2018 11:11 am, lilyp...@maltemeyn.de wrote: On 2018/12/28 09:43:58, Valentin Villenave wrote: On 2018/12/21 17:50:33, Valentin Villenave wrote: > Correct convert rules. OK, pushed onto staging as 72067b395d947f1349ab8010f0592d45e52b8141. I think you should change the sourceforge issue (https://sourceforge.net/p/testlilyissues/issues/4603/): • click “Edit” at the top right • set “Status” to “Fixed” • unset “Patch” • set “Labels” to “Fixed_2_21_0” • mention the commit in the comment section at the bottom and click “Save” I did this for you as I was checking all the current trackers/Rietvelds anyway. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makelsr
Am 28.12.18 um 21:33 schrieb Phil Holmes: A little late to the party, but I am almost certain that running makelsr to create an LSR patch and then (after testing with at least make, make doc) and pushing that patch, and then putting up the doc patch for review is a perfectly accestable way to go. I've rather got out of the habit, but I regularly used to run makelsr, eyeball it carefully (as in the CG) then push it without review. Extra files in the patch won't break the build, only missing ones. I think that this sounds like the easiest way. That way every single commit ‘make’s without problems, there is no makelsr output in the review of the then following doc patch and one doesn’t have to mess with different branches. (Ok, I have to admit that I simply didn’t understand exactly how the solution with separate commits and a merge should look like. But it seems as if I’m not the only one.) Could you, Phil, please push such a makelsr run as you described? As long as I don’t have permission/trust from some of you to do this without review, I’d have to go the ‘long’ Rietveld way. Of course, if there are objections against this way, I’ll try to figure out how exactly the ‘separate-branches-and-merge-commit’ thing works. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
