Re: First stab at getting bar extents right. (issue 5186049)
On 2011/10/07 04:17:11, Keith wrote: Your patch removes the only use of skyline-vertical-padding, Oops. I lied. There is vertical-padding on NoteColumns too. So its patch 6d751144 that want to partially revert -- probably just the define-grobs.scm part. The C++ changes should stay because that fixed a bug causing a sneaky asymmetry in the horizontal skylines. http://codereview.appspot.com/5186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: First stab at getting bar extents right. (issue 5186049)
On Oct 7, 2011, at 6:28 AM, k-ohara5...@oco.net wrote: // First stab at getting bar extents right. Now, the bar extents are right already. They correspond to the extend of the bar as printed. For some reason, having the extents correct was important enough to Pál that he made 51494aa2. You want the bar to have influence beyond its visible extent, so that accidentals do not cross over. That is usually done with extra-spacing-height (for note spacing) or some kind of padding. Customize extra-spacing-height instead of extent. This I can do. And in response to your comment about what the patch is trying to do, you're right. It exists to let grobs that should spill over/under barlines (lyrics, for example) spill over whereas other grobs that shouldn't (like accidentals) stay within the bar. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20111006
On Oct 5, 2011, at 5:01 AM, Colin Campbell wrote: For 22:00 MDT Thursday October 6th Issue 1952: Patch: Sketch for broken beams with consistent slopes - R 4961041 Hey all, This has now been through two countdowns and not received any review yet. I'm going to postpone pushing it until I get at least one LGTM (potentially with comments) or fix X,Y,Z... If you have a few minutes, please take the time to have a look at it. Thanks! Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
Reviewers: , Message: Hi, This is a try to increase performance, especially under Windows (see http://code.google.com/p/lilypond/issues/detail?id=1926). As I don't use Windows to compile LilyPond, can someone test it? Regards, Bertrand Description: Optimizes note-heads.cc and introduces robust_symbol2string. Potential fix to issue 1926. Please review this at http://codereview.appspot.com/5233042/ Affected files: M lily/include/lily-guile.hh M lily/lily-guile.cc M lily/lily-parser-scheme.cc M lily/note-head.cc M lily/page-turn-engraver.cc M lily/paper-column-engraver.cc M lily/program-option-scheme.cc M lily/rest.cc M lily/stem.cc M lily/time-signature.cc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates a LeftBarStub that stops lyrics from bumping into the SystemStartBar. (issue 5201043)
Reviewers: J_lowe, Message: On 2011/10/06 19:41:26, J_lowe wrote: passes make but I get a programming error show up on make check (as well as half a dozen reg test diffs). See attached http://code.google.com/p/lilypond/issues/detail?id=1956#c1 All these are fixed. Now, the only diffs should be lyrics that used to be flush with the system start being pushed to the right by 1.0 units. Description: Creates a LeftBarStub that stops lyrics from bumping into the SystemStartBar. Please review this at http://codereview.appspot.com/5201043/ Affected files: A input/regression/lyric-left-edge.ly A lily/left-bar-stub-engraver.cc M ly/engraver-init.ly M scm/define-grobs.scm M scm/output-lib.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855 lily/stem.cc:855: if (attach !scm_is_eq (style, ly_symbol2scm (mensural)) I meant: the stem is aligned to the right of the attachment point (and to its left for down-stems). For centered stems like we have in ancient styles, the stems have to be centered around the attachment point, which is positioned at the center of the notehead. http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Here's the second part of my review. I saw that kievan notation has beams, contrary to what I thought. If you're intrepid, you can also try to implement the kievan beaming parameters in you KievanVoice. Hold on, it's the end! Bertrand http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf File mf/parmesan-clefs.mf (right): http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf#newcode1738 mf/parmesan-clefs.mf:1738: % TODO: merge this code with the above Obviously, this must be done. This is easy, you just have to define the glyph and create two characters with it: def draw_kievan_do_clef = z1 = [...] [...] enddef; fet_beginchar ([...]); draw_kievan_do_clef; fet_endchar; fet beginchar ([...]_change); % TODO: make a different glyph for changes, but % dunno what a kievan clef looks like in changes... draw[...]; endchar; http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf File mf/parmesan-noteheads.mf (right): http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf#newcode1861 mf/parmesan-noteheads.mf:1861: fet_beginchar (kievan half note (space position), s1rkievan); Still sr1kievan. http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode101 scm/output-lib.scm:101: (min 2 Maybe you could try to change min 2 for min 3 and remove what you added before. I'm totally unsure of that, we must check what's going on downstream to be sure. http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode595 scm/output-lib.scm:595: (0 . accidentals.vaticana0) I guess there's no natural glyph in kievan notation since there is no time signature and no accidental 'remembering'. Can you confirm this? Maybe we need to remove this line, then. This will produce a warning (but no crash) if one tries to use a natural in kievan style. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
- Original Message - From: bordage.bertr...@gmail.com To: bordage.bertr...@gmail.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Sent: Friday, October 07, 2011 10:37 AM Subject: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042) Reviewers: , Message: Hi, This is a try to increase performance, especially under Windows (see http://code.google.com/p/lilypond/issues/detail?id=1926). As I don't use Windows to compile LilyPond, can someone test it? AFAIK, the only way to get a Windows build is with GUB - so it's pretty much only Graham who can do this. Please correct me if I'm wrong, and I'll test it if I can get an .exe. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Issue 1926 in lilypond: 2.15.12 processing speed problems
- Original Message - From: lilyp...@googlecode.com To: philehol...@gmail.com Sent: Friday, October 07, 2011 10:40 AM Subject: Re: Issue 1926 in lilypond: 2.15.12 processing speed problems Updates: Labels: Patch-new Comment #9 on issue 1926 by bordage.bertrand: 2.15.12 processing speed problems http://code.google.com/p/lilypond/issues/detail?id=1926 http://codereview.appspot.com/5233042/ I uploaded the patch using our brand new git-cl. I got this warning: ««« [...] This has been identified with code.google.com issue 1926. Is this correct? [y/n (y)]y WARNING: could not change issue labels; please email lilypond-devel with a general description of the problem Tracker issue done »»» Thanks, Bertrand -- You received this message because you starred the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment or make updates. I think the message above only came to me? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Issue 1926 in lilypond: 2.15.12 processing speed problems
On Fri, Oct 07, 2011 at 12:29:03PM +0100, Phil Holmes wrote: You received this message because you starred the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment or make updates. I think the message above only came to me? The message with the special you have starred the issue footer only went to you. The message to bug-lilypond was the normal update from code.google.com. Both messages have exactly the same message body; the only difference is that footer (and the special headers which allow you to reply to it by email). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
On Fri, Oct 07, 2011 at 12:27:52PM +0100, Phil Holmes wrote: AFAIK, the only way to get a Windows build is with GUB - so it's pretty much only Graham who can do this. Please correct me if I'm wrong, and I'll test it if I can get an .exe. Anybody with a fast computer running lilydev can build a windows binary with GUB. Anybody with a fast computer running a different linux should be able to build a windows binary with GUB, but I'd budget 10 hours of fixing bugs in GUB before you get there. (that's a budget, not an estimate -- if you're lucky it will work out of the box) On your computer, I'd guess that GUB will take about 4 hours to compile all the stuff it needs, and then 15 minutes to produce a lilypond .exe. (oh, you also need a decent internet connection; it needs to download about 600 megs of source files. If that's the only thing holding you back, I could send you a CD by post. I'll send it with only a thin cardboard CD cover this time. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: bordage.bertr...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Friday, October 07, 2011 12:52 PM Subject: Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042) On Fri, Oct 07, 2011 at 12:27:52PM +0100, Phil Holmes wrote: AFAIK, the only way to get a Windows build is with GUB - so it's pretty much only Graham who can do this. Please correct me if I'm wrong, and I'll test it if I can get an .exe. Anybody with a fast computer running lilydev can build a windows binary with GUB. Anybody with a fast computer running a different linux should be able to build a windows binary with GUB, but I'd budget 10 hours of fixing bugs in GUB before you get there. (that's a budget, not an estimate -- if you're lucky it will work out of the box) On your computer, I'd guess that GUB will take about 4 hours to compile all the stuff it needs, and then 15 minutes to produce a lilypond .exe. (oh, you also need a decent internet connection; it needs to download about 600 megs of source files. If that's the only thing holding you back, I could send you a CD by post. I'll send it with only a thin cardboard CD cover this time. :) Cheers, - Graham I'm up for it. I can download that. I'd appreciate Unix newbie-level instructions. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
On Fri, Oct 07, 2011 at 01:10:56PM +0100, Phil Holmes wrote: I'm up for it. I can download that. I'd appreciate Unix newbie-level instructions. git repo is here: https://github.com/janneke/gub github has great docs for starting with git, so look there if you have trouble downloading it. Once you have it, type make bootstrap and then take your wife out shopping for 2-4 hours. If that goes well, we'll talk about the next stage. If not, we'll need to know the error message. *cough* I mean, the error from gub, not from your wife. You're on your own if she doesn't enjoy the shopping. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
Graham Percival gra...@percival-music.ca writes: On Fri, Oct 07, 2011 at 01:10:56PM +0100, Phil Holmes wrote: I'm up for it. I can download that. I'd appreciate Unix newbie-level instructions. git repo is here: https://github.com/janneke/gub github has great docs for starting with git, so look there if you have trouble downloading it. Once you have it, type make bootstrap and then take your wife out shopping for 2-4 hours. If that goes well, we'll talk about the next stage. If he can still afford internet access. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20111006
On 11-10-07 12:56 AM, m...@apollinemike.com wrote: On Oct 5, 2011, at 5:01 AM, Colin Campbell wrote: For 22:00 MDT Thursday October 6th Issue 1952 http://code.google.com/p/lilypond/issues/detail?id=1952: Patch: Sketch for broken beams with consistent slopes - R 4961041 http://codereview.appspot.com/4961041/ Hey all, This has now been through two countdowns and not received any review yet. I'm going to postpone pushing it until I get at least one LGTM (potentially with comments) or fix X,Y,Z... If you have a few minutes, please take the time to have a look at it. Thanks! Cheers, MS Folks, a developer is being very cautious about a patch here, an unusual event in our community: this is Six-Gun Mike after all!. The review system assumes developers will look at the patches which interest them most, and also that silence is consent: if you don't say anything, the patch gets pushed. Mike is asking for independent review of his work because of its potential impact, so if you have a look at the patch, would you take a moment and make a comment, even if only to say you've visited? Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Strike 1 music functionization...
Hi, I've tried reworking the syntax such that \mark can become a syntax function. What a nuisance. Here is the short breakdown: \mark has an argument of syntax class scalar. Likely unbeknown to most people, a scalar can include oddities like A+B (string concatenation). Trying to rework the syntax to accommodate that eventually failed. I'll spare you most of the folderol and decisions I made. What finally made Lilypond barf when I finished was something like \language italian sol Why would that be a problem? \language would have become similar to \mark regarding the parser, taking one argument accommodating, for example, italian+. So the parser needs to look ahead to see whether there is a + coming up in order to augment italian. Of course, when it looks ahead, the next token sol is not recognizable at all, since the language is still in the old state. @!#$!#@$! When I fixed that, scalar become similar enough with embedded_scm that I got 87 reduce/reduce conflicts and frankly, that was enough of a pest. Why do I distinguish those? I can't accept a scalar anywhere sensibly except at the end of an argument list, because a scalar can also be something like either 5, or \cm, or 5\cm. If I except this anywhere except at the end of the argument list, I can't reliably tell whether this is one scalar or two. Lilypond syntax sucks. I've decided to boil down scalars enough that they don't need lookahead (frankly, who used the string concatenation feature or even knew about it?). But a scalar can also be markup, and in connection with optional arguments (and with typechecking) you soon get into a situation where it is hard to find optional arguments when a scalar can be used anywhere but it end position. So what I'll likely do is smother most distinctions in the parser that can be uniquely identified by predicate anyway, and figure out how I can make the parser skip optional arguments if the predicate turns out false, rather than just doing the predicate check as a verification of an already made choice. That will at least conflate Scheme arguments, markup arguments, markup lists, numbers and strings in the parser, obliterating the drawbacks from the markup-list-in-the-parser changes from Reinhold (that exploded in somebody's face recently). Of course, pitches, durations, and music expressions will still need to be told apart by the parser itself. But at least you'll be able to cook up predicates markup-or-string (pretty redundant since currently every string _is_ a markup) yourself and have them work fine. I don't think I'll allow actual multiterm expressions (including 3\cm) anywhere except in assignments and similar explicitly parsed constructs (property setters and so). Possibly there will be a way to get them elsewhere, if somebody really complains loudly, if you enclose them in braces or parentheses or something like that. I am pretty annoyed, having spent over a week cooking down reduce/reduce and shift/reduce conflicts in the fight for a somewhat more powerful syntax and finding that the results are not really all that useful. Of course, this change of design is bad news for the impending markup workshop: the changed design will make it even more convenient that strings, numbers(?) and other stuff can be swapped rather freely with markup. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Strike 1 music functionization...
On Oct 7, 2011, at 3:51 PM, David Kastrup wrote: Hi, I've tried reworking the syntax such that \mark can become a syntax function. What a nuisance. Here is the short breakdown: \mark has an argument of syntax class scalar. Likely unbeknown to most people, a scalar can include oddities like A+B (string concatenation). Trying to rework the syntax to accommodate that eventually failed. I'll spare you most of the folderol and decisions I made. What finally made Lilypond barf when I finished was something like \language italian sol Why would that be a problem? \language would have become similar to \mark regarding the parser, taking one argument accommodating, for example, italian+. So the parser needs to look ahead to see whether there is a + coming up in order to augment italian. Of course, when it looks ahead, the next token sol is not recognizable at all, since the language is still in the old state. @!#$!#@$! When I fixed that, scalar become similar enough with embedded_scm that I got 87 reduce/reduce conflicts and frankly, that was enough of a pest. Why do I distinguish those? I can't accept a scalar anywhere sensibly except at the end of an argument list, because a scalar can also be something like either 5, or \cm, or 5\cm. If I except this anywhere except at the end of the argument list, I can't reliably tell whether this is one scalar or two. Lilypond syntax sucks. I've decided to boil down scalars enough that they don't need lookahead (frankly, who used the string concatenation feature or even knew about it?). But a scalar can also be markup, and in connection with optional arguments (and with typechecking) you soon get into a situation where it is hard to find optional arguments when a scalar can be used anywhere but it end position. So what I'll likely do is smother most distinctions in the parser that can be uniquely identified by predicate anyway, and figure out how I can make the parser skip optional arguments if the predicate turns out false, rather than just doing the predicate check as a verification of an already made choice. That will at least conflate Scheme arguments, markup arguments, markup lists, numbers and strings in the parser, obliterating the drawbacks from the markup-list-in-the-parser changes from Reinhold (that exploded in somebody's face recently). Of course, pitches, durations, and music expressions will still need to be told apart by the parser itself. But at least you'll be able to cook up predicates markup-or-string (pretty redundant since currently every string _is_ a markup) yourself and have them work fine. I don't think I'll allow actual multiterm expressions (including 3\cm) anywhere except in assignments and similar explicitly parsed constructs (property setters and so). Possibly there will be a way to get them elsewhere, if somebody really complains loudly, if you enclose them in braces or parentheses or something like that. I am pretty annoyed, having spent over a week cooking down reduce/reduce and shift/reduce conflicts in the fight for a somewhat more powerful syntax and finding that the results are not really all that useful. Of course, this change of design is bad news for the impending markup workshop: the changed design will make it even more convenient that strings, numbers(?) and other stuff can be swapped rather freely with markup. I don't see this being a problem. Most of the work we'll be doing will start on the music stream, well after the parser's finished doing its thing. That said, I don't completely get what you're talking about (not because you're not clear, but because it is over my head and would take me a while to understand), so if you feel that it will get in our way in some way that I'm not anticipating, please send a point-by-point list that is digestible by newbs (it'll be mostly rookies at the event, and I'm more or less a newb to parsing) and I'll explain it to all those who are interested. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Strike 1 music functionization...
m...@apollinemike.com m...@apollinemike.com writes: I don't see this being a problem. Most of the work we'll be doing will start on the music stream, well after the parser's finished doing its thing. As long as (markup? x) and (markup-list? '()) still can sensibly return #t with your changes, things will most likely continue to work. That said, I don't completely get what you're talking about (not because you're not clear, but because it is over my head and would take me a while to understand), so if you feel that it will get in our way in some way that I'm not anticipating, please send a point-by-point list that is digestible by newbs (it'll be mostly rookies at the event, and I'm more or less a newb to parsing) and I'll explain it to all those who are interested. The above should be the gist of it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
- Original Message -
From: Graham Percival gra...@percival-music.ca
To: Phil Holmes m...@philholmes.net
Cc: bordage.bertr...@gmail.com; lilypond-devel@gnu.org;
re...@codereview.appspotmail.com
Sent: Friday, October 07, 2011 1:41 PM
Subject: Re: Optimizes note-heads.cc and introduces robust_symbol2string.
(issue5233042)
On Fri, Oct 07, 2011 at 01:10:56PM +0100, Phil Holmes wrote:
I'm up for it. I can download that. I'd appreciate Unix
newbie-level instructions.
git repo is here:
https://github.com/janneke/gub
github has great docs for starting with git, so look there if you
have trouble downloading it.
Once you have it, type
make bootstrap
and then take your wife out shopping for 2-4 hours. If that goes
well, we'll talk about the next stage. If not, we'll need to know
the error message. *cough* I mean, the error from gub, not from
your wife. You're on your own if she doesn't enjoy the shopping.
I get this:
downloading http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz -
/media/IntelSSD/lilypond/git-gub/gub/downloads/git/
downloading
http://lilypond.org/download/gub-sources/git/git-1.6.4.4.tar.gz -
/media/IntelSSD/lilypond/git-gub/gub/downloads/git/
Tail of log/gub.log
*** Stage: download (git, tools)
Running download_url
('http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz',
'/media/IntelSSD/lilypond/git-gub/gub/downloads/git')
{}
Tail of log/gub.log
Looks like it's trying to download
http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz and failing to
find it - I don't think it's there now.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
I'm trying to implement beams, but I get this message: must have Item for spanner bound of Beam What does this refer to? A On Fri, Oct 7, 2011 at 6:29 AM, bordage.bertr...@gmail.com wrote: Here's the second part of my review. I saw that kievan notation has beams, contrary to what I thought. If you're intrepid, you can also try to implement the kievan beaming parameters in you KievanVoice. Hold on, it's the end! Bertrand http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf File mf/parmesan-clefs.mf (right): http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf#newcode1738 mf/parmesan-clefs.mf:1738: % TODO: merge this code with the above Obviously, this must be done. This is easy, you just have to define the glyph and create two characters with it: def draw_kievan_do_clef = z1 = [...] [...] enddef; fet_beginchar ([...]); draw_kievan_do_clef; fet_endchar; fet beginchar ([...]_change); % TODO: make a different glyph for changes, but % dunno what a kievan clef looks like in changes... draw[...]; endchar; http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf File mf/parmesan-noteheads.mf (right): http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf#newcode1861 mf/parmesan-noteheads.mf:1861: fet_beginchar (kievan half note (space position), s1rkievan); Still sr1kievan. http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode101 scm/output-lib.scm:101: (min 2 Maybe you could try to change min 2 for min 3 and remove what you added before. I'm totally unsure of that, we must check what's going on downstream to be sure. http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode595 scm/output-lib.scm:595: (0 . accidentals.vaticana0) I guess there's no natural glyph in kievan notation since there is no time signature and no accidental 'remembering'. Can you confirm this? Maybe we need to remove this line, then. This will produce a warning (but no crash) if one tries to use a natural in kievan style. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
On Fri, Oct 07, 2011 at 05:25:54PM +0100, Phil Holmes wrote: Looks like it's trying to download http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz and failing to find it - I don't think it's there now. Agreed... every year or so I delete my downloads/ dir to force it to download everything again, and there's always 2 or 3 projects that have moved locations. Could you look for the new offical git download location, ideally pick 1.6.4.4 again so we don't have any confusion from a different version, then edit gub/specs/git.py (that's probably $HOME/gub/gub/specs/ for you) 99% of the time that something's wrong in GUB, you'll be looking at the files in gub/specs/ Changing line 5 of that file should make it work. Once you've done that, please send me a git patch so I can push it and fix the main repo. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: bordage.bertr...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Friday, October 07, 2011 5:52 PM Subject: Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042) On Fri, Oct 07, 2011 at 05:25:54PM +0100, Phil Holmes wrote: Looks like it's trying to download http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz and failing to find it - I don't think it's there now. Agreed... every year or so I delete my downloads/ dir to force it to download everything again, and there's always 2 or 3 projects that have moved locations. Could you look for the new offical git download location, ideally pick 1.6.4.4 again so we don't have any confusion from a different version, then edit gub/specs/git.py (that's probably $HOME/gub/gub/specs/ for you) 99% of the time that something's wrong in GUB, you'll be looking at the files in gub/specs/ Changing line 5 of that file should make it work. Once you've done that, please send me a git patch so I can push it and fix the main repo. Cheers, - Graham Found it in a few places - none looks particularly official: http://ftp.ntu.edu.tw/software/scm/git/ http://mirrors.adnettelecom.ro/kernel.org/software/scm/git/?order=N http://www.mmnt.net/db/0/0/ftp.uni-duisburg.de/Unix/SCM Best more official copy seems to be at http://code.google.com/p/git-core/downloads/list but this only goes back to 1.7.6.4 Any preference? Is it worth caching a copy ourselves? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
On Fri, Oct 07, 2011 at 06:20:01PM +0100, Phil Holmes wrote: Best more official copy seems to be at http://code.google.com/p/git-core/downloads/list but this only goes back to 1.7.6.4 agreed. Any preference? Is it worth caching a copy ourselves? I don't think it's worth keeping a copy ourselves; let's just jump to the latest git-1.7.7.tar.gz and cross our fingers. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
On 10/7/11 11:29 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Oct 07, 2011 at 06:20:01PM +0100, Phil Holmes wrote: Best more official copy seems to be at http://code.google.com/p/git-core/downloads/list but this only goes back to 1.7.6.4 agreed. Any preference? Is it worth caching a copy ourselves? I don't think it's worth keeping a copy ourselves; let's just jump to the latest git-1.7.7.tar.gz and cross our fingers. There's also an oregon state university open source software server that has lots of older stuff. http://ftp.osuosl.org/pub/software/scm/git/git-1.6.4.4.tar.gz But I think I'm with Graham -- use the official repo and the latest software. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
Looks like it's trying to download http://kernel.org/pub/software/scm/git/git-1.6.4.4.tar.gz and failing to find it - I don't think it's there now. There are severe problems with kernel.org since a few weeks (it has been compromised), and just now the maintainers are slowly restoring the host. Please try a mirror to download git. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855 lily/stem.cc:855: if (attach !scm_is_eq (style, ly_symbol2scm (mensural)) On 2011/10/07 09:47:24, Bertrand Bordage wrote: stems have to be centered around the attachment point, which is positioned at the center of the notehead. Okay; I thought the centered case was excluded by if(attach) http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc File lily/note-head.cc (right): http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc#newcode79 lily/note-head.cc:79: out = fm-find_by_name (idx_either); This performs a second lookup for every note-head. Move this call to line 61, so you only perform the second lookup if there is a possibility that it will give a new result. http://codereview.appspot.com/5233042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042)
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: bordage.bertr...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Friday, October 07, 2011 6:29 PM Subject: Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue5233042) On Fri, Oct 07, 2011 at 06:20:01PM +0100, Phil Holmes wrote: Best more official copy seems to be at http://code.google.com/p/git-core/downloads/list but this only goes back to 1.7.6.4 agreed. Any preference? Is it worth caching a copy ourselves? I don't think it's worth keeping a copy ourselves; let's just jump to the latest git-1.7.7.tar.gz and cross our fingers. I now get this: Tail of target/tools/log/perl.log tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Command barfed: tar -C /media/IntelSSD/lilypond/git-gub/gub/target/tools/src/perl-5.10.0 --strip-component=1 -v -z -xf /media/IntelSSD/lilypond/git-gub/gub/downloads/perl/perl-5.10.0.tar.gz If I try to open perl*.tar.gz I get unexpected end-of-file. I get the same with the re-downloaded version from CPAN. I'm assuming it's corrupt. Find another one? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB
On Fri, Oct 07, 2011 at 07:09:57PM +0100, Phil Holmes wrote: Tail of target/tools/log/perl.log tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Command barfed: tar -C /media/IntelSSD/lilypond/git-gub/gub/target/tools/src/perl-5.10.0 --strip-component=1 -v -z -xf /media/IntelSSD/lilypond/git-gub/gub/downloads/perl/perl-5.10.0.tar.gz If I try to open perl*.tar.gz I get unexpected end-of-file. I get the same with the re-downloaded version from CPAN. I'm assuming it's corrupt. Find another one? Let's change the subject line here. I guess we'll need a different one... let's use perl-5.10.1 http://www.cpan.org/src/5.0/perl-5.10.1.tar.gz since that's the least likely to break stuff that used to work in 5.10.0. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR: Updated snippet for MMR Positions (1931) (issue 5155045)
LGTM http://codereview.appspot.com/5155045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc File lily/note-head.cc (right): http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc#newcode79 lily/note-head.cc:79: out = fm-find_by_name (idx_either); Unfortunately, this doesn't work. If the condition line 73 is false, then out will be an empty stencil. But this gave me an idea: use two stencils instead of one. Instead of overwriting the working stencil 'out' to check if the new one is empty, we can use another 'test' stencil. I test that now and upload it. http://codereview.appspot.com/5233042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website.make
On Thu, Oct 06, 2011 at 06:46:40PM +0200, Julien Rioux wrote: I tested and there is absolutely no diff between the out-website generated with the old website.make and the new website.make. Should I upload this to Rietveld for review? Yes please. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates a LeftBarStub that stops lyrics from bumping into the SystemStartBar. (issue 5201043)
Passes make and make check shows 2 reg test diffs that Mike seems to think are expected attached at: http://code.google.com/p/lilypond/issues/detail?id=1956#c3 http://codereview.appspot.com/5201043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes closeness-factor from the Slur details list. (issue 4825051)
Passes make and make check looks fine too. Graphviz.log does show up (and as I don't know what it means I'll paste it here anyway just in case ...) @@ -15,13 +15,13 @@ rankdir=LR node [shape=rectangle] 41 [label=caching Stem.stencil\n# - #] -40 [label=caching VerticalAxisGroup.stencil\n# - #f] -39 [label=caching LedgerLineSpanner.stencil\n# - #] -38 [label=caching StaffSymbol.stencil\n# - #] -37 [label=caching Stem.Y-extent\n# - (-2.812186 . 0.5)] -36 [label=caching Stem.length\n# - 6.624372] -35 [label=caching Stem.stem-begin-position\n# - -5.624372] -34 [label=caching Stem.Y-offset\n# - 0.0] +40 [label=caching LedgerLineSpanner.stencil\n# - #] +39 [label=caching VerticalAxisGroup.stencil\n# - #f] +38 [label=caching Stem.Y-extent\n# - (-2.812186 . 0.5)] +37 [label=caching Stem.length\n# - 6.624372] +36 [label=caching Stem.stem-begin-position\n# - -5.624372] +35 [label=caching Stem.Y-offset\n# - 0.0] +34 [label=caching StaffSymbol.stencil\n# - #] 33 [label=Stem\n/home/jlowe/lilypond-git/lily/grob.cc:341\npure-Y-offset-in-progress - #t] 32 [label=caching TimeSignature.stencil\n# - #] 31 [label=caching Stem.X-extent\n# - (-0.065 . 0.065)] @@ -56,11 +56,11 @@ 2 [label=NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause - # 41 +38 - 41 +37 - 38 36 - 37 35 - 36 -34 - 35 -33 - 34 +33 - 35 31 - 33 30 - 31 29 - 30 snip-- James http://codereview.appspot.com/4825051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
Passes make and make check throws up no reg tests except graphviz.log:
--snip--
@@ -14,9 +14,9 @@
Writing graph `#f'...digraph G {
rankdir=LR
node [shape=rectangle]
-41 [label=caching Stem.stencil\n# - #]
+41 [label=caching LedgerLineSpanner.stencil\n# - #]
40 [label=caching VerticalAxisGroup.stencil\n# - #f]
-39 [label=caching LedgerLineSpanner.stencil\n# - #]
+39 [label=caching Stem.stencil\n# - #]
38 [label=caching StaffSymbol.stencil\n# - #]
37 [label=caching Stem.Y-extent\n# - (-2.812186 . 0.5)]
36 [label=caching Stem.length\n# - 6.624372]
@@ -56,7 +56,7 @@
2 [label=NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause
- # 41
+37 - 39
36 - 37
35 - 36
34 - 35
--snip--
James
http://codereview.appspot.com/5233042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Allows NoteColumns to be skipped over by glissandi. (issue 5242041)
passes make and make check only throws out
@@ -14,9 +14,9 @@
Writing graph `#f'...digraph G {
rankdir=LR
node [shape=rectangle]
-41 [label=caching Stem.stencil\n# - #]
+41 [label=caching LedgerLineSpanner.stencil\n# - #]
40 [label=caching VerticalAxisGroup.stencil\n# - #f]
-39 [label=caching LedgerLineSpanner.stencil\n# - #]
+39 [label=caching Stem.stencil\n# - #]
38 [label=caching StaffSymbol.stencil\n# - #]
37 [label=caching Stem.Y-extent\n# - (-2.812186 . 0.5)]
36 [label=caching Stem.length\n# - 6.624372]
@@ -56,7 +56,7 @@
2 [label=NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause
- # 41
+37 - 39
36 - 37
35 - 36
34 - 35
--snip--
James
http://codereview.appspot.com/5242041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Errors when doing 'make' for the first time when building the fonts
Hello,
I've always these errors when I 'make' for the first time (i.e. when I
have a fresh out of tree build).
I expect most of them have always been there, but I wondered if they
are problematic or not?
--snip--
Internal Error in accidentals.flat.arrowdown: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowdown: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowdown: Expected needed monotonic.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: Expected needed monotonic.
Internal Error in accidentals.flat.arrowdown: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowdown: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowdown: Expected needed monotonic.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: Expected needed monotonic.
@{char@:Flageolet@:115@:3.36@:3.36@:3.36@:3.36@:3.36@:0@:flageolet@}
[115]Internal Error in accidentals.flat.arrowdown:
Internal Error in accidentals.flat.arrowdown: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowdown: Expected needed monotonic.
@} [151]Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: monotonic is both needed and unneeded.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: couldn't find a needed exit from an
intersection
Internal Error in clefs.G_change: Humph. This monotonic leads nowhere.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Closing contour with unneeded path
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Humph. This monotonic leads nowhere.
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in clefs.G_change: Closing contour with unneeded path
Internal Error in clefs.G_change: Expected needed monotonic.
Internal Error in accidentals.sharp.arrowup: couldn't find a needed
exit from an intersection
Internal Error:
Internal Error in accidentals.sharp.arrowup: couldn't find a needed
exit from an intersection
Internal Error in accidentals.sharp.arrowboth: couldn't find a needed
exit from an intersection
Internal Error:
Internal Error in accidentals.sharp.arrowboth: couldn't find a needed
exit from an intersection
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: Expected needed monotonic.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: monotonic is both needed
and unneeded.
Internal Error in accidentals.flat.arrowboth: Expected needed monotonic.
Internal Error in scripts.varcoda: couldn't find a needed exit from an
intersection
Internal Error:
Internal Error in scripts.varcoda: couldn't find a needed exit from an
intersection
--snip--
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
