Re: CG addition about Git pulling
Graham Percival wrote:
> Could we get the new introduction chapter added? I've
> been wanting to add the info about lilypond mentors for a
> while, but I don't want to add a new chapter filled with
> stubs if you're going to add the same new chapter filled
> with real sections.
For the moment I'm just working on the Git stuff (as you
suggested). I don't imagine the mentor stuff will conflict
too much with my current work. If you think it might, you
can send me a patchlet with your ideas so I know what you're
envisioning.
> I think everybody liked the idea of the intro chapter,
> even if there's slight uncertainty over one section of it
> (i.e. lily-git). Let's get the part(s) that everybody
> agrees with done.
Okay, I've attached a patch that adds an intro. Still
unfinished but perhaps it's worth adding as it is. I've
also started a `Git commands for developers' node, though I
don't yet know where to put it. Would this be better to
post on Rietveld? It seemed small enough for the mailing
list. Let me know. Comments appreciated.
- Mark
From 290ed28568a3c09fd128ac758a0b36f7a0da745c Mon Sep 17 00:00:00 2001
From: Mark Polesky
Date: Mon, 4 Jan 2010 23:48:57 -0800
Subject: [PATCH] Doc: Add CG `Introduction to contributing'.
---
Documentation/contributor.texi |2 +
Documentation/contributor/git-for-developers.itexi | 46 +++
Documentation/contributor/introduction.itexi | 84
3 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/contributor/git-for-developers.itexi
create mode 100644 Documentation/contributor/introduction.itexi
diff --git a/Documentation/contributor.texi b/Documentation/contributor.texi
index 4af6e6f..e5077d3 100644
--- a/Documentation/contributor.texi
+++ b/Documentation/contributor.texi
@@ -48,6 +48,7 @@ Copyright @copyright{} 2007--2009 by the authors.
@ifnottex
@menu
+* Introduction to contributing::
* Starting with git::
* Compiling LilyPond::
* Documentation work::
@@ -69,6 +70,7 @@ Appendices
@contents
+...@include contributor/introduction.itexi
@include contributor/git-starting.itexi
@include contributor/compiling.itexi
@include contributor/doc-work.itexi
diff --git a/Documentation/contributor/git-for-developers.itexi b/Documentation/contributor/git-for-developers.itexi
new file mode 100644
index 000..3534c30
--- /dev/null
+++ b/Documentation/contributor/git-for-developers.itexi
@@ -0,0 +1,46 @@
+...@c -*- coding: us-ascii; mode: texinfo; -*-
+
+...@c not sure where this should go yet
+...@node Git commands for developers
+...@section Git commands for developers
+
+
+Initialize an empty Git repository:
+
+...@example
+$ mkdir ~/lilypond-git/; cd ~/lilypond-git/
+$ git init
+...@end example
+
+
+Configure Git:
+
+...@example
+$ git config --global user.name "@emph{John Doe}"
+$ git config --global user.email @emph{john@@example.com}
+$ git config --global core.editor @emph{my_editor}
+$ git config --global color.ui auto
+...@end example
+
+
+Download remote @q{master} branch to local repository:
+
+...@example
+$ git remote add -ft master -m master origin \
+ git://git.sv.gnu.org/lilypond.git/
+$ git checkout -b master origin/master
+...@end example
+
+
+Download remote @q{lilypond/translation} branch to local
+repository:
+
+...@example
+$ git remote add -ft lilypond/translation -m \
+ lilypond/translation origin git://git.sv.gnu.org/lilypond.git/
+$ git checkout -b lilypond/translation origin/lilypond/translation
+...@end example
+
+
+... more to follow ...
+
diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi
new file mode 100644
index 000..f151c83
--- /dev/null
+++ b/Documentation/contributor/introduction.itexi
@@ -0,0 +1,84 @@
+...@c -*- coding: us-ascii; mode: texinfo; -*-
+
+...@node Introduction to contributing
+...@chapter Introduction to contributing
+
+
+...@menu
+* Overview of tasks::
+* For unix developers::
+* For other contributors::
+...@end menu
+
+
+...@node Overview of tasks
+...@section Overview of tasks
+
+
+...@c Graham wrote:
+...@c The intro should contain the "help us" material from web/,
+...@c quite possibly as the very first thing. This requires
+...@c having a macro for it, which depends on issue 939. James
+...@c said that he might take a look at it, but it's a bit
+...@c complicated for a new contributor.
+
+
+...@node For unix developers
+...@section For unix developers
+
+
+...@c make a `Git for developers' appendix?
+
+
+...@node For other contributors
+...@section For other contributors
+
+
+The LilyPond source code is maintained as a Git repository, which
+contains:
+
+...@itemize
+...@item
+all of the source files needed to build LilyPond, and
+
+...@item
+a record of the entire history of every change made to every file
+since the program was born.
+...@end itemize
+
+The @q{official} LilyPond Git repository is hosted by the GNU
+Savannah software forge
openSUSE Lilypond now building documentation
Hi, maintainer of lilypond for openSUSE and I'm now building the documentation and have restored most of the original spec file. I would appreciate somebody knowledgeable looking over the spec file at :- http://pastebin.com/m3d9ed2aa I would especially like somebody to scan the files section to see if everything is where it should be, I inherited the package with a lot of spec file statements commented out. Anyone with an openSUSE build service account can see a better layout of the spec file at :- https://build.opensuse.org/package/view_file?file=lilypond.spec&package=lilypond&project=home%3Aplater%3Abranches%3AopenSUSE%3AFactory%3AContrib Thanks Dave P ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG addition about Git pulling
Mark Polesky wrote Tuesday, January 05, 2010 8:21 AM Graham Percival wrote: I think everybody liked the idea of the intro chapter, even if there's slight uncertainty over one section of it (i.e. lily-git). Let's get the part(s) that everybody agrees with done. Okay, I've attached a patch that adds an intro. Still unfinished but perhaps it's worth adding as it is. I've also started a `Git commands for developers' node, though I don't yet know where to put it. Would this be better to post on Rietveld? It seemed small enough for the mailing list. Let me know. Comments appreciated. I think Reitveld is better reserved for patches to code. Normally patches to docs don't need to go through a formal review, but if you just want comments before pushing a patch sending it by email is fine. The section headings need to make it clearer what audience is being addressed. Perhaps Summary for experienced Unix developers Full details for new contributors Then of course there is a lot more to add to provide "full details". But that can come later. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG addition about Git pulling
On Tue, Jan 05, 2010 at 12:21:06AM -0800, Mark Polesky wrote:
> Graham Percival wrote:
> > I think everybody liked the idea of the intro chapter,
> > even if there's slight uncertainty over one section of it
> > (i.e. lily-git). Let's get the part(s) that everybody
> > agrees with done.
>
> Okay, I've attached a patch that adds an intro. Still
> unfinished but perhaps it's worth adding as it is. I've
> also started a `Git commands for developers' node, though I
> don't yet know where to put it.
I don't know what you're trying to do with this "git commands for
developers". If anything, I'd say those commands are better for
non-developers.
In any case, that would go in the git chapter, so that's a
separate issue from this.
> Documentation/contributor.texi |2 +
> Documentation/contributor/introduction.itexi | 84
>
Please push those.
> +...@c Graham wrote:
> +...@c The intro should contain the "help us" material from web/,
> +...@c quite possibly as the very first thing. This requires
> +...@c having a macro for it, which depends on issue 939. James
> +...@c said that he might take a look at it, but it's a bit
> +...@c complicated for a new contributor.
... John's going to laugh about this, but oh well. Add a big
FIXME there, though, please, so that it'll definitely get fixed
before 2.14.
> +...@node For unix developers
> +...@section For unix developers
> +
> +
> +...@c make a `Git for developers' appendix?
No; just dump a two-paragraph introduction to lilypond. "We use
git. The docs are generated from texinfo. Send patches to
lilypond-devel. If you're planning a large patch, ask for some
guidance first in case you're going about it wrong."
... ok, that was 4 sentences, not two paragraphs. whatever. Just
get something in there; if we need to add more later, we can add
it.
Remember, the perfect is the enemy of the good. Just get
something in there.
> +...@c Is this helpful or just redundant? :
> +
> +...@c To put it simply, if you only want to use the program, you only
> +...@c need to install it. If you want to modify source files and
> +...@c create patches for development, then you need a Git repository
> +...@c (technically you don't even need an installed copy of the
> +...@c program, but it helps). But if you want modify source files
> +...@c and see how your changes affect the finished product, then
> +...@c you'll need a Git repository @emph{and} you'll need to compile
> +...@c the program on your own.
Sorry, I have a train to catch, so I'm not going to read/think
about it yet. Just push it, and we can look at it later.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Op dinsdag 05-01-2010 om 11:38 uur [tijdzone +0200], schreef Dave Plater: [keeping cc on list] > On 01/05/2010 11:12 AM, Jan Nieuwenhuizen wrote: > > Op dinsdag 05-01-2010 om 07:52 uur [tijdzone +0200], schreef Dave > > Plater: > > see the attached lily-65a7b1b1-1.eps; however it seems that currently > > ghostscript and ghostscript-debuginfo ar out of sync on factory; I > > cannot create a backtrace. > Interesting, I've just finished the final, not tested on build service, Yes, that's interesting. Does the gs command thas segfaults for me work for you? Are you running factory? I filed n#568280 > The i586 builds have just failed in build service, I have to do some > paying work now and haven't time to go through the build log but you can > find it at :- > https://build.opensuse.org/package/live_build_log?arch=i586&package=lilypond&project=home%3Aplater%3Abranches%3AopenSUSE%3AFactory%3AContrib&repository=openSUSE_11.2 > and then use the link at the bottom left "download raw logfile" to view > the whole log, including the versions of packages used for build. Weird. It may be because you do not use DESTDIR anymore in your spec but instead prepend buildroot to webdir? That's a scary thing to do imnsho :-) If the make install command uses/installs in any other directory too (infodir?) will touch the root file system instead of the package build root, right? Although I cannot imagine why this would have worked on x86_64, then. Greetings, Jan. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
On 01/05/2010 03:16 PM, Jan Nieuwenhuizen wrote: > Op dinsdag 05-01-2010 om 11:38 uur [tijdzone +0200], schreef Dave > Plater: > > [keeping cc on list] > > >> On 01/05/2010 11:12 AM, Jan Nieuwenhuizen wrote: >> >>> Op dinsdag 05-01-2010 om 07:52 uur [tijdzone +0200], schreef Dave >>> Plater: >>> > >>> see the attached lily-65a7b1b1-1.eps; however it seems that currently >>> ghostscript and ghostscript-debuginfo ar out of sync on factory; I >>> cannot create a backtrace. >>> > >> Interesting, I've just finished the final, not tested on build service, >> > Yes, that's interesting. Does the gs command thas segfaults for me > work for you? Are you running factory? I filed n#568280 > > >> The i586 builds have just failed in build service, I have to do some >> paying work now and haven't time to go through the build log but you can >> find it at :- >> https://build.opensuse.org/package/live_build_log?arch=i586&package=lilypond&project=home%3Aplater%3Abranches%3AopenSUSE%3AFactory%3AContrib&repository=openSUSE_11.2 >> and then use the link at the bottom left "download raw logfile" to view >> the whole log, including the versions of packages used for build. >> > Weird. It may be because you do not use DESTDIR anymore in your > spec but instead prepend buildroot to webdir? That's a scary > thing to do imnsho :-) > > If the make install command uses/installs in any other directory > too (infodir?) will touch the root file system instead of the package > build root, right? > > Although I cannot imagine why this would have worked on x86_64, then. > > Greetings, > Jan. > Just got back, at first I thought it was due to the use of parallel builds, build service defaults to 4 and disabled that but that has also failed during document build, not install on :- |command failed: /usr/src/packages/BUILD/lilypond-2.12.3/out/bin/lilypond -I ./ -I ./out-www -I ../../input -I ../../input/lsr/ -I ../../input/regression/ -I ../../input/manual/ -I ../../input/tutorial/ -I /usr/src/packages/BUILD/lilypond-2.12.3/mf/out/ -I /usr/src/packages/BUILD/lilypond-2.12.3/mf/out/ -I /usr/src/packages/BUILD/lilypond-2.12.3/input/manual -I /usr/src/packages/BUILD/lilypond-2.12.3/Documentation -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlefr --header=doctitlees --header=doctitlede --header=doctitleja --header=texidoc --header=texidocfr --header=texidoces --header=texidocde --header=texidocja -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I "/usr/src/packages/BUILD/lilypond-2.12.3/out/lybook-db" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/regression" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/regression" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/regression/out-www" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/lsr" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/regression" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/manual" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/tutorial" -I "/usr/src/packages/BUILD/lilypond-2.12.3/mf/out" -I "/usr/src/packages/BUILD/lilypond-2.12.3/mf/out" -I "/usr/src/packages/BUILD/lilypond-2.12.3/input/manual" -I "/usr/src/packages/BUILD/lilypond-2.12.3/Documentation" --formats=eps --verbose -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/usr/src/packages/BUILD/lilypond-2.12.3/out/lybook-db/snippet-names--7471402555679770406.ly" Can you make anything of this? I'm going to look for a newer ghostscript in build service and try building against that. At least it fails on x86_64 and i586 on 11.0 through to factory. I left an rpmbuild going when I left and it's succeeded again. Regards Dave P | ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Interrupted builds: gs should remove broken output? [Re: [opensuse-contrib] lilypond]
Op dinsdag 05-01-2010 om 16:00 uur [tijdzone +0200], schreef Dave Plater: > On 01/05/2010 03:16 PM, Jan Nieuwenhuizen wrote: > > Op dinsdag 05-01-2010 om 11:38 uur [tijdzone +0200], schreef Dave > > Plater: > "/usr/src/packages/BUILD/lilypond-2.12.3/out/lybook-db/snippet-names--7471402555679770406.ly" > > Can you make anything of this? Yes, look earlier in the log and you'll most probably see the gs segfault that I mailed and reported this morning. The trouble is that when gs fails it [may] still produce a .pdf which is not removed by gs or the current build system. Possibly our postscript->pdf or postscript->png functions should remove any leftovers of what they're building when they exit, although I think this is something that should be fixed in gs. Greetings, Jan. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] bends: pre-implementation issues
Patrick Horgan schrieb: Marc Hohl wrote: Hello all, I plan to work on the emplementation of bends for lilypond. Some preliminary tests with scheme were successful, so I want to go to the next stage soon and create some new engravers. But there are still some unsolved issues. But first, a brief explanation for all non-guitarists out there: a band is achieved by pressing down a string and moving it along the frets. The string gets bend, and the resulting tone gets higher. There are three variants: 1) the bend (or bend up): plucking the string, then doing the bend 2) release bend: plucking a already bent string. Sounds like a reverse bend. 3) pre bend: bend the unplucked string, pluck afterwards. Mostly (but not always) followed by a release bend. You leave out the common case of a release bend without a pluck, following a bend. It's common in blues for example, to pluck, bend up a whole step, then back down a half step without an intervening pluck, for example leaving the string bent (and then of course shaking it all around). How would you notate that? _/ \ ~ note the ascii art won't work so well if you have variable width chars;) __/ Patrick Thanks for your hint! I wasn't referring to all possibilities, but mainly the three fundamental parts which can be combined to more complex bend fingures. I would notate this as e \bend fis \release f (durations aside). Thanks, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bends: pre-implementation issues
Han-Wen Nienhuys schrieb: I am confused here. Are you trying to implement the symbols that are on the tab staff, or on the normal notation? Both. But first, I want to concentrate on the pointed slurs in the normal notation, make that the default for normal staves *and* tablature and then (as tablature will be changed to "numbers only" in ly/engraver-init.ly) overwrite the engraver to produce the arrows instead of the pointed slurs. Would it be a sensible option to create a new slur style and activate it by \override Slur #'style = #'pointed or something similar? Then most parts of the slur computation routines hadn't to be duplicated, just extended to draw pointed slurs. Marc On Mon, Jan 4, 2010 at 5:44 PM, Marc Hohl wrote: Oops, I just sent a mail with an attachment that seems to be too big for -devel, I don't know where the limits are for the tablature list. I'll upload it to my homepage: http://www.hohlart.de/marc/bendtest.pdf Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] Re: bends: pre-implementation issues
On 1/5/10 12:36 PM, "Marc Hohl" wrote: > Han-Wen Nienhuys schrieb: >> I am confused here. Are you trying to implement the symbols that are >> on the tab staff, or on the normal notation? >> > Both. But first, I want to concentrate on the pointed slurs in the > normal notation, > make that the default for normal staves *and* tablature and then (as > tablature will > be changed to "numbers only" in ly/engraver-init.ly) overwrite the > engraver to > produce the arrows instead of the pointed slurs. > > Would it be a sensible option to create a new slur style and activate it by > > \override Slur #'style = #'pointed > > or something similar? Then most parts of the slur computation > routines hadn't to be duplicated, just extended to draw pointed slurs. I wouldn't recommend doing that as a way to start, because bend indications always go between two sequential notes, and slurs can span as many notes as desired. For hacking on it, when you don't have a bend_engraver to create a different kind of spanner, I can see that torturing the slur_engraver can be helpful. But if you look at David's sheet, you'll see that sometimes bends are enclosed inside of slurs, so losing the slur to the bend is probably not a good approach. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bends: pre-implementation issues
On Tue, Jan 5, 2010 at 5:36 PM, Marc Hohl wrote: > Han-Wen Nienhuys schrieb: >> >> I am confused here. Are you trying to implement the symbols that are >> on the tab staff, or on the normal notation? >> > > Both. But first, I want to concentrate on the pointed slurs in the normal > notation, > make that the default for normal staves *and* tablature and then (as I wouldnt bother with the slurs at all, not in the last part because your bends will likely break if someone ever decides to refactor the slur code. Just write a simple grob that is composed of two line segments to make the pointed bend. Have you already thought of how the spanner should behave when it crosses a line break? Have a look at tuplet-spanner.cc for some inspiration (tuplet spanner is probably more complex than you need; you can just have a right and left span point). You'll probably need entirely different code for the tab version, including different grob code, and a different engraver. I recommend worrying about that once the pointed-brace version is completely working. -- 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: CG addition about Git pulling
Trevor Daniels wrote: > The section headings need to make it clearer what audience > is being addressed. Perhaps > > Summary for experienced Unix developers > Full details for new contributors > > Then of course there is a lot more to add to provide "full > details". But that can come later. Well, this is just the introduction. Full details will come in the chapter on Git. Graham Percival wrote: > I don't know what you're trying to do with this "git > commands for developers". If anything, I'd say those > commands are better for non-developers. I thought I'd list all the commands from the Git chapter but without any of the "fluff". >> Documentation/contributor.texi >> Documentation/contributor/introduction.itexi > > Please push those. Done. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
