Let scheme-sandbox use system-repl with guile-2.x (issue 319520043 by thomasmorle...@gmail.com)
Reviewers: , Message: Please review Description: Let scheme-sandbox use system-repl with guile-2.x This fixes the warning returned by guile-2.x `scm-style-repl' in the default environment is deprecated. Find it in the `(ice-9 scm-style-repl)' module instead, or better yet, use the repl from `(system repl repl)'. Please review this at https://codereview.appspot.com/319520043/ Affected files (+5, -1 lines): M ly/scheme-sandbox.ly Index: ly/scheme-sandbox.ly diff --git a/ly/scheme-sandbox.ly b/ly/scheme-sandbox.ly index 7dec0dcd1c157aed892b4e152bd54bcc5d2643ac..1f233c0cfa46ce064fcedca2a47bde87408849f3 100644 --- a/ly/scheme-sandbox.ly +++ b/ly/scheme-sandbox.ly @@ -13,4 +13,8 @@ % requirements may be different. #(newline) -#(scm-style-repl) +#(if (guile-v2) + (begin + (use-modules (system repl repl)) + (start-repl)) + (scm-style-repl)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 5097: reach HorizontalBracketText through directed tweak (issue 317460043 by david.nales...@gmail.com)
Reviewers: ,
Message:
Please review. Thanks!
Description:
Issue 5097: reach HorizontalBracketText through directed tweak
HorizontalBracketText is now caused by HorizontalBracket, rather
than the same note-grouping event.
Fix a number of programming errors caused by commit for Issue
5064.
Please review this at https://codereview.appspot.com/317460043/
Affected files (+12, -11 lines):
M Documentation/changes.tely
M Documentation/snippets/new/analysis-brackets-with-labels.ly
M input/regression/horizontal-bracket-broken-texted.ly
M input/regression/horizontal-bracket-texted.ly
M lily/horizontal-bracket-engraver.cc
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
f205d0014cb270556d9d6c1bf52de721d4d0e13b..b9782edbb85486b12fc6cc9575408c4564771b0f
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -75,7 +75,7 @@ It is now possible to add text to analysis brackets
through the
{
\once \override HorizontalBracketText.text = "a"
c''\startGroup d''\stopGroup
- e''-\tweak text "a'" \startGroup d''\stopGroup
+ e''-\tweak HorizontalBracketText.text "a'" \startGroup d''\stopGroup
}
@end lilypond
Index: Documentation/snippets/new/analysis-brackets-with-labels.ly
diff --git a/Documentation/snippets/new/analysis-brackets-with-labels.ly
b/Documentation/snippets/new/analysis-brackets-with-labels.ly
index
30ae349b05bfc5960454af299f53ed464afa8a4f..93f65ea49d413b9853c63684242653b28f298824
100644
--- a/Documentation/snippets/new/analysis-brackets-with-labels.ly
+++ b/Documentation/snippets/new/analysis-brackets-with-labels.ly
@@ -27,12 +27,12 @@ Bracket text will be parenthesized after a line break.
\once\override HorizontalBracketText.text = "a'"
e''\startGroup d''\stopGroup
c''
- -\tweak text \markup \bold \huge "b" \startGroup
- -\tweak text "a" \startGroup
+ -\tweak HorizontalBracketText.text \markup \bold \huge "b" \startGroup
+ -\tweak HorizontalBracketText.text "a" \startGroup
d''\stopGroup
- e''-\tweak text "a'" \startGroup
+ e''-\tweak HorizontalBracketText.text "a'" \startGroup
d''\stopGroup\stopGroup
- c''-\tweak text foo \startGroup d'' e'' f''
+ c''-\tweak HorizontalBracketText.text foo \startGroup d'' e'' f''
\break
g'' a'' b'' c'''\stopGroup
}
Index: input/regression/horizontal-bracket-broken-texted.ly
diff --git a/input/regression/horizontal-bracket-broken-texted.ly
b/input/regression/horizontal-bracket-broken-texted.ly
index
1f8455261e169d2273c480908bd48e986c7ac5e5..00bcac987f38a33e759cb3d981f3d3432e466dbd
100644
--- a/input/regression/horizontal-bracket-broken-texted.ly
+++ b/input/regression/horizontal-bracket-broken-texted.ly
@@ -15,11 +15,12 @@ breaks.
{
c''
- -\tweak text \markup \draw-circle #1 #0.5 ##f \startGroup
- -\tweak text "a" \startGroup
+ -\tweak HorizontalBracketText.text \markup \draw-circle #1 #0.5 ##f
+ \startGroup
+ -\tweak HorizontalBracketText.text "a" \startGroup
d'' e'' f''
g'' a'' b'' c'''\stopGroup
- c'''-\tweak text "a'" \startGroup b'' a'' g''
+ c'''-\tweak HorizontalBracketText.text "a'" \startGroup b'' a'' g''
\break
f'' e'' d'' c''\stopGroup\stopGroup
}
Index: input/regression/horizontal-bracket-texted.ly
diff --git a/input/regression/horizontal-bracket-texted.ly
b/input/regression/horizontal-bracket-texted.ly
index
dc1a673a08423ec037cb2a4c30f44a7c73845327..0ab4520236bb2240b89af8f7b3473dbfe3dcee8d
100644
--- a/input/regression/horizontal-bracket-texted.ly
+++ b/input/regression/horizontal-bracket-texted.ly
@@ -21,8 +21,8 @@ usual nesting order of brackets.
\time 3/4
\key f \major
c4
- -\tweak text "contrasting period" \startGroup
- -\tweak text "a" \startGroup
+ -\tweak HorizontalBracketText.text "contrasting period" \startGroup
+ -\tweak HorizontalBracketText.text "a" \startGroup
a8( bes c f)
f4( e d)
c d8( c bes c)
Index: lily/horizontal-bracket-engraver.cc
diff --git a/lily/horizontal-bracket-engraver.cc
b/lily/horizontal-bracket-engraver.cc
index
1f176a321591a5c18b5446e506ed8182c3266199..860495750ad4124c5cff1c9c0b432800b668dfb6
100644
--- a/lily/horizontal-bracket-engraver.cc
+++ b/lily/horizontal-bracket-engraver.cc
@@ -94,7 +94,7 @@ Horizontal_bracket_engraver::process_music ()
{
Spanner *sp = make_spanner ("HorizontalBracket",
events_[k]->self_scm ());
- Spanner *hbt = make_spanner ("HorizontalBracketText",
events_[k]->self_scm ());
+ Spanner *hbt = make_spanner ("HorizontalBracketText", sp->self_scm
());
sp->set_object ("bracket-text", hbt->self_scm ());
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright update script
> On 21 Mar 2017, at 13:56, Urs Liska wrote: > So please review this script carefully and look for unintended behaviour… Depending on the setup you have, if the Flex & Bison source files are altered, their generated files might need to be regenerated. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Copyright update script
Am 21.03.2017 um 11:21 schrieb Urs Liska: > > Am 21.03.2017 um 11:11 schrieb Phil Holmes: >> "Urs Liska" wrote in message >> news:bbe7ead5-ea04-abcf-e08c-9a2ae3dce...@openlilylib.org... >>> lilypond --version >>> GNU LilyPond 2.19.57 >>> >>> Copyright (c) 1996--2015 by >>> Han-Wen Nienhuys >>> Jan Nieuwenhuizen >>> and others. >>> >>> This program is free software. It is covered by the GNU General Public >>> License and you are welcome to change it and/or distribute copies of it >>> under certain conditions. Invoke as `lilypond --warranty' for more >>> information. >>> >>> Spot the error? >>> >>> The copyright notice gives 2015 instead of 2017. I did a git grep on >>> Copyright but it seems there's much more to that than simply replacing >>> one occurence, as (varying) copyright statements are scattered >>> throughout the code. >>> >>> So, what's the procedure to update the copyright notice(s)? >>> >>> Urs >> I think this is the last time it was done: >> >> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=47db9a3883d726ca53e2133a3b2298f78dd6a32e >> > Ah, so it actually *does* involve changing all these occurences ... > Thanks for the pointer. > > This should be quite easily done with sed. > > BUT: If I'm not mistaken Copyright should only be updated when there are > actual changes to a file, isn't it? So globablly changing all occurences > to --2017 wouldn't be accurate but should only be applied to files that > have last been modified in 2017. > > If that's correct that we should maybe update files that have been > modified in 2016 and then those that have already been modified 2017. > > And if these assumptions are correct I suggest to create a script that > is regularly applied (maybe as part of the staging->master merge?) > checking for files that have been updated in the current year and have > an outdated copyright in it. I think we can't rely on contributors to > update the copyright of changed files manually as part of their commits, > and I think we shouldn't rely on "someone" doing the job occasionally. > Especially as Werner's commit from Jan 4 globablly updated everything > (which probably hadn't updated in these four days ...) > > Opinions? I've now uploaded a patch for review (https://codereview.appspot.com/320390043). This contains two commits, updating the copyright notice for files that have last been changed in 2016 and 2017. In addition (but hidden in the huge number of files) is the file scripts/auxiliar/update-copyright.sh. This is a script that finds the last commit of each tracked file and if that has been modified in the target year (or the current year) it does a sed replace of the copyright notice. It did so properly for the two commits, at least I did a number of random checks (i.e. checking if the affected file had actually been modified in the given year), but I'm absolutely not confident about. So please review this script carefully and look for unintended behaviour or even security issues. Also I find it's pretty slow and I think there should be a faster way to retrieve the interesting commits, but I didn't find any. If the script is found working (maybe after some updates) I think we should incorporate this in the automated process somewhere. If we'd want to run such an update automatically in the staging->master merge we can make it much faster by limiting the search to the files that differ between staging and master. Urs > Urs > -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Degenerate file access patterns
the repeating syscall is the read, on the same file descriptor. If
fontconfig failed a cache, you'd more likely see
open() = 6
read(6, .. )
close(6)
open() = 6
read(6, .. )
close(6)
I think.
I'll have a look again tonight. Maybe I can attach a debugger (my
machine has long lost the ability to compile lilypond. Sigh.)
On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG wrote:
>
>>> "The culprit is that the lilypond binary has a bit sub-optimal file
>>> access pattern (opening the same file thousands of times and
>>> reading it byte by byte, causing a syscall flood - nearly 500K
>>> lseek and read operations). On a local machine, because of this
>>> issue, it will spend about 1s in I/O syscalls, which is half of the
>>> total execution time. This currently does not play nice with our
>>> systems, getting it from 1s to over half a minute."
>
> Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
>
>> The font support is reading the same section of some font file over
>> and over again.
>>
>> $ cat f.ly
>> { c }
>> $ strace -e trace=open,read lilypond f.ly >& log ; grep OTTO log|wc
>> 9925953 90234
>
> On my box this is
>
> 1 6 88
>
>> $ grep OTTO log|head -10
>> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>> read(6, "OTTO\0\r\0\200\0\3\0PCFF
>> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
>>
>> the number of calls is apparently proportional to the number of glyphs
>> in the file:
>>
>> $ cat f.ly
>> \repeat unfold 100 { c }
>>
>> $ strace -e trace=open,read lilypond f.ly >& log ; grep OTTO log|wc
>> 40929 245575 3724501
>
> For me, it is again
>
> 1 6 88
>
>> Werner may have better hunches than I which code is really
>> responsible for this.
>
> Maybe a problem with fontconfig? Where is the location of
> fontconfig's database of available fonts on your system? This must be
> created in advance so that lilypond can access it. If it is missing,
> fontconfig tries to build it (which makes e.g. the first invocation of
> lilypond very slow on a Windows box since there is no global
> fontconfig database).
>
> Is it possible that fontconfig always fails so that it tries again and
> again?
>
>
> Werner
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
