GOP meta: pause in new proposals
Hi all, We've been passing proposals faster than we can implement them. That's particularly a shame because there's a *huge* amount of friction and unpleasantness that can be avoided by spending a few hours on implementing a number of those proposals. We will continue with the existing proposals, but I won't introduce any new ones for the next 2 weeks, possibly longer. I want to make a serious dent in the pain of our development process. Given the current amount of interest in pain removal work, I'm forecasting that GOP will continue until April 2012 or so, and thus GLISS won't begin until Summer 2012. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 13: patch management tools (probable withdraw)
I don't see this proposal (really more of a set of musings) going anywhere. There's been a bunch of ideas: - tool X, tool Y - make better use of our current tools - do a survey of what other projects do but nothing has made a significant amount of people go yeah, that the right direction to move in!. We're not getting closer to any kind of decision, and what's worse, we're not even getting closer to figuring out how we would make any kind of decision. So I propose that we shelve this discussion. If somebody feels motivated and makes a detailed report about the benefits and disadvantages of up various other tools, great; if somebody feels motivated and makes a serious investigation of our *current* tools (what capabilities are we missing, makes feature requests or bug reports to the google overlords, etc), great! If somebody is feeling optimistic about the discussion and thinks I'm totally off-base on this, we can talk about that... but I'm thinking that it needs some serious thought and energy, and at the moment I think I should be putting my energy towards removing pain points in our development for which we've already agreed on what to do. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix 1477: Add (ly:expect-warning msg args) to suppress expected warnings (issue 5037046)
Passes make and reg tests look ok but I guess someone who really knows should check See: http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1477-td4835846.html This has a zipped dir of the make check results. http://codereview.appspot.com/5037046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools (probable withdraw)
Hello, On Sat, Sep 24, 2011 at 8:01 AM, Graham Percival gra...@percival-music.ca wrote: I don't see this proposal (really more of a set of musings) going anywhere. There's been a bunch of ideas: - tool X, tool Y - make better use of our current tools - do a survey of what other projects do but nothing has made a significant amount of people go yeah, that the right direction to move in!. We're not getting closer to any kind of decision, and what's worse, we're not even getting closer to figuring out how we would make any kind of decision. So I propose that we shelve this discussion. If somebody feels motivated and makes a detailed report about the benefits and disadvantages of up various other tools, great; if somebody feels motivated and makes a serious investigation of our *current* tools (what capabilities are we missing, makes feature requests or bug reports to the google overlords, etc), great! If somebody is feeling optimistic about the discussion and thinks I'm totally off-base on this, we can talk about that... but I'm thinking that it needs some serious thought and energy, and at the moment I think I should be putting my energy towards removing pain points in our development for which we've already agreed on what to do. Speaking for myself and (I think) people like Colin, Phil and Dymtryo the biggest headache for bug-squadders and patch-testers is simply the easy correlation between Rietveld and Google code. I know we've already stated that. If this discussion has only done one thing it has highlighted the extra work that this takes and the potential for existing patches to wait and wait. There seems to be four basic cases of how 'stuff' gets created in this regard. 1. Email from person (I'd like LP to do this, or LP breaks when you do X) 2. Rietveld issue with no tracker 3. Tracker issue with no Rietveld (usually RFEs or Devs/experienced users who spot a bug) 4. Rietveld and Tracker are created at the same time Could I therefore suggest two things? 1 Devs who put up a Rietveld put up a tracker too and use the *exact* same title (even if it is very cryptic) the description can be simply the link to the Rietveld URL. if you can also cut;/paste the Rietveld comment into the tracker great but it is not essential. Then leave all the other stuff (labels, owners, tags etc) to the bug squadders or people like myself as I think that might be what is putting people off using the tracker (what label should it be? am I going to cause a lot of huffing and puffing I use Type-Ugly when it is Type-Script and is it Patch-New or Patch-review? and so on. or 2. Devs who put up Rietvelds just add something in the comment like 'this needs a tracker item', or 'no tracker item for this yet' as I realise that getting code up for initial review is more important than the 'admin/paperwork' in many respects, but at least that line gives us a chance, then when we see this we can add the tracker. is that acceptable or am I flogging the proverbial dead horse :) -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110925
On Sep 24, 2011, at 4:27 AM, Graham Percival wrote: On Fri, Sep 23, 2011 at 09:43:01PM -0400, Colin Campbell wrote: Instead, we present a special, one time only, batch as requested by Mike Solomon. Am I correct that these have not been checked by James? I don't think we should call this a countdown. By all means suggest that people review patches, but if they patch hasn't reached patch-review under the normal procedures, I don't think it should be called a countdown. Then they should not be put on a countdown - I'm not sure which patches of mine will be review-ready by the time Colin sends out his weekly e-mail. I ask him to please put all of these on the countdown, and it is up to him which ones to put on the countdown or not. I am not sure what the normal procedures are, but I'm positive he is, and he makes the decision accordingly (see below). oh, and Mike: please stop asking for special favors for your patches. I'm not sure what you mean. I have sent Colin 7 e-mails regarding my patches. Here is the breakdown for every one of them: 7/21: E-mail with 5 patches. Next countdown: 1 patch. 7/25: E-mail with 3 patches. Next countdown: 3 patches. 8/5: E-mail with 5 patches: Next countdown: 0 patches. 8/9: E-mail with 4 patches. Next countdown: 3 patches. 8/14: E-mail with 8 patches. Next countdown: 2 patches put. 8/25: E-mail with 7 patches. Next countdown: 2 patches put. 9/22: E-mail with 5 patches. Next countdown: 5 patches put. As you can see from the tallies above, whenever Colin does not want to put one of my patches on a countdown for whatever reason (too many other patches, not patch-review at the time he makes his batch, whatever) he doesn't. The only response I've ever gotten back from him on this subject is: -snip- This is very helpful, Mike. Do these patches have tracker issues or are they just on Rietveld? ALso, do you use more than one ID on Rietveld? I had a look last night, searching under mts...@gmail.com and saw only closed issues, but maybe I set the parameters wrongly? At any rate, I'll blend these into the next couple of patch batches. You've certainly had a productive Summer, Mike! Cheers, Colin -snip- I would like to continue doing this, as it helps make sure that none of my patches fall through the cracks, it allows me to tell Colin which patches are the most important and which ones can wait, and I get the sense that it is helpful for Colin. However, I also get the sense that from your comment above that you do not feel it is appropriate. Could you elaborate further on what would be a better way to go about this? Everybody (other than me) works hard on their stuff. When you've made a new version of a patch, change the code.google.com issue to Patch-new, and then the updated patch will go through the system again. I only do this when there are substantive changes (and when I remember to do it - I forget sometimes, as you point out below). For example, if during a countdown someone recommends changing a regtest and I throw a patch up with the new regtest so that I can download the unified diff to apply to master, I don't check off patch new. Anytime that I feel a change is big enough to merit going through the system again, I let Colin know (as you saw from this week's countdown for both the SpanBar and the TupletBracket patch). Making git-cl do this automatically will take about 30 minutes of python hacking. Unfortunately, I only have 60 minutes left for this week, and I should reserve those for emails and fixing the darwin-ppc release problem that only I or Jan can fix. http://codereview.appspot.com/5050046/ (no issue #) http://code.google.com/p/lilypond/issues/detail?id=1921 http://codereview.appspot.com/5067041/ (no issue #) http://code.google.com/p/lilypond/issues/detail?id=1922 http://codereview.appspot.com/4961041/ (i imagine that it'll be pulled off by someone, but at least it'll get people looking at it! http://code.google.com/p/lilypond/issues/detail?id=1923 http://codereview.appspot.com/4917046/ (i decided not to push this one because joe had some reservations - i think i've addressed them, but i'd like it to go through another countdown) Thanks for this. The appropriate action is to change it to patch-new, and if James thinks it looks good, it will become patch-review. http://code.google.com/p/lilypond/issues/detail?id=1846 http://codereview.appspot.com/4808082/ (it'll be this patch's 6th go-around! i want to throw it back up because i haven't heard any responses either way about the newest batch of changes) ditto. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110925
On Sat, Sep 24, 2011 at 11:16:35AM +0200, m...@apollinemike.com wrote: Then they should not be put on a countdown - I'm not sure which patches of mine will be review-ready by the time Colin sends out his weekly e-mail. It's three times a week. There should be no rush to get stuff added. Just make patches, mark them patch-new, and the process will handle them. If the patch is good, it's pushed within 72 hours (unless there's unusual load). If it's not good, you'll get comments within 72 hours. However, I also get the sense that from your comment above that you do not feel it is appropriate. Could you elaborate further on what would be a better way to go about this? Add every patch to code.google.com with a Patch-new issue (or adding Patch-new to an existing issue, if it's a bugfix). Every update to every patch should change that issue to Patch-new. Result: no missed patches. Every patch gets a regtest check before it's reviewed, and every patch gets onto a countdown. I don't like asking developers to do this manually -- hence my fussing around with modifying git-cl to do this automatically. But if you're concerned about patches going missing, then go through these manual steps for a week or two until the new git-cl has been tested some more. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110925
On Sep 24, 2011, at 11:39 AM, Graham Percival wrote: On Sat, Sep 24, 2011 at 11:16:35AM +0200, m...@apollinemike.com wrote: Then they should not be put on a countdown - I'm not sure which patches of mine will be review-ready by the time Colin sends out his weekly e-mail. It's three times a week. There should be no rush to get stuff added. Just make patches, mark them patch-new, and the process will handle them. Sorry - I don't know why I said weekly! If the patch is good, it's pushed within 72 hours (unless there's unusual load). If it's not good, you'll get comments within 72 hours. However, I also get the sense that from your comment above that you do not feel it is appropriate. Could you elaborate further on what would be a better way to go about this? Add every patch to code.google.com with a Patch-new issue (or adding Patch-new to an existing issue, if it's a bugfix). Every update to every patch should change that issue to Patch-new. Result: no missed patches. Every patch gets a regtest check before it's reviewed, and every patch gets onto a countdown. I don't like asking developers to do this manually -- hence my fussing around with modifying git-cl to do this automatically. But if you're concerned about patches going missing, then go through these manual steps for a week or two until the new git-cl has been tested some more. That's great! I didn't follow that you were doing that (I don't read all the stuff on devel), but that will help a lot. What would be useful in git-cl is a way to signal to the PatchMeister the developer's perceived importance of a patch. If I have 8 patches waiting to get pushed, I generally have a sense of which ones I'd like to get into a countdown sooner rather than later. Sometimes, this is obvious (i.e. if it fixes a Critical Issue). But sometimes this is less obvious (i.e. it is needed so that I can work on something else), in which case it'd be great if I could communicate this through git-cl. That way, if Colin is deciding between a batch of patches and there's a coin-flip between two patches from one developer, he'll have the developer's notes at his disposal to make the decision. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FiguredBass: Rewrite of the engraver to fix vertical position (issue 224052)
any chance of rebasing this patch? http://codereview.appspot.com/224052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110925
On Sat, Sep 24, 2011 at 11:49:44AM +0200, m...@apollinemike.com wrote: What would be useful in git-cl is a way to signal to the PatchMeister the developer's perceived importance of a patch. Current thinking is to automatically randomly pick 10 patch-review for the countdown, with priority for Critical. I think we're looking at an average of about 10 patches per week so far in Sep, so that gives us a 200% overhead for sudden surges. That said, I've just discovered a ton of old updated patches that got lost, so it'll take a week or two to clear out that backlog. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
archeological patch digging
I've just discovered about 10 patches that had new versions, but hadn't been updated with Patch-new, so James wasn't checking them, so they weren't getting to Patch-review, so they were never getting onto a countdown. I got bored before I finished going throught the entire list, and I didn't look at any of the patch-abandoned stuff. Does anybody feel like doing this? For each patch, - if there's a newer version since the last set of complaints, make it patch-new - if there's existing complaints and it's been over a month since any action, send PRIVATE email to the owner asking if it's abandoned. I say private because public emails are often ignored. If you hear back from the owner that they've definitely given up, make it patch-abandoned. If they say they're still working on it, just make a little comment to that effect so we know what's up. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
- Original Message - From: aleksandr.andr...@gmail.com To: percival.music...@gmail.com; janek.lilyp...@gmail.com; pkx1...@gmail.com; carl.d.soren...@gmail.com; lemzw...@googlemail.com; reinhold.kainho...@gmail.com; w...@gnu.org; n.putt...@gmail.com; gra...@percival-music.ca; m...@apollinemike.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Sent: Friday, September 23, 2011 9:00 PM Subject: Re: Glyphs for Kievan Notation (issue 4951062) make doc problem solved on my system. I can confirm that make and make doc run successfully with this patch. What did you do to get make doc going? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)
On 2011/09/23 15:36:15, p-l-s wrote: Hi Reinhold and Janek, I hope I got it right this time. I didn't include the bit about miscellaneous. This will be part of a seperate patch. BTW: I noticed that the midi-block is not always inserted in every .ly file (this is not related to my patch). I will do some testing... Thanks for your help! patrick I just discovered that I forgot to add the changes related to conversion-info and \center-column. Do I have to make a completely new patch containing all 3 files (musicxml2ly.py, musicxml.py and musicexp.py) or is it ok to upload only the files with these changes (i.e. musicexp.py and musicxml2ly.py)? http://codereview.appspot.com/5096050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Text hyphenation
2011/9/23 Janek Warchoł janek.lilyp...@gmail.com Hi Bertrand, 2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com: * making a system that allows to specify where a word is breakable (like \- in LaTeX); I vote for this because it seems most multi-language friendly. I.e., implementing hyphenation rules for all major languages (i'm interested at least in english, polish and latin) seems a big pain (or are free libraries about it avaiable?). Thanks, Janek! I worked on this yesterday. I chose '--' instead of '\-'. The result is great (see attached). I need to solve a few bugs before putting the patch on codereview. Bertrand hyphenation.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
Pushed as 688f5f1711d8ca07338385a2ae0191b1a8aae315. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Text hyphenation
Hello, 2011/9/24 Bertrand Bordage bordage.bertr...@gmail.com: 2011/9/23 Janek Warchoł janek.lilyp...@gmail.com Hi Bertrand, 2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com: * making a system that allows to specify where a word is breakable (like \- in LaTeX); I vote for this because it seems most multi-language friendly. I.e., implementing hyphenation rules for all major languages (i'm interested at least in english, polish and latin) seems a big pain (or are free libraries about it avaiable?). Thanks, Janek! I worked on this yesterday. I chose '--' instead of '\-'. The result is great (see attached). Hmm... breaking a 4 letter word into two over two lines? :) The typesetter in me cringes slightly. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Text hyphenation
Peekay wrote Saturday, September 24, 2011 12:22 PM 2011/9/24 Bertrand Bordage bordage.bertr...@gmail.com: I worked on this yesterday. I chose '--' instead of '\-'. The result is great (see attached). Hmm... breaking a 4 letter word into two over two lines? Splitting père is even worse - that's not even two syllables, so it really destroys readability. Splits should only be placed between syllables, but maybe this was just a demonstration. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1520/3915 - Release Date: 09/23/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Text hyphenation
2011/9/24 Peekay Ex pkx1...@gmail.com Hmm... breaking a 4 letter word into two over two lines? The typesetter in me cringes slightly. Indeed, global rules would be great for absent-minded people like me... @Trevor : Yes, this was only a manual demonstration. Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
What did you do to get make doc going? I nuked my entire lilypond-git directory, reinstalled the source and ran make and make doc. Then, I ran the Kievan patch and recompiled. A ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
This is a great work, but it doesn't fit correctly into LilyPond: OK, I will merge with Parmesan and work on the Scheme stuff. I also agree with Werner, there's also a lot of cleanup to do inside your MetaFont stuff. I'm new to MetaFont, so right now I'm using it like a GUI-less outline font editor. I know that's probably the wrong approach. A ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Does lilypond 2.15.x support guile 2.0 yet?
If all else fails maybe I can use the release candidate of lilypond for openSUSE 12.1 and update to 2.16.0 before release. If it supports guile 2.0 then I'm wasting precious time on 2.14.2. They wanted to drop lilypond as 2.12.3 has failed for 123 days in factory due to guile 2.0 and my absence for one and a half months due to unfortunate circumstances. Thanks Dave Plater ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
What is -dold-relative and why do we need it?
In program-option-scheme.cc we have
else if (var == ly_symbol2scm (old-relative))
{
lily_1_8_relative = to_boolean (val);
/* Needs to be reset for each file that uses this option. */
lily_1_8_compatibility_used = to_boolean (val);
val = scm_from_bool (to_boolean (val));
}
and it is queried in quite a few places. Lilypond 1.8 seems like a
rather old version to support.
Do we really need to have this around? Anybody even knows what it does?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
Hi, On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. I know it's been used in loads of projects and is much loved, but actually, from a design perspective, it's appalling. I don't understand why so many people think it is... The Make language as it stands does have some quirks, but I like the fundamental concept. But of course that's mostly irrelevant anyways when using a Makefile generator such as Autotools... If I was writing a make system from scratch, I would describe dependencies in data structures that are viewable and editable, and have a separate program that uses those structures to determine which files need making. I'm not sure why you need extra structures for that? For C/C++, gcc can figure out the dependencies as a side effect of compiling the normal source code; and this can be done for most other languages as well. Very few non-trivial programs actually maintain their dependencies by hand nowadays... I've done 5 minutes research and have found SCons. I've not gone into any more depth with that yet. Does it seem worth looking into this, or something else, in more detail? I don't know about SCons, but at least the often-proposed Cmake is *not* a Make replacement. It's a Makefile generator, just like Autotools. Also please consider that the build system is not used only by developers, but also by distribution packagers, and anyone else building the software. Projects using Autotools are still by far the most convenient; anything else means extra effort. -antrik- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need help with openSUSE:Factory build failure in lilypond
On 09/24/2011 12:37 AM, Reinhold Kainhofer wrote: The problem with guile 2.0 is that it includes many major changes (compiled code, new macro handling, new garbage collection, completely new string/unicode handling, etc.), which also require major code changes and restructuring. Lilypond, however, has not been tested AT ALL with the new version yet. Currently, Ian is trying to make lilypond compile and make the basics work with guile 2.0. Guile is not just some additional extension package that lilypond uses, where an update should be mostly painless. Lilyond uses Guile at its very core, and large parts of lilypond are implemented in guile, so an update to guile 2.0 means replacing the very core of lilypond. I don't think you want to play the guinea pig for such a guile 2.0 switch. That's like switching to a completely untested, unstable kernel version shortly before a distribution release. Cheers, Reinhold My problem is that at the moment I'm one man alone trying to find a solution to this problem and still keep up with maintaining multimedia libs and apps along with a few others as an unpaid openSUSE community member. I've started on a guile 1.88 package called guile1 but although --program-suffix=1 appends a one to the executables and I can just rename the pkg-config file, delete guile-config, rename the info pages and install the libs in $libdir/name there appears to be a lot more to do to produce a parallel installable guile1 package. Lilypond will also have to be patched to use it. I could use a bit of help, I'm not as familiar with autoconf and friends as I am with cmake and scons, I have difficulty with large packages such as lilypond and guile, I've only worked with simple library packages. It seems, from googling guile, the rpm based distributions are behind with their guile updates and the patches applied to the handful of openSUSE packages are very simple, gnucash for instance only seems to have a couple of lines in it's patch. The thing that surprises me the most is that guile 2 isn't backward compatible with guile 1, at least python 3 suffixes everything with a 3 and they have tools and information for porting from 2 to 3 guile doesn't seem to have any info about porting, not even in the list messages. Thanks Dave ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Big web page
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Friday, September 23, 2011 7:54 PM Subject: Re: Big web page On Fri, Sep 23, 2011 at 05:03:21PM +0100, Phil Holmes wrote: You know, I'm wondering if this serves any purpose. It's a humungous thing that takes an age to load and display, and for a long time has had a load of missing images, bad links, etc. No-one complained much and no-one really seemed to notice. Yet we lose the images on web-examples and get a user report same day. Given the shenanigans needed to create it, might it make sense to retire it? When the new website was first being built, there was a huge outcry when I suggested not bothering with it. I'd rather keep it around, at least for a bit longer, because it serves as a canary. Is the doc build system as generic as we need? no. (note that there's a few pictures in other manuals; it's not just web-big-html that needs them) Is the doc build system as well-organized as we need? of course not. I think we can do a huge amount of work just by cleaning up the make website process. Admittedly that doesn't include web-big-html, but the increased understanding and simplifications should have follow-on effects to make doc. Cheers, - Graham I thought I'd start with a rather easier to follow description of how make website works. It's attached as a text file with no formatting as yet, for quick thoughts. If wanted I could put it on Rietveld as is, or if it's close enough to being useful, I could texify it first. -- Phil Holmes The Story of make website The rule for make website is found in GNUmakefile.in: website: $(MAKE) config_make=$(config_make) \ top-src-dir=$(top-src-dir) \ -f $(top-src-dir)/make/website.make \ website This translates as: make --no-builtin-rules config_make=./config.make \ top-src-dir=/home/phil/lilypond-git \ -f /home/phil/lilypond-git/make/website.make \ website which has the effect of setting the variables config_make and top-src-dir and then processing the file git/make/website.make with the target of website. website.make starts with the following: ifeq ($(WEBSITE_ONLY_BUILD),1) which checks to see whether the variable WEBSITE_ONLY_BUILD was set to one on the command line. This is only done for standalone website builds, not in the normal case. The result of the test determines the value of some variables that are set. A number of other variables are set, in order to establish locations of various files. An example is: CREATE_VERSION=python $(script-dir)/create-version-itexi.py The rule for website is: website: website-texinfo website-css website-pictures website-examples web-post cp $(SERVER_FILES)/favicon.ico $(OUT)/website cp $(SERVER_FILES)/robots.txt $(OUT)/website cp $(top-htaccess) $(OUT)/.htaccess cp $(dir-htaccess) $(OUT)/website/.htaccess so we see that this starts by running the rules for 5 other targets, then finishes by copying some files. We'll cover that later - first website-texinfo. That rule is: website-texinfo: website-version website-xrefs website-bibs for l in '' $(WEB_LANGS); do \ if test -n $$l; then \ langopt=--lang=$$l; \ langsuf=.$$l; \ fi; \ $(TEXI2HTML) --prefix=index \ --split=section \ --I=$(top-src-dir)/Documentation/$$l \ --I=$(top-src-dir)/Documentation \ --I=$(OUT) \ $$langopt \ --init-file=$(texi2html-init-file) \ -D web_version \ --output=$(OUT)/$$l \ $(top-src-dir)/Documentation/$$l/web.texi ; \ ls $(OUT)/$$l/*.html | xargs grep -L 'UNTRANSLATED NODE: IGNORE ME' | sed 's!$(OUT)/'$$l'/!!g' | xargs $(MASS_LINK) --prepend-suffix=$$langsuf hard $(OUT)/$$l/ $(OUT)/website/ ; \ done which therefore depends on website-version, website-xrefs website-bibs. website-version: mkdir -p $(OUT) $(CREATE_VERSION) $(top-src-dir) $(OUT)/version.itexi $(CREATE_WEBLINKS) $(top-src-dir) $(OUT)/weblinks.itexi which translates as: mkdir -p out-website python /home/phil/lilypond-git/scripts/build/create-version-itexi.py /home/phil/lilypond-git out-website/version.itexi python /home/phil/lilypond-git/scripts/build/create-weblinks-itexi.py /home/phil/lilypond-git out-website/weblinks.itexi So, we make out-website then send the output of create-version-itexi.py to out-website/version.itexi and create-weblinks-itexi.py to out-website/weblinks.itexi. create-version-itexi.py parses the file VERSION in the top source dir. It contains:
Re: Creates convert-ly rules for flag syntax changes (issue 5050046)
Passes make and reg tests http://codereview.appspot.com/5050046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds StemTremolo to the note column's element list. (issue 5067041)
passes make, get some reg tests show up but nothing of note. See attached on http://code.google.com/p/lilypond/issues/detail?id=1922#c1 http://codereview.appspot.com/5067041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue 4808082)
Passes make and reg tests show as before see: http://code.google.com/p/lilypond/issues/detail?id=1855#c9 James http://codereview.appspot.com/4808082/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
Passes make, reg tests that get spewed out look identical, too many to attach but they are zipped here http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1846-td4837220.html http://codereview.appspot.com/4917046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)
passes make and reg tests http://codereview.appspot.com/5096050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
This patch no longer applies to current tree (as of 24th Sept) http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily/bezier.cc: Avoid a floating point compare (issue 5121042)
passes make and reg tests http://codereview.appspot.com/5121042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
Passes make but there are a few reg tests that someone should look at See http://code.google.com/p/lilypond/issues/detail?id=1844#c5 http://codereview.appspot.com/4961041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Several fixes for annotate-spacing. (issue 4950071)
Passes make and reg tests http://codereview.appspot.com/4950071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for fix of issue 307 (issue 4813048)
passes make and reg tests http://codereview.appspot.com/4813048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New partcombineUp and partcombineDown functions (issue 4514042)
passes make and reg tests http://codereview.appspot.com/4514042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does lilypond 2.15.x support guile 2.0 yet?
On Fri, Sep 23, 2011 at 03:53:56PM +0200, Dave Plater wrote: If all else fails maybe I can use the release candidate of lilypond for openSUSE 12.1 and update to 2.16.0 before release. There is absolutely zero chance of lilypond 2.16 using guile 2.0. There is maybe a 10% chance that any version of lilypond will support guile 2.0 in 2011. Total guesswork for future predictions: 50% chance of supporting guile 2.0 before July 2012, 80% chance of support guile 2.0 before the end of 2012. What that means for opensuse is up to you. If you particularly want guile 2.0, then by all means jump in; the more people working on it, the higher the chances are that it'll get done sooner. But based on the amount of work that currently goes into guile 2.0, those are my estimates. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR Context Layout Order rewrite (5.1.7) - tracker 1812 (issue 4839061)
Reviewers: Trevor Daniels, Message: On 2011/08/10 22:32:13, Trevor Daniels wrote: James My suggestion was to remove the *material* in 5.1.7 and replace it with material from 5.4.3, removing 5.4.3 as a section. The reference at the end of the material from 5.4.3 will need to be removed. Also, following Neil's reminder, we need to expand the documentation of the use of \accepts in 5.1.7 too, using his neat example. Trevor I've done an initial patch and know it still needs more work but I need some guidance and suggestions as this is something I know little about technically Description: Doc: NR remove 5.1.7 Tracker issue 1812 Removed 5.1.7 as it was felt that this was already explaind in 5.1.6 the use of \accepts and \denies is now only required when creating new contexts. Please review this at http://codereview.appspot.com/4839061/ Affected files: M Documentation/notation/changing-defaults.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR Context Layout Order rewrite (5.1.7) - tracker 1812 (issue 4839061)
James
Looks pretty good. I've made a couple of suggested additions. Could
you please make a new patch with these changes in, and then I'll give it
a more careful check over.
Trevor
http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode935
Documentation/notation/changing-defaults.itely:935: @cindex contexts,
layout order
@funindex \accepts
@funindex \denies
http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode954
Documentation/notation/changing-defaults.itely:954: To places chord
names on a stave e.g.,
Replace the previous two paras with:
The @qq{accepts} list of a context can be changed with the
@code{\accepts} and @code{\denies} commands. @code{\accepts} adds a
context to the @qq{accepts} list and @code{\denies} removes a context
from the list. For example, it would not normally be desirable for
chord names to be nested within a @{Staff} context, so the
@code{ChordNames} context is not included by default in the @qq{accepts}
list of the @code{Staff} context, but if this were to be required it can
be done:
http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode964
Documentation/notation/changing-defaults.itely:964:
Add here:
@code{\denies} is mainly used when a new context is being based on
another, but the required nesting differs. For example, the
@code{VaticanaStaff} context is based on the @code{Staff} context, but
with the @code{VaticanaVoice} context substituted for the @code{Voice}
context in the @qq{accepts} list.
http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode967
Documentation/notation/changing-defaults.itely:967: @rprogram{An extra
staff appears}.
Add:
Installed Files:
@file{ly/engraver-init.ly}.
http://codereview.appspot.com/4839061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
Pushed as 5aac8e8d8e2b1fc490354cba2cdecd204e9d5006 http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser.yy: allow composite_music to also consist of a MUSIC_IDENTIFIER. (issue 5090045)
Pushed as 049021415e2af3a48b1ec6d724df3d2f1d9f7dd3 http://codereview.appspot.com/5090045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
parser.yy et al: Make \relative a music function. (issue 5123043)
Reviewers: ,
Message:
This is a rather straightforward patch to take \relative out of the
grammar and let it be implemented as a music function.
I have copied some code from parser.yy straight to music-scheme.cc to
make ly:make-music-relative!. This code keeps the original indentation
so that git blame -C will recognize its origin. If desired, the
indentation can be fixed with a separate commit instead.
I have not touched the lily_1_8_relative wart when working on this. So
there are a few likely changes offering themselves, but it seems to be
cleaner to me if they are in a separate commit.
One surprise was that I got 18 additional shift/reduce conflicts when
removing \relative that needed to get fixed by augmenting the operator
list.
This suggests that it might be possible to introduce some artificial
terminal symbols and corresponding rules (taking the old place of
RELATIVE and more in the grammar) not actually produced by the lexer to
cut down on the number of symbols needing operator priorities.
Interesting.
Regtests pass with good visuals on my system (I think), so I am pushing
this to dev/staging. It seems like a reasonably solid change to me, and
in good shape. Since there will be almost no documents not going
through the new code paths, it should move to master only after a full
check including DOC builds on clean systems.
Description:
parser.yy et al: Make \relative a music function.
Please review this at http://codereview.appspot.com/5123043/
Affected files:
M lily/lily-lexer.cc
M lily/music-scheme.cc
M lily/parser.yy
M ly/music-functions-init.ly
Index: lily/lily-lexer.cc
diff --git a/lily/lily-lexer.cc b/lily/lily-lexer.cc
index
f80ea67703010594d088202f86e12702d27879c8..6c1336744b3286f6e2f0ca21d13ad8c5d4a508ca
100644
--- a/lily/lily-lexer.cc
+++ b/lily/lily-lexer.cc
@@ -75,7 +75,6 @@ static Keyword_ent the_key_tab[]
{once, ONCE},
{override, OVERRIDE},
{paper, PAPER},
- {relative, RELATIVE},
{remove, REMOVE},
{repeat, REPEAT},
{rest, REST},
Index: lily/music-scheme.cc
diff --git a/lily/music-scheme.cc b/lily/music-scheme.cc
index
89c810a5679df344d5ab41ee8f4f70c2b9dbfd81..34545fa911d33da5293c4c656e2342da1d4ad329
100644
--- a/lily/music-scheme.cc
+++ b/lily/music-scheme.cc
@@ -20,6 +20,7 @@
#include music.hh
#include duration.hh
+#include program-option.hh
#include warn.hh
LY_DEFINE (ly_music_length, ly:music-length,
@@ -158,6 +159,24 @@ LY_DEFINE (ly_music_compress, ly:music-compress,
return sc-self_scm ();
}
+LY_DEFINE (ly_make_music_relative_x, ly:make-music-relative!,
+ 2, 0, 0, (SCM music, SCM pitch),
+ Make @var{music} relative to @var{pitch},
+ return final pitch.)
+{
+ LY_ASSERT_TYPE (unsmob_music, music, 1);
+ LY_ASSERT_TYPE (unsmob_pitch, pitch, 2);
+
+ Pitch start = *unsmob_pitch (pitch);
+ Music *m = unsmob_music (music);
+ Pitch last = m-to_relative_octave (start);
+ if (lily_1_8_relative)
+ m-set_property (last-pitch, last.smobbed_copy ());
+
+ return last.smobbed_copy ();
+}
+
+
LY_DEFINE (ly_music_duration_length, ly:music-duration-length, 1, 0, 0,
(SCM mus),
Extract the duration field from @var{mus} and return the
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index
4714f67326d9595728c8d7fe798483a2f297a19d..b0a584ff91e93fd71465659a7d181c7321093bce
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -62,6 +62,8 @@ or
PITCH_IDENTIFIER NOTENAME_PITCH TONICNAME_PITCH
SCM_FUNCTION SCM_IDENTIFIER SCM_TOKEN
UNSIGNED DURATION_IDENTIFIER
+ CHORDMODE CHORDS DRUMMODE DRUMS FIGUREMODE FIGURES LYRICMODE LYRICS
+ NOTEMODE
/* The above are the symbols that can start function arguments */
@@ -107,10 +109,8 @@ using namespace std;
#include main.hh
#include misc.hh
#include music.hh
-#include music.hh
#include output-def.hh
#include paper-book.hh
-#include program-option.hh
#include scm-hash.hh
#include score.hh
#include text-interface.hh
@@ -156,7 +156,6 @@ SCM get_next_unique_lyrics_context_id ();
static Music *make_music_with_input (SCM name, Input where);
-SCM make_music_relative (Pitch start, SCM music, Input loc);
SCM run_music_function (Lily_parser *parser, Input loc, SCM func, SCM
args);
SCM check_scheme_arg (Lily_parser *parser, Input loc, SCM fallback,
SCM arg, SCM args, SCM pred);
@@ -217,7 +216,6 @@ void set_music_properties (Music *p, SCM a);
%token ONCE \\once
%token OVERRIDE \\override
%token PAPER \\paper
-%token RELATIVE \\relative
%token REMOVE \\remove
%token REPEAT \\repeat
%token REST \\rest
@@ -370,7 +368,6 @@ If we give names, Bison complains.
%type scm post_event
%type scm post_event_nofinger
%type scm re_rhythmed_music
-%type scm relative_music
%type scm simple_element
%type scm simple_music_property_def
%type scm start_symbol
@@ -385,7 +382,6 @@ If we give names, Bison complains.
%type scm
Re: parser.yy et al: Make \relative a music function. (issue 5123043)
Pushed as db3e78a1d3ac62dff61e80a3f0ccf60009f535ed to /dev/staging http://codereview.appspot.com/5123043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Fri, Sep 23, 2011 at 07:08:26PM +0200, olafbuddenha...@gmx.net wrote: Hi, On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. I know it's been used in loads of projects and is much loved, but actually, from a design perspective, it's appalling. I don't understand why so many people think it is... The Make language as it stands does have some quirks, but I like the fundamental concept. That's like saying java has some quirks, but I like the fundamental concept of architecture-independent interpreted code and just-in-time compilers. There's an order of magnitude between ease of programming in python and java. But of course that's mostly irrelevant anyways when using a Makefile generator such as Autotools... Phil was using the term make to refer to our stepmake system, which is on top of autotools, which (of course) is on top of actual make(1). Yes, this is technically incorrect, but I think that's a relatively small nit to pick. If I was writing a make system from scratch, I would describe dependencies in data structures that are viewable and editable, and have a separate program that uses those structures to determine which files need making. I'm not sure why you need extra structures for that? For C/C++, gcc can figure out the dependencies as a side effect of compiling the normal source code; and this can be done for most other languages as well. Very few non-trivial programs actually maintain their dependencies by hand nowadays... That's a great comfort for our lilypond texinfo documentation, which *does* require explicit dependencies. As far as I know, every single build system has trivially easy support for C/C++ compilation. That's not an issue. The issue is building documentation, building swig python modules (for me personally, not lilypond), generating translations, generating test cases and automatically showing potential problems, etc. According to find . -name *.make -or -name GNUmakefile* | xargs cat | wc -l we have 5059 lines of build-system stuff. Actually, that's not counting python helper scripts: wc scripts/build/*.py -l 4113 total So... 9171 lines of build-system junk. I think this meme is appropriate: It's over NINE THOUSAND!!! This didn't happen for fun and giggles. Over the years, we've built up hack upon hack, and ended up with this unholy mess. Is that purely the fault of autotools? No. Could it be *worse* if we used a different build system? Sure. But it could also be *better* if we used a different build system. I've done 5 minutes research and have found SCons. I've not gone into any more depth with that yet. Does it seem worth looking into this, or something else, in more detail? I don't know about SCons, but at least the often-proposed Cmake is *not* a Make replacement. It's a Makefile generator, just like Autotools. Yes, but it's still a different *build system*. Our interaction with the build system would take the form of CMakeLists.txt files. Would that interaction result in a more maintainable system, i.e. one which does not have a powerlevel of OVER 9000? Probably yes. What's uncertain is how much work would be involved in switching to that (or any other) build system, vs. how much better that would make matters, Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival gra...@percival-music.ca wrote: If I was writing a make system from scratch, I would describe dependencies in data structures that are viewable and editable, and have a separate program that uses those structures to determine which files need making. I'm not sure why you need extra structures for that? For C/C++, gcc can figure out the dependencies as a side effect of compiling the normal source code; and this can be done for most other languages as well. Very few non-trivial programs actually maintain their dependencies by hand nowadays... That's a great comfort for our lilypond texinfo documentation, which *does* require explicit dependencies. As far as I know, every single build system has trivially easy support for C/C++ compilation. That's not an issue. The issue is building documentation, building swig python modules (for me personally, not lilypond), generating translations, generating test cases and automatically showing potential problems, etc. According to find . -name *.make -or -name GNUmakefile* | xargs cat | wc -l we have 5059 lines of build-system stuff. Actually, that's not counting python helper scripts: wc scripts/build/*.py -l 4113 total So... 9171 lines of build-system junk. I think this meme is appropriate: It's over NINE THOUSAND!!! This didn't happen for fun and giggles. Over the years, we've built up hack upon hack, and ended up with this unholy mess. Is that purely the fault of autotools? No. Could it be *worse* if we used a different build system? Sure. But it could also be *better* if we used a different build system. You sound spoiled. * The build scripts are not really part of the complexity of the build system. They are normal programs, they are just not intended to be run by end users. I assume you are not considering a rewrite of output-distance.py in CMake's scripting language. * You make 5000 lines of makefile sound as if it is a lot. I think you should look at other packages' build systems more closely. For example, coreutils, which is 70k lines of C, and a trivial documtentation and test process has, count'dem: 2000 lines of Makefile.am. This is for just linking together a bunch of bog-standard C object files, generating an info page, and running some shell scripts as tests. I think 5k lines is pretty impressive for a package as complex as LilyPond, considering that it has a bizarre documentation process, translated docs, python bindings, fonts that are run through metapost and fontforge, a complex regression test, and needs weird acrobatics to find its gazilion different init files. -- 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: Moving away from make
On Sat, Sep 24, 2011 at 10:41:05PM -0300, Han-Wen Nienhuys wrote: On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival gra...@percival-music.ca wrote: This didn't happen for fun and giggles. Over the years, we've built up hack upon hack, and ended up with this unholy mess. You sound spoiled. Why, because I think it's not perfect? How many discussions, how many developer-hours, have we spend talking about build problems on this list? How much frustration and wasted time/goodwill have we spent on those problems? Despite that, I'm not advocating a move away from make; it would take us about 200 hours to reach merely the current level of build system-ness. There are far more important things to work on -- but I'm not going to pretend that the status quo is great, nor do I think it's silly to ask about switching to a different system. I will admit there is one aspect in which I *am* spoiled, though: I am totally spoiled by python's readable code. I am so accustomed to writing stuff like cmd = compiler + ' -o ' + exe_name + src_files or cmd = %(compiler)s -o %(exe_name)s %(src_files) % locals() that I find stuff like $(CC) -o $@ $ silly. The readability for casual contributors -- which is what most people looking at build system stuff are -- is ridiculously better in python than anything else. * The build scripts are not really part of the complexity of the build system. They are normal programs, they are just not intended to be run by end users. I assume you are not considering a rewrite of output-distance.py in CMake's scripting language. True. OTOH, there is certainly complexity in there that we don't need -- AFAIK we don't use bib2html.pl any more; we instead ose bib2texi.py. So we could remove the perl file from the GNUmakefiles, and even remove the script entirely from our source tree. It's stuff like that which bugs me. Some time down the road, somebody will be trying to fix some bug in the bibliography, and they'll spend hours looking at bib2html and the files it produces, before finally discovering that it's not actually used. * You make 5000 lines of makefile sound as if it is a lot. I think you should look at other packages' build systems more closely. For example, coreutils, which is 70k lines of C, and a trivial documtentation and test process has, count'dem: 2000 lines of Makefile.am. This is for just linking together a bunch of bog-standard C object files, generating an info page, and running some shell scripts as tests. Wow. That's insane. I think 5k lines is pretty impressive for a package as complex as LilyPond, considering that it has a bizarre documentation process, translated docs, python bindings, fonts that are run through metapost and fontforge, a complex regression test, and needs weird acrobatics to find its gazilion different init files. It's certainly impressive, and it could definitely be worse. But it's not easy to maintain. At least, it's not easy to maintain for casual developers like me. I'd be overjoyed if somebody non-spoiled and non-stupid (i.e. not me) offered to step forward and fix the known problems with the build system. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Sun, Sep 25, 2011 at 03:12:14AM +0100, Graham Percival wrote: On Sat, Sep 24, 2011 at 10:41:05PM -0300, Han-Wen Nienhuys wrote: You sound spoiled. On second thought, I really *am* spoiled: I don't want to even notice the build system. I view it in the same way I view food: a waste of time that's unfortunately necessary for survival. I mean, food is a pain. You need to leave the house/university to buy it, you need to carry it home, you need to cook (or otherwise prepare) it, then eat it, then wash the dishes, and occasionally empty the garbage depending on what you were preparing. Now, with frozen lazagna the cooking+washing isn't so bad (since you can eat it out the dish; you only need to wash one fork). But if you eat nothing but microwaved food, you get sick. Trust me, I've tried. Life would be so much easier if/when they have some kind of grey mush that provides all nutrients you need! That's what I want from a build system. I want a grey mush that just works. No problems, no confusion, no work required to maintain it. I want to spend time improving documentation or fixing bugs in graphical output or adding new features! Unfortunately that's not possible, so I'm hoping for the next best thing: to have a build system which requires the least amount of work, while still providing the most robust environment with the least amount of confusion for developers. Now, I suppose that since I have such hostility for build systems, I really shouldn't be involved in discussing them -- I should leave it up to people who enjoy dealing with their crap. Unfortunately, just like the kitchen garbage in my shared apartment, if I don't clean up the garbage from time to time, nobody else does. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
On Sep 24, 2011, at 9:31 PM, pkx1...@gmail.com wrote: Passes make, reg tests that get spewed out look identical, too many to attach but they are zipped here http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1846-td4837220.html http://codereview.appspot.com/4917046/ Just so you all know, the changes show up because SpanBar no longer has a Y-extent in this patch. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
On Sep 24, 2011, at 9:57 PM, pkx1...@gmail.com wrote: Passes make but there are a few reg tests that someone should look at See http://code.google.com/p/lilypond/issues/detail?id=1844#c5 The only thing that I'm not sure about is beam-slope-stemlet.ly. What do people think of this compared to the old version? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds StemTremolo to the note column's element list. (issue 5067041)
On 2011/09/19 18:48:17, mike_apollinemike.com wrote: What I'd really like to know is why the spring ideal and minimum distances are different just by virtue of its belonging to the array, but I have a feeling the answer lies deep in the bowels of the horizontal spacing code and I don't have time to get to the bottom of that in the foreseeable future. I doubt anyone can remember this faster than you can figure it out. Note_spacing::get_spacing() uses the horizontal skylines of the NoteColumns to set the spring lengths. Spacing_interface::skylines() sets these skylines using the elements... somehow. Probably the elements' extents are the boxes over which the skyline is draped (or rather, shrink-wrapped since it is the skyline for horizontal spacing). http://codereview.appspot.com/5067041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
