Re: Patchy email
> makeinfo.notation.log states:
>
> out/notation/rhythms.texi:1961: misplaced {
> out/notation/rhythms.texi:1961: misplaced }
>
> The respective line appears to be:
>
> the note name uppercase @example{R}. Their duration is entered
>
> @example is not an in-text command but rather an environment.
> Backing out the respective commit from staging.
Oops, I gave wrong advice, sorry. Please do
s/@example/@samp/
and re-commit.
Werner
Re: Issue #5822 aftermath: download sizes are gone from web site
Francisco Vila writes: > El 24/3/20 a las 21:58, David Kastrup escribió: >>> Thanks, I patched it up. >> Partly. Several download links now contain b'...' visibly. >> > Unrelated. I saw this in my local build before the sizes script. Oh, I didn't even consider that the "sizes" script was at fault. It would not have affected that area of the files as far as I can tell. Any update likely would have gone bad without it as far as I can tell, due to Python problems. -- David Kastrup
Re: Issue #5822 aftermath: download sizes are gone from web site
El 24/3/20 a las 21:58, David Kastrup escribió: Thanks, I patched it up. Partly. Several download links now contain b'...' visibly. Unrelated. I saw this in my local build before the sizes script. -- Francisco Vila, Ph.D. - Badajoz (Spain) paconet.org , lilypond.es
Re: Patchy email
pat...@gnu.org writes:
> 22:26:26 (UTC) Begin LilyPond compile, previous commit at
> 83045b846acb4aaadf54373941a915c4c45fb522
> 22:26:34 Merged staging, now at: 83045b846acb4aaadf54373941a915c4c45fb522
> 22:26:35 Success:./autogen.sh --noconfigure
> 22:26:47 Success:/tmp/lilypond-autobuild/configure
> --enable-checking
> 22:26:51 Success:nice make clean
> 22:30:49 *** FAILED BUILD ***
> nice make -j9 CPU_COUNT=9
> Previous good commit: 786c3669ff08804465a89013d349fc745fd783c9
> Current broken commit: 83045b846acb4aaadf54373941a915c4c45fb522
> 22:30:49 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> 22:30:49 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 528, in handle_staging
> self.build (issue_id=issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 316, in build
> issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>
>
makeinfo.notation.log states:
out/notation/rhythms.texi:1961: misplaced {
out/notation/rhythms.texi:1961: misplaced }
The respective line appears to be:
the note name uppercase @example{R}. Their duration is entered
@example is not an in-text command but rather an environment.
Backing out the respective commit from staging.
All the best.
--
David Kastrup
Patchy email
22:26:26 (UTC) Begin LilyPond compile, previous commit at
83045b846acb4aaadf54373941a915c4c45fb522
22:26:34 Merged staging, now at:83045b846acb4aaadf54373941a915c4c45fb522
22:26:35Success:./autogen.sh --noconfigure
22:26:47Success:/tmp/lilypond-autobuild/configure
--enable-checking
22:26:51Success:nice make clean
22:30:49 *** FAILED BUILD ***
nice make -j9 CPU_COUNT=9
Previous good commit: 786c3669ff08804465a89013d349fc745fd783c9
Current broken commit: 83045b846acb4aaadf54373941a915c4c45fb522
22:30:49 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
22:30:49 Traceback (most recent call last):
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line
528, in handle_staging
self.build (issue_id=issue_id)
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line
316, in build
issue_id)
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line
266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
this_logfilename))
FailedCommand: Failed runner: nice make -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
Re: \compressFullBarRests should be renamed (issue 553750044 by v.villen...@gmail.com)
Reviewers: lemzwerg, Trevor Daniels,
Message:
Thanks guys, it means a lot! (Particularly from Trevor, who opened the
tracker page in the first place.)
Since I had both your LGTMs, I’ve pushed my patch onto staging as
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?h=staging&id=83045b846acb4aaadf54373941a915c4c45fb522
(then I realized the review window was technically still open until
tomorrow. Sorry about that.)
I’ve taken into account all your suggestions, with only a couple of
additional comments:
On 2020/03/21 18:27:07, lemzwerg wrote:
> I guess you refer to the `measure-length` property, right? If this is
correct,
> then you should write `@code{measure-length}` instead.
Hm. Measure-length was the wording used so far, but it’s really more of
an internal property than something we want to emphasize as
user-exposed; it’s not documented anywhere in the NR other than through
grob-properties.scm (not even a regtest). So I’d rather rewrite the
sentence as "the length of a measure", which is wordier but a bit
clearer I think.
> why @var?
’coz I keep misreading the CG :-/
On 2020/03/22 11:07:23, Trevor Daniels wrote:
> Thanks for picking this up and taking it over the finishing line,
Valentin.
My pleasure. Hopefully I’ll be able to contribute a bit more in the
next few weeks…
I hope you’re well; take good care of yourself… and stay away from
London!
Cheers,
V.
Description:
\compressFullBarRests should be renamed
- Rename \compressFullBarRests to \compressEmptyMeasures
as suggested by Trevor in #4375.
- Document the new command (and explain its difference
with \compressMMRests) by creating a new subsubsec in
NR 1.6.3 "Writing parts".
- Add index entries and links everywhere I can think of,
obviously starting with NR 1.2.2.3 "Full measure rests".
- Add convert rule and update syntax through the doc.
- Clarify the (in)famous progerror
"Multi_measure_rest::get_rods (): I am not spanned!"
since a) the function it refers to has changed anyway
b) its wording’s never been particularly helpful IMO.
- This patch will require po-update and makelsr at
some point (and snippets/new should be checked for
duplicate stuff now that the LSR’s been updated).
Please review this at https://codereview.appspot.com/553750044/
Affected files (+196, -98 lines):
M Documentation/changes.tely
M Documentation/de/changes.tely
M Documentation/de/notation/changing-defaults.itely
M Documentation/de/notation/rhythms.itely
M Documentation/de/notation/staff.itely
M Documentation/fr/changes.tely
M Documentation/it/changes.tely
M Documentation/ja/changes.tely
M Documentation/ja/notation/rhythms.itely
M Documentation/notation/ancient.itely
M Documentation/notation/changing-defaults.itely
M Documentation/notation/rhythms.itely
M Documentation/notation/staff.itely
M Documentation/snippets/multi-measure-rest-length-control.ly
M Documentation/snippets/new/multi-measure-rest-length-control.ly
A + Documentation/snippets/new/numbering-single-measure-rests.ly
M Documentation/snippets/numbering-single-measure-rests.ly
M input/regression/merge-rests-engraver.ly
M input/regression/merge-rests-magnify-staff.ly
M input/regression/multi-measure-rest-number-threshold.ly
M input/regression/rest-hanging-breve.ly
M lily/multi-measure-rest.cc
M ly/property-init.ly
M python/convertrules.py
Re[2]: Patch on dynamics and \RemoveEmptyStaves
Hi "Jean Abou Samra", you wrote My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Added as a Developer, with Update and Create permissions in addition to Read. Welcome aboard! Trevor
Re: Added transition lines for lyrics (issue 565750043 by davidgrant...@gmail.com)
LGTM
Can you verify that the patch description is correct? The current
version doesn't use -> anymore.
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc
File lily/vowel-transition.cc (right):
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc#newcode37
lily/vowel-transition.cc:37: SCM num_length = me->get_property
("minimum-length");
num suggests a number.
minimum_length ?
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc#newcode137
lily/vowel-transition.cc:137: w += -d * r->item_drul_[d]->extent
(r->item_drul_[d], X_AXIS)[-d];
this still looks strange, but if it's problem, it'll be contained within
the vowel-transition code, which is acceptable.
https://codereview.appspot.com/565750043/
Re: Issue #5822 aftermath: download sizes are gone from web site
Thanks, I patched it up.
On Tue, Mar 24, 2020 at 5:31 PM David Kastrup wrote:
>
> Francisco Vila writes:
>
> > El 24/3/20 a las 11:19, Francisco Vila escribió:
> >> El 24/3/20 a las 10:21, Han-Wen Nienhuys escribió:
> >>> b'@uref{http://lilypond.org/download/sources/v2.20/lilypond-2.20.0.tar.gz,
> >>> C\xc3\xb3digo fuente: lilypond-2.20.0.tar.gz}'
> >>>
> >>> Looks like these strings come from the source code itself.
> >>>
> >>> graham@lilypond-webserver:~/lilypond/build-website$ python --version
> >>> Python 2.7.12
> >>>
> >>> make.website should specify python3 rather than python.
> >>>
> >>> Do the string literals with unicode codepoints need to be declared
> >>> as u" " ?
> >>
> >> Should I save the file with a different encoding?
> >>
> > Uh-oh, now I see macro names, unexpanded, online.
>
> At the toplevel web page http://lilypond.org , no less.
>
>
>
> --
> David Kastrup
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Issue 5036: 128 beaming output not producing output as expected (?) (issue 559700043 by torsten.haemme...@web.de)
Proposed corrections/changes applied to input/regression/beaming-more-than-4-beams-normal-size.ly in my local branch. https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly File input/regression/beaming-more-than-4-beams-normal-size.ly (right): https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly#newcode7 input/regression/beaming-more-than-4-beams-normal-size.ly:7: smoothly as possible (standard-sized beams). The outide-staff beams will On 2020/03/24 18:54:34, lemzwerg wrote: > s/outide/outside/, and please avoid future tense. Done. "outside" corrected, "will not" replaced by "do not". https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly#newcode9 input/regression/beaming-more-than-4-beams-normal-size.ly:9: when it comes to beam quanting/scoring/positioning." On 2020/03/24 18:54:34, lemzwerg wrote: > Please add `/@` after the `/`s to allow line breaks (in the PDF output). Good point - done! But it's @/, --> "quanting/@/scoring/@/positioning". https://codereview.appspot.com/559700043/
Re: Patch on dynamics and \RemoveEmptyStaves
Hi Valentin, How strange it sounds to write you in English. Le 24/03/2020 à 19:24, Valentin Villenave a écrit :Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html Thanks for the pointer. My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Best regards, Jean Abou Samra
Re: Issue 5036: 128 beaming output not producing output as expected (?) (issue 559700043 by torsten.haemme...@web.de)
LGTM https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly File input/regression/beaming-more-than-4-beams-normal-size.ly (right): https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly#newcode7 input/regression/beaming-more-than-4-beams-normal-size.ly:7: smoothly as possible (standard-sized beams). The outide-staff beams will s/outide/outside/, and please avoid future tense. https://codereview.appspot.com/559700043/diff/545760043/input/regression/beaming-more-than-4-beams-normal-size.ly#newcode9 input/regression/beaming-more-than-4-beams-normal-size.ly:9: when it comes to beam quanting/scoring/positioning." Please add `/@` after the `/`s to allow line breaks (in the PDF output). https://codereview.appspot.com/559700043/
Re: Patch on dynamics and \RemoveEmptyStaves
On 3/24/20, Jean Abou Samra wrote: > I have the attached very simple patch for LilyPond. Could anyone please > guide me through the process for patch submission? Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html You may not need to use all that, but at least git and git-cl are strongly advised. Good luck, feel free to ask if you have any additional questions! Cheers, V.
Issue 5036: 128 beaming output not producing output as expected (?) (issue 559700043 by torsten.haemme...@web.de)
Reviewers: ,
Message:
Please review.
TIA,
Torsten
Description:
Issue 5036: 128 beaming output not producing output as expected (?)
In case of more than 4 normal-sized beams, a grid shift correction
will be applied to the outside-staff quants so that the inner beams
within the staff can be neatly aligned to the staff lines.
If all the beams fall outside the staff (cf. stem shortening), this
grid shift will ensure a consistent vertical alignment of beams.
See regtest beam-shortened-lengths.ly
regression beam-shortened-lengths.ly: new durations 256, 512, and 1024
added.
new regression beaming-more-than-4-beams-normal-size.ly
Please review this at https://codereview.appspot.com/559700043/
Affected files (+66, -7 lines):
M input/regression/beam-shortened-lengths.ly
A input/regression/beaming-more-than-4-beams-normal-size.ly
M lily/beam-quanting.cc
M lily/include/beam-scoring-problem.hh
Index: input/regression/beam-shortened-lengths.ly
diff --git a/input/regression/beam-shortened-lengths.ly
b/input/regression/beam-shortened-lengths.ly
index
057e602963f7386ff6db72911c342d036d7fe799..cc4d5fb78bcd4db0f2f093b08a219cde5beab8ff
100644
--- a/input/regression/beam-shortened-lengths.ly
+++ b/input/regression/beam-shortened-lengths.ly
@@ -1,4 +1,4 @@
-\version "2.16.0"
+\version "2.21.0"
\header{
texidoc="Beams in unnatural direction, have shortened stems, but do not look
too short."
@@ -8,5 +8,5 @@
\relative c'{
\stemUp
- f'4 f8[ f] f16[ f] f32[ f] f64[ f] f128[ f]
+ f'4 f8[ f] f16[ f] f32[ f] f64[ f] f128[ f] f256[ f] f512[ f] f1024[ f]
}
Index: input/regression/beaming-more-than-4-beams-normal-size.ly
diff --git a/input/regression/beaming-more-than-4-beams-normal-size.ly
b/input/regression/beaming-more-than-4-beams-normal-size.ly
new file mode 100644
index
..dc63626e771aab501059275441b10f2c016e0427
--- /dev/null
+++ b/input/regression/beaming-more-than-4-beams-normal-size.ly
@@ -0,0 +1,39 @@
+
+\version "2.21.0"
+
+\header{
+texidoc="
+Inside-staff beams should align with staff lines (sit, straddle, hang) as
+smoothly as possible (standard-sized beams). The outide-staff beams will
+not interfere with staff lines, so the inside-staff beams are more important
+when it comes to beam quanting/scoring/positioning."
+}
+
+\layout {
+ indent = 0
+ line-width = 100
+ ragged-right = ##t
+ \context {
+\Staff
+\omit Clef
+\omit TimeSignature
+ }
+}
+
+testMusic = {
+ \cadenzaOn
+ a8[ 8]
+ 16[ 16]
+ 32[ 32]
+ 64[ 64]
+ 128[ 128]
+ 256[ 256]
+ 512[ 512]
+ 1024[ 1024]
+ 128[ 64 32 16 8]
+}
+
+<<
+ \new Staff \testMusic
+ \new Staff \transpose a c''' \testMusic
+>>
Index: lily/beam-quanting.cc
diff --git a/lily/beam-quanting.cc b/lily/beam-quanting.cc
index
8657bac2f7eb66957aaa09fc2fa1112bb8c5d758..852cedf9063b8da4af014ac0d6969d03e6cd7d66
100644
--- a/lily/beam-quanting.cc
+++ b/lily/beam-quanting.cc
@@ -220,7 +220,8 @@ void Beam_scoring_problem::init_instance_variables (Grob
*me, Drul_array y
staff_space_ = Staff_symbol_referencer::staff_space (beam_);
beam_thickness_ = Beam::get_beam_thickness (beam_) / staff_space_;
line_thickness_ = Staff_symbol_referencer::line_thickness (beam_) /
staff_space_;
-
+ length_fraction_
+= robust_scm2double (beam_->get_property ("length-fraction"), 1.0);
// This is the least-squares DY, corrected for concave beams.
musical_dy_ = robust_scm2double (beam_->get_property ("least-squares-dy"),
0);
@@ -876,6 +877,17 @@ Beam_scoring_problem::generate_quants
(vector> *s
Real hang = 1.0 - (beam_thickness_ - line_thickness_) / 2;
Real base_quants [] = {straddle, sit, inter, hang};
int num_base_quants = int (sizeof (base_quants) / sizeof (Real));
+ int max_beam_count = std::max (edge_beam_counts_[LEFT],
+ edge_beam_counts_[RIGHT]);
+
+ /* for normal-sized beams, in case of more than 4 beams, the outer beam
+ used for generating quants will never interfere with staff lines, but
+ prevent the inside-staff beams from being neatly positioned.
+ A correctional grid_shift has to be applied to compensate. */
+ Real grid_shift = 0.0;
+ /* grid shift only makes sense for widened normal-sized beams: */
+ if (!is_knee_ && max_beam_count > 4 && length_fraction_ == 1.0)
+grid_shift = (max_beam_count - 4) * (1.0 - beam_translation_);
/*
Asymetry ? should run to <= region_size ?
@@ -890,10 +902,17 @@ Beam_scoring_problem::generate_quants
(vector> *s
for (vsize i = 0; i < unshifted_quants.size (); i++)
for (vsize j = 0; j < unshifted_quants.size (); j++)
{
-auto c
- = Beam_configuration::new_config (unquanted_y_,
-Interval (unshifted_quants[i],
- unshifted_quants[j]));
+Interval corr (0.0, 0.0);
+if (grid_shift)
+ for (LEFT_and_RIGHT (d))
+
Patch on dynamics and \RemoveEmptyStaves
Hi,
I have the attached very simple patch for LilyPond. Could anyone please
guide me through the process for patch submission?
Thanks,
Jean Abou Samra
>From 091ef8928c7c54ac658ad74165e1fa99137aab00 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra
Date: Tue, 24 Mar 2020 15:54:16 +0100
Subject: [PATCH] Add dynamic-interface to keepAliveInterfaces
This will prevent \Remove[All]EmptyStaves from removing
Dynamics contexts containing dynamics attached to spacer
rests but no actual notes (the standard use case
for a Dynamics context).
---
ly/engraver-init.ly | 1 +
1 file changed, 1 insertion(+)
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index 450795e298..4df8656690 100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -762,6 +762,7 @@ automatically when an output definition (a @code{\\score} or
bass-figure-interface
chord-name-interface
cluster-beacon-interface
+dynamic-interface
fret-diagram-interface
lyric-syllable-interface
note-head-interface
--
2.17.1
Re: Issue #5822 aftermath: download sizes are gone from web site
El 24/3/20 a las 11:19, Francisco Vila escribió:
El 24/3/20 a las 10:21, Han-Wen Nienhuys escribió:
b'@uref{http://lilypond.org/download/sources/v2.20/lilypond-2.20.0.tar.gz,
C\xc3\xb3digo fuente: lilypond-2.20.0.tar.gz}'
Looks like these strings come from the source code itself.
graham@lilypond-webserver:~/lilypond/build-website$ python --version
Python 2.7.12
make.website should specify python3 rather than python.
Do the string literals with unicode codepoints need to be declared as
u" " ?
Should I save the file with a different encoding?
Uh-oh, now I see macro names, unexpanded, online.
--
Francisco Vila, Ph.D. - Badajoz (Spain)
paconet.org , lilypond.es
Re: Issue #5822 aftermath: download sizes are gone from web site
El 24/3/20 a las 10:21, Han-Wen Nienhuys escribió:
b'@uref{http://lilypond.org/download/sources/v2.20/lilypond-2.20.0.tar.gz,
C\xc3\xb3digo fuente: lilypond-2.20.0.tar.gz}'
Looks like these strings come from the source code itself.
graham@lilypond-webserver:~/lilypond/build-website$ python --version
Python 2.7.12
make.website should specify python3 rather than python.
Do the string literals with unicode codepoints need to be declared as u" " ?
Should I save the file with a different encoding?
--
Francisco Vila, Ph.D. - Badajoz (Spain)
paconet.org , lilypond.es
Re: Issue #5822 aftermath: download sizes are gone from web site
On Mon, Mar 23, 2020 at 1:33 PM David Kastrup wrote:
>
> David Kastrup writes:
>
> > Han-Wen Nienhuys writes:
> >
> >> The website uses scripts that aren't directly checked out from
> >> savannah, so you can't directly compromise the webserver through code
> >> commits.
> >>
> >> I can update the scripts.
> >
> > Any chance of giving this a try now? The stuff is in master's script
> > now.
> >
> > Thanks!
>
> Ping?
I installed the script on Sunday
The website build tries to do incremental builds (which, given the
state of the build system isn't a great idea).
If I remove 'out-website', and build from scratch, I get
Traceback (most recent call last):
File "/home/graham/lilypond/trusted-scripts/create-weblinks-itexi.py",
line 602, in
make_download_source("downloadStableSource", VERSION_STABLE, lang)
File "/home/graham/lilypond/trusted-scripts/create-weblinks-itexi.py",
line 454, in make_download_source
make_macro(macroLang(name,lang), string)
File "/home/graham/lilypond/trusted-scripts/create-weblinks-itexi.py",
line 428, in make_macro
print(string.encode('utf-8'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
74: ordinal not in range(128)
website.make:225: recipe for target 'out-website/weblinks.itexi' failed
make: *** [out-website/weblinks.itexi] Error 1
a debug print suggests this comes from
>>> x =
>>> u"@uref{http://lilypond.org/download/sources/v2.20/lilypond-2.20.0.tar.gz,
>>> Código fuente: lilypond-2.20.0.tar.gz}"
>>> x[74]
'ó'
>>> ord(x[74])
243
>>> x.encode("utf-8")
b'@uref{http://lilypond.org/download/sources/v2.20/lilypond-2.20.0.tar.gz,
C\xc3\xb3digo fuente: lilypond-2.20.0.tar.gz}'
Looks like these strings come from the source code itself.
graham@lilypond-webserver:~/lilypond/build-website$ python --version
Python 2.7.12
make.website should specify python3 rather than python.
Do the string literals with unicode codepoints need to be declared as u" " ?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanweng
