Re: Segfault 2.15.23 Span_bar_stub_engraver
Keith OHara k-ohara5...@oco.net writes: Jay Anderson horndude77 at gmail.com writes: On Mon, Jan 2, 2012 at 6:41 PM, Keith OHara k-ohara5a5a at oco.net wrote: I can't produce the segfault, either. Strange I can consistently reproduce it (just pulled the latest and recompiled): Ubuntu 11.10, gcc 4.6.1. If you have *only* seen it in compiles with gcc 4.6.1 it might be the compiler bug (yes, really a gcc bug) that David found. http://code.google.com/p/lilypond/issues/detail?id=1997 He patched the new makefiles to avoid the bug by turning off some option to gcc, based on a test that happens if you re-run ./configure If he hadn't rerun configure since before version 2.15.21, I think that the compilation would likely have failed for other reasons. The problem report is for 2.15.23. It may be worth for him to report the CXXFLAGS setting in config.status just to be on the safe side, but I consider it unlikely that this particular problem has not already been covered. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault 2.15.23 Span_bar_stub_engraver
On Jan 3, 2012, at 9:02 AM, David Kastrup wrote: Keith OHara k-ohara5...@oco.net writes: Jay Anderson horndude77 at gmail.com writes: On Mon, Jan 2, 2012 at 6:41 PM, Keith OHara k-ohara5a5a at oco.net wrote: I can't produce the segfault, either. Strange I can consistently reproduce it (just pulled the latest and recompiled): Ubuntu 11.10, gcc 4.6.1. If you have *only* seen it in compiles with gcc 4.6.1 it might be the compiler bug (yes, really a gcc bug) that David found. http://code.google.com/p/lilypond/issues/detail?id=1997 He patched the new makefiles to avoid the bug by turning off some option to gcc, based on a test that happens if you re-run ./configure If he hadn't rerun configure since before version 2.15.21, I think that the compilation would likely have failed for other reasons. The problem report is for 2.15.23. It may be worth for him to report the CXXFLAGS setting in config.status just to be on the safe side, but I consider it unlikely that this particular problem has not already been covered. Jay, Are you using an optimized binary? Mine is unoptimized. Please try ./autogen.sh --disable-optimizing before compiling and let me know if that makes the segfault go away. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes ugly side bars from learning (issue 5498089)
- Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; perciv...@gmail.com; pkx1...@gmail.com; tdanielsmu...@googlemail.com; m...@philholmes.net; em...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Monday, January 02, 2012 9:23 PM Subject: Re: Removes ugly side bars from learning (issue 5498089) could we get those @* turned into @example ? Just grit your teeth and ignore the yellow boxes for now? If you want to add a comment to remind us to change the @example when we have a better way of doing this, go ahead. http://codereview.appspot.com/5498089/ That's what I've done on my local-not-uploaded-for-review copy. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
my apologies, Simon
On Tue, Jan 03, 2012 at 11:35:16AM +0100, Simon Percivall wrote: Please stop including me in these mails. My apologies. Somebody must have gotten our names confused, and added you instead of me. To lilypond developers: please make sure that you do not include Simon Percivall on any more emails. Check the CC headers of your email client. - Graham Percival ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch of not remaking html files (issue 5498093)
- Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; perciv...@gmail.com Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Monday, January 02, 2012 9:41 PM Subject: Re: Sketch of not remaking html files (issue 5498093) a few minor quibbles; I'm on a ferry right now so I can't test a full doc build. http://codereview.appspot.com/5498093/diff/1/GNUmakefile.in File GNUmakefile.in (right): http://codereview.appspot.com/5498093/diff/1/GNUmakefile.in#newcode125 GNUmakefile.in:125: # find $(outdir) -name '*-root' | xargs rm -rf please either delete the line entirely, or add a comment explaining why you've commented-out that line. Otherwise I fear that this may become another time bomb that may confuse future people working on the build process. I commented it out for my initial trial - easier to put it back if there's a problem. Looks like deleting the line is the best option. http://codereview.appspot.com/5498093/diff/1/python/auxiliar/postprocess_html.py File python/auxiliar/postprocess_html.py (right): http://codereview.appspot.com/5498093/diff/1/python/auxiliar/postprocess_html.py#newcode353 python/auxiliar/postprocess_html.py:353: SourceTime = os.path.getmtime(file_name) there's an extremely strong convention in python programming to use lower-case and underscores, i.e. source_time = os.path.getmtime(file_name) No problems. I'm just a Camel caser. http://codereview.appspot.com/5498093/diff/1/scripts/build/www_post.py File scripts/build/www_post.py (right): http://codereview.appspot.com/5498093/diff/1/scripts/build/www_post.py#newcode76 scripts/build/www_post.py:76: sys.exc_clear() why do you want to catch this exception? Surely if mkdir fails, we want to display the error message on the command-line? maybe do something like if not os.path.isdir(out_root): os.mkdir (out_root) instead? (I mean, what if the exception that was raised was you have no disk space left on this drive, or something more serious than that directory already exists ? -- and yes, I've occasionally tried to build lilypond on a drive that wasn't big enough, so this isn't just a theoretical concern!) I spent a while researching online as to how to create a directory if it didn't already exist, and consensus was that catching the exception was the best option. There's some sort of issues with race conditions over checking whether it exist before creating it - although thinking about this, it's possible that this would only occur if more than one process was trying to create it at the same time, but anyway Probably the very best way is to catch the specific exception of directory exists and throw any others. Having said that, it's almost certainly theoretical. If mkdir fails because of a disk problem, something else will blow pretty soon. http://codereview.appspot.com/5498093/ I'll have a think and put up a new patch. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch of not remaking html files (issue 5498093)
- Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; perciv...@gmail.com Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org Sent: Monday, January 02, 2012 9:41 PM Subject: Re: Sketch of not remaking html files (issue 5498093) a few minor quibbles; I'm on a ferry right now so I can't test a full doc build. The float plane's more fun. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Tuesday, January 03, 2012 7:55 AM Subject: Re: critical issues Graham Percival gra...@percival-music.ca writes: On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: We could certainly consider dropping support for OSX or windows. That sort of token solidarity is actually counterproductive: if you believe that non-releases lead to non-users, yes and you think that non-releases for GNU/Linux may pressure GNU/Linux developers into making OSX/Windows releases, no then how does a non-release for GNU/Linux, with its corresponding result in decreasing GNU/Linux users and GNU/Linux developers, help in recruiting GNU/Linux developers that can be pressured into making OSX and Windows releases? it doesn't? Exactly. Suppose we announce a big new shiny lilypond 2.16. For linux and freebsd only. OSX and windows users can go screw themselves. We are not announcing a big new shiny Lilypond 2.16. We are announcing big new shiny 2.15.xx developer releases one after another. For GNU/Linux and FreeBSD only. N. I'm happily running pretty much every 2.15 version on my Windows box. It runs fine and it's my normal music-producing environment, and also the one on which I test for bugs and get examples to add to the tracker. AFAIK the only problem is with lilypond-book, which I personally don't run on my windows machine. OSX and Windows users _are_ second class (or handicapped) citizens for LilyPond because the whole technology is based on GNU, and since the developer skills needed to work with it strongly correlate with UNIX-like systems. The whole point of GUB is that it is a _cross_ building ennvironment that can be maintained by GNU/Linux developers for the sake of OSX and Windows users. The skill level for actively keeping GUB working (rather than plug and pray) is considerable, and requires good GNU/Linux (or at least UNIX) skills and at least contact skills with OSX and Windows. Without a healthy surplus of GNU/Linux-based developers that are not already locked down with keeping up their own projects, our OSX and Windows users can indeed, as you so flowery put it, can go screw themselves because they can't hope to screw with LilyPond, rather pure UNIX-based technology requiring UNIX-centric skill sets and mind frames. There is a _reason_ the remaining OSX and Windows based developers are doing (definitely important) documentation and web site work. They are to a large degree locked out and dependent on support from surplus GNU/Linux-based developer capacities. We are not doing them any favors by killing LilyPond development as a whole out of sympathy with their plight. Not at all. I think you know that myself and James are mainly Windows users. We also run big Ubuntu machines that support the build environment. However, we came to the development from being Windows users. Cut off that supply and I'll probably stop supporting Lily, which I would regret. - what does this do to our ONLY documentation writers and reviewers (who are all windows-based)? Will they be a) more motivated to work on lilypond, b) no change, or c) less motivated? We are already screwing them over with GNU/Linux-only developer releases. When will we stop using our Windows and OSX developers as an excuse for not working on a stable release that would actually warrant the effort of getting GUB working again and matched to current Windows and OSX releases? Not true - see above. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Phil Holmes m...@philholmes.net writes: From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org There is a _reason_ the remaining OSX and Windows based developers are doing (definitely important) documentation and web site work. They are to a large degree locked out and dependent on support from surplus GNU/Linux-based developer capacities. We are not doing them any favors by killing LilyPond development as a whole out of sympathy with their plight. Not at all. I think you know that myself and James are mainly Windows users. We also run big Ubuntu machines that support the build environment. However, we came to the development from being Windows users. Cut off that supply and I'll probably stop supporting Lily, which I would regret. You are compiling your own binaries without using GNU/Linux in the process? That's what a native development environment would look like. - what does this do to our ONLY documentation writers and reviewers (who are all windows-based)? Will they be a) more motivated to work on lilypond, b) no change, or c) less motivated? We are already screwing them over with GNU/Linux-only developer releases. When will we stop using our Windows and OSX developers as an excuse for not working on a stable release that would actually warrant the effort of getting GUB working again and matched to current Windows and OSX releases? Not true - see above. Documentation and web writing without a functional lilypond-book strikes me as somewhat difficult. It is nice that things are not as completely broken as I thought. But I still think that our effectively current philosophy of the next stable release is something only developers interested in Windows and OSX need to concern themselves with is doing anybody a favor. Our road map has nothing to offer beyond GUB, and so there is little interest in getting even there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Tuesday, January 03, 2012 11:44 AM Subject: Re: critical issues Phil Holmes m...@philholmes.net writes: From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org There is a _reason_ the remaining OSX and Windows based developers are doing (definitely important) documentation and web site work. They are to a large degree locked out and dependent on support from surplus GNU/Linux-based developer capacities. We are not doing them any favors by killing LilyPond development as a whole out of sympathy with their plight. Not at all. I think you know that myself and James are mainly Windows users. We also run big Ubuntu machines that support the build environment. However, we came to the development from being Windows users. Cut off that supply and I'll probably stop supporting Lily, which I would regret. You are compiling your own binaries without using GNU/Linux in the process? That's what a native development environment would look like. No. I have an Ubuntu VM which I use for quick experiments and a very fast Ubuntu PC which I use for full builds. But I support lilypond because I _use_ it for typesetting music on a _Windows_ machine. Take away that ability to use it, and the sesire to support goes away. - what does this do to our ONLY documentation writers and reviewers (who are all windows-based)? Will they be a) more motivated to work on lilypond, b) no change, or c) less motivated? We are already screwing them over with GNU/Linux-only developer releases. When will we stop using our Windows and OSX developers as an excuse for not working on a stable release that would actually warrant the effort of getting GUB working again and matched to current Windows and OSX releases? Not true - see above. Documentation and web writing without a functional lilypond-book strikes me as somewhat difficult. I don't use lilypond-book for day-day activity - only lilypond development. It is nice that things are not as completely broken as I thought. But I still think that our effectively current philosophy of the next stable release is something only developers interested in Windows and OSX need to concern themselves with is doing anybody a favor. Our road map has nothing to offer beyond GUB, and so there is little interest in getting even there. I think you've mis-stated the philosophy. It's the next stable release is something that will benefit users of many operating systems, including many flavours of Unix, plus windows and MAC. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Phil Holmes m...@philholmes.net writes: From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Tuesday, January 03, 2012 11:44 AM Subject: Re: critical issues Phil Holmes m...@philholmes.net writes: From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org There is a _reason_ the remaining OSX and Windows based developers are doing (definitely important) documentation and web site work. They are to a large degree locked out and dependent on support from surplus GNU/Linux-based developer capacities. We are not doing them any favors by killing LilyPond development as a whole out of sympathy with their plight. Not at all. I think you know that myself and James are mainly Windows users. We also run big Ubuntu machines that support the build environment. However, we came to the development from being Windows users. Cut off that supply and I'll probably stop supporting Lily, which I would regret. You are compiling your own binaries without using GNU/Linux in the process? That's what a native development environment would look like. No. I have an Ubuntu VM which I use for quick experiments and a very fast Ubuntu PC which I use for full builds. But I support lilypond because I _use_ it for typesetting music on a _Windows_ machine. Take away that ability to use it, and the sesire to support goes away. Yup, and our current effective strategy of not doing stable releases takes away that ability from anyone. Not just Windows users. It is nice that things are not as completely broken as I thought. But I still think that our effectively current philosophy of the next stable release is something only developers interested in Windows and OSX need to concern themselves with is doing anybody a favor. Our road map has nothing to offer beyond GUB, and so there is little interest in getting even there. I think you've mis-stated the philosophy. It's the next stable release is something that will benefit users of many operating systems, including many flavours of Unix, plus windows and MAC. That's the vision. The vision can't replace the road leading to it. The only roadmap we have is critical issues, and none of the critical issues are anything that could be tackled by anybody rather than developers with quite special skills and interests. If all of the critical issues go away over night for some reason, we still have nothing that can in good conscience be sold as stable release. And by the time we get there, GUB will probably have acquired enough fresh bit rot that we will be in the same situation as we are now. If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net No. I have an Ubuntu VM which I use for quick experiments and a very fast Ubuntu PC which I use for full builds. But I support lilypond because I _use_ it for typesetting music on a _Windows_ machine. Take away that ability to use it, and the desire to support goes away. Yup, and our current effective strategy of not doing stable releases takes away that ability from anyone. Not just Windows users. Personally, I'm quite happy using a development version for my music typesetting. If the most recent one causes a problem, I revert to the previous version. -- David Kastrup -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Jan 3, 2012, at 1:36 PM, Werner LEMBERG wrote: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. One in-the-middle approach is to check out package managers that are offering LilyPond releases. I know, for example, that brew offers a version of LilyPond on Mac OS X. If we provide a list of package managers and how-tos for the techno-phobic, that may be enough to maintain (and even grow) the user base. It has the added benefit of pointing people to better resources than those we could maintain in-house: I think that jEdit plus the brew version of LilyPond, for example, is a more compelling package than the GUI we distribute. Does Windows have its share of package managers that offer this sorta thing? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. From a support perspective, not releasing the windows and mac versions at the same time is problematic. Many questions and bugreports that could be answered with upgrade to the latest version all of a sudden start depending on the platform that the user is using. Also, it makes it more difficult to get users to pay for work, since users won't pay if you don't release the work to their platform I fully sympathize with the desire to junk Mac and Windows for being a pains in the asses to develop for, but they are the platforms where the majority of the users are. We (Jan and I) made a conscious decision that having more users is better for lilypond than saving some developer resources over not distributing windows/mac binaries. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases I don't see how this reasoning works. You do stable releases for users, not developers. -- 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: GUB Build Success!
On 12-01-02 09:15 PM, Carl Sorensen wrote: Graham Percivalgrahamat percival-music.ca writes: On Sun, Jan 01, 2012 at 08:43:05PM +, Carl Sorensen wrote: I have made one change to the spec files (the location of netpm on lilypond.org has changed), and I did a couple of manual downloads, so I'm not sure yet that GUB is ready to build out-of-the-box. But I have demonstrated that I can get all the way through it. Eh? I regularly build GUB out-of-the-box on lilydev [*]. What exactly do you think you need to do? Well, I tried building GUB on 11.04, unsuccessfully (I have a file that kept a record of everything I did, if anybody is interested). Then I tried on lilydev in a virtual machine, and was also unsuccessful. I didn't keep a good record of what happened at that time. So then I tried with a fresh copy of Ubuntu 10.04 LTS. I was able to work everything out and get it to build. I will probably try to summarize the efforts in the miscellaneous part of the CG. In particular, what's this netpbm thing? The source for netpbm on lilypon.org is http://lilypond.org/download/gub-sources/netpbm-patched/ netpbm-patched-10.35.tar.bz2. The source entry in gub/gub/specs/netpbm.py is http://lilypond.org/download/gub-sources/netpbm-patched-10.35.tar.bz2 When the download doesn't succeed, no error is thrown. So as long as you have the file when it comes time to extract it, you can go ahead. But if the file isn't there, you end up with an error. I've made a patch that fixes it and will send it to you. It would be very useful if the build process *did* barf when, and as soon as, a download fails. It's painful to wait several hours into make lilypond, only to get a delayed error from a missing file. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Werner LEMBERG w...@gnu.org writes: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. The problem is not that bugs specific to Windows and Mac would be preventing stable releases. The problem is that we have a _number_ of problems preventing a stable release, and we are not addressing them because Mac and Windows provide a convenient excuse. The Learning Guide and the Notation Guide need a complete rereading and reorganization, and it is not like the Extending Guide is in significantly better shape. There are only few languages for which the translations can be considered maintained. Stuff like that picks up considerably after stable releases since the motivation to help with documenting something that will take years before the helper gets to see it (and fresh blood tends to get started on stable releases) is limited. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. If you take a look at Ubuntu release candidates, they usually start with a list of caveats concerning computers and applications that won't run at all. You need to _start_ with the work for cutting out a release before it is magically finished. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Hello, On 3 January 2012 12:53, Han-Wen Nienhuys hanw...@gmail.com wrote: On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. From a support perspective, not releasing the windows and mac versions at the same time is problematic. Many questions and bugreports that could be answered with upgrade to the latest version all of a sudden start depending on the platform that the user is using. Yes, Han-Wen beat me to that point. So if 2.14 works on OSX but 2.16 doesn't then the user has no choice but to stick with 2.14 or use a 2.15 branch both which are no no longer being developed. That is a pain to troubleshoot There is some wonderful work gone into 2.15 that isn't (and never will be in 2.14) that the user-base will miss out on. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases I don't see how this reasoning works. You do stable releases for users, not developers. Beautifully put. As a side note, I came to LP via MacOS X + Lilypad, and ran with windows only because it is my OS at work. Now I use Linux for all my LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is not a problem for me and having LilyDev in a VM even if it is in a Linux OS itself - allows me to use VBox's snapshot for testing or reverting when I run into git issues or build issues), in fact my Windows LP work is virtually nil now, unless a user or dev asks for some second verification. My question to David, because I am not getting where the 'ire' is coming from, why do you care if we release dev after dev release vs stable? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
m...@apollinemike.com m...@apollinemike.com writes: One in-the-middle approach is to check out package managers that are offering LilyPond releases. I know, for example, that brew offers a version of LilyPond on Mac OS X. If we provide a list of package managers and how-tos for the techno-phobic, that may be enough to maintain (and even grow) the user base. It has the added benefit of pointing people to better resources than those we could maintain in-house: I think that jEdit plus the brew version of LilyPond, for example, is a more compelling package than the GUI we distribute. It sounds to me like Frescobaldi might be a nice base for a good total package for systems with GUI-centric use patterns. I have looked at neither LilyPondTool nor Frescobaldi myself (GUIs are totally not my thing), but maintaining a compelling GUI/editing package requires a constant and focused effort, and I have the vague impression that Frescobaldi is maintained with more of a core vengeance rather than an addon spirit. Emacs could be a nice package as well since its info reader beats every other Lilypond information system hollow (unless you get precompiled info files without included images in which case it is mostly pointless), but its support of ly and lytex (and, to a degree, itexi) is not as strong as to put it solidly ahead of the glorified duct tape class. Tying lytex, ly, and itexi into the AUCTeX machinery would make a very impressive offering, but that would entail quite a bit of work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Han-Wen Nienhuys hanw...@gmail.com writes: On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. From a support perspective, not releasing the windows and mac versions at the same time is problematic. Many questions and bugreports that could be answered with upgrade to the latest version all of a sudden start depending on the platform that the user is using. Also, it makes it more difficult to get users to pay for work, since users won't pay if you don't release the work to their platform Which is exactly the situation that we find ourselves in already. I fully sympathize with the desire to junk Mac and Windows for being a pains in the asses to develop for, but they are the platforms where the majority of the users are. We (Jan and I) made a conscious decision that having more users is better for lilypond than saving some developer resources over not distributing windows/mac binaries. Sure, but we are not talking about junking Mac and Windows, but about junking using them as a cheap excuse for losing sight of stable release criteria altogether. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
James pkx1...@gmail.com writes: Hello, On 3 January 2012 12:53, Han-Wen Nienhuys hanw...@gmail.com wrote: On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote: If we refuse thinking about stable releases by taking GUB as an excuse, the grand next stable release that will benefit users of many operating systems is likely to fall in the class too little, too late. I second David. Given that we develop within a GNU environment, bugs specific to Windows and Mac shouldn't prevent stable releases. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. From a support perspective, not releasing the windows and mac versions at the same time is problematic. Many questions and bugreports that could be answered with upgrade to the latest version all of a sudden start depending on the platform that the user is using. Yes, Han-Wen beat me to that point. So if 2.14 works on OSX but 2.16 doesn't then the user has no choice but to stick with 2.14 or use a 2.15 branch both which are no no longer being developed. Newsflash: 2.16 does not work on OSX. Nor does it work on any other platform. The user has no choice but to stick with 2.14 or use a 2.15 branch which does not apparently work on OSX. That is a pain to troubleshoot There is some wonderful work gone into 2.15 that isn't (and never will be in 2.14) that the user-base will miss out on. Newsflash: it is already missing out. As a side note, I came to LP via MacOS X + Lilypad, and ran with windows only because it is my OS at work. Now I use Linux for all my LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is not a problem for me and having LilyDev in a VM even if it is in a Linux OS itself - allows me to use VBox's snapshot for testing or reverting when I run into git issues or build issues), in fact my Windows LP work is virtually nil now, unless a user or dev asks for some second verification. This does not exactly make a strong point about the ability of Windows to attract development. My question to David, because I am not getting where the 'ire' is coming from, why do you care if we release dev after dev release vs stable? URL:http://xkcd.com/386/ If we look beyond that personality trait, I have a financial interest in LilyPond becoming a package attractive to people with more money than programming skills. A stable release for which the stability and usability aim is more than just mostly works on OSX and Windows would be helpful to point to. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
2012/1/3 Graham Percival gra...@percival-music.ca: It so happens that none of these Critical issues are really fixable by reverting a single commit. [...] ok, thanks for this explanation! Is finding them an easy (no knowledge needed, a complete set of dumbed-down instructions can be given) task that can be done using a moderately fast computer running lilydev (1,5 GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if multicore thingy translates to virtual machine)? when the problem *is* in the lilypond code base, yes it's brain-dead easy to identify the problematic commit. Instructions are already in the CG -- look in the regressions chapter. Silly me, i forgot about that. 2012/1/3 David Kastrup d...@gnu.org: The Learning Guide and the Notation Guide need a complete rereading and reorganization, and it is not like the Extending Guide is in significantly better shape. I'd like to fix them too, but i don't have time for everything i want :( Splitting my time doesn't look like a good idea - it's more effective when i put all my foxus on one thing, analyze it deeply and make a complete solution than swap issues. I have to choose and i choose improving graphical output. I can even imagine that well announced release candidates for a new stable version attracts developers to help fix issues with problematic platforms. If you take a look at Ubuntu release candidates, they usually start with a list of caveats concerning computers and applications that won't run at all. You need to _start_ with the work for cutting out a release before it is magically finished. Indeed this looks like a good point. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 David Kastrup d...@gnu.org: The Learning Guide and the Notation Guide need a complete rereading and reorganization, and it is not like the Extending Guide is in significantly better shape. I'd like to fix them too, but i don't have time for everything i want :( Splitting my time doesn't look like a good idea - it's more effective when i put all my foxus on one thing, analyze it deeply and make a complete solution than swap issues. I have to choose and i choose improving graphical output. I am a TeX specialist, system programmer, Emacs specialist, the GNU maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi anybody? preview-latex for Lilypond?), know how to make Emacs read data from Midi ports, am pretty good concerning compiler writing, shell scripting, general programming, efficient algorithms, am the resident quiz person for git and so on and so on. I would have no problems spending a few hundred man years focused on Lilypond. Except that I don't have a few hundred man years. Nobody has. The next best option is spending time on multipliers. Getting LilyPond in a shape where passersby find it intriguing, to a degree where they get hooked and contribute manmonths of work over some time without having planned to do so at the start. LilyPond has great infrastructure: it makes by far the most from Texinfo from any application I know, with much better HTML than upstream, far more thorough and good use of images (only useful in HTML or with Emacs as info reader, I am afraid). I have no clue why or how GUB works, but many others don't have something like that. It has good facilities for internationalization. There are other novel pieces that turn out to be more of a maintenance problem than an asset because of a total lack of documentation and/or mindshare: yaffut, the organization of the C++ core, many internals, stepmake, ... Many corners are lying dormant since their respective driving force went away or lost interest or time. I don't manage to keep up with code reviews and am pretty sure that there are maintenance time bombs creeping in all the while. The only thing that is going to help is more eyes, more people who get interested, more people discovering dark corners and doing something about them. LilyPond needs to get into a state where, say, half the engravers are written and maintained in Scheme. And by Scheme I don't mean Scheme at the level Nicolas can barely handle but Scheme a Fortran programmer would not have all too much of a problem understanding. To get there, we need serious programmers and serious musicians interested seriously in LilyPond. To a level where they start asking good questions. And we better be in a position to provide answers, since there is no more effective way to spend our time than on getting more people to spend their time, and love, and interest. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copy pdf docs to new website folder (issue 5507046)
Reviewers: Graham Percival,
Message:
On 2012/01/01 23:14:05, Graham Percival wrote:
LGTM, but I had to add issue 2166 to track this.
Sorry, didn't understand what you mean by add issue 2166 to track this
Anything I can do to help this to get live?
Description:
Patch related to http://codereview.appspot.com/5500069/.
There is a git pull request on github to put pdf files in
lilypond-extra.
These patches copy the files to the correct place, and rewrite links.
I did some changes on the contribution documentation page as well, given
that is misses some details. Also not that the wbesite page is not
up-to-date to the latest git repository version.
Please review this at http://codereview.appspot.com/5507046/
Affected files:
M Documentation/contributor/programming-work.itexi
M Documentation/contributor/website-work.itexi
M Documentation/cs/web/introduction.itexi
M Documentation/de/web/introduction.itexi
M Documentation/es/web/introduction.itexi
M Documentation/fr/web/community.itexi
M Documentation/fr/web/introduction.itexi
M Documentation/hu/web/community.itexi
M Documentation/it/web/introduction.itexi
M Documentation/ja/web/introduction.itexi
M Documentation/nl/web/introduction.itexi
M Documentation/web/introduction.itexi
M Documentation/web/we-wrote.bib
M make/website.make
Index: Documentation/contributor/programming-work.itexi
diff --git a/Documentation/contributor/programming-work.itexi
b/Documentation/contributor/programming-work.itexi
index
e6aa1f0d9961e9522715159e94ff8066c808088c..1ff0247a731a2fd725ae08507a12fca73fa9a3cd
100644
--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -29,7 +29,7 @@ number of stages. This process, along with the types of
routines that
accomplish the various stages of the process, is described in this
section. A
more complete description of the LilyPond architecture and internal program
execution is found in Erik Sandberg's
-@uref{http://lilypond.org/web/images/thesis-erik-sandberg.pdf, master's
+@uref{http://lilypond.org/website/pdf/thesis-erik-sandberg.pdf, master's
thesis}.
The first stage of LilyPond processing is @emph{parsing}. In the parsing
Index: Documentation/contributor/website-work.itexi
diff --git a/Documentation/contributor/website-work.itexi
b/Documentation/contributor/website-work.itexi
index
49bf3db6f5a6f1f9196cd9ffd723c8aa37da264e..aaced80cff446d2845649a332f49209d3d8c9839
100644
--- a/Documentation/contributor/website-work.itexi
+++ b/Documentation/contributor/website-work.itexi
@@ -65,9 +65,9 @@ Initial setup:
Create directories:
@example
-$HOME/lilypond/
-$HOME/lilypond/media/
-$HOME/lilypond/trusted-scripts/
+mkdir $HOME/lilypond/
+mkdir $HOME/lilypond/media/
+mkdir $HOME/lilypond/trusted-scripts/
@end example
To reduce the CPU burden on the shared host (as well as some
@@ -114,6 +114,17 @@ cp $GIT/Documentation/web/server/lilypond.org.htaccess
$DEST/lilypond.org.htacce
cp $GIT/Documentation/web/server/website-dir.htaccess
$DEST/website-dir.htaccess
@end smallexample
+For a complete build you will need a copy of @code{lilypond-extra} git
repository.
+You can checkout a fresh copy easily:
+
+@example
+export LILYPOND_WEB_MEDIA_GIT=$HOME/lilypond-extra
+git clone git://github.com/gperciva/lilypond-extra.git
$LILYPOND_WEB_MEDIA_GIT
+@end example
+
+Just note that the example above expects a bash environment. If you are
using another shell
+you might need to use a different keyword, other than @code{export}.
+
Delete your build directory (or maybe just rename your build
directory to build-old).
Index: Documentation/cs/web/introduction.itexi
diff --git a/Documentation/cs/web/introduction.itexi
b/Documentation/cs/web/introduction.itexi
index
e1290089a155e42b6f589ddb796b9298e9064d5d..b1096adb499c05700a092105120448fae7c1bbeb
100644
--- a/Documentation/cs/web/introduction.itexi
+++ b/Documentation/cs/web/introduction.itexi
@@ -687,7 +687,7 @@ Francouzský článek o LilyPondu ve verzi 2.6 se objevuje
na
Vydavatelé holandského časopisu Computer!Totaal,
který se věnuje počítačům,
-@uref{http://lilypond.org/web/images/computer-totaal.jpeg,
+@uref{http://lilypond.org/website/pdf/computer-totaal.jpeg,
popisují LilyPond} ve vydání z října 2004 jako: @qq{báječný
svobodný (Open Source) program [...] Noty vytvořené LilyPondem
jsou bez výjimky nádherné [...] Jde o velmi silný systém, který
Index: Documentation/de/web/introduction.itexi
diff --git a/Documentation/de/web/introduction.itexi
b/Documentation/de/web/introduction.itexi
index
ba8fc7497481dd82f077998a034549e4cf22a1e4..e9f52b22851c4428575d36c5f436d226fb4c52e4
100644
--- a/Documentation/de/web/introduction.itexi
+++ b/Documentation/de/web/introduction.itexi
@@ -722,7 +722,7 @@ Oktober 2004
Die Editoren von Computer!Totaal, einer holländischen
Computerzeitschrift,
-@uref{http://lilypond.org/web/images/computer-totaal.jpeg,
Re: GUB Build Success!
On Jan 3, 2012, at 2:20 PM, Colin Campbell wrote: On 12-01-02 09:15 PM, Carl Sorensen wrote: Graham Percivalgrahamat percival-music.ca writes: On Sun, Jan 01, 2012 at 08:43:05PM +, Carl Sorensen wrote: I have made one change to the spec files (the location of netpm on lilypond.org has changed), and I did a couple of manual downloads, so I'm not sure yet that GUB is ready to build out-of-the-box. But I have demonstrated that I can get all the way through it. Eh? I regularly build GUB out-of-the-box on lilydev [*]. What exactly do you think you need to do? Well, I tried building GUB on 11.04, unsuccessfully (I have a file that kept a record of everything I did, if anybody is interested). Then I tried on lilydev in a virtual machine, and was also unsuccessful. I didn't keep a good record of what happened at that time. So then I tried with a fresh copy of Ubuntu 10.04 LTS. I was able to work everything out and get it to build. I will probably try to summarize the efforts in the miscellaneous part of the CG. In particular, what's this netpbm thing? The source for netpbm on lilypon.org is http://lilypond.org/download/gub-sources/netpbm-patched/ netpbm-patched-10.35.tar.bz2. The source entry in gub/gub/specs/netpbm.py is http://lilypond.org/download/gub-sources/netpbm-patched-10.35.tar.bz2 When the download doesn't succeed, no error is thrown. So as long as you have the file when it comes time to extract it, you can go ahead. But if the file isn't there, you end up with an error. I've made a patch that fixes it and will send it to you. I decided to download GUB and I think I've compiled everything (it ran for several hours and did not complain). I have no clue how it works, though. Is there any documentation beside the README? The thing I understand least are the patches - are the patches in the patches file hand-written or auto-generated? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
problem with checking out staging branch
Hi, i have problems with staging branch. I understand what it's supposed to do and how branches work; the problem is purely technical. Firstly, I cannot diff it, unlike master branch: calling 'git diff origin/master' shows me a diff between the local branch i'm on and the master branch from remote origin, but calling 'git diff origin/staging' says fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions - ? I concluded that i have to add staging branch (tell git about its existence); i tried git remote add -ft staging -m staging origin git://git.sv.gnu.org/lilypond.git/ (in analogy to what is written in http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches about downloading master), but git protested fatal: remote origin already exists. i suppose this means that 'git remote' is used for whole locations (references), not branches. How can i add a branch, then? I've searched CG but found nothing. I finally tried 'git checkout staging' and surprisingly it worked, but git message was a bit alarming: Branch staging set up to track remote branch staging from testorigin. Switched to a new branch 'staging' what is testorigin? It is possible that it was something i accidentally set up 3 months ago, i don't remember; nevertheless this doesn't make much sense to me. Can you help? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Janek Warchoł janek.lilyp...@gmail.com writes: git remote add -ft staging -m staging origin git://git.sv.gnu.org/lilypond.git/ (in analogy to what is written in http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches about downloading master), but git protested fatal: remote origin already exists. i suppose this means that 'git remote' is used for whole locations (references), not branches. How can i add a branch, then? I've searched CG but found nothing. I finally tried 'git checkout staging' and surprisingly it worked, but git message was a bit alarming: Branch staging set up to track remote branch staging from testorigin. Switched to a new branch 'staging' what is testorigin? It is possible that it was something i accidentally set up 3 months ago, i don't remember; nevertheless this doesn't make much sense to me. Can you help? Personally, I've mostly given up with the git command line for config stuff. Just post the contents of .git/config and we'll go from there, seeing what you should do using a text editor. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 David Kastrup d...@gnu.org: Personally, I've mostly given up with the git command line for config stuff. Just post the contents of .git/config and we'll go from there, seeing what you should do using a text editor. [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [branch master] remote = origin merge = refs/heads/master rebase = true [gui] wmstate = normal geometry = 1386x631+0+51 216 192 [rietveld] server = codereview.appspot.com cc = lilypond-devel@gnu.org user = lemniskata.bernoullego [branch arp-arrow] rietveldissue = 4793041 rietveldpatchset = 1 [branch narrow-acc] rietveldissue = 4790043 rietveldpatchset = 1 [branch tremolo] rietveldissue = 4636081 rietveldpatchset = 49001 [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master [remote aspiers] url = git://github.com/aspiers/lilypond.git fetch = +refs/heads/*:refs/remotes/aspiers/* [branch new-tremolo] [remote testorigin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/*:refs/remotes/testorigin/* [branch staging] remote = testorigin merge = refs/heads/staging I guess i should change it into this: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [branch master] remote = origin merge = refs/heads/master rebase = true [gui] wmstate = normal geometry = 1386x631+0+51 216 192 [rietveld] server = codereview.appspot.com cc = lilypond-devel@gnu.org user = janek.lilypond [branch arp-arrow] rietveldissue = 4793041 rietveldpatchset = 1 [branch narrow-acc] rietveldissue = 4790043 rietveldpatchset = 1 [branch tremolo] rietveldissue = 4636081 rietveldpatchset = 49001 [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master [remote aspiers] url = git://github.com/aspiers/lilypond.git fetch = +refs/heads/*:refs/remotes/aspiers/* [branch new-tremolo] [branch staging] remote = origin merge = refs/heads/staging rebase = true Am i right? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: explanation of branches for the impatient (issue 5484043)
A few comments, but otherwise LGTM
http://codereview.appspot.com/5484043/diff/7001/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5484043/diff/7001/Documentation/contributor/source-code.itexi#newcode318
Documentation/contributor/source-code.itexi:318: @qq{profit}, I mean
@qq{push stuff to staging}.
i don't understand how switching branches has anything to do with
pushing to staging.
http://codereview.appspot.com/5484043/diff/7001/Documentation/contributor/source-code.itexi#newcode446
Documentation/contributor/source-code.itexi:446: git rebase dev/cg
On 2011/12/16 05:52:34, Keith wrote:
This makes the history of commits linear, but in the wrong order. (It
puts any
new commits from the repository /after/ the new commits from dev/cg --
and any
conflict resolution would change the commits from the repository.)
Git changes the branch that is checked-out, and we want to change the
sequence
of commits developers branch, so
git checkout dev/cg
git rebase staging
git checkout staging
gitk
+1, this makes much more sense
http://codereview.appspot.com/5484043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Janek Warchoł janek.lilyp...@gmail.com writes: I guess i should change it into this: [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master I'd put * instead of twice master here (easier than multiple fetch lines). [remote aspiers] url = git://github.com/aspiers/lilypond.git fetch = +refs/heads/*:refs/remotes/aspiers/* And it does not look like you need the remote aspiers. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: I guess i should change it into this: [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master I'd put * instead of twice master here (easier than multiple fetch lines). I don't get it. Anyway, its only a readability enhancement? [remote aspiers] url = git://github.com/aspiers/lilypond.git fetch = +refs/heads/*:refs/remotes/aspiers/* And it does not look like you need the remote aspiers. Indeed, his patches were pushed. Well, i changed config file, can check out branch staging, but still cannot diff it: fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions i don't understand what he says... Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copy pdf docs to new website folder (issue 5507046)
Hello, On 3 January 2012 18:31, hashas...@gmail.com wrote: Reviewers: Graham Percival, Message: On 2012/01/01 23:14:05, Graham Percival wrote: LGTM, but I had to add issue 2166 to track this. Sorry, didn't understand what you mean by add issue 2166 to track this http://code.google.com/p/lilypond/issues/detail?id=2166 We use Google tracker for any issue we have a patch for on Rietveld Normally you would use git-cl that comes with the LilyPond Code as per the Contributor's Guide to upload the patch and during the upload you'd be prompted for a tracker issue. http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review The tracker is required, among other things, so our automated scripts can test all 'new' google tracker patches to make sure they apply. Without a tracker issue code uploaded to Rietveld gets missed and so slows down the eventual pushing of this. Anything I can do to help this to get live? Well, the patch has been changed to 'countdown' see: http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#summary-for-experienced-developers under 'reviews'. Hope this helps. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: Well, i changed config file, can check out branch staging, but still cannot diff it: fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions i don't understand what he says... However, it looks that i can push to staging. Can you confirm that Benko Pal's fix for http://code.google.com/p/lilypond/issues/detail?id=2109 was pushed properly to staging? From what i see, it got ID 9f24e79a945ec4ab000d3e09ff2d2ac8208e2246. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Hello, 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: Well, i changed config file, can check out branch staging, but still cannot diff it: fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions i don't understand what he says... However, it looks that i can push to staging. Can you confirm that Benko Pal's fix for http://code.google.com/p/lilypond/issues/detail?id=2109 was pushed properly to staging? From what i see, it got ID 9f24e79a945ec4ab000d3e09ff2d2ac8208e2246. thanks, Janek LGTM http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/staging -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: I guess i should change it into this: [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master I'd put * instead of twice master here (easier than multiple fetch lines). I don't get it. Anyway, its only a readability enhancement? No. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: Well, i changed config file, can check out branch staging, but still cannot diff it: fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions i don't understand what he says... You don't have staging in your fetch line. That's why I recommended fetching * instead of just master. However, it looks that i can push to staging. Can you confirm that Benko Pal's fix for http://code.google.com/p/lilypond/issues/detail?id=2109 was pushed properly to staging? From what i see, it got ID 9f24e79a945ec4ab000d3e09ff2d2ac8208e2246. That's there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Tue, Jan 03, 2012 at 08:09:10PM +0100, m...@apollinemike.com wrote: I decided to download GUB and I think I've compiled everything (it ran for several hours and did not complain). I have no clue how it works, though. Is there any documentation beside the README? The thing I understand least are the patches - are the patches in the patches file hand-written or auto-generated? There's the README and the materials in the CG. Umm, did you even *look* in the CG for release instructions or releases or whatever that chapter is called? Chapter 11 or 12, I think it is? I slavishly follow the instructions in the minor release subsection or subsubsection. Every single devel release is created by me copypasting from those steps. If you follow those steps as well, you should have exactly the same 2.15.23 release as the official one. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20111224
2011/12/31 Benkő Pál benko@gmail.com: 2011/12/23 Colin Campbell c...@shaw.ca: For 22:00 MST Saturday The Night Before Christmas Enhancement: Issue 2109: do not tinker with the position of a pitched rest - R 5434061 could someone with push rights push this? pushed as 9f24e79a945ec4ab000d3e09ff2d2ac8208e2246 Sorry for the delay and many thanks for the patch, Pal! cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 James pkx1...@gmail.com: Hello, 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: However, it looks that i can push to staging. Can you confirm that Benko Pal's fix for http://code.google.com/p/lilypond/issues/detail?id=2109 was pushed properly to staging? From what i see, it got ID 9f24e79a945ec4ab000d3e09ff2d2ac8208e2246. LGTM Thanks! 2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: I guess i should change it into this: [remote origin] url = ssh://jan...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/master:refs/remotes/origin/master I'd put * instead of twice master here (easier than multiple fetch lines). I don't get it. Anyway, its only a readability enhancement? No. Ah, ok, i understand now! 2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: Well, i changed config file, can check out branch staging, but still cannot diff it: fatal: ambiguous argument 'origin/staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions i don't understand what he says... You don't have staging in your fetch line. That's why I recommended fetching * instead of just master. Ah!! You see, i wasn't smart enough to understand what you wrote about that asterisk. Everything works fine now, and i understand. Great! Many thanks!! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Jan 3, 2012, at 9:18 PM, Graham Percival wrote: On Tue, Jan 03, 2012 at 08:09:10PM +0100, m...@apollinemike.com wrote: I decided to download GUB and I think I've compiled everything (it ran for several hours and did not complain). I have no clue how it works, though. Is there any documentation beside the README? The thing I understand least are the patches - are the patches in the patches file hand-written or auto-generated? There's the README and the materials in the CG. Umm, did you even *look* in the CG for release instructions or releases or whatever that chapter is called? Chapter 11 or 12, I think it is? This I did not... I slavishly follow the instructions in the minor release subsection or subsubsection. Every single devel release is created by me copypasting from those steps. If you follow those steps as well, you should have exactly the same 2.15.23 release as the official one. I'm afraid that if I did the whole prep release announcement thing, I'll accidentally push stuff to master that shouldn't be there, no? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Tue, Jan 03, 2012 at 09:26:48PM +0100, m...@apollinemike.com wrote: I slavishly follow the instructions in the minor release subsection or subsubsection. Every single devel release is created by me copypasting from those steps. If you follow those steps as well, you should have exactly the same 2.15.23 release as the official one. I'm afraid that if I did the whole prep release announcement thing, I'll accidentally push stuff to master that shouldn't be there, no? hmm, yes, good point. Also, I wouldn't want to have stuff in release/unstable unless it's an actual release. Ok, skip over the git commands, and maybe other stuff if they're not relevant... but the basic idea of look in the minor releases section to see how to use GUB is still valid. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copy pdf docs to new website folder (issue 5507046)
On Tue, Jan 03, 2012 at 06:31:54PM +, hashas...@gmail.com wrote: Sorry, didn't understand what you mean by add issue 2166 to track this It's not relevant unless you're going to be making other patches. If you are, read the summary for experienced developers again in more detail. The git-cl step wasn't done properly. Anything I can do to help this to get live? Wait a day or two. It's on the countdown right now. See the summary for experienced developers if you don't know what that means. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
m...@apollinemike.com m...@apollinemike.com writes: I slavishly follow the instructions in the minor release subsection or subsubsection. Every single devel release is created by me copypasting from those steps. If you follow those steps as well, you should have exactly the same 2.15.23 release as the official one. I'm afraid that if I did the whole prep release announcement thing, I'll accidentally push stuff to master that shouldn't be there, no? You could work in a directory created with git clone, then you would likely only be pushing to your own repository (be sure to reset it before pushing anything upstream though, or create another clone or checkout for your upstream simulation). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
2012/1/3 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 David Kastrup d...@gnu.org: The Learning Guide and the Notation Guide need a complete rereading and reorganization, and it is not like the Extending Guide is in significantly better shape. I'd like to fix them too, but i don't have time for everything i want :( Splitting my time doesn't look like a good idea - it's more effective when i put all my foxus on one thing, analyze it deeply and make a complete solution than swap issues. I have to choose and i choose improving graphical output. I am a TeX specialist, system programmer, Emacs specialist, the GNU maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi anybody? preview-latex for Lilypond?), know how to make Emacs read data from Midi ports, am pretty good concerning compiler writing, shell scripting, general programming, efficient algorithms, am the resident quiz person for git and so on and so on. I would have no problems spending a few hundred man years focused on Lilypond. Except that I don't have a few hundred man years. Nobody has. The next best option is spending time on multipliers. Getting LilyPond in a shape where passersby find it intriguing, to a degree where they get hooked and contribute manmonths of work over some time without having planned to do so at the start. +1 LilyPond has great infrastructure: it makes by far the most from Texinfo from any application I know, with much better HTML than upstream, far more thorough and good use of images (only useful in HTML or with Emacs as info reader, I am afraid). I have no clue why or how GUB works, but many others don't have something like that. It has good facilities for internationalization. There are other novel pieces that turn out to be more of a maintenance problem than an asset because of a total lack of documentation and/or mindshare: yaffut, the organization of the C++ core, many internals, stepmake, ... Many corners are lying dormant since their respective driving force went away or lost interest or time. I don't manage to keep up with code reviews and am pretty sure that there are maintenance time bombs creeping in all the while. The only thing that is going to help is more eyes, more people who get interested, more people discovering dark corners and doing something about them. +1 LilyPond needs to get into a state where, say, half the engravers are written and maintained in Scheme. And by Scheme I don't mean Scheme at the level Nicolas can barely handle but Scheme a Fortran programmer would not have all too much of a problem understanding. Umm, impossible? From my perspective, 'Scheme' and 'easy to understand' are mutually exclusive. Unless there are more comments than code - literally - but we don't do so. To get there, we need serious programmers and serious musicians interested seriously in LilyPond. To a level where they start asking good questions. And we better be in a position to provide answers, since there is no more effective way to spend our time than on getting more people to spend their time, and love, and interest. That's like + from me! In general, i agree that we should think in a more 'release-oriented' way (last stable release was half a year ago, so we should make another one, so i'm fixing whatever needs to be fixed to make this possible) instead of 'free coding' way (i care about this issue, i'll fix it. And that one. Oh, we have 0 criticals, so let's make a stable release before an obstruction occurs!). To do so, we would have to work more as a team, less independently. How can we achieve that if GOP7 showed that we don't want to? By the way, you mentioned earlier that there are issues much more severe and threatening to Lily 'stability' than those currently marked as critical. This made me curious. Can you elaborate? And we better be in a position to provide answers, since there is no more effective way to spend our time than on getting more people to spend their time, and love, and interest. The only easy way of moving towards this goal which i see is adding comments to the code, explaining what it does (and thus making it easier to provide answers). Some time ago i was looking at horizontal spacing code and i didn't understand anything. I was also recently trying to make Lily place augmentation dot differently with my friend Luke (who is, unlike me, a programmer) - it took us a few hours to figure it out. I seriously think that Lily code could (and should) be better described internally. What do you think? thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues -- hope you're having fun
On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote: James pkx1...@gmail.com writes: My question to David, because I am not getting where the 'ire' is coming from, why do you care if we release dev after dev release vs stable? Yeah, especially since Carl was *already* making good progress on the GUB-related critical issues. URL:http://xkcd.com/386/ yep. Let's cut to the chase: I am an evil semi-overlord. I jealously guard my ssh login to lilypond.org (along with Han-Wen's and Jan's), I am fickle, and I like to play with small kittens. Due to my evil fickle nature, I am not going to change the stated policy until it has been in place for at least 12 months. Any critical issue will block a stable release. I am chuckling maniacally and delighting in how evil and wrong I am being. Don't like it? You have three (effective) options: 1. don't add regressions. 2. fix (or help fix) any critical issues. 3. build your own binary releases. Finally: I bet that Hitler had strong opinions on when open-source projects should release stable versions. Hugs and kisses, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues -- hope you're having fun
Hello, On 3 January 2012 20:49, Graham Percival gra...@percival-music.ca wrote: On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote: James pkx1...@gmail.com writes: My question to David, because I am not getting where the 'ire' is coming from, why do you care if we release dev after dev release vs stable? Yeah, especially since Carl was *already* making good progress on the GUB-related critical issues. URL:http://xkcd.com/386/ yep. Let's cut to the chase: I am an evil semi-overlord. I jealously guard my ssh login to lilypond.org (along with Han-Wen's and Jan's), I am fickle, and I like to play with small kittens. Due to my evil fickle nature, I am not going to change the stated policy until it has been in place for at least 12 months. Any critical issue will block a stable release. I am chuckling maniacally and delighting in how evil and wrong I am being. Don't like it? You have three (effective) options: 1. don't add regressions. 2. fix (or help fix) any critical issues. 3. build your own binary releases. Finally: I bet that Hitler had strong opinions on when open-source projects should release stable versions. Hugs and kisses, - Graham http://en.wikipedia.org/wiki/Godwin's_law ! -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues -- hope you're having fun
Graham Percival gra...@percival-music.ca writes: On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote: James pkx1...@gmail.com writes: My question to David, because I am not getting where the 'ire' is coming from, why do you care if we release dev after dev release vs stable? Yeah, especially since Carl was *already* making good progress on the GUB-related critical issues. URL:http://xkcd.com/386/ yep. Let's cut to the chase: I am an evil semi-overlord. I jealously guard my ssh login to lilypond.org (along with Han-Wen's and Jan's), I am fickle, and I like to play with small kittens. Due to my evil fickle nature, I am not going to change the stated policy until it has been in place for at least 12 months. Any critical issue will block a stable release. I am chuckling maniacally and delighting in how evil and wrong I am being. Don't like it? You have three (effective) options: 1. don't add regressions. The problem is that this actually falls into the categories 1a) don't mention regressions 1b) don't make significant enhancements 1c) don't contribute enhancements 2. fix (or help fix) any critical issues. This is usually implemented as 2a) shrug your shoulders since they don't concern you and wait another year. 3. build your own binary releases. Usually done as 3a) never mind, I got my own checkout. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Jan 3, 2012, at 9:35 PM, Graham Percival wrote: On Tue, Jan 03, 2012 at 09:26:48PM +0100, m...@apollinemike.com wrote: I slavishly follow the instructions in the minor release subsection or subsubsection. Every single devel release is created by me copypasting from those steps. If you follow those steps as well, you should have exactly the same 2.15.23 release as the official one. I'm afraid that if I did the whole prep release announcement thing, I'll accidentally push stuff to master that shouldn't be there, no? hmm, yes, good point. Also, I wouldn't want to have stuff in release/unstable unless it's an actual release. Ok, skip over the git commands, and maybe other stuff if they're not relevant... but the basic idea of look in the minor releases section to see how to use GUB is still valid. :) Sorry to pester - I promise to be as autonomous as possible so long as GUB starts being as autonomous as possible. I got : make LILYPOND_BRANCH=release/unstable lilypond make -f lilypond.make make[1]: Entering directory `/home/mikesol/gub' mkdir -p versiondb regtests uploads ** CHECK: regression tests tarball (i.e. something like lilypond-2.13.4-1.test-output.tar.bz2 ) should be placed in regtests/ When you have done this, disable this check by doing: touch regtests/ignore ** exit 1 make[1]: *** [regtests/ignore] Error 1 make[1]: Leaving directory `/home/mikesol/gub' make: *** [lilypond] Error 2 Any ideas as to why gub hates me so early? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/3 David Kastrup d...@gnu.org:
LilyPond needs to get into a state where, say, half the
engravers are written and maintained in Scheme. And by Scheme I don't
mean Scheme at the level Nicolas can barely handle but Scheme a
Fortran programmer would not have all too much of a problem
understanding.
Umm, impossible? From my perspective, 'Scheme' and 'easy to
understand' are mutually exclusive. Unless there are more comments
than code - literally - but we don't do so.
Well, as an example, take a look at
URL:http://nicolas.sceaux.free.fr/prelude/prelude.html
Now take a look at
\begin{lilypond}
ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
(ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
#{
\repeat unfold 2 { $p1 2 } |
\repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
\repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
#})
\parallelMusic #'(low middle high)
{
\ph c' e' g' c'' e''
R1*7 | \skip 1*7 | R1*7 |
\ph ac' e' g' c''
\voiceTwo | \change Staff = down \voiceOne | \oneVoice |
\ph da d' fis' c''
R1*21 | \skip 1*21 | R1*21 |
\ph c, c g bes e'
c,2~ c, | r16 c8. ~ c4 ~ c2
| r8 f16 a c' f' c' a c' a f a f d f d |
c,2~ c, | r16 b,8. ~ b,4 ~ b,2
| r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
c,1\fermata | c1 | e' g' c''1\fermata \bar |. |
}
\score {
\new PianoStaff
\new Staff = up {
\high \\ \middle
}
\new Staff = down {
\clef bass
\low
}
\midi {
\context {
\Score
\with \settingsFrom { \tempo 4 = 80 }
}
}
\layout {
\context {
\Score
\with \settingsFrom { \compressFullBarRests }
}
\context {
\Staff
\with \settingsFrom { \accidentalStyle modern }
}
}
}
\end{lilypond}
\ph is a music function written in Scheme. Can you understand it?
\settingsFrom is actually returning a Scheme expression for \with to
use. It makes things rather simpler than more complex, even though it
constitutes a Scheme expression.
Scheme is not hard. Programming is hard. And there is still far too
much repetitive programming required for stuff that could be handled
using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
bothered packaging them. Far too often if I think Ok, task x has no
documented way of dealing with it. Let's see whether we can find an
undocumented API. And then I find about 10 files implementing their
own ad hoc API that will break in different ways if one has to change
the data structures at some point of time.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
CG: clarify what countdown means (issue 5489141)
Reviewers: ,
Message:
very small patch
Description:
CG: clarify what countdown means
CG currently sounds like countdown is the time
when developers can review a patch, but it's not true.
Developers can review a patch since it's uploaded,
the countdown is only a warning/reminder about a patch.
Please review this at http://codereview.appspot.com/5489141/
Affected files:
M Documentation/contributor/introduction.itexi
Index: Documentation/contributor/introduction.itexi
diff --git a/Documentation/contributor/introduction.itexi
b/Documentation/contributor/introduction.itexi
index
914e7ef72b09ab8884a70284fdf6d1ad044031f3..5c72933e71a0dd168dba7548d384e1c5b2bb20bd
100644
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -172,8 +172,8 @@ your patch is put on a countdown, it will be given
@item
The countdown is a 48-hour period which gives other developers a
-chance to review the patch. If no significant problems are found,
-your patch will be given @code{Patch-push} status.
+last chance to review the patch. If no significant problems are
+found, your patch will be given @code{Patch-push} status.
@item
You may now either push it to the @code{staging} branch, or email
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Tue, Jan 03, 2012 at 10:00:01PM +0100, m...@apollinemike.com wrote: Any ideas as to why gub hates me so early? GUB hates you because you skipped over point 3 under pre-release on: http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: 2012/1/3 David Kastrup d...@gnu.org: You don't have staging in your fetch line. That's why I recommended fetching * instead of just master. Ah!! You see, i wasn't smart enough to understand what you wrote about that asterisk. Everything works fine now, and i understand. Great! Many thanks!! Fetching all branches created a new problem: can i tell git that it should rebase branches against master by default? Because now when i checked a non-master, non-staging local branch and called 'git pull -r' he said You asked me to pull without telling me which branch you want to rebase against, and 'branch.mook.merge' in your configuration file does not tell me, either. Please specify which branch you want to use on the command line and try again (e.g. 'git pull repository refspec'). See git-pull(1) for details. If you often rebase against the same branch, you may want to use something like the following in your configuration file: [branch mook] remote = nickname merge = remote-ref rebase = true [remote nickname] url = url fetch = refspec See git-config(1) for details. Of course i can do what he suggests, but it means either - a lot of typing 'git pull -r origin refs/heads/master' (if i got it right) - editing config file every time i create a branch (not nice). Ideas? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: clarify what countdown means (issue 5489141)
LGTM http://codereview.appspot.com/5489141/diff/1/Documentation/contributor/introduction.itexi File Documentation/contributor/introduction.itexi (right): http://codereview.appspot.com/5489141/diff/1/Documentation/contributor/introduction.itexi#newcode175 Documentation/contributor/introduction.itexi:175: last chance to review the patch. If no significant problems are change: a last chance to: one last chance then push directly to staging. http://codereview.appspot.com/5489141/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
On Tue, Jan 03, 2012 at 08:45:45PM +0100, Janek Warchoł wrote: I guess i should change it into this: [core] [branch master] It's not a bad thing that we can ask git wizards to give us custom advice on our .git/config, but this shouldn't be necessary. I mean, the only time I've ever edited .git/config was to give myself push ability, following the CG. Once you've got your system working, Janek, could you (in a separate directory) do a fresh git clone, following the instructions in http://lilypond.org/doc/v2.15/Documentation/contributor/setting-up and nowhere else, then see what happens if you follow the instructions in the current patch for 2100 ? I think *that's* where we should focus the attention. Get the CG clear on this point (which will involve deleting most of 3.2.2, but that comes later), so that we don't need to do this song and dance for every single developer. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Jan 3, 2012, at 10:35 PM, Graham Percival wrote:
On Tue, Jan 03, 2012 at 10:00:01PM +0100, m...@apollinemike.com wrote:
Any ideas as to why gub hates me so early?
GUB hates you because you skipped over point 3 under pre-release
on:
http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist
Ah, I missed it cuz of the layout - my eyes are attracted by things in boxes.
So my lilypond development for the day is...
diff --git a/Documentation/contributor/release-work.itexi
b/Documentation/contributor/release-work.itexi
index a3b7e86..413fc83 100644
--- a/Documentation/contributor/release-work.itexi
+++ b/Documentation/contributor/release-work.itexi
@@ -95,6 +95,12 @@ git push origin release/unstable
If you do not have the previous release test-output tarball, download
it and put it in @code{regtests/}
+@example
+This box has no reason for being here except to attract attention
+to the point above about downloading the previous release test-output
+tarball.
+@end example
+
@item Prepare GUB environment by running:
@example
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
explain how to add git-cl to PATH (issue 5503093)
Reviewers: ,
Description:
explain how to add git-cl to PATH
i know modifying PATH is basic knowledge,
but i'm windows man and figuring this out
took me 15 minutes... too long.
Please review this at http://codereview.appspot.com/5503093/
Affected files:
M Documentation/contributor/source-code.itexi
Index: Documentation/contributor/source-code.itexi
diff --git a/Documentation/contributor/source-code.itexi
b/Documentation/contributor/source-code.itexi
index
3f964f93a41f65b321b586feedab8e9962adf2b6..449e8c83fe4b24eead0b7297463c02d2c4a7be51
100644
--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -913,10 +913,12 @@ git clone git://github.com/gperciva/git-cl.git
@end example
@item
-Add the @file{git-cl/} directory to your PATH, or create a
-symbolic link to the @command{git-cl} and @command{upload.py}
-scripts in one of your PATH directories (such as
-@file{$HOME/bin}).
+Add the @file{git-cl/} directory to your PATH (add line
+@command{PATH=~/type-here-directory-containing-git-cl:${PATH}}
+at the end of a hidden file @file{.bashrc} in your home directory),
+or create a symbolic link to the @command{git-cl}
+and @command{upload.py} scripts in one of your PATH
+directories (such as @file{$HOME/bin}).
@end enumerate
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
2012/1/3 Graham Percival gra...@percival-music.ca: On Tue, Jan 03, 2012 at 08:45:45PM +0100, Janek Warchoł wrote: I guess i should change it into this: [core] [branch master] It's not a bad thing that we can ask git wizards to give us custom advice on our .git/config, but this shouldn't be necessary. I mean, the only time I've ever edited .git/config was to give myself push ability, following the CG. Once you've got your system working, Janek, could you (in a separate directory) do a fresh git clone, following the instructions in http://lilypond.org/doc/v2.15/Documentation/contributor/setting-up and nowhere else, then see what happens if you follow the instructions in the current patch for 2100 ? I think *that's* where we should focus the attention. Get the CG clear on this point (which will involve deleting most of 3.2.2, but that comes later), so that we don't need to do this song and dance for every single developer. Ok, i'll do it tomorrow (hopefully). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: explain how to add git-cl to PATH (issue 5503093)
I hesitate to do this because is it OS-specific.
I think if we are going to do it, we should clearly mark this line as
applying to lilydev and similar systems.
When we do this, we are diving development towards only occuring on
lilydev. Maybe that's OK, but it seems unnecessary to me.
Thanks,
Carl
http://codereview.appspot.com/5503093/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5503093/diff/1/Documentation/contributor/source-code.itexi#newcode917
Documentation/contributor/source-code.itexi:917:
@command{PATH=~/type-here-directory-containing-git-cl:${PATH}}
If we are going to do this, we should probably have the line be in an
@example
http://codereview.appspot.com/5503093/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: clarify what countdown means (issue 5489141)
pushed as c1a1f9684b6cfab2e4b4d813db6058c7d22b9b0a http://codereview.appspot.com/5489141/diff/1/Documentation/contributor/introduction.itexi File Documentation/contributor/introduction.itexi (right): http://codereview.appspot.com/5489141/diff/1/Documentation/contributor/introduction.itexi#newcode175 Documentation/contributor/introduction.itexi:175: last chance to review the patch. If no significant problems are On 2012/01/03 21:37:00, Graham Percival wrote: change: a last chance to: one last chance then push directly to staging. Done. http://codereview.appspot.com/5489141/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: explain how to add git-cl to PATH (issue 5503093)
Most linux distributions use bash, so this isn't a terrible idea. But
you need to log out and log back in for the change to take effect.
http://codereview.appspot.com/5503093/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5503093/diff/1/Documentation/contributor/source-code.itexi#newcode917
Documentation/contributor/source-code.itexi:917:
@command{PATH=~/type-here-directory-containing-git-cl:${PATH}}
On 2012/01/03 21:55:09, Carl wrote:
If we are going to do this, we should probably have the line be in an
@example
+1
http://codereview.appspot.com/5503093/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On Tue, Jan 03, 2012 at 10:44:57PM +0100, m...@apollinemike.com wrote: Ah, I missed it cuz of the layout - my eyes are attracted by things in boxes. So my lilypond development for the day is... heh, I've wondered about doing something like that. I'm not wild about the idea, since the command-line gives you a clue about it anyway, and it's only relevant the very first time you do this... but sure, go ahead and push to staging. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
My non-official instructions for getting GUB going on lilydev
Here's what I did to get GUB going on the latest lilydev. It's not pretty, and it's not formatted, but it's what worked for me. Hope this helps somebody else. OK, starting with fresh install of lilydev. Need to get libmpfr-dev sudo apt-get install libmpfr-dev make bootstrap make lilypond If it doesn't complete, then the error will likely be because there is no netpbm file in gub/downloads/netpbm. I thought I had updated the sources, but it still isn't downloading. If you find yourself in this fix, do the following: download netpbm from http://lilypond.org/download/gub-sources/netpbm-patched/netpbm-patched-10.3 5.tar.bz2 and put it in downloads/netpbm download rsync from ftp://ftp.samba.org/pub/rsync/src/rsync-3.0.4.tar.gz and put it in downloads/rsync make lilypond Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Build Success!
On 1/3/12 3:10 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Jan 03, 2012 at 10:44:57PM +0100, m...@apollinemike.com wrote: Ah, I missed it cuz of the layout - my eyes are attracted by things in boxes. So my lilypond development for the day is... heh, I've wondered about doing something like that. I'm not wild about the idea, since the command-line gives you a clue about it anyway, and it's only relevant the very first time you do this... but sure, go ahead and push to staging. Rather than doing it this way, let's put the original paragraph in an example, even though it's not one. @example If you do not have the previous released. @end example Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
2012/1/3 David Kastrup d...@gnu.org:
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/3 David Kastrup d...@gnu.org:
LilyPond needs to get into a state where, say, half the
engravers are written and maintained in Scheme. And by Scheme I don't
mean Scheme at the level Nicolas can barely handle but Scheme a
Fortran programmer would not have all too much of a problem
understanding.
Umm, impossible? From my perspective, 'Scheme' and 'easy to
understand' are mutually exclusive. Unless there are more comments
than code - literally - but we don't do so.
Well, as an example, take a look at
URL:http://nicolas.sceaux.free.fr/prelude/prelude.html
Hmm, excuse me while my brain melts ;)
Now take a look at
\begin{lilypond}
ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
(ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
#{
\repeat unfold 2 { $p1 2 } |
\repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
\repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
#})
\parallelMusic #'(low middle high)
{
\ph c' e' g' c'' e''
R1*7 | \skip 1*7 | R1*7 |
\ph a c' e' g' c''
\voiceTwo | \change Staff = down \voiceOne | \oneVoice |
\ph d a d' fis' c''
R1*21 | \skip 1*21 | R1*21 |
\ph c, c g bes e'
c,2~ c, | r16 c8. ~ c4 ~ c2
| r8 f16 a c' f' c' a c' a f a f d f d |
c,2~ c, | r16 b,8. ~ b,4 ~ b,2
| r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
c,1\fermata | c1 | e' g' c''1\fermata \bar |. |
}
\score {
\new PianoStaff
\new Staff = up {
\high \\ \middle
}
\new Staff = down {
\clef bass
\low
}
\midi {
\context {
\Score
\with \settingsFrom { \tempo 4 = 80 }
}
}
\layout {
\context {
\Score
\with \settingsFrom { \compressFullBarRests }
}
\context {
\Staff
\with \settingsFrom { \accidentalStyle modern }
}
}
}
\end{lilypond}
\ph is a music function written in Scheme. Can you understand it?
Yes, but i get lost on \parallellMusic :(
\settingsFrom is actually returning a Scheme expression for \with to
use. It makes things rather simpler than more complex, even though it
constitutes a Scheme expression.
Um... i would really love to be able to type
\layout {
\compressFullBarRests
\override Score.SpacingSpanner #'common-shortest-duration =
#(ly:make-moment 6 10)
etc...
}
Scheme is not hard. Programming is hard. And there is still far too
much repetitive programming required for stuff that could be handled
using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
bothered packaging them. Far too often if I think Ok, task x has no
documented way of dealing with it. Let's see whether we can find an
undocumented API. And then I find about 10 files implementing their
own ad hoc API that will break in different ways if one has to change
the data structures at some point of time.
I agree, this should not work like that.
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Hi Luke, nice to see you joining the discussion :) W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński milimet...@gmail.com napisał: That's like + from me! In general, i agree that we should think in a more 'release-oriented' way (last stable release was half a year ago, so we should make another one, so i'm fixing whatever needs to be fixed to make this possible) instead of 'free coding' way (i care about this issue, i'll fix it. And that one. Oh, we have 0 criticals, so let's make a stable release before an obstruction occurs!). To do so, we would have to work more as a team, less independently. How can we achieve that if GOP7 showed that we don't want to? and: And we better be in a position to provide answers, since there is no more effective way to spend our time than on getting more people to spend their time, and love, and interest. Regarding all those fragments of Janek's and David's emails: For some time I have been observing how bugs are being fixed in Lilypond and spent some time on conversations with Janek. For me there is almost no team work in Lilypond - only a bunch of geek trying to fix some issues, but without a leader who coordinates all actions. I might have given you a wrong impression, i don't think its really that bad. There is some teamwork, but no leader indeed. As far as I remember, some time ago you have tried hard to make some big changes in Lilypond, but finally there was no big revolution... Hmm? I remember that i mentioned to you the rewrite of vertical spacing system, which was implemented quite successfully. Without a leader that will make key design implementation decisions Lilypond will improve in a slow pace, letting Finale and Sibellius gain more and more users. Probably some of you will return to the old row - is a goal of a Lilypond to substitue Finale or compete with Sibellius. I think there is no point in loosing your energy and time on that. Instead we should do as much as possible to constantly improve Lilypond. That means not only fixing critical bugs, but also: anticipating future stability problems, constantly improving end user documentation and the quality of source code (reduce complexity, comment code and so on). By now there is a huge work to be done and Lilypond needs someone who will form guidelines and priorities. That's generally true and i'd love to have a leader and lots of teamwork, but who would be the leader? It would be a time-consuming task, none of our current developers has much spare time; it would also require lots of knowledge, so only few would qualify :( You might consider reading http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-7-_002d-developers-as-resources It's simply that we discussed this before and didn't manage to do these (good) things you propose. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
hello, On 3 Jan 2012, at 22:26, Janek Warchoł janek.lilyp...@gmail.com wrote: Hi Luke, nice to see you joining the discussion :) W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński milimet...@gmail.com napisał: That's like + from me! In general, i agree that we should think in a more 'release-oriented' way (last stable release was half a year ago, so we should make another one, so i'm fixing whatever needs to be fixed to make this possible) instead of 'free coding' way (i care about this issue, i'll fix it. And that one. Oh, we have 0 criticals, so let's make a stable release before an obstruction occurs!). To do so, we would have to work more as a team, less independently. How can we achieve that if GOP7 showed that we don't want to? and: And we better be in a position to provide answers, since there is no more effective way to spend our time than on getting more people to spend their time, and love, and interest. Regarding all those fragments of Janek's and David's emails: For some time I have been observing how bugs are being fixed in Lilypond and spent some time on conversations with Janek. For me there is almost no team work in Lilypond - only a bunch of geek trying to fix some issues, but without a leader who coordinates all actions. I might have given you a wrong impression, i don't think its really that bad. There is some teamwork, but no leader indeed. to use an English expression ... poppycock! Janek you may have not noticed that the team of Colin, Phil and myself along with some of the bug squad managed, with the the help of Graham (if you want to call him a 'leader') to process a quite impressive number of patches. Before we managed to get some kind of automation of patch testing I personally was fielding about 6 new patches a day, producing reg test diffs, make checks and the like. Colin was managing all patch countdown and push requests while Phil ran around, figuratively speaking, making sure things were in order in terms of regressions between dev releases. all co ordinated by graham - pretty much. in the meantime Mike, Keith, Carl and co had plenty of time then to fix some long standing bugs, and I am seeing some serious work by David to do whatever it is he does with the parser etc. All of which we still pretty much managed to keep a relatively stable tree with one or two hiccups which considering the amount of pushed changes and the fundamental stuff the coders were free to do because of them not having to worry about things like ... oh testing their patches don't break the main tree, spotting quickly any potential issues or breakages because now they can focus on reviews of code than having to administer them, that new features are documented and that all emails from users complaining about this and that are documented themselves in a tracker completely makes that claim ridiculous and rather gets on my wick( to use another expression). comments like that from Luke are unhelpful, disrespectful to many of us and frankly, tedious. As far as I remember, some time ago you have tried hard to make some big changes in Lilypond, but finally there was no big revolution... Maybe before my time, however instead of complaining how about doing something constructive? Hmm? I remember that i mentioned to you the rewrite of vertical spacing system, which was implemented quite successfully. Without a leader that will make key design implementation decisions Lilypond will improve in a slow pace, letting Finale and Sibellius gain more and more users. So what? it's not a competition. Probably some of you will return to the old row - is a goal of a Lilypond to substitue Finale or compete with Sibellius. I think there is no point in loosing your energy and time on that. Yet you just did. some of us aren't fixated wit the stupid Sibfib comparison or even care. Instead we should do as much as possible to constantly improve Lilypond. That means not only fixing critical bugs, but also: anticipating future stability problems, constantly improving end user documentation and the quality of source code (reduce complexity, comment code and so on). By now there is a huge work to be done and Lilypond needs someone who will form guidelines and priorities. yeah, blah blah ... some of us already know and some of us are getting on with it instead of complaining. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: 2f25894efd8ad242b233d5a1d07afcfa087ebab2 Merged staging, now at: c1a1f9684b6cfab2e4b4d813db6058c7d22b9b0a Success:./autogen.sh --noconfigure Success:../configure --disable-optimising Success:nice make -j3 CPU_COUNT=3 Success:nice make test -j3 CPU_COUNT=3 *** FAILED BUILD *** nice make doc -j3 CPU_COUNT=3 Previous good commit: 2fd5a378f5d883536b1aac57583d261ce60a4043 Current broken commit: c1a1f9684b6cfab2e4b4d813db6058c7d22b9b0a ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault 2.15.23 Span_bar_stub_engraver
On Tue, Jan 3, 2012 at 1:12 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Jan 3, 2012, at 9:02 AM, David Kastrup wrote: If he hadn't rerun configure since before version 2.15.21, I think that the compilation would likely have failed for other reasons. The problem report is for 2.15.23. It may be worth for him to report the CXXFLAGS setting in config.status just to be on the safe side, but I consider it unlikely that this particular problem has not already been covered. I pulled down lilypond and build new just last week. CXXFLAGS in config.status is: - With optimization (default): O2 -finline-functions -g -pipe -fno-optimize-sibling-calls - Without optimization: -g -pipe -fno-optimize-sibling-calls Are you using an optimized binary? Mine is unoptimized. Please try ./autogen.sh --disable-optimizing before compiling and let me know if that makes the segfault go away. I found --disable-optimising instead. Same result. I can't reproduce this on my wife's mac or on my laptop (also running ubuntu 11.10). The only difference I can think of is I'm running 64-bit and my laptop is 32-bit. Unless someone else can reproduce this issue don't spend much more time on this. I have a good solution (adding in the dynamics). Thanks! -Jay ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120105
For 21:00 MST Thursday January 5, 2012 Maintainability: Issue 2026 http://code.google.com/p/lilypond/issues/detail?id=2026: Make markup utility definitions available via new (scm markup-utility-defs) scheme module - R 5504107 http://codereview.appspot.com/5504107/ Documentation: Issue 2093 http://code.google.com/p/lilypond/issues/detail?id=2093: Doc: NR alternativeNumberingStyle (fix issue 2059) needs to be documented - R 5507043 http://codereview.appspot.com/5507043/ Issue 1802 http://code.google.com/p/lilypond/issues/detail?id=1802: system-system-spacing in lilypond-book-file within a LaTeX file - R 5492075 http://codereview.appspot.com/5492075/ Enhancement: Issue 2165 http://code.google.com/p/lilypond/issues/detail?id=2165: Patch: Modifies broken hairpin height - R 5502089 http://codereview.appspot.com/5502089/ Issue 2171 http://code.google.com/p/lilypond/issues/detail?id=2171: Patch: Implements DOM-id property for grobs - R 5504106 http://codereview.appspot.com/5504106/ Issue 2168 http://code.google.com/p/lilypond/issues/detail?id=2168: Patch: Fix a few more warnings in clang - R 5489131 http://codereview.appspot.com/5489131/ Issue 2167 http://code.google.com/p/lilypond/issues/detail?id=2167: Patch: Doc: selective point and click - R 5507048 http://codereview.appspot.com/5507048/ Patch: Issue 2169 http://code.google.com/p/lilypond/issues/detail?id=2169: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams - R 5507050 http://codereview.appspot.com/5507050/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR added snippet for Alt Bar Numbering (issue 5507043)
LGTM http://codereview.appspot.com/5507043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with checking out staging branch
Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/3 Janek Warchoł janek.lilyp...@gmail.com: 2012/1/3 David Kastrup d...@gnu.org: You don't have staging in your fetch line. That's why I recommended fetching * instead of just master. Ah!! You see, i wasn't smart enough to understand what you wrote about that asterisk. Everything works fine now, and i understand. Great! Many thanks!! Fetching all branches created a new problem: can i tell git that it should rebase branches against master by default? Because now when i checked a non-master, non-staging local branch and called 'git pull -r' he said You asked me to pull without telling me which branch you want to rebase against, and 'branch.mook.merge' in your configuration file does not tell me, either. Please specify which branch you want to use on the command line and try again (e.g. 'git pull repository refspec'). See git-pull(1) for details. I usually rebase manually and instead do just git fetch. Of course i can do what he suggests, but it means either - a lot of typing 'git pull -r origin refs/heads/master' (if i got it right) - editing config file every time i create a branch (not nice). You can just create the branch as git checkout -b new-branch origin and git will know where to pull from. And you can always do git branch --set-upstream new-branch origin after having created it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
