Re: [PATCH] GUB: fix cross/gcc for darwin-x86
Op maandag 02-11-2009 om 13:29 uur [tijdzone -0800], schreef Patrick McCarty: > I've tried doing `sh -x ./fixinc.sh', but that didn't reveal any > clues. > > I suppose I'll try doing a `sh -x ./fixinc.sh' with > freebsd-x86::cross/gcc, which uses gcc 4.3.2 too (and is succeeding). > Comparing the logs might provide some hints. That's something like what I would do. You can also try doing bash -x and compare the log with sh -x. And beware of LIBRESTRICT errors of course, those can have nasty effects -- esp. in "languages" like sh or perl that just continue upon an error. > Are there any other ways to debug this issue besides shell tracing? Is fixinc.sh being generated? Greetings, Jan. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: Tracker 836: Add facility to change output file-name for a \book block
On 2009-11-03, Ian Hulin wrote: > Hi all, > I've installed emacs and checked the indenting as per Carl and Neils > recommendations. Patch set has been on rietveld 143055 for some > days. > > Is this ready to push now? Hi Ian, The indentation in lily-library.scm is still very weird in several spots. I'll point some of them out on Rietveld. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 872 in lilypond: Changes split-page has broken images
On Tue, Nov 03, 2009 at 08:52:30PM +0100, John Mandereau wrote: > Le mardi 03 novembre 2009 à 19:21 +, Graham Percival a écrit : > > Evidently this issue was "too trivial", so I'll bear that in mind > > when considering future additions. > > Ah, thanks :-) Before raising such an issue in the future, may I > suggest you bug me with CC to -devel? Sure! At the time, I thought you were completely engrossed in sorting out your move, and I didn't want to bother you. > I mean, I'm not expecting you to > master all of postprocess_html.py and other stuff like this, you have > much more important things to do. Yes and no. My stated aim is that my job is to let everybody else do their jobs. If the doc people (kind-of not counting myself) want new manuals, I'll do that. If the font people want updated packages in GUB, I'll do that. For that matter, if anybody wants releases, I'll do that. If somebody else is willing to poke around in postprocess_html.py, I will gladly not attempt to learn what's happening... but if nobody else is doing it, I'll buckle down and figure it out. > > If there's a strong argument against using the Issue tracker for > > all sorts of development issues, I don't mind reserving it for > > purely bugs... but then how should we keep track of problems in > > GUB, the build system, translation infrastructure, etc? > > On the wiki ;-) I have no special strong argument, the little argument > I have is that comments on Google Code issues are turned into emails > with horrible indentation. Why don't we just agree that any substantial discussion (more than 2 or 3 sentences) should be on the mailist? Once the discussion has ended, we can add a link to the archives on the tracker so it doesn't get lost. > > It explains that there's "special processing, so it can be used on > > a website with content negotiation for automatic language > > selection", but it's not clear to me why we don't make *all* the > > HTML docs "online". > > Why do you mean by "making *all* the HTML docs online"? > Are you aware that we do need an offline and a online target as long as > the website uses the automatic language selection we currently have and > we want to distribute a docball? Or do you mean we should always build > both offline and online targets? I'm not aware that we need an offline target. If that's used for the docball, why not build that from the online target? This isn't rhetoric; I really honestly do not know what the point is for having an "offline" doc target. What do we lose if we only have the "online" doc target? > > But if the lilypond docs place bugs.html under general/bugs.html, > > then we need to do extra work to strip that out. > > We'll need such extra work anyway for the online target () if we keep a > directory scheme like I'm not convinced about this, but let's discuss it again in a few weeks when it becomes relevant. > > In that case, I think I'll keep on muddling with the old build > > system when necessary. > > I frankly don't recommend you to spend time on it, OTOH I concede that > it's sometimes necessary :-( Well, off the top of my head, the only thing that's left before declaring the build system side of the new website "finished" is fixing the image links in changes.tely. So... 15 minutes (?) of work for you to modify postprocess_html.py, 60 minutes (?) for me to understand and then modify postprocess_html.py... or 5-10 weeks to get the new doc build system ready? At this stage, I really want to be finishing projects and getting 2.14 ready, so I think it makes sense to work on the old build system. (I consider postprocess.py part of the build system) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracker 836: Add facility to change output file-name for a \book block
http://codereview.appspot.com/143055 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracker 836: Add facility to change output file-name for a \book block
http://codereview.appspot.com/143055/diff/19/1020 File scm/lily-library.scm (right): http://codereview.appspot.com/143055/diff/19/1020#newcode99 Line 99: (for-each (lambda (symbol) I would recommend indenting like so: (for-each (lambda (symbol) (let ((.. http://codereview.appspot.com/143055/diff/19/1020#newcode142 Line 142: (if (not book-filename) The if block should be indented two more spaces here. http://codereview.appspot.com/143055/diff/19/1020#newcode143 Line 143: (ly:parser-output-name parser) These two lines should begin in the same column as (not ...) http://codereview.appspot.com/143055/diff/19/1020#newcode149 Line 149: (let ((book-output-suffix (ly:parser-lookup parser 'book-output-suffix))) indent the if block http://codereview.appspot.com/143055/diff/19/1020#newcode151 Line 151: (ly:parser-lookup parser 'output-suffix) align these with (not ...) http://codereview.appspot.com/143055 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracker 836: Add facility to change output file-name for a \book block
http://codereview.appspot.com/143055/diff/19/1020 File scm/lily-library.scm (right): http://codereview.appspot.com/143055/diff/19/1020#newcode99 Line 99: (for-each (lambda (symbol) I would recommend indenting like so: (for-each (lambda (symbol) (let ((.. http://codereview.appspot.com/143055/diff/19/1020#newcode142 Line 142: (if (not book-filename) The if block should be indented two more spaces here. http://codereview.appspot.com/143055/diff/19/1020#newcode143 Line 143: (ly:parser-output-name parser) These two lines should begin in the same column as (not ...) http://codereview.appspot.com/143055/diff/19/1020#newcode149 Line 149: (let ((book-output-suffix (ly:parser-lookup parser 'book-output-suffix))) indent the if block http://codereview.appspot.com/143055/diff/19/1020#newcode151 Line 151: (ly:parser-lookup parser 'output-suffix) align these with (not ...) http://codereview.appspot.com/143055 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 872 in lilypond: Changes split-page has broken images
Hi guys, I forgot to reply to -devel too, so I include at least all of Graham's reply. Le mardi 03 novembre 2009 à 19:21 +, Graham Percival a écrit : > On Fri, Oct 30, 2009 at 07:18:50PM +0100, John Mandereau wrote: > > The problem is, we might end up creating many issues for trivial > > building problems, which would surely clutter issues with LilyPond > > programs, and in our current situation for a build system that may die > > soon. > > I still don't see the problem. Searching for Type-Defect or > Type-Enhancement (or just "label:not-maintainability") is easy > enough. I agree that we don't want many issues for trivial > building problems, but I think we can rely on developers to use > their own judgement as to what's trivial or not. > > Evidently this issue was "too trivial", so I'll bear that in mind > when considering future additions. Ah, thanks :-) Before raising such an issue in the future, may I suggest you bug me with CC to -devel? I mean, I'm not expecting you to master all of postprocess_html.py and other stuff like this, you have much more important things to do. > Why not? I mean, they're called "issues" and not "bugs". We even > have labels for Type-Other and maintainability. You're right. > If there's a strong argument against using the Issue tracker for > all sorts of development issues, I don't mind reserving it for > purely bugs... but then how should we keep track of problems in > GUB, the build system, translation infrastructure, etc? On the wiki ;-) I have no special strong argument, the little argument I have is that comments on Google Code issues are turned into emails with horrible indentation. > > Speaking of, doesn't ROADMAP already say this? > > Oops. I never look at that file. I guess I should include it in > the CG. Agreed. > It explains that there's "special processing, so it can be used on > a website with content negotiation for automatic language > selection", but it's not clear to me why we don't make *all* the > HTML docs "online". Why do you mean by "making *all* the HTML docs online"? Are you aware that we do need an offline and a online target as long as the website uses the automatic language selection we currently have and we want to distribute a docball? Or do you mean we should always build both offline and online targets? > If it adds less than 10 minutes to the total > processing time, I'd say go for it. It mostly depends on the speed of your hard disk and the amount of output HTML files that are still in the cache in RAM. > But if the lilypond docs place bugs.html under general/bugs.html, > then we need to do extra work to strip that out. We'll need such extra work anyway for the online target () if we keep a directory scheme like web/ doc/vx.y or / (website) /doc/vx.y I don't suggest putting both the website and docs in the same directory, as this would break a few more links (this is easily fixed with .htaccess-like stuff, as you pointed out below), and more importantly this would add a discrepancy between URLs of the last stable docs -- e.g. /(web/)notation/ -- and URLs of doc for other branches -- e.g. /doc/vx.y/notation. > > I guess there will be no particular difficulty doing > > so, but this might break more old pages URLs than putting the new > > website in web/. > > We have url forwarding (or whatever the technical name is) in > .htaccess, so this shouldn't be a problem. Sure, agreed. > > I've done few math work and much bureaucratic work, but this should > > change in November. A waf-based build system could be developed much > > quicker (more than twice faster) with two people on it; we'd have been > > two on switching to SCons if I accepted to switch to this build system, > > but because of its slowness I don't want to go for it. As I'm alone to > > work on it, my motivation for this is down too easily to enable me > > giving any timeframe. > > In that case, I think I'll keep on muddling with the old build > system when necessary. I frankly don't recommend you to spend time on it, OTOH I concede that it's sometimes necessary :-( > I mean, we could try asking for volunteers > to help you, but this stuff is probably sufficiently technical > that any random volunteers from -user would slow you down rather > than help. Exactly. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: Tracker 836: Add facility to change output file-name for a \book block
Hi all, I've installed emacs and checked the indenting as per Carl and Neils recommendations. Patch set has been on rietveld 143055 for some days. Is this ready to push now? Cheers, Ian Carl Sorensen wrote: On 10/29/09 6:10 PM, "Graham Percival" wrote: On Thu, Oct 29, 2009 at 06:00:06PM -0600, Carl Sorensen wrote: On 10/29/09 3:14 PM, "n.putt...@gmail.com" wrote: I'd suggest installing emacs to sort out the indentation (even if you prefer to use another editor for your main work), otherwise we're going to spend ages pointing out every little nitpick when we should be focusing on the code. vim also does a decent job of indenting scheme code, and automatically strips trailing whitespace if you set it to. Yes, but the official lilypond formatting is "whatever emacs does, plus one or two other scripts to tweak a few more things". vim's scheme code indenting is the same as "whatever emacs does". Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracker 836: Add facility to change output file-name for a \book block
http://codereview.appspot.com/143055 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracker 836: Add facility to change output file-name for a \book block
Ian, I found some indentation errors in the .ly file. Thanks for your patience, Carl http://codereview.appspot.com/143055/diff/19/1019 File ly/music-functions-init.ly (right): http://codereview.appspot.com/143055/diff/19/1019#newcode616 Line 616: (let* ( (get-notes (lambda (ev-chord) eliminate space between ( (, and align the following lines http://codereview.appspot.com/143055/diff/19/1019#newcode626 Line 626: (let*( (trill-pitch (ly:music-property (car sec-note-events) 'pitch)) space after let*, no space before (trill-pitch http://codereview.appspot.com/143055/diff/19/1019#newcode628 Line 628: 'force-accidental))) This alignment isn't right. 'force-accidental should align with (car http://codereview.appspot.com/143055/diff/19/1019#newcode630 Line 630: (if (ly:pitch? trill-pitch) (if should align with e in let* http://codereview.appspot.com/143055/diff/19/1019#newcode632 Line 632: (ly:music-set-property! m 'pitch trill-pitch)) trill-events) should be indented relative to lambda http://codereview.appspot.com/143055/diff/19/1019#newcode638 Line 638: (for-each (lambda (m) align with (eq? http://codereview.appspot.com/143055/diff/19/1019#newcode639 Line 639: (ly:music-set-property! m 'force-accidental forced)) align with (eq? http://codereview.appspot.com/143055 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
