out-of-tree documentation build
Does anybody feel like working on the out-of-tree documentation build? That's the current release blocker, but you don't need GUB around to build it. mkdir ~/whatever/ cd ~/whatever /path/to/git/configure --srcdir ~/path/to/git/ make make doc then debug. Currently it's not finding version.itexi in Documentation/out-www/ ... it gets built in Documentation/out/. There's probably half a dozen such little problems. If nobody wants to do it, I'll continue working on it in 23 hours. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote Sunday, September 20, 2009 8:26 PM I was confused because Joseph keeps on talking about wanting to copy "code" from the documentation, and Trevor Daniels recently said "you know what? you guys are nutters. Do whatever you want with my stuff, now shut up and do work". ... ok, he didn't say that. But it would have been awesome if he *had* said that. Not quite my style, but it does clarify my meaning ;) For example, we seem to have lost Joseph's really promising work to document contemporary music. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Trevor Daniels wrote: > For example, we seem to have lost Joseph's really > promising work to document contemporary music. Not lost. :-) Actually, the delay came at least in part because I was looking through problems of functionality related to my docs. I'll post about this on -user. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
In message <200909201334.52063.reinh...@kainhofer.com>, Reinhold Kainhofer writes The LGPLv3 also includes the patents clause and the anti-DRM clause, which both add additional restrictions, which the GPLv2 does not have. On the other hand, all lilypond contributors -- by putting their code under GPLv2only -- explicitly say that they do not agree to any additional restrictions. Oops - haven't you got that backwards? If they put it under v2 ONLY, aren't they saying they don't agree to any additional FREEDOMS Thus lilypond can't link to any (L)GPLv3 library, which would add additional restrictions. such as allowing it to be distributed under v3? (Yes I know I'm being a pedant! But that's why I think demanding contributors use v2 *only* is a bad idea. You're saying they can't grant *more* *freedom* (if that's what they want).) Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On Mon, Sep 21, 2009 at 2:34 AM, Carl Sorensen wrote: > I think that we shouldn't yet add a tracker for the general solution. We're > still working on the output-suffix issues, which might have a more general > solution. No problem, as long as you're still patient enough to keep track of the whole thing. If not, please do give me a ping :-) Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 21. September 2009 18:49:18 schrieb Anthony W. Youngman: > In message <200909201334.52063.reinh...@kainhofer.com>, Reinhold > Kainhofer writes > > >The LGPLv3 also includes the patents clause and the anti-DRM clause, which > >both add additional restrictions, which the GPLv2 does not have. > > > >On the other hand, all lilypond contributors -- by putting their code > > under GPLv2only -- explicitly say that they do not agree to any > > additional restrictions. > > Oops - haven't you got that backwards? If they put it under v2 ONLY, > aren't they saying they don't agree to any additional FREEDOMS Both are right: They don't agree to additional FREEDOMS in the sense that the "user" is not free to choose GPLv2 or GPLv3, but they also don't agree to additional RESTRICTIONS: Using GPLv3 would add an additional restriction to the use (DRM, atent claues) and this is prohibited by GPLv2only. All users are be free to use GPLv2 applications in tivo-like machines and that freedom is whatI'm talking about. > >Thus lilypond can't link to any (L)GPLv3 library, which would add > > additional restrictions. > > such as allowing it to be distributed under v3? No byt linking to a LGPLv3 library, this does not require the application to be GPLv3. However, the LGPLv3 says that you can only link to it if you agree to the DRM- and patent clauses. That's the additional restrictions that LGPLv3 has compared to GPLv2. Thus linking to a LGPLv3 library takes aways rights (e.g. to legally prevent access by using DRM or to sue for patent infringement) that the GPLv2 provided. > (Yes I know I'm being a pedant! But that's why I think demanding > contributors use v2 *only* is a bad idea. So do I! I contribute to lilypond to support lilypond, not to be picky about copyrights. For example, I signed over all my KDE contributions to the KDE e.V. and additionally crossed out the paragraph that that contract becomes void under certain circumstances... Unfortunately, there is nothing like that for Lilypond. I did these contributions to support lilypond (and sometimes also because I needed them), so they should really help lilypond and not cause legal problems. > You're saying they can't grant > *more* *freedom* (if that's what they want).) The developers can of course grant more freedom to their own code. It's just that the default is GPLv2only and nobody cares about asking or explicitly giving more rights (which would result in a mess anyway, because you would need to track who changed which lines, etc.). 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) iD8DBQFKt9DWTqjEwhXvPN0RAlziAKCKDGKWRkYO9Bk8R7AkeIsLNEaU8gCgsVib Tzx7l+nikWxvJtPWHtn8y9c= =QWCl -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] New margin handling - final version (updated)
2009/9/20 Michael Käppler : > - your git master compiles without warning and with proper spacing (?, > please proof) Correct. I've just done a completely clean build, and it compiles without any problems (see attached output, which is taken from my local copy of this page: http://www.kainhofer.com/~lilypond/Documentation/general/Examples.html#Examples). As far as I can tell, it's identical to the kainhofer version. > - the example png at kainhofer.com looks fine, though I'm not sure if it's > compiled with git, since it's on the new website preview. Yep, it's a nightly build based on master, though only certain parts are rebuilt unless a clean build is forced (I doubt the Granados example is built from scratch every night). Regards, Neil <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
http://mattsmiley.blogspot.com/2009/09/2nd-day-of-crumb.html
Any takers? :-) -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: out-of-tree documentation build
2009/9/21 Graham Percival : > Does anybody feel like working on the out-of-tree documentation build? > That's the current release blocker, but you don't need GUB around to > build it. I'll give it a go, though I probably won't be much use when it comes to debugging any build problems. :) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
2009/9/19 Carl Sorensen : > Well, during the translation step the translators write output to the output > file using the appropriate output calls, don't they? So they make use of > the file that was created using the output-prefix. So this has *something* > to do with translation, even though it's not a characteristic of an > engraver. I don't think so, since the output file doesn't exist until a Paper_book object has been finalized and sent to the appropriate output framework. > This is part of the function of LilyPond that I don't understand. Maybe you > can help clarify it for me. Let me give my brief understanding. Seriously, I don't understand it either. :) > I think the third phase is engraving. During this phase, the music streams > are converted into printed objects, and sent to the appropriate output file. I think this phase is much more complicated than the other two, since there's a great deal of work going on after grobs have been created (e.g., line-breaking and page-breaking) before anything is dumped to an ouput file. > It would be convenient if the output-prefix could be defined in the /score > or /layout block that causes the creation of a Score context. I think > that's why Ian was wanting to make it a context property of Score. But I > suspect (although I can't prove) that the file handler exists *outside of*, > not inside of, the Score context. Hence, we don't want to make it a context > property of Score, because we could change the property inside of the Score, > and the file handler wouldn't know about it. I think this is the main stumbling block (leaving aside the issue of whether it's appropriate to store a file suffix at this point); I can't see any elegant (kludge-free) way of getting this information to the file handler. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On 9/21/09 2:38 PM, "Neil Puttock" wrote: > 2009/9/19 Carl Sorensen : > >> Well, during the translation step the translators write output to the output >> file using the appropriate output calls, don't they? So they make use of >> the file that was created using the output-prefix. So this has *something* >> to do with translation, even though it's not a characteristic of an >> engraver. > > I don't think so, since the output file doesn't exist until a > Paper_book object has been finalized and sent to the appropriate > output framework. OK, so what sends Paper_book objects to output frameworks? > >> This is part of the function of LilyPond that I don't understand. Maybe you >> can help clarify it for me. Let me give my brief understanding. > > Seriously, I don't understand it either. :) > >> I think the third phase is engraving. During this phase, the music streams >> are converted into printed objects, and sent to the appropriate output file. > > I think this phase is much more complicated than the other two, since > there's a great deal of work going on after grobs have been created > (e.g., line-breaking and page-breaking) before anything is dumped to > an ouput file. > I agree. My understanding is that first, grobs are created (and grobs are *not* ink on paper, they are scheme objects that will eventually be converted into ink on paper). Once grobs are created, layout happens (line breaking, page breaking, and collision resolution, I think). During layout, properties of grobs are changed, and new grobs are sometimes created. Then, once layout happens, Paper_book objects are sent to output framework where they are converted into output that will ultimately put ink on the page (e.g. postscript instructions, or svg instructions). Is this even close? >> It would be convenient if the output-prefix could be defined in the /score >> or /layout block that causes the creation of a Score context. I think >> that's why Ian was wanting to make it a context property of Score. But I >> suspect (although I can't prove) that the file handler exists *outside of*, >> not inside of, the Score context. Hence, we don't want to make it a context >> property of Score, because we could change the property inside of the Score, >> and the file handler wouldn't know about it. > > I think this is the main stumbling block (leaving aside the issue of > whether it's appropriate to store a file suffix at this point); I > can't see any elegant (kludge-free) way of getting this information to > the file handler. What do you think of Ian's suggestion to create pv-properties for parser variables? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On Mon, Sep 21, 2009 at 1:48 PM, Carl Sorensen wrote: > > On 9/21/09 2:38 PM, "Neil Puttock" wrote: > >> 2009/9/19 Carl Sorensen : >> >>> Well, during the translation step the translators write output to the output >>> file using the appropriate output calls, don't they? So they make use of >>> the file that was created using the output-prefix. So this has *something* >>> to do with translation, even though it's not a characteristic of an >>> engraver. >> >> I don't think so, since the output file doesn't exist until a >> Paper_book object has been finalized and sent to the appropriate >> output framework. > > OK, so what sends Paper_book objects to output frameworks? I think this occurs in Paper_book::output(), line 183. The self_scm() call applies to the Paper_book object, and this object becomes the 2nd argument in the call to output-framework. Thus the output frameworks have access to the Paper_book object. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
2009/9/19 Ian Hulin :
> Hi Carl, Neil,
>
> I'm quite happy to re-think the proposal if what I have in mind contravenes
> existing design architecture.
> Put it down to relative inexperience and the fact I don't get opportunity to
> work on lilly as often as I'd like.
>
> Anyhow, here are some of the reasons why I'd like to do something with this
> stuff:
>
> Using parser variables to configure things is evil, because it requires
> users to drop into Scheme to set the parser variable. I feel we need to
> replace #(define output-suffix "gibbon-vole-aardvark") with something
> handled at the lilypond language level.
This isn't strictly true, since it's possible to set it using LilyPond
syntax; the only issue is the parser requirement that the identifier
be enclosed in quotes to prevent the hyphen being misinterpreted:
"output-suffix" = "gibbon-vole-aardvark"
> So what I'd like to do is to have some way of replacing the Scheme
> definition either -
> \book {
> \set output-suffix "gibbon-vole-aardvark"
> {... \score blocks and things}
> }
This is a recipe for confusion, since the \set command is reserved for
context properties; users find it confusing enough that there are
distinct properties requiring \set and \override.
> , or
> \book \with {output-suffix = "gibbon-vole-aardvark"}
> {
> {... \score blocks and things}
> }.
A \book block doesn't instantiate a context, so you can't use (or
extend) \with here (in any case the parser expects either \new or
\context to come before \with, so you'd also have to do some serious
parser hacking).
> If you have any ideas for an architecturally cleaner solution which would
> allow users to avoid dropping into Scheme I'm open to suggestions.
Since the main issue appears to be the situation with \midi blocks, I
think the best option would be to set a midi-output-suffix within the
\midi block, though I'm not sure whether this is feasible.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On Fri, 2009-09-18 at 18:06 -0600, Carl Sorensen wrote: > It would be convenient if the output-prefix could be defined in the /score > or /layout block that causes the creation of a Score context. I think > that's why Ian was wanting to make it a context property of Score. But I > suspect (although I can't prove) that the file handler exists *outside of*, > not inside of, the Score context. Hence, we don't want to make it a context > property of Score, because we could change the property inside of the Score, > and the file handler wouldn't know about it. An important reason (the main reason?) we can't (or shouldn't?) define the file name in the score context is that there are often several scores in a file. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Texinfo macros without arguments
Hi everybody,
Recently I've been getting loads of error messages when building the
docs; they all relate to Texinfo macros which don't have arguments.
Here's a random example:
out-www//notation/repeats.texi:879: warning: @snippets defined with 0
arguments should be invoked with {}
I had a look at the Texinfo documentation, and it says such macros
should always include the braces when invoked, so should we change all
these invocations accordingly?
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Hi Joe, Joe Neeman wrote: On Fri, 2009-09-18 at 18:06 -0600, Carl Sorensen wrote: It would be convenient if the output-prefix could be defined in the /score or /layout block that causes the creation of a Score context. I think that's why Ian was wanting to make it a context property of Score. But I suspect (although I can't prove) that the file handler exists *outside of*, not inside of, the Score context. Hence, we don't want to make it a context property of Score, because we could change the property inside of the Score, and the file handler wouldn't know about it. An important reason (the main reason?) we can't (or shouldn't?) define the file name in the score context is that there are often several scores in a file. No. It's exactly the reason we *do* need to be able to do something with it. If a \score is set to produce midi output it produces one per score block. Midi files were getting were getting over-written which is the reason the original (numeric-only) version of output-prefix was developed. We either need to be able to do things which ape the context properties (use \override \revert) or have some separate midi-output-suffix property for the files to play with. For other graphical back-ends (.pdf .png etc) there is one file per \book block (even if its an implicit one). I did have kludgey idea to implement it but I'm still trying to get my head round the spate of responses which have just come in. I'm just off to play in the sandpit with this for a bit. . . Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: out-of-tree documentation build
2009/9/21 Graham Percival :
> Currently it's not finding version.itexi in
> Documentation/out-www/ ... it gets built in Documentation/out/.
Running as root, I've got version.itexi in both Doc*/out-www and
Doc*/out, but the build fails when processing out-www/general.texi:
./general.texi:0: Could not find image file pictures/out-www/double-lily-modifi
ed3 for pdf.
@dopdfimage ...uld not find image file #1 for pdf}
@else @gdef @pdfimgext {PD...
@imagexxx ...ndent @ifpdf @dopdfimage {#1}{#2}{#3}
@else @setbox 0 = @hbox
{...@...
@image ...true @fi @else @imagexxx #1,@finish
@fi
l.7 ...y-modified3},,,@xeatspaces {LilyPond logo}}
@scanmacro ...ceisspace @scantokens {...@endinput }
@endgroup
@imageIdxxx ...,,,@xeatspaces {#4}}...@end ifinfo}
@egroup
l.83 ...o,double-lily-modified3,png,LilyPond logo}
!pdfTeX error: pdfetex (file pictures/out-www/double-lily-modified3.): cannot f
ind image file
Regards,
Neil
> There's probably half a dozen such little problems.
> If nobody wants to do it, I'll continue working on it in 23 hours.
>
> Cheers,
> - Graham
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Beaming direction shorthand for manual beams
Hi, Here's a little patch which allows the use of direction tokens with manual beaming: http://codereview.appspot.com/120060/show Please review. Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texinfo macros without arguments
Neil Puttock wrote Monday, September 21, 2009 10:23 PM Recently I've been getting loads of error messages when building the docs; they all relate to Texinfo macros which don't have arguments. Has the version of texinfo you are using changed? I use texi2html, admittedly a very old version, for my local doc compiles and don't see this problem. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
On Sun, 20 Sep 2009, Graham Percival wrote: > Now, at some point, there will be some important bug fix or new > feature in guile 1.9, which is only published under v3. *Then* we'd > have problems... but wait! If guile is truly under LGPL, and not > GPL, then there should be no problems. I mean, if you can link to > closed-source apps (the whole point of LGPL), then surely a mere > GPLv2 app can still link to the library? The problem isn't with libguile being LGPLv3; the problem is with lilypond being GPLv2 only. The copyright infringement would be an infringement of lilypond's license, not libguile's. Lilypond would either need a linking exception to link with libguile (or ideally an exception to link with any GPLv2+ or LGPLv2+ work) or would need to change its licensing accordingly. All of which would require by-in from all of lilypond's contributors.[1] As far as distributions go, I know I personally don't want to maintain guile-1.8, so if at some point it stops being maintained in Debian,[2] someone else will have to step up and maintain it for us to continue distributing lilypond. Don Armstrong 1: This is YA example of why choosing GPLv2 only is a bad idea if all you want to do is get on with your coding; the worst thing that could happen in future versions of the GPL is that more rights were given instead of less, since anyone who wanted would always be able to use the code under GPLv2. 2: It's currently being maintained, but since I'm not doing the work, I can't guarantee that that will continue to be the case. -- Guns Don't Kill People. *I* Kill People. http://www.donarmstrong.com http://rzlab.ucr.edu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texinfo macros without arguments
Le lundi 21 septembre 2009 à 23:54 +0100, Trevor Daniels a écrit : > Has the version of texinfo you are using changed? I use texi2html, > admittedly a very old version, for my local doc compiles and don't > see this problem. Remember that the accepted Texinfo language depends on the Texinfo processor (texi2pdf/TeX, makeinfo or texi2thml). Waf will hopefully allow you to compile the documentation as we do on Unix-like systems. 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
Manual beaming forced directions (^[ & _[).
lgtm http://codereview.appspot.com/120060 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: out-of-tree documentation build
Le lundi 21 septembre 2009 à 09:12 +0100, Graham Percival a écrit : > then debug. Currently it's not finding version.itexi in > Documentation/out-www/ ... it gets built in Documentation/out/. I couldn't reproduce this error, but I hit a truckload of broken image paths, and hopefully fixed them. The image paths are were already a headache, but you made it worse by hardcoding out-www in the image path in the macro definitions, and I don't get why you didn't copy'n'paste $(outdir)/pcitures rule for $(outdir)/examples in Documentation/GNUmakefile. Doc build out of source tree still fails, you might want to make search-box.html looked up through include path in web-texi2html.init using the appropriate routine. """ PERL_UNICODE=SD texi2html --prefix=index --split=node --node-files --I=/home/lilydev/git/lily/Documentation --I=./out-www -I /home/lilydev/git/lily/Documentation --I=/home/lilydev/git/lilybuild/./out-www/xref-maps --init-file=/home/lilydev/git/lily/Documentation/web-texi2html.init --output=out-www/general/ out-www/general.texi Reading map file: /home/lilydev/git/lilybuild/./out-www/xref-maps/general.xref-map no such file: search-box.html: No such file or directory at /home/lilydev/git/lily/Documentation/web-texi2html.init line 763. make[2]: *** [out-www/general/index.html] Error 2 """ > There's probably half a dozen such little problems. > If nobody wants to do it, I'll continue working on it in 23 hours. ... in the meantime, I'm going to bed now. Good luck, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Beaming direction shorthand for manual beams
On 9/21/09 4:32 PM, "Neil Puttock" wrote: > Hi, > > Here's a little patch which allows the use of direction tokens with > manual beaming: > > http://codereview.appspot.com/120060/show LGTM. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
