Re: templates and a little bit more
Am 06.04.2012 um 13:17 schrieb Janek Warchoł: On Thu, Apr 5, 2012 at 7:37 PM, Jan-Peter Voigt jp.vo...@gmx.de wrote: Dear community, I bundled some extensions in a little package to try out. Some of these ideas might be interesting to include in lily. Here is a start of some docs, but just a little bit. I am working on it ... http://www.xn--schne-noten-tfb.de/?tabs=3,1 I'm sorry that i don't have time to dig deeper, Thats OK - I hope that you will be successful with your GSoC project! And that your exams don't suffer too much ;-) but my first impression is that it's somewhat similar to OrchestralLily: http://lac.linuxaudio.org/2010/papers/25.pdf http://reinhold.kainhofer.com/orchestrallily/A-simple-example.html#A-simple-example - it may give you some inspiration. Yes I know orchestralily. Generally speaking, i'd very much linke to simplify writing LilyPond scores. Have you read my article LilyPond's future? (http://news.lilynet.net/?The-LilyPond-Report-25lang=en#lilypond_s_future) What do you think about it? I read it and I like it. It is a reason to send my stuff to the list, because I think, my ideas might be helpful in this matter. I will explain it a little bit more the next days. Cheers, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
verbosity of `make doc'
Folks, I really appreciate that `make doc' doesn't flood the console. However, right now I see a long line calling lilypond-book.py which sits there for already more than 15 minutes without any progress indicator at all. This is perhaps too extreme and suitable only to the supercomputers some of us apparently have at home :-) Wouldn't it be possible, similar to automake, that the name of the currently processed file gets written to stdout, and that this behaviour is the default? In case the names are meaningless, a simple 1/1023 2/1023 3/1023 ... would also suffice as a progress indicator. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verbosity of `make doc'
On Sat, Apr 07, 2012 at 08:56:15AM +0200, Werner LEMBERG wrote: Wouldn't it be possible, similar to automake, that the name of the currently processed file gets written to stdout, and that this behaviour is the default? In case the names are meaningless, a simple No, because what's taking so long is the lilypond-book --tons-of-flags all_regtests_at_once.tely command. (same for NR chapters) We're saving stdout and sterr to log files so we can keep the output. Any additional info that lilypond-book prints would just be saved to a file instead of screen. Potentially we could print the name of the log file, so that you could tail out-www/Documentation/notation/spacing.log to view the progress...? but I'm not certain this can be done cleanly in our build system. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verbosity of `make doc'
We're saving stdout and sterr to log files so we can keep the output. Any additional info that lilypond-book prints would just be saved to a file instead of screen. There are more streams available than stderr and stdout, so it would be actually possible to save stderr and stdout from lilypond-book's subprocesses to files, together with other useful information, while printing something different to the console. However, since I can't implement this by myself, I'll shut up now :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verbosity of `make doc'
- Original Message - From: Werner LEMBERG w...@gnu.org To: lilypond-devel@gnu.org Sent: Saturday, April 07, 2012 7:56 AM Subject: verbosity of `make doc' Folks, I really appreciate that `make doc' doesn't flood the console. However, right now I see a long line calling lilypond-book.py which sits there for already more than 15 minutes without any progress indicator at all. This is perhaps too extreme and suitable only to the supercomputers some of us apparently have at home :-) Wouldn't it be possible, similar to automake, that the name of the currently processed file gets written to stdout, and that this behaviour is the default? In case the names are meaningless, a simple 1/1023 2/1023 3/1023 ... would also suffice as a progress indicator. Werner I tend to use the CPU meter as a progress indicator. If it's 100%, make doc is progressing... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no critical issues!
On Fri, Apr 6, 2012 at 6:11 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Apr 06, 2012 at 06:04:39PM +0200, m...@apollinemike.com wrote: Release candidate anyone? Or have we already had a version bump? I can build it, Graham, if you're over hours. It's already building. Sorry, guys, bad news: http://code.google.com/p/lilypond/issues/detail?id=2468 http://code.google.com/p/lilypond/issues/detail?id=2469 :/ Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 06.04.2012 23:04, schrieb Carl Sorensen: On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. Well, that's what I did, more or less. I saw a do-loop in Nicolas' code, and I am pretty sure he knows *a lot more* scheme than I do, and at least I am glad that the code works (well, most of it). It surely can be improved ... set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Sounds good - thanks for your kind words! Regards, Marc Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 07.04.2012 01:03, schrieb Thomas Morley: Am 6. April 2012 23:04 schrieb Carl Sorensenc_soren...@byu.edu: On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Thanks, Carl I'm working on a very similiar stuff. But I didn' try to rewrite lily/bar-line.cc etc. I tried another approach, defining only drawing-functions for glyphs of string-length = 1 Putting them together with a recursive function. Please note: This is work in progress. You may recognize many fragments of your and Nicolas' work. Thanks to you both. Currently there are a lot of inconsequences and small issues. And I didn't work on the line-break and the span-bar so far. That's on my todo-list. :) Nevertheless, I'm able to print very curious custom-barlines. Perhaps you may get some ideas for your own work. Hey, looks good! The idea of building the bar lines by parsing the string argument is very clever! How shall we proceed? I am short of time now (I have to move with my familiy into another house by the end of april, perhaps even one or two weeks earlier), but ... do you think we can work together on this issue? Perhaps we both could bring the stuff in a shape suitable for being included in lilys code base. Regards, Marc -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.15.36 regtests
Clean. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
