Re: Adjusting "Piano centered dynamics" template and "Les Néréides"
On Tue, Aug 04, 2009 at 03:22:10PM +1000, Joe Neeman wrote: > On Mon, 2009-08-03 at 12:24 +0200, John Mandereau wrote: > > There's no protocol for snippets in input/or input/mutopia/*: just edit > > the snippet, then commit and push when the result looks good to you. > > This is a snippet in Documentation/snippets and it has a few lines at > the top warning me not to edit it directly... The general steps are: 1) copy snippet from Documentation/snippets/ to new/ 2) remove any non-english texidoc?? items from the \header 3) edit file at will 4) run makelsr.py without arguments I'm not certain if these steps work at the moment, though. I think this would be slightly clearer if we didn't store a ton of files in Documentation/snippets/ but instead put the in a separate subdirectory (nobody's going to look through 299 items to notice the new/ -- OTOH, as long as the CG is clear on this point, there shouldn't be any problems) 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 Mon, 2009-08-03 at 12:24 +0200, John Mandereau wrote: > Le dimanche 02 août 2009 à 00:38 -0700, Joe Neeman a écrit : > > I've added some more stretchable space and a little padding to Dynamics, > > so the pedals look better. If you think pedals and dynamics should be > > treated differently, feel free to add a new context. I haven't actually > > updated the snippet because I don't know the protocol for updating > > snippets. > > There's no protocol for snippets in input/or input/mutopia/*: just edit > the snippet, then commit and push when the result looks good to you. This is a snippet in Documentation/snippets and it has a few lines at the top warning me not to edit it directly... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Mon, 2009-08-03 at 12:22 -0600, Andrew Hawryluk wrote: > On Thu, Jul 30, 2009 at 7:18 PM, Joe Neeman wrote: > > After fixing the latest round of bugs (pointed out by Neil Puttock and > > Michael Käppler), I've pushed the changes to git's master branch. That > > is, you should test master instead of dev/jneeman and bugs now belong on > > the bug list instead of in this thread. > > Just tried the latest version, and it looks awesome! > A pleasant, but unexpected side-effect of the new logic is that it > accepts more compact systems: the first piece I tried it on went from > 11 pages to 8, and only the first system looked too squished. > (Attached.) I tried > \override StaffGrouper #'between-staff-spacing #'padding = #1 > with no effect. Should this pad the skylines or just the staff itself? The interaction between the different xxx-spacing variables is a little complex and I need to document it properly. In this case, the problem is that Lyrics are unaffected by between-staff-spacing (because they are non-spaceable) and so your override only forces there to be one staff unit of padding between adjacent _staves_, which is satisfied by your example. Unfortunately, there is not yet any way to control the spacing between Lyrics and the staff below it, which is where you really want the extra padding AFAICT. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "anchors" in the music stream?
On Mon, Aug 3, 2009 at 2:58 PM, Mats Bengtsson wrote: > Reminds me of the GOTO command in BASIC! ;-) > > Seriously, I seem to recall that I proposed this feature some 11-12 years > ago and at that Han-Wen at that time answered with a "No!!!" (I don't > remember any details and this was long before we started using mailing list > archives). 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. :) -- 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: "anchors" in the music stream?
Hi Mats,
Reminds me of the GOTO command in BASIC! ;-)
An *extremely* underrated and powerful command. ;-p
One alternative way to achieve the same thing is to simply do a
global =
{
\time 4/4 s4*4*10
\time 3/4 s4*3*5
\time 7/4 s4*7
<<{ \time 4/4
\bar "|." }
\anchoredStuff >>
}
Nope: that is *not* an alternative way to achieve the same thing...
that's a way of doing something that *appears* to be the same thing. =)
Cheers,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
On Mon, Aug 03, 2009 at 06:18:20PM -0700, Mark Polesky wrote: > > Graham Percival wrote: > > > If you do restart, try the > > git clone --depth 1 git://URL > > method. (the CG will probably be updated to use this method in a > > week or so) > > it seems that this method is not suitable for developers with > push access. You can't push from it -- see below. I've done it. > --depth > Create a shallow clone with a history truncated to the specified > number of revisions. A shallow repository has a number of > limitations (you cannot clone or fetch from it, nor push from nor > into it), but is adequate if you are only interested in the recent > history of a large project with a long history, and would want to > send in fixes as patches. I read that before, but I tried it anyway. git push was just fine. I was using git 1.5.6.5. I'll double-check in a few days, before changing the CG. In short: buggered if I can figure out how to use git. :/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Graham Percival wrote: > If you do restart, try the > git clone --depth 1 git://URL > method. (the CG will probably be updated to use this method in a > week or so) Graham, it seems that this method is not suitable for developers with push access. You can't push from it -- see below. - Mark --depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Mark Polesky wrote Monday, August 03, 2009 11:38 PM Trevor Daniels wrote: These commands will fail. The correct command is $ git reset --hard origin/master It gets up to 50%, then crashes: Checking out files: 50% (963/1926) (here the Windows error box pops up) Once I close the pop-up, the line changes to: fatal: Could not reset index file to revision 'origin/master'. When I try resetting master to an *earlier* commit in my own repo, it again crashes with the (git) error: child process exited abmormally I think deleting your repository and rebuilding it from Savannah is the next thing to try. It only takes 20 mins or so, and I don't know what else you can do. I don't see the connection of a faulty repo with some of your errors, but this problem with reset and your earlier one with validate seem to suggest a screwed repo. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Trevor Daniels wrote: > These commands will fail. The correct command is > > $ git reset --hard origin/master It gets up to 50%, then crashes: Checking out files: 50% (963/1926) (here the Windows error box pops up) Once I close the pop-up, the line changes to: fatal: Could not reset index file to revision 'origin/master'. When I try resetting master to an *earlier* commit in my own repo, it again crashes with the (git) error: child process exited abmormally ? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Mark Polesky wrote Monday, August 03, 2009 4:25 PM Graham Percival wrote: What does: git reset --hard origin or git reset --hard origin master do? I'd expect one of those to set you to a working state. (NB: by "I'd expect", I mean "as a user, I think the program should do this". Unfortunately, as somebody who's been fighting with git for years, I have no confidence that git /will/ behave in that manner) $ git reset --hard origin fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. Use '--' to separate paths from revisions $ git reset --hard origin master fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. Use '--' to separate paths from revisions These commands will fail. The correct command is $ git reset --hard origin/master Let me know if that works. Trevor ps I'm still unable to discern the cause of your problems; maybe the reset hard will help, although a few rogue commits are not likely to cause some of your other problems. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New German PO file for 'lilypond' (version 2.13.3)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/lilypond/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Forward of moderated message
--- Begin Message --- Hello. I do not have a bug to report but I was looking for the English translation of giro armonico (Italian) or tour harmonique (French). I've had a guess at it of "chord sequence" but I really don't know what the translation should be, so it might be a useful one to include in your glossary. Regards and thanks, Helene Bell _ Windows Live Messenger: Thanks for 10 great years—enjoy free winks and emoticons. http://clk.atdmt.com/UKM/go/157562755/direct/01/--- End Message --- ___ 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 : > 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, but they will be difficult to avoid to obtain in the result. This makes me remember we should add links to PDFs. > 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. > - 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. > - 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? We could also put output-distance in service for the examples. > If this wasn't our "pride and joy showcase for non-users", I'd be > perfectly content letting the images be built however they are. I > mean, I don't care (much) if a headword ends up looking silly. > But on the website, I *really* want to be certain that nothing > changes unless we explicitly want it to change. Agreed. This doesn't mean that they shouldn't be generated. > It's true that we *could* remove the Download pages. But again: > they don't really cause any problems. The install instructions > are in there, so theoretically somebody might get lilypond and the > docs on a CD, but might not figure out how to double-click on the > lilypond.exe file. You're right, I forgot this point. > Hey, there must be *some* reason why the windows users wanted an > enumerated list of 6 items! On a more serious note, the info in > Unix or MacOS X could well be useful. Sure :-P > I just meant that in general, it should be easy to change from > stable/2.x to stable/2.y (or even stable/3.x). i.e. please add a > IMPORT_FROM=stable/2.14 > to the top of the makefile (or python script). Sure. > 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. > Why should the 3 logos -- one of which is depecated, and one of > which I've never seen before in my life -- have their own dir? > I'm not totally against this, but I can't see a good reason for > it. 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: cd Documentation git mv pictures logos cd .. find -name '*.make' -or -name 'GNUmakefile*' |xargs grep pictures then replace occurences of pictures by logos (you could even replace grep by "sed -i -e s!pictures!logos!g" then check the result with git diff). > Fine with me. In the comment for the import, please write > something like > > Web: import files from web-gop branch. > > 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. > 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. There will likely be rough edges in the output, e.g. if I haven't managed to quickly convert Jan's patch to a usable init file chunk. > > 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? Th
Re: RFC: new vertical layout engine
On Thu, Jul 30, 2009 at 7:18 PM, Joe Neeman wrote: > After fixing the latest round of bugs (pointed out by Neil Puttock and > Michael Käppler), I've pushed the changes to git's master branch. That > is, you should test master instead of dev/jneeman and bugs now belong on > the bug list instead of in this thread. Just tried the latest version, and it looks awesome! A pleasant, but unexpected side-effect of the new logic is that it accepts more compact systems: the first piece I tried it on went from 11 pages to 8, and only the first system looked too squished. (Attached.) I tried \override StaffGrouper #'between-staff-spacing #'padding = #1 with no effect. Should this pad the skylines or just the staff itself? Andrew <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
Le lundi 03 août 2009 à 09:01 -0600, Andrew Hawryluk a écrit : > I may use said script to quickly check for dumb errors, but it didn't > seem to import the images, and if I run 'make doc' twice the second > run only takes 33 seconds, so I'll still build the full set regularly. We all rely on this as much as possible. Unclean builds don't behave very well, that will sorted out in a few weeks. > On that note, the LM version of the essay includes three images that > are stored in Documentation/, but the next version will probably have > several others. Is there a way to move any included images to > Documentation/essay/ so I'm not cluttering things up? 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. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: progress indicator?
>> Any chance to add a progress indicator, for example, giving the >> ratio between the total number of grobs and the grobs already >> processed? > > What could be done is having a progress indicator showing the number > grob/property combinations that were computed. OK. Even a rotating dash would be a better than nothing... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: progress indicator?
On Mon, Aug 3, 2009 at 6:22 AM, Werner LEMBERG wrote: > > For longer pieces, lilypond takes ages for the `preprocessing > graphical elements' stage. For the novice, it might appear that > lilypond hangs. Any chance to add a progress indicator, for example, > giving the ratio between the total number of grobs and the grobs > already processed? That's less trivial than it sounds. Because all computation is done lazily, we don't know how many grobs there are to be processed. What could be done is having a progress indicator showing the number grob/property combinations that were computed. -- 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: git hang-ups
Graham Percival wrote: > What does: > git reset --hard origin > or > git reset --hard origin master > do? I'd expect one of those to set you to a working state. (NB: > by "I'd expect", I mean "as a user, I think the program should do > this". Unfortunately, as somebody who's been fighting with git > for years, I have no confidence that git /will/ behave in that > manner) $ git reset --hard origin fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. Use '--' to separate paths from revisions $ git reset --hard origin master fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. Use '--' to separate paths from revisions It's comforting to know that I'm not the only one fighting git! - Mark ___ 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 3, 2009 at 6:05 AM, Graham Percival wrote: > On Sun, Aug 02, 2009 at 07:55:14PM +0200, John Mandereau wrote: >> Le samedi 01 août 2009 à 20:22 -0700, Graham Percival a écrit : >> > You're on osx, right? Or linux? I've attached a shell script >> > that just builds the essay. >> >> Please don't write, use and spread such scripts, or make sure I won't >> notice them nor their consequences: they will likely break next time >> makefiles are changed, and there are already so many issues and >> questions with the official build system that we don't want to be >> bothered by halping contributors that use such alternative building >> methods. > > Oops, I meant to warn Andrew that it was fragile. Andrew: if it > stops working at some point, let me know and I'll whip up another > script. Consider me warned! I may use said script to quickly check for dumb errors, but it didn't seem to import the images, and if I run 'make doc' twice the second run only takes 33 seconds, so I'll still build the full set regularly. On that note, the LM version of the essay includes three images that are stored in Documentation/, but the next version will probably have several others. Is there a way to move any included images to Documentation/essay/ so I'm not cluttering things up? Andrew ___ 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:
Would it be technically feasible/possible to establish a system of
"anchors" instead?
This would be indeed a great feature!
Reminds me of the GOTO command in BASIC! ;-)
Seriously, I seem to recall that I proposed this feature some 11-12
years ago and at that Han-Wen at that time answered with a "No!!!" (I
don't remember any details and this was long before we started using
mailing list archives).
One alternative way to achieve the same thing is to simply do a
global =
{
\time 4/4 s4*4*10
\time 3/4 s4*3*5
\time 7/4 s4*7
<<{ \time 4/4
\bar "|." }
\anchoredStuff >>
}
/Mats
___
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 Sun, Aug 02, 2009 at 07:51:46PM +0200, John Mandereau wrote: > Le lundi 27 juillet 2009 à 17:26 -0700, Graham Percival a écrit : > > There are *plenty* of lilypond sources available. I really think > > that adding complexity to the Introduction pages would not be > > warranted. > > Just like free software source code should be reachable from a place > where you get binaries, I think we should provide sources for examples. In a "free software" sense, they can get the sources from the source. > I'm not against hiding source links as much as possible in the > Introduction pages, though. *sigh* 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. ... you know, I *really* think that the examples should be left alone. We don't want newbies looking at the source, because it'll only confuse and scare them. They complicate the build process even more. Everything about this is screaming "not worth the effort" to me. > > All the files in input/ and input/mutopia/ (which isn't AFAIK > > available anyway!) > > Huh, many of them are available through examples page! 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! > > are getting deleted. Introduction->Examples > > is their replacement. > > > > Yes, there are no complete pieces there, but we already have > > *tons* of lilypond input examples available. > > Where else can you find these particular ones for current Lily versions? Good point. I'll think about this. 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 02:12:54PM +0200, John Mandereau wrote:
> Le lundi 03 août 2009 à 04:19 -0700, Graham Percival a écrit :
> > "generated manually" meaning "run make generate-examlpes once a
> > year or so".
>
> OTOH we could be a bit prouder and say on the examples pages something
> like "These examples are generated with latest stable version without
> any further tweak to the source files, which are available through a
> link at the side of each image" just like the old examples.
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'd also rather keep the safety of *not* generating them for every
stable release.
> > - under the "website from stable" proposal, updating the examples
> > will require me to rsync them. (they can't depend on the latest
> > stable release, since we might want to update the examples on
> > a different schedule)
> > This isn't necessarily a problem, since I'll be around a lot for
> > the next few years... but it's worth considering.
>
> This is the only significant disavantage of what I propose: every
> contributor that has permission to push can update a branch from
> another, but only Han-Wen, Jan and you can upload compiled docs. I
> think it's not a big deal as long as there are at least two of you
> available to react within a day or two if necessary.
Ok. I'm willing to try it. I mean, in the worst case, we could
just switch lilypond.org to automatically download images from
http://lilynet.net/example_upload/
and give write permission for that dir to whoever you want.
> > - actually, let's *not* automatically take the examples from the
> > latest stable. We need a distinct way of updating them anyway,
> > so all this would do would be to add another layer of
> > "paperwork" for making a release.
>
> I don't see the issue here: stable branch should only carry
> documentation improvements and bug fixes that introduce no regression.
> I can't remember any adventurous changes to Lily binary or lilypond-book
> have been committed that would break generated music examples (some
> early 2.10 releases had broken docs, but because of the build system).
- for X months, where X is as large as possible, the "stable"
branch *is* the "main" branch, so there's more changes.
- 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.
If this wasn't our "pride and joy showcase for non-users", I'd be
perfectly content letting the images be built however they are. I
mean, I don't care (much) if a headword ends up looking silly.
But on the website, I *really* want to be certain that nothing
changes unless we explicitly want it to change.
> > - I can't see any parts of the website that particularly don't
> > belong as distributed docs. Sure, we could probably identify a
> > few sections here and there that don't *need* to be in a doc
> > tarball, but I don't think it's worth it to identify those
> > sections and creating build scripts to omit them.
>
> On the contrary, before you explain a precise plan I understood that web
> repo would contain the two only things that surely don't make sense in
> the "distributed web site" (i.e. general information): the news entries
> and the download pages, which would be generated only in HTML in Web
> repo. Those two pages would still be generated automatically from a cron
> job, so that e.g. uploading a release will trigger a build of download
> pages.
I don't see any harm in distributing the news. Granted, most of
it is really boring ("released 2.7.4. Fixed some beam issues"),
but it only adds a few pages to the pdf. For the HTML, users can
simply avoid following the link to "Old news".
It's true that we *could* remove the Download pages. But again:
they don't really cause any problems. The install instructions
are in there, so theoretically somebody might get lilypond and the
docs on a CD, but might not figure out how to double-click on the
lilypond.exe file.
Hey, there must be *some* reason why the windows users wanted an
enumerated list of 6 items! On a more serious note, the info in
Unix or MacOS X could well be useful.
> > - the scripts on lilypond.org will need to easily be changeable
> > from stable/2.12 to stable/2.14.
>
> It will be much easier to release 2.14 and the new web site at the same
> time; if we don't, somebody (me?) will have to move docs in stable/2.12
> (OK, the makefiles would mostly need to be copied without further
> hacking, but even with this this would be much of a pain too). You have
> the final say on this, but now you know that it costs to release the
> website before 2.14 (rel
documentation of `after-title-spacing' is missing
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. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
progress indicator?
For longer pieces, lilypond takes ages for the `preprocessing graphical elements' stage. For the novice, it might appear that lilypond hangs. Any chance to add a progress indicator, for example, giving the ratio between the total number of grobs and the grobs already processed? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
improving layout of ly-grammar.txt
Carl, can you modify yyout2grammar.py to avoid overlong lines? For example, it currently generates 206 music_function_chord_body: music_function_identifier_musicless_prefix EXPECT_MUSIC function_arglist_nonmusic chord_body_element 207 | music_function_identifier_musicless_prefix function_arglist_nonmusi which is ugly both in HTML and PDF output. My suggestion is to align it as follows: 206 music_function_chord_body: music_function_identifier_musicless_prefix EXPECT_MUSIC function_arglist_nonmusic chord_body_element 207 | music_function_identifier_musicless_prefix function_arglist_nonmusic In other words, if a token (starting with the second one after the colon or vertical bar) causes the line length to exceed, put it into the next line, with a slight indentation relative to the first token after the colon or vertical bar. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On Sun, Aug 02, 2009 at 08:48:01PM +0200, John Mandereau wrote: > Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit : > > One of the biggest complaints people have with lilypond -- other > > than that silly "there's no gui" -- is the changing syntax. Now, > > IMHO this project should be an opportunity to promote Erik Sandberg's > music streams as a more stable music data representation before making > syntax changes that can't be handled by regular expressions and that > break a lot of source files. I think that's beyond us. Unless Erik or Han-Wen decide to implement it, I'm almost certain that this work will go nowhere. And since it's been 3 years since the thesis was finished, I think that if they wanted to do it, they'd have finished it. Understanding somebody else's half-finished work can be harder than doing it from scratch, after all! Basically, I don't see an overabundance of programmers with deep knowledge of lilypond internals (which is what the music streams would require). I *do* see an overabundance of intelligent people who see the value of creating general principals and rules. I'm certain that we can simplify+standarize the lilypond input notation, and I'm certain that I can organize such an effort. I'm not *at all* certain[1] that I could organize an attempt to implement the music streams. Umm, I don't mean "overabundance" as in "there's too any of them". I'm using some other meaning of "overabundance" here. :) [1] or rather: I'm certain that if I cared deeply about this, I could do it. I simply don't care deeply about it -- I mean, I wouldn't sacrifice any academic matters in favor of working on music streams, whereas I _would_ sacrifice some academic matters in favor of GLISS or the normal lilypond maintenance. I n any case, I don't anticipate that GLISS would create many non-convert-ly changes. The main manual change would be the prefix -> postfix change (\cr, \[, maybe one or two others). In theory, those could be automated, but since we probably won't have anybody who feels like writing python rules for that, we could just change \cr to \PREcr. That would identify the places were \PREcr needs to be moved and changed to \cr. 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
Le lundi 03 août 2009 à 04:19 -0700, Graham Percival a écrit : > On Sun, Aug 02, 2009 at 09:16:15PM +0200, John Mandereau wrote: > > Le lundi 27 juillet 2009 à 18:13 -0700, Graham Percival a écrit : > > > - nobody edits texinfo files in this repo. They are imported > > > via scripts/update-imported.sh from the > > > > I have one first concern with update-imported.sh: downloading latest > > changes from master branch by requesting a tarball from Git web > > interface is wasting bandwidth and Savannah servers ressources, it's > > I think that's a minor issue at this stage, but if we went with > this idea (which we don't appear to be doing), I'd certainly > implement your solution to this problem. > > > > - the website can be built without lilypond, or even texinfo > > > installed. All it needs it texi2html (perl). > > > > You hide other requirements by making them generated manually -- music > > examples for instance -- > > "generated manually" meaning "run make generate-examlpes once a > year or so". OTOH we could be a bit prouder and say on the examples pages something like "These examples are generated with latest stable version without any further tweak to the source files, which are available through a link at the side of each image" just like the old examples. > Ultimately, this is your show. I'm not convinced that a separate > web repo with imported files isn't the best way, but since you're > doing this work and not me, it's up to you. As you proposed to move the main web site sources to the main source tree, I think we should take as many advantages as possible of the build system, including generating examples from ly source, sharing the translation infrastructure and the HTML postprocessing. > A few things to consider: > - under the "website from stable" proposal, updating the examples > will require me to rsync them. (they can't depend on the latest > stable release, since we might want to update the examples on > a different schedule) > This isn't necessarily a problem, since I'll be around a lot for > the next few years... but it's worth considering. This is the only significant disavantage of what I propose: every contributor that has permission to push can update a branch from another, but only Han-Wen, Jan and you can upload compiled docs. I think it's not a big deal as long as there are at least two of you available to react within a day or two if necessary. > - actually, let's *not* automatically take the examples from the > latest stable. We need a distinct way of updating them anyway, > so all this would do would be to add another layer of > "paperwork" for making a release. I don't see the issue here: stable branch should only carry documentation improvements and bug fixes that introduce no regression. I can't remember any adventurous changes to Lily binary or lilypond-book have been committed that would break generated music examples (some early 2.10 releases had broken docs, but because of the build system). > - I can't see any parts of the website that particularly don't > belong as distributed docs. Sure, we could probably identify a > few sections here and there that don't *need* to be in a doc > tarball, but I don't think it's worth it to identify those > sections and creating build scripts to omit them. On the contrary, before you explain a precise plan I understood that web repo would contain the two only things that surely don't make sense in the "distributed web site" (i.e. general information): the news entries and the download pages, which would be generated only in HTML in Web repo. Those two pages would still be generated automatically from a cron job, so that e.g. uploading a release will trigger a build of download pages. > - Ideally, we'd have a script that copies everything from > master/Documentation/web/* to stable/2.12/Documentation/web/. Sure, even if some manual adjustments may be sometimes necessary after having run the script. > - the scripts on lilypond.org will need to easily be changeable > from stable/2.12 to stable/2.14. It will be much easier to release 2.14 and the new web site at the same time; if we don't, somebody (me?) will have to move docs in stable/2.12 (OK, the makefiles would mostly need to be copied without further hacking, but even with this this would be much of a pain too). You have the final say on this, but now you know that it costs to release the website before 2.14 (releasing it after would be a lesser pain). > - we'll need to add a few extra files to master like > lilypond.org.htaccess and favicon, but this isn't a big deal. Can't they remain on web branch along with the news and download pages? > Well, a few days ago I asked about a Documentation/pictures. This directory already serves another purpose, list it and/or see ROADMAP. > I'm > not troubled about whether we call it pictures or graphics. I > still have a slight preference for moving images into their >
Re: working on the new website
On Mon, Aug 03, 2009 at 12:42:27PM +0200, John Mandereau wrote: > After having built Lily binary or set LILYPOND_EXTERNAL_BINARY, > > cd TOP-BUILD-DIR/Documentation/ > make local-doc > > should build English docs only. This is kind-of implied by "make help", > but I leave documenting this more explicitly up to you. Thanks, I'll do this later today or tomorrow. 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 Sun, Aug 02, 2009 at 07:55:14PM +0200, John Mandereau wrote: > Le samedi 01 août 2009 à 20:22 -0700, Graham Percival a écrit : > > On Sat, Aug 01, 2009 at 07:32:21PM -0600, Andrew Hawryluk wrote: > > > OK, sounds good. New questions then: > > > - do I need to run 'make doc' to build the essay in the new location? > > > > Mao, I forgot about that. That'd take ages. > > It depends much on your machine... it may take from 26 min to more than > 2 hours on a 1,4 GHz Celeron GNU/Linux box with 512 MB RAM. Lucky. :) gperc...@nagi:~/svn/lilypond$ make doc-clean &> /dev/null gperc...@nagi:~/svn/lilypond$ time make doc &> /dev/null real226m57.986s user193m0.560s sys 18m35.950s Granted, that builds all the input/ files as well, but I'm pretty certain that those take about 1 hour, leaving 3 hours for the actual docs. And no, I wasn't using my laptop at the time; I started the build just before I went out for the evening. > > You're on osx, right? Or linux? I've attached a shell script > > that just builds the essay. > > Please don't write, use and spread such scripts, or make sure I won't > notice them nor their consequences: they will likely break next time > makefiles are changed, and there are already so many issues and > questions with the official build system that we don't want to be > bothered by halping contributors that use such alternative building > methods. Oops, I meant to warn Andrew that it was fragile. Andrew: if it stops working at some point, let me know and I'll whip up another script. Other than that, I don't regret it in the least. It's my job to make sure that other people can do their jobs. That was the fastest+easiest way to let Andrew get started. In the long term, I'd definitely recommend that he use the normal build system, but since that's in flux right now, the custom shell script lets him concentrate on his job (the essay), without getting distracted by other issues. > > Eventually I hope to have individual > > targets in the makefile, but I couldn't get that to work. > > Cross-references maps from all other manuals may be necessary to build > one manual in HTML. It might be possible to detect dependencies far > enough to determine which other manuals one manual refers to, but > frankly there are much more essential goals to reach first. Well, the point of individual-manual building would be to test one specific manual. For those cases, we could just make the ref point to null or whatever. > > The doc > > build process is in the middle of a severe revamping, > > Docs makefiles dependencies are currently a mess, which I won't attempt > at polishing before many other things are sorted out: web site > integration, Texinfo parser, translation infrastructure... That makes sense. > > Rendered output (from the shell script) is in > > Documentation/out/essay.html > > Documentation/out-www/essay.html. The shell script dumps it in out/. I used an $OUTDIR, though, so if Andrew wanted, he could make it out-www/ or out-stupid-script/ or whatever. 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 Sun, Aug 02, 2009 at 09:16:15PM +0200, John Mandereau wrote: > Le lundi 27 juillet 2009 à 18:13 -0700, Graham Percival a écrit : > > - nobody edits texinfo files in this repo. They are imported > > via scripts/update-imported.sh from the > > I have one first concern with update-imported.sh: downloading latest > changes from master branch by requesting a tarball from Git web > interface is wasting bandwidth and Savannah servers ressources, it's I think that's a minor issue at this stage, but if we went with this idea (which we don't appear to be doing), I'd certainly implement your solution to this problem. > > - the website can be built without lilypond, or even texinfo > > installed. All it needs it texi2html (perl). > > You hide other requirements by making them generated manually -- music > examples for instance -- "generated manually" meaning "run make generate-examlpes once a year or so". > > - normal users cannot screw up the official, uploaded, web page. > > (a dedicated developer needs to import the latest changes from > > master and review them, before pushing them to the lilypond-web > > repo) > > Have you already found any developer to do this? Since it's roughly half the work of updating LSR, I don't think this would be a problem. I can handle this stuff, no problem. > And it would be bad to > distribute an outdated offline version of the web site in either master > or stable/*, so there should be a dedicated developer to cherry-pick > website changes from one branch into the other one. Mao, I hadn't thought of that. I mean, master/ would have the latest changes anyway (since any changes are made there), but we'd definitely want to backport those anyway. Not that this backporting would be a big job -- once you verified that the changes were good for the web.repo, you'd just run the "copy Documentation/web/* from master/ to stable/" script. > This and and the > requirement to regenerated examples by hand are too much overhead for > our development resources, I can't support this plan in its current > infrastructure shape. Again, the plan is that we *wouldn't* regenerate examples on a regular basis. And certainly not by hand! > My proposal to upload most of the web site from generated documentation > of stable branch solves this problem: regular contributors can edit the > web site on master, then the dedicated developer you mention cherry-pick > changes into stable branch. We'd have cron job on lilypond.org take a > almost built output tree of stable docs and only (re)build the web site > and a bit of stuff we don't want in distributed docs (e.g. home page > news). I won't precise it any further, but will start hacking instead > and propose patches. Ok. Ultimately, this is your show. I'm not convinced that a separate web repo with imported files isn't the best way, but since you're doing this work and not me, it's up to you. A few things to consider: - under the "website from stable" proposal, updating the examples will require me to rsync them. (they can't depend on the latest stable release, since we might want to update the examples on a different schedule) This isn't necessarily a problem, since I'll be around a lot for the next few years... but it's worth considering. - actually, let's *not* automatically take the examples from the latest stable. We need a distinct way of updating them anyway, so all this would do would be to add another layer of "paperwork" for making a release. - I can't see any parts of the website that particularly don't belong as distributed docs. Sure, we could probably identify a few sections here and there that don't *need* to be in a doc tarball, but I don't think it's worth it to identify those sections and creating build scripts to omit them. - Ideally, we'd have a script that copies everything from master/Documentation/web/* to stable/2.12/Documentation/web/. - the scripts on lilypond.org will need to easily be changeable from stable/2.12 to stable/2.14. - we'll need to add a few extra files to master like lilypond.org.htaccess and favicon, but this isn't a big deal. > > My only uncertainty with this proposal is that I'm not certain how > > this affects the cross-references. I'm hopeful that since the > > Err, cross-references to other manuals need more information (see > below). Unless you import all manuals into web repo and build from there > (which would make no sense), you need at least the xref-map files of > other manuals. That makes sense. If we were doing the separate repo thing, then we'd just import the xref-map as well. > BTW what about creating a directory Documentation/graphics, which would > host non-Lily-generated graphics for all manuals? Well, a few days ago I asked about a Documentation/pictures. I'm not troubled about whether we call it pictures or graphics. I still have a slight preference for moving images into their respective dirs (say, notation/images/, e
Re: working on the new website
Le dimanche 02 août 2009 à 19:55 +0200, John Mandereau a écrit : > Le samedi 01 août 2009 à 20:22 -0700, Graham Percival a écrit : > > so we can't > > build the English docs without building all the docs in other > > languages. > > I understand this one can be annoying, I'll look at it soon. After having built Lily binary or set LILYPOND_EXTERNAL_BINARY, cd TOP-BUILD-DIR/Documentation/ make local-doc should build English docs only. This is kind-of implied by "make help", but I leave documenting this more explicitly up to you. 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: LSR, updates and committishes
Le lundi 27 juillet 2009 à 17:12 +0200, John Mandereau a écrit : > Le dimanche 28 juin 2009 à 17:58 +0300, Till Paala a écrit : > > I called it without any argument and it updated some 4 > > snippets in input/lsr with convert-ly to a new lilypond-version -- but > > it didn't touch anything that was modified in input/texidoc. > > This is a bug, or a missing feature if you like. I just implemented and tested it. Please test next time you edit or translate a texidoc. 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: Adjusting "Piano centered dynamics" template and "Les Néréides"
Le dimanche 02 août 2009 à 00:38 -0700, Joe Neeman a écrit : > I've added some more stretchable space and a little padding to Dynamics, > so the pedals look better. If you think pedals and dynamics should be > treated differently, feel free to add a new context. I haven't actually > updated the snippet because I don't know the protocol for updating > snippets. There's no protocol for snippets in input/or input/mutopia/*: just edit the snippet, then commit and push when the result looks good to you. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: harmonicDots
Graham Percival wrote ages ago on Monday, October 06, 2008 8:00 PM On Mon, 6 Oct 2008 19:53:10 +0100 "Neil Puttock" wrote: 2008/10/6 Graham Percival : > Why isn't > \set HarmonicDots = ##t > set by default? IMO we should normally print the dot in > 2. by default -- if somebody wants to suppress > this, > let them use a =##f tweak. I agree, though \harmonic is really for use with artificial harmonics; your example should really use \override NoteHead #'style = #'harmonic (which would naturally show dots). We could have a predef for this usage, I suppose. Agreed. \harmonicHeadsOn and \harmonicHeadsOff ? I'm gradually clearing away some old TODOs. This was one of them. I've added the new predefs and changed the docs to suit. Having done that, I'm not sure that we still want to change the default value of harmonicDots. Is it the usual practice to show artificial harmonics with or without the dots? The dot is of course visible in the base note. And by using \harmonicsOn it is shown by default for natural harmonics. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature-request / doc-actualization (right-margin)
Le dimanche 02 août 2009 à 21:27 +0200, Michael Käppler a écrit : > What I wasn't unable to figure out is at which time line-width is > calculated if you don't set it explicitly. And, much more confusing, I > don't see any procedures in C++ that actually check the line-width. A > "grep -R line-width *" isn't very informative. > Any ideas? I'm quite ignorant in page settings in Lily code, but have you greped scm/*.scm? HTH, 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
On Mon, Aug 03, 2009 at 08:54:58AM +0100, Trevor Daniels wrote: > > Mark Polesky wrote Monday, August 03, 2009 2:30 AM >> > 3. >> git gui/Repository/Verify Database >> With that, I get: >> Error: Command Failed >> git-fsck-objects.exe has encountered a problem and needs to close. >> We are sorry for the inconvenience. > > So there is no problem starting git tasks, > but all fail during processing. Errors 2 > and 3 don't need ssh, so that isn't the > problem. Agreed. What does: git reset --hard origin or git reset --hard origin master do? I'd expect one of those to set you to a working state. (NB: by "I'd expect", I mean "as a user, I think the program should do this". Unfortunately, as somebody who's been fighting with git for years, I have no confidence that git /will/ behave in that manner) >> I'm thinking of removing my entire lilypond repo and starting >> over from the beginning. If that doesn't work, I'll uninstall/ >> reinstall git. > > Well, that would eliminate one possibility, > and it's easy to do, but I'm not convinced > you have a problem with the git code. If you do restart, try the git clone --depth 1 git://URL method. (the CG will probably be updated to use this method in a week or so) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Mark Polesky wrote Monday, August 03, 2009 2:30 AM Mark Polesky wrote: > 199.232.41.69 ssh-rsa B3NzaC1yc2E ... > > It's the public key of the Savannah server. In > case you've lost it, I've attached one. My copy of the public key looks fine. Any other ideas? Not shots in the dark. It's difficult helping from a distance as there's all sorts of trivial things which would give more clues but I don't know what exactly you've done to investigate this, or what precisely your operating regimen is. Let's summarise: 1. $ git pull ssh://sv/srv/git/lilypond.git master fatal: The remote end hung up unexpectedly 2. when I try "update" through the gitk screen, I get a rather disturbing message... Error reading commits: child killed: unknown signal 3. git gui/Repository/Verify Database With that, I get: Error: Command Failed git-fsck-objects.exe has encountered a problem and needs to close. We are sorry for the inconvenience. 4. $ git fetch The authenticity of 'git.sv.gnu.org (199.232.41.69)' can't be established. So there is no problem starting git tasks, but all fail during processing. Errors 2 and 3 don't need ssh, so that isn't the problem. The git repo is a common factor, but I don't see how a problem there could generate error 4. The common problem seems to be in locating files under your account, ~/, from tasks running under the bash shell. What does the env command return? Is HOME still set correctly (should point to your ~/)? Perhaps you could mail me the output from env. Enter env > env.txt to get it into a file. I'm thinking of removing my entire lilypond repo and starting over from the beginning. If that doesn't work, I'll uninstall/ reinstall git. Well, that would eliminate one possibility, and it's easy to do, but I'm not convinced you have a problem with the git code. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
