Re: regular patchy staging
Hello, 2012/3/2 Janek Warchoł janek.lilyp...@gmail.com: On Sat, Mar 3, 2012 at 12:01 AM, Graham Percival gra...@percival-music.ca wrote: Any advance on having a regular patchy staging compile? like, every 6 hours or something? Currently it's David who is running Patchy (i am amazed by his involvement), and he lacks processing power to do this more often. I think Patchy could be improved a bit to be more user-friendly (that's just my personal opinion), thus allowing James (for example) to run it more easily. I want to get back to work on Patchy, but i'm totally buried under GSoC and other things; i cannot magically multiply my time despite my sincere wishes to the contrary :( I am back from my break (and the internet connection is much better if still not great - tops out at 300kb/s which is ok) and have been going through the emails that had come in the last week or so, I'm just about caught up and have done a few doc tracker items to boot, and have been trying to get patchy working following the instructions in the CG - they are still a bit vague but we can build on that. I'd saw that David and Graham and (i think) Phil and Janek (?) had been running patchy so figured it was now covered and had been trying to broaden my knowledge elsewhere (for example working out how to update LilyDev - I see a few requests in that area), but if there is still a need for me to run patchy - if only to take the load off - I'll refocus on that. I still have some fundamental questions about the scripts. Patchy actually seems to be two things not one and I am still unclear on this aspect. There is a 'script' that checks Patch-new against current master and there is a 'script' that merges staging with master. Is it required (desired) to run both aspects for me or should I just be doing one of them? It isn't clear from the files I download which does what and which I don't need if I only want to do one or the other. I am working this weekend but will have some free time in the evening. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unexpected accidental following cadenza
Hello,
On 3 March 2012 08:11, David Bobroff bobr...@centrum.is wrote:
I got a surprise when a cancelling accidental was printed at the beginning
of a measure. This happened following a cadenza. Short example below:
%%%
\version 2.14.2
\relative c'
{
\key c \major
\cadenzaOn
fis4 g a b
\cadenzaOff
\bar |
f
}
%%%
Is this a bug?
Could be..
If you use
%%%
\version 2.14.2
\relative c'
{
\key c \major
\cadenzaOn
fis4 g a
b
\cadenzaOff
\bar |
fis fis fis fis
f f f f
}
%%%
Then the natural symbol doesn't occur in the *next* measure.
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
On Sat, Mar 3, 2012 at 9:16 AM, James pkx1...@gmail.com wrote: I am back from my break (and the internet connection is much better if still not great - tops out at 300kb/s which is ok) and have been going through the emails that had come in the last week or so, I'm just about caught up and have done a few doc tracker items to boot, and have been trying to get patchy working following the instructions in the CG - they are still a bit vague but we can build on that. I'd saw that David and Graham and (i think) Phil and Janek (?) Not quite. I still have some fundamental questions about the scripts. Patchy actually seems to be two things not one and I am still unclear on this aspect. There is a 'script' that checks Patch-new against current master and there is a 'script' that merges staging with master. Is it required (desired) to run both aspects for me or should I just be doing one of them? It isn't clear from the files I download which does what and which I don't need if I only want to do one or the other. GrahamDavid, when i said that i'd like to make Patchy more user-friendly i meant to make it so straightforward that these questions wouldn't have been asked. I will volunteer to do this, but i have to finish GSoC thing first. (sorry for not providing answers to your questions, James, i don't know them at the moment) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
James pkx1...@gmail.com writes: I'd saw that David and Graham and (i think) Phil and Janek (?) had been running patchy so figured it was now covered There is staging-patchy. It does not require manual work, just processing power, but lots of that. It is not bothered if people run it in parallel (the worst that happens is that cycles are wasted). I still run it occasionally, and it is rather a holdup on my setup. Then there is test-patchy. It takes less processing power, but the results need to be evaluated manually and an appropriate comment made. It does not matter if people run it in parallel, but it is a bit of a nuisance if the manual commenting overlaps. staging-patchy and test-patchy currently use the same testing directory (why?), so it will lead to problems if both are run on the same machine at the same time. I still have some fundamental questions about the scripts. Patchy actually seems to be two things not one and I am still unclear on this aspect. There is a 'script' that checks Patch-new against current master and there is a 'script' that merges staging with master. Is it required (desired) to run both aspects for me or should I just be doing one of them? lilypond-patchy-staging (?) is the more important one since it takes more processing power and less manual intervention. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
Hello, On 3 March 2012 09:03, David Kastrup d...@gnu.org wrote: James pkx1...@gmail.com writes: I'd saw that David and Graham and (i think) Phil and Janek (?) had been running patchy so figured it was now covered There is staging-patchy. It does not require manual work, just processing power, but lots of that. It is not bothered if people run it in parallel (the worst that happens is that cycles are wasted). I still run it occasionally, and it is rather a holdup on my setup. Then there is test-patchy. It takes less processing power, but the results need to be evaluated manually and an appropriate comment made. It does not matter if people run it in parallel, but it is a bit of a nuisance if the manual commenting overlaps. staging-patchy and test-patchy currently use the same testing directory (why?), so it will lead to problems if both are run on the same machine at the same time. I still have some fundamental questions about the scripts. Patchy actually seems to be two things not one and I am still unclear on this aspect. There is a 'script' that checks Patch-new against current master and there is a 'script' that merges staging with master. Is it required (desired) to run both aspects for me or should I just be doing one of them? lilypond-patchy-staging (?) is the more important one since it takes more processing power and less manual intervention. OK thanks, I'll focus on that one. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
Snip all and some updates. For some background to patchy, see http://lilypond.org/doc/v2.15/Documentation/contributor/patchy FWIW, it's normally me that runs patchy-staging, not David. I know he does run it when needed, but I have been running it generally twice a day for the last few weeks. My routine is to check when I get up and if there's a difference between staging and master, I boot my build machine and run patchy over breakfast. Ditto early evening. So far, it has required zero intervention from me, which is good if it's a breakfast run - I wouldn't normally have the time to investigate problems then. Setting it up was completely painless. The only reason I don't run it more often is (a) it doesn't seem needed - 12 hours to migrate to master doesn't seem excessive; (b) I can't run it most days, with college and CAB; and (c) I don't want to leave that machine running unattended. It takes 17 minutes to run on the fast box. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Fri, Mar 2, 2012 at 8:26 PM, Pavel Roskin pro...@gnu.org wrote: Hello! On Tue, 28 Feb 2012 15:14:29 -0800 Joe Neeman joenee...@gmail.com wrote: Don't use ly:axis-group-interface::add-element, because stems don't implement the axis-group-interface. (Removing this will also remove the axes warning.) Instead, use ly:grob-set-parent!. You'll probably want to set both the X parent and the Y parent. Then the X and Y offsets of new-stem will be measured relative to stem (instead of relative to the whole system, which is the default). OK, this is what I have now. I think it's a pretty good solution. Looks good! The code is capable of creating multiple cross-staff stems per moment. It's possible to connect more than two stems as long as they lie on the same line. There is a workaround for a problem with Lilypond 2.14 that has a flag as part of the stem. I spent way too much time on the issue, but it helped me learn Scheme and Lilypond. That's ok; now that you're an expert, your next feature will be much easier... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
On Sat, Mar 03, 2012 at 09:56:33AM +0100, Janek Warchoł wrote: On Sat, Mar 3, 2012 at 9:16 AM, James pkx1...@gmail.com wrote: I still have some fundamental questions about the scripts. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? GrahamDavid, when i said that i'd like to make Patchy more user-friendly i meant to make it so straightforward that these questions wouldn't have been asked. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Janek, tell me exactly which step in that process is unclear. Making vague claims of it should be more user-friendly does not help. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bugreports section commit
commit d1141b3e90d6ae768f9349806a1e33f1026d90aa Author: Janek Warchoł janek.lilyp...@gmail.com Date: Tue Feb 14 09:42:58 2012 +0100 web: rephrase bugreports section According to Graham's favorite rule (perfection is attained when there's nothing more to delete) i'm rephrasing bugreports section hoping to make it even more brief and straightforward for all users. This removes all mention of users being able to add comments to bug reports. The impression is that users should treat the bug tracker as a readonly resource. Simplicity may be nice, but I don't think we are doing people a favor if we create the impression that they should stay away after reporting a bug. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bugreports section commit
On Sat, Mar 03, 2012 at 03:08:27PM +0100, David Kastrup wrote: This removes all mention of users being able to add comments to bug reports. It's still mentioned under step 4, so I didn't complain during the countdown. But after glancing at the final output, http://lilypond.org/bug-reports.html I agree that the @warning gives a misleading impression. I've added the second sentence back to the @warning. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
Graham, 2012/3/3 Graham Percival gra...@percival-music.ca: On Sat, Mar 03, 2012 at 09:56:33AM +0100, Janek Warchoł wrote: On Sat, Mar 3, 2012 at 9:16 AM, James pkx1...@gmail.com wrote: I still have some fundamental questions about the scripts. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Yes. GrahamDavid, when i said that i'd like to make Patchy more user-friendly i meant to make it so straightforward that these questions wouldn't have been asked. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Janek, tell me exactly which step in that process is unclear. Making vague claims of it should be more user-friendly does not help. I guess in my case it just wasn't clear to me if we can run one without the other 'all the time' (i.e. as I have now found out what Phil does), and that the two scripts were not dependent (i.e. I can only run one when the other has run or I should run the other when the other has run). Phil and David have just made that more clearer to me. Also should I be running both or would it better to just run one and (for instance) let someone else 'merge'. That was all. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify example for unpure-pure containers (issue 5623044)
On 3/2/12 11:58 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 3, 2012, at 4:38 PM, plros...@gmail.com wrote: Why do stems fix the spacing? I don't understand the question :( I believe it's because stems are involved in optical spacing decisions. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
- Original Message - From: James pkx1...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: David Kastrup d...@gnu.org; lilypond-devel@gnu.org Sent: Saturday, March 03, 2012 2:28 PM Subject: Re: regular patchy staging Graham, 2012/3/3 Graham Percival gra...@percival-music.ca: On Sat, Mar 03, 2012 at 09:56:33AM +0100, Janek Warchoł wrote: On Sat, Mar 3, 2012 at 9:16 AM, James pkx1...@gmail.com wrote: I still have some fundamental questions about the scripts. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Yes. GrahamDavid, when i said that i'd like to make Patchy more user-friendly i meant to make it so straightforward that these questions wouldn't have been asked. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Janek, tell me exactly which step in that process is unclear. Making vague claims of it should be more user-friendly does not help. I guess in my case it just wasn't clear to me if we can run one without the other 'all the time' (i.e. as I have now found out what Phil does), and that the two scripts were not dependent (i.e. I can only run one when the other has run or I should run the other when the other has run). Phil and David have just made that more clearer to me. Also should I be running both or would it better to just run one and (for instance) let someone else 'merge'. That was all. James I'd be happy if you could take over merge, since I'd assume you'd leave the machine on and could thus run it with a cron job and get email notifications of any problems as well as providing more frequent updates. It may make sense to offer to David to take over test - this is very similar to what you had been doing with your manual patch testing. If I were running both, I think I'd run them as separate users, to avoid problems with one affecting the git repo of build directory of another. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify example for unpure-pure containers (issue 5623044)
I mean, why is this needed? \remove Stem_engraver Stems must be fixing the problem somehow. http://codereview.appspot.com/5623044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
broken GUB doc
At some point in the build, it dies with this: .git-release-unstable/out-www/online-root/ . Instrumenting for Google Analytics Documentation/web/index.html Documentation/changes/index.html Documentation/notation/index.html Documentation/internals/index.html Traceback (most recent call last): File test-lily/rsync-lily-doc.py, line 225, in module main () File test-lily/rsync-lily-doc.py, line 219, in main create_local_web_dir (opts, a) File test-lily/rsync-lily-doc.py, line 126, in create_local_web_dir do_urchin (f) File test-lily/rsync-lily-doc.py, line 72, in do_urchin s = open (filename).read () IOError: [Errno 2] No such file or directory: 'examples.html' make[3]: *** [unlocked-doc-export] Error 1 make[3]: Leaving directory `/main/src/gub' - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
Graham Percival gra...@percival-music.ca writes: At some point in the build, it dies with this: .git-release-unstable/out-www/online-root/ . Instrumenting for Google Analytics Documentation/web/index.html Documentation/changes/index.html Documentation/notation/index.html Documentation/internals/index.html Traceback (most recent call last): File test-lily/rsync-lily-doc.py, line 225, in module main () File test-lily/rsync-lily-doc.py, line 219, in main create_local_web_dir (opts, a) File test-lily/rsync-lily-doc.py, line 126, in create_local_web_dir do_urchin (f) File test-lily/rsync-lily-doc.py, line 72, in do_urchin s = open (filename).read () IOError: [Errno 2] No such file or directory: 'examples.html' make[3]: *** [unlocked-doc-export] Error 1 make[3]: Leaving directory `/main/src/gub' Interesting in so far as the last doc builds in the course of patchy were successful. I have /tmp/lilypond-autobuild/build/out-www/offline-root But nothing looking like online-root: dak@lola:/tmp/lilypond-autobuild$ find -name online-root dak@lola:/tmp/lilypond-autobuild$ But dak@lola:/tmp/lilypond-autobuild$ find -name examples.html -ls 2890093 16 -rw-rw-r-- 2 dak dak 13010 Mar 3 20:22 ./build/Documentation/es/out-www/web/examples.html 2890743 12 -rw-rw-r-- 2 dak dak 12139 Mar 3 20:24 ./build/Documentation/it/out-www/web/examples.html 2890034 16 -rw-rw-r-- 2 dak dak 12381 Mar 3 20:21 ./build/Documentation/de/out-www/web/examples.html 2890380 12 -rw-rw-r-- 2 dak dak 11818 Mar 3 20:23 ./build/Documentation/hu/out-www/web/examples.html 28913438 -rw-rw-r-- 2 dak dak 5441 Mar 3 20:27 ./build/Documentation/zh/out-www/web/examples.html 2891192 12 -rw-rw-r-- 2 dak dak 12036 Mar 3 20:27 ./build/Documentation/nl/out-www/web/examples.html 2889984 16 -rw-rw-r-- 2 dak dak 12427 Mar 3 20:20 ./build/Documentation/cs/out-www/web/examples.html 2889933 12 -rw-rw-r-- 1 dak dak 11831 Mar 3 20:20 ./build/Documentation/out-www/web/examples.html 2890905 16 -rw-rw-r-- 2 dak dak 13050 Mar 3 20:26 ./build/Documentation/ja/out-www/web/examples.html 2890144 16 -rw-rw-r-- 2 dak dak 13062 Mar 3 20:23 ./build/Documentation/fr/out-www/web/examples.html 2903848 16 -rw-rw-r-- 1 dak dak 12397 Mar 3 20:28 ./build/out-www/offline-root/Documentation/web/examples.html Hm. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
Graham Percival gra...@percival-music.ca writes:
At some point in the build, it dies with this:
.git-release-unstable/out-www/online-root/ .
Instrumenting for Google Analytics
Documentation/web/index.html
Documentation/changes/index.html
Documentation/notation/index.html
Documentation/internals/index.html
Traceback (most recent call last):
File test-lily/rsync-lily-doc.py, line 225, in module
main ()
File test-lily/rsync-lily-doc.py, line 219, in main
create_local_web_dir (opts, a)
File test-lily/rsync-lily-doc.py, line 126, in
create_local_web_dir
do_urchin (f)
File test-lily/rsync-lily-doc.py, line 72, in do_urchin
s = open (filename).read ()
IOError: [Errno 2] No such file or directory: 'examples.html'
make[3]: *** [unlocked-doc-export] Error 1
make[3]: Leaving directory `/main/src/gub'
- Graham
I have
@subheading Actual release
@enumerate
@item If you're not the right user on the webserver, remove the
@code{t} from the rsync command in:
@example
test-lily/rsync-lily-doc.py
test-lily/rsync-test.py
@end example
Have you tried doing the release as the right user on the webserver?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
On Sat, Mar 03, 2012 at 09:08:46PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: File test-lily/rsync-lily-doc.py, line 225, in module Interesting in so far as the last doc builds in the course of patchy were successful. Those are the lilypond make doc, not the GUB make doc. If you're interested in fixing this, take a look at test-lily/rsync-lily-doc.py in GUB. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
On Sat, Mar 03, 2012 at 09:15:46PM +0100, David Kastrup wrote:
@item If you're not the right user on the webserver, remove the
@code{t} from the rsync command in:
Have you tried doing the release as the right user on the webserver?
That's only relevant for the upload. Despite the rsync in the
name of the failing script, it's just doing a local rsync, not
uploading anything.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixing height of Kievan bar line (issue 5727051)
Reviewers: , Message: Changing the char_box of the Kievan bar line to eliminate the problem with the bar line being cut off. However, this brings back the problem of staff lines appearing under the bar line. Description: Fixing height of Kievan bar line Kievan bar line is cut off when running lilypond with -dpreview, or using Kievan score as a snippet in lilypond-book See issue: http://code.google.com/p/lilypond/issues/detail?id=2344 Please review this at http://codereview.appspot.com/5727051/ Affected files: M mf/parmesan-scripts.mf Index: mf/parmesan-scripts.mf diff --git a/mf/parmesan-scripts.mf b/mf/parmesan-scripts.mf index 284aa45f5c163b7bebcf22ee621c2adebbf7142c..0689c22613f9a9a2fd4eef53c2533ea43ebc1659 100644 --- a/mf/parmesan-scripts.mf +++ b/mf/parmesan-scripts.mf @@ -254,16 +254,16 @@ fet_beginchar (Kievan end of piece (slash), barline.kievan); save hair_thickness, thick_thickness, width, depth, height, padding; hair# = 1.9 linethickness#; thick# = 6.0 linethickness#; - width = .8 staff_space; + width# = 1.0 staff_space#; height# + depth# = 4 staff_space#; depth# = height# + hair# / 2; - padding = .2 staff_space; + padding# = .2 staff_space#; - set_char_box (0, 0, depth#, height#); - define_pixels (hair, thick); + set_char_box (0, width# + 3 padding#, depth#, height# + staff_space#); + define_pixels (hair, thick, width, padding, depth, height); - x1r - x2l = width; - y1 - y3r = d + h + linethickness / 2; + x7r - x2l = width; + y1 - y3r = depth + height + linethickness / 2; z3 = z2; z4 = .5 [z1, z2] = (width / 2 + padding, hair / 8); ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
Graham Percival gra...@percival-music.ca writes: On Sat, Mar 03, 2012 at 09:08:46PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: File test-lily/rsync-lily-doc.py, line 225, in module Interesting in so far as the last doc builds in the course of patchy were successful. Those are the lilypond make doc, not the GUB make doc. If you're interested in fixing this, take a look at test-lily/rsync-lily-doc.py in GUB. Well, the question is why its behavior would have bothered changing. Sure it is not a problem of user identity, or a parallel build, or user quota? When looking at the changes since last release with git log release/2.15.31-1..origin/release/unstable --graph --decorate --stat I get (in the context of build system relevant files) not more than * commit 8bfdda40f3444df7f94f32ebc79e0ccd9695949a | Author: Phil Holmes m...@philholmes.net | Date: Sat Feb 25 16:53:34 2012 + | | More reductions in make doc | | Pushes the output from making midi .ly files and ly-examples to logfiles. | | Documentation/ly-examples/GNUmakefile |2 +- | make/midi-rules.make |2 +- | 2 files changed, 2 insertions(+), 2 deletions(-) | * commit dd6232b71b9d1b1cfd6938608e6583fe54f93004 | Author: Phil Holmes m...@philholmes.net | Date: Sat Feb 25 15:23:29 2012 + | | Removes mutopia-index.py processing | | GNUmakefile.in |5 +- | scripts/build/mutopia-index.py | 197 --- | 2 files changed, 1 insertions(+), 201 deletions(-) | * commit 55d9ad39acee4288ee0d36230f70110b02546ab3 | Author: Graham Percival gra...@percival-music.ca | Date: Wed Feb 29 15:59:44 2012 + | | Release: bump version. | | VERSION |4 ++-- | 1 files changed, 2 insertions(+), 2 deletions(-) | * commit 4493eb4584f92123ebacf51541ace8c0e20f5e5a | Merge: 2411d0e ea270d9 | Author: Graham Percival gra...@percival-music.ca | Date: Wed Feb 29 15:59:33 2012 + | | Merge branch 'release/unstable' into HEAD | * commit 2411d0e11c5ca03997122c905bc2e58ea6a8682e Author: Janek Warchoł janek.lilyp...@gmail.com Date: Sat Feb 25 08:11:10 2012 +0100 CG: Use latest convert-ly for LSR updates (fix 2346) Suggested by Thomas Morley: Use convert-ly from latest development release for LSR updates Documentation/contributor/lsr-work.itexi | 25 + 1 files changed, 25 insertions(+), 0 deletions(-) And all that does not really seem related. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
On Sat, Mar 03, 2012 at 09:34:54PM +0100, David Kastrup wrote: Well, the question is why its behavior would have bothered changing. Sure it is not a problem of user identity, or a parallel build, or user quota? * commit dd6232b71b9d1b1cfd6938608e6583fe54f93004 | Author: Phil Holmes m...@philholmes.net | Date: Sat Feb 25 15:23:29 2012 + | | Removes mutopia-index.py processing | | GNUmakefile.in |5 +- Yes, and this commit contains: -WWW-post: $(top-build-dir)/.htaccess $(outdir)/examples.html $(WEB_ROOT_FILES) +WWW-post: $(top-build-dir)/.htaccess $(WEB_ROOT_FILES) ... -$(outdir)/examples.html: $(WEB_EXAMPLE_FILES) - $(buildscript-dir)/mutopia-index -o $(outdir)/examples.html input/ (the above may have a few extra linebreaks due to email formatting; if in doubt, look at the commit in your local git history) The GUB error was: IOError: [Errno 2] No such file or directory: 'examples.html' See the similarity? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken GUB doc
Graham Percival gra...@percival-music.ca writes: On Sat, Mar 03, 2012 at 09:34:54PM +0100, David Kastrup wrote: Well, the question is why its behavior would have bothered changing. Sure it is not a problem of user identity, or a parallel build, or user quota? * commit dd6232b71b9d1b1cfd6938608e6583fe54f93004 | Author: Phil Holmes m...@philholmes.net | Date: Sat Feb 25 15:23:29 2012 + | | Removes mutopia-index.py processing | | GNUmakefile.in |5 +- Yes, and this commit contains: -WWW-post: $(top-build-dir)/.htaccess $(outdir)/examples.html $(WEB_ROOT_FILES) +WWW-post: $(top-build-dir)/.htaccess $(WEB_ROOT_FILES) ... -$(outdir)/examples.html: $(WEB_EXAMPLE_FILES) - $(buildscript-dir)/mutopia-index -o $(outdir)/examples.html input/ (the above may have a few extra linebreaks due to email formatting; if in doubt, look at the commit in your local git history) The GUB error was: IOError: [Errno 2] No such file or directory: 'examples.html' See the similarity? No more questions, your honor. Looking at that would have been the logical next step (after all, there is little point in checking commits without files that could make a difference), but for now I just went believing the commit message. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: acb4ce2a0927ae1899752c991d1c843f5b01196e *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
lilypond.patchy.ja...@gmail.com writes: Begin LilyPond compile, commit: acb4ce2a0927ae1899752c991d1c843f5b01196e *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Maybe somewhat had a patchy running that pushed a commit later than yours. I am surprised that my patchy should have been faster than yours, though. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: acb4ce2a0927ae1899752c991d1c843f5b01196e *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Uses derived_mark to avoid segfault (issue 5729051)
Reviewers: ,
Message:
Hey all,
I don't have time to test this patch tonight (David sent me to bed) but
it should do the trick. The map was overkill - a simple list of pairs
does the trick w/o anymore overhead and allows the use of derived_mark.
Cheers,
MS
Description:
Uses derived_mark to avoid segfault
Please review this at http://codereview.appspot.com/5729051/
Affected files:
M lily/span-bar-stub-engraver.cc
Index: lily/span-bar-stub-engraver.cc
diff --git a/lily/span-bar-stub-engraver.cc b/lily/span-bar-stub-engraver.cc
index
7b26ddbd1e68ed1d0892471d3f465650661e1bdf..35a47207fa5f353519889393ca1a8e948883ac2f
100644
--- a/lily/span-bar-stub-engraver.cc
+++ b/lily/span-bar-stub-engraver.cc
@@ -17,7 +17,6 @@
along with LilyPond. If not, see http://www.gnu.org/licenses/.
*/
-#include map
#include algorithm
#include align-interface.hh
@@ -38,7 +37,7 @@
class Span_bar_stub_engraver : public Engraver
{
vectorGrob * spanbars_;
- mapGrob *, Context * axis_groups_;
+ SCM axis_groups_;
public:
TRANSLATOR_DECLARATIONS (Span_bar_stub_engraver);
@@ -46,10 +45,18 @@ protected:
DECLARE_ACKNOWLEDGER (span_bar);
DECLARE_ACKNOWLEDGER (hara_kiri_group_spanner);
void process_acknowledged ();
+ virtual void derived_mark () const;
};
Span_bar_stub_engraver::Span_bar_stub_engraver ()
{
+ axis_groups_ = SCM_EOL;
+}
+
+void
+Span_bar_stub_engraver::derived_mark () const
+{
+ scm_gc_mark (axis_groups_);
}
void
@@ -61,7 +68,7 @@ Span_bar_stub_engraver::acknowledge_span_bar (Grob_info i)
void
Span_bar_stub_engraver::acknowledge_hara_kiri_group_spanner (Grob_info i)
{
- axis_groups_[i.grob ()] = i.context ();
+ axis_groups_ = scm_cons (scm_cons (i.grob ()-self_scm (), i.context
()-self_scm ()), axis_groups_);
}
void
@@ -70,12 +77,10 @@ Span_bar_stub_engraver::process_acknowledged ()
if (!spanbars_.size ())
return;
- Grob *vertical_alignment = Grob::get_root_vertical_alignment
((*axis_groups_.begin ()).first);
+ Grob *vertical_alignment = Grob::get_root_vertical_alignment
(unsmob_grob (scm_caar (axis_groups_)));
if (!vertical_alignment) // we are at the beginning of a score, so no
need for stubs
return;
- extract_grob_set (vertical_alignment, elements, elts);
-
for (vsize i = 0; i spanbars_.size (); i++)
{
extract_grob_set (spanbars_[i], elements, bars);
@@ -89,8 +94,14 @@ Span_bar_stub_engraver::process_acknowledged ()
vectorContext * affected_contexts;
vectorGrob * y_parents;
vectorbool keep_extent;
- for (vsize j = 0; j elts.size (); j++)
+ for (SCM s = axis_groups_; scm_is_pair (s); s = scm_cdr (s))
{
+ Context *c = unsmob_context (scm_cdar (s));
+ Grob *g = unsmob_grob (scm_caar (s));
+ if (!c || !g)
+continue;
+
+ vsize j = Grob::get_vertical_axis_group_index (g);
if (j bar_axis_indices[0]
j bar_axis_indices.back ()
find (bar_axis_indices.begin (), bar_axis_indices.end (),
j) == bar_axis_indices.end ())
@@ -101,12 +112,11 @@ Span_bar_stub_engraver::process_acknowledged ()
break;
k--;
- keep_extent.push_back (to_boolean (bars[k]-get_property
(allow-span-bar)));
- Context *c = axis_groups_[elts[j]];
if (c c-get_parent_context ())
{
- y_parents.push_back (elts[j]);
+ keep_extent.push_back (to_boolean (bars[k]-get_property
(allow-span-bar)));
+ y_parents.push_back (g);
affected_contexts.push_back (c);
}
}
@@ -122,7 +132,7 @@ Span_bar_stub_engraver::process_acknowledged ()
gi.rerouting_daddy_context_ = affected_contexts[j];
announce_grob (gi);
if (!keep_extent[j])
-it-suicide ();//it-set_property (Y-extent, ly_interval2scm
(Interval (infinity_f, -infinity_f)));
+it-suicide ();
}
}
spanbars_.clear ();
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses derived_mark to avoid segfault (issue 5729051)
http://codereview.appspot.com/5729051/diff/1001/lily/span-bar-stub-engraver.cc File lily/span-bar-stub-engraver.cc (right): http://codereview.appspot.com/5729051/diff/1001/lily/span-bar-stub-engraver.cc#newcode71 lily/span-bar-stub-engraver.cc:71: axis_groups_ = scm_cons (scm_cons (i.grob ()-self_scm (), i.context ()-self_scm ()), axis_groups_); axis_groups_ never gets cleared out again: this keeps grobs and contexts alive at least until the engraver is collected. http://codereview.appspot.com/5729051/diff/1001/lily/span-bar-stub-engraver.cc#newcode81 lily/span-bar-stub-engraver.cc:81: if (!vertical_alignment) // we are at the beginning of a score, so no need for stubs If we are at the beginning of the score is a valid state here, scm_caar (axis_groups_) is likely to throw an exception. http://codereview.appspot.com/5729051/diff/1001/lily/span-bar-stub-engraver.cc#newcode127 lily/span-bar-stub-engraver.cc:127: for (vsize j = 0; j affected_contexts.size (); j++) While you are at it: how about throwing out all of the reverses and instead letting the loop run backwards? http://codereview.appspot.com/5729051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
