Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/21 Graham Percival gra...@percival-music.ca: On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote: /home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly Does anyone have any idea what could be going on? What's in the above file? It'll probably contain 5-10 other filenames; one of those is the failing file. If you find the failing file, you can see the syntax that caused the error in lilypond, and then you can (relatively) easily investigate why that syntax causes a problem. Out of curiosity i searched for snippet-names-5304161007275961614.ly file in build/out/lybook-db/ and... it doesn't exist. In fact i couldn't find snippet-names-5304161007275961614.ly anywhere in lilypond-git. Another interesting thing is that make doc failed for me too, but with different error message: extract_texi_filenames.py: Processing out-www/learning.texi Warning: No such file: learning/working.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) Warning: No such file: learning/scheme-tutorial.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) writing: /home/janek/lilypond-git/build/./out-www/xref-maps/learning.de.xref-map /home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames -o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I /home/janek/lilypond-git/Documentation/de -I /home/janek/lilypond-git/Documentation/de/included -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/build/Documentation/./out-www --master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/notation.xref-map out-www/notation.texi extract_texi_filenames.py: Processing out-www/notation.texi Warning: No such file: notation/programming-interface.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) writing: /home/janek/lilypond-git/build/./out-www/xref-maps/notation.de.xref-map /home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames -o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I /home/janek/lilypond-git/Documentation/de -I /home/janek/lilypond-git/Documentation/de/included -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/build/Documentation/./out-www --master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/usage.xref-map out-www/usage.texi extract_texi_filenames.py: Processing out-www/usage.texi writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 make[3]: Leaving directory `/home/janek/lilypond-git/build/Documentation/de' make[2]: *** [WWW-1] Error 2 rm out-www/weblinks.itexi make[2]: Leaving directory `/home/janek/lilypond-git/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/janek/lilypond-git/build' make: *** [doc-stage-1] Error 2 It's the first time i tried compiling docs, so i may have screwed something. Here's what i did: rm -r build sh autogen.sh --noconfigure mkdir -p build/ cd build/ ../configure make make doc and this failed as above... This process can be automated relatively easily (relatively easily meaning 2-10 hours of python and build system work); that was the whole point of http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-9-_002d-behavior-of-make-doc What's the status of this? I don't see any protests to the probable decision but i also don't see any final decision... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote: 2011/9/21 Graham Percival gra...@percival-music.ca: On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote: /home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly Does anyone have any idea what could be going on? What's in the above file? It'll probably contain 5-10 other filenames; one of those is the failing file. If you find the failing file, you can see the syntax that caused the error in lilypond, and then you can (relatively) easily investigate why that syntax causes a problem. Out of curiosity i searched for snippet-names-5304161007275961614.ly file in build/out/lybook-db/ and... it doesn't exist. In fact i couldn't find snippet-names-5304161007275961614.ly anywhere in lilypond-git. Hey Janek, I believe that the names of snippets are randomly generated anew every time the relevant make command is called. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
David Kastrup writes: The main problem is that it is catastrophic with regard to rebasing, and still rather disruptive with regard to merging. +1 Personally, I'd prefer it if we focused on solving rather than creating real problems. +1 Also, I'm not going to start the C++ indentation discussion all over again. I did not read this proposal as I figured that it would do the only sensible thing: formalise the status quo while allowing people who are not using Emacs yet to indent their files the GNU way using a script. We're a GNU project, remember? Please find an indenter that does what Emacs does. Most every .scm is indented by Emacs now. And please, pretty please, give Emacs another try. Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Doc: NR Clarify finer point of repeat unfold
http://codereview.appspot.com/5075047/
This is for tracker issue 1801.
Explain as an example, that \repeat unfold 2 {music expression} is
not always the same as writing out the music expression twice - especially
in a \relative context
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
carl.d.soren...@gmail.com writes:
I'd be lying if I said I understood everything going on here, but I
think I get the gist.
Same here.
I like moving this way!
I like the approach of simplifying things.
I like having optional predicates, and optional predicates with
defaults.
I will trust you that it is O(n) and that all the shift-reduce conflicts
have been resolved.
No need to trust: I was talking about O(n) concerning the number of
rules. Since there are no longer rules with EXPECT_A EXPECT_B
_combinations_, adding new types will add a number of rules to the
grammar that is proportional to the number of new types.
The cost is that one needs to either
a) have a precedence rule for _every_ terminal symbol that may start a
function argument
b) be prepared to ignore a large number of shift/reduce conflicts.
There are also two restrictions that may be arbitrary:
a) if you leave out an optional argument, all immediately following
optional arguments are also skipped. The reason is that I don't want a
puzzle game for filling optional arguments into a list of argument types
A A B C A C . If you get arguments A C in the input, where will they
end up?
b) the last argument needs to be non-optional. Otherwise a call ending
with five optional arguments can look five syntactic arguments ahead in
the input before deciding it does not want any.
I don't actually think that the parser can deal with this kind of
lookahead, so this may cut down expectations to a more reasonable level.
As to performance: that is more or less O(n*l) where n is input size and
l is the average lookahead piling up. Lookahead is pretty much limited:
this mostly assigns arguments left to right, skipping optional argument
lists once the first input does not fit.
I wanted the code to be simpler but that is really hard. Anyway, here
is an application:
afterGrace =
#(define-music-function (parser location main dur grace)
(ly:music? (ly:duration?) ly:music?)
(_i Create @var{grace} note(s) after a @var{main} music expression.
An optional duration between the expressions gives the point of time where the
grace notes are placed.
)
(let ((main-length (ly:music-length main))
(fraction (ly:parser-lookup parser 'afterGraceFraction)))
(make-simultaneous-music
(list
main
(make-sequential-music
(list
(make-music 'SkipMusic
'duration (or dur
(ly:make-duration
0 0
(* (ly:moment-main-numerator main-length)
(car fraction))
(* (ly:moment-main-denominator main-length)
(cdr fraction)
(make-music 'GraceMusic
'element grace)))
\new Voice { \afterGrace { c'1 } { c'16 d' }
\afterGrace { c'1 } 1*7/8 { c'16 d' }
\afterGrace { c'1} 4 {c'16 d' }
\afterGrace c'2 {c'16 d'} d'2}
As you can see when comparing with the original in
ly/music-functions-init.ly, the source code is minimally more complex.
Since the default duration needs to be calculated at run time when left
unspecified, we let the optional argument default to #f (defaults are no
longer checked for the correct type, so this works) and splice in the
default calculation with (or dur ...).
I'm not a parser expert, so it doesn't mean much coming from me, but I
think this looks good.
Neither am I.
http://codereview.appspot.com/5023044/
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Hello,
2011/9/21 m...@apollinemike.com m...@apollinemike.com:
On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote:
2011/9/21 Graham Percival gra...@percival-music.ca:
On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote:
/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly
Does anyone have any idea what could be going on?
What's in the above file? It'll probably contain 5-10 other
filenames; one of those is the failing file. If you find the
failing file, you can see the syntax that caused the error in
lilypond, and then you can (relatively) easily investigate why
that syntax causes a problem.
Out of curiosity i searched for snippet-names-5304161007275961614.ly
file in build/out/lybook-db/ and... it doesn't exist. In fact i
couldn't find snippet-names-5304161007275961614.ly anywhere in
lilypond-git.
Hey Janek,
I believe that the names of snippets are randomly generated anew every time
the relevant make command is called.
Yes, they are.
--
--
James
� �{
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
Graham Percival gra...@percival-music.ca writes: On Mon, Sep 19, 2011 at 09:29:32PM -0600, Colin Campbell wrote: For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. Where is the point in changing patch status and telling nobody who did not look yet? Sorry, I think that is a bad idea. Patch-countdown is a final warning of the speak now or be forever silent kind. If you read the bug list, that is the kind of clutter you need to _deal_ with. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
2011/9/21 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: On Mon, Sep 19, 2011 at 09:29:32PM -0600, Colin Campbell wrote: For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. Where is the point in changing patch status and telling nobody who did not look yet? Sorry, I think that is a bad idea. Patch-countdown is a final warning of the speak now or be forever silent kind. If you read the bug list, that is the kind of clutter you need to _deal_ with. I think Graham did so because it was only an experiment. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/21 Peekay Ex pkx1...@gmail.com: Hello, 2011/9/21 m...@apollinemike.com m...@apollinemike.com: On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote: Out of curiosity i searched for snippet-names-5304161007275961614.ly file in build/out/lybook-db/ and... it doesn't exist. In fact i couldn't find snippet-names-5304161007275961614.ly anywhere in lilypond-git. I believe that the names of snippets are randomly generated anew every time the relevant make command is called. Yes, they are. Aha. Thanks for explanation. How can we find out what's the problem then? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: add a note about \relative f to notation (issue 1909) (issue 5096046)
Reviewers: ,
Message:
http://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00331.html
http://code.google.com/p/lilypond/issues/detail?id=1909
Description:
Doc: add a note about \relative f to notation
Please review this at http://codereview.appspot.com/5096046/
Affected files:
M Documentation/notation/pitches.itely
Index: Documentation/notation/pitches.itely
diff --git a/Documentation/notation/pitches.itely
b/Documentation/notation/pitches.itely
index
d9d2fb2faaca63f9e7e3d9dcce460c1c044945cd..6c4427d8c18e14e5ec32ae1e4735a1108cdebae2
100644
--- a/Documentation/notation/pitches.itely
+++ b/Documentation/notation/pitches.itely
@@ -255,6 +255,11 @@ that each interval contains.
}
@end lilypond
+If you carefully consider all the rules above and remember that the
+octave of absolute pitches is also specified disregarding any
+accidentals, one rather interesting consequence is that the first note
+inside @code{@w{\relative f}} music is interpreted just the same as
+if it was written in absolute pitch mode.
@seealso
Music Glossary:
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR Clarify finer point of repeat unfold (issue 5075047)
LGTM. From what i see, the surprise in this behaviour comes from two meanings of music expression - it can be understood as a piece of ly input or a piece of music. Shall we write a sentence about this difference? I.e. Using \repeat unfold is equal to writing out a fragment of music several times over, not a fragments of ly input? cheers, Janek http://codereview.appspot.com/5075047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: add a note about \relative f to notation (issue 1909) (issue 5096046)
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely#newcode258 Documentation/notation/pitches.itely:258: If you carefully consider all the rules above and remember that the Probably a bit too contorted in the beginning. Just One consequence of these rules is that would be quite more concise, decreasing the chances of the reader falling asleep before he gets to the conclusion. Graham's warning against complex language was quite valid; the monosyllabic version in the mail exchange a definite improvement. The levity of language makes it fit less well with a reference manual, though. Cutting down the starting sentence of the version quoted here seems still prudent. http://codereview.appspot.com/5096046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
Janek Warchoł janek.lilyp...@gmail.com writes: 2011/9/21 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: On Mon, Sep 19, 2011 at 09:29:32PM -0600, Colin Campbell wrote: For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. Where is the point in changing patch status and telling nobody who did not look yet? Sorry, I think that is a bad idea. Patch-countdown is a final warning of the speak now or be forever silent kind. If you read the bug list, that is the kind of clutter you need to _deal_ with. I think Graham did so because it was only an experiment. Ah, ok. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Clarify finer point of repeat unfold (issue 5075047)
janek.lilyp...@gmail.com writes:
LGTM.
From what i see, the surprise in this behaviour comes from two meanings
of music expression - it can be understood as a piece of ly input or
a piece of music. Shall we write a sentence about this difference?
I.e. Using \repeat unfold is equal to writing out a fragment of music
several times over, not a fragments of ly input?
If you write
blurb = { c e g a }
{ \blurb \relative c'' \blurb }
is \blurb a fragment of music, or a fragment of ly input? I am afraid
it is both: relativable music is a weird thing.
And
\relative c' { \blurb \blurb }
is different from
\relative c' \repeat unfold 2 \blurb
The reason that it is different is not that one is ly input and the
other is music, but that making \repeat unfold do something different
from \repeat volta would be a total nuisance, and so we _explicitly_
programmed this case to behave differently.
http://codereview.appspot.com/5075047/
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: do we want special versions of the accidentals for use with text?
For figured bass, the situation is different: Here we use LilyPond's digit font, which is completely under our control, and having accidentals fitting those digits better is a good thing. I will prepare shorter versions of accidentals. Thanks! Would you help me with writing code that employs them? I did a quick glance at the code (chord-name-engraver, figured-bass-engraver) but i don't know where to start. Me neither :( I would like to have 48h a day, then I could afford more time for LilyPond, learning to understand how engravers work behind the scenes. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: do we want special versions of the accidentals for use with text?
On Sep 21, 2011, at 10:05 AM, Werner LEMBERG wrote: For figured bass, the situation is different: Here we use LilyPond's digit font, which is completely under our control, and having accidentals fitting those digits better is a good thing. I will prepare shorter versions of accidentals. Thanks! Would you help me with writing code that employs them? I did a quick glance at the code (chord-name-engraver, figured-bass-engraver) but i don't know where to start. Me neither :( I would like to have 48h a day, then I could afford more time for LilyPond, learning to understand how engravers work behind the scenes. Hey Janek, You wouldn't need to touch the engravers. The changes would need to be made in standard-alteration-glyph-name-alist, which is found in output-lib.scm. Just sub in the glyphs you want to use. Note that this will have effects in other parts of the code (chord symbols, for example). To limit your changes to figured bass stuff, check out format-bass-figure in translation-functions.scm. The function alteration-text-accidental-markup is the one that ultimately leads to the accessing of standard-alteration-glyph-name-alist : you'd need to sub this function out with another one for the special figured bass figures. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Rietveld workflow problems
Just wanted to throw this observation out: the current work on optional arguments is one area where working with Rietveld is getting really strained. The reason is that Rietveld just supports discussing and improving a single patch/commit. The current patch series consists of one infrastructure patch (allowing pushing tokens with values) and the rest. But there are about five different other (co-developed) infrastructure patches that the whole depends on. Making those independent issues would mean that you could not apply the main Rietveld patch to origin/master and check it out. So my workflow when on a larger Rietveld-reviewed patch like this consists of silently pushing required infrastructure/cleanup patches without discussion or review in order to keep origin/master in a state where one can meaningfully discuss the large single patch on top without getting side-tracked in unrelated issues. That's not really pretty. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Clarify finer point of repeat unfold (issue 5075047)
2011/9/21 David Kastrup d...@gnu.org:
janek.lilyp...@gmail.com writes:
LGTM.
From what i see, the surprise in this behaviour comes from two meanings
of music expression - it can be understood as a piece of ly input or
a piece of music. Shall we write a sentence about this difference?
I.e. Using \repeat unfold is equal to writing out a fragment of music
several times over, not a fragments of ly input?
If you write
blurb = { c e g a }
{ \blurb \relative c'' \blurb }
is \blurb a fragment of music, or a fragment of ly input? I am afraid
it is both: relativable music is a weird thing.
And
\relative c' { \blurb \blurb }
is different from
\relative c' \repeat unfold 2 \blurb
The reason that it is different is not that one is ly input and the
other is music, but that making \repeat unfold do something different
from \repeat volta would be a total nuisance, and so we _explicitly_
programmed this case to behave differently.
Good point, you are right that it was nonsense.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On Sep 21, 2011, at 10:27 AM, David Kastrup wrote: Just wanted to throw this observation out: the current work on optional arguments is one area where working with Rietveld is getting really strained. The reason is that Rietveld just supports discussing and improving a single patch/commit. The current patch series consists of one infrastructure patch (allowing pushing tokens with values) and the rest. But there are about five different other (co-developed) infrastructure patches that the whole depends on. Making those independent issues would mean that you could not apply the main Rietveld patch to origin/master and check it out. So my workflow when on a larger Rietveld-reviewed patch like this consists of silently pushing required infrastructure/cleanup patches without discussion or review in order to keep origin/master in a state where one can meaningfully discuss the large single patch on top without getting side-tracked in unrelated issues. That's not really pretty. For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. Ditto for a variable-name changing patch. I think that if it is really infrastructure / clean-up / small, then if you send an e-mail to the list with a heads up and nobody complains within 12ish hours (and/or if you get a LGTM), then it is OK to push. The definition of infrastructure / clean-up / small is, of course, up for debate, but I think that people have a pretty good sense of what needs review and what doesn't. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Added note to CG about disable-optimizing (issue 5081048)
LGTM, with one comment
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi#newcode143
Documentation/contributor/regressions.itexi:143: be run with the
@code{--disable-optimising} option. Then you will need
I think I'd mention just running ./autogen, just in
case the reader is doing the build for the first time.
But if you leave the configure option in it should be
./configure.
http://codereview.appspot.com/5081048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: engraver question: how to define an array to store events?
Am 20.09.2011 08:59, schrieb Marc Hohl: Hello list, while trying to get more insight into the engraver stuff, I encountered a problem. I hope I can explain it: I need some kind of a array of vectors: Nevermind - smells like the wrong way to go ;-) I think I found a more generic solution. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
m...@apollinemike.com m...@apollinemike.com writes: On Sep 21, 2011, at 10:27 AM, David Kastrup wrote: Just wanted to throw this observation out: the current work on optional arguments is one area where working with Rietveld is getting really strained. The reason is that Rietveld just supports discussing and improving a single patch/commit. The current patch series consists of one infrastructure patch (allowing pushing tokens with values) and the rest. But there are about five different other (co-developed) infrastructure patches that the whole depends on. Making those independent issues would mean that you could not apply the main Rietveld patch to origin/master and check it out. So my workflow when on a larger Rietveld-reviewed patch like this consists of silently pushing required infrastructure/cleanup patches without discussion or review in order to keep origin/master in a state where one can meaningfully discuss the large single patch on top without getting side-tracked in unrelated issues. That's not really pretty. For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. Ditto for a variable-name changing patch. I think that if it is really infrastructure / clean-up / small, then if you send an e-mail to the list with a heads up and nobody complains within 12ish hours (and/or if you get a LGTM), then it is OK to push. The definition of infrastructure / clean-up / small is, of course, up for debate, but I think that people have a pretty good sense of what needs review and what doesn't. It decouples the large patch from master/discussion for 12ish hours. Per small change. That breaks the stride. Now the usual function of review is a byproduct: it should not brake the usually sole developer from continuing work on the functionality, but keep others informed and able to check out his work and contribute. Review procedures should never block development, it should aid it. The only blockage that is acceptable is the decision about when to merge the completed work into master. I can't do anything until is bad. This depends on x also is bad. What we want, I think, is being able to pull a branch, or at least apply a patch _series_ (in a manner where already applied patches in the right order will get skipped, like git am does IIRC). Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added note to CG about disable-optimizing (issue 5081048)
On 2011/09/21 08:43:09, Trevor Daniels wrote: But if you leave the configure option in it should be ./configure. Ah, that was a bit simplistic. In-tree and out-of-tree builds are different wrt configure, I think. http://codereview.appspot.com/5081048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
Neil Puttock n.putt...@gmail.com writes: On 20 September 2011 21:50, Benkő Pál benko@gmail.com wrote: I don't know what to do, could you help me? The attached patch works for me (haven't run make check on it though). I have taken the liberty of pushing it after looking it through (I don't quite like relying on the implicit $$ = $1 action, but then the whole other book_body and bookpart_body rules do exactly that, so there is little point in making the new rules different). It definitely is a better solution than reverting the patch exhibiting the problem. Which does not mean that there is a guarantee no other commands from my patch might lead to similar surprises. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added note to CG about disable-optimizing (issue 5081048)
On Wed, Sep 21, 2011 at 10:01 AM, tdanielsmu...@googlemail.com wrote: On 2011/09/21 08:43:09, Trevor Daniels wrote: But if you leave the configure option in it should be ./configure. Ah, that was a bit simplistic. In-tree and out-of-tree builds are different wrt configure, I think. http://codereview.appspot.com/5081048/ Well I wasn't sure even this was the right place to put this information, we could for instance put this in the section(s) 4.4.1 and 4.4.2 instead where we explicitly talk about ./autogen.sh or ../configure (which as far as I can tell is only referred to when we use out of tree builds - i.e. I don't see any ./configure, only ../configure. James -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Hello, On Wed, Sep 21, 2011 at 9:35 AM, m...@apollinemike.com m...@apollinemike.com wrote: For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. So, and this is a genuine question, why do you need to make a tiny patch so that a (next) larger patch works. Why not include the tiny patch in your larger patch (if that makes sense)? And without wishing to sound rude rude, are we just blaming the tool here for 'your preference' of work flow? regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: add a note about \relative f to notation (issue 1909) (issue 5096046)
Suggestion to text.
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely#newcode263
Documentation/notation/pitches.itely:263:
Janek, something 'like' this:
Absolute pitch disregards accidentals which means that the first note
inside @code{@w{\relative f}} is interpreted as if it was written in
absolute pitch mode.
http://codereview.appspot.com/5096046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: add a note about \relative f to notation (issue 1909) (issue 5096046)
pkx1...@gmail.com writes:
Suggestion to text.
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely#newcode263
Documentation/notation/pitches.itely:263:
Janek, something 'like' this:
Absolute pitch disregards accidentals
Uh what? I really think we are better off not trying to add an
explanation that will be harder to make sense from than the resulting
behavior.
which means that the first note inside @code{@w{\relative f}} is
interpreted as if it was written in absolute pitch mode.
http://codereview.appspot.com/5096046/
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Peekay Ex pkx1...@gmail.com writes: Hello, On Wed, Sep 21, 2011 at 9:35 AM, m...@apollinemike.com m...@apollinemike.com wrote: For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. So, and this is a genuine question, why do you need to make a tiny patch so that a (next) larger patch works. Why not include the tiny patch in your larger patch (if that makes sense)? Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. And without wishing to sound rude rude, are we just blaming the tool here for 'your preference' of work flow? I prefer not editing tarballs as a means of source control, so git comes in quite handy. Of _course_ it is the task of tools to support preferable work flows. Now generally preferable is more important than individually preferred, and the list is the place where one would argue the general merit of one's preferences. So rude or not, I don't see the point in chastising Mike for explaining his personal preferences and their reasons to the discussion. If there is any fault to be found, it would be mine for starting this thread. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Hello, On Wed, Sep 21, 2011 at 11:45 AM, David Kastrup d...@gnu.org wrote: Peekay Ex pkx1...@gmail.com writes: Hello, On Wed, Sep 21, 2011 at 9:35 AM, m...@apollinemike.com m...@apollinemike.com wrote: For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. So, and this is a genuine question, why do you need to make a tiny patch so that a (next) larger patch works. Why not include the tiny patch in your larger patch (if that makes sense)? Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. And without wishing to sound rude rude, are we just blaming the tool here for 'your preference' of work flow? I prefer not editing tarballs as a means of source control, so git comes in quite handy. Of _course_ it is the task of tools to support preferable work flows. Now generally preferable is more important than individually preferred, and the list is the place where one would argue the general merit of one's preferences. So rude or not, I don't see the point in chastising Mike for explaining his personal preferences and their reasons to the discussion. There was no chastisement, the point I was trying to make is it seemed to me that some of the devs were trying to shoehorn a workflow into a 'system' (that being how we track and review patches) that they are not designed for. As to it being an unrelated patch - how can it be unrelated if it is required in the first place for the 'next' patch to apply correctly? That sounds 'related' to me. Again perhaps I am being too simplistic but if I make change to file A for Patch A and then I make a new Patch B which also includes file A change (from a new base) but also add file B does it matter that I have two patches that have the same file A? Doesn't it just overwrite the file with the same information (i.e. no change). Then if I want also to make Patch C (for something different to Patch B) but it also requires file A then, again can I just not just make Patch C with File A and File C and I'm still ok? Anyway, I'll shush now. I wasn't trying to start an argument I was just trying to get a perspective. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Am Wednesday, 21. September 2011, 04:27:02 schrieb Aleksandr Andreev: Unfortunately, I cannot get my documentation to build. As was suggested earlier, I nuked my build folder and redid everything from the beginning (configure.sh, make all, touch, make doc). However, make doc errors out with the following message: Calculating line breaks... Segmentation fault command failed: /home/sasha/lilypond-git/build/out/bin/lilypond [...] What was the output before the Calculating line breaks... There should be some processed file name, which will help you track down the problem. 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On Sep 21, 2011, at 1:00 PM, Peekay Ex wrote: Hello, On Wed, Sep 21, 2011 at 11:45 AM, David Kastrup d...@gnu.org wrote: Peekay Ex pkx1...@gmail.com writes: Hello, On Wed, Sep 21, 2011 at 9:35 AM, m...@apollinemike.com m...@apollinemike.com wrote: For what it's worth, I run into the same problem from time to time - I recently sent an e-mail to the list about a 1-line patch to fix kneed beams that I needed to apply for other work. So, and this is a genuine question, why do you need to make a tiny patch so that a (next) larger patch works. Why not include the tiny patch in your larger patch (if that makes sense)? Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. And without wishing to sound rude rude, are we just blaming the tool here for 'your preference' of work flow? I prefer not editing tarballs as a means of source control, so git comes in quite handy. Of _course_ it is the task of tools to support preferable work flows. Now generally preferable is more important than individually preferred, and the list is the place where one would argue the general merit of one's preferences. So rude or not, I don't see the point in chastising Mike for explaining his personal preferences and their reasons to the discussion. There was no chastisement, the point I was trying to make is it seemed to me that some of the devs were trying to shoehorn a workflow into a 'system' (that being how we track and review patches) that they are not designed for. No worries! It is true that the preferences I'm talking about are personal - a lot of my patches are gimungous, and they often need several tweaks to the code base just so I can work on them. I don't mind using Reitveld, though - I've never ran into unsolvable problems because of it. As to it being an unrelated patch - how can it be unrelated if it is required in the first place for the 'next' patch to apply correctly? That sounds 'related' to me. Again perhaps I am being too simplistic but if I make change to file A for Patch A and then I make a new Patch B which also includes file A change (from a new base) but also add file B does it matter that I have two patches that have the same file A? Doesn't it just overwrite the file with the same information (i.e. no change). Then if I want also to make Patch C (for something different to Patch B) but it also requires file A then, again can I just not just make Patch C with File A and File C and I'm still ok? I think this sorta thing needs some git trickery that's way above my head. That said, the no change thing you're talking about is possible (I've applied patches to branches that have the changes in those patches already and git says Merge made by recursive), but this is only when the changes are line-for-line equivalent. If they contain additional work, the merge needs to be done manually. Long story short, I leave it to the wise discretion of Mr. Percival if we ever change hosting tools. For the moment, I'm happy as a clam using consistent sloped beams across line breaks and glissando stems to write crazy string music. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Am Wednesday, 21. September 2011, 12:45:17 schrieb David Kastrup: Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. To submit a review to rietveld, the changes do not necessarily have to be in one single patch. If you do git cl upload origin/master, all patches in your local branch will be submitted as one merged review. When pushing to git, you can still have multiple patches. 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 12:45:17 schrieb David Kastrup: Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. To submit a review to rietveld, the changes do not necessarily have to be in one single patch. If you do git cl upload origin/master, all patches in your local branch will be submitted as one merged review. Sure. But there is no point in letting people review unrelated work that has been merged into the total review. When pushing to git, you can still have multiple patches. Even in the case where the patches are related by more than dependency, it might make sense to be able to review several parts separately. Increases the amount of work one can keep track of before eyes start glazing over. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
What's in the above file? It'll probably contain 5-10 other filename Yes. All the different snippets seem to have something to do with percussion. Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
2011/9/21 David Kastrup d...@gnu.org: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 12:45:17 schrieb David Kastrup: Because it doesn't make sense to combine unrelated patches in that manner. You can't find them in the history then, and if the large patch gets applied or reverted, the independent small patch has to go along. To submit a review to rietveld, the changes do not necessarily have to be in one single patch. If you do git cl upload origin/master, all patches in your local branch will be submitted as one merged review. Sure. But there is no point in letting people review unrelated work that has been merged into the total review. From what i understand, this unrelated, but somehow related work consists of small patches about infrastructure. If they are small, i see no problem in including them in the main review. When pushing to git, you can still have multiple patches. Even in the case where the patches are related by more than dependency, it might make sense to be able to review several parts separately. Increases the amount of work one can keep track of before eyes start glazing over. My impression is that using separate branches for development, as suggested by Graham not long ago, would help solving the problems you encounter: all related (depending on themselves) commits would be on a dedicated branch, so you can tell people checkout this branch to see how it works, and still a review could be made without including some commits. Example: create new branch make some small fixes to infrastructure commit them, let's say the committish is aaabbbc(...) make the big change which depends on aaabbbc(...) commit it create a review of big change without those small fixes: 'git cl upload aaabbbc(...)'. in review's description, write pull from branch xyz to get this feature. Seems straightforward to me. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Here is a quick summary: -) Each review is basically one commit in a branch on the gerrit server. -) To submit a review, you have to use git and push to a particular ref on the server: git push gerrit HEAD:refs/for/master/ e.g. git push gerrit 1477-suppress-expected-warnings:refs/for/master So, everyone submitting a patch needs to know how to work with git and remote refs etc. -) To be able to handle updates to patches, it needs a dirty hack: Each commit needs to include a unique ID (the commit hash will change if you amend a patch or otherwise change it!). There are post-commit hooks for git to insert such unique IDs, but still it pollutes the commit message. See http://gerrit-documentation.googlecode.com/svn/Documentation/2.1.7/user- upload.html -) You can only review individual patches. It's not possible to merge multiple git commits into one code review. It is, however, possible to review multiple patches in one branch. Each patch will have its own review, but you can checkout the branch in one go, and the web UI will display the dependencies of the patches. For example, the three patches on http://server.kainhofer.com:8088/ are subsequent patches in one branch. See the individual patch's page for the dependencies. -) It's pretty simple to set up on the server. -) Each user MUST have an OpenID account somewhere to create the user, and to use git he needs to create and upload an SSH key. Login with user/pw like with git-cl is not possible. All pushing is ONLY done over ssh. -) The web frontend does NOT work in Konqueror!!! -) My impression is that gerrit is mainly intended to review patches that are completely finished and should be either applied without changes or completely discarded. Also, it seems to make life easier for people who are git masters, but make life much harder for people who don't know git that well. 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Hello, On Wed, Sep 21, 2011 at 1:09 PM, Aleksandr Andreev aleksandr.andr...@gmail.com wrote: What's in the above file? It'll probably contain 5-10 other filename Yes. All the different snippets seem to have something to do with percussion. Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel You did see that I was able to build the documentation this morning on your patch? I think the problem is possibly the state of your tree you are building from. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added note to CG about disable-optimizing (issue 5081048)
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi#newcode143
Documentation/contributor/regressions.itexi:143: be run with the
@code{--disable-optimising} option. Then you will need
On 2011/09/21 08:43:09, Trevor Daniels wrote:
I think I'd mention just running ./autogen, just in
case the reader is doing the build for the first time.
But if you leave the configure option in it should be
./configure.
I believe the ../configure is appropriate for an out of tree build: it
would be run from a /build directory, which we strongly recommend, no?
http://codereview.appspot.com/5081048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Here is a quick summary: -) Each review is basically one commit in a branch on the gerrit server. Well, that's pretty much what we already have. If one can't link related reviews in a manner that you can, say, _pull_ a reviewed patch (which should automagically fetch any dependencies), I am not all that clear of what it actually gives us in addition. The basic advantage that I see is a separately maintained repository for reviews, meaning that review material does not clutter up the main repository permanently (once a commit has entered a repository, it is close to impossible to remove all traces of it again). Hm. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Am Wednesday, 21. September 2011, 15:04:05 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Here is a quick summary: -) Each review is basically one commit in a branch on the gerrit server. Well, that's pretty much what we already have. No. In gerrit you really need to clean up your patches before you submit them for review. I typically have lots of small commits in a branch when I upload a patch to rietveld. git-cl will simply take the diff to origin/master (i.e. all patches in the branch combined into one large patch) and show the combined diff. gerrit, on the other hand, will show each small patch as one review. So, I would have to clean up my local branch before submitting for review (i.e. rebase -i and squash and reorder the patches). That's a very fundamental difference in the approach. Rietveld works on the diff level, gerrit on the git commit level. If one can't link related reviews in a manner that you can, say, _pull_ a reviewed patch (which should automagically fetch any dependencies), I am not all that clear of what it actually gives us in addition. You'll have to check that yourself. The gerrit review page for a patch gives the pull URL, and it lists the dependencies. I would expect that it correctly pulls also the dependencies. The basic advantage that I see is a separately maintained repository for reviews, meaning that review material does not clutter up the main repository permanently (once a commit has entered a repository, it is close to impossible to remove all traces of it again). If you use a developer branch and remove that branch, there are no direct references any more. IIUC, the next garbage collection run on the server will clean those stale commits Of course, if you merge your developer branch into master, then the commits are there in the history forever. 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
2011/9/21 Reinhold Kainhofer reinh...@kainhofer.com: Am Wednesday, 21. September 2011, 15:04:05 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Here is a quick summary: -) Each review is basically one commit in a branch on the gerrit server. Well, that's pretty much what we already have. No. In gerrit you really need to clean up your patches before you submit them for review. I typically have lots of small commits in a branch when I upload a patch to rietveld. git-cl will simply take the diff to origin/master (i.e. all patches in the branch combined into one large patch) and show the combined diff. gerrit, on the other hand, will show each small patch as one review. +1, that's what i was going to write. So, I would have to clean up my local branch before submitting for review (i.e. rebase -i and squash and reorder the patches). And do this each time when you're submitting a fix for that patch, did i get it right? I don't like this. If one can't link related reviews in a manner that you can, say, _pull_ a reviewed patch (which should automagically fetch any dependencies), I am not all that clear of what it actually gives us in addition. What do you think about the branching solution i described? Isn't it working just like this? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 15:04:05 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Here is a quick summary: -) Each review is basically one commit in a branch on the gerrit server. Well, that's pretty much what we already have. No. In gerrit you really need to clean up your patches before you submit them for review. I typically have lots of small commits in a branch when I upload a patch to rietveld. git-cl will simply take the diff to origin/master (i.e. all patches in the branch combined into one large patch) and show the combined diff. gerrit, on the other hand, will show each small patch as one review. So what? Assume you have committed everything on branch untidy. Then you do git rebase origin git checkout -b tidy origin git checkout -p untidy And voila, you have patched in the current state of the untidy HEAD into your brandnew tidy branch and may choose to commit it. So, I would have to clean up my local branch before submitting for review (i.e. rebase -i and squash and reorder the patches). That's a very fundamental difference in the approach. Rietveld works on the diff level, gerrit on the git commit level. It is not hard to munch everything into one commit. The complex thing is dealing sensibly with stuff that you do _not_ want to have munched into a single commit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we need organizers
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com I might be willing to do this (since there are no other volunteers). Can i see this web app? Private email sent. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com [snip] It's the first time i tried compiling docs, so i may have screwed something. Here's what i did: rm -r build sh autogen.sh --noconfigure mkdir -p build/ cd build/ ../configure make make doc That looks OK - although you don't need the autogen if you've done it before. A quick look at what you have above makes it seem like you have missing files. Is your git tree up to date and in good shape? If you can't get make doc to work with the commands above, I've resorted to nuking my git directory too... Before you do this, though, go through the steps above with a good git tree and instead of running make doc, run make -d doc somefile.txt. Then zip the output and send it my way some convenient way. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
2011/9/21 David Kastrup d...@gnu.org: Reinhold Kainhofer reinh...@kainhofer.com writes: In gerrit you really need to clean up your patches before you submit them for review. I typically have lots of small commits in a branch when I upload a patch to rietveld. git-cl will simply take the diff to origin/master (i.e. all patches in the branch combined into one large patch) and show the combined diff. gerrit, on the other hand, will show each small patch as one review. So what? Assume you have committed everything on branch untidy. Then you do git rebase origin git checkout -b tidy origin git checkout -p untidy And voila, you have patched in the current state of the untidy HEAD into your brandnew tidy branch and may choose to commit it. So, I would have to clean up my local branch before submitting for review (i.e. rebase -i and squash and reorder the patches). That's a very fundamental difference in the approach. Rietveld works on the diff level, gerrit on the git commit level. It is not hard to munch everything into one commit. The complex thing is dealing sensibly with stuff that you do _not_ want to have munched into a single commit. I don't say that it's hard, i say that's additional work. Currently i only have to do 'git cl upload origin/master' and that's all. Also, i think that it is a difference for our Frogs. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
CG updates
I've added a few updates to the CG concerning regression tests - it answers some FAQs that have come up about regtest comparison. I took the liberty of a direct push as 173c86fbf69abf076ec9c16147c1bf106c52b541 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On 9/21/11 6:48 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Google Code now supports git archives. Reviews in Google Code are done on branches, and each commit on the branch is visible and reviewable. I'm not sur if I like the way reviews are requested, but doing the review by branches seems to work out quite well. If you want to see how it works, I've got a sandbox for another project set up at http://code.google.com/p/plant-sim/source/list You can choose either of two branches in a selection list, and you can review any commit by clicking on the SHA-1 ID. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Wed, Sep 21, 2011 at 08:31:51AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. Where is the point in changing patch status and telling nobody who did not look yet? Sorry, I think that is a bad idea. Patch-countdown is a final warning of the speak now or be forever silent kind. You previously had one option to see the countdown: 1. read -devel, read all the responses to the initial countdown message, mentally subtract the 2 or 3 patches that were withdrawn by the authors because they didn't remove the patch-review label when they should have, then look at the remaining patches. With a countdown of 5 issues, that's ok-ish, but when we get up to 10 issues, that's more mental arithmetic than I want to do. I'm bad at arithmetic. There's now a second and third option: 2. read -devel, see there's a new countdown, skim the list, then lick on the helpful link http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown that gives you a complete up-to-date list of patches that are in danger of being pushed. 3. check that helpful link once a day. Or, after the automatic script is generating these, just check it on Monday, Wednesday, and Friday (GMT), or maybe tues/fri/sat depending on your time zome. And email would still be sent to -devel about the initial list, of course, just like we currently do. So the first option is still on the table if you enjoy mental arithmetic. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On Wed, Sep 21, 2011 at 10:39:01AM +0100, Peekay Ex wrote: So, and this is a genuine question, why do you need to make a tiny patch so that a (next) larger patch works. Why not include the tiny patch in your larger patch (if that makes sense)? Remember when you were first learning doc stuff, and I kept on telling you to make smaller patches? It's just like that. I mean, pretend that you notice a typo in a doc section that you want to rearrange. Now, the rearranging will be contentious; we'll argue about the best order, the number of @nodes to use, whether we can make the examples shorter, etc. It's take weeks to discuss. But fixing that typo would only be a few seconds -- just get that done first! In the cases that David is suggesting, the typo is slightly more serious than a literal typo (i.e. it's something that should probably be examined by other developers), but it's still something that needs to get done before the other work can begin. In short, it's absolutely good software engineering to *not* include that tiny patch in the larger one. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Problem with make
On my fast build system, I can't currently get a successful make. Abort
changes, pull, clean build directory. The build ends with:
make[2]: Entering directory
`/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs'
LILYPOND_VERSION=2.15.13 [snip options] out/NEWS.tely
/usr/bin/python
/home/phil/lilypond-git/scripts/build/create-weblinks-itexi.py
out/weblinks.itexi
langdefs.py: warning: lilypond-doc gettext domain not found.
langdefs.py: warning: lilypond-doc gettext domain not found.
LANG= makeinfo --enable-encoding -I /home/phil/lilypond-git/Documentation -I
/home/phil/lilypond-git/Documentation/usage -I
/home/phil/lilypond-git/Documentation/contributor -I/home/phil/lilypond-git/Documentation/topdocs
-I./out --no-split --no-headers --output out/AUTHORS.txt out/AUTHORS.texi
out/AUTHORS.texi: No such file or directory
Reading out/NEWS.tely...
make[2]: *** [out/AUTHORS.txt] Error 1
make[2]: *** Waiting for unfinished jobs
Running texi2pdf on file /tmp/tmpCitEBl.texi to detect default page
settings.
Executing: LC_ALL=C texi2pdf -c -o /tmp/tmpCitEBl.pdf /tmp/tmpCitEBl.texi
Auto-detected values are: {'exampleindent': '10.16\\mm', 'line-width':
'160\\mm'}
Dissecting...
Writing snippets...
All snippets are up to date...
Compiling
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/NEWS.texi...
Writing
`/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/NEWS.texi'...
Processing include: macros.itexi
Reading /home/phil/lilypond-git/Documentation/macros.itexi...
Dissecting...
Writing snippets...
All snippets are up to date...
Compiling
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/macros.texi...
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/macros.texi
is up to date.
Processing include: version.itexi
Reading
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/version.itexi...
Dissecting...
Writing snippets...
All snippets are up to date...
Compiling
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/version.texi...
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/version.texi
is up to date.
Processing include: common-macros.itexi
Reading /home/phil/lilypond-git/Documentation/common-macros.itexi...
Dissecting...
Writing snippets...
All snippets are up to date...
Compiling
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/common-macros.texi...
/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs/out/common-macros.texi
is up to date.
lilypond-book.py (GNU LilyPond) 2.15.13
make[2]: *** wait: No child processes. Stop.
make[1]: *** [all] Error 2
rm out/weblinks.itexi
make[1]: Leaving directory
`/media/IntelSSD/lilypond/lilypond-git/build/Documentation'
make: *** [all] Error 2
As you see, the problem is a missing AUTHORS.texi. The odd thing is that on
previous make runs, I get
make[2]: Entering directory
`/media/IntelSSD/lilypond/lilypond-git/build/Documentation/topdocs'
(as above), but nothing is built - so I'm not sure why it's suddenly decided
to build NEWS.tely.
Is anyone else seeing this? Anyone aware of why this is happening?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
New patch set. I hope this is ready for to be pushed, now. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: On my fast build system, I can't currently get a successful make. Abort changes, pull, clean build directory. The build ends with: ... As you see, the problem is a missing AUTHORS.texi. The odd thing is that on previous make runs, I get yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/21 Peekay Ex pkx1...@gmail.com:
Hello,
On Wed, Sep 21, 2011 at 1:09 PM, Aleksandr Andreev
aleksandr.andr...@gmail.com wrote:
What's in the above file? It'll probably contain 5-10 other
filename
Yes. All the different snippets seem to have something to do with percussion.
You did see that I was able to build the documentation this morning on
your patch?
I think the problem is possibly the state of your tree you are building from.
The most interesting thing is that i got a make doc error too!
Here is what i see when i call 'git log --oneline':
5bb8482 Add glyphs for Kievan Notation
1b77637 Doc: update translation status.
41fca35 Doc-es: update Vocal.
9446d6a Merge branch 'master' into lilypond/translation
f2ac987 Doc-es: update Usage/Running.
7c6fe26 Doc-es: update Notation/Rhythms, Usage/LilyPond-Book.
adb80c0 Doc-es: update Input.
8dabf10 Doc-es: complete updating Programming Interface.
4469eaf Doc-es: update Programming interfaces.
a8b60ab parser.yy: Allow embedded_scm inside \book and \bookpart
ef8dd3e Merge branch 'release/unstable'
e166d07 Release: bump version.
a327032 Release: update news.
63cfd55 Release: update news.
1a41431 parser.yy: Use precedences to remove REPEAT/ALTERNATIVE
shift/reduce problem
0ae0eb4 parser.yy: Reorganization/cleanup
31e79fa define-markup-commands.scm: Fix bad parameter type for \on-the-fly
5483f4b Doc-fr: typo (notation/input)
4d8f987 Doc-es: update Changing defaults.
3930746 Fix 1896: chord names can have instrument names.
3c6e2cd Amend 16e626a85244: Forgot to change the function documentation string
ff38b00 doc build: Use all includes for texinfo also for the xref-map generation
16e626a Introduce a maximum depth for markup evaluation
25be0aa Fix 380: Try to auto-detect cyclic references in header fields
e2ebf57 Fix 380: Auto-detect all cyclic references in markups
f925133 Add some polyphonically directed grobs
2fff263 New short lyric tie.
ca53f84 Fix 1903: honor score-ending manual page breaks.
c5ad460 Uses Beam::is_knee instead of get_property (knee) to check
for kneed beams.
126b045 Doc: a more precise translation status.
f78e9c0 Doc-es: update Suggestions, Scheme, Updating.
7fb2a99 Doc-es: update CHANGES, Chords, Percussion, World,
usage/external, and more.
f8a4491 Fix missing linebreaks in output
e10a13c Formatting nits.
b551257 Warnings: Turn some normal messages into warnings
8653d9a Revert Release: update news.
ea4fdf1 Merge branch 'master' into lilypond/translation
5de09e7 Doc: adding doc strings for \...DashPattern and \harmonicBy...
fced4c8 Cleans the selector of reduced hole noteheads.
a2d8779 change longas similarly to how breves were changed
3f36a29 Revert change longas similarly to how breves were changed
79c2154 Revert variable fix
67e06fc variable fix
72b2acb change longas similarly to how breves were changed
b1bc02e Glossary: Fix snippets with Scale degree and function
31dd18a Make: Move comments out of the receipe; We don't want them to
be passed to the shell
b7fc79e Build fix : destroy nice python list comprehension
677f06b Release: update news.
463be0c Build: fix website (1892)
0e31cd9 Add missing files of the previous commit.
0dcc93c Improves parmesan noteheads.
Here is my error message:
\entry{Benutzung auf der Kommandozeile}{51}{\code {\xeatspaces {Benutzung auf d
er Kommandozeile}}}
\entry{lilypond-book}{51}{\code {\xeatspaces {lilypond-book}}}
] [52] [53] [54] [55] [56] [57]) Anhang B [58] (./usage.cps [59]) [60] )
(see the transcript file for additional information) /home/janek/.texmf-var/fo
nts/pk/ljfour/jknappen/ec/ecrm0900.600pk /home/janek/.texmf-var/fonts/pk/ljfo
ur/jknappen/ec/ecrm1095.603pk/usr/share/texmf-texlive/fonts/type1/public/amsf
onts/cm/cmb10.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmbx
12.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmcsc10.pfb/u
sr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmmi10.pfb/usr/share/te
xmf-texlive/fonts/type1/public/amsfonts/cm/cmmi12.pfb/usr/share/texmf-texlive
/fonts/type1/public/amsfonts/cm/cmmi9.pfb/usr/share/texmf-texlive/fonts/type1
/public/amsfonts/cm/cmr10.pfb/usr/share/texmf-texlive/fonts/type1/public/amsf
onts/cm/cmr7.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr8.
pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr9.pfb/usr/sha
re/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsl10.pfb/usr/share/texmf-te
xlive/fonts/type1/public/amsfonts/cm/cmsltt10.pfb/usr/share/texmf-texlive/fon
ts/type1/public/amsfonts/cm/cmsy10.pfb/usr/share/texmf-texlive/fonts/type1/pu
blic/amsfonts/cm/cmti10.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfon
ts/cm/cmti8.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt10
.pfb/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt12.pfb/usr/
share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt9.pfb/usr/share/texmf-
texlive/fonts/type1/public/amsfonts/latxfont/lcircle1.pfb/usr/share/texmf-tex
Re: Rietveld workflow problems
David Kastrup dak at gnu.org writes: The reason is that Rietveld just supports discussing and improving a single patch/commit. A counterexample http://codereview.appspot.com/4830064/ More complicated sets can benefit from Reitveld's ability to load patch sets relative to different baselines. I uploaded the counterexample above in the simple way, thinking it easy enough to choose delta from patch set one to see the code changes alone. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement define-event-function (issue 5083045)
Reviewers: ,
Message:
This allows defining music functions that can be used as directionless
events, a frequently made request. It may be noted that the amount of
code needed for implementing this functionality is not exactly
staggering given the current infrastructure in lexer and parser.
Example:
dyn=
#(define-event-function (parser location arg) (markup?)
(make-dynamic-script arg))
{ c1\dyn p }
Description:
Implement define-event-function
Please review this at http://codereview.appspot.com/5083045/
Affected files:
M lily/lexer.ll
M lily/parser.yy
M scm/c++.scm
M scm/lily.scm
M scm/music-functions.scm
Index: lily/lexer.ll
diff --git a/lily/lexer.ll b/lily/lexer.ll
index
db78e049f2597b09a0e772aa1f41e9e620aa12c3..e126e883071b0226728a2214bea9e79131c19f2e
100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -812,6 +812,8 @@ Lily_lexer::scan_escaped_word (string str)
if (scm_is_eq (cs, ly_lily_module_constant (ly:music?)))
funtype = MUSIC_FUNCTION;
+ else if (scm_is_eq (cs, ly_lily_module_constant (event?)))
+ funtype = EVENT_FUNCTION;
else if (ly_is_procedure (cs))
funtype = SCM_FUNCTION;
else programming_error (Bad syntax function predicate);
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index
82df956fa830db25b41bbcc3d9fcec7a56b378ea..1d88a648d6d832eef39863cc664cfc4534aa6070
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -286,6 +286,7 @@ If we give names, Bison complains.
%token scm PITCH_IDENTIFIER
%token scm DURATION_IDENTIFIER
%token scm EVENT_IDENTIFIER
+%token scm EVENT_FUNCTION
%token scm FRACTION
%token scm LYRICS_STRING
%token scm LYRIC_MARKUP_IDENTIFIER
@@ -393,6 +394,7 @@ If we give names, Bison complains.
%type scm embedded_scm_closed
%type scm embedded_scm_chord_body
%type scm embedded_scm_event
+%type scm event_function_event
%type scm figure_list
%type scm figure_spec
%type scm fraction
@@ -1680,6 +1682,13 @@ music_function_event:
}
;
+event_function_event:
+ EVENT_FUNCTION music_function_event_arglist {
+ $$ = run_music_function (PARSER, @$,
+$1, $2);
+ }
+ ;
+
command_element:
command_event {
$$ = $1;
@@ -1879,6 +1888,7 @@ direction_less_event:
a-set_property (tremolo-type, scm_from_int ($1));
$$ = a-unprotect ();
}
+ | event_function_event
;
direction_reqd_event:
Index: scm/c++.scm
diff --git a/scm/c++.scm b/scm/c++.scm
index
74f58f4da3f4da2449535f0faf6ca1034c85dcd0..17efd7e6b86e7b74cd44fd71d424795ff49f0aac
100644
--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -35,6 +35,11 @@
(and (pair? x)
(ly:moment? (car x)) (ly:moment? (cdr x
+(define-public (event? x)
+ (and (ly:music? x)
+ (memq 'event (ly:music-property x 'types))
+ #t))
+
(define-public (boolean-or-symbol? x)
(or (boolean? x) (symbol? x)))
Index: scm/lily.scm
diff --git a/scm/lily.scm b/scm/lily.scm
index
b82cd08aa2a2630077c06e38950eab438df7aa50..bea9662d5784ef6e962dcbc42a8e07ee0f55694f
100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -529,6 +529,7 @@ LilyPond safe mode. The syntax is the same as
`define*-public'.
`((,boolean-or-symbol? . boolean or symbol)
(,color? . color)
(,cheap-list? . list)
+(,event? . event)
(,grob-list? . list of grobs)
;; this is built on cheap-list
(,list-or-symbol? . list or symbol)
Index: scm/music-functions.scm
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index
e1ee53017392219563bd04d0700903421ac673db..75f72c05568fefc17c5a45348c3ba3ceb2f42ee1
100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -827,6 +827,28 @@ Syntax:
`(define-syntax-function scheme? ,@rest))
+(defmacro-public define-event-function rest
+ Defining macro returning event functions.
+Syntax:
+ (define-event-function (parser location arg1 arg2 ...) (arg1-type?
arg2-type? ...)
+...function body...)
+
+argX-type can take one of the forms @code{predicate?} for mandatory
+arguments satisfying the predicate, @code{(predicate?)} for optional
+parameters of that type defaulting to @code{#f}, @code{@w{(predicate?
+value)}} for optional parameters with a specified default
+value (evaluated at definition time). An optional parameter can be
+omitted in a call only when it can't get confused with a following
+parameter of different type.
+
+Predicates with syntactical significance are @code{ly:pitch?},
+@code{ly:duration?}, @code{ly:music?}, @code{markup?}. Other
+predicates require the parameter to be entered as Scheme expression.
+
+Must return an event expression. The @code{origin} is automatically
+set to the @code{location} parameter.
+
+ `(define-syntax-function (event? (make-music 'Event 'void #t)) ,@rest))
GOP-PROP 9: behavior of make doc (final)
I forgot to send the final version here. It was added to the CG, and nobody complained about the final versions being in the CG, but I should have still sent it for the email archives. http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-9-_002d-behavior-of-make-doc ** summary If there are build problems, then it should be easier to find out why it’s failing. This will be achieved with log files, as well as possibly including scripts which automatically display portions of those log files for a failing build. We will also add targets for building a specific manual (for quick+easy checking of doc work), as well as for building all documentation in a specific language (either English or a translated language). When you run make doc, * All output will be saved to various log files, with the exception of output directly from make(1). Note that make(1) refers to a specific executable file on unix computers, and is not a general term for the build system. * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. The user may optionally request additional output to be printed; this is controlled with the VERBOSE=x flag. In such cases, all output will still be written to log files; the console output is strictly additional to the log files. * Logfiles from calling lilypond (as part of lilypond-book) will go in the relevant ‘build/out/lybook-db/12/lily-123456.log’ file. All other logfiles will go in the ‘build/logfiles/’ directory. A single make doc will therefore result in hundreds of log files. Log files produced from individual lilypond runs are not under our control; apart from that, I anticipate having one or two dozen log files. As long as it is clear which log file is associated with which operation(s), I think this is entirely appropriate. The precise implementation will be discussed for specific patches as they appear. * Both stderr and stdout will be saved in *.log. The order of lines from these streams should be preserved. * There will be no additional “progress messages” during the build process. If you run make --silent, a non-failing build should print absolutely nothing to the screen. * Assuming that the loglevels patch is accepted, lilypond (inside lilypond-book) will be run with –loglevel=WARN. http://codereview.appspot.com/4822055/ * Ideally, a failing build should provide hints about the reason why it failed, or at least hints about which log file(s) to examine. None of these policies will be assumed to apply to any other aspect of the build system. Policies for any other aspect of the build system will be discussed in separate proposals. ** Don’t cause more build problems However, there is a danger in this approach, that vital error messages can also be lost, thus preventing the cause of the failure of a make being found. We therefore need to be exceptionally careful to move cautiously, include plenty of tests, and give time for people to experiment/find problems in each stage before proceeding to the next stage. This will be done by starting from individual lilypond calls within lilypond-book, and slowly moving to “larger” targets of the build system – after the individual lilypond calls are are producing the appropriate amount of output and this is saved in the right place and we can automatically isolate parts of a failing build, we will work on lilypond-book in general, and only then will we look at the build system itself. ** Implementation notes There is an existing make variable QUIET_BUILD, which alter the amount of output being displayed (http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables ). We are not planning on keeping this make variable. The standard way for GNU packages to give more output is with a V=x option. Presumably this is done by increasing x? If we support this option, we should still write log files; we would simply print more of the info in those log files to screen. The command tee may be useful to write to a file and display to stdout (in the case of VERBOSE). ** Discussions https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00378.html https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00703.html Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
I haven't looked at the code itself, but a regtest is definitely missing from the patch. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Causes lily to fail during regtests if binary is unoptimized. (issue 5067042)
Not acceptable in current form because it would cause GUB to fail a build. I suggest an alternate make target for this type of build. http://codereview.appspot.com/5067042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added note to CG about disable-optimizing (issue 5081048)
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):
http://codereview.appspot.com/5081048/diff/1/Documentation/contributor/regressions.itexi#newcode143
Documentation/contributor/regressions.itexi:143: be run with the
@code{--disable-optimising} option. Then you will need
On 2011/09/21 12:55:56, Colin Campbell wrote:
On 2011/09/21 08:43:09, Trevor Daniels wrote:
I think I'd mention just running ./autogen, just in
case the reader is doing the build for the first time.
But if you leave the configure option in it should be
./configure.
I believe the ../configure is appropriate for an out of tree build: it
would be
run from a /build directory, which we strongly recommend, no?
Yes, we very strongly recommend ../configure. And as far as I'm
concerned, there is no such thing as a
./autogen.sh
command; there is merely
./autogetn.sh --noconfigure
(followed by mkdir -p build/ ; cd build/ ; ../configure --options)
At this point in the CG, I don't think it's worth worrying about
somebody starting from a totally untouched git tree -- or rather, if
anybody _is_ in that state, they'll know to run autogen.sh first.
http://codereview.appspot.com/5081048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
reinhold.kainho...@gmail.com writes: I haven't looked at the code itself, but a regtest is definitely missing from the patch. http://codereview.appspot.com/5083045/ Writing regtests is one of my least favorite occupations. This feature has been requested so often that I'd appreciate somebody else to volunteer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: add a note about \relative f to notation (issue 1909) (issue 5096046)
http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely#newcode258 Documentation/notation/pitches.itely:258: If you carefully consider all the rules above and remember that the On 2011/09/21 07:50:05, dak wrote: Just One consequence of these rules is that would be quite more concise, +1 Graham's warning against complex language was quite valid; the monosyllabic version in the mail exchange a definite improvement. I'm not as concerned about monosyllabic words in Notation as I am about Learning, but it's still good to avoid them. Quite apart from putting (some) native English readers to sleep, those words are harder for non-native English speakers to read. http://codereview.appspot.com/5096046/diff/1/Documentation/notation/pitches.itely#newcode263 Documentation/notation/pitches.itely:263: On 2011/09/21 09:51:09, J_lowe wrote: Janek, something 'like' this: Absolute pitch disregards accidentals hmm, I agree with David here -- mentioning accidentals only confuses the issue. http://codereview.appspot.com/5096046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Clarify finer point of repeat unfold (issue 5075047)
LGTM. http://codereview.appspot.com/5075047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
Neil, David, I don't know what to do, could you help me? The attached patch works for me (haven't run make check on it though). I have taken the liberty of pushing it after looking it through thanks to both of you: the patch works and I've learnt something about LilyPond again. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
Am Wednesday, 21. September 2011, 21:26:54 schrieb David Kastrup:
reinhold.kainho...@gmail.com writes:
I haven't looked at the code itself, but a regtest is definitely missing
from the patch.
http://codereview.appspot.com/5083045/
Writing regtests is one of my least favorite occupations.
Huh? How do you verify that your feature works at all? I'm sure you are using
some simple test file for this. So, simply take that file, add a \header {
doctitle=some short description } and you're done.
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
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
On 2011/09/21 19:40:37, reinhold_kainhofer.com wrote:
Huh? How do you verify that your feature works at all? I'm sure you
are using
some simple test file for this. So, simply take that file, add a
\header {
doctitle=some short description } and you're done.
The example David's posted above doesn't work:
/home/neil/lilypond/out/share/lilypond/current/scm/ly-syntax-constructors.scm:50:9:
In expression (pred m):
/home/neil/lilypond/out/share/lilypond/current/scm/ly-syntax-constructors.scm:50:9:
Wrong type to apply: #f
Cheers,
Neil
http://codereview.appspot.com/5083045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
On 2011/09/18 19:55:47, Bertrand Bordage wrote: Another update that fixes some variable errors. It now passes make. thanks Bertrand, this is great work; I can now print flexae just the default way! (so long I had to use non-default viewers and lpr commands.) p http://codereview.appspot.com/5030053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
http://codereview.appspot.com/4553056/diff/106003/Documentation/included/special-characters.ly
File Documentation/included/special-characters.ly (right):
http://codereview.appspot.com/4553056/diff/106003/Documentation/included/special-characters.ly#newcode1
Documentation/included/special-characters.ly:1: \version 2.15.12
2.15.13
http://codereview.appspot.com/4553056/diff/106003/Documentation/included/special-characters.ly#newcode8
Documentation/included/special-characters.ly:8:
#(define-markup-list-command (show-special-characters layout props) ()
fix indentation (nearly every line)
http://codereview.appspot.com/4553056/diff/106003/Documentation/included/special-characters.ly#newcode13
Documentation/included/special-characters.ly:13: #:override
'(replacement-alist . ()) (car pair)
indentation is artificially compressed (aligns with the dangling
parenthesis)
http://codereview.appspot.com/4553056/diff/106003/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/106003/Documentation/notation/input.itely#newcode1762
Documentation/notation/input.itely:1762: \new Staff { \repeat unfold 9
a' }
a'4
http://codereview.appspot.com/4553056/diff/106003/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
http://codereview.appspot.com/4553056/diff/106003/Documentation/notation/notation-appendices.itely#newcode912
Documentation/notation/notation-appendices.itely:912: The rest of them
are inspired of LaTeX.
inspired by @LaTeX{}
http://codereview.appspot.com/4553056/diff/106003/input/regression/markup-special-characters.ly
File input/regression/markup-special-characters.ly (right):
http://codereview.appspot.com/4553056/diff/106003/input/regression/markup-special-characters.ly#newcode1
input/regression/markup-special-characters.ly:1: \version 2.15.12
2.15.13
http://codereview.appspot.com/4553056/diff/106003/input/regression/markup-special-characters.ly#newcode4
input/regression/markup-special-characters.ly:4: A list of special
characters ASCII aliases can be easily included.
character
http://codereview.appspot.com/4553056/diff/106003/input/regression/markup-special-characters.ly#newcode5
input/regression/markup-special-characters.ly:5: This works for markups
and lyrics.
remove leading spaces
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc
File lily/text-interface.cc (right):
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode43
lily/text-interface.cc:43: if (!to_boolean (scm_list_p
(replacement_alist))
!ly_is_list
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode44
lily/text-interface.cc:44: || to_boolean (scm_null_p
(replacement_alist)))
scm_is_null
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode51
lily/text-interface.cc:51: (scm_string_length (scm_caar (s;
fix indent (run through fixcc.py)
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode56
lily/text-interface.cc:56: for (int j = max_length; j 0; j--)
(vsize j = max_length; j--;)
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode60
lily/text-interface.cc:60: (ly_assoc_get (ly_string2scm (dummy),
fix indent
http://codereview.appspot.com/4553056/diff/106003/lily/text-interface.cc#newcode61
lily/text-interface.cc:61: replacement_alist, SCM_BOOL_F), );
fix indent
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly
File ly/text-replacements.ly (right):
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode20
ly/text-replacements.ly:20: #(define (add-text-replacements! alist)
fix indentation
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode26
ly/text-replacements.ly:26: (add-text-replacements!
fix indentation
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode27
ly/text-replacements.ly:27: '(; Punctuation
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode36
ly/text-replacements.ly:36: ; French, German and English quotes
open/close
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode50
ly/text-replacements.ly:50: ; Word dividers
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode60
ly/text-replacements.ly:60: ; General typography
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode77
ly/text-replacements.ly:77: ; Diacritics
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode88
ly/text-replacements.ly:88: ; Non-ASCII Letters (Excluding Accented
Letters)
;;
http://codereview.appspot.com/4553056/diff/106003/ly/text-replacements.ly#newcode110
ly/text-replacements.ly:110: ; Mathematical symbols
;;
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
http://codereview.appspot.com/5030053/diff/2004/lily/mensural-ligature.cc File lily/mensural-ligature.cc (right): http://codereview.appspot.com/5030053/diff/2004/lily/mensural-ligature.cc#newcode74 lily/mensural-ligature.cc:74: = (me-layout ()-get_dimension (ly_symbol2scm (blot-diameter))); remove extra parens http://codereview.appspot.com/5030053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
On 2011/09/21 19:44:46, Neil Puttock wrote:
On 2011/09/21 19:40:37, http://reinhold_kainhofer.com wrote:
Huh? How do you verify that your feature works at all? I'm sure you
are using
some simple test file for this. So, simply take that file, add a
\header {
doctitle=some short description } and you're done.
The example David's posted above doesn't work:
/home/neil/lilypond/out/share/lilypond/current/scm/ly-syntax-constructors.scm:50:9:
In expression (pred m):
/home/neil/lilypond/out/share/lilypond/current/scm/ly-syntax-constructors.scm:50:9:
Wrong type to apply: #f
Sigh. Looks like I mixed up branches/binaries again while testing: this
one requires the patch for optional music arguments to be applied first.
I'll see whether I can factor out the relevant functionality into a
separate patch and commit it to master.
I apologize for the confusion.
http://codereview.appspot.com/5083045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
http://codereview.appspot.com/5083045/diff/1/scm/c++.scm File scm/c++.scm (right): http://codereview.appspot.com/5083045/diff/1/scm/c++.scm#newcode38 scm/c++.scm:38: (define-public (event? x) I'd prefer a less vague name for this since it's going to conflict with the stream event predicate (currently ly:stream-event?) when we get round to renaming Stream_event - Event http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Progress on loose columns. (issue 4841052)
LGTM. http://codereview.appspot.com/4841052/diff/25001/input/regression/spacing-loose-polyphony.ly File input/regression/spacing-loose-polyphony.ly (right): http://codereview.appspot.com/4841052/diff/25001/input/regression/spacing-loose-polyphony.ly#newcode1 input/regression/spacing-loose-polyphony.ly:1: \version 2.15.9 2.15.13 http://codereview.appspot.com/4841052/diff/25001/input/regression/spacing-loose-polyphony.ly#newcode4 input/regression/spacing-loose-polyphony.ly:4: texidoc = Loose columns are spaced correctly in describe which columns are loose in the example http://codereview.appspot.com/4841052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Terminates outside_staff_callback early if a grob is outside a slur's X-extent (issue 5056041)
Needs a regression test.
This might do:
\relative c'' {
\set strokeFingerOrientations = #'(up)
\override StrokeFinger #'avoid-slur = #'outside
a-\rightHandFinger #2 16( b)
}
http://codereview.appspot.com/5056041/diff/1/lily/slur.cc
File lily/slur.cc (right):
http://codereview.appspot.com/5056041/diff/1/lily/slur.cc#newcode278
lily/slur.cc:278: contains = contains || slur_wid.contains (xext[d]);
contains |= slur_wid.contains (xext[d]);
http://codereview.appspot.com/5056041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 10: scheme indentation
I've added make it work like emacs to the proposal. http://lilypond.org/~graham/gop/gop_10.html ** Proposal summary Speaking academically, scheme code style is a “solved problem”. Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to source code. The script will be scripts/auxiliar/fix-scheme.sh ** Rationale New contributors sometimes struggle to follow our indentation and code style – this is especially difficult when parts of our existing source code doesn’t have a consistent style. This is problematic... we want new contributors to be struggling with the lilypond architecture, not playing games in their text editors! ** Proposal details Use: http://codereview.appspot.com/4896043/ I will auto-indent all ‘.scm’ files in the git tree on 2011 Oct 15. ** Desired indentation style There is a request that the script format scheme files like emacs does. I am not aware of any objections to this, so let’s try to make it so. ** Implementation notes The C++ change went quite well, and we have far fewer outstanding patches for scheme code. No problems anticipated. We will not manually specify what the scheme files should look like as part of this proposal; just run that script on your files. Interested parties may add an unofficial description of the scheme indentation to the CG if they are interested. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On Wed, Sep 21, 2011 at 09:27:39AM -0600, Carl Sorensen wrote: On 9/21/11 6:48 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Gerrit is certainly an option, although I'm not encouraged by the discussion about it so far. Google Code now supports git archives. Reviews in Google Code are done on branches, and each commit on the branch is visible and reviewable. If you want to see how it works, I've got a sandbox for another project set up at http://code.google.com/p/plant-sim/source/list Hmm, interesting. Does anybody want to look into this in more detail? This all ties in nicely with the just-opened patch management proposal: http://lilypond.org/~graham/gop/gop_13.html I'm reasonably certain we can write a python script which requests a review and adds a patch-new issue to the tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Tue, Sep 20, 2011 at 09:32:55AM +0100, Trevor Daniels wrote: Graham Percival wrote Tuesday, September 20, 2011 12:09 AM * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. Hmm. There are often comments which don't necessarily imply disapproval (or approval for that matter). I've vague-ified the description about this script. The exact behaviour can be determined later. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
Thanks a lot, Neil. Could you have a last look at the Scheme files? I'm not sure of the indentation. I created a new scm/text.scm file for the definitions I couldn't put elsewhere. Bertrand http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Tue, Sep 20, 2011 at 09:04:39PM +0200, Janek Warchoł wrote: My impression is that the main problem is the duplicancy of data and e-mail threads. Over and over again i'm getting lost, for example: I can't see that going away. - email is the most convenient option for quick discussion - rietveld is the best option (other than other potential review tools) for discussing specific bits of code - issue tracker keeps comments in a more organized archived state It would be nice if specific patches/issues were discussed on either rietveld or the issue tracker, but I can't see everybody doing this. One thing comes to my mind: there is some code revieving tool on Google Code. I remember that i saw it being used in some other project. It's a bit hidden, but i managed to found some info: http://code.google.com/p/support/wiki/CodeReviews Looks that we need to add our source code to the Google Code to be able to use that. I think this may be worth considering. Could we add our source to Google Code and see what we can do then? Of course it's worth considering, but I don't see that cutting down on the duplicate discussions. Another thing: i'd consider adding a policy about separating discussion about code and notation: comments on issue tracker should be about notation/features (i.e. what should the output be? What syntax do we want to use?) and all comments about code itself (is the indentation correct? Does it pass regtests?) should be done at code revieving tool. I don't see that going well; the people we most want comments from (i.e. senior developers) are the people who are the least likely to log into a website and comment there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
http://codereview.appspot.com/5083045/diff/1/scm/c++.scm File scm/c++.scm (right): http://codereview.appspot.com/5083045/diff/1/scm/c++.scm#newcode38 scm/c++.scm:38: (define-public (event? x) On 2011/09/21 21:32:30, Neil Puttock wrote: I'd prefer a less vague name for this since it's going to conflict with the stream event predicate (currently ly:stream-event?) when we get round to renaming Stream_event - Event Hm. It corresponds to 'event being in types. Since parser.yy also checks this property in C, it might make sense implementing it in C and offering ly:event? for calling it instead. Since ly:music? is valid for all music objects having 'music in types, and not just those of class Music, I can't quite see a good reason for preferring ly:event? or event? to point to an Event music class. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Tue, Sep 20, 2011 at 07:05:04AM -0600, Colin Campbell wrote: The remaining case is where there are no comments when a countdown expires. I've been taking that as silence implying consent, but with no assurance that anyone has actually reviewed the patch. Yes, that's correct. Think of the question in marriage ceremonies: if anybody knows of a reason why these two should not be wed, speak now or forever hold your peace.. Despite what one reads[1] in trashy romance novels, that question is mostly ceremonial -- nobody actually expects an objection. That's supposed to happen when you're still dating. So think of Patch-review as dating, and Patch-countdown as a marriage ceremony. :) (but don't delay the countdown just because they've only been dating for a few hours; if there's space left on the countdown, might as well go for it. I guess the analogy kind-of breaks down here) [1] *cough* I mean, theoretically. Based on what I've heard. I'm not an expert on the subject. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
http://codereview.appspot.com/5083045/diff/1/scm/c++.scm File scm/c++.scm (right): http://codereview.appspot.com/5083045/diff/1/scm/c++.scm#newcode38 scm/c++.scm:38: (define-public (event? x) On 2011/09/21 22:14:40, dak wrote: On 2011/09/21 21:32:30, Neil Puttock wrote: I'd prefer a less vague name for this since it's going to conflict with the stream event predicate (currently ly:stream-event?) when we get round to renaming Stream_event - Event Hm. It corresponds to 'event being in types. Since parser.yy also checks this property in C, it might make sense implementing it in C and offering ly:event? for calling it instead. Since ly:music? is valid for all music objects having 'music in types, and not just those of class Music, I can't quite see a good reason for preferring ly:event? or event? to point to an Event music class. Hm[2]. In scm/define-music-display-methods.scm (of all files) there is a definition post-event? apparently intended for something like this. More or less: it checks for a number of classes explicitly instead of looking at types. But that's not what lily/parser.yy does for deciding whether to interpret a Scheme value as MUSIC_IDENTIFIER or EVENT_IDENTIFIER. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Updated Documentation/notation/notation-appendices.itely to show new glyphs, reflecting comments by Neil. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
pkx1...@gmail.com pkx1...@gmail.com writes: hello, On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: On my fast build system, I can't currently get a successful make. Abort changes, pull, clean build directory. The build ends with: ... As you see, the problem is a missing AUTHORS.texi. The odd thing is that on previous make runs, I get yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. I probably run make about 10 times a day at the moment, checking patches. I'm used to it and just assumed it was one of our build quirks. You'll see lots more on faster machines in my own personal experience. That points to either a problem with parallel make processes, or more likely a time stamp resolution problem. When file modification dates are only accessed with second resolution (because the info is not available in the file system type, or the application does not use it) and a process for updates is quite fast, an updated dependent file may seem to have the same time stamp as its original. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
Ok, I have made this based off origin/master, and I moved the stuff to using ly:event? instead of event? (not really addressing Neil's issue at all, merely for somewhat more symmetry to ly:music?). Untested. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
If this can be verified as working, it might go on the patch countdown, barring comments that require addressing. Note that ly:event? is not part of the public API of define-event-function: if ly:event?'s function name changes at some later point of time, uses of define-event-function will not need to adapt. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Yet another rm -fdr build/ and re-run of make, etc., eliminated my original problem with snippets. Now, my make doc command crashes with the same error message that Janek is getting. Looks like there's a missing file web.texi. Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On 11-09-21 04:13 PM, Graham Percival wrote: On Tue, Sep 20, 2011 at 09:04:39PM +0200, Janek Warchoł wrote: My impression is that the main problem is the duplicancy of data and e-mail threads. Over and over again i'm getting lost, for example: I can't see that going away. - email is the most convenient option for quick discussion - rietveld is the best option (other than other potential review tools) for discussing specific bits of code - issue tracker keeps comments in a more organized archived state It would be nice if specific patches/issues were discussed on either rietveld or the issue tracker, but I can't see everybody doing this. One thing comes to my mind: there is some code revieving tool on Google Code. I remember that i saw it being used in some other project. It's a bit hidden, but i managed to found some info: http://code.google.com/p/support/wiki/CodeReviews Looks that we need to add our source code to the Google Code to be able to use that. I think this may be worth considering. Could we add our source to Google Code and see what we can do then? Of course it's worth considering, but I don't see that cutting down on the duplicate discussions. Another thing: i'd consider adding a policy about separating discussion about code and notation: comments on issue tracker should be about notation/features (i.e. what should the output be? What syntax do we want to use?) and all comments about code itself (is the indentation correct? Does it pass regtests?) should be done at code revieving tool. I don't see that going well; the people we most want comments from (i.e. senior developers) are the people who are the least likely to log into a website and comment there. Cheers, - Graham I'm solidly with Janek here, Graham. As it sits, a person wanting to follow the trail of a (bug/issue/enhancement request) has to find the thing on two separate web-sites, where developers log in despite your comment above, using two different tracking numbers and possibly two different descriptions. The curious person also has to read -devel and -bug to be sure nothing relevant was sent mail-list only. No doubt it would be a wrench converting to a code management system, but I firmly believe the benefits from having all relevant material, discussions, patches and reviews, in a single place, are immediately large, and that although there is no way to quantify it but one can reasonably expect it, a synergy will develop where unexpected things happen as a result of seeing a bigger picture. I know this is a change from my earlier vote for your collection of automagic scripts and linkages, but ISTM that's reinventing wheels in an effort to avoid change. We are accustomed to using two quite different tools, each very good at what it does, but with upwards of 600 issues live at any time, I don't think tying a rock to a stick with a lot more thongs is the answer: I think we need a hammer designed for the purpose. Cheers Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
On Thu, Sep 22, 2011 at 01:59:53AM +0200, David Kastrup wrote: David Kastrup d...@gnu.org writes: pkx1...@gmail.com pkx1...@gmail.com writes: hello, On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: On my fast build system, I can't currently get a successful make. Abort changes, pull, clean build directory. The build ends with: ... As you see, the problem is a missing AUTHORS.texi. The odd thing is that on previous make runs, I get Expounding on that theory and doing pattern matching: does the problem get better or worse when you replace the in python/book_snippets.py:781: os.stat (single)[stat.ST_MTIME]))): with = ? I doubt that's the issue; AUTHORS.texi has nothing to do with lilypond-book. We do something weird and complicated to build the TOPDOC_FILES. I've tried poking around every so often, but I always get lost around the third or fourth redirect. If anybody wants to go spelunking, start off with git grep AUTHORS and pay particular attention to any GNUmakefile or anything in make/ or stepmake/ or stepmake/stepmake/ . Sooner or later, you'll find out exactly how AUTHORS.texi is built, but I would budget at least an hour for grepping and reading various build files. Also, keeping notes with pen and paper might not be a bad idea. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On 9/21/11 9:25 PM, Colin Campbell c...@shaw.ca wrote: On 11-09-21 04:13 PM, Graham Percival wrote: On Tue, Sep 20, 2011 at 09:04:39PM +0200, Janek Warchoł wrote: One thing comes to my mind: there is some code revieving tool on Google Code. I remember that i saw it being used in some other project. It's a bit hidden, but i managed to found some info: http://code.google.com/p/support/wiki/CodeReviews Looks that we need to add our source code to the Google Code to be able to use that. I think this may be worth considering. Could we add our source to Google Code and see what we can do then? Of course it's worth considering, but I don't see that cutting down on the duplicate discussions. I'm solidly with Janek here, Graham. As it sits, a person wanting to follow the trail of a (bug/issue/enhancement request) has to find the thing on two separate web-sites, where developers log in despite your comment above, using two different tracking numbers and possibly two different descriptions. The curious person also has to read -devel and -bug to be sure nothing relevant was sent mail-list only. No doubt it would be a wrench converting to a code management system, but I firmly believe the benefits from having all relevant material, discussions, patches and reviews, in a single place, are immediately large, and that although there is no way to quantify it but one can reasonably expect it, a synergy will develop where unexpected things happen as a result of seeing a bigger picture. From my initial exploration of Code Review on Google Code, I don't see any way to make an automatic linkage from a code review request to an issue. In fact, a code review request makes a new issue... Oh, wait, I guess we could link the code review request to the issue(s) that generated the patch, so maybe the linkage is possible. I'll try it on my sandbox. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Wed, Sep 21, 2011 at 09:25:45PM -0600, Colin Campbell wrote: I'm solidly with Janek here, Graham. As it sits, a person wanting to follow the trail of a (bug/issue/enhancement request) has to find the thing on two separate web-sites, where developers log in despite your comment above, using two different tracking numbers and possibly two different descriptions. The curious person also has to read -devel and -bug to be sure nothing relevant was sent mail-list only. Yep. I'd describe it as three websites, though -- the email archives being the third. And even then, the discussion may very well span multiple email lists (start off on -user, migrate to bug-, then to -devel?). It's a royal mess. No doubt it would be a wrench converting to a code management system, but I firmly believe the benefits from having all relevant material, discussions, patches and reviews, in a single place, are immediately large, and that although there is no way to quantify it but one can reasonably expect it, a synergy will develop where unexpected things happen as a result of seeing a bigger picture. Any ideas on how to deal with people who only want to deal with email? Suppose that we switch to a unified issue+patch tool. Then suppose that somebody posts patch, an automatic email is sent out, and I quickly reply to that email saying nice idea, but it won't work because XYZ, but you can work around that by adding this one line of code ABC because I need to go teach a class in 2 minutes, but I knew I had the solution right away and wanted to let the person know. What happens to that email? - somebody manually adds is to the unified tool? - somebody tells me to screw off for not playing ball? - everybody pretends that email didn't exist, and spends hours trying to figure out ABC? For better or worse, the open-source community has a huge history of development via email. We simply cannot survive if we break with that. Now, some tools will automatically accept replies via email; we've had mixed success doing that with tracker issues and Rietveld discussions. If somebody can step forward with a tool that provides flawless support for email, I guess it's worth discussing. My vague recollection is that the google project tools have easy support for email as long as everybody is using google accounts. Not just have access to a google account, but is using the email address associated with their google account. I suppose it's not so much of a big step to require this for lilypond developers -- but on the other hand, I'm concerned that we're getting too far away from the ideals of a GNU project. I generally don't have a lot of patience for the more hard-line FSF people, but even I'm getting worried about the direction we're heading. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20110923
For 20:00 CDT Friday September 23 (no, the time is not a typo: I'll be visiting my Mother in Ontario, and hope to borrow her browser) Issue 935 http://code.google.com/p/lilypond/issues/detail?id=935: Enhancement: optional arguments in music functions - R 5023044 http://codereview.appspot.com/5023044/ Issue 1477 http://code.google.com/p/lilypond/issues/detail?id=1477: suppress output for expected warnings - R 5037046 http://codereview.appspot.com/5037046/ Issue 1801 http://code.google.com/p/lilypond/issues/detail?id=1801: Clarify \repeat unfold in the documentation - R 5075047 http://codereview.appspot.com/5075047/ Issue 1897 http://code.google.com/p/lilypond/issues/detail?id=1897: Automatically set the eps backend in lilypond-book-preamble.ly - R 5038045 http://codereview.appspot.com/5038045/ Issue 1905 http://code.google.com/p/lilypond/issues/detail?id=1905: Add note to CG 9.3 'Compiling reg tests' to add --disable-optimising when using autogen.sh or configure - R 5081048 http://codereview.appspot.com/5081048/ Issue 1891 http://code.google.com/p/lilypond/issues/detail?id=1891: New alist to replace special characters - R 4553056 http://codereview.appspot.com/4553056/ Rietveld Issue 5083045 http://codereview.appspot.com/5083045/: Implement define-event-function Cheers, Colin ps: I use a filter in my email client to send everything with patch in the subject to a special folder, so that it stands out from the background hum of -devel, -bug and -user. -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/21 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł janek.lilyp...@gmail.com [snip] It's the first time i tried compiling docs, so i may have screwed something. Here's what i did: rm -r build sh autogen.sh --noconfigure mkdir -p build/ cd build/ ../configure make make doc That looks OK - although you don't need the autogen if you've done it before. A quick look at what you have above makes it seem like you have missing files. Is your git tree up to date and in good shape? Overnight i tried making doc on current master and it failed too. Looks like the error message is the same: writing: /home/janek/lilypond-git/build/./out-www/xref-maps/extending.de.xref-map /home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames -o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I /home/janek/lilypond-git/Documentation/de -I /home/janek/lilypond-git/Documentation/de/included -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/build/Documentation/./out-www --master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/learning.xref-map out-www/learning.texi extract_texi_filenames.py: Processing out-www/learning.texi Warning: No such file: learning/working.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) Warning: No such file: learning/scheme-tutorial.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) writing: /home/janek/lilypond-git/build/./out-www/xref-maps/learning.de.xref-map /home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames -o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I /home/janek/lilypond-git/Documentation/de -I /home/janek/lilypond-git/Documentation/de/included -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/build/Documentation/./out-www --master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/notation.xref-map out-www/notation.texi extract_texi_filenames.py: Processing out-www/notation.texi Warning: No such file: notation/programming-interface.itely (search path: .:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www) writing: /home/janek/lilypond-git/build/./out-www/xref-maps/notation.de.xref-map /home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames -o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I /home/janek/lilypond-git/Documentation/de -I /home/janek/lilypond-git/Documentation/de/included -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/build/Documentation/./out-www --master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/usage.xref-map out-www/usage.texi extract_texi_filenames.py: Processing out-www/usage.texi writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 make[3]: Leaving directory `/home/janek/lilypond-git/build/Documentation/de' make[2]: *** [WWW-1] Error 2 rm out-www/weblinks.itexi make[2]: Leaving directory `/home/janek/lilypond-git/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/janek/lilypond-git/build' make: *** [doc-stage-1] Error 2 Before you do this, though, go through the steps above with a good git tree and instead of running make doc, run make -d doc somefile.txt. Then zip the output and send it my way some convenient way. I'll try this too, but probably not today. cheers, Janek PS i guess i know now why GOP-PROP 9 (bahavior of make doc) is so important... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
2011/9/21 Carl Sorensen c_soren...@byu.edu: On 9/21/11 6:48 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup: Perhaps it would be nice if we found a way to play with Gerrit, supposedly a git-based system similar to Rietveld. I looked at gerrit a while ago. If you want to take a look at it: http://server.kainhofer.com:8088/ Google Code now supports git archives. Reviews in Google Code are done on branches, and each commit on the branch is visible and reviewable. I'm not sur if I like the way reviews are requested, but doing the review by branches seems to work out quite well. If you want to see how it works, I've got a sandbox for another project set up at http://code.google.com/p/plant-sim/source/list You can choose either of two branches in a selection list, and you can review any commit by clicking on the SHA-1 ID. Looks interesting, however i seem to be unable to add comments - probably because i'm not a project member. Could you enable adding comments by non-project members and could we mess with that repository a bit by sending bogus reviews etc? thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On Thu, Sep 22, 2011 at 06:22:13AM +0200, Janek Warchoł wrote: Overnight i tried making doc on current master and it failed too. ef8dd3eaee73588faf1a6687407a6fda60cff591 worked perfectly in ubuntu 10.04 (not quite lilydev) for me a few hours ago. 63cfd5548c42a98c7dae43f1f92e67772969e53c worked with no problems in GUB. Looks like the error message is the same: writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 ... you know, I'm now remembering a nasty bug I saw last Christmas. Are you using the latest lilydev with all upgrades? In particular, all kernel upgrades? The previous version of lilydev had mysterious+magical problems, when running inside virtualbox, due to a kernel issue. It was very reproducible, but only inside virtualbox, but it went away in the latest version of lilydev so I stopped investigating. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble: Automatically set the eps backend, since we require it anyway (issue 5038045)
LGTM http://codereview.appspot.com/5038045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110923
On Wed, Sep 21, 2011 at 10:17:59PM -0600, Colin Campbell wrote: For 20:00 CDT Friday September 23 (no, the time is not a typo: I'll be visiting my Mother in Ontario, and hope to borrow her browser) I've just nuked two of those because there's existing complaints/suggestions on Rietveld. I also added a tracker issue for define-event-function. Latest list here: http://code.google.com/p/lilypond/issues/list?can=2q=patch=countdown Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
2011/9/21 Graham Percival gra...@percival-music.ca: On Wed, Sep 21, 2011 at 08:20:39AM +0200, Jan Nieuwenhuizen wrote: David Kastrup writes: Personally, I'd prefer it if we focused on solving rather than creating real problems. +1 Automatic indentation *does* solve real problems. Take a look at this: http://codereview.appspot.com/4490045/ and then compare with the final commit: 258dd9a854b627b533ab709a137b23c539857838 Drafts 3-9 were indentation. Note that discussion involved me, Carl, Janek, Janek, and Benko -- that's a lot of lilypond development experience. And yet the end result was still 5 weeks to get a ~50 line patch from a new contributor contributor. Gee, I wonder why we haven't seen any more patches from that new contributor? /sarcasm Now admittedly I haven't seen anything like that for scheme indentation, but I never want to. If a simple script can lower the chances of driving away new contributors, let's go for it. Yes. There are two acceptable choices about indentation: don't care about it at all, or have an auto-indenting script and therefore don't have to worry about it at all. Issue 1630 was a nightmare. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/22 Graham Percival gra...@percival-music.ca: On Thu, Sep 22, 2011 at 06:22:13AM +0200, Janek Warchoł wrote: Overnight i tried making doc on current master and it failed too. ef8dd3eaee73588faf1a6687407a6fda60cff591 worked perfectly in ubuntu 10.04 (not quite lilydev) for me a few hours ago. 63cfd5548c42a98c7dae43f1f92e67772969e53c worked with no problems in GUB. Well, i tried 1b77637344d0eb5361186f7049cb1b0e61720e2f, which is a direct descendant of ef8dd3eaee73588faf1a6687407a6fda60cff591. However, i remember from a speech by Linus http://www.youtube.com/watch?v=4XpnKHJAok8 (0:56:20) that the committishes being SHA-1 checksums means that the history must be ok if the hashes match - so our histories up to the point of ef8dd3eaee73588faf1a6687407a6fda60cff591 should be precisely the same, did i get it right? Looks like the error message is the same: writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 ... you know, I'm now remembering a nasty bug I saw last Christmas. Are you using the latest lilydev with all upgrades? In particular, all kernel upgrades? The previous version of lilydev had mysterious+magical problems, when running inside virtualbox, due to a kernel issue. It was very reproducible, but only inside virtualbox, but it went away in the latest version of lilydev so I stopped investigating. Hmm. I don't remember which version it is (how can i check it? System - about Ubuntu says only You are using Ubuntu 10.04 LTS - the Lucid Lynx - released in April 2010), but i've installed it quite a while ago (it was definately before holidays). I've updated it something like a week ago. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
