Re: Catching up on bugs
On 24.12.2009, at 23:57, Joe Neeman wrote: profile-property-access.ly errors and fails when I try to compile it. Additionally, the properties shown in the output are all 0 You need to configure with --disable-optimising in order for property access profiling to work. Okay, since I can't compile lilypond, can someone else just have a quick look at this? And thanks Joe! Cheers, Joe James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Catching up on bugs
On Fri, Dec 25, 2009 at 12:25 AM, James Bailey derhindem...@googlemail.com wrote: On 24.12.2009, at 23:57, Joe Neeman wrote: profile-property-access.ly errors and fails when I try to compile it. Additionally, the properties shown in the output are all 0 You need to configure with --disable-optimising in order for property access profiling to work. Okay, since I can't compile lilypond, can someone else just have a quick look at this? I can confirm that it works with --disable-optimising. See the attached log. Thanks, Patrick GNU LilyPond 2.13.10 Processing `profile-property-access.ly' Parsing... Interpreting music... [8] Preprocessing graphical objects... Interpreting music... MIDI output to `profile-property-access.midi'... Solving 1 page-breaking chunks...[1: 1 pages] Drawing systems... Layout output to `profile-property-access.ps'... Converting to `./profile-property-access.pdf'... prob properties, top 50 rounded to 10 TOTAL : 40780 length: 8160 elements : 6430 element : 5620 class : 3180 origin: 1520 duration : 1510 name : 1290 types : 1210 pitch : 1100 articulations : 1050 iterator-ctor :930 error-found :750 quoted-events :750 quoted-music-name :750 length-callback :610 start-callback:610 to-relative-callback :560 symbol:520 events:400 once :330 parenthesize :260 moment:230 text :230 value :230 tweaks:210 grob-property :180 grob-property-path:180 absolute-octave :150 cautionary:150 force-accidental :150 property-path :150 grob-value:120 pop-first :120 span-direction:110 context-id: 90 context-type : 90 create-new: 90 descend-only : 90 property-operations : 90 elements-callback : 80 paper-book: 60 type : 60 context : 50 is-bookpart-last-page : 40 is-last-bookpart : 40 page-number : 40 direction : 30 id: 30 ops : 30 context properties, top 50 rounded to 10 TOTAL : 60920 measurePosition : 5200 whichBar : 3820 busyGrobs : 2750 currentCommandColumn : 2280 fontSize : 2140 tieWaitForNote: 2050 associatedVoice : 1930 timeSignatureFraction : 1800 measureLength : 1420 midiInstrument: 1330 shortVocalName: 1330 vocalName : 1330 autoBeaming : 1150 instrumentCueName : 1140 staffLineLayoutFunction : 1140 keySignature : 1130 localKeySignature : 1110 beamSettings : 1100 beatLength: 1100 internalBarNumber : 1100 autoBeamCheck : 1070 hasStaffSpacing :990 forceClef :860 ottavation:860 Stem :830 melismaBusy :820 NoteColumn:760 NoteHead :740 shapeNoteStyles :710 NoteSpacing :700 stemLeftBeamCount :700 stemRightBeamCount:700 middleCPosition :680 Beam :640 melismaBusyProperties :620 instrumentTransposition :600 clefOctavation:570 completionBusy:500 subdivideBeams:480 instrumentName:470 shortInstrumentName :470 ignoreMelismata :460 clefGlyph :440 clefPosition :440 skipTypesetting :390 keepAliveInterfaces :310 skipBars :310 timing:310 repeatCommands:280 grob properties, top 50 rounded to 10 TOTAL : 309760 staff-affinity
Re: lilypond-book is hosed
Le jeudi 24 décembre 2009 à 20:52 +, Graham Percival a écrit : I can now confirm that the regtest comparison is done on the files in input/regression/out-test/ , which are created via make test. More precisely, the comparison is done between input/regression/out-test/ and input/regression/out-test-baseline/ IIRC. If the files in those directories had names corresponding to their actual regtest file names, then the regtest comparisons would be more robust against changing lilypond-book options. I'm not certain whether this would be best achieved by adding a special option to lilypond-book (--use-original-filename ?) Yes, but only for 'make test-baseline' and 'make check'. Unless there is any brilliant idea, I'll go for implementing this. Best and merry Xmas, 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: lilypond-book is hosed
Le jeudi 24 décembre 2009 à 19:30 +, Graham Percival a écrit : Ah, we're talking about two different kinds of hashes. One hash decides if the snippet should be (re)processed -- I don't care about that one. Do whatever seems sensible for that. The other kind of hashing produces the lily-.ly filename based on the contents. *That's* the kind that we (intentionally) changed to be independent of snippet options, in order to have the same filename produced for regtests with different options. That change seems to have disturbed the first kind of hashing, though. ** edit: rather, there are two *goals* of hashing in lilypond-book. Technically, they seem to be generated via the same mechanism, which is the cause of this whole problem. But we avoid that problem by using the regtest filenames, so that's fine. This makes no sense. Between two lilypond-book invocations, hashes are not stored in any other place than in the filenames, so if lilypond-book has to decide whether to rebuild a snippet, it can only do this by comparing the computed hash to the hash in a filename, so there is no way that filenames hashes should be generated with another hashing mechanism, unless you store the actual hashes in some database. Doesn't input/regression/out-www/ use out/lybook-db ? Yes, lilypond-book hardlinks output files from the second directory to the first one. The bottom line is this: I'd like a regtest processed with one set of options to have the same filename as that same regtest processed with another set of options. I don't care what you do to either set of hashes, as long as that goal is met. :) This goal makes sense only for test-baseline and check targets, right? (see my final comment below) Whatever happens, I'll need to generate a new set of 2.13.9 regtests with the new filename-hashing (or regtest-filename-keeping) in order to compare them with the 2.13.10 regtests. OK. Sorry, I was only intending to propose this for the regtests, not the normal docs. For 'doc' target, normal docs and regtests share the same snippet database, so I'd rather not change filenames of regtests output when building this target. 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: New template for 'lilypond' made available
Le vendredi 25 décembre 2009 à 08:52 +0100, Erwin Poeze a écrit : Sorry, about this. It was done by me, the TP coordinator. I have the habit of checking for newer domain versions on an irregular base and noticed that the 2.13.7 was newer that the 2.13.3 version in the TP. Getting new versions in the TP is a sort of 'reminder' for translators that 'work needs be done', so I try to keep the flow of pot files going. Thank you, all this makes sense after you explain it. I will send you an update request with an updated POT when 2.13 branch is near to the Release Candidate state. Best regards and merry Christmas, John Mandereau 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: lilypond-book is hosed
Le jeudi 24 décembre 2009 à 10:18 -0800, Patrick McCarty a écrit : Thank you for noticing this, John. I'll admit I did not think through the issue carefully enough when I made that commit. I'm not qualified to comment on your patch to fix the issue, but I trust your judgment here. OK, so after careful checking of 'make doc' output I'll push my patch minus the diff printing hook, then I'll cook an option --use-original-filenames. 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: lilypond-book is hosed
Le jeudi 24 décembre 2009 à 22:21 +0100, Reinhold Kainhofer a écrit : I would definitely like that option. Every now and then, when working with lilypond-book based projects, I also need to send e.g. an image per mail or insert an image into some word-processing app. In these cases, such an option would be extremely helpful. I see. Note that this option will work only with snippets included with \lilypondfilename or snippets containing \renameinput. In the case of lily-output-dir option is set, I'd rather keep filenames using hashes and use the original filename only when linking to final output directory, though, so the idea of a shared snippet database to save processing time and space would still be possible. 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: @insertcopying
Le jeudi 24 décembre 2009 à 21:17 +, Graham Percival a écrit :
commit 6c1cdaa331972442a8fd62d98da5adebfaa9a17b
I thought that texinfo macros were supposed to have a {} after them --
I mean, it's not /required/ for arguments without any macros, but...?
..but see Texi2HTML warnings if @insertcopying{} is used.
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: New template for 'lilypond' made available
Best wishes to you and the development team as well! Op vrijdag 25-12-2009 om 11:13 uur [tijdzone +0100], schreef John Mandereau: Le vendredi 25 décembre 2009 à 08:52 +0100, Erwin Poeze a écrit : Sorry, about this. It was done by me, the TP coordinator. I have the habit of checking for newer domain versions on an irregular base and noticed that the 2.13.7 was newer that the 2.13.3 version in the TP. Getting new versions in the TP is a sort of 'reminder' for translators that 'work needs be done', so I try to keep the flow of pot files going. Thank you, all this makes sense after you explain it. I will send you an update request with an updated POT when 2.13 branch is near to the Release Candidate state. Best regards and merry Christmas, John Mandereau -- Best Regards, Erwin Poeze coordina...@translationproject.org Want to know what's going on in the TP? Follow us at www.twitter.com/translationproj ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
(not) factorizing xref macro definitions [was Re: [PATCH] Update announcement]
Le jeudi 10 décembre 2009 à 15:50 +, Graham Percival a écrit : Ok. Let's just agree to disagree: you think it's important, but I don't think it's important. If somebody (be it you or Denes) writes a patch, I'm willing to test it on GUB. I just tried factorizing French macro definitions using @ifXXX blocks, @set and @alias, but I got a stack overflow with TeX when attempting to generate the PDF manuals, so we won't do this until Texinfo is well-defined as a language with that much flexibility and reliability whatever the output format is. 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: @insertcopying
On Fri, Dec 25, 2009 at 11:22:21AM +0100, John Mandereau wrote:
Le jeudi 24 décembre 2009 à 21:17 +, Graham Percival a écrit :
commit 6c1cdaa331972442a8fd62d98da5adebfaa9a17b
I thought that texinfo macros were supposed to have a {} after them --
I mean, it's not /required/ for arguments without any macros, but...?
..but see Texi2HTML warnings if @insertcopying{} is used.
I know about those warnings. I've known about them for 6 months.
They seem to be harmless, so I've been waiting for somebody to
work on the build warnings (it's in the issue tracker) and send a
bug report to texi2html.
I guess that in this case, it doesn't really matter.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @insertcopying
Le vendredi 25 décembre 2009 à 14:29 +, Graham Percival a écrit :
..but see Texi2HTML warnings if @insertcopying{} is used.
I know about those warnings.
Then, why the mao do you waste our time with this thread? :-)
I guess that in this case, it doesn't really matter.
Indeed, this is just one warning less in the output, which I fixed
because I had sent Harmath all Texi2HTML warnings for one manual in
Hungarian.
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: @insertcopying
On Fri, Dec 25, 2009 at 03:54:06PM +0100, John Mandereau wrote:
Le vendredi 25 décembre 2009 à 14:29 +, Graham Percival a écrit :
..but see Texi2HTML warnings if @insertcopying{} is used.
I know about those warnings.
Then, why the mao do you waste our time with this thread? :-)
I was wondering if I was wrong about texinfo. It's been known to
happen.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @insertcopying
Le vendredi 25 décembre 2009 à 14:57 +, Graham Percival a écrit : I was wondering if I was wrong about texinfo. It's been known to happen. Texinfo is not a well-defined language, it's defined only by what the formatters support and to some extent by Texinfo manual, so it's practically impossible to know when you're wrong :-P If you want to be right, just convince Texinfo devs to implement what you want. 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: New LilyPond Spanish Users list at GNU
On Thu, Dec 24, 2009 at 12:55 AM, Carl Sorensen c_soren...@byu.edu wrote: On 12/23/09 5:37 PM, Francisco Vila paconet@gmail.com wrote: Ask the LilyPond mantainer to create the list in their project. So all we need to do is get Graham, Jan, or Han-Wen to add a list lilypond-es. I think we could get one of them to do that. Yes, this looks simple; type fr and Discussion list for Spanish users in two places, then click. But before we do this, I'd like to settle a few questions: 1) which languages get a mailing list? I mean, if somebody comes along and asks for an official swahili lilypond list, do we just add it? My tentative answer is that we could create an official language-specific list for any translation that finished the top-priority items (IIRC, the website + Learning 1 Tutorial). Thoughts? 2) lilypond-es vs. lilypond-user-fr. Francisco made a good argument for omitting the -user-, but since the lilypond-user-fr list already exists, I'm not so keen on making a new format for list names. Should we make all new languages just as lilypond-XY, and keep lilypond-user-fr for tradition's sake? Should we ask the -user-fr people to accept a name change to lilypond-fr ? Should we make all new languages in the form lilypond-user-XY ? Thoughts? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New LilyPond Spanish Users list at GNU
On Fri, Dec 25, 2009 at 10:04 PM, Graham Percival gra...@percival-music.ca wrote: But before we do this, I'd like to settle a few questions: Oops, I forgot to add 3) Given that there's some kind of problems with accents with savannah lists (I haven't grasped what it is, but read https://savannah.gnu.org/task/?9148 if you're interested), is it really good to have these non-English lists hosts on savannah? I admit that the name looks much more official, but if the software stops you from communicating in your native language, that's hardly a step up. Does the google group stuff allow non-English characters? We have an official google code project (mostly for the issue tracker), so we could add a few mailing lists attached to that project. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book is hosed
On Fri, Dec 25, 2009 at 11:02:03AM +0100, John Mandereau wrote: Le jeudi 24 décembre 2009 à 20:52 +, Graham Percival a écrit : I can now confirm that the regtest comparison is done on the files in input/regression/out-test/ , which are created via make test. More precisely, the comparison is done between input/regression/out-test/ and input/regression/out-test-baseline/ IIRC. That's make check. GUB compares tarballs generated from input/regression/out-test/ from two different iterations of make test. Yes, but only for 'make test-baseline' and 'make check'. Unless there is any brilliant idea, I'll go for implementing this. And make test. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book is hosed
On Fri, Dec 25, 2009 at 11:21:17AM +0100, John Mandereau wrote: Le jeudi 24 décembre 2009 à 22:21 +0100, Reinhold Kainhofer a écrit : I would definitely like that option. Every now and then, when working with lilypond-book based projects, I also need to send e.g. an image per mail or insert an image into some word-processing app. In these cases, such an option would be extremely helpful. I see. Note that this option will work only with snippets included with \lilypondfilename or snippets containing \renameinput. In the case of lily-output-dir option is set, I'd rather keep filenames using hashes and use the original filename only when linking to final output directory, though, so the idea of a shared snippet database to save processing time and space would still be possible. The regtests are not used in the docs. Period. It's possible that a new feature might a file in Documentation/snippets/new/ which is an exact copy of a new regtest (actually, I've encouraged this), but we don't have many of those examples, and I'd expect them to diverge anyway (as the regtest covers more cases, or the LSR-bound snippet gets better explanations, or whatever). I think that any saving of processing time would be measured in seconds counted on fingers, and the simplification of keeping the output from input/regressions/ would far outweigh that amount of time. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book is hosed
Le vendredi 25 décembre 2009 à 22:17 +, Graham Percival a écrit : The regtests are not used in the docs. Period. It's possible that a new feature might a file in Documentation/snippets/new/ which is an exact copy of a new regtest (actually, I've encouraged this), but we don't have many of those examples, and I'd expect them to diverge anyway (as the regtest covers more cases, or the LSR-bound snippet gets better explanations, or whatever). I think that any saving of processing time would be measured in seconds counted on fingers, and the simplification of keeping the output from input/regressions/ would far outweigh that amount of time. All this is perfectly right. However, my reply to Reinhold was about lilypond-book usage outside official docs and regtests building, so your remarks don't invalidate my preference for renaming generated snippets in the final output dir, and not in out/lybook-db (option --lily-output-dir in lilypond-book). 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: New LilyPond Spanish Users list at GNU
Le vendredi 25 décembre 2009 à 22:08 +, Graham Percival a écrit : 3) Given that there's some kind of problems with accents with savannah lists (I haven't grasped what it is, but read https://savannah.gnu.org/task/?9148 if you're interested), is it really good to have these non-English lists hosts on savannah? I admit that the name looks much more official, but if the software stops you from communicating in your native language, that's hardly a step up. Then the software should be fixed. The lack of proper UTF-8 support is really a pity in 2009 (2010 soon). Does the google group stuff allow non-English characters? We have an official google code project (mostly for the issue tracker), so we could add a few mailing lists attached to that project. I'd rather not attach too many things to google code project, for the sake of our independence, whereas LilyPond is already part of GNU. If there is no way to create a Spanish-speaking list with enough support for Spanish (actually UTF-8 encoding), we could ask Valentin to host the list on lilynet.net, but this doesn't sound like a proper solution for a list almost as big (in number of subscribers) as lilypond-user-fr. 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: New LilyPond Spanish Users list at GNU
Le vendredi 25 décembre 2009 à 22:04 +, Graham Percival a écrit : My tentative answer is that we could create an official language-specific list for any translation that finished the top-priority items (IIRC, the website + Learning 1 Tutorial). Thoughts? This is basically what happened in the French-speaking world, except that there was no technical infrastructure to integrate a translation of the documentation when the list was created. For new lists, I'd advertise the possiblity of requesting this in the CG, and always waiting for the translator to request the mailing list creation explicitly. Should we make all new languages just as lilypond-XY, and keep lilypond-user-fr for tradition's sake? I don't mind. Should we ask the -user-fr people to accept a name change to lilypond-fr ? This is perfectly acceptable, and I think a confirmation of Valentin, the other administrator, will be enough to decide to request it to Savannah hackers. If this happens, we should send a big fat warning on the list and info-lilypond, and put a news item on lilypond.org, to announce the name change. Should we make all new languages in the form lilypond-user-XY ? As you already told, Francisco made a good point for not putting -user in the name. We'll certainly need a second LilyPond-related French-speaking list within a few weeks, but it may be better that it remains outside of GNU anyway. 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: New LilyPond Spanish Users list at GNU
2009/12/25 John Mandereau john.mander...@gmail.com: Then the software should be fixed. The lack of proper UTF-8 support is really a pity in 2009 (2010 soon). Oh, I definitely agree! But that's outside my control. I'd rather not attach too many things to google code project, for the sake of our independence, whereas LilyPond is already part of GNU. Good point. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New LilyPond Spanish Users list at GNU
2009/12/25 John Mandereau john.mander...@gmail.com: Le vendredi 25 décembre 2009 à 22:04 +, Graham Percival a écrit : Should we ask the -user-fr people to accept a name change to lilypond-fr ? This is perfectly acceptable, and I think a confirmation of Valentin, the other administrator, will be enough to decide to request it to Savannah hackers. If this happens, we should send a big fat warning on the list and info-lilypond, and put a news item on lilypond.org, to announce the name change. I agree that if we make the change, we'd need to have lots of warning about it. If we want to do the change, there's two possibilities: 1) ask the savannah people to change the name. 2) I make a new list, you send warnings to the old list, somebody monitors the new list for any messages and forwards them and/or tells the sender to send it to the new list instead... then in X months (3? 6? 12?) I can delete the old list. The advantage of #2 is that we don't need to depend on savannah people. Of course, it means that all subscribers will need to sign up for the new list... OTOH, that might not be such a bad thing, since it'll remind them that they need to send future emails to the new address. If we just change their subscriptions automatically, they're more likely to send a message to their saved (old) french lilypond list alias / email contact by mistake. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New LilyPond Spanish Users list at GNU
Le vendredi 25 décembre 2009 à 23:56 +, Graham Percival a écrit : I agree that if we make the change, we'd need to have lots of warning about it. If we want to do the change, there's two possibilities: 1) ask the savannah people to change the name. If we go for this, which I would prefer, we should ask a precise date for the name change, so that we can announce it a bit in advance and know what to do on Nabble interface side. 2) I make a new list, you send warnings to the old list, somebody monitors the new list for any messages and forwards them and/or tells the sender to send it to the new list instead... then in X months (3? 6? 12?) I can delete the old list. The advantage of #2 is that we don't need to depend on savannah people. Of course, it means that all subscribers will need to sign up for the new list... OTOH, that might not be such a bad thing, since it'll remind them that they need to send future emails to the new address. If we just change their subscriptions automatically, they're more likely to send a message to their saved (old) french lilypond list alias / email contact by mistake. The burden of having to resubscribe will appear as unfriendly and might drive out some existing subscribers, and the traffic is important enough so that the burden of forwarding emails between lists will be a huge PITA for Valentin and me. 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: [PATCH] Fix #867 and other lilypond-book snippet handling
Le jeudi 24 décembre 2009 à 20:45 +, Graham Percival a écrit : Looks fine to me, and nothing broken while doing an out-of-tree build from scratch. Pushed. I finally decided to keep the diff generation, because this allows us to reliably catch hash collisions, and with last doc build I only got 2 such warnings. I'm planning to refine further this warning by not displaying it if the difference only concerns \sourcefileline and/or \sourcefilename. 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
[patch] create xrefs from .tely
The attached patch lets me build xrefs by looking at
Documentation/*.tely
directly, instead of looking at the corresponding
Documentation/out-www/*.texi
files.
This would be very nice for the website, since we can't build all of
lilypond on the server. (the alternative is to generate the xrefs
locally, upload the .xref-map files, and hope that they don't change
very often... this isn't quite as terrible as it sounds at first,
since we need to do this for the examples and pictures anyway, but it
would still be nice to avoid this)
I tested it out, and it seems to work, but I don't particularly know
how xrefs work, so I thought I should ask if it's ok.
Cheers,
- Graham
From 1950c0500346b8a96658703880808a5cf4bbb789 Mon Sep 17 00:00:00 2001
From: Graham Percival gra...@percival-music.ca
Date: Sat, 26 Dec 2009 02:21:25 +
Subject: [PATCH] Doc build: allow xref-map creation from (i)tely.
This simplifies the special website target.
---
scripts/build/extract_texi_filenames.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/build/extract_texi_filenames.py b/scripts/build/extract_texi_filenames.py
index 5082df2..fda8fc1 100644
--- a/scripts/build/extract_texi_filenames.py
+++ b/scripts/build/extract_texi_filenames.py
@@ -86,7 +86,7 @@ if not os.path.isdir (outdir):
os.unlink (outdir)
os.makedirs (outdir)
-include_re = re.compile (r'@include ((?!../lily-).*?\.i?texi)$', re.M)
+include_re = re.compile (r'@include ((?!../lily-).*?\.i?te(xi|ly))$', re.M)
whitespaces = re.compile (r'\s+')
section_translation_re = re.compile ('^@(node|(?:unnumbered|appendix)\
(?:(?:sub){0,2}sec)?|top|chapter|(?:sub){0,2}section|\
--
1.6.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving the CG
Carl Sorensen wrote: As I think more about this, I wonder if there should be a short and sweet summary for experienced Linux developers, followed by a gentle (and longer) introduction for the Windows guys. Actually, I'm thinking there should be a short and sweet summary for the GUI-based contributors, followed by a different (and longer) introduction for the Git-based developers. I think most of the essentials will be visible just by skipping the paragraphs (which wouldn't be _that_ long) and looking only at the command-line examples, which would have everything the experienced devs would need. ** Some more thoughts about restructuring the CG... I finally looked at the lilycontrib app and, well it's pretty awesome. Has anyone written any documentation for it? I could probably do it if nobody has yet, since I'm already looking at the rest of the CG. Anyway, regarding comments about `short and sweet' vs. `diluted with fluff'... I'm writing some text intended for serious would-be developers that makes no assumptions about previous development experience. It won't be fluff (I'm aiming for clarity not length), and it won't be required reading for GUI contributors. But it will explain (with modest clarity, I hope) some of the currently missing elements involved that may be common knowledge among more experienced developers. If I organize the chapters efficiently, this text would be in a place where it won't scare away GUI contributors with details they don't need. But these `details' will be valuable to those interested in a deeper level of development involvement. I feel that it has taken me longer than it should have to get familiar with some of the basics of compiling, so this text would ideally reduce the confusion time for new developers. The idea is not just to get more contributors, but to make it easier for more contributors to become good developers. I've attached an updated (but still unfinished) index proposal. The less detailed version follows below. Let me know if you have objections to the outline. Also, the introduction that I first proposed* would be changed to more clearly reflect the options available (ie. Graham's insistence that you don't need Git to contribute). Furthermore, some of the `scary details' would be removed from the introduction and moved to the `Using Git' or `Compiling' chapters. *http://lists.gnu.org/archive/html/lilypond-devel/2009-12/txt0Sx9cyLDKu.txt One final note about the current proposal: Chapter 3 `Using Git' looks like it'll be quite long this way. I'm considering splitting it into two chapters, but I've not made up my mind about it. Comments appreciated. - Mark 1. Introduction to contributing 2. Using the `lilycontrib' GUI 3. Using Git 4. Compiling 5. Documentation work (3) 6. Website work (4) 7. LSR work (5) 8. Issues (6) 9. Regression tests (7) 10. Programming work (8) 11. Release work (9) A. GNU Free Documentation License (A) 1. Introduction to contributing 2. Using the `lilycontrib' GUI 3. Using Git 3.1 Starting with Git 3.1.1 Installing Git 3.1.2 Initializing a repository 3.1.3 Configuring Git * Global settings(1.1.2) * Repository settings 3.2 Downloading branches 3.2.1 LilyPond repository sources (1.1.6) 3.2.2 The `master' branch (1.1.3) 3.2.3 The `lilypond/translation' branch(1.1.4) 3.2.4 Other branches (1.1.5) 3.3 Basic procedures 3.3.1 Staying current * Pulling(1.2.1, .2) * Resolving conflicts(1.2.3) 3.3.2 Working with branches(1.4.2) * Creating and removing branches * Listing branches * Checking out branches * Merging branches 3.3.3 Modifying source files * Making commits * Formatting patches (1.3.1) 3.4 Advanced procedures 3.4.1 Working with remote branches (1.4.3) 3.4.2 Git log (1.4.4) 3.4.3 Applying remote patches (1.4.5) 3.4.4 Pushing to git.sv.gnu.org(1.3.2) 3.5 Git on Windows 3.6 Repository directory structure (1.7) 3.7 Other Git documentation(1.6) 4. Compiling 4.1 Installing build dependencies (2.1.2) 4.1.1 Using `build-dep' 4.1.2 Requirements for compiling LilyPond 4.1.3 Requirements for running LilyPond 4.1.4 Requirements for building documentation 4.2 Configuring `make' 4.2.1
Re: improving the CG
On 12/25/09 8:13 PM, Mark Polesky markpole...@yahoo.com wrote: Carl Sorensen wrote: As I think more about this, I wonder if there should be a short and sweet summary for experienced Linux developers, followed by a gentle (and longer) introduction for the Windows guys. Actually, I'm thinking there should be a short and sweet summary for the GUI-based contributors, followed by a different (and longer) introduction for the Git-based developers. I think most of the essentials will be visible just by skipping the paragraphs (which wouldn't be _that_ long) and looking only at the command-line examples, which would have everything the experienced devs would need. I still think you should have a quick-start guide for people who are already experienced with Linux development and git, so that they can quickly find out what is special/unique to LilyPond development. ** Some more thoughts about restructuring the CG... I finally looked at the lilycontrib app and, well it's pretty awesome. Has anyone written any documentation for it? I could probably do it if nobody has yet, since I'm already looking at the rest of the CG. I'm glad you think the LGCG (LilyPond Git Contributor's GUI) is pretty awesome. You have Graham to thank for that, as he kept the development focused. There is *no* documentation for the LGCG. You're welcome to write it. I wasn't planning to. BTW, the reason I call it LGCG instead of the GUI is that there is a git GUI (you get there by typing git gui at the command prompt), and I don't want to have those two confused. Anyway, regarding comments about `short and sweet' vs. `diluted with fluff'... I'm writing some text intended for serious would-be developers that makes no assumptions about previous development experience. It won't be fluff (I'm aiming for clarity not length), and it won't be required reading for GUI contributors. But it will explain (with modest clarity, I hope) some of the currently missing elements involved that may be common knowledge among more experienced developers. If I organize the chapters efficiently, this text would be in a place where it won't scare away GUI contributors with details they don't need. But these `details' will be valuable to those interested in a deeper level of development involvement. I feel that it has taken me longer than it should have to get familiar with some of the basics of compiling, so this text would ideally reduce the confusion time for new developers. The idea is not just to get more contributors, but to make it easier for more contributors to become good developers. I've attached an updated (but still unfinished) index proposal. The less detailed version follows below. Let me know if you have objections to the outline. Also, the introduction that I first proposed* would be changed to more clearly reflect the options available (ie. Graham's insistence that you don't need Git to contribute). Furthermore, some of the `scary details' would be removed from the introduction and moved to the `Using Git' or `Compiling' chapters. *http://lists.gnu.org/archive/html/lilypond-devel/2009-12/txt0Sx9cyLDKu.txt One final note about the current proposal: Chapter 3 `Using Git' looks like it'll be quite long this way. I'm considering splitting it into two chapters, but I've not made up my mind about it. Comments appreciated. - Mark Have you considered whether Using Git should be an appendix? To the extent that it's teaching about git, rather than about LilyPond, it might belong in an appendix. Maybe there should be a chapter called something like Contributing patches that mentions all the possible ways of contributing patches, and then appendices describing various ways (diff, git, lilycontrib.tcl). 1. Introduction to contributing 2. Using the `lilycontrib' GUI 3. Using Git 4. Compiling 5. Documentation work (3) 6. Website work (4) 7. LSR work (5) 8. Issues (6) 9. Regression tests (7) 10. Programming work (8) 11. Release work (9) A. GNU Free Documentation License (A) Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
