Re: Doc: Added \compoundMeter function to NR (issue4837050)
http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1555 Documentation/notation/rhythms.itely:1555: shown durations are multiplied by 3/5 -- as 3/5 * 10/8 = 3/4. It may be On 2011/08/07 20:33:38, J_lowe wrote: On 2011/08/07 15:24:44, Trevor Daniels wrote: > I prefer brackets to show these parenthetical comments: > (because 2/3 * 9/8 = 3/4) I have no strong feelings either way. So Done. I like this. http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1643 Documentation/notation/rhythms.itely:1643: come before it indicate the beat value. On 2011/08/07 20:33:38, J_lowe wrote: On 2011/08/07 15:24:44, Trevor Daniels wrote: > I think it's clearer to say top and bottom of the time signature: > ... last number in the list is placed at the bottom of the time signature and > the numbers that come before it are placed as a summation at the top. All but > the last number indicate the stress groupings and sum to the duration of the > measure. hmmm..I still think that is a bit awkward - I'm not sure 'summation' comes over well for non-native English speakers looking at the NR. I also don't feel the last sentence is necessary if the @lilyponds are good enough (that and we talk about beaming anyway later). See what you think of my very simple change. I agree that the last sentence suggested by Treveor isn't necassary. I think that if we change "summation" to "sum" in his proposal, it will be understood by people. In Wiktionary i see that word for sum is similar in many languages. http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely#newcode1643 Documentation/notation/rhythms.itely:1643: before it, the bottom numbers. It's the other way round - Last number goes to the bottom. http://codereview.appspot.com/4837050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
2011/8/8 Graham Percival : > On Mon, Aug 08, 2011 at 03:52:52AM +, k-ohara5...@oco.net wrote: >> >If any of the above is incorrect, >> >then maybe consider adding some >> >comment(s) where you define the variables, >> >> Now, Mike created none of these variables, nor does his added code use >> them. If he adds helpful comments, great, but he has no more duty to >> add comments than do the rest of us who reviewed the code. > > I certainly agree that he has no more duty to clarify stuff than > anybody else! +1, ofc. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Kievan square notation in LilyPond
Hi, 2011/8/8 Aleksandr Andreev : > Hi everybody, > > Back to the topic of adding support for East Slavic (aka Kievan) music > notation. Great to see you working on this! > I've rewritten our font for Kievan notation (called Suprasl) in > Metafont. Now, I am trying to figure out how to incorporate the new > glyphs into the Feta files. Our contributor's guide contains a very brief introduction to modifying metafont files, it may be useful if you haven't seen it yet: http://lilypond.org/doc/v2.15/Documentation/contributor/modifying-the-feta-font If during your work you'll have anything to add there, contributions to CG will be most welcome! > I've created a new file, feta-kievan.mf in the mf directory. > > Now I'd like to make sure I'm doing this right before I proceed .. > this is the first time I've worked with Metafont, so please bear with > me. > > In our file (suprasl.mf), the glyphs are defined with beginchar(name, > width, height, depth). Next, I define a series of points in terms of > the quantity u, which is derived from a sharped quantity u#. > Basically, u# tells us what the size of the character should be given > the font's design size. Finally, I draw the character with fill. can you send these files (in the patch format if possible)? It's easier to say something when you see the code (at least in my case). > The question I have is this: what is the appropriate coordinate system > to use for feta-kievan? > > What I've gleaned from reading the source of feta-notehead.mf is that > things are somehow defined in terms of stafflinethickness# and > staff_space. Yes, and also there is design_size used to encode differencies between particular versions of the font (see http://lilypond.org/doc/v2.15/Documentation/essay/engraving-details#optical-sizing). > Am I right to understand that stafflinethickness is the thickness of a > line in the five line staff? And staff_space is the amount of space > between lines? stafflinethickness is the thickness of one line in the staff. staff_space is the distance between middle of one line to the middle of a next line (in other words, it's the amount of whitespace between lines + stafflinethickness) > Would it be appropriate to define a basis unit u in terms of > stafflinethickness and then specify the points in terms of u? In case of noteheads, i suppose that everything would be best defined in staff_space. For stems (as i understand there are special characters for stems) stafflinethickness will be more appropriate. However, i may be mistaken since i don't see the code. > Where is the origin? origin of what? (sorry, i didn't understand) HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Line 722 of axis-group-interface.cc
Question: on line 722 of axis-group-interface.cc, I see:
while (i + 1 < elements.size ()
&& scm_eq_p (elements[i + 1]->get_property
("outside-staff-priority"), priority))
Shouldn't this be:
while (i + 1 < elements.size ()
&& to_boolean (scm_eq_p (elements[i + 1]->get_property
("outside-staff-priority"), priority)))
?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
2011/8/7 Phil Holmes : > I've prepared some changes for the web search box in line with what I > suggested in http://code.google.com/p/lilypond/issues/detail?id=1806 - > screenshot attached. It requires changes to search-box.ihtml and > lilypond-website.css (to make room for the new box). > > Problem is, I've currently got a review going for the mozart horn regtest. I > use lily-git.tcl for git. I'm presuming that I'm restricted to a single > branch with this? I think so. > If I try git from the command line to create a new local > branch, I presume there's some way to tell git cl that you want to upload a > different patch for review? There must be a way. I don't use lily-git and i don't have access to my Lilydev-enabled machine, so i cannot tell anything for sure, but here is my guess at how this should be done. Be sure to have the most recent version of your mozart horn regtest patch uploaded to Rietveld just in case. open terminal, go to main source directory (usually 'cd lilypond-git') call 'git status' to confirm where you are. I suppose it will say "current branch: master, nothing to be committed" (roughly). If it says that there are some changes to be committed, commit them before proceeding with 'git commit -a'). call 'git log' to see git history. You should see your commit(s) for mozart horn regtest at the top. Notice that every commit has a hexadecimal number, something like 46b423b3db2a90f8e8ac - this is commit's identifier, iirc called "committish". copy the committish of the last commit before your mozart horn regtest commit(s). (copying in terminal is done using Ctrl+Shift+C, pasting with Ctrl+Shift+V) call 'git branch websearch [paste above committish, without brackets]' to tell git to create a new branch named websearch, pointing to that last commit before your mozart horn regtest (so the new branch won't "contain" your mozart horn regtest changes). call 'git checkout websearch' to move to that branch confirm that everything is right by calling 'git status' (it should tell that you are on websearch branch and there's nothing to commit) and 'git log' to check that your mozart horn regtest commit(s) is not included in this branch. make changes to the source as usual commit them by calling 'git commit -a' update repository by calling 'git pull -r' upload patch to Rietveld using 'git cl upload origin/master'. IIRC, vi might open at some moment; to close it press : w q This should work. I'll be at home with my Lilydev-enabled machine at around 20:00 UTC, if you'd like more help - we could talk using IRC chat for example.. HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Italian PO file for 'lilypond' (version 2.15.9)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Italian team of translators. The file is available at: http://translationproject.org/latest/lilypond/it.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: test macosx 10.7 binaries
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Graham Percival )Sent: 08 August 2011 01:52 )To: lilypond-devel@gnu.org )Subject: Re: test macosx 10.7 binaries ) )On Wed, Aug 03, 2011 at 12:30:15PM -0700, Graham Percival wrote: )> Get them here: )> http://lilypond.org/~graham/ ) )Hmm. Nobody cares about MacOS X 10.7 ? ok, no skin off my nose... ) )I was thinking that it would be nice to announce that this was working in )the next release notes, but I guess I'll just make a completely mundane )release and wait to see if anybody tries it on )10.7 by accident? Well it might be the people who had the problem are not on the dev list. I'll go and find the threads on the users list and let them know. Keep it there for now. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: NR 5.5.4 - Modifying ties and slurs
Hello, )-Original Message- )From: Trevor Daniels [mailto:t.dani...@treda.co.uk] )Sent: 07 August 2011 23:04 )To: James Lowe; Neil Puttock )Cc: Lily-Devel List )Subject: Re: NR 5.5.4 - Modifying ties and slurs ) ) )James Lowe wrote Sunday, August 07, 2011 10:24 PM ) )>> If I navigate to TieColumn, )>> )>> http://lilypond.org/doc/v2.15/Documentation/internals/tiecolumn )>> )>> there's a list of interfaces at the bottom, one of which is )>> tie-column-interface. If I follow this link, there's a description )>> of )>> tie-configuration: )>> )> )> Right. So why do I need to care about TieColumn? Why not just get )> straight to desert and link to tie-column-interface - it's )> back-referenced anyway back to TieColumn? ) )Any override has to be applied to the grob - the TieColumn. )So this should be the primary entity referenced. ) )There are many properties which are not set by default in certain grobs )and have to be looked up in the interfaces. How to do this is clearly )explained in the LM. See )http://www.lilypond.org/doc/v2.15/Documentation/learning/properties- )found-in-interfaces )So referencing the grob is correct. ) OK, thanks for the clarification. Pushed as commit 476d8dc8ff51a5084030eda03013312dbb8c5859 Sorry for this. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Should this be applied?
In an attempt to figure out whether my coredumps were related to lying
to the compiler about const, I tried checking the effects of not using
casts to non-const in const member functions. Nothing came off it.
However, there was one not-just-declarational change that seemed like a
sensible thing to do:
diff --git a/lily/item.cc b/lily/item.cc
index 4e98181..14b6751 100644
--- a/lily/item.cc
+++ b/lily/item.cc
@@ -178,7 +178,7 @@ Item::break_visible (Grob *g)
bool
Item::pure_is_visible (int start, int end) const
{
- SCM vis = get_property ("break-visibility");
+ SCM vis = get_pure_property ("break-visibility", start, end);
if (scm_is_vector (vis))
{
int pos = 1;
I have no clue what start and end are, and I have no clue what pure is.
But get_pure_property takes start and end as additional arguments over
get_property, and so does pure_is_visible.
So from a mere text-matching hand-waving likelihood point of view, the
above change seems plausible.
Is there anybody that could shed light on this?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Kievan square notation in LilyPond
Hi Jan, Thanks for your comments. > In case of noteheads, i suppose that everything would be best defined in > staff_space. For stems (as i understand there are special characters for > stems) stafflinethickness will be more appropriate. Right now, I've got the notehead and stem being drawn as one character. Is this a bad idea? > However, i may be mistaken since i don't see the code. Here's the file I'm working with right now: http://www.ponomar.net/files/metasuprasl.mf And here's a proof sheet to make your life easier: http://www.ponomar.net/files/metasuprasl.pdf Thanks for your help, Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
On Sun, Aug 7, 2011 at 4:02 PM, Graham Percival wrote: > On Sun, Aug 07, 2011 at 11:46:51AM +0200, m...@apollinemike.com wrote: >> I'm certainly not against adding comments, but I think that when >> the code does a good job of explaining stuff via variable names, >> comments can clutter what's going on. For example, dz_unit to >> me sounds like a unit vector (which it is), > > To me, dz_unit sounds like the difference in the z_unit vectors. > I mean, "d" is "delta", right? > > I personally would have used z_unit_vector unless there was a > clear tradition of using _v for a vector, in which case I'd use > z_unit_v. > > ... BTW, you *are* using "z" as the "vector going away from the > page", right? I mean, x_unit would be the unit vector going from > left to right along the page, y_unit would be the unit vector > going from bottom to top along the page, while z_unit is going > away from the page? (like, to implement "layers" or something > like that?) Most of the offset code implicitly identifies an offset with a complex number, and z is commonly used to name a complex number. The complex number analogon is probably more confusing than it is useful for anything. It could be cleaned up if someone is interested in cleaning things. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a glyph for tied lyrics. (issue4808074)
Changes done. Passes make, regtest comparison and make doc. Bertrand http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Jean-Charles Malahieude" ; "David Kastrup" ; Sent: Sunday, August 07, 2011 11:37 PM Subject: Re: Ugliness in the Learning Manual On Sun, Aug 07, 2011 at 11:22:48AM +0100, Phil Holmes wrote: - Original Message - From: "Jean-Charles Malahieude" >(./usage.texi (/home/jcharles/GIT/Mentors/tex/texinfo.tex That looks good. git grep TEXINPUTS gives: make/lilypond-vars.make:TEXINPUTS=$(top-src-dir)/tex/:: So we're setting the location of the texinfo.tex file explicitly during make. Think this makes the issue invalid, but the "feature" is probably worth documenting with other make stuff - Graham? What's the '"feature"' ? Just that, in make, we set the TEXINPUTS, so you would also need to do this if compiling from command line. I don't think it's worth discussing this specific environment variable on its own. However, I'd quite like to see either: 1) change the build system to avoid using environment variables -- or rather, print the exact env vars on each line. i.e. instead of make(1) producing: export TEXINPUTS=$(top-src-dir)/tex/:: texi2pdf blah.texi it would produce TEXINPUTS=$(top-src-dir)/tex/:: texi2pdf blah.texi Advantage: when investigating a failing command, you can actually copy&paste the command you see make(1) running, and it should fail in exactly the same way because there's no environment variable garbage. Disadvantage: I'm not 100% certain that all shells handle environment variables in the same way. I know that non-bash shells don't use "export" to set an env var. This would involve more research about unix shell portability, and/or en email from somebody knowledgeable about such matters. In theory, it also means you only have one line to change if a directory structure shanges. 2) list all environment variables used (both internally and externally) in the build system in the CG. Advantage: at least this knowledge is written down somewhere. Disadvantage: the list will not be kept up-to-date. (don't argue; there's absolutely nothing you can say that will make me believe that everybody will keep it up-to-date over the next 20 years) Think it's quite a bit of work, too. Think I'll put the information I found in the bug report and mark it invalid. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
- Original Message -
From:
To: ; ;
;
Cc: ;
Sent: Sunday, August 07, 2011 11:42 PM
Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
LGTM. My comment is a tiny nitpick; I don't think it needs to hold up
pushing this.
http://codereview.appspot.com/4811066/diff/8003/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):
http://codereview.appspot.com/4811066/diff/8003/input/regression/mozart-hrn-3.ly#newcode27
input/regression/mozart-hrn-3.ly:27: \typewriter {
"http://mutopiaproject.org/"; }
this would be slightly nicer if you used \url instead of \typewriter.
That would use that typeface, but would also produce a clickable link.
http://codereview.appspot.com/4811066/
Nitpick changed - I've kept typewriter for the look, but added url. Patch
attached. Please push.
--
Phil Holmes
0001-Update-regtest-morart-hrn.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
- Original Message - From: "Trevor Daniels" To: "Graham Percival" Cc: "Phil Holmes" ; "Lily-Devel List" Sent: Monday, August 08, 2011 12:11 AM Subject: Re: Search box changes Grahamm you wrote Sunday, August 07, 2011 11:47 PM On Sun, Aug 07, 2011 at 06:35:34PM +0100, Trevor Daniels wrote: ps I wish you wouldn't send messages from newsgroups. I have to mess about cutting and pasting To:, Cc: and Subject: fields in order to reply. really? I just hit "reply to all" and my mail client takes care of it. Maybe there's a different "reply to group" or "reply to list" command you can use? Maybe it's because I'm not subscribed to any newsgroups? Reply-to-all in Windows mail sets up a reply to a newsgroup, but the newsgroup field is blank and I don't know what it should be. Phil's the only one causing me this problem. I do use Windows mail's newsgroups interface to post to devel, and it's possible I'm unique in that, and that Trevor is unique in that he also uses Windows mail, but without subscribing. I'll see how I can avoid the problem in future. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
- Original Message - From: "Jan Warchoł" [snip] Thanks for this excellent guide, Jan. Looks like I won't need to use it since I just sent a patch for my regtest to GP, but I may need it in future... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
I'll push it.
james
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 08 August 2011 15:54
)To: philehol...@googlemail.com; percival.music...@gmail.com;
)n.putt...@gmail.com; m...@philholmes.net; em...@philholmes.net;
)lilypond-devel@gnu.org; re...@codereview.appspotmail.com
)Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)- Original Message -
)From:
)To: ; ;
);
)Cc: ;
)Sent: Sunday, August 07, 2011 11:42 PM
)Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)
)> LGTM. My comment is a tiny nitpick; I don't think it needs to hold up
)> pushing this.
)>
)>
)>
)http://codereview.appspot.com/4811066/diff/8003/input/regression/mo
)zar
)> t-hrn-3.ly File input/regression/mozart-hrn-3.ly (right):
)>
)>
)http://codereview.appspot.com/4811066/diff/8003/input/regression/mo
)zar
)> t-hrn-3.ly#newcode27
)> input/regression/mozart-hrn-3.ly:27: \typewriter {
)> "http://mutopiaproject.org/"; } this would be slightly nicer if you
)> used \url instead of \typewriter.
)> That would use that typeface, but would also produce a clickable link.
)>
)> http://codereview.appspot.com/4811066/
)
)Nitpick changed - I've kept typewriter for the look, but added url. Patch
)attached. Please push.
)
)--
)Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
Can we have a regtest, please? http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
commit 403e66a45e752231fb49deea2e8ccb1976505c7c
Thanks Mr Holmes!
James
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of James Lowe
)Sent: 08 August 2011 16:13
)To: Phil Holmes; philehol...@googlemail.com;
)percival.music...@gmail.com; n.putt...@gmail.com;
)m...@philholmes.net; lilypond-devel@gnu.org;
)re...@codereview.appspotmail.com
)Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)Importance: Low
)
)I'll push it.
)
)james
)
))-Original Message-
))From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
))[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org]
)On )Behalf Of Phil Holmes
))Sent: 08 August 2011 15:54
))To: philehol...@googlemail.com; percival.music...@gmail.com;
))n.putt...@gmail.com; m...@philholmes.net; em...@philholmes.net;
))lilypond-devel@gnu.org; re...@codereview.appspotmail.com
))Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
))
))- Original Message -
))From:
))To: ; ;
));
))Cc: ;
))Sent: Sunday, August 07, 2011 11:42 PM
))Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
))
))
))> LGTM. My comment is a tiny nitpick; I don't think it needs to hold up )>
)pushing this.
))>
))>
))>
))http://codereview.appspot.com/4811066/diff/8003/input/regression/m
)o
))zar
))> t-hrn-3.ly File input/regression/mozart-hrn-3.ly (right):
))>
))>
))http://codereview.appspot.com/4811066/diff/8003/input/regression/m
)o
))zar
))> t-hrn-3.ly#newcode27
))> input/regression/mozart-hrn-3.ly:27: \typewriter { )>
)"http://mutopiaproject.org/"; } this would be slightly nicer if you )> used
)\url instead of \typewriter.
))> That would use that typeface, but would also produce a clickable link.
))>
))> http://codereview.appspot.com/4811066/
))
))Nitpick changed - I've kept typewriter for the look, but added url. Patch
))attached. Please push.
))
))--
))Phil Holmes
)
)___
)lilypond-devel mailing list
)lilypond-devel@gnu.org
)https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected
this to GP, but here's a corrected patch.
--
Phil Holmes
- Original Message -
From: "James Lowe"
To: "Phil Holmes" ; ;
; ; ;
;
Sent: Monday, August 08, 2011 4:13 PM
Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
I'll push it.
james
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 08 August 2011 15:54
)To: philehol...@googlemail.com; percival.music...@gmail.com;
)n.putt...@gmail.com; m...@philholmes.net; em...@philholmes.net;
)lilypond-devel@gnu.org; re...@codereview.appspotmail.com
)Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)- Original Message -
)From:
)To: ; ;
);
)Cc: ;
)Sent: Sunday, August 07, 2011 11:42 PM
)Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)
)> LGTM. My comment is a tiny nitpick; I don't think it needs to hold up
)> pushing this.
)>
)>
)>
)http://codereview.appspot.com/4811066/diff/8003/input/regression/mo
)zar
)> t-hrn-3.ly File input/regression/mozart-hrn-3.ly (right):
)>
)>
)http://codereview.appspot.com/4811066/diff/8003/input/regression/mo
)zar
)> t-hrn-3.ly#newcode27
)> input/regression/mozart-hrn-3.ly:27: \typewriter {
)> "http://mutopiaproject.org/"; } this would be slightly nicer if you
)> used \url instead of \typewriter.
)> That would use that typeface, but would also produce a clickable link.
)>
)> http://codereview.appspot.com/4811066/
)
)Nitpick changed - I've kept typewriter for the look, but added url. Patch
)attached. Please push.
)
)--
)Phil Holmes
0001-Update-regtest-morart-hrn.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Version specific code
In website_post.py, we have the following:
if (line.find('2.12') >= 0):
line = line.replace('a href=', 'a
onClick=\"javascript:urchinTracker(\'/download/v2.12\');\" href=')
elif (line.find('2.13') >= 0):
line = line.replace('a href=', 'a
onClick=\"javascript:urchinTracker(\'/download/v2.13\');\" href=')
This (I think) means we're currently not using the Google analytics to track
downloads.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
Am Montag, 8. August 2011, 02:59:31 schrieb Graham Percival: > - will will ***NOT*** display any errors from g++. (second point) > - exception: we ***MIGHT*** display some portion(s) of the > relevant log file(s). The policy uses the word "might" here, > not "must". There is a huge difference between those two words. > > Please always remember that there is a difference between the > make(1) program, and other programs which are called by make(1). > > ... if we are still this unclear about precisely what the policy > states, No, the policy is clear in that regard. It's just that this is a decision I simply CANNOT LIVE WITH! You know, compiler errors is the single most important information that a build system can give, even more important than success/failure message! To a developer that's the information that is absolutely required from a build system. Also, this policy builds on the assumption that the commands called by make are the most important things and all output created by them (e.g. compiler warnings, errors, etc.) are not that important. This gets the priorities completely wrong: The exact command line called by make (usually 5-10 lines of output!) might be useful to reproduce, but only know what the problem is. The current proposal does NOT tell you that there is a problem and what the problem is. So you can't use the exact commands directly anyway. On the other hand, the compiler errors are typically crafted to tell you which problem occurred and where, so you can easily fix the problem and run make again, without having to know the exact call of the gcc binary. Below I'll make a list of possible output from a build system, with things that are essential to me as a developer down to things that might be an annoyance if printed. Our build system will be about the only build system on earth that does not print compiler errors. And that makes it pretty useless as a build system. Currently, the normal build (i.e. 'make') produces output that is acceptable for developing lilypond. On the other hand, I think we all agree that a docs build prints out so much that the output is not really usable. Plus, the error output for errors in lilypond-book-included snippets is broken in that it does not properly tell you which file exactly failed and how it failed. For a compilation run, the following types of output are possible, sorted in my order of importance. Everything above the +++ separator I consider absolutely essential and a major annoyance to a developer if not printed by default. Everything below the - separator is also not useful and if printed clutters the output with unuseful information, thus making it an annoyance, too. COMPILATION RUN: When coding, all compiler errors and warnings are essential, because they need to be fixed (warnings usually point to serious coding errors!) 1) Compiler errors 2) Success/Failure of the build 3) Simple progress (which file is processed) 4) Compiler warnings (usually pointing to serious programming errors) +++ 5) directory traversal of make 6) make failures 7) Exact commands called by make 8) "normal" output (progress) by commands invoked by make --- 9) All environment variables 10) debug output by commands invoked by make (i.e. output for debugging a problem with the invoked commands, like a bug in gcc, not for problems in the files processed) Ideally, the default make prints out 1-6 (at least 1-4). Verbose prints out more. DOCUMENTATION BUILD: Here things are a bit different, because e.g. some regtests are supposed to trigger warnings. 1) Success/Failure of the whole build 2) Error messages 3) Simple progress (which file is processed) 4) make failures 5) Warnings that should be fixed 6) directory traversal of make +++ 7) minimal progress output by commands invoked by make (e.g. lilypond-book printing which snippet it is processing) 8) Exact commands called by make 9) "normal" output (progress) by commands invoked by make (e.g. lilypond-book printing the progress for each processed snippet) 10) Warnings that are expected and should be there (e.g. in regtests) 11) All environment variables (e.g. python include pathes!) needed to call the commands manually --- 12) debug output by commands invoked by make (i.e. output for debugging a problem with the invoked commands, e.g. a bug in gcc, not for problems in the files processed; or all debug output of lilypond when processing snippets - this is only needed to find a bug in lilypond, but not useful to find a typo in the documentation) Ideally, the default make prints out 1-7 or 1-9. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/,
Re: GOP-PROP 5: build system output (final)
Am Sonntag, 7. August 2011, 11:11:13 schrieb Phil Holmes: > There's no intention of stopping make showing errors. There is an issue > with warnings - make doc produces so many that the output is pretty much > unreadable, and they've been ignored for a long time - so having warnings > turned off by default is the preferred option. We should allow them to be > turned back on, though. For a documentation build, I might agree (some of the warnings are desired, like in some regtests, while others are harmless), but for a build of the lilypond binary, hiding compiler warnings is a really bad idea, as they typically point to grave coding errors (e.g. variable shadowing, unused parameters, signed/unsigned messups, etc.). Many of them will directly cause bugs. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
no problem. I'll do it now.
James
)-Original Message-
)From: Phil Holmes [mailto:m...@philholmes.net]
)Sent: 08 August 2011 16:46
)To: James Lowe; philehol...@googlemail.com;
)percival.music...@gmail.com; n.putt...@gmail.com; lilypond-
)de...@gnu.org; re...@codereview.appspotmail.com
)Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)
)Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected
this
)to GP, but here's a corrected patch.
)
)--
)Phil Holmes
)
)
)- Original Message -
)From: "James Lowe"
)To: "Phil Holmes" ;
); ;
); ; ;
)Sent: Monday, August 08, 2011 4:13 PM
)Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
)
)
)I'll push it.
)
)james
)
))-Original Message-
))From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
))[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org]
)On )Behalf Of Phil Holmes
))Sent: 08 August 2011 15:54
))To: philehol...@googlemail.com; percival.music...@gmail.com;
))n.putt...@gmail.com; m...@philholmes.net; em...@philholmes.net;
))lilypond-devel@gnu.org; re...@codereview.appspotmail.com
))Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
))
))- Original Message -
))From:
))To: ; ;
));
))Cc: ;
))Sent: Sunday, August 07, 2011 11:42 PM
))Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
))
))
))> LGTM. My comment is a tiny nitpick; I don't think it needs to hold up )>
)pushing this.
))>
))>
))>
))http://codereview.appspot.com/4811066/diff/8003/input/regression/m
)o
))zar
))> t-hrn-3.ly File input/regression/mozart-hrn-3.ly (right):
))>
))>
))http://codereview.appspot.com/4811066/diff/8003/input/regression/m
)o
))zar
))> t-hrn-3.ly#newcode27
))> input/regression/mozart-hrn-3.ly:27: \typewriter { )>
)"http://mutopiaproject.org/"; } this would be slightly nicer if you )> used
)\url instead of \typewriter.
))> That would use that typeface, but would also produce a clickable link.
))>
))> http://codereview.appspot.com/4811066/
))
))Nitpick changed - I've kept typewriter for the look, but added url. Patch
))attached. Please push.
))
))--
))Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Phil, From: Phil Holmes [m...@philholmes.net] Sent: 08 August 2011 16:45 To: James Lowe; philehol...@googlemail.com; percival.music...@gmail.com; n.putt...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected this to GP, but here's a corrected patch. It's a bit blind leading the partially sighted here. I cannot apply this patch because I've already applied the original one. So can you reset (big red button in lilygit.tcl), then update source (git pull -r) and then make a new patch with just the correction? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
On Mon, Aug 08, 2011 at 04:45:49PM +0100, Phil Holmes wrote: > > Woh. There's an error - \url isn't part of Lilypond syntax! I'd > corrected this to GP, but here's a corrected patch. apparently the command is called \with-url instead. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
- Original Message - From: "James Lowe" To: "Phil Holmes" ; ; ; ; ; Sent: Monday, August 08, 2011 4:58 PM Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066) Phil, From: Phil Holmes [m...@philholmes.net] Sent: 08 August 2011 16:45 To: James Lowe; philehol...@googlemail.com; percival.music...@gmail.com; n.putt...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected this to GP, but here's a corrected patch. It's a bit blind leading the partially sighted here. I cannot apply this patch because I've already applied the original one. So can you reset (big red button in lilygit.tcl), then update source (git pull -r) and then make a new patch with just the correction? James= = Thanks. Here you go. -- Phil Holmes 0001-Mozart-horn-regtest-correct-url-to-typewriter.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Second time's the charm ;) commit 6f818c30809d32c10b33d13e51f0910788ac0493 James )-Original Message- )From: Phil Holmes [mailto:philehol...@googlemail.com] On Behalf Of )Phil Holmes )Sent: 08 August 2011 17:03 )To: James Lowe; philehol...@googlemail.com; )percival.music...@gmail.com; n.putt...@gmail.com; lilypond- )de...@gnu.org; re...@codereview.appspotmail.com )Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) ) )- Original Message - )From: "James Lowe" )To: "Phil Holmes" ; ); ; ); ; ) )Sent: Monday, August 08, 2011 4:58 PM )Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066) ) ) )Phil, ) )From: Phil Holmes [m...@philholmes.net] )Sent: 08 August 2011 16:45 )To: James Lowe; philehol...@googlemail.com; )percival.music...@gmail.com; n.putt...@gmail.com; lilypond- )de...@gnu.org; re...@codereview.appspotmail.com )Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) ) )Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected this )to GP, but here's a corrected patch. ) ) ) )It's a bit blind leading the partially sighted here. ) )I cannot apply this patch because I've already applied the original one. ) )So can you reset (big red button in lilygit.tcl), then update source (git pull - )r) and then make a new patch with just the correction? ) )James= )= ) )Thanks. Here you go. ) )-- )Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
On Mon, Aug 08, 2011 at 05:48:47PM +0200, Reinhold Kainhofer wrote: > Am Montag, 8. August 2011, 02:59:31 schrieb Graham Percival: > > ... if we are still this unclear about precisely what the policy > > states, > > No, the policy is clear in that regard. It's just that this is a decision I > simply CANNOT LIVE WITH! ok. This proposal was too board. We'll scrap it, and do this with narrower scope. Your logging system for the lilypond(1) binary seems to have a great deal of support. On Wednesday, I'll introduce a proposal for the output of "make doc". Once that's been accepted and work has started, I'll introduce a separate proposal for "make test", and once that's accepted, I'll introduce another proposal for "make". Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Kievan square notation in LilyPond
On 8/8/11 6:07 AM, "Aleksandr Andreev" wrote: > Hi Jan, > > Thanks for your comments. > >> In case of noteheads, i suppose that everything would be best defined in >> staff_space. For stems (as i understand there are special characters for >> stems) stafflinethickness will be more appropriate. > > Right now, I've got the notehead and stem being drawn as one > character. Is this a bad idea? It's a fine idea, as long as you don't want to have stems or beams. You'll want to remove the stem_engraver and the beam_engraver from places you use Kievan square notes. > >> However, i may be mistaken since i don't see the code. > > Here's the file I'm working with right now: > http://www.ponomar.net/files/metasuprasl.mf > > And here's a proof sheet to make your life easier: > http://www.ponomar.net/files/metasuprasl.pdf > The glyphs look very nice. I *think* you'll want to use fet_beginchar instead of beginchar. > Would it be appropriate to define a basis unit u in terms of > stafflinethickness and then specify the points in terms of u? I think that staff_space would be a better basis than stafflinethickness. staff_space governs the overall size of things. > Where is the origin? I believe that the origin is at the center of the note head. That's the basis under which I worked on the shape note heads. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
Phil, you wrote Monday, August 08, 2011 4:07 PM I do use Windows mail's newsgroups interface to post to devel, and it's possible I'm unique in that, and that Trevor is unique in that he also uses Windows mail, but without subscribing. I'll see how I can avoid the problem in future. Thanks Phil. For my part I'm happy to investigate subscribing to the lily-dev newsgroup to see if that fixes the problem. But the only newsgroups Windows Mail presents to me are MS ones. How do I get at the lily ones? Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3820 - Release Date: 08/07/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
- Original Message - From: "Trevor Daniels" To: "Phil Holmes" ; "Graham Percival" Cc: "Lily-Devel List" Sent: Monday, August 08, 2011 6:10 PM Subject: Re: Search box changes Phil, you wrote Monday, August 08, 2011 4:07 PM I do use Windows mail's newsgroups interface to post to devel, and it's possible I'm unique in that, and that Trevor is unique in that he also uses Windows mail, but without subscribing. I'll see how I can avoid the problem in future. Thanks Phil. For my part I'm happy to investigate subscribing to the lily-dev newsgroup to see if that fixes the problem. But the only newsgroups Windows Mail presents to me are MS ones. How do I get at the lily ones? Trevor Slightly difficult to check, since I've already got it set up. I reckon Tools, Accounts, Add, Newsgroup Account and eventually use the server news.gmane.org. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
On 2011/08/08 15:19:06, Carl wrote: Can we have a regtest, please? Regtest added. Cheers, MS http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Prevents nested tuplets from colliding. (issue4808082)
Reviewers: ,
Message:
This fixes Issue 509 and passes regtests.
Cheers,
MS
Description:
Prevents nested tuplets from colliding.
Please review this at http://codereview.appspot.com/4808082/
Affected files:
M input/regression/tuplet-nest.ly
M lily/tuplet-bracket.cc
M scm/define-grob-properties.scm
M scm/define-grobs.scm
Index: input/regression/tuplet-nest.ly
diff --git a/input/regression/tuplet-nest.ly
b/input/regression/tuplet-nest.ly
index
dfdd543450bf13c3793e3b29671dd2213db49f61..f3a4a587f9f1c4f42e12dc5387dedc3d3345f8ff
100644
--- a/input/regression/tuplet-nest.ly
+++ b/input/regression/tuplet-nest.ly
@@ -11,10 +11,22 @@
}
\relative c'' {
+ \times 4/3 {
+\times 2/3 { c8 [c8 c8 ]}
+\times 2/3 { c8 [c8 c8 ]}
+\times 2/3 { c8 [c8 c8 ]}
+ }
+
+ \times 4/3 {
+\times 2/3 { a8 [a8 a8 ]}
+\times 2/3 { a8 [a8 a8 ]}
+\times 2/3 { a8 [a8 a8 ]}
+ }
+
\override TupletNumber #'text = #tuplet-number::calc-fraction-text
\times 4/6 {
\times 2/3 {
- a a a
+ a4 a a
}
\times 3/5 {
a a a a a
Index: lily/tuplet-bracket.cc
diff --git a/lily/tuplet-bracket.cc b/lily/tuplet-bracket.cc
index
c6dfa799924a5c4b169406cf26854c1b865d0f24..c97be7ef7d0f9bd5fe7234a38a09d293d0bcdea9
100644
--- a/lily/tuplet-bracket.cc
+++ b/lily/tuplet-bracket.cc
@@ -51,6 +51,7 @@
#include "note-column.hh"
#include "pointer-group-interface.hh"
#include "directional-element-interface.hh"
+#include "skyline.hh"
#include "spanner.hh"
#include "staff-symbol-referencer.hh"
#include "lookup.hh"
@@ -656,6 +657,10 @@ Tuplet_bracket::calc_position_and_height (Grob
*me_grob, Real *offset, Real *dy)
points.push_back (Offset (tuplet_x[d] - x0, y));
}
while (flip (&d) != LEFT);
+ // Check for number-on-bracket collisions
+ Grob *number = unsmob_grob (tuplets[i]->get_object
("tuplet-number"));
+ if (number)
+points.push_back (Offset (number->extent (commonx, X_AXIS).center
() - x0, number->extent (commony, Y_AXIS).center ()));
}
*offset = -dir * infinity_f;
@@ -671,6 +676,34 @@ Tuplet_bracket::calc_position_and_height (Grob
*me_grob, Real *offset, Real *dy)
*offset += scm_to_double (me->get_property ("padding")) * dir;
+ // have to re_run numbers to check for number-on-number collisions
+ Grob *my_number = unsmob_grob (me->get_object ("tuplet-number"));
+ if (my_number)
+{
+ /*
+Slightly kludgy, as it centers the number as it would be in
ly:tuplet-number::stencil
+If this function is over-ridden, this may lead to bizarre
results...
+ */
+ Stencil *my_number_stencil = unsmob_stencil (Text_interface::print
(me->get_object ("tuplet-number")));
+ Real base_line = minmax (dir, *offset, *offset + *dy) + dir * fabs
(*dy) / 2;
+ Real sten_len = my_number_stencil->extent (Y_AXIS).length () / 2;
+ Box my_number_box = Box (my_number_stencil->extent (X_AXIS),
Interval (base_line - sten_len, base_line + sten_len));
+ my_number_box[X_AXIS] = my_number_box[X_AXIS] + x0 + (x1 - x0) / 2 -
my_number_box[X_AXIS].length () / 2;
+ Skyline my_number_skyline (my_number_box, 0.0, X_AXIS, -dir);
+ vector their_number_boxes;
+ for (vsize i = 0; i < tuplets.size (); i++)
+{
+ Grob *her_number = unsmob_grob (tuplets[i]->get_object
("tuplet-number"));
+ if (her_number)
+their_number_boxes.push_back (Box (her_number->extent
(commonx, X_AXIS), her_number->extent (commony, Y_AXIS)));
+}
+ Skyline their_numbers_skyline (their_number_boxes, 0.0, X_AXIS, dir);
+ Real dist = my_number_skyline.distance (their_numbers_skyline);
+ Real tuplet_number_padding = robust_scm2double (me->get_property
("tuplet-number-padding"), 0.0);
+
+ if (dist > -tuplet_number_padding)
+*offset += dir * (dist + tuplet_number_padding);
+}
/*
horizontal brackets should not collide with staff lines.
@@ -830,6 +863,7 @@ ADD_INTERFACE (Tuplet_bracket,
"note-columns "
"padding "
"tuplet-number "
+ "tuplet-number-padding "
"shorten-pair "
"staff-padding "
"thickness "
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index
3f9da21f6d0c7e71b4aa172f3f30677b4d7b72bd..a0ab26557258de1ad61ae1cd2e1ce805cb0d8fa7
100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -896,6 +896,8 @@ toward the stem if their direction coincides with the
stem direction.
head), @code{1.0} means centered on the stem. Interpolated values are
possible.")
(transparent ,boolean? "This makes the grob invisible.")
+ (tuplet-number-padding ,number? "Padding between two tuplet
+numbers.")
;;
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index
4545e5bd9f
Re: Search box changes
Phil, you wrote Monday, August 08, 2011 6:30 PM From: "Trevor Daniels" For my part I'm happy to investigate subscribing to the lily-dev newsgroup to see if that fixes the problem. But the only newsgroups Windows Mail presents to me are MS ones. How do I get at the lily ones? Slightly difficult to check, since I've already got it set up. I reckon Tools, Accounts, Add, Newsgroup Account and eventually use the server news.gmane.org. Thanks. I've set it up and subscribed to all the Lily groups, but it didn't help. However, I have found the troublesome Newsgroup: field only appears if I hit Reply to All. If I just use Reply I get a standard reply window with your email address in. So all I have to do is add a Cc: for lily-devel - that I can do easily. So, problem solved. I should have tried that earlier :( but I'm so used to always hitting Reply to All when replying to mailing lists I didn't think of it. So feel free to continue to use Newsgroups - I can handle them now. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3821 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour countdown
On 11-08-07 01:03 AM, Graham Percival wrote: Sorry for the delay; Colin's away this week, and he asked me to keep it rolling, but now that I'm in Canada I suddenly (and unexpectedly!) have a social life, so I'm not keeping stuff together all that well. Colin's back today, and can't decide how to react to the implication that Weejuns and Canadians don't ordinarily have a social life. Thanks for carrying on, Graham, in as many senses as seem reasonable! Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
Hi all, >> 2) list all environment variables used (both internally and >> externally) in the build system in the CG. >> >> Advantage: at least this knowledge is written down somewhere. >> Disadvantage: the list will not be kept up-to-date. (don't argue; >> there's absolutely nothing you can say that will make me believe >> that everybody will keep it up-to-date over the next 20 years) > > Think it's quite a bit of work, too. I don't know anything about the build system, but isn't it possible to do this automatically? Say, if you rename all lilypond-related environment variables so that they start with LILY_ then why can't you say something like 'env | grep LILY_' and put the output into the CG? Please ignore if this doesn't make any sense, I haven't followed the thread closely so I may be missing something. Cheers, Max P.S.: Since Graham mentioned getting rid of environment variables: only very recently have I started to appreciate the enormous value they have once you work on systems where things are just slightly different than what everyone considers to be standard because everyone uses Ubuntu (I'm exaggerating, of course) - or even just for testing different configurations on the same system. So personally I'd say try to keep them if at all possible. Just my two cents. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
LGTM. Thanks, Carl http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Treats multi measure rest staff position like rest staff position. (issue4822046)
Passes make and reg tests http://codereview.appspot.com/4822046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
On 08/08/11 21:36, Maximilian Albert wrote: > I don't know anything about the build system, but isn't it possible to > do this automatically? Say, if you rename all lilypond-related > environment variables so that they start with LILY_ then why can't you > say something like 'env | grep LILY_' and put the output into the CG? > Please ignore if this doesn't make any sense, I haven't followed the > thread closely so I may be missing something. >From digging into the LibreOffice build system ... All environment variables should be specified / set up there, so getting hold of a definitive list should just be a matter of reading something like configure.sh (Note I said *should* :-) > > Cheers, > Max > > P.S.: Since Graham mentioned getting rid of environment variables: > only very recently have I started to appreciate the enormous value > they have once you work on systems where things are just slightly > different than what everyone considers to be standard because everyone > uses Ubuntu (I'm exaggerating, of course) - or even just for testing > different configurations on the same system. So personally I'd say try > to keep them if at all possible. Just my two cents. LibreOffice has (and don't ask me how it's done) various distro-specific files which pull in the requisite settings for those distros. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a glyph for tied lyrics. (issue4808074)
Passes make and reg tests http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
FW: New Binary for LilyPond on MacOSX 10.7 available
For some reason Hans won't email the group ;) From: Hans Aberg [haber...@telia.com] Sent: 08 August 2011 21:54 To: James Lowe Cc: Floris van Manen Subject: Re: New Binary for LilyPond on MacOSX 10.7 available On 8 Aug 2011, at 20:39, James Lowe wrote: > )> We have built a new binary for use on 10.7 that we wondered if you can > )try. > )> > )> http://lilypond.org/~graham/ > ) > )It works on a developer release (opening the Application and compiling a > )simple example), but I suggest you try on the final, public release. > There is a bug: when showing Info in the Finder, it says version 2.14.2. But $ LilyPond.app/Contents/Resources/bin/lilypond --version GNU LilyPond 2.15.9 Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue4808082)
Passes make and reg test diff looks ok see http://code.google.com/p/lilypond/issues/detail?id=509#c4 for attached png http://codereview.appspot.com/4808082/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
On Mon, Aug 08, 2011 at 09:36:34PM +0100, Maximilian Albert wrote: > P.S.: Since Graham mentioned getting rid of environment variables: > only very recently have I started to appreciate the enormous value > they have once you work on systems where things are just slightly > different than what everyone considers to be standard because everyone > uses Ubuntu (I'm exaggerating, of course) - or even just for testing > different configurations on the same system. So personally I'd say try > to keep them if at all possible. Just my two cents. I'm talking about making the variables explicit. Right now, you can copy&paste a line from the build system output that fails within the build but works perfectly well on your command-line (and vice-versa). That makes it hard to debug stuff. If we print the variables for each command, then there'll be no such confusion. (or at least, if we print any non-standard or unusual variables -- I'm not suggesting that we need to print the PATH for every command!) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Version specific code
On Mon, Aug 08, 2011 at 04:48:46PM +0100, Phil Holmes wrote:
> In website_post.py, we have the following:
>
>if (line.find('2.12') >= 0):
>line = line.replace('a href=', 'a
> onClick=\"javascript:urchinTracker(\'/download/v2.12\');\" href=')
>elif (line.find('2.13') >= 0):
>line = line.replace('a href=', 'a
> onClick=\"javascript:urchinTracker(\'/download/v2.13\');\" href=')
>
> This (I think) means we're currently not using the Google analytics
> to track downloads.
That sounds like a reasonable investigation. Next step: does the
html source contain any urchinTracker? If not, then we're
definitely not using the Google analytics!
Once this bug is confirmed, please either add it to the tracker,
or fix that part (test it the same way you investigated whether
it's actually there or not, in the html source). Or both, I
suppose, but this doesn't look like a long job so we might as well
fix it and push directly.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Since you pushed it, James, could you correct the \typewriter to \with-url ? Before you push, compile it on the command-line to make sure you have the right syntax and you have a clickable link. Cheers, - Graham On Mon, Aug 08, 2011 at 04:08:16PM +, James Lowe wrote: > Second time's the charm > > ;) > > commit6f818c30809d32c10b33d13e51f0910788ac0493 > > James > > )-Original Message- > )From: Phil Holmes [mailto:philehol...@googlemail.com] On Behalf Of > )Phil Holmes > )Sent: 08 August 2011 17:03 > )To: James Lowe; philehol...@googlemail.com; > )percival.music...@gmail.com; n.putt...@gmail.com; lilypond- > )de...@gnu.org; re...@codereview.appspotmail.com > )Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) > ) > )- Original Message - > )From: "James Lowe" > )To: "Phil Holmes" ; > ); ; > ); ; > ) > )Sent: Monday, August 08, 2011 4:58 PM > )Subject: RE: Rewrite regtest mozart-hrn-3.ly (issue4811066) > ) > ) > )Phil, > ) > )From: Phil Holmes [m...@philholmes.net] > )Sent: 08 August 2011 16:45 > )To: James Lowe; philehol...@googlemail.com; > )percival.music...@gmail.com; n.putt...@gmail.com; lilypond- > )de...@gnu.org; re...@codereview.appspotmail.com > )Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066) > ) > )Woh. There's an error - \url isn't part of Lilypond syntax! I'd corrected > this > )to GP, but here's a corrected patch. > ) > ) > ) > )It's a bit blind leading the partially sighted here. > ) > )I cannot apply this patch because I've already applied the original one. > ) > )So can you reset (big red button in lilygit.tcl), then update source (git > pull - > )r) and then make a new patch with just the correction? > ) > )James= > )= > ) > )Thanks. Here you go. > ) > )-- > )Phil Holmes > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added \compoundMeter function to NR (issue4837050)
Draft 5 - removed all translation docs with this snippet in it too (for when it is removed from LSR). have at it. http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1643 Documentation/notation/rhythms.itely:1643: come before it indicate the beat value. On 2011/08/08 07:32:48, Janek Warchol wrote: On 2011/08/07 20:33:38, J_lowe wrote: > On 2011/08/07 15:24:44, Trevor Daniels wrote: > > I think it's clearer to say top and bottom of the time signature: > > ... last number in the list is placed at the bottom of the time signature and > > the numbers that come before it are placed as a summation at the top. All but > > the last number indicate the stress groupings and sum to the duration of the > > measure. > > hmmm..I still think that is a bit awkward - I'm not sure 'summation' comes over > well for non-native English speakers looking at the NR. I also don't feel the > last sentence is necessary if the @lilyponds are good enough (that and we talk > about beaming anyway later). See what you think of my very simple change. I agree that the last sentence suggested by Treveor isn't necassary. I think that if we change "summation" to "sum" in his proposal, it will be understood by people. In Wiktionary i see that word for sum is similar in many languages. Well I haven't made any changes since my last edit. See if this is ok. http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely#newcode1643 Documentation/notation/rhythms.itely:1643: before it, the bottom numbers. On 2011/08/08 07:32:48, Janek Warchol wrote: It's the other way round - Last number goes to the bottom. Done. http://codereview.appspot.com/4837050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham Percival wrote Monday, August 08, 2011 6:06 AM ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. This is a better approach than haggling over priority. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-critical: [snipped] * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. More new/changed types [snipped] * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. I don't think this is a stand-alone type. It's more a label which could be applied to several types. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. I like this suggestion. There are already 6 open issues with more than 7 stars, so it's already being used. In spite of that we'd need to explain more clearly how to star an issue so all users can play, with a disclaimer that some issues might not receive attention however many stars they get. It will give quite a different rating cf to the priority field. Of the 6 issues with more than 7 stars, 2 are low, 3 medium and 1 abandoned! Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3821 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added \compoundMeter function to NR (issue4837050)
LGTM Although I'm not sure about editing the other language files. Best wait for Francisco to comment. http://codereview.appspot.com/4837050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New Binary for LilyPond on MacOSX 10.7 available
On 8 Aug 2011, at 23:11, James Lowe wrote: > For some reason Hans won't email the group ;) So then don't forward my mail to the lists! - The reason is that I can't verify it, so I do not want unreliable information spread around. Wait until you find someone who can do it. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Mon, Aug 08, 2011 at 10:50:02PM +0100, Trevor Daniels wrote: > > Graham Percival wrote Monday, August 08, 2011 6:06 AM > > > * anything which stops contributors from helping out (e.g. > > lily-git.tcl not working, source tree(s) not being > > available). To limit this scope of this point, we will > > assume that the contributor is using the latest lilydev and > > has read the relevant part(s) of the Contributor’s Guide. > > I agree this is important, but I don't see why it > should prevent a new release per se. Hmm. I must admit that this rather contrasts with the "we should let each contributor make their own judgement" sentiment. > > * Type-ignorance: (fixme name?) it is not clear what the > > correct output should look like. We need scans, references, > > examples, etc. > > I don't think this is a stand-alone type. It's more a label > which could be applied to several types. Well... it depends on how much we trust users (and even developers!) to be able to search the tracker, and/or pay attention to the labels. I'd like to make it Really Bleeding Obvious (tm) to users that an issue is in limbo; no programming will or can take place until some non-technical work is done (i.e. finding the references). The most visible sign is to have a Type specifically for such issues, but as you point out, this isn't really a "type" kind of thing. I guess that at the moment, I still have a slight preference for this "abuse" of the "type" system... but I could be convinced otherwise. Especially if there's another way of making this clear? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
On 08/08/11 16:04, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > To: "Phil Holmes" > Cc: > Sent: Sunday, August 07, 2011 11:45 PM > Subject: Re: Search box changes > > >> On Sun, Aug 07, 2011 at 05:33:45PM +0100, Phil Holmes wrote: >>> I've prepared some changes for the web search box in line with what >>> I suggested in >>> http://code.google.com/p/lilypond/issues/detail?id=1806 - screenshot >>> attached. >> >> I'd need to look at the effects of the patch to see how it behaves >> in a 800-pixel wide screen. > > I didn't expect it to, but it looks fine. Image attached. I would > actually propose not supporting screens this narrow - even netbooks > typically run 1024x600. And then people like me get royally pee-d off! I HATE HATE HATE screens that only work when maximised. I typically have a whole bunch of programs running at once, and try and arrange my screen so that *all* of them are partially visible *all* the time. Anything that tries to force me to run full-screen generally annoys me so much that I stop using it. If it needs that much screen estate, fair enough, but if it doesn't need it don't use it! Let the USER decide how much screen they want to give it, don't demand that it be allowed to take the lot! Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where X-extent of noteheads is set?
2011/8/7 Bertrand Bordage :
>> I've done a very dirty test which showed that a properly set glyph
>> bounding box solves this perfectly (see in the attachment how the
>> bounding box should change).
>> However, there is a problem. Currently bounding box is set by
>> procedure draw_outside_ellipse (defined in mf/feta-params.mf) - it is
>> not set in the definition of the glyph. How to set glyph bounding box
>> to something different than outside_ellipse bounding box?
>
> You could define it in the "final" definitions of glyphs. Here is an
> example. Of course, these values have to be define in a clean metafont way.
> fet_beginchar ("Brevis notehead", "sM1");
> draw_brevis (1, 1);
> draw_staff (-2, 2, 0);
> set_char_box (.1 staff_space#, 2.1 staff_space#, .5 staff_space#, .5
> staff_space#);
> fet_endchar;
Yes, it works!
I'll upload a draft soon.
thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a glyph for tied lyrics. (issue4808074)
I'd make the tie slightly shorter. I find it awkward that two adjacent
ties collide so easily, for example here
{
\time 3/4
\relative c' { c2 e4 g2 e4 }
\addlyrics { gran- de_a- mi- go }
\addlyrics { pu- "ro y ho-" nes- to }
\addlyrics { pu- ro~y~ho- nes- to }
}
(example from documentation), or in the example you attached on the
tracker issue page.
cheers,
Janek
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
2011/8/8 Trevor Daniels : > > Graham Percival wrote Monday, August 08, 2011 6:06 AM >> Type-critical: >> * anything which stops contributors from helping out (e.g. >> lily-git.tcl not working, source tree(s) not being >> available). To limit this scope of this point, we will >> assume that the contributor is using the latest lilydev and >> has read the relevant part(s) of the Contributor’s Guide. > > I agree this is important, but I don't see why it > should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
LGTM note that image of the issue will also require a minimum distance setting, otherwise, the glissando will be shortened into a dot? http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
On 2011/08/09 05:08:56, hanwenn wrote: LGTM note that image of the issue will also require a minimum distance setting, otherwise, the glissando will be shortened into a dot? Done. New patchset uploaded. Cheers, MS http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents lilypond from segfaulting with add-footer = ##f (issue4832046)
On 2011/08/02 21:45:52, Neil Puttock wrote:
http://codereview.appspot.com/4832046/diff/2001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/4832046/diff/2001/lily/page-layout-problem.cc#newcode282
lily/page-layout-problem.cc:282: warning ("Must have a footer to add
footnotes.");
(_ ("must have a footer to add footnotes"))
but we only want this warning to appear if the user has added
footnotes
Fix pushed as 435b36a3e6576cebf794d815ae7cc78b652180f9.
Cheers,
MS
http://codereview.appspot.com/4832046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Correctly parses nan from scheme in output-distance (issue4835049)
Reviewers: ,
Message:
Pushed as 7cd9444ea5dfc80782befa6b64bae015bddbd967.
Cheers,
MS
Description:
Correctly parses nan from scheme in output-distance
Please review this at http://codereview.appspot.com/4835049/
Affected files:
M scripts/build/output-distance.py
Index: scripts/build/output-distance.py
diff --git a/scripts/build/output-distance.py
b/scripts/build/output-distance.py
index
c08ea147b86eb40556f77d0f0d384e56c93741f7..537363b63a4958b26ab2698e72d08ff91c858aaa
100644
--- a/scripts/build/output-distance.py
+++ b/scripts/build/output-distance.py
@@ -313,12 +313,15 @@ class SystemLink:
self.orphan_count (),
self.geometric_distance ())
+def scheme_float (s) :
+ return float(s) if 'nan' not in s else float(s.split('.')[0])
+
def read_signature_file (name):
print 'reading', name
entries = open (name).read ().split ('\n')
def string_to_tup (s):
-return tuple (map (float, s.split (' ')))
+return tuple (map (scheme_float, s.split (' ')))
def string_to_entry (s):
fields = s.split('@')
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
