Re: Regression test information
On Thu, Jul 16, 2009 at 10:11:50AM -0600, Carl Sorensen wrote: > I'd like permission to move the information on regression testing from make > test-baseline and make check from the AU to the CG (There's a placeholder > there already; section 7). > > Any concerns about doing this? My concern is that the entire "compiling" is slated to move to the CG, so it would make sense to do this at once. That said, we might split up the user- and packager-oriented parts of compiling from the developer-oriented parts. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change clef inside a grob-callback?
Joe Neeman wrote: > > Is there a way to change the clef from within a grob callback? > > Not really. You can change the clef's glyph, but you can't really change > the clef's influence on the following notes. I presume you mean I can change the clef stencil, or do you mean that it's possible to change the clefGlyph context property? If that were the case, then couldn't I change clefPosition and middleCPosition and do it that way? > ...Reason being, the NoteHead > grobs are created around the same time as the Clef grob and their > positions are fixed at that time, so unless you want to somehow iterate > over and modify all the NoteHeads, it isn't really going to work. > > I'd suggest a music function rather than a grob override. How? I was using a music function before, but I couldn't find a way to get NoteHead staff-positions without a callback. And I get stuck with a music-function because I don't know how to test if I'm in a \relative block or not. I guess the algorithmic idea would be: *Before* staff-positions are concretely determined... 1. what would the staff-positions be if we stayed in this clef? 2. if they're within this clef's "staff-range", do nothing. 3. if another clef is better (according to user), change the clef. 4. determine actual staff-positions with the updated clef info. I just don't know how to catch the process before the staff-positions are determined, if all I have is a context and a EventChord. I thought that if I could at least know whether I'm in a \relative block, I could then look at the current clef, and figure it out the long way (not that I'd want to). But I imagine there must be an easier way in. And I can't test for \relative-ness as far as I can tell anyway. Do you have any other (slightly more specific) suggestions? (: Thanks for taking a look at this. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change clef inside a grob-callback?
On Thu, 2009-07-16 at 19:10 -0700, Mark Polesky wrote: > Is there a way to change the clef from within a grob callback? Not really. You can change the clef's glyph, but you can't really change the clef's influence on the following notes. Reason being, the NoteHead grobs are created around the same time as the Clef grob and their positions are fixed at that time, so unless you want to somehow iterate over and modify all the NoteHeads, it isn't really going to work. > I'm trying to create an auto-clef-change function that will find the > average staff-position within a chord and change the clef if needed. But > I'm a little stuck. I found a way to calculate each chord's average > staff-position, but it's within a grob-callback. And I can't figure out > how to change the clef from there, or if it's even possible. So for the > moment, I'm having the function display the would-be clef decisions in > the console. > > Maybe an entirely different approach is needed -- I don't know. > Can anyone look this over and point me in a helpful direction? I'd suggest a music function rather than a grob override. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
change clef inside a grob-callback?
Is there a way to change the clef from within a grob callback?
I'm trying to create an auto-clef-change function that will find the
average staff-position within a chord and change the clef if needed. But
I'm a little stuck. I found a way to calculate each chord's average
staff-position, but it's within a grob-callback. And I can't figure out
how to change the clef from there, or if it's even possible. So for the
moment, I'm having the function display the would-be clef decisions in
the console.
Maybe an entirely different approach is needed -- I don't know.
Can anyone look this over and point me in a helpful direction?
Thanks so much!
- Mark
\version "2.13.2"
#(define (first-note? note-grob)
(let* ((note-column (ly:grob-parent note-grob X))
(note-grob-array (ly:grob-object note-column 'note-heads))
(first-note (ly:grob-array-ref note-grob-array 0)))
(eq? note-grob first-note)))
#(define (get-avg-staff-pos note-grob)
(let* ((note-column (ly:grob-parent note-grob X))
(note-grob-array (ly:grob-object note-column 'note-heads))
(note-count (ly:grob-array-length note-grob-array)))
;; maybe there should be a ly:grob-array-map procedure...
(let loop ((staff-pos-sum 0) (i 0))
(if (>= i note-count)
(/ staff-pos-sum note-count)
(loop (+ staff-pos-sum
(ly:grob-staff-position
(ly:grob-array-ref note-grob-array i)))
(1+ i))
autoClefOn =
\override NoteHead #'before-line-breaking =
#(lambda (grob)
(if (first-note? grob)
(if (< (get-avg-staff-pos grob) -6)
(display "bass\n")
(display "treble\n"
autoClefOff =
\revert NoteHead #'before-line-breaking
\relative {
\autoClefOn
b c,
\autoClefOff
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup commands: \left-brace & \right-brace.
Code looks good to me.
I have a couple of optional minor nitpicks.
Thanks,
Carl
http://codereview.appspot.com/8874/diff/5202/4204
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/8874/diff/5202/4204#newcode2623
Line 2623: (ly:font-get-glyph font (string-append "brace"
(number->string n)
Do we want to keep line length to <80 chars?
http://codereview.appspot.com/8874/diff/5202/4205
File scm/lily-library.scm (right):
http://codereview.appspot.com/8874/diff/5202/4205#newcode555
Line 555: "Find the index between START and END (an integer) which
Use @var{start} instead of START ?
Use (_i "docstring") to allow internationalization?
http://codereview.appspot.com/8874
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 5:54 PM, "Jonathan Kulp" wrote: > Carl Sorensen wrote: >> >> So, while I asked Marc to provide documentation, I didn't require it. I >> did, however, require regtests. >> >> As soon as we get the patch applied, we can ask one of the people who is >> clamoring for improved tab support on -user to get involved in writing the >> documentation for it, working with you to get it in proper form. >> > > I've been looking more carefully at the regtests and think that > the texidoc headers might be enough to get started on the new > parts of fretted-strings.itely. Would you like me to prepare a > patch based on these so that it can be applied at the same time as > the program code, or should we just wait? Let's wait a bit -- I'd like to see if we can get somebody in the tablature group to do it. If they don't bite, then we'll have you do it. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. I've been looking more carefully at the regtests and think that the texidoc headers might be enough to get started on the new parts of fretted-strings.itely. Would you like me to prepare a patch based on these so that it can be applied at the same time as the program code, or should we just wait? Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup commands: \left-brace & \right-brace.
Add exported function ly:otf-glyph-count. * use this function to remove hard-coded value in binary search and brace lookup. * normalize type assertion messages * fix potential null dereference in ly:otf-font-glyph-info * tidy formatting http://codereview.appspot.com/8874 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New instrument name positioning in Scheme.
Reviewers: joeneeman, Message: On 2009/07/16 05:52:35, joeneeman wrote: Just one corner case, otherwise lgtm Thanks, Joe. I'll add a convert-ly rule for ly:system-start-text::print, a regtest and NEWS entry before pushing. http://codereview.appspot.com/91119/diff/1/10 File scm/output-lib.scm (right): http://codereview.appspot.com/91119/diff/1/10#newcode833 Line 833: (interval-center extent If (not (pair? live-elts)) then (interval-center extent) will be NaN, instead of 0 which would be more sensible. That's caught by interval-center, since it returns 0.0 for empty intervals. Description: New instrument name positioning in Scheme. * remove x/y positioning from print callback to separate X- and Y-offset callbacks * add x-offset calculation for system start delimeter extents so all instrument names in a system are aligned correctly based on self-alignment-X * use 'when from left-bound instead of get_break_index () to determine which text to print; this fixes incorrect indentation and text for shortInstrumentName overrides (Issue #452) * remove acknowledger for system-start-text from system-start-delimiter-engraver.cc * remove system-start-text.cc * add system-start-text-interface to define-grob-interfaces.scm * add library functions used by new callbacks to lily-library.scm and output-lib.scm Please review this at http://codereview.appspot.com/91119 Affected files: M input/lsr/incipit.ly A input/new/incipit.ly M input/regression/incipit.ly M lily/system-start-delimiter-engraver.cc M lily/system-start-text.cc M scm/define-grob-interfaces.scm M scm/define-grobs.scm M scm/lily-library.scm M scm/output-lib.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup commands: \left-brace & \right-brace.
Reviewers: Patrick McCarty, Message: Thanks for the review, Patrick. On 2009/07/16 03:40:58, Patrick McCarty wrote: http://codereview.appspot.com/8874/diff/2201/3202 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/8874/diff/2201/3202#newcode2625 Line 2625: (find-brace (binary-search 0 575 get-y-from-brace scaled-size)) Would Open_type_font::count () return the value 575 you need here? If it does return 575, I would recommend writing and using a callback to retrieve this value, named something like "ly:otf-glyph-count". An excellent suggestion; I wasn't too happy with the hard-coded value, so this will be a nice refinement. Brace yourself for a new patch set. :) Description: New markup commands: \left-brace & \right-brace. Please review this at http://codereview.appspot.com/8874 Affected files: A input/regression/markup-braces.ly M scm/define-markup-commands.scm M scm/lily-library.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 9:56 AM, "Carl Sorensen" wrote:
> Marc Hohl has completed a patch for improved tablature support. It is
> available for review at:
>
> http://codereview.appspot.com/95059
>
> Please review and comment.
>
> Thanks,
Marc,
Here are some comments.
1) All regression tests should be \version "2.13.4" -- I'll fix that.
2) Your regression test for the modernTab clef:
Doc header should say "four- to seven- stringed instruments", which means
instruments having four to seven strings. "four to seven stringed
instruments" means four to seven instruments having strings. Isn't english
fun?
You should demonstrate in the regtest that it works for four strings and
seven strings, and that it works with various staff sizes. You may want two
different regtests -- one that shows variations in string numbers and one
that shows variation in sizes.
3) Is it necessary (or desirable) to have both \deadNote and
\deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
DeadNotes, I can't imagine that it's better to write
\deadNoteOn e e deadNoteOff
than
\deadNotes{e e}.
If there's no value to the On..Off pairs, then it's probably best to
eliminate them. But if there is value, we can keep them. And I'm not the
judge of value. I'm just asking the question.
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
>
> Carl
>
>
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: I like the features, especially the "moderntab" clef. Is it best for "numbersOnly" to be default? I'm not saying it isn't best, I really don't know. I'm a classical guitarist and have never dealt with tablature except when working on the fretted-strings.itely and recently when doing another project. Is it most common for tab not to have any rhythmic indication? If tab is in a staffgroup with traditional notation, then no rhythmic indication is given, because the rhythm comes from the traditional notation. If tab is in a staff by itself, it has rhythmic indication, and that is when \tabFullTab would be used to include stems and flags. The folks who care about tab (which do not include me, BTW) think that numbers only should be the default. Thanks for the explanation. That's good enough for me. :) Yes, we need documentation for the new work. However, according to established policy (by Graham?), developers are not required to add documentation information. Documentation editors add documentation, using regtests as their templates. So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. Yes, I saw these and looked through them. They should be good for the docs. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. Excellent. I'm happy to put it into texinfo format and make the patch, but I'd prefer that actual tablature users write the text. Thanks, Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 4:00 PM, "Jonathan Kulp" wrote: > Carl Sorensen wrote: >> Marc Hohl has completed a patch for improved tablature support. It is >> available for review at: >> >> http://codereview.appspot.com/95059 >> >> Please review and comment. >> >> Thanks, >> >> Carl >> > > I like the features, especially the "moderntab" clef. Is it best > for "numbersOnly" to be default? I'm not saying it isn't best, I > really don't know. I'm a classical guitarist and have never dealt > with tablature except when working on the fretted-strings.itely > and recently when doing another project. Is it most common for tab > not to have any rhythmic indication? If tab is in a staffgroup with traditional notation, then no rhythmic indication is given, because the rhythm comes from the traditional notation. If tab is in a staff by itself, it has rhythmic indication, and that is when \tabFullTab would be used to include stems and flags. The folks who care about tab (which do not include me, BTW) think that numbers only should be the default. > > I think the patch set should include one for fretted-strings.itely > showing the tab clef and whatever other features should be shown, > as well as a brief paragraph about tab conventions. Yes, we need documentation for the new work. However, according to established policy (by Graham?), developers are not required to add documentation information. Documentation editors add documentation, using regtests as their templates. So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. Thanks for your review, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: Marc Hohl has completed a patch for improved tablature support. It is available for review at: http://codereview.appspot.com/95059 Please review and comment. Thanks, Carl I like the features, especially the "moderntab" clef. Is it best for "numbersOnly" to be default? I'm not saying it isn't best, I really don't know. I'm a classical guitarist and have never dealt with tablature except when working on the fretted-strings.itely and recently when doing another project. Is it most common for tab not to have any rhythmic indication? I think the patch set should include one for fretted-strings.itely showing the tab clef and whatever other features should be shown, as well as a brief paragraph about tab conventions. Great work, though. thanks. :) Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Regression test information
I'd like permission to move the information on regression testing from make test-baseline and make check from the AU to the CG (There's a placeholder there already; section 7). Any concerns about doing this? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Improved tablature support
Marc Hohl has completed a patch for improved tablature support. It is available for review at: http://codereview.appspot.com/95059 Please review and comment. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
Le jeudi 16 juillet 2009 à 09:40 -0600, Carl Sorensen a écrit : > However, when non-snippet text is changed, added, or removed from the > english documentation, no corresponding changes should be made to the > translated versions of the documentation. All right, this is clearer. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
On 7/16/09 9:31 AM, "John Mandereau" wrote: > >> So, just to make sure I'm clear on this, I'd like to propose the following >> for addition to the CG: >> >> When a snippet is changed or deleted from the english documentation, the >> same change (or deletion) should be applied to all translated versions of >> the documentation. >> >> However, when text is changed, added, or removed from the english >> documentation, no changes should be made to the translated versions of the >> documentation. >> >> >> Is this correct? > > I'd complete the last sentence with "besides removing snippets that > break compilation of the documentation"; besides this, this LGTM. How about: However, when non-snippet text is changed, added, or removed from the english documentation, no corresponding changes should be made to the translated versions of the documentation. I intended to have the snippet part be covered by the first paragraph. > > Thanks, > John > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
Le jeudi 16 juillet 2009 à 09:12 -0600, Carl Sorensen a écrit : > I tried running > > make ISOLANG=fr snippet-update > > from Documentation/. It ran, but most of the files were not able to be > updated because they had a different snippet count. So at the present time, > make snippet-update is not particularly useful in terms of updating > snippets; the work will need to be done largely by hand. Indeed. If we had a Texinfo parser usable as a module (and I hope we'll have one soon), it would be easy to change this script so it would try to update snippets node by node. > So, just to make sure I'm clear on this, I'd like to propose the following > for addition to the CG: > > When a snippet is changed or deleted from the english documentation, the > same change (or deletion) should be applied to all translated versions of > the documentation. > > However, when text is changed, added, or removed from the english > documentation, no changes should be made to the translated versions of the > documentation. > > > Is this correct? I'd complete the last sentence with "besides removing snippets that break compilation of the documentation"; besides this, this LGTM. Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
On 7/15/09 9:48 AM, "John Mandereau" wrote: > Le mardi 14 juillet 2009 à 16:21 -0600, Carl Sorensen a écrit : >> Hmm -- I read through the CG and missed it. Now that I know what I'm >> looking for, I see where it is. I'll add something to the CG. > > Thanks. The general problem when I write instructions in the CG (besides > the fact that I still haven't updated it enough) is that I have in mind > the design of the translation infrastructure, that AFAIK is only known > by Jan, me, and probably a little by Han-Wen and Reinhold. The more I > think about it, the more I find I should write a short paper and/or CG > section that explains the general design of the docs translations > integration, so we can avoid formalizing too many procedure details > related to translations into the CG. I tried running make ISOLANG=fr snippet-update from Documentation/. It ran, but most of the files were not able to be updated because they had a different snippet count. So at the present time, make snippet-update is not particularly useful in terms of updating snippets; the work will need to be done largely by hand. > > >> But if I've changed syntax, and the translated manuals will no longer work >> properly, then I break compilation if I push a patch. >> >> So in the case of a syntax change that needs a NOT_SMART convert-ly rule, we >> should have some procedure in place to avoid future occurences of this >> problem, it seems to me. > > The procedure that used to be applied by Jan, Han-Wen and other > contributors was to apply syntax changes in snippets > (@lilypond/@lilypondfile) to all languages without asking anything, or > (I can't remember whether they have already done so) commenting out or > remove broken snippets in translations. The former is the most sensible > thing to do IMHO. So, just to make sure I'm clear on this, I'd like to propose the following for addition to the CG: When a snippet is changed or deleted from the english documentation, the same change (or deletion) should be applied to all translated versions of the documentation. However, when text is changed, added, or removed from the english documentation, no changes should be made to the translated versions of the documentation. Is this correct? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor corrections to the contrib-guide
Hi Till, Sorry for the delay :-/ Le dimanche 28 juin 2009 à 11:00 +0300, Till Rettig a écrit : > first time I consulted the contributor's guide. It's never too late :-) (it's never too late either for me to work on it again :-P) > in 3.7.2 Documentation translation details you have different starting > points for the individual files: mostly you start from LL-directory, but > then it should be also ../po/lilypond-doc.pot and > ../../lilypond-texi2html.init No, paths are relative to Documentation/; this list mentions original files, not translated ones. > The last was what made me stumble -- I never remember that I have > translated it -- isn't this done from the .po-file? At least that is > what I thought. No, just skim through this file and you'll see some stuff to translate. I should add PO file loading support in Texi2html through a Perl library this summer; after that, it will be easy to move these translations to the doc PO. > After the lilypond-texi2html.init file you write (see TRANSLATION), do > you refer to the old text file that got deleted? No, this means you should look for stuff to translate after a comment line name "TRANSLATIONS". > A bit later there is mentioned the install.itely -- didn't it get parted > into install and compile? Thanks, fixed in my working tree. Files not to be translated are not mentioned. > In the section Maintaining without updating translations there are some > orthography mistakes -- you will spot them more quickly yourself. I hope I've caught all of them, but it's almost always easier to find other's typos and bad wording than yours, so please report them next time! > (The > last sentence in the third paragraph is double.) Fixed on my working tree. I'm sorry I have not pushed those fixes, but as you can see from Git history, I'm preparing translation of node names in Texinfo sources, which will be the subject of another email, and I've been silly enough to mix the fixes for the typos you reported with changes related to nodes translation. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
Le jeudi 16 juillet 2009 à 04:46 -0700, Graham Percival a écrit :
> On Thu, Jul 16, 2009 at 01:30:56AM +0200, John Mandereau wrote:
> > I assume you mean Documentation.
>
> No; I really want to rename that dir. I've wanted to rename it
> since I first got involved in lilypond. Typing shift-d has been
> bugging me for the past 6 years, and I want it gone. :)
>
> I'm assuming that this is easy in git, and that a "git mv" will
> keep the history, not produce conflicts, etc.
Ah, then just do it yourself, I don't want to take the responsability
for this nor the effort to make it work (including GUB and
translations). Have you realized that it will make browsing Git history
more difficult and require hackery in translation checking scripts to
follow old history of files from docs/ to Documentation? We have this
problem for input/texidocs, but these files are recent and much smaller
than the manuals, and the benefit of merging Snippets into Documentation
is much greater on the long term. Well, all this probably means
Documentation won't be renamed. Sorry for the disappointment. After all,
it's not that bugging to type shift-d then TAB :-)
> Definitely; "info lilypond" should give you the website (or
> whatever parts thereof are present in the main repo)
>
> Every manual contains a line like this:
> @setfilename lilypond.info
> so I assume it's easy to change.
I hope so.
> It's impossible to miss, as is
> INSTALL.txt in the tarball, so the masocists that want to compile
> from source can still find their instructions.
Do you mean that all packagers are masocists? :-)
> I think this is met by my later proposal to keep a separate web/
> repo, but to not edit the texinfo sources on that branch. That
> way, no lilypond snippet compiling will be necessary to build the
> website, so the hourly build will be fine.
If no Texinfo/ly compilation is done on web branch, then there should be
no Texinfo/ly source on web. I assume you mean this.
> Of course, the split-repo thing brings back a bunch of trickery to
> get references working. :(
Not necessarily (see my next paragraph).
> I'm not certain we want to require an active internet connection.
> If we have an "imported read-only" directory in the web repo (just
> like our current input/lsr/ is an "imported read-only"
> directory... read-only by policy, not technically read-only) then
> we can still build it offline. As long as somebody updates the
> imported read-only dir from time to time.
> (just like the LSR editor updates input/lsr/ from time to time)
I'm against recording HTML ouptut and/or a bunch of generated
PNG/SVG/EPS images of music in web repository: this will clutter history
a lot. It would be cool if lilypond.org server could accept daily upload
of a docs snapshot, which would be used to build the web site. I think
the part built on lilypond.org can be trimmed down to HTML fragments
that will be inserted into the already compiled site (e.g. download
pages that urrently live in site/install/v2.x.ihtml).
> I agree with a split between temporal and atemporal, altough could
> we call it "variable and permenant" or something like that? It's
> confusing when I try to skim emails about {'','a'}temporal at
> 4:46am. :)
OK, although I've already read "temporal" in books on concurrency,
"atemporal" may be kind of a Frenchism :-)
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
On Thu, Jul 16, 2009 at 04:02:28PM +0200, Valentin Villenave wrote: > Another point is that, as far as I can see, we're ready to happily > break any existing links to the former documentation, as well as URLs > we've been using for years such as lily.org/web/install... and it's a > bit frightening to imagine that any website or mail that has been > linking to a specific page in the last decade will suddenly cease to > work. Or am I the only one concerned? You're the only one concerned, because everybody else knows that redirects are done in web/lilypond.org.htaccess, and adding more redirects is only a git push away. If anybody was silly enough to link to a specific documentation page, then we probably broke that during GDP anyway. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
2009/7/16 John Mandereau : > The hourly script is useful to allow any web site maintainer to react > quickly against typos and minor bugs that don't require fixing the > Makefile or Python scripts, whereas it could take much longer if you (or > another maintainer) are the only person that can fix problems. I'm not > keen on dropping the hourly build unless there are two or three active > web site maintainers (i.e. people that have a SSH access to Lily main > web site). The cron hourly job is also handy to quickly publish news > items. BTW I'm sure Valentin is tempted to say (and I'd agree with him) > that lilypond.org should be a bit more dynamic than it is currently, > suppressing the hourly build would not go in the right direction. No. You don't know me at all. In fact, I want the *complete* website/documentation to be coded in Flash. With moving-blinking-flashy little pink stars. Everywhere. :-) More seriously speaking, I'm not sure if it's sensible to use the webserver as a /build/ server as well. These are two very different tasks, and from a security/stability point of view, these two tasks might put each other at risk. The ideal would be to have two separate machines to do that, and the webserver should only receive the ready-to-use website without having to compile or build anything (other than, maybe, trivial python substitution tasks). Another point is that, as far as I can see, we're ready to happily break any existing links to the former documentation, as well as URLs we've been using for years such as lily.org/web/install... and it's a bit frightening to imagine that any website or mail that has been linking to a specific page in the last decade will suddenly cease to work. Or am I the only one concerned? Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
On Thu, Jul 16, 2009 at 01:30:56AM +0200, John Mandereau wrote:
> Le samedi 11 juillet 2009 à 03:21 -0700, Graham Percival a écrit :
> > docs/
>
> I assume you mean Documentation.
No; I really want to rename that dir. I've wanted to rename it
since I first got involved in lilypond. Typing shift-d has been
bugging me for the past 6 years, and I want it gone. :)
I'm assuming that this is easy in git, and that a "git mv" will
keep the history, not produce conflicts, etc.
> > docs/learning.tely
> > docs/learning/*.itely
> > docs/notation.tely
> > docs/notation/*.itely
> > + glossary, essay, application
>
> Fine, but Info file names must be named lilypond (for the main Info
> documentation, probably some kind of part of the web site)
Definitely; "info lilypond" should give you the website (or
whatever parts thereof are present in the main repo)
> or lilypond-*. IIRC source file names don't have to have the
> same file name prefix as the Info file, I'll have to check this.
Every manual contains a line like this:
@setfilename lilypond.info
so I assume it's easy to change.
> > docs/web.texi
> > docs/web/*.itexi
>
> Why not, but this can only be almost permanent contents IMHO (I'll try
> to explain at the end of this message).
IMO, "changes.tely" (oops) definitely should be present for every
build from source.
> > docs/topdocs/compile.texi
>
> Do you mean this would be a standalone document?
No; this would only be present in the CG and as INSTALL.txt in
tarballs. Yes, there's a direct link from Download->Source to the
relevant chapter of the CG. It's impossible to miss, as is
INSTALL.txt in the tarball, so the masocists that want to compile
from source can still find their instructions.
> > regression/ new location of input/regressions/
> > input/completely deleted
>
> Can somebody already starts checking where could go stuff that remains
> in input/{tutorial,manual}?
input/manual/ -> docs/notation/
(and/or docs/learning/, as appropriate)
input/tutorial/ -> docs/application
(unless we rename that manual... in any case, this is AU stuff)
input/lsr, new, texidocs -> docs/snippets/ lsr, new, texidocs
(my earlier email was unclear about this, sorry)
input/mutopia -> /dev/null
(I honestly don't know if these have been visible at all for
the past 8 years; it's certainly not obvious, if they are!)
input/*.ly -> /dev/null
(examples are done in web-gop now)
> > There are other considerations: I'd like to include the authors
> > and THANKS file in Community->Authors. I suppose we could move
>
> In all that reasoning, you missed the essential fact that as long as
> we'll have two branches, building the web site will require at least two
> branches (or by-products of two branches), one for the development
> branch, the other for the stable branch; (BTW you pointed this out later
> in your message). So some "weird hackery" is needed to get (download or
> cd into another local Git branch and generate) generated Texinfo xref
> maps from the other branch to generate correct HTML links, or
> alternatively we are bound to have the same node names and output
> directories in both branches.
>
> This also raises the web site build host issue: a hourly cron job on
> lilypond.org for building is currently incompatible with having ly
> snippets compiled during the build; even if we can get Lily to run
> safely, I doubt that lilypond.org host will provide efficiently the
> needed CPU and memory ressources while keeping its server role.
I think this is met by my later proposal to keep a separate web/
repo, but to not edit the texinfo sources on that branch. That
way, no lilypond snippet compiling will be necessary to build the
website, so the hourly build will be fine.
Of course, the split-repo thing brings back a bunch of trickery to
get references working. :(
> The temporal part would be contents that changes often and/or that
> requires information from several branches: the news and the download
> pages.
And Changes.
> Building it would require an active Internet connection, a read
> access to Lily git repo and a build of the website including some
> by-products (e.g. xref-map files to get cross-references right).
I'm not certain we want to require an active internet connection.
If we have an "imported read-only" directory in the web repo (just
like our current input/lsr/ is an "imported read-only"
directory... read-only by policy, not technically read-only) then
we can still build it offline. As long as somebody updates the
imported read-only dir from time to time.
(just like the LSR editor updates input/lsr/ from time to time)
> The atemporal part would be all the rest, which would be compiled from
> master branch sources in Documentation/web and would follow the usual
> release cycle, allowing verification, validation, translation updating
> between releases.
>
> The offline version of the web site would be available in the docball,
> temporal pages would be replaced by at
Re: proposal for doc+web sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 16. Juli 2009 01:30:56 schrieb John Mandereau: > Speaking of cross-references, I'll add sooner or later a makefile hook > that runs the cross-reference checking script I wrote and/or some > Texi2html-internal hook, which will break the doc build if there are any > broken cros-references (including cross-manuals cross-references). We > are not ready to be so strict now because of the web+docs upcoming > overhaul, but so much effort has been put into documentation that this > important quality criterion is checked. Speaking of checking cross-references, I'm still running the linkchecker on the documentation on kainhofer.com on a daily basis. The output (broken links and anchors) can be found at http://kainhofer.com/~lilypond/linkdoc/ Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKXwubTqjEwhXvPN0RAtJdAJ9laSggraWATN+q+npx585z46U3CgCgzCfJ Qn6oy1oiZEu1aomPEEIk20Q= =XKc4 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Obsolete snippets
Le mercredi 15 juillet 2009 à 18:40 -0600, Carl Sorensen a écrit : > I'll delete all the English and just leave the corrected snippets in the > Spanish docs. > > How about french and german? What would you prefer? Let's not have different policies for different languages, or all contributors and developers will go mad; Francisco is right, dumping text in English is not useful. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
Le samedi 11 juillet 2009 à 03:21 -0700, Graham Percival a écrit :
> Here's my proposal for the source/makefile view of documentation.
> (this is the big argument one)
...and here is my big reply :-P
> My understanding is that linking between texinfo manuals is easier
> if the main files are in the same directory.
This is true. This also makes makefiles maintenance easier too, and it
most probably speeds up the doc build on multicore/multi-CPU systems.
> docs/
I assume you mean Documentation.
> docs/learning.tely
> docs/learning/*.itely
> docs/notation.tely
> docs/notation/*.itely
> + glossary, essay, application
Fine, but Info file names must be named lilypond (for the main Info
documentation, probably some kind of part of the web site) or
lilypond-*. IIRC source file names don't have to have the same file name
prefix as the Info file, I'll have to check this.
> docs/snippets.tely(moved from input/lsr/ and input/new/)
> docs/snippets/*.ly
>
> docs/contributors.texi
> docs/contributors/*.texi
>
> docs/web.texi
> docs/web/*.itexi
Why not, but this can only be almost permanent contents IMHO (I'll try
to explain at the end of this message).
> docs/topdocs/
> docs/topdocs/changes.texi
You mean changes.tely, don't you?
> docs/topdocs/compile.texi
Do you mean this would be a standalone document?
> regression/ new location of input/regressions/
> input/completely deleted
Can somebody already starts checking where could go stuff that remains
in input/{tutorial,manual}?
> How much cross-referencing do we want? Probably not a huge
> amount, but enough that is could be a pain. Web->Manuals links to
> every manual, of course. The FAQ -- which might live as part of
> manuals.itexi in manuals, or as a separate manual in docs/ --
> wants to link to the LM, website, and AU. Quite possibly other
> items, too. The AU will probably want to link to certain pages on
> the website. LM probably also wants to link to parts of the
> website (Community->Contact ->Tiny examples, and maybe ->Bug
> reports).
Speaking of cross-references, I'll add sooner or later a makefile hook
that runs the cross-reference checking script I wrote and/or some
Texi2html-internal hook, which will break the doc build if there are any
broken cros-references (including cross-manuals cross-references). We
are not ready to be so strict now because of the web+docs upcoming
overhaul, but so much effort has been put into documentation that this
important quality criterion is checked.
> There are other considerations: I'd like to include the authors
> and THANKS file in Community->Authors. I suppose we could move
> all the author bios into a separate branch... but what about the
> THANKS file? I _guess_ we could hack up a git checkout, so
> whenever you built the docs in a separate web/ repository, it
> would get the latest THANKS from the separate lilypond.git
> repository... but this sounds ridiculous to me.
>
> Ditto for the Changes manual (the renamed NEWS) and FAQ. The
> master copy of this obviously needs to be in the source, but that
> means that we either distribute these as fully distinct manuals (a
> one-page lilypond-faq.pdf ?), or do some weird hackery to include
> it in the build process of a separate website repository.
In all that reasoning, you missed the essential fact that as long as
we'll have two branches, building the web site will require at least two
branches (or by-products of two branches), one for the development
branch, the other for the stable branch; (BTW you pointed this out later
in your message). So some "weird hackery" is needed to get (download or
cd into another local Git branch and generate) generated Texinfo xref
maps from the other branch to generate correct HTML links, or
alternatively we are bound to have the same node names and output
directories in both branches.
This also raises the web site build host issue: a hourly cron job on
lilypond.org for building is currently incompatible with having ly
snippets compiled during the build; even if we can get Lily to run
safely, I doubt that lilypond.org host will provide efficiently the
needed CPU and memory ressources while keeping its server role.
> I know that there's some concerns about people accidently screwing
> up the website and having it show up in an hour. I've never been
> quite certain why we have an automatic hourly rebuild -- we don't
> update the website all that often. We could disable that for a
> few months, see how often people screw up the website and go with
> a script to upload the generated website, then re-evaluate the
> situation.
The hourly script is useful to allow any web site maintainer to react
quickly against typos and minor bugs that don't require fixing the
Makefile or Python scripts, whereas it could take much longer if you (or
another maintainer) are the only person that can fix problems. I'm not
keen on dropping the hourly build unless there are two or three active
web site maint
Re: Snippets in doc compile different from stand-alone
Le mardi 14 juillet 2009 à 16:21 -0600, Carl Sorensen a écrit : > Hmm -- I read through the CG and missed it. Now that I know what I'm > looking for, I see where it is. I'll add something to the CG. Thanks. The general problem when I write instructions in the CG (besides the fact that I still haven't updated it enough) is that I have in mind the design of the translation infrastructure, that AFAIK is only known by Jan, me, and probably a little by Han-Wen and Reinhold. The more I think about it, the more I find I should write a short paper and/or CG section that explains the general design of the docs translations integration, so we can avoid formalizing too many procedure details related to translations into the CG. > But if I've changed syntax, and the translated manuals will no longer work > properly, then I break compilation if I push a patch. > > So in the case of a syntax change that needs a NOT_SMART convert-ly rule, we > should have some procedure in place to avoid future occurences of this > problem, it seems to me. The procedure that used to be applied by Jan, Han-Wen and other contributors was to apply syntax changes in snippets (@lilypond/@lilypondfile) to all languages without asking anything, or (I can't remember whether they have already done so) commenting out or remove broken snippets in translations. The former is the most sensible thing to do IMHO. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [trivial patch] fix bracket padding
2009/7/9 Graham Percival :
> Since this contains a patch, I forward it to lilypond-devel. Does
> anybody think it looks reasonable?
>
>
> On Mon, Jul 06, 2009 at 11:08:42PM +, Thomas Morgan wrote:
>> Consider this input:
>>
>> \version "2.13.2"
>> \markup {
>> \column {
>> \concat { "a" \bracket { "b" } "c" }
>> "abc" % For comparison.
>> }
>> }
>>
>> The right bracket's padding causes the following "c" to move out
>> of the way of the bracket. But the left bracket's padding does not
>> prevent the "a" and the left bracket from colliding.
>>
>> Is this a bug? If so, it could be fixed by the following patch.
>>
>> (I also switched `lb' and `rb' having noticed that `lb' was actually
>> the right bracket and `rb' was the left bracket.)
>>
>> diff --git a/scm/stencil.scm b/scm/stencil.scm
>> index 105f6f5..fcf5434 100644
>> --- a/scm/stencil.scm
>> +++ b/scm/stencil.scm
>> @@ -62,12 +62,12 @@
>> "Add brackets around STIL, producing a new stencil."
>>
>> (let* ((ext (ly:stencil-extent stil axis))
>> - (lb (ly:bracket axis ext thick (- protusion)))
>> - (rb (ly:bracket axis ext thick protusion)))
>> + (lb (ly:bracket axis ext thick protusion))
>> + (rb (ly:bracket axis ext thick (- protusion
>> (set! stil
>> - (ly:stencil-combine-at-edge stil (other-axis axis) 1 lb padding))
>> + (ly:stencil-combine-at-edge stil (other-axis axis) 1 rb padding))
>> (set! stil
>> - (ly:stencil-combine-at-edge stil (other-axis axis) -1 rb padding))
>> + (ly:stencil-combine-at-edge lb (other-axis axis) 1 stil padding))
>> stil))
>>
>> (define-public (make-line-stencil width startx starty endx endy)
Although it mostly LGTM, I am in no position to merge it on my own.
So, it's now added as #807 in our tracker.
(and the lb/rb thing looks weird indeed, if I may)
Regards,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly bug?
2009/7/15 ArnoWaschk : > while trying to import some scores into lilypond i was given as xml export > from a finale using collegue, i stumbled across some problems... Hi Arno, Added as http://code.google.com/p/lilypond/issues/detail?id=806 (please use the bug-lilypond mailing list for such reports, otherwise there's a chance they'll go unnoticed.) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
