Re: Code review/discussion time again.
Am Sonntag, 22. November 2009 07:49:04 schrieb David Kastrup: > Carl Sorensen writes: > > And if you have the source tree in a git repository, then it's trivial to > > make branches, and checkout the appropriate branch. That way you don't > > have to worry about overwrites (and if you do have overwrite problems, > > then you just reset the head). > > > > It's no problem at all, if you do it that way. > > Hello merge conflict, my old friend, I've come to talk with you again... > > If you have ever worked in a project with a central ChangeLog file, you > know the permanent hassle with switching branches when some changes > require entries in a central file. With git this is not really a problem. I'm constantly working with 5-10 different branches. Every now and then, I rebase them to current master, but apart from that each branch is isolated, doesn't influence each other, and changes to the global news file, etc. can be merged when I want to do a rebase. Really, once you have learned how to use git rebase (and the manual merging it sometimes requires), working with branches in git is really no problem at all. 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/4] scm/define-markup-commands.scm: remove some unnecessary lookups
Am Montag, 23. November 2009 01:03:10 schrieb David Kastrup: > --- > scm/define-markup-commands.scm |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > This patch series makes the syntax of builtin markup > commands upwards compatible with the user level ones. Wrong description for what this particular patch does, but apart from that, it totally makes sense to me to commit it. 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 2/4] scm/harp-pedals.scm: Fold make-harp-pedal into \harp-pedal markup.
Am Montag, 23. November 2009 01:03:11 schrieb David Kastrup: > The already outcommented problematic \harp-pedal-verbose markup is > removed completely. Inlining make-harp-pedal makes it possible to use > the property binding mechanism of define-builtin-markup-command in > order to minimize inconsistencies between documentation and behavior. As the author of the harp pedals code, I'm fine with that change (provided the regtest still works, which I haven't checked). 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code review/discussion time again.
Am Montag, 23. November 2009 07:19:58 schrieb David Kastrup: > Han-Wen Nienhuys writes: > > this is exactly why do not have a central ChangeLog file. > > Sure, that's sane. I am just saying that a central place to register > properties has the same problem. No, with a ChangeLog, changes are always appended at the beginning (or at the end), so two persons adding entries will invariably lead to automatic merge problems. However, properties are alphabetically sorted, so the longer the list, the smaller the chance that the two committers are working on the same three lines that are relevant to the two patches. If the patches don't overlap, the automatic merge of git rebase or git merge will take care of the merge, and you won't see any problems. 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help wanted page
Valentin Villenave wrote: On Sun, Nov 22, 2009 at 7:05 PM, David Pounder wrote: Very small point, but the phrase "Frogs are simple LilyPond users" would be better expressed as "Frogs are simply LilyPond users" as the former has an undesired implication, at least in UK English. Hehe. It never occurred to me, but now that you're mentioning it... :-) Cheers, Valentin Probably the best phrasing is "Frogs are ordinary Lilypond users". Maybe Vincent didn't write this because "ordinaire" in French can also mean "vulgar" or "common-as-muck". I'm sure Vincent would never dream of writing something like that about is Frogs. . .:-}. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code review/discussion time again.
Reinhold Kainhofer writes: > Am Sonntag, 22. November 2009 07:49:04 schrieb David Kastrup: >> Carl Sorensen writes: >> > And if you have the source tree in a git repository, then it's trivial to >> > make branches, and checkout the appropriate branch. That way you don't >> > have to worry about overwrites (and if you do have overwrite problems, >> > then you just reset the head). >> > >> > It's no problem at all, if you do it that way. >> >> Hello merge conflict, my old friend, I've come to talk with you again... >> >> If you have ever worked in a project with a central ChangeLog file, you >> know the permanent hassle with switching branches when some changes >> require entries in a central file. > > With git this is not really a problem. What about "entries in a central file" was not understandable here? > I'm constantly working with 5-10 different branches. Every now and > then, I rebase them to current master, but apart from that each branch > is isolated, doesn't influence each other, and changes to the global > news file, etc. can be merged when I want to do a rebase. > > Really, once you have learned how to use git rebase (and the manual > merging it sometimes requires), working with branches in git is really > no problem at all. Thanks for telling me, but I've been the main feature merger in my last job for years, using git-svn. I prefer interface designs not requiring registration in central files. When you frequently rebase stuff consisting of hundreds of commits, you don't really want to have a significant percentage of manual merges. More bluntly: if managing extensions is not feasible without a version control system, the design is faulty, like a computer that you can't assemble without a soldering iron. I _have_ managed computers with soldering iron and hand-wiring. It is not merely incompetence when I consider it not the way to go. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help wanted page
Ian Hulin writes: > Valentin Villenave wrote: >> On Sun, Nov 22, 2009 at 7:05 PM, David Pounder wrote: >>> Very small point, but the phrase "Frogs are simple LilyPond users" would be >>> better expressed as "Frogs are simply LilyPond users" as the former has an >>> undesired implication, at least in UK English. >> >> Hehe. It never occurred to me, but now that you're mentioning it... :-) >> >> Cheers, >> Valentin > Probably the best phrasing is "Frogs are ordinary Lilypond > users". Maybe Vincent didn't write this because "ordinaire" in French > can also mean "vulgar" or "common-as-muck". I'm sure Vincent would > never dream of writing something like that about is Frogs. . .:-}. I prefer "interested". Avoids lots of pitfalls and sensitivities. And lists the sole relevant qualification. You don't need sub-wizard coding abilities to choose the way of the frog. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/4] scm/define-markup-commands.scm: remove some unnecessary lookups
Reinhold Kainhofer writes: > Am Montag, 23. November 2009 01:03:10 schrieb David Kastrup: >> --- >> scm/define-markup-commands.scm |3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> This patch series makes the syntax of builtin markup >> commands upwards compatible with the user level ones. > > Wrong description for what this particular patch does, Which is why it is not in the patch's commit message but only in the non-committed part of the mail body, and talks about "patch series" (of which this is the first patch) rather than "patch". I was just trying to be helpful. > but apart from that, it totally makes sense to me to commit it. Thanks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code review/discussion time again.
On Mon, Nov 23, 2009 at 4:02 AM, David Kastrup wrote: >>> I have no idea what I am doing here. In particular not with the >>> \override, and the set-object-property!. Can somebody explain to me >>> just what data structures I happen to manipulate, and how a user is >>> actually _supposed_ to be mangling them? >> >> Perhaps you could explain us how accordion notation works; that will >> make it easier to give advice on how to best achieve your targets. > > In the context of _this_ patch, we are just placing register symbols. Right, but I have the feeling this patch is the wrong way to go, but I need more information. > The set of symbols that is being used is normally valid per staff. It > is just in rare cases that you would want to change this set in > mid-staff, with the exception of switching between "Free Bass" and > "Standard Bass" symbols which can be interchanged on one hand. > >> As far as I can see, there are 2 settings: >> >> - the type of accordion (eg defaultStdBassV), which typically span >> multiple notes, or even the entire piece? > > There are separate symbol sets for left and right hand, and that of the > left hand may be interchanged in mid-stream. > >> - the register of a note. Is that specific for one note or for >> multiple notes? > > Multiple notes. If both are stateful properties (ie. span multiple notes) of the music, like key signatures, they should be context properties, to be modified using \set accordionType = "StdVII" \set accordionRegister = "22x7whatever" When are there symbols to be printed? In case of a change of either property, manual forcing, or both? In any event, the correct approach would be write an engraver, which unfortunately cannot currently be done in Scheme (it would be a nice project to write bindings to enable though). The engraver creates a new grob (AccordionRegister ?) carrying a markup. The markup should be created by calling out to a Scheme function which would look at the accordionType and accordionRegister. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
What's the deal with the module system?
Hi, in the course of seeing how much code can be shared between define-builtin-markup-command and define-markup-command, the main difference appears to be scope. That's not much of a problem: just call the defining command, then (export ...) the result. Except that lilypond jiggles with symbols and procedure properties and similar in some functions. I quote: %%;; to be define later, in a closure #(define-public toplevel-module-define-public! #f) #(define-public toplevel-module-ref #f) #(let ((toplevel-module (current-module))) (set! toplevel-module-define-public! (lambda (symbol value) (module-define! toplevel-module symbol value) (module-export! toplevel-module (list symbol (set! toplevel-module-ref (lambda (symbol) (module-ref toplevel-module symbol #(defmacro-public define-public-toplevel (first-arg . rest) "Define a public variable or function in the toplevel module: (define-public-toplevel variable-name value) or: (define-public-toplevel (function-name . args) ..body..)" (if (symbol? first-arg) ;; (define-public-toplevel symbol value) (let ((symbol first-arg) (value (car rest))) `(toplevel-module-define-public! ',symbol ,value)) ;; (define-public-toplevel (function-name . args) . body) (let ((function-name (car first-arg)) (arg-list (cdr first-arg)) (body rest)) `(toplevel-module-define-public! ',function-name (let ((proc (lambda ,arg-list ,@body))) (set-procedure-property! proc 'name ',function-name) proc) Now the use of these intricate macros bypassing the (well-documented) guile module system pervades the whole builtin/not-builtin system. Why does one need a different, manually implemented module system? Well, the above code (and the quoted sparingly used comments) are the whole design and implementation document I can find. At least the code does not contain references to anything. Grep for "toplevel" in the Lilypond tree makes clear that it is a popular term. It is used in the syntax, for organizing the info hierarchy, for book structures, to indicate the top parsing level of a .ly input file. There is even mentioning of "toplevel scope" for *.ly files, but the relation to the guile module system, if any, is not further mentioned. There are things like a "toplevel music handler", but this toplevel appears to be rather that of a dynamic execution hierarchy than of namespaces. So what's the deal with the builtin definitions, and why can't one just use them followed by export for defining public functions? Why is an undocumented private module system employed? What problems does it solve that makes it worth scaring prospective contributors away, even assuming that it _would_ be documented somewhere somewhat obvious eventually? I am trying to get into Lilypond, and it is an exercise of frustration fighting a lot of badly documented code that _affects_ my ability to code without obvious benefits or relation to the task that I actually want to be doing. Being cleverer than the platform one is working on is a recipe for unmaintainability. It will also get in the way of using Scheme compilers, debuggers and similar tools. So where do I get to know about the design goals and benefits? Thanks, -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
On Mon, Nov 23, 2009 at 11:56 AM, David Kastrup wrote:
>
> Hi,
>
> in the course of seeing how much code can be shared between
> define-builtin-markup-command and define-markup-command, the main
> difference appears to be scope.
>
> That's not much of a problem: just call the defining command, then
> (export ...) the result. Except that lilypond jiggles with symbols and
> procedure properties and similar in some functions. I quote:
>
The Lilypond language has a concept of scoping, ie you can do
foo = 1
#(begin
(display (+ foo 2)))
with \paper, \midi and \header being nested scope inside the .ly
file-level scope. "foo = 1" is translated in to a scheme variable
definition.
This implemented using modules, with each scope being an anonymous
module that imports its enclosing scope's module.
The reason to put some functions ("builtin") outside the .ly level, is
that in case of
lilypond a.ly b.ly
we want to reuse the built-in definitions, without changes effected in
a.ly leaking into the processing of b.ly
> Being cleverer than the platform one is working on is a recipe for
> unmaintainability. It will also get in the way of using Scheme
> compilers, debuggers and similar tools.
>
> So where do I get to know about the design goals and benefits?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code review/discussion time again.
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 4:02 AM, David Kastrup wrote:
I have no idea what I am doing here. In particular not with the
\override, and the set-object-property!. Can somebody explain to me
just what data structures I happen to manipulate, and how a user is
actually _supposed_ to be mangling them?
>>>
>>> Perhaps you could explain us how accordion notation works; that will
>>> make it easier to give advice on how to best achieve your targets.
>>
>> In the context of _this_ patch, we are just placing register symbols.
>
> Right, but I have the feeling this patch is the wrong way to go, but I
> need more information.
Well, currently it is not as much a patch than a snippet of user-level
code, neither fit nor intended for inclusion in the Lilypond source
tree. There are quite a few user-level code snippets in the LSR that
certainly feel "the wrong way to go" not just for me.
At the current point of time, this code is the result of beating
Lilypond with a crowbar until the behavior has mostly the scoping I
need.
I was rather hoping for "are you crazy, you have to do this sort of
thing in _this_ way" answers. Because just asking the questions without
this addition of badly written code did not suffice for moving me
forward. I am several months into this "project" with just ugly hacks
to show. So I show them.
>>> - the type of accordion (eg defaultStdBassV), which typically span
>>> multiple notes, or even the entire piece?
>>
>> There are separate symbol sets for left and right hand, and that of the
>> left hand may be interchanged in mid-stream.
>>
>>> - the register of a note. Is that specific for one note or for
>>> multiple notes?
>>
>> Multiple notes.
>
> If both are stateful properties (ie. span multiple notes) of the
> music, like key signatures, they should be context properties, to be
> modified using
>
> \set accordionType = "StdVII"
> \set accordionRegister = "22x7whatever"
Probably.
> When are there symbols to be printed? In case of a change of either
> property, manual forcing, or both?
Change. There is also a case for pure markup changes. It is common to
give more than one registration, something like
\registersymbol "101" \bracket { \registersymbol "11" }
to indicate an alternative register if your actual instrument does not
have the required register.
> In any event, the correct approach would be write an engraver, which
> unfortunately cannot currently be done in Scheme (it would be a nice
> project to write bindings to enable though).
Likely something which I'll end up doing eventually. I don't like
problems which require recompilation, or even changing the engine in any
manner, even if it is just copying and changing one Scheme file and
putting the changed file into your personal load-path.
> The engraver creates a new grob (AccordionRegister ?) carrying a
> markup. The markup should be created by calling out to a Scheme
> function which would look at the accordionType and accordionRegister.
Hm. I'll have to take more of a look at things.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.8 now?
On Sun, Nov 22, 2009 at 9:19 PM, Neil Puttock wrote: > 2009/11/22 Graham Percival : >> Also, two very-near collisions between rests and >> beams are fixed. There's a bunch of text with a "cells" numbers >> that's changed. I don't know what that's about. > > I'm not quite sure what you mean with the rest/beam collisions though > (can't see any improvements here); is it rest-collision-beam-note.ly > which has changed? Now that 2.13.8 is uploaded: http://lilypond.org/test/v2.13.8-1/compare-v2.13.7-1/index.html dot-rest-beam-trigger.ly rest-collision-beam-note.ly Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 11:56 AM, David Kastrup wrote:
>>
>> Hi,
>>
>> in the course of seeing how much code can be shared between
>> define-builtin-markup-command and define-markup-command, the main
>> difference appears to be scope.
>>
>> That's not much of a problem: just call the defining command, then
>> (export ...) the result. Except that lilypond jiggles with symbols and
>> procedure properties and similar in some functions. I quote:
>
> The Lilypond language has a concept of scoping, ie you can do
>
>
> foo = 1
>
> #(begin
> (display (+ foo 2)))
>
> with \paper, \midi and \header being nested scope inside the .ly
> file-level scope. "foo = 1" is translated in to a scheme variable
> definition.
>
> This implemented using modules, with each scope being an anonymous
> module that imports its enclosing scope's module.
>
> The reason to put some functions ("builtin") outside the .ly level, is
> that in case of
>
> lilypond a.ly b.ly
>
> we want to reuse the built-in definitions, without changes effected in
> a.ly leaking into the processing of b.ly
Wouldn't just putting the built-in definition at public scope accomplish
that?
define-builtin-markup-command and define-markup-command have a lot of
code duplication. Now this is sort of a special command because there
will rarely if ever be any need to use define-markup-command in Lilypond
itself (creating a private markup).
Assuming that we do need both for some defining word, wouldn't something
like
(define-toplevel-alias
(define-builtin-markup-command arg1 arg2 . rest)
`(define-markup-command ,arg1 ,arg2 . ,rest)
:exports `(,arg1 ,(symbol->keyword arg1) ...))
or the respective equivalent code (which is straightforward enough
except that something like the above contraption could autogenerate the
doc string) be much better than copy&paste of the definition and
replacing every defining word with define-toplevel* or similar?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote: >> lilypond a.ly b.ly >> >> we want to reuse the built-in definitions, without changes effected in >> a.ly leaking into the processing of b.ly > > Wouldn't just putting the built-in definition at public scope accomplish > that? I don't know. Why don't you try it, and send us a patch if it passes the regression tests? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Han-Wen Nienhuys writes: > On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote: > >>> lilypond a.ly b.ly >>> >>> we want to reuse the built-in definitions, without changes effected >>> in a.ly leaking into the processing of b.ly >> >> Wouldn't just putting the built-in definition at public scope >> accomplish that? > > I don't know. Why don't you try it, and send us a patch if it passes > the regression tests? That would not be my first thought when meddling with code I know nothing about, and where I assume that somebody had created it because of some inherent necessity. And not every dead end needs to be entered repeatedly. It is a waste of time. But I think that guile's module system changed in the last few years, so it is actually possible that some necessities went away since the code was written. I'll probably take a look. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
out-www not ignored
Having just installed ubuntu, a new git repo and compiled Lily and the docs for the first time I see that all the entries in out-www appear as unstaged changes in git. Should not out-www be included in .gitignore or am I doing something wrong here? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: out-www not ignored
Le lundi 23 novembre 2009 à 18:03 +, Trevor Daniels a écrit : > Having just installed ubuntu, a new git repo and compiled Lily and > the docs for the first time I see that all the entries in out-www > appear as unstaged changes in git. > > Should not out-www be included in .gitignore or am I doing something > wrong here? I'm surprised that out-www isn't already in .gitignore, and that files in out-www dirs don't appear as untracked in my local Git repositories. What about replacing all entries starting with out in .gitignore with out out-* ? Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve doc on markup command writing (issue157133)
Le 23 nov. 2009 à 03:23, Carl Sorensen a écrit :
>
> I think that what Graham meant was you should use @var{props} instead of
> `props'.
Yes, I've finally understood what Graham meant, but after I've sent that
stupid message :)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Le 23 nov. 2009 à 01:03, David Kastrup a écrit : > The specification of category and properties makes the *-builtin-* > variants diverge syntactically from the user specified markup. Moving > those specifications into keyword arguments makes the builtin defining > macros upwards compatible with the user specified ones. Could you publish your patches on retvield? It's just a matter of git-cl upload from your branch. I think somewhere you missed a change from define-builtin-markup-list-command to define-markup-list-command. It would be easier to read and comment on retvield, together with other modified files. It also seems that ly/markup-init.ly is impacted, but I don't see the patch. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Nicolas Sceaux writes: > Le 23 nov. 2009 à 01:03, David Kastrup a écrit : > >> The specification of category and properties makes the *-builtin-* >> variants diverge syntactically from the user specified markup. Moving >> those specifications into keyword arguments makes the builtin defining >> macros upwards compatible with the user specified ones. > > Could you publish your patches on retvield? > It's just a matter of git-cl upload from your branch. Nope. The contributor's guide says: Then, add the git-cl directory to your PATH, or create a symbolic link to the git-cl and upload.py in one of your PATH directories (like usr/bin). git-cl will is then configured by git-cl config and answering the questions that are asked. There is no clue just _how_ one should answer the questions or what they mean. Let's see where we go: $ git-cl config Rietveld server (host[:port]) [codereview.appspot.com]: CC list: lilypond-devel@gnu.org Tree status URL: ViewVC URL: d...@lola:/usr/local/tmp/lilypond$ git-cl status Branches associated with reviews: master: None Current branch: no issue assigned. $ Does not look really convincing. d...@lola:/usr/local/tmp/lilypond$ git-cl rebase Can't locate SVN/Core.pm in @INC (@INC contains: /opt/git/share/perl/5.10.0 /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /us Really, that's not something that would appear to helpmy workflow. git-checkout -d mad-dak then piping the four postings through git-am should do the trick for reviewing. Feel free to post the thing to Rietveld yourself if you feel like it, but at the moment I really can't be bothered fighting some none-working tools. > I think somewhere you missed a change from > define-builtin-markup-list-command to define-markup-list-command. I did not change any define-builtin-markup-list-command to define-markup-list-command in this patch series. > It would be easier to read and comment on retvield, together with > other modified files. Feel free to put it there. > It also seems that ly/markup-init.ly is impacted, but I don't see the > patch. It isn't impacted. The patch series gives the *-builtin-* commands a different syntax that is upwards-compatible to the user counterparts. It does not change the user counterparts at all. The first two patches in the series are cleanups and would work independently of the rest of the patch series. I had posted them previously on the list and they have basically been ignored. They are in the patch series because they touch code _overlapping_ with patch 4, and it makes no sense in not doing the cleanup. Patch 3 actually changes changes the *-builtin-* syntax and consequently renders Lilypond inoperative when applied alone. That is the core of the patch series, and it is much better reviewable when kept separate from patch 4. Patch 4 changes all the callers to the new *-builtin-* syntax. This is just boring legwork without intellectual value, but a lot of it. This patch series is _only_ concerned with *-builtin-*. It does a complete job on that and nothing else. Eventually the user-level counterparts should accept #:properties and #:category as well (likely ignoring the latter), but that's a different topic. And I am still looking through the module concepts for that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Le 23 nov. 2009 à 22:05, David Kastrup a écrit : > > There is no clue just _how_ one should answer the questions or what they > mean. Oh please... If you had read the git-cl README, which gives the complete sequence, instead of writing (one more time) a lengthy useless mail, then the patch would already have been on retvield. Please show an ounce of good will sometimes, it does not hurt. >> I think somewhere you missed a change from >> define-builtin-markup-list-command to define-markup-list-command. > > I did not change any define-builtin-markup-list-command to > define-markup-list-command in this patch series. This is precisely what I meant. If you change define-builtin-markup-command into define-markup-command then also change define-builtin-markup-list-command into define-markup-list-command Just a matter of consistency. I didn't read the rest of your message, I got bored meantime. Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Le 23 nov. 2009 à 19:03, David Kastrup a écrit :
> Han-Wen Nienhuys writes:
>
>> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote:
>>
lilypond a.ly b.ly
we want to reuse the built-in definitions, without changes effected
in a.ly leaking into the processing of b.ly
>>>
>>> Wouldn't just putting the built-in definition at public scope
>>> accomplish that?
>>
>> I don't know. Why don't you try it, and send us a patch if it passes
>> the regression tests?
>
> That would not be my first thought when meddling with code I know
> nothing about, and where I assume that somebody had created it because
> of some inherent necessity. And not every dead end needs to be entered
> repeatedly. It is a waste of time.
A waste of time for you.
I think it's a waste of time *for me* to explain you things when I read
a subject line like "WTF with..." and no thank you in the end.
As you can easily guess, there are three possible reasons why I did
something complicated in ly/markup-init.ly and a bit a code duplication
from scm/markup.scm:
1) I like to make me some bad
2) There's no easier way
3) There is an easy way, but I didn't see it.
The answer is between 2 and 3, and hopefully you will prove that it
is 3. Otherwise you will at least understand why I insisted that
define-builtin-markup-command and define-markup-command are not exactly
the same thing (with respect to modules).
The reason why I've used this define-public-toplevel macro has something
to do with the modules being not the same when a .ly file is included into
another. So that hack was a way to define all markup commands in the same
module. I didn't find at that time an easier way to define a function in
a given module (not the current one) than to define this macro.
BTW, the guile module is not bypassed: module-define!, module-export!
and module-ref are all guile module primitives.
When you modify that code, try something like:
file1.ly:
\include "file2.ly"
\markup \foo
file2.ly:
#(define-markup-command (foo ...) ...)
and compile file1.ly
Also try to compile file3.ly:
file3.ly:
myInclude =
#(define-music-function (parser location file) (string?)
#{ \include $file #}
(make-music 'void #t))
\myInclude "file2.ly"
\markup \foo
Please send *complete* patches for review at retvield.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve doc on markup command writing (issue157133)
On Mon, Nov 23, 2009 at 3:23 AM, Carl Sorensen wrote:
> The way we indicate a variable name in the documentation is not with CAPS or
> with 'single quotes' but with @var{macro}.
That (unfortunately) doesn't seem to apply in music-functions.scm:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/music-functions.scm;hb=HEAD#l695
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Nicolas Sceaux writes: >>> I think somewhere you missed a change from >>> define-builtin-markup-list-command to define-markup-list-command. >> >> I did not change any define-builtin-markup-list-command to >> define-markup-list-command in this patch series. > > This is precisely what I meant. If you change > define-builtin-markup-command into define-markup-command I didn't. > then also change > define-builtin-markup-list-command into define-markup-list-command I didn't. > Just a matter of consistency. Indeed. > I didn't read the rest of your message, I got bored meantime. If you are not interested in the answers, don't ask questions. Han-Wen already posted "LGTM", and the patches include patches to the documentation of the changed macros. I don't think that I can contribute much more to your amusement. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
And this year's "Good Will Generator" Award goes to… I don't think that I can contribute much more to your amusement. Wow. I've [fortunately] never witnessed such mindless negative energy on a mailing list to which I've been subscribed. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve doc on markup command writing (issue157133)
On 11/23/09 2:41 PM, "Valentin Villenave" wrote:
> On Mon, Nov 23, 2009 at 3:23 AM, Carl Sorensen wrote:
>> The way we indicate a variable name in the documentation is not with CAPS or
>> with 'single quotes' but with @var{macro}.
>
> That (unfortunately) doesn't seem to apply in music-functions.scm:
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/music-function
> s.scm;hb=HEAD#l695
That's right. This was a change that happened some time ago, and code
predating the change has never been fixed.
I guess that's a job for a Frog.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
On 11/23/09 2:05 PM, "David Kastrup" wrote: > Nicolas Sceaux writes: > >> Le 23 nov. 2009 à 01:03, David Kastrup a écrit : >> >>> The specification of category and properties makes the *-builtin-* >>> variants diverge syntactically from the user specified markup. Moving >>> those specifications into keyword arguments makes the builtin defining >>> macros upwards compatible with the user specified ones. >> >> Could you publish your patches on retvield? >> It's just a matter of git-cl upload from your branch. > > Nope. The contributor's guide says: > >Then, add the git-cl directory to your PATH, or create a symbolic > link to the git-cl and upload.py in one of your PATH directories (like > usr/bin). git-cl will is then configured by > > git-cl config > > and answering the questions that are asked. > > There is no clue just _how_ one should answer the questions or what they > mean. Let's see where we go: > > $ git-cl config > Rietveld server (host[:port]) [codereview.appspot.com]: > CC list: lilypond-devel@gnu.org > Tree status URL: > ViewVC URL: > > d...@lola:/usr/local/tmp/lilypond$ git-cl status > Branches associated with reviews: > master: None > > Current branch: no issue assigned. Since you haven't uploaded a patch, you don't have any reviews assigned yet. Did you try git-cl upload? > > $ > > Does not look really convincing. > > > d...@lola:/usr/local/tmp/lilypond$ git-cl rebase > Can't locate SVN/Core.pm in @INC (@INC contains: /opt/git/share/perl/5.10.0 > /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 > /usr/lib/perl5 /us > > > Really, that's not something that would appear to helpmy workflow. > > > git-checkout -d mad-dak > > then piping the four postings through git-am should do the trick for > reviewing. Feel free to post the thing to Rietveld yourself if you feel > like it, but at the moment I really can't be bothered fighting some > none-working tools. > >> I think somewhere you missed a change from >> define-builtin-markup-list-command to define-markup-list-command. > > I did not change any define-builtin-markup-list-command to > define-markup-list-command in this patch series. > >> It would be easier to read and comment on retvield, together with >> other modified files. > > Feel free to put it there. > >> It also seems that ly/markup-init.ly is impacted, but I don't see the >> patch. > > It isn't impacted. The patch series gives the *-builtin-* commands a > different syntax that is upwards-compatible to the user counterparts. > It does not change the user counterparts at all. > > The first two patches in the series are cleanups and would work > independently of the rest of the patch series. I had posted them > previously on the list and they have basically been ignored. They are > in the patch series because they touch code _overlapping_ with patch 4, > and it makes no sense in not doing the cleanup. > > Patch 3 actually changes changes the *-builtin-* syntax and consequently > renders Lilypond inoperative when applied alone. That is the core of > the patch series, and it is much better reviewable when kept separate > from patch 4. Not if you're using Reitveld with side-by-side diffs. The two patches together are very nicely reviewable. IIUC, our policy is that *every* patch that is applied should result in a buildable LilyPond. If not, it's a bad patch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Kieren MacMillan writes: > And this year's "Good Will Generator" Award goes to… > >> I don't think that I can contribute much more to your amusement. > > Wow. > I've [fortunately] never witnessed such mindless negative energy on a > mailing list to which I've been subscribed. It was in direct reply to >>> I didn't read the rest of your message, I got bored meantime. as response to my mail answering design questions which, by the way, were already explained in the code documentation contained in the patches, as well as the commit messages. So while indeed there was no additional information for dissemination, on request of Nicolas, I spelled everything out again and bored him. It is apparent that I am not up to the standards required for making contributions to Lilypond code. Since actually getting things to run takes one tenth of the effort and aggravation than getting them both into acceptable shape as well as accepted, it is a clear waste of my resources to discuss patches or ask for information. Ultimately, it makes more sense to fight code than people. I might post patches here (rather than doing it in the apparently only acceptable manner with tools that don't work for me and which I have not the time for to fight as well), but I don't see myself up to defending them. And there is no point in doing so anyway: the last thing Lilypond needs is more code that can't be understood just by looking at the code and its documentation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/4] scm/define-markup-commands.scm: remove some unnecessary lookups
2009/11/23 David Kastrup : > Reinhold Kainhofer writes: > >> Am Montag, 23. November 2009 01:03:10 schrieb David Kastrup: >>> --- >>> scm/define-markup-commands.scm | 3 +-- >>> 1 files changed, 1 insertions(+), 2 deletions(-) >>> >>> This patch series makes the syntax of builtin markup >>> commands upwards compatible with the user level ones. >> >> Wrong description for what this particular patch does, > > Which is why it is not in the patch's commit message but only in the > non-committed part of the mail body, and talks about "patch series" (of > which this is the first patch) rather than "patch". I was just trying > to be helpful. > >> but apart from that, it totally makes sense to me to commit it. > > Thanks. LGTM too, and applied. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 2/4] scm/harp-pedals.scm: Fold make-harp-pedal into \harp-pedal markup.
2009/11/23 Reinhold Kainhofer : > As the author of the harp pedals code, I'm fine with that change (provided the > regtest still works, which I haven't checked). The regtests are fine here, so I've pushed to master. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Nicolas Sceaux writes:
> Le 23 nov. 2009 à 19:03, David Kastrup a écrit :
>
>> Han-Wen Nienhuys writes:
>>
>>> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote:
>>>
> lilypond a.ly b.ly
>
> we want to reuse the built-in definitions, without changes effected
> in a.ly leaking into the processing of b.ly
Wouldn't just putting the built-in definition at public scope
accomplish that?
>>>
>>> I don't know. Why don't you try it, and send us a patch if it passes
>>> the regression tests?
>>
>> That would not be my first thought when meddling with code I know
>> nothing about, and where I assume that somebody had created it because
>> of some inherent necessity. And not every dead end needs to be entered
>> repeatedly. It is a waste of time.
>
> A waste of time for you.
And everybody else trying to work with this code.
> I think it's a waste of time *for me* to explain you things when I
> read a subject line like "WTF with..." and no thank you in the end.
I think you are well aware that your personal dislike of me, which
certainly is quite justified, skews your perception and your
representation. "What is the deal with" is an open question, certainly
not the same as "WTF with". And this request which you complain about
here _did_ end with "Thanks," as I bothered to check right now.
There is really no need to invent or exaggerate things in order to
convince others of my obnoxiousness: I think it is apparent enough
without external help.
> The reason why I've used this define-public-toplevel macro has something
> to do with the modules being not the same when a .ly file is included into
> another. So that hack was a way to define all markup commands in the same
> module. I didn't find at that time an easier way to define a function in
> a given module (not the current one) than to define this macro.
>
> BTW, the guile module is not bypassed: module-define!, module-export!
> and module-ref are all guile module primitives.
>
> When you modify that code, try something like:
>
> file1.ly:
> \include "file2.ly"
> \markup \foo
>
> file2.ly:
>#(define-markup-command (foo ...) ...)
>
> and compile file1.ly
>
> Also try to compile file3.ly:
>
> file3.ly:
> myInclude =
> #(define-music-function (parser location file) (string?)
> #{ \include $file #}
> (make-music 'void #t))
>
> \myInclude "file2.ly"
> \markup \foo
>
> Please send *complete* patches for review at retvield.
Thank you: this information about the intent and mechanism of this code
is certainly helpful. I recommend that you place something like this
along with the code itself.
I don't see myself fighting Subversion and Rietveld myself in the near
future, but am confident that somebody with a better control of the
required tools will pick up patches posted here that are well enough
documented and of enough interest.
I certainly will try to see whether I can figure out a way to use the
module system in a manner requiring less code duplication and separate
defining commands.
Thanks for the test examples and the explanation.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
>> I don't think that I can contribute much more to your amusement. > > Wow. > I've [fortunately] never witnessed such mindless negative energy on > a mailing list to which I've been subscribed. Guys, cool down. I think everyone of you is interested to improve lilypond, perhaps it helps if all of you are saying o a few times. If this doesn't help, say ommm again until it helps. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Werner LEMBERG writes: >>> I don't think that I can contribute much more to your amusement. >> >> Wow. >> I've [fortunately] never witnessed such mindless negative energy on >> a mailing list to which I've been subscribed. > > Guys, cool down. I think everyone of you is interested to improve > lilypond, That's a rather daring assumption. One would expect working, documented code to be posted if that was the case. > perhaps it helps if all of you are saying o a few times. If > this doesn't help, say ommm again until it helps. I think I'll try reading the guile manual instead. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help wanted page
Graham Percival wrote: On Sun, Nov 22, 2009 at 03:19:00PM +, Ian Hulin wrote: Graham Percival wrote: I've made a first draft of the "help us" page: http://kainhofer.com/~lilypond/Documentation/web/help-us.html "To get the source code, see Starting with git." I've got problems with this here and in the CG. The reason is that You're making a lot of assumptions about potential contributers' experience There's only so much we can explain on this page -- and, for that matter, the CG. I've revamped the "help us" page (should be visible on kainhofer tomorrow), and added a bit of general info to the CG about doc source files, output formats, etc. On web page 'Many users ask “I can’t program; how can I help?”' - this needs to be as prominent as the 'No source, no programming' beneath it - can you bold it? 'Mailist support: we have many users asking for him.' Who's he? Do you mean something like 'Mailing list support: you can help by answering queries and requests for support from Lilypond users'? At this point, I think we've reached a point of diminishing returns... if anybody is seriously interested in doc work and doesn't understand these points, a few sentences in an email about his specific concerns will clear it up. If you'd like to work more about this point in the CG, I of course have no objections. It's next on my list. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Carl Sorensen writes: > On 11/23/09 2:05 PM, "David Kastrup" wrote: > >> Nicolas Sceaux writes: >> >>> Le 23 nov. 2009 à 01:03, David Kastrup a écrit : >>> The specification of category and properties makes the *-builtin-* variants diverge syntactically from the user specified markup. Moving those specifications into keyword arguments makes the builtin defining macros upwards compatible with the user specified ones. >>> >>> Could you publish your patches on retvield? >>> It's just a matter of git-cl upload from your branch. >> >> Nope. The contributor's guide says: >> >>Then, add the git-cl directory to your PATH, or create a symbolic >> link to the git-cl and upload.py in one of your PATH directories (like >> usr/bin). git-cl will is then configured by >> >> git-cl config >> >> and answering the questions that are asked. >> >> There is no clue just _how_ one should answer the questions or what they >> mean. Let's see where we go: >> >> $ git-cl config >> Rietveld server (host[:port]) [codereview.appspot.com]: >> CC list: lilypond-devel@gnu.org >> Tree status URL: >> ViewVC URL: >> >> d...@lola:/usr/local/tmp/lilypond$ git-cl status >> Branches associated with reviews: >> master: None >> >> Current branch: no issue assigned. > > Since you haven't uploaded a patch, you don't have any reviews assigned yet. > > Did you try git-cl upload? Interesting. After all the error messages I would not have expected it to do anything. >> Patch 3 actually changes changes the *-builtin-* syntax and consequently >> renders Lilypond inoperative when applied alone. That is the core of >> the patch series, and it is much better reviewable when kept separate >> from patch 4. > > Not if you're using Reitveld with side-by-side diffs. The two patches > together are very nicely reviewable. > > IIUC, our policy is that *every* patch that is applied should result > in a buildable LilyPond. If not, it's a bad patch. I don't consider this policy prudent in the particular situation "API change implemented with little code" "Wagonloads of changes in API users" because everything within part 1 requires an intensive review, while the much larger part 2 can be skimmed at a much faster pace. It would appear that git-cl contrib call has taken both commits together. Which is a good thing since mixing them together myself would go against my taste. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help wanted page
On Mon, Nov 23, 2009 at 11:55:59PM +, Ian Hulin wrote: > Graham Percival wrote: >> On Sun, Nov 22, 2009 at 03:19:00PM +, Ian Hulin wrote: >> I've revamped the "help us" page (should be visible on kainhofer >> tomorrow), and added a bit of general info to the CG about doc >> source files, output formats, etc. Huh, apparently the page wasn't rebuilt. The version on the official website is newer now: http://lilypond.org/doc/v2.13/Documentation/web/help-us I'm happy enough with this version... I mean, it's on par with the rest of the site. Suggestions are still appreciated, but I don't think it's worth having daily updates of the page. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
On Mon, Nov 23, 2009 at 7:45 PM, David Kastrup wrote: > Han-Wen already posted "LGTM", and the patches include patches to the > documentation of the changed macros. > > I don't think that I can contribute much more to your amusement. Nicolas wrote most of the Scheme code, and he has my full confidence. His word on patches of the scheme code is final. If you disagree with this policy, I suggest you start a fork of LilyPond where you can change things at will. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Han-Wen Nienhuys writes: > On Mon, Nov 23, 2009 at 7:45 PM, David Kastrup wrote: >> Han-Wen already posted "LGTM", and the patches include patches to the >> documentation of the changed macros. >> >> I don't think that I can contribute much more to your amusement. > > Nicolas wrote most of the Scheme code, and he has my full confidence. > His word on patches of the scheme code is final. Well, he declared my explanation of this patch too boring already, so I guess that means it's dead. Considering the amount of time and energy wasted on defending rather than writing it, probably best for all involved. This would not be sustainable for serious work, anyway. > If you disagree with this policy, I suggest you start a fork of > LilyPond where you can change things at will. This is free software. I don't need to start a fork for making my version of Lilypond do what I need and/or understand. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
On Tue, 2009-11-24 at 01:03 +0100, David Kastrup wrote: > Carl Sorensen writes: > > IIUC, our policy is that *every* patch that is applied should result > > in a buildable LilyPond. If not, it's a bad patch. > > I don't consider this policy prudent in the particular situation "API > change implemented with little code" "Wagonloads of changes in API > users" because everything within part 1 requires an intensive review, > while the much larger part 2 can be skimmed at a much faster pace. On the other hand, patches which break lilypond make git-bisect much less fun. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords
Joe Neeman writes: > On Tue, 2009-11-24 at 01:03 +0100, David Kastrup wrote: >> Carl Sorensen writes: >> > IIUC, our policy is that *every* patch that is applied should result >> > in a buildable LilyPond. If not, it's a bad patch. >> >> I don't consider this policy prudent in the particular situation "API >> change implemented with little code" "Wagonloads of changes in API >> users" because everything within part 1 requires an intensive review, >> while the much larger part 2 can be skimmed at a much faster pace. > > On the other hand, patches which break lilypond make git-bisect much > less fun. Uh yes. Good point. You got me there. It appears that the Cc functionality for git-cl was not working, so just for the record: http://codereview.appspot.com/160048>. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
