Re: Avoid Scheme-computed Skyline_pair values to get collected before use (issue 12708048)
On 2013/08/12 05:50:10, Keith wrote: On 2013/08/11 21:07:03, dak wrote: It's conceivable that this change helped, though there don't seem to be a lot of opportunities for garbage collection between return of the SCM value and use of the Skyline_pair. There is ample opportunity for garbage generation and garbage collection. The call to maybe_pure_coordinate() estimates positions for everything in the score, which causes a lot of computation and memory use. Adding the two tracer printf()s below, I see a SCM object holding the skyline for the Presto is returned, then two hundred twenty three other skylines are created, side-positioned, and discarded, Independent of this issue, this seems, uh, excessive? then the pointer into the skyline for the Presto is accessed. I think that the C++ memory allocator is independent of the Scheme allocator (ly:format uses scm_malloc so it may garbage collect when memory is tight, but that seems about the only use of scm_malloc). So as long as the skylines calculated in between are not smobbed (turned into Scheme objects), the Scheme garbage collector has no incentive to run. Some Scheme objects, however, are allocated whenever a symbol is encountered for the first time, so there are a lot of code paths that seem safe from triggering garbage collection _except_ when they are run for the first time. While most symbols used via get_property or similar are already somewhere present in permanent Scheme code (and thus the symbols themselves are already allocated), the memoizing construct used internally by get_property enters them into a weak hash table to make sure they have a reference. Maintenance of that weak hash table can still cause a Scheme allocation on the first run through. In short: it's just not a good idea to rely on no Scheme allocations in a non-trivial code passage. At any rate, the circumstances of this patch seem sufficient for retesting current master. https://codereview.appspot.com/12708048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make doc: was: Windows tutorial
- Original Message - From: David Kastrup d...@gnu.org To: Colin Campbell c...@shaw.ca Cc: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Sunday, August 11, 2013 10:19 PM Subject: Re: Windows tutorial Oh, again with only the usual warnings? I thought that repeatably was supposed to mean repeatably crashing. Any news from those who had reliable crashes to show? -- David Kastrup Just successfully run a full make doc against git master - the first time this has been successful for a few months. I'm 99.9% certain that this patch has fixed the problem - I think we can mark it closed. Thanks David, Keith and others for getting to the bottom of the problem. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Increase tagline spacing (Issue 3214) (issue 12562050)
Updating 2 regtests to prevent new overflow. Overflow would be expected, so allowing one regtest to compress a little more by using lyrics with smaller vertical extent, and getting rid of the tagline on the other, which is not really appropriate for paper of this size. https://codereview.appspot.com/12562050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
- Original Message - From: tdanielsmu...@googlemail.com To: philehol...@googlemail.com Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Sunday, August 11, 2013 3:33 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) Non-standard headings; otherwise LGTM. https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode67 Documentation/learning/common-notation.itely:67: @subheading Bar lines @unnumberedsubsubsec plus @node and menu See http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode80 Documentation/learning/common-notation.itely:80: @subheading Bar checks ditto https://codereview.appspot.com/12724043/ More than happy to make this change, but there's lots and lots of subheading headings in that file - should they all be taken out? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
On 2013/08/12 13:48:32, email_philholmes.net wrote: - Original Message - From: mailto:tdanielsmu...@googlemail.com To: mailto:philehol...@googlemail.com Cc: lilypond-devel@gnu.org; mailto:re...@codereview-hr.appspotmail.com Sent: Sunday, August 11, 2013 3:33 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) Non-standard headings; otherwise LGTM. https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode67 Documentation/learning/common-notation.itely:67: @subheading Bar lines @unnumberedsubsubsec plus @node and menu See http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode80 Documentation/learning/common-notation.itely:80: @subheading Bar checks ditto https://codereview.appspot.com/12724043/ More than happy to make this change, but there's lots and lots of subheading headings in that file - should they all be taken out? -- Phil Holmes Well, it's quite a bit of work as they'll need menus and nodes adding. Each subsubsec will be rather small, but I think it is well worth doing as these subsubsecs can then be referenced individually and they'll appear as headings in the ToC. They can also be given a more direct reference from the indexes. https://codereview.appspot.com/12724043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
- Original Message - From: tdanielsmu...@googlemail.com To: philehol...@googlemail.com; em...@philholmes.net Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org Sent: Monday, August 12, 2013 3:50 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) On 2013/08/12 13:48:32, email_philholmes.net wrote: - Original Message - From: mailto:tdanielsmu...@googlemail.com To: mailto:philehol...@googlemail.com Cc: lilypond-devel@gnu.org; mailto:re...@codereview-hr.appspotmail.com Sent: Sunday, August 11, 2013 3:33 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) Non-standard headings; otherwise LGTM. https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode67 Documentation/learning/common-notation.itely:67: @subheading Bar lines @unnumberedsubsubsec plus @node and menu See http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode80 Documentation/learning/common-notation.itely:80: @subheading Bar checks ditto https://codereview.appspot.com/12724043/ More than happy to make this change, but there's lots and lots of subheading headings in that file - should they all be taken out? -- Phil Holmes Well, it's quite a bit of work as they'll need menus and nodes adding. Each subsubsec will be rather small, but I think it is well worth doing as these subsubsecs can then be referenced individually and they'll appear as headings in the ToC. They can also be given a more direct reference from the indexes. https://codereview.appspot.com/12724043/ OK - I suggest I don't change my patch as you've suggested, because the way I did it was to copy the original, and so it currently follows the style for that section. I'll raised an issue to change all instances of @subheading to @unnumberedsubsubsec in the LM and do that once this patch is pushed. That sound OK? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
Phil, you wrote OK - I suggest I don't change my patch as you've suggested, because the way I did it was to copy the original, and so it currently follows the style for that section. I'll raised an issue to change all instances of @subheading to @unnumberedsubsubsec in the LM and do that once this patch is pushed. That sound OK? Yup. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond meeting in Waltrop, Germany, 2013-08-16 to 2013-08-20
David Kastrup d...@gnu.org writes: Well, after several announcements, I now have about four participants for this year's meeting secured. While that's about the amount who bothered registering timely last year, it means that I am not able to plan suitably ahead. Well, we are now six (though at most five at a time). I've thought briefly about postponing the meeting, but then it is unclear that there is actually significantly more interest this year, the date has been announced a long time ago already, a few people actually prepared for it, and it makes good sense to make use of camping weather. And actually, we can still get quite a bit done and discussed as there are a few shared interests and heavy hitters. But I need to rein in the dates. Here are what I have so far: Jan Niewenhuizen: reports from the Liedboek project, bringing samples, and I'll likely milk him for getting some internals documented and some GUB stuff. Arrives either Thursday evening or Friday noon and leaves Sunday evening. Pitches a tent on our ground. Han-Wen Nienhuys: participation unclear, has a concert on Sunday evening, can likely come Monday at the earliest. Thomas Morley/Harm: still on vacation (so no early feedback), will bring his own tent, will come, but I don't know when. Janek: announced coming, but I don't know when. Jan Rosseel from the Scora project (check it out) can attend from Sunday morning to Monday afternoon (halfway). Can bring an LCD projector. Given the low total number of participants, we can probably get along without renting one on the other days. Patrick Schmidt (Philomelos project) will arrive by bike and bring his own tent. Don't know the exact dates. I think it would make sense if he planned to be here overlapping with Jan Rosseel as they have related interests/projects. Jan Rosseel enquired about whether there was a quorum for the event happening because he wanted to know whether to book a hotel: I think with the rather high-profile guests, we'll find stuff to work on anyway and there is actually quite a bit of overlap in interests/projects/abilities. While I can't vouch for a separate room for everybody, there is certainly quite more room in the house per guest than the last time round particularly given the high number of campers, so we'll probably be able to have everybody in the house (I can't vouch that the work on the plumbing will be finished, though, but I certainly hope so). The travel details again, ask if you have questions: Reports about the last meeting can be found at URL:http://news.lilynet.net/?The-LilyPond-Report-28. Information about travel and place (please don't get confused by last year's dates!) is still at URL:http://news.lilynet.net/?LilyPond-meeting-in-Waltrop, in a nutshell: Im Knäppen 63 in 45731 Waltrop, next useful bus station Waltrop Elmenhorst, next useful subway Brambauer Verkehrshof, next large train station Dortmund Hbf, next large airport Düsseldorf (there is some Ryanair airport called Düsseldorf Weeze which is actually quite far from Düsseldorf). Of course, the Spotted Flycatchers are nesting in different places, last year's foal Socke is by now a yearling, OpenStreetMap still has no clue about our address (but Google Maps does, and Bing Maps too, but the final yards of the approach have to be from the Southeast since the bridge to the Northwest has fallen prey to fire decades ago without telling Bing). The date this time around will be August 2013, Friday 16th to Tuesday 20th, with the possibility to arrive Thursday 15th late in the day for people who'd otherwise miss stuff early Friday. The proposed date coincides with the Dattelner Kanalfest URL:http://www.kanalfest.de/ which is the big competition (next town) of the Waltroper Parkfest we had running parallel to the conference last year. It still provides a reasonably close festival and entertainment for potentially not-just-LilyPond interested attendants or accompaniment, though with more focus on music and less on small arts like jugglers and stuff. But since it is next town, it will not suck dry external accommodation in Waltrop like the Parkfest did last year. So it should be easier for people preferring to stay at some hotel or similar to find something not too far away. Camping on the ground and sleep-ins are of course possible like last year and I expect most participants to make use of that. As mentioned above, most travellers will aim for Dortmund (through bus or train) though some international travellers will likely have Düsseldorf as their first destination in Germany. Hope to _really_ hear from you soon. All the best! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond meeting in Waltrop, Germany, 2013-08-16 to 2013-08-20
Hi David all, firstly let me apologize for being offline recently without letting you know. I need to get a better grip on myself... 2013/8/12 David Kastrup d...@gnu.org The following message is a courtesy copy of an article that has been posted to gmane.comp.gnu.lilypond.devel,gmane.comp.gnu.lilypond.general as well. David Kastrup d...@gnu.org writes: Well, after several announcements, I now have about four participants for this year's meeting secured. While that's about the amount who bothered registering timely last year, it means that I am not able to plan suitably ahead. Well, we are now six (though at most five at a time). I've thought briefly about postponing the meeting, but then it is unclear that there is actually significantly more interest this year, the date has been announced a long time ago already, a few people actually prepared for it, and it makes good sense to make use of camping weather. As for me, i haven't booked tickets yet, so if other people would like to move the meeting i can adapt. I have plans for 23-29th of August, but my September is quite free. And actually, we can still get quite a bit done and discussed as there are a few shared interests and heavy hitters. But I need to rein in the dates. Here are what I have so far: Jan Niewenhuizen: reports from the Liedboek project, bringing samples, and I'll likely milk him for getting some internals documented and some GUB stuff. Arrives either Thursday evening or Friday noon and leaves Sunday evening. Pitches a tent on our ground. Han-Wen Nienhuys: participation unclear, has a concert on Sunday evening, can likely come Monday at the earliest. Thomas Morley/Harm: still on vacation (so no early feedback), will bring his own tent, will come, but I don't know when. Janek: announced coming, but I don't know when. I will come Thursday evening/Friday during the day, depending on bus. I will leave on Tuesday. I don't have a tent ;) so i'd like to ask for a bed (will bring my sleeping bag). Jan Rosseel from the Scora project (check it out) can attend from Sunday morning to Monday afternoon (halfway). It will be great to meet him! As for the talk subjects: i'd like to discuss some big picture design goals. I have some notes on that subject and will try to bring them to order and send them to you. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond meeting in Waltrop, Germany, 2013-08-16 to 2013-08-20
2013/8/12 David Kastrup d...@gnu.org: Thomas Morley/Harm: still on vacation (so no early feedback), will bring his own tent, will come, but I don't know when. Hi David, back from vacation, I'm still reading all these new threads ... I'll arrive Thursday, leave Tuesday, sleeping in my tent. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: dashes on identifier
2013/8/7 David Kastrup d...@gnu.org Pedro Kroger kroegerlis...@pedrokroeger.net writes: I know an identifier can't have numbers, underscores, or dashes but I'd really appreciate if at least dashes were allowed. I'd love to be able to write identifiers like: \this-is-my-identifier Would that be possible? This reply is not entirely timely, but dashes in identifiers have been supported since LilyPond 2.15.43. Check out URL:http://code.google.com/p/lilypond/issues/detail?id=2702. Wow, this is cool! (somehow i missed that change...) thanks janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Symmetric slur input
Hi, 2013/8/7 David Kastrup d...@gnu.org Han-Wen Nienhuys hanw...@gmail.com writes: On Sun, Aug 4, 2013 at 9:18 AM, David Kastrup d...@gnu.org wrote: I don't think that distributing ( and ) between standalone event and post-event respectively is a concept that will carry the day sufficiently to be given a chance at a comeback. It would make (c (d) e) visually confusing. While neither the current c( d)( e) nor the standalone event version (c )(d )e will win a price for prettiness, they both beat (c (d) e) in conveying meaning rather than looking pleasing. What about considering ( as a post-event and ) as a standalone event ? c( )d( )e is symmetric and very clear. c()d()e is a pain in the ass, and we got rid of it in the 1.8-2.0 syntax change. It is a pain in the ass, because when copying music, you have to remember to put some adornments (ie. the ')' ) before the note, while most go after the note. Example? While I am apparently preparing the ground for historic reenactments, we'll want to convey some of the original horror, and I don't get it yet. Do i understand correctly that http://code.google.com/p/lilypond/issues/detail?id=3487 would change slur syntax from c( d)( e) to c()d()e ? I have to say that i don't like c()d()e. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: dashes on identifier
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/8/7 David Kastrup d...@gnu.org Pedro Kroger kroegerlis...@pedrokroeger.net writes: I know an identifier can't have numbers, underscores, or dashes but I'd really appreciate if at least dashes were allowed. I'd love to be able to write identifiers like: \this-is-my-identifier Would that be possible? This reply is not entirely timely, but dashes in identifiers have been supported since LilyPond 2.15.43. Check out URL:http://code.google.com/p/lilypond/issues/detail?id=2702. Wow, this is cool! (somehow i missed that change...) Actually, it was just harmonizing identifier syntax across modes (there always were things like \with-dimensions and similar in markups and ragged-right = ##t in context mods) since otherwise mode switching can lead to surprises when the lookahead token has been scanned with the wrong syntax. It was also more of a joke since the message I had been replying to was about 10 years old. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Symmetric slur input
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/8/7 David Kastrup d...@gnu.org Han-Wen Nienhuys hanw...@gmail.com writes: On Sun, Aug 4, 2013 at 9:18 AM, David Kastrup d...@gnu.org wrote: I don't think that distributing ( and ) between standalone event and post-event respectively is a concept that will carry the day sufficiently to be given a chance at a comeback. It would make (c (d) e) visually confusing. While neither the current c( d)( e) nor the standalone event version (c )(d )e will win a price for prettiness, they both beat (c (d) e) in conveying meaning rather than looking pleasing. What about considering ( as a post-event and ) as a standalone event ? c( )d( )e is symmetric and very clear. c()d()e is a pain in the ass, and we got rid of it in the 1.8-2.0 syntax change. It is a pain in the ass, because when copying music, you have to remember to put some adornments (ie. the ')' ) before the note, while most go after the note. Example? While I am apparently preparing the ground for historic reenactments, we'll want to convey some of the original horror, and I don't get it yet. Do i understand correctly that http://code.google.com/p/lilypond/issues/detail?id=3487 would change slur syntax from c( d)( e) to c()d()e ? I have to say that i don't like c()d()e. No, you don't understand correctly. It just makes possible redefining things like ( and ) so that you _could_ write a document in that style if you wanted to. I think it should be obvious from the issue description and review. I actually changed the regression test to something less scary, namely redefining ( and ) as \melisma and \melismaEnd (not possible previously because they behave like articulations to the user but aren't to LilyPond). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: dashes on identifier
2013/8/12 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: 2013/8/7 David Kastrup d...@gnu.org This reply is not entirely timely, but dashes in identifiers have been supported since LilyPond 2.15.43. Check out URL:http://code.google.com/p/lilypond/issues/detail?id=2702. Wow, this is cool! (somehow i missed that change...) Actually, it was just harmonizing identifier syntax across modes (there always were things like \with-dimensions and similar in markups and ragged-right = ##t in context mods) since otherwise mode switching can lead to surprises when the lookahead token has been scanned with the wrong syntax. Yes, i saw that and i appreciate your work on bringing consistency to us! It was also more of a joke since the message I had been replying to was about 10 years old. Wow! This explains why i didn't find that email in my mailbox... I thought that the original message was just a year or two old :) Jaenk ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Finale: why is this not automatic?
FYI, We're not amazing with dynamics alignment, but apparently we're not the only one https://twitter.com/jonsenge/status/367018161549234176 Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
This disturbed me to, though, not to a point that I started to work on it my own. ;) One thought: https://codereview.appspot.com/12732043/diff/1/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/12732043/diff/1/ly/music-functions-init.ly#newcode346 ly/music-functions-init.ly:346: #(define-void-function (parser location markup) (markup?) I'd use define-scheme-function and return the markup in the end. https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
what does LedgerLineSpanner.thickness do?
Ledger line thickness is set with the 'ledger-line-thickness property of the StaffSymbol grob. So then why does the LedgerLineSpanner grob have a 'thickness property? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
