Re: keyboard navigation in html docs
On Thu, Jul 30, 2009 at 10:19:42AM +0200, Francisco Vila wrote: > 2009/7/30 Graham Percival : > > I think it's possibly to detect keypresses in javascript. > > Javascript not needed. > > Links can have > > Next Neat! Ok, I think we have enough positive, and no negative, responses. Valentin, could add this to the tracker, so that we can lose it? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new repos: do we want an archive?
On Tue, Aug 04, 2009 at 06:44:12PM -0300, Han-Wen Nienhuys wrote: > On Tue, Aug 4, 2009 at 5:19 AM, Graham Percival > wrote: > > However, I started wondering about all the old history that would > > be lost when we delete web/ and (to a much lesser extent) > > web-gop/. > > I don't understand this action. In general the whole purpose of > having a source code control system is to _have_ an archive old > material. Why do you want to delete old stuff, or move it into a > different repo where nobody will be able to find it? I'm hoping to avoid confusing new contributors -- if we don't use the web/ branch, then there's a danger that somebody might start working on files in there. Basically, I *do* want to make it harder for people to find stuff that they don't actually want to find. However, I've discovered that git can rename branches, so we could call them archive/web and archive/web-gop instead. That should be clear enough to avoid confusion. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Neil Puttock wrote:
> Sorry to throw a spanner in the works, but have you considered what
> will happen if an innocent user adds the Span_arpeggio_engraver to the
> Staff context in order to span voices on one stave?
Can you give an example that fails? (You may want to read my reply to
Joe first before you spend any time concocting something - see below)
At least the example from the docsworks:
\new Staff \with {
\consists "Span_arpeggio_engraver"
}
\relative c' {
\set Staff.connectArpeggios = ##t
<<
\arpeggioArrowDown
{ 4\arpeggio 2 } \\
{ 2\arpeggio 2 }
>>
}
> A few nitpicks:
>
> (not (null? parent))
> (not (null? origin))
> ly:context?
Changed - thanks.
> (let* ((Arpeggio
> arpeggio (or something else without the capital letter)
What's bad about the capital letter? I capitalized it because it's
a grob-name and grob-names are capitalized. Does the same problem
extend to the X-extent binding one line below?
Thanks Neil!
Joe Neeman wrote:
> I'd like to second Neil's objection regarding the hard-coding of
> GrandStaff/PianoStaff/StaffGroup as contexts containing
> Span_arpeggio_engraver. Given the flexibility of contexts and engravers
> in lilypond, it isn't a good idea to assume that certain contexts are
> the only ones to provide a particular functionality.
Is there a scheme procedure to test if a given context contains
a particular engraver? Like...
(context-has-engraver? context 'Span_arpeggio_engraver)
If not, is there a way to test that? I agree, my current solution
there isn't ideal.
> Also, one other minor comment:
>
> you've written out the recursion twice: it should be
> (let ((parent (ly:context-parent context)))
> (if parent
> (find-spannable-context parent)
> #f))
Thanks. That was code from an earlier version that I forgot to
remove once it became redundant.
Thanks guys. Looking forward to the next round...
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with VerticalAlignment
On 8/4/09 8:02 PM, "Joe Neeman" wrote: > On Tue, 2009-08-04 at 19:02 -0600, Carl Sorensen wrote: >> >> >> On 8/4/09 5:49 AM, "Graham Percival" wrote: >> >>> On Tue, Aug 04, 2009 at 09:13:40PM +1000, Cameron Horsburgh wrote: I'm having trouble with a brand new clone of the git repo. Running lilypond on even the simplest of files generates this error: >>> | programming error: no VerticalAlignment in system: can't do vertical spacing/usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: In procedure - in expression (- 0 y ...): | /usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: Wrong type: () | | Compilation exited abnormally with code 1 at Tue Aug 4 21:00:32 >>> >>> I also see this; I think it's related to the recent vertical >>> spacing code. >>> >> >> >> It's some strange interaction between the vertical spacing code and my >> autobeaming patch. >> >> If I do >> >> make clean >> make >> >> I get the error. > > Does this still happen with Neil's fix? > 80af529db0afd356533d3feef770f8593a89358c > No, it's all fixed. Thanks, Neil. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with VerticalAlignment
On Tue, 2009-08-04 at 19:02 -0600, Carl Sorensen wrote: > > > On 8/4/09 5:49 AM, "Graham Percival" wrote: > > > On Tue, Aug 04, 2009 at 09:13:40PM +1000, Cameron Horsburgh wrote: > >> I'm having trouble with a brand new clone of the git repo. Running > >> lilypond on even the simplest of files generates this error: > > > >> | programming error: no VerticalAlignment in system: can't do vertical > >> spacing/usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: In > >> procedure - in expression (- 0 y ...): > >> | /usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: Wrong type: () > >> | > >> | Compilation exited abnormally with code 1 at Tue Aug 4 21:00:32 > > > > I also see this; I think it's related to the recent vertical > > spacing code. > > > > > It's some strange interaction between the vertical spacing code and my > autobeaming patch. > > If I do > > make clean > make > > I get the error. Does this still happen with Neil's fix? 80af529db0afd356533d3feef770f8593a89358c ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with VerticalAlignment
On 8/4/09 5:49 AM, "Graham Percival" wrote: > On Tue, Aug 04, 2009 at 09:13:40PM +1000, Cameron Horsburgh wrote: >> I'm having trouble with a brand new clone of the git repo. Running >> lilypond on even the simplest of files generates this error: > >> | programming error: no VerticalAlignment in system: can't do vertical >> spacing/usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: In >> procedure - in expression (- 0 y ...): >> | /usr/local/share/lilypond/2.13.4/scm/page.scm:241:68: Wrong type: () >> | >> | Compilation exited abnormally with code 1 at Tue Aug 4 21:00:32 > > I also see this; I think it's related to the recent vertical > spacing code. > It's some strange interaction between the vertical spacing code and my autobeaming patch. If I do make clean make I get the error. If I do git checkout edbfb6ad6f5c8d3d0628ac1fc2e18046d9b14ddc (last commit before autobeaming) make clean make then git checkout master make I don't get the error. I have been unable to find the cause of this. I'd welcome help from anybody who can provide it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Tue, 2009-08-04 at 14:01 -0700, Mark Polesky wrote: > Mark Polesky wrote: > > > Otherwise, does this look good? > > I'm sorry to keep doing this, but I keep finding ways of > improving this. Now I think users should find this very > intuitive, although the internal workings are more complex. > > I've attached the most recent version, which includes an > annotated example at the bottom, which explains the behind- > the-scenes operations. > > Anyone want to have a look at it? > Anyone have any comments/suggestions? I'd like to second Neil's objection regarding the hard-coding of GrandStaff/PianoStaff/StaffGroup as contexts containing Span_arpeggio_engraver. Given the flexibility of contexts and engravers in lilypond, it isn't a good idea to assume that certain contexts are the only ones to provide a particular functionality. Also, one other minor comment: > #(define (find-spannable-context context) > (let ((spannable-contexts '(GrandStaff PianoStaff StaffGroup))) > (if (member (ly:context-name context) spannable-contexts) > context > (let ((parent (ly:context-parent context))) > (if parent > (let ((parent-name (ly:context-name parent))) > (if (member parent-name spannable-contexts) > parent > (find-spannable-context parent))) > #f) you've written out the recursion twice: it should be (let ((parent (ly:context-parent context))) (if parent (find-spannable-context parent) #f)) Cheers, Joe > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
2009/8/4 Graham Percival : > On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: >> I was thinking on annotated SVG examples, which should be created for >> the essay BTW -- I believed Till had taken this over a while ago, but I >> never got news about this. > > Do you mean the annotated SVGs in web->Introduction->Text input? Daniel Tonda was who started translating the web page, he succeeded at using Inkscape to build the translated http://lilypond.org/web/switch/howto (the crash course) pages. http://lilypond.org/web/graphics/annotate-example-1.es.png etc. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Include path priority for documentation/snippets
2009/8/2 John Mandereau : > You have surely noticed that this is fixed in Git. Sorry for the little > delay for fixfing this and for having ignored your patch Neil, I only > remembered you had complained with this but didn't go back to the email > thread to look at your patch, though discussions on -devel are > interesting the traffic is a bit high nowadays. No worries, John. It's only a minor nitpick, so I wasn't too concerned about it; I knew you'd get around to sorting it eventually. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new repos: do we want an archive?
On Tue, Aug 4, 2009 at 5:19 AM, Graham Percival wrote: > GUB won't be moved into lilypond git, and web stuff will live in > master and stable. So currently we're only looking at creating > one extra repo: > ...@sv/lilypond/lilypad.git > description: Lightweight editor for lilypond files > > However, I started wondering about all the old history that would > be lost when we delete web/ and (to a much lesser extent) > web-gop/. That also reminded me of dev/rune, which I find myself > reluctant to delete. > description: Old material for lilypond I don't understand this action. In general the whole purpose of having a source code control system is to _have_ an archive old material. Why do you want to delete old stuff, or move it into a different repo where nobody will be able to find it? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
2009/8/4 Mark Polesky : > Anyone have any comments/suggestions? Sorry to throw a spanner in the works, but have you considered what will happen if an innocent user adds the Span_arpeggio_engraver to the Staff context in order to span voices on one stave? A few nitpicks: (not (null? parent)) (not (null? origin)) ly:context? (let* ((Arpeggio arpeggio (or something else without the capital letter) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
On Fri, Jul 31, 2009 at 3:10 PM, Mark Polesky wrote: > > Han-Wen Nienhuys wrote: >> No. In the specific case, I'd recommend making another music >> function that takes an argument, so you can pass the 15/16 >> explicitly, without mucking with variables. > > So it sounds like you believe that one way or another, the burden > should be on the user. Then do you think we should add a warning > in the docs, something like this? > > "When the value of such a variable is changed in a .ly file, the > change is global, and unless explicitly reverted, the new value > will persist to the end of the file, affecting subsequent \score > blocks as well as external files added with the \include command. > This can lead to unintended consequences (if a variable is not > explicitly reverted). Especially in complex typesetting projects, > these types of errors can be difficult to track down." I think in general the manual should not encourage users to define or set variables using Scheme, exactly because the scoping semantics are confusing. If the manual shows tricks that require this, the appropriate parts of Lily should be revised so it offers a less hacky solution. > I suppose we could also explain (in the docs) how to devise (in > general) a custom music-function with the extra argument as you > described, but this is a little trickier than simply pointing > users to NR 6.1.3 "Paired substitution functions". Rewriting the > music-function involves not only finding the location of its > definition in the distribution files, but also manipulating the > scheme code -- far more advanced than explicitly reverting the > value, but much safer. > > What do you think? You are misunderstanding me. I think someone should go into the lilypond source and create the function I suggested in the earlier message. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky writes: > Mark Polesky wrote: > >> Otherwise, does this look good? > > I'm sorry to keep doing this, but I keep finding ways of > improving this. Now I think users should find this very > intuitive, although the internal workings are more complex. > > I've attached the most recent version, which includes an > annotated example at the bottom, which explains the behind- > the-scenes operations. > > Anyone want to have a look at it? > Anyone have any comments/suggestions? Ok, since I was the one originally complaining, it seems appropriate to say something here: I have to admit that I have never needed an arpeggio, let alone a cross-staff one. I have, more or less, reacted in a keyword-triggered manner: the original proposal sounded like something that was rather hard and unintuitive to use, and like something that required so much manual tweaking that it would not adapt itself well to changed conditions (autocombined staffs/voices and similar). Lilypond should IMO aim to describe more the music than its representation, since the act of casting the music into a representation is conceptually Lilypond's task. It would appear that your work has improved the user interface considerably, where it looks like an implemented feature rather than a bunch of twiddling knobs sticking out. I have no idea how robust this feature will work in combination with other features and/or extensions, and how well the internals of Lilypond have lent themselves to the implementation, or resisted. So I don't have enough of a clue to figure out further areas of queasiness. Since this construct is not used all that often, it is my guess that worthwhile feedback will trickle in rather slowly after the feature has been published and documented, from the rare user that actually needs to exercise it. I am glad to know that it will be there in a reasonably user-comprehensible way, should the need arise for me. And it is, after all, something which meets a need particularly in piano music (I don't play piano), so the current dearth of feedback does not mean that doing this well was merely an academic exercise. All the best -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
> Otherwise, does this look good?
I'm sorry to keep doing this, but I keep finding ways of
improving this. Now I think users should find this very
intuitive, although the internal workings are more complex.
I've attached the most recent version, which includes an
annotated example at the bottom, which explains the behind-
the-scenes operations.
Anyone want to have a look at it?
Anyone have any comments/suggestions?
- Mark
\version "2.13.3"
%% begin property-init.ly revision %%
#(define (arpeggio-generic pushpops)
(lambda (context)
(let* ((parent
(ly:context-property-where-defined context
'connectArpeggios))
(target
(if (and (not (null? parent))
(eq? #t (ly:context-property parent
'connectArpeggios)))
parent
context)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops
#(define (find-spannable-context context)
(let ((spannable-contexts '(GrandStaff PianoStaff StaffGroup)))
(if (member (ly:context-name context) spannable-contexts)
context
(let ((parent (ly:context-parent context)))
(if parent
(let ((parent-name (ly:context-name parent)))
(if (member parent-name spannable-contexts)
parent
(find-spannable-context parent)))
#f)
#(define (move-arpeggio-generic origin destination)
;; origin and destination are contexts
(let* ((Arpeggio (ly:context-grob-definition origin 'Arpeggio))
(X-extent (assoc 'X-extent Arpeggio))
(stencil(assoc 'stencilArpeggio))
(arpeggio-direction (assoc 'arpeggio-direction Arpeggio))
(direction (assoc 'direction Arpeggio))
(dash-definition(assoc 'dash-definitionArpeggio))
(props `((X-extent . ,X-extent)
(stencil. ,stencil)
(arpeggio-direction . ,arpeggio-direction)
(direction . ,direction)
(dash-definition. ,dash-definition
(for-each
(lambda (prop)
;; copy .Arpeggio props to .Arpeggio
(if (cdr prop)
(ly:context-pushpop-property destination
'Arpeggio
(cadr prop)
(cddr prop))
(ly:context-pushpop-property destination
'Arpeggio
(car prop)))
;; revert .Arpeggio props
(ly:context-pushpop-property origin 'Arpeggio (car prop)))
props)))
#(define (move-arpeggio-to-spannable-context context)
;; move the active arpeggio properties to the closest GrandStaff,
;; PianoStaff, or StaffGroup parent that can be found.
(let ((target (find-spannable-context context)))
(if target (move-arpeggio-generic context target
#(define (move-arpeggio-to-this-context context)
;; move any arpeggio props, active in a parent context where
;; 'connectArpeggios is #t, to this context (usually Voice).
(let ((origin (ly:context-property-where-defined context
'connectArpeggios)))
(if (and (not (null? origin))
(eq? #t (ly:context-property origin 'connectArpeggios)))
(move-arpeggio-generic origin context
#(define (connect-arpeggios-switch value)
(lambda (context)
(let ((target (find-spannable-context context)))
(if target
(ly:context-set-property! target 'connectArpeggios value)
(ly:warning "No viable context found for connectArpeggios")
connectArpeggiosOn = {
\applyContext #move-arpeggio-to-spannable-context
\applyContext #(connect-arpeggios-switch #t)
}
connectArpeggiosOff = {
\applyContext #move-arpeggio-to-this-context
\applyContext #(connect-arpeggios-switch #f)
}
arpeggioArrowUp =
\applyContext
#(arpeggio-generic `(stencil
X-extent
(arpeggio-direction . ,UP)))
arpeggioArrowDown =
\applyContext
#(arpeggio-generic `(stencil
X-extent
(arpeggio-direction . ,DOWN)))
arpeggioNormal =
\applyContext
#(arpeggio-generic '(stencil
X-extent
arpeggio-
Re: "anchors" in the music stream?
>> > IIUC, one interesting advantage of this is that scheme symbols >> > have less restrictions than parser identifiers: >> > >> > \anchor #'m.32 >> > \anchor #'flute2-entrance >> >> Mhmm, this is not something we should advertize loudly... > > Why not? I believe it confuses users that Scheme code allows more symbols compared to LilyPond code. It should be mentioned in the docs, of course. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote: > Hopefully there are no more snafus, but I need you guys to test this. > Let me know if you find any problems. I'd like to apply this if the > developers approve. In the file attached to the previous post http://lists.gnu.org/archive/html/lilypond-devel/2009-08/txtDIrSYMGg1c.txt one small (but important) correction needs to be made. In the definition for "move-arpeggio-to-this-context", 8 lines down, this line: (let* ((Arpeggio (ly:context-grob-definition context 'Arpeggio)) should instead read: (let* ((Arpeggio (ly:context-grob-definition parent 'Arpeggio)) Thanks to Jonathan Wilkes for catching this (on -user). http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00059.html Otherwise, does this look good? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "anchors" in the music stream?
Werner LEMBERG wrote: > > IIUC, one interesting advantage of this is that scheme symbols > > have less restrictions than parser identifiers: > > > > \anchor #'m.32 > > \anchor #'flute2-entrance > > Mhmm, this is not something we should advertize loudly... Why not? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "anchors" in the music stream?
> IIUC, one interesting advantage of this is that scheme symbols > have less restrictions than parser identifiers: > > \anchor #'m.32 > \anchor #'flute2-entrance Mhmm, this is not something we should advertize loudly... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
Trevor Daniels wrote: Mark Polesky wrote Thursday, July 30, 2009 7:06 PM It would be nice to have some central place that explains some "internals" concepts. Here are examples of things that a new developer might have to ask about, or perhaps spend a long time disentangling: grob prob smob output-def callback simple-closure It would be nice to have a LilyPond-specific glossary, that users could also use. For example, a user might get "glyph" and "stencil" confused. I still get "command" "keyword" "identifier" and "variable" confused. I still don't know the difference between "parser" and "lexer". You get the idea. Any thoughts? It would be a helpful addition. The best place would be another appendix to the NR. The only alternative would be the CG, but this would not be helpful to users. As it's a glossary, including terms which users don't ever need would not a problem, I think. (The LM is too simplistic for this, the MG is for musical terms and the AU is not appropriate.) Maybe Technical glossary would be a better term? But we need to wait for more comments before taking any action. Trevor +10 As these are all things for helping developers to get up to speed, I think they fit best in the CG. Cheers, Ian --- Begin Message --- Trevor Daniels wrote: Mark Polesky wrote Thursday, July 30, 2009 7:06 PM It would be nice to have some central place that explains some "internals" concepts. Here are examples of things that a new developer might have to ask about, or perhaps spend a long time disentangling: grob prob smob output-def callback simple-closure It would be nice to have a LilyPond-specific glossary, that users could also use. For example, a user might get "glyph" and "stencil" confused. I still get "command" "keyword" "identifier" and "variable" confused. I still don't know the difference between "parser" and "lexer". You get the idea. Any thoughts? It would be a helpful addition. The best place would be another appendix to the NR. The only alternative would be the CG, but this would not be helpful to users. As it's a glossary, including terms which users don't ever need would not a problem, I think. (The LM is too simplistic for this, the MG is for musical terms and the AU is not appropriate.) Maybe Technical glossary would be a better term? But we need to wait for more comments before taking any action. Trevor +10 As these are all things for helping developers to get up to speed, I think they fit best in the CG. Cheers, Ian --- End Message --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
Trevor Daniels wrote: Mark Polesky wrote Thursday, July 30, 2009 7:06 PM It would be nice to have some central place that explains some "internals" concepts. Here are examples of things that a new developer might have to ask about, or perhaps spend a long time disentangling: grob prob smob output-def callback simple-closure It would be nice to have a LilyPond-specific glossary, that users could also use. For example, a user might get "glyph" and "stencil" confused. I still get "command" "keyword" "identifier" and "variable" confused. I still don't know the difference between "parser" and "lexer". You get the idea. Any thoughts? It would be a helpful addition. The best place would be another appendix to the NR. The only alternative would be the CG, but this would not be helpful to users. As it's a glossary, including terms which users don't ever need would not a problem, I think. (The LM is too simplistic for this, the MG is for musical terms and the AU is not appropriate.) Maybe Technical glossary would be a better term? But we need to wait for more comments before taking any action. Trevor +10 As these are all things for helping developers to get up to speed, I think they fit best in the CG. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Mark Polesky wrote: Han-Wen Nienhuys wrote: No. In the specific case, I'd recommend making another music function that takes an argument, so you can pass the 15/16 explicitly, without mucking with variables. So it sounds like you believe that one way or another, the burden should be on the user. Then do you think we should add a warning in the docs, something like this? "When the value of such a variable is changed in a .ly file, the change is global, and unless explicitly reverted, the new value will persist to the end of the file, affecting subsequent \score blocks as well as external files added with the \include command. This can lead to unintended consequences (if a variable is not explicitly reverted). Especially in complex typesetting projects, these types of errors can be difficult to track down." Would this be something to add to LM 5.2.2 "Common errors"? I suppose we could also explain (in the docs) how to devise (in general) a custom music-function with the extra argument as youidea described, but this is a little trickier than simply pointing users to NR 6.1.3 "Paired substitution functions". Rewriting the music-function involves not only finding the location of its definition in the distribution files, but also manipulating the scheme code -- far more advanced than explicitly reverting the value, but much safer. What do you think? To me, as a newbie looking at the Scheme code, I think these are kludges and therefore suck. If you are going to write document the restriction as a "Common Error" and in LM 5.2.2 there should be big TODO comments in the code and a tracker to say that some (or all) of these variables need to be scoped by \score blocks, as Mark suggested. See comments below for further info. ** By the way, the number of "parser variables" susceptible to this situation may be quite small. I grepped "(ly:parser-lookup" and found these 12 variables: afterGraceFraction musicQuotes mode output-count output-suffix parseStringResult partCombineListener pitchnames toplevel-bookparts toplevel-scores showLastLength showFirstLength Of these 12, 5 were involved in examples (in the docs) showing how to modify the value from a .ly file: #(define afterGraceFraction (cons 15 16)) #(set! output-count 1) #(define output-suffix "violin") showFirstLength = R1*1 showLastLength = R1*5 <** Graham and Trevor alert**> At the very least, these need documenting in the CG, along with some comments on what they are for. I was able to work out output-count and output-suffix from the code in print-book-with, but I wouldn't have a clue where to look for where they are defined/where they are used in the code beyond what Mark has produced here. Any offers to lighten the Frogs' darkness? OK, here's the reason I feel strongly on this: I've been looking at the low-level trackers regarding output filenames. In the lilypond code we assume that there is only one output filename of each type which is produced when compiling a lilypond source (and the files it \includes). Each lilypond source file has to have at least one \source block, and if the user doesn't code it, the compiler assumes an implicit one during compilation. The compiler assumes that the filename part of the source file, or if specified, the --output argument value is what we use for producing the set of files for the \score block. So foobar.ly produces foobar.pdf (or foobar.svg or foobar.png) and maybe foobar.mid/foobar.midi. However there's a real problem that opens up once we allow more than one \score block in each source file: while the graphical back-ends (pdf, svg, png} etc. append the output for each \score to the original, the \midi block produces a separate file, which is the reason for the output-count and output-suffix parser variables. This is so the print-book-with Scheme function in lily-library.scm can play around with them and add a sequential number to to each filename for the midi files produced. I think the sequence number idea using parser variables was a rough-and-ready solution to prevent successive \midi blocks within a \score from over-writing the midi block from a previous \score. However the assumption that parser-variables-only-apply-to-things-at-outermost-score-level was left in place. I've been trying to look at this problem but to allow either a property within the \midi block or a function to allow users to specify a specific filename for that \score section or specify the output-suffix for that section, and before I went on holiday was that print-book-with function was only called once per compilation, so it seemed I was up against a brick wall without guidance from a grown-up developer, and I believed properties attached to \score within a \bookpart were inheritable and scoped, and Han-Wen appears to be saying they're not. I think they need to be, hence why I agree with Mark's original proposal. I reckon output-suffix (at least) needs t
Re: Directory structure for docs and web site
Le mardi 04 août 2009 à 05:06 -0700, Graham Percival a écrit : > Look, I was sole maintainer of the docs for 4 years. A few times, > I took a look at the build process because I wanted something or > other changed. Each time, I abandoned the idea after a few hours, > because I was getting nowhere. You could do it, but it's a bit more of effort. I could facilitate this effort by documenting the makefiles inline and the overall infrastructure in the CG, but the time I have for this is currently completely absorbed by dicsussions about the building process. If you think it's worth documeting the makefiles, please either add everything I recently told you and will tell you about the building process as makefiles comments or into the CG, or leave it up to me and stop thinking out loud on the list on how the building infrastructure works (and I don't want to snob you by ignoring such questions). > There's a great quote, I think by somebody Kernighan: "Debugging > is twice as hard as writing the program in the first place. So if > you write your code as cleverly as possible, how will you ever > debug it?" I guess, by documenting it properly? With all the repsect I have for Kernighan, I don't agree with writing less clever code just to make it easier to debug. There are well-known coding standards and rules (including proper code commenting) that still allow cleverness. > Now, it's safe to assume that reading somebody else's code is > twice as hard as reading your own code. And I think it's also > safe to assume that the next person to touch the build process > won't want to spend as long on it as you're willing to spend in > Aug. So the entire build process should be written 1/4 as > intelligently as you want to write it. I've already got one half by deciding not to merge makefiles for docs in English and translated docs, which would add another layer of complexity. Are you satisfied? :-) > I said I'd think about it. If we need any long pieces -- and I'm > not convinced we do -- then we might as well put them in LSR. But > I don't think we need to make any decisions about this yet, so > let's get other matters settled first. Agreed. > I'd suggest Documentation/general/examples/ ? Assuming the > manual is called general.texi, right? This is a bit too deep, we only need a separate to have specific makefile bits and not clutter Documentation/ nor general/. 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
2009/8/4 John Mandereau : > Le mardi 28 juillet 2009 à 16:39 +0200, Translation Project Robot a > écrit : >> A new POT file for textual domain 'lilypond' has been made available >> to the language teams for translation. It is archived as: >> >> http://translationproject.org/POT-files/lilypond-2.13.3.pot > >> >> http://download.linuxaudio.org/lilypond/sources/v2.13/lilypond-2.13.3.tar.gz > > > Who sent the request to the TP that resulted in this notification? Not me. > The > POT file has not been updated since 2.12 besides copyright year, and the > source tarball is a bit old. > I don't mind if anybody takes over from me on this, but please do it > properly and at the right time. In this particular case, this request > to the TP was pretty useless besides pinging translators to review their > work on PO files, and it should have waited for new messages integration > (e.g. there might be new strings for spacing features?). The Spanish PO had only an untranslated (or perhaps fuzzy) string. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "anchors" in the music stream?
Jay Anderson wrote:
> global =
> {
> \time 4/4 s4*4*10
> \time 3/4 s4*3*5
> \time 7/4 s4*7
> \time 4/4 \anchor #'coda s4*4*10
> \bar "|."
> }
>
> \addAt #'coda \global {\tempo \markup "Extremely slow"}
IIUC, one interesting advantage of this is that scheme symbols
have less restrictions than parser identifiers:
\anchor #'m.32
\anchor #'flute2-entrance
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
Le mardi 04 août 2009 à 07:30 -0600, Carl Sorensen a écrit : > So, I have heartburn about regressions on the stable branch as indicated by > failure to pass the regtest. But I have no heartburn about "regressions" > that mean a complicated example that uses tweaks doesn't look right any > more. I agree with your point, and if I understand it well, it doesn't give a justification for not generating examples from the sources with binary from the sources. However, complicated examples are like real users scores, which shouldn't suffer from the need of syntax updates other what convert-ly can handle, in case we ever allow convert-lyable syntax changes in a stable branch -- IIRC we don't want to, do we? I think changes in formatting that make some tweaks no longer necessary imply should be handled by convert-ly, or alternatively should be pushed to a development branch. 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
Split ambitus engraver?
Hi, I use Lilypond to make diagrams of all the available notes on an accordion. For that I use a single system and switch from bass clef to violin clef (and it would also be feasible to use 8va and 8ve modifiers). Now the problem is that the ambitus is engraved using the first clef of the system, in this case the bass clef, and the upper range is just somewhere in the clouds. In this case it would be nicer if the ambitus were engraved with the actually used clefs for upper and lower range, so that one first depicts the lower part of the range (presumably with a dotted line at the top of the broken off ambitus line a bit above the system to indicate it reaching higher) with its original clef in smaller size, and then the upper range of the ambitus with its original clef in smaller size (with a corresponding dotted line pointing downwards to indicate it reaching some indefinite distance lower). If that is not comprehensible, I can try making a sketch and photographing it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
Le mardi 04 août 2009 à 06:58 -0700, Graham Percival a écrit : > Hmm, I suppose this would screw up the cross-references. Not at all, cross-references are defined in macros.itexi. > I guess we'll just expect users > looking at a pdf tarball to open up "general.pdf" first. We don't care so much about the name, as long as said PDF is easily reachable from a HTML documentation central, i.e. Manuals page, I guess. > More importantly, this screws up the "info lilypond" idea. We have already foo -> lilypond-foo almost manual renaming for many manuals, we can have one more renaming. My concern was about building docs, not naming Info output. > ... just a moment. *why* do we have a lilypond/ info dir being > created? Look for INFO_IMAGES_DIR stuff. BTW it's not a directory, it's a symlink. > Isn't that just because notation.tely contains > @setfilename lilypond.info > (IIRC)? No, this is rather because we want images for Info docs to be in a subdirectory of $(prefix)/share/info. Cheers, 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: git hang-ups
Trevor Daniels wrote: > Something must have happened between the last > time git worked and the first time it failed. > Anything you did during that time is a suspect. The only other things I can imagine: 1) my anti-virus software might have done something 2) my security might have been compromised by some outside attack No idea. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On Tue, Aug 04, 2009 at 12:00:40PM +0200, John Mandereau wrote: > Le mardi 04 août 2009 à 01:12 -0700, Graham Percival a écrit : > > Fair enough -- but could you add a post-build rule to rename > > general.info/pdf/html to lilypond.info/pdf/html ? > > Not worth the effort. DIY if you like. Hmm, I suppose this would screw up the cross-references. Mao, I see why you don't want to do it. I guess we'll just expect users looking at a pdf tarball to open up "general.pdf" first. More importantly, this screws up the "info lilypond" idea. ... just a moment. *why* do we have a lilypond/ info dir being created? Isn't that just because notation.tely contains @setfilename lilypond.info (IIRC)? Changing that should surely remove this weird lilypond/ dir, letting us renaming general.texi to lilypond.texi. > > I ran into problems with score line-width vs. complete paper > > width. In particular, it was the Vocal music example. > > I assume knowing/fixing the paper width is easy, isn't it? That's what I told Jonathan, but when I tried to make it work with aucun.ly, it didn't. Feel free to investigate and potentially file bug reports. As far as I was concerned, since I'd already made a fool out of myself for not getting it to work after two hours (after chiding him for an "ugly" solution), and Jonathan already had a working makefile that gave us the desired formatting, I went with his makefile. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: > Le mardi 04 août 2009 à 05:20 -0700, Graham Percival a écrit : > > But we don't require them for building the website on > > lilypond.org. > > Inkscape *is* required for building current web site from web branch > sources. But it's not required for the new web stuff. At least, it's not required for the "demonstration-of-concept" dir in web-gop. > As for lilypond, you have pressed for merging web branch into > the main source tree, so I assume docs include website, which means in > particular that lilypond will be available for building ly files. In the past, I pressed for merging the web into the main source tree. After a bit more experience with web-gop, I proposed the "separate, but integrated" web branch. I still think the texinfo editing should be on master, but I think that having a separate repo that doesn't require lilypond to create the website would be a good idea. I'm not at all certain that the owners of lilypond.org want us building lilypond there -- especially if we'd expect to build it (locally) for every stable release. > > Do you think we should abandon the hourly cron job? > > Honestly, that always struck me as a bit unnecessary; I wouldn't > > mind running a shell script to rsync a new website every few days. > > Agreed. This is heavier for people that have access to lilypond.org, > but OTOH this will avoid bugging you, Jan or Han-Wen on uploading > generated images from SVG for example. ... err, what does the "agreed" refer to? Were you agreeing that we shouldn't use an hourly cron job? Agreeing that we shouldn't do any website building on lilypond.org, and instead I would build the website locally and rsync whenever I felt like it? This won't "avoid bugging" me. > > Err, if we kept those 13 png files in git, the contributor > > wouldn't need to run "make generate-examples". > > But the innocent contributor would ask, "I updated the ly source", or > the impatient developer that updated an example would pester again "make > doc" not rebuilding the examples. I know both categories of people are > expected to read the CG, but let's not bug them unnecessarily with warts > like generated examples in sources. - we don't expect people to be changing those examples. - if they do, it will be so rare that I feel no worry whatsoever in telling them to read the CG. > > Eh? Why on earth would the Examples change for different > > languages? IIRC, we currently have French lyrics, Italian musical > > terms, German titles, Italian lyrics, an English instrument name, > > Italian instrument names, a Hungarian (?) title, Italian titles, > > some English lyrics and directions... if there was ever part of > > the docs that we could say "yeah, we really don't need any > > translations here", it would be the pngs on > > Introduction->Examples. > > I was thinking on annotated SVG examples, which should be created for > the essay BTW -- I believed Till had taken this over a while ago, but I > never got news about this. Do you mean the annotated SVGs in web->Introduction->Text input? > I have given enough justifications so that web site examples will be > generated from ly sources. As long as I'll have something to do with > docs building (which is until somebody can and is willing to take over > the translations management), I won't allow generated images from Ly > sources that are or could be present in the source tree, Ok, it's up to you. I still think it's not worth the effort involved, but it's up to you. Provided that lilypond.org doesn't need to build, or run, lilypond. If that means that I need to manually rsync an examples dir and/or the complete website, so be it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New mailing list for translators
Greetings everyone, as the -devel list tends to get crowded these days, John and I have opened a separate mailing list for documentation translators. You can subscribe and read the archives on http://lists.lilynet.net/translations To whomever is in charge of the translationproject.org LilyPond coordination: please update the address so that automatic robot-generated mails be send to translati...@lilynet.net instead of -devel. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On 8/4/09 4:00 AM, "John Mandereau" wrote: > Le mardi 04 août 2009 à 01:12 -0700, Graham Percival a écrit : > > > Yes, even power users could run lilypond and output-distance on entire > input file directories and detect changes in formatting. This is a goal > for 2.14, or more reasonnably after 2.14.0. > > >> Our word "stable" refers to the input syntax, so it still has >> meaning. I certainly admit that we want to avoid regressions in a >> stable branch, but we already have the regtests (which nobody >> looks at) for this purpose! > > Regtests comparisons should be enough to check the regtests, I don't > know if they still work. > > >> Yes. I mean, if somebody asked me "hey, want to break this now?", >> I'd say no, of course. But a regression occurs, I'm not going to >> cry. And more to the point, I'm not going to expend a lot of >> energy trying to ensure that no regressions occur. Given the lack >> of *other* people willing expend this effort, I don't think I'm >> unique in this regard. > > If you are willing to allow development on stable branch with accepting > regressions, then please put a big fat warning on the download page to > warn about this, otherwise we'll have many complaints from users. I > think allowing development with regressions in stable branch without > having working regtests comparison is unsane. > > I think that there are two different meanings for regressions, as I've followed this thread. The first is failed regression tests. We should not release stable with failed regression tests (and the regression test facility should allow us to easily do that testing). The second meaning is "failed complex examples, like we might see in the introduction". I think that complex example failures are a problem, not with the application, but with the example. As part of the documentation, we need to be sure that the examples are adjusted to work with the current lilypond version. But I don't think that making the examples work (as currently written) is a necessary part of updating the lilypond application. Over time, we improve things (like the spacing engine) which could make the layout change and eliminate (or change) the need for a specific tweak in a complicated example. The proper response there is to change the example, not to change the application, IMO. So, I have heartburn about regressions on the stable branch as indicated by failure to pass the regtest. But I have no heartburn about "regressions" that mean a complicated example that uses tweaks doesn't look right any more. Thanks for listening, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New template for 'lilypond' made available
Le mardi 28 juillet 2009 à 16:39 +0200, Translation Project Robot a écrit : > A new POT file for textual domain 'lilypond' has been made available > to the language teams for translation. It is archived as: > > http://translationproject.org/POT-files/lilypond-2.13.3.pot > > http://download.linuxaudio.org/lilypond/sources/v2.13/lilypond-2.13.3.tar.gz Who sent the request to the TP that resulted in this notification? The POT file has not been updated since 2.12 besides copyright year, and the source tarball is a bit old. I don't mind if anybody takes over from me on this, but please do it properly and at the right time. In this particular case, this request to the TP was pretty useless besides pinging translators to review their work on PO files, and it should have waited for new messages integration (e.g. there might be new strings for spacing features?). 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: Documentation language switch problem
Le mardi 04 août 2009 à 14:36 +0200, Reinhold Kainhofer a écrit : > > I see this too, but not on my build. It looks like @translationof > > commands are ignored on kainhofer.com, as I saw French page names. > > Hmm, this should work. I haven't updated texi2html for some days/weeks, > though... This is probably not the cause IMHO. > So, there is no auto-removal of "old" files (shouldn't make automatically > detect it when files need to be rebuilt???) It should, but docs building will remain a complete mess (i.e. non-clean builds are not warranted) for weeks. As a compromise, maybe you could have a daily cron job that and deletes any output in the build tree older than two days. > I suppose, I need to adjust my script > to the new dir structure :( ) Certainly. Cheers, 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: the "separate, but integrated" website proposal
Le mardi 04 août 2009 à 05:20 -0700, Graham Percival a écrit : > ... at the very minimum, we could omit the news on the home page > (that would require one macro/conditional thingie in > general.texi), I want to restore and fix the RSS feed, so I merge news-* into a single source file for import into master. > If you're planning on making one monolithic patch, then of course > you should add yourself to the list. :) It won't be monolithic, I'll import things gradually as I manage to cleanly integrate them into the main source tree. > But we don't require them for building the website on > lilypond.org. Inkscape *is* required for building current web site from web branch sources. As for lilypond, you have pressed for merging web branch into the main source tree, so I assume docs include website, which means in particular that lilypond will be available for building ly files. > Do you think we should abandon the hourly cron job? > Honestly, that always struck me as a bit unnecessary; I wouldn't > mind running a shell script to rsync a new website every few days. Agreed. This is heavier for people that have access to lilypond.org, but OTOH this will avoid bugging you, Jan or Han-Wen on uploading generated images from SVG for example. > Err, if we kept those 13 png files in git, the contributor > wouldn't need to run "make generate-examples". But the innocent contributor would ask, "I updated the ly source", or the impatient developer that updated an example would pester again "make doc" not rebuilding the examples. I know both categories of people are expected to read the CG, but let's not bug them unnecessarily with warts like generated examples in sources. The translations instructions have been so complicated that it's a miracle that three main manuals have been translated as much as the technical infrastructure in German and Spanish by only one person in each language; I'm trying to improve things by the end of August. > Eh? Why on earth would the Examples change for different > languages? IIRC, we currently have French lyrics, Italian musical > terms, German titles, Italian lyrics, an English instrument name, > Italian instrument names, a Hungarian (?) title, Italian titles, > some English lyrics and directions... if there was ever part of > the docs that we could say "yeah, we really don't need any > translations here", it would be the pngs on > Introduction->Examples. I was thinking on annotated SVG examples, which should be created for the essay BTW -- I believed Till had taken this over a while ago, but I never got news about this. I have given enough justifications so that web site examples will be generated from ly sources. As long as I'll have something to do with docs building (which is until somebody can and is willing to take over the translations management), I won't allow generated images from Ly sources that are or could be present in the source tree, which of course excludes images generated by old Lily versions. 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: Documentation language switch problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 2. August 2009 20:00:56 schrieb John Mandereau:
> Le dimanche 02 août 2009 à 19:00 +0200, Jean-Charles Malahieude a
>
> écrit :
> > For the first point: you'll notice it when you choose a language other
> > than English on the root page and then navigate into one of the manuals.
>
> I see this too, but not on my build. It looks like @translationof
> commands are ignored on kainhofer.com, as I saw French page names.
Hmm, this should work. I haven't updated texi2html for some days/weeks,
though...
> There also seems to be a mix of output files from last build and stalled
> output files.
Hmm, this morning the build failed, but it it ran without problems the days
before.
> Reinhold, do you usually do clean builds, or at least do you have a cron
> job that remove files older than a fixed age in out/ and out-www?
No, I don't do clean builds to keep the CPU usage down.
The script simply does:
- -) a git pull and call "make" to build the binary
- -) remove Documentation/{devel/,}out-www/index*html
- -) rm Documentation/user/out-www/lilypond{,-program,-learning,-internals}.*
- -) rm Documentation/topdocs/out-www/*.texi
- -) rm input/lsr/out-www/lilypond-snippets.*
- -) call "make doc"
- -) copy the out-www/offline-root over to the web directory.
So, there is no auto-removal of "old" files (shouldn't make automatically
detect it when files need to be rebuilt???), and the build is anything else
than clean.
If there are larger changes (like your shuffling around of documentation/user),
I usually do a clean build manually (and I suppose, I need to adjust my script
to the new dir structure :( )
> And do you usually rebuild lilypond binary (including scripts/) before the
> docs?
Yes. I call make in the top dir after pulling
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)
iD8DBQFKeCtFTqjEwhXvPN0RAnEXAJ0bANAP/XnVEjIMvmtvY06rPkNvuwCghL5+
RyBzD9vHjpetgk9LyMmnDhM=
=5CZ0
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On Tue, Aug 04, 2009 at 12:55:05PM +0200, John Mandereau wrote: > Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit : > > I thought the website was going to be built from the stable > > branch? If we're doing that, then let's delete the web branches. > > This just made me come to mind that I'm for not including News in > generated offline docball: if we did, it would either > — require calling docs generation from GUB twice, once for the actual > build, once more for adding a news entry, > — require you to commit to Git a news entry then revert it in case you > notice the build can't make a release. > > There may be other sneaky side effects of merging all of the web site > into the main sources, but I haven't notice them. Hmm. If that's the only issue, I'm sure we can find a solution. ... at the very minimum, we could omit the news on the home page (that would require one macro/conditional thingie in general.texi), but leave the "Old news" in Community. I mean, nobody could complain about "Old news" not having the current release, right? :) Alternately, the announcement could be committed (to master). Then I could attempt to build. If the build fails, then I yell at people, but leave the announcement in git master -- after all, we'll make a 2.x.y release *eventually*. If the build succeeds, _then_ I backport that commit to stable, which updates the website. > > Overall structure by Graham, with many comments and suggestions > > from -user. Patrick McCarty worked extensively on the css and its > > integration with texinfo. Jonathan worked on the Introduction. > > Patrick Schmidt did further work on the CSS and the Old news page. > > > > I won't but I could add "makefiles and input files organization by > John". I assumed that would be obvious in all the successive patches you made after the import from web-gop. I mean, I figured the import from web-gop would be one patch, then you'd spend anywhere between 1 to 10 patches sorting out the modifications to the build process. If you're planning on making one monolithic patch, then of course you should add yourself to the list. :) > Most of the building infrastructure of the web site is yet to be > done, so don't expect much of lilypond-general output to look good on > master tonight: No problem. > About the discussion on generating examples, let's remember that > generated files in the sources are evil and should be reduced to the > bare minimum. Oh, totally agreed. The only question is whether this qualifies as the bare minimum. :) > We already require lilypond and inkscape for the full > docs build, so let's use them also to generate pictures for the web > site. But we don't require them for building the website on lilypond.org. Do you think we should abandon the hourly cron job? Honestly, that always struck me as a bit unnecessary; I wouldn't mind running a shell script to rsync a new website every few days. > Do you realize how complicated would be the docs building process > for the packager or simple contributor if instead of 'make doc', he had > to cd into a lot of directories directories to call 'make > generated-examples', 'make examples' and whatever? Err, if we kept those 13 png files in git, the contributor wouldn't need to run "make generate-examples". > If we allowed this, > all those secondary targets would also have to generate examples for all > languages; on a long-term perspective, I let you imagine the burden it > would add to commit to Git generated files for 20 languages(I agree that > 20 is optimistic :-) Eh? Why on earth would the Examples change for different languages? IIRC, we currently have French lyrics, Italian musical terms, German titles, Italian lyrics, an English instrument name, Italian instrument names, a Hungarian (?) title, Italian titles, some English lyrics and directions... if there was ever part of the docs that we could say "yeah, we really don't need any translations here", it would be the pngs on Introduction->Examples. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory structure for docs and web site
On Tue, Aug 04, 2009 at 12:22:02PM +0200, John Mandereau wrote: > Le lundi 03 août 2009 à 05:57 -0700, Graham Percival a écrit : > > They complicate the build process > > even more. > > I'm not sure what this means, but it's hard to scare me with the build > process. That's the biggest thing that scares me. Look, I was sole maintainer of the docs for 4 years. A few times, I took a look at the build process because I wanted something or other changed. Each time, I abandoned the idea after a few hours, because I was getting nowhere. Yes, you and Jan and Han-Wen -- although I'm not positive about the last two -- know how the doc build and translation stuff works. But that doesn't fill me with glee. Next year, you're going to be doing less lilypond work, and the other two are already doing less than they did a few years ago. Are we going to end up with another case where none of the actively-working doc people are too scared to touch the doc build system for another 4 years? There's a great quote, I think by somebody Kernighan: "Debugging is twice as hard as writing the program in the first place. So if you write your code as cleverly as possible, how will you ever debug it?" Now, it's safe to assume that reading somebody else's code is twice as hard as reading your own code. And I think it's also safe to assume that the next person to touch the build process won't want to spend as long on it as you're willing to spend in Aug. So the entire build process should be written 1/4 as intelligently as you want to write it. > > Wow, you're right. Some files in input/ are included, others > > aren't. Some dirs in input/mutopia/ are included, others aren't. > > What a maoing mess! > > Let's not bury input/ and input/mutopia too quickly, I said I'd think about it. If we need any long pieces -- and I'm not convinced we do -- then we might as well put them in LSR. But I don't think we need to make any decisions about this yet, so let's get other matters settled first. > or please tell me a > new directory name for the examples .ly sources... > Documentation/examples? I'd suggest Documentation/general/examples/ ? Assuming the manual is called general.texi, right? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adjusting "Piano centered dynamics" template and "Les Néréides"
On Tue, Aug 04, 2009 at 12:58:02PM +0200, Valentin Villenave wrote: > A lot of users have been using a user-defined Dynamics context for > years. How about making convert-ly print a warning whenever it finds a > Dynamics context in a score? No. Put a warning in changes.itely (the new NEWS), and that's it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adjusting "Piano centered dynamics" template and "Les Néréides"
2009/7/31 Joe Neeman : > It should be sufficient to simply remove the definition of the Dynamics > context from these files (and the \accepts Dynamics part from > PianoStaff). The default Dynamics context is very similar (and drew > heavily from) the piano dynamics template, so it should be a drop-in > replacement. A lot of users have been using a user-defined Dynamics context for years. How about making convert-ly print a warning whenever it finds a Dynamics context in a score? Something such as: "Warning: Please check if the user-defined Dynamic context is still needed, as recent versions of LilyPond implement it by default" Or a less verbose NOT_SMART_ENOUGH thingy... Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit : > I thought the website was going to be built from the stable > branch? If we're doing that, then let's delete the web branches. This just made me come to mind that I'm for not including News in generated offline docball: if we did, it would either — require calling docs generation from GUB twice, once for the actual build, once more for adding a news entry, — require you to commit to Git a news entry then revert it in case you notice the build can't make a release. There may be other sneaky side effects of merging all of the web site into the main sources, but I haven't notice them. > Overall structure by Graham, with many comments and suggestions > from -user. Patrick McCarty worked extensively on the css and its > integration with texinfo. Jonathan worked on the Introduction. > Patrick Schmidt did further work on the CSS and the Old news page. > I won't but I could add "makefiles and input files organization by John". Most of the building infrastructure of the web site is yet to be done, so don't expect much of lilypond-general output to look good on master tonight: as a docs build maintainter, my priority is having a clean docs building infrastructure over working output, even for the initial commit. This is a bit uncomfortable, but as the generated web site won't be made widely available (only a link from the old Documentation index for next devel release?) and there are still a few weeks before next stable release, this is fair. About the discussion on generating examples, let's remember that generated files in the sources are evil and should be reduced to the bare minimum. We already require lilypond and inkscape for the full docs build, so let's use them also to generate pictures for the web site. Do you realize how complicated would be the docs building process for the packager or simple contributor if instead of 'make doc', he had to cd into a lot of directories directories to call 'make generated-examples', 'make examples' and whatever? If we allowed this, all those secondary targets would also have to generate examples for all languages; on a long-term perspective, I let you imagine the burden it would add to commit to Git generated files for 20 languages(I agree that 20 is optimistic :-) Cheers, 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: "anchors" in the music stream?
2009/8/4 Han-Wen Nienhuys : > I can imagine how this would be implemented, but it would be a lot of > work. If anyone is up for a challenge, I can give some pointers. :) OK, now there's no way I'm gonna let you get away with such a promise :-) http://code.google.com/p/lilypond/issues/detail?id=824 Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory structure for docs and web site
Le lundi 03 août 2009 à 05:57 -0700, Graham Percival a écrit : > ok, I'm willing to go as far as adding a single "View sources" > link at the bottom of the page, which takes people to a > Snippets->Examples page. Of course, that would require adding the > Examples to LSR (or at least new/), requiring yet more build > hackery, and introducing more black magic that Jonathan and I > won't understand. Of course not, a simple link to the sources directory is enough IMHO. > ... you know, I *really* think that the examples should be left > alone. Yes, generated directly by calling LilyPond :-) > We don't want newbies looking at the source, because it'll > only confuse and scare them. That's true, but (the few) curious people should be satisfied too. > They complicate the build process > even more. I'm not sure what this means, but it's hard to scare me with the build process. > Wow, you're right. Some files in input/ are included, others > aren't. Some dirs in input/mutopia/ are included, others aren't. > What a maoing mess! Let's not bury input/ and input/mutopia too quickly, or please tell me a new directory name for the examples .ly sources... Documentation/examples? 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: the "separate, but integrated" website proposal
Le mardi 04 août 2009 à 01:12 -0700, Graham Percival a écrit : > Yes, but what if somebody reads the LM, looks at the source, then > accuses us of lying when we claimed "no tweaks were used"? I > wouldn't blame that person at all! Of course, I rather meant lilyond-book trickery, which we probably shouldn't use lilypond-book for the examples (see below). > You mean "download these PDF" links? Ick, this is rapidly > becoming complicated. It shouldn't be more complicated than the old Examples page, but Python scripting will be replaced by Texinfo macros you started defining. > The point of Examples is to showcase our > features... ok, it seems like dumping these into LSR and including > them in Snippets makes more sense. That'll give you the desired > source and pdf generation. After a bit of thinking, it would be easier to call lilypond directly, as it's currently done for the old Examples. > Just how much time do you want to spend on buildscript in Aug? You mean until December? ;-) More seriously, I'd like to get done with build system janitoring at the beginning of September, then move to more interesting aspects of development. > This is going to add yet more complexity -- to GUB, as well as the > lilypond build scripts. Seriously, I think this would add at > least 20 hours to your workload. All just to generate 13 png > images in an alternate way? Is that /really/ a good idea? > > Since 2.13.4 is being held up because GUB is broken, I don't think > that extra complexity is a great idea. Yes, even power users could run lilypond and output-distance on entire input file directories and detect changes in formatting. This is a goal for 2.14, or more reasonnably after 2.14.0. > Our word "stable" refers to the input syntax, so it still has > meaning. I certainly admit that we want to avoid regressions in a > stable branch, but we already have the regtests (which nobody > looks at) for this purpose! Regtests comparisons should be enough to check the regtests, I don't know if they still work. > Yes. I mean, if somebody asked me "hey, want to break this now?", > I'd say no, of course. But a regression occurs, I'm not going to > cry. And more to the point, I'm not going to expend a lot of > energy trying to ensure that no regressions occur. Given the lack > of *other* people willing expend this effort, I don't think I'm > unique in this regard. If you are willing to allow development on stable branch with accepting regressions, then please put a big fat warning on the download page to warn about this, otherwise we'll have many complaints from users. I think allowing development with regressions in stable branch without having working regtests comparison is unsane. > Fair enough -- but could you add a post-build rule to rename > general.info/pdf/html to lilypond.info/pdf/html ? Not worth the effort. DIY if you like. > I ran into problems with score line-width vs. complete paper > width. In particular, it was the Vocal music example. I assume knowing/fixing the paper width is easy, isn't it? 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: git hang-ups
Mark Polesky wrote Tuesday, August 04, 2009 9:23 AM Does anyone know -- is there any harm in just generating a new SSH key pair? No harm at all. I think my modem gives me a different IP address from time to time. It (well, your ISP) will - that's normal. I could be making that up, and I don't know if that would even affect the SSH stuff. It won't affect it at all. But I'm willing to try anything at this point. Would generating a new key pair cause problems? No, but I doubt it will fix anything either. Did rebuilding the repository have no effect? BTW your env variables seem normal, so no help from there, I'm afraid. Something must have happened between the last time git worked and the first time it failed. Anything you did during that time is a suspect. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
On Tue, Aug 04, 2009 at 01:23:11AM -0700, Mark Polesky wrote: > Does anyone know -- is there any harm in just generating a new > SSH key pair? Absolutely no problems. Go ahead. > I think my modem gives me a different IP address > from time to time. I could be making that up, and I don't know > if that would even affect the SSH stuff. Most ISPs deliberately don't guarantee IP addresses, so it's quite reasonable that it would change. This won't effect SSH, though. But in the interest of problem elimination, definitely try generating a new key pair. Just remember that savannah needs an hour or so to update it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Does anyone know -- is there any harm in just generating a new SSH key pair? I think my modem gives me a different IP address from time to time. I could be making that up, and I don't know if that would even affect the SSH stuff. But I'm willing to try anything at this point. Would generating a new key pair cause problems? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
new repos: do we want an archive?
GUB won't be moved into lilypond git, and web stuff will live in master and stable. So currently we're only looking at creating one extra repo: g...@sv/lilypond/lilypad.git description: Lightweight editor for lilypond files However, I started wondering about all the old history that would be lost when we delete web/ and (to a much lesser extent) web-gop/. That also reminded me of dev/rune, which I find myself reluctant to delete. Any thoughts about creating a g...@sv/lilypond/archive.git description: Old material for lilypond repo, to store the old web/ branch, dev/rune, maybe the stable/1.x stuff, and generally anything that seems too old to be possibly useful in the main repo? Cheers, - GRaham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On Mon, Aug 03, 2009 at 08:51:55PM +0200, John Mandereau wrote: > Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit : > > Well, it depends how you define "tweak". In the LM, we lean > > pretty heavily on "tweak = \override and \set" (plus others). > > Some of those examples definitely *do* use tweaks! > > > > I'd rather keep the wiggle room and just say "look at these > > examples". Nobody will think that we loaded the images in gimp > > and changed things! > > I meant applying obscure covnersion steps, Yes, but what if somebody reads the LM, looks at the source, then accuses us of lying when we claimed "no tweaks were used"? I wouldn't blame that person at all! > but they will be difficult to avoid to obtain in the result. > This makes me remember we should add links to PDFs. You mean "download these PDF" links? Ick, this is rapidly becoming complicated. The point of Examples is to showcase our features... ok, it seems like dumping these into LSR and including them in Snippets makes more sense. That'll give you the desired source and pdf generation. > > I'd also rather keep the safety of *not* generating them for every > > stable release. > > GUB comparison tool output-distance is designed to check such changes > before releasing, so it could be used for examples too. Just how much time do you want to spend on buildscript in Aug? This is going to add yet more complexity -- to GUB, as well as the lilypond build scripts. Seriously, I think this would add at least 20 hours to your workload. All just to generate 13 png images in an alternate way? Is that /really/ a good idea? Since 2.13.4 is being held up because GUB is broken, I don't think that extra complexity is a great idea. > > - for X months, where X is as large as possible, the "stable" > > branch *is* the "main" branch, so there's more changes. > > I agree with this; however, changes that bring regressions should not be > accepted in stable branch but should be the starting point of a > development branch. If you don't have this policy, then the word > "stable" loses its meaning. Our word "stable" refers to the input syntax, so it still has meaning. I certainly admit that we want to avoid regressions in a stable branch, but we already have the regtests (which nobody looks at) for this purpose! > > - the examples will deliberately do fancy stuff; a small change to > > a spacing algorithm or improved slur shape might result in a > > manually-placed fingering causing a collision. > > Would you allow any regressions in stable releases? Yes. I mean, if somebody asked me "hey, want to break this now?", I'd say no, of course. But a regression occurs, I'm not going to cry. And more to the point, I'm not going to expend a lot of energy trying to ensure that no regressions occur. Given the lack of *other* people willing expend this effort, I don't think I'm unique in this regard. > > I thought the website was going to be built from the stable > > branch? If we're doing that, then let's delete the web branches. > > This means importing all web stuff into the main source tree. This is > doable, but the part that will be done by hourly cron job will have to > be well distinct. This means much buildscripts hacking and janitoring, > but this is OK. Yes. > > Especially with a generic name like "pictures". Now, if it > > was "logos", or possibly "old-and-unused-and-current-logos", then > > I'd agree. > > I'm lazy about moving directories except with strong justifications. If > you really want to, I tell you a recipe for next time: Thanks, I've used it, and I'll definitely keep this around for any future changes. > Noted. I'll work on something clean enough from a source files and > directory perspective and push general.texi (sorry, there is a directory > named lilypond/ for Info docs with images build, and I don't want to do > special casing for MANUAL_SUBDIRS) and its inclusions tomorrow if > everything goes well. Fair enough -- but could you add a post-build rule to rename general.info/pdf/html to lilypond.info/pdf/html ? I kind-of expected that the source file couldn't be "lilypond". > > > I'll hack lilypond-book to produce snippets with preview images > > > and "click to enlarge/click to see the complete score" links. > > > > ... I'm still really iffy about this. Both Jonathan and I spent a > > few hours trying to force lilypond to create images with a > > specific pixel width (600 pixels, IIRC -- see > > texinfo/examples/GNUmakefile). We both failed. > > Ugh. Lilypond already resizes in a similar way as what you put in > $(SCALE), why don't you calculate the appropriate -dresolution value? I ran into problems with score line-width vs. complete paper width. In particular, it was the Vocal music example. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Mon, Aug 03, 2009 at 03:19:54PM -0600, Andrew Hawryluk wrote: > 2009/8/3 John Mandereau : > > No, there isn't. Having pictures in respective manual directories would > > create more Git history noise and more ad-hoc include path > > specifications for images shared between several manuals. Put them in > > Documentation/pictures without specifying any path in @image command, > > I'll add this directory along with the web site. > > I moved the existing essay images and it builds fine (except for the > multi-page HTML version, but you may already know about that issue). > Patch attached (201k will be too big for the -devel list). Well, pictures/ should actually be logo/. I'm testing this change right now. Once that's cleaned up, either John or I will see about moving those files from Documentation/ to Documentation/pictures/, but it's a bit more complicated than simply moving the files. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation of `after-title-spacing' is missing
On Mon, 2009-08-03 at 13:28 +0200, Werner LEMBERG wrote: > The documentation of the new `after-title-spacing' property and its > siblings is missing. Additionally, there are no regression tests > showing those parameters in action. Thanks, I'll add this to my todo list. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
