Re: enhancement request - new header field: movement
2013/9/25 Jan-Peter Voigt jp.vo...@gmx.de: Hi David, lilypond has a header field piece, which is meant for movement names. To have this field centered - default is left above the score - one has to modify scoreTitleMarkup in paper. Perhaps other markups would be nice. (a markup is a template by itself, because it gets its title/coposer/etc names via \getProperty #'header:...) You mean it would be nice to add a few predefined header styles to choose from? I agree, and i have something that i could share, but i'd like to first sort out our contribution policies (the github discussion). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: enhancement request - new header field: movement
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/9/25 Jan-Peter Voigt jp.vo...@gmx.de: Hi David, lilypond has a header field piece, which is meant for movement names. To have this field centered - default is left above the score - one has to modify scoreTitleMarkup in paper. Perhaps other markups would be nice. (a markup is a template by itself, because it gets its title/coposer/etc names via \getProperty #'header:...) You mean it would be nice to add a few predefined header styles to choose from? I agree, and i have something that i could share, but i'd like to first sort out our contribution policies (the github discussion). Well, there is movement in there, where we'll explore the technical tools that Savannah might provide us with and see where we might want to take our infrastructure based on that. I suppose it's more efficient to stall discussion until we actually know which options are feasible using which hosters as I think it desirable to stay close with Savannah where feasible. LilyPond is not a _core_ GNU project like GCC or Emacs where copyright assignments are required for every contribution in order to provide a court-strong defensible position in the hand of the FSF regarding its copyright. If it were, pressing the necessity for a strong defensible toolchain and hosting in the hand of the FSF would be easier. But still, I think that we can make a reasonably good case for Savannah to consider trying new things if that proves desirable. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: enhancement request - new header field: movement
Hi Janek, Am 26.09.2013 09:53, schrieb Janek Warchoł: You mean it would be nice to add a few predefined header styles to choose from? I agree, and i have something that i could share, me too ;) but i'd like to first sort out our contribution policies (the github discussion). yes ... I do understand the objections against github. But its still usable to show, what one'd like to share ;) IMO your and Urs affords in bringing in some kind of SSRfL (Schem Snippet Repo for Lilypond) brought up an important discussion. I read most of the discussion and hope it will end up in a more intuitive (or whatever ;) ) toolchain for contributors. Best, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: enhancement request - new header field: movement
Hi David, Am 26.09.2013 10:08, schrieb David Kastrup: Well, there is movement in there, where we'll explore the technical tools that Savannah might provide us with and see where we might want to take our infrastructure based on that. I suppose it's more efficient to stall discussion until we actually know which options are feasible using which hosters as I think it desirable to stay close with Savannah where feasible. The important thing is: there is movement in the discussion and I really appreciate, that there is a discussion! But still, I think that we can make a reasonably good case for Savannah to consider trying new things if that proves desirable. +1 Best, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
improving our contributing tools and workflow
Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 10:48 AM Subject: improving our contributing tools and workflow Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/26 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł janek.lilyp...@gmail.com after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 11:13 AM Subject: Re: improving our contributing tools and workflow Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. I will participate as usual, although noting that my summer vacation ends this weekend. I was simply reiterating something that Graham said to me on a number of occasions - don't assume that the work you do will be accepted - it's always possible that anything done on a collaborative project won't be. Patches are criticised, changed and occasionally junked, and the same can apply to proposals for changes in tools and processes - so don't become too committed and expend more work than you can afford to lose. Ever. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/9/26 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. There is a joke about an experimental physicist approaching the college dean for funding a collider. The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Joke aside: if you are going to do serious programming or infrastructure work, your most important tool _will_ be the wastebasket. You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. If that sounds very discouraging to you, don't study mathematics. And actually, I'd not recommend studying philosophy either, if just for the sake of philosophy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stop \lyricmode { \skip 1.*3 } from failing. (issue 13256053)
2013/9/25 d...@gnu.org:
On 2013/09/24 07:44:44, janek wrote:
Hmm. From my point of view, this deserves some comment
(but i don't insist).
Well, multiple matching regexps are messy and might call for an
appropriate comment. But the whole point of the change is not to have
multiple matching regexps any more.
The original commit message of the commit that failed to do the job was:
commit 38a4081efa4a8ee2f5da780ca0ed2991627afc46
Author: David Kastrup d...@gnu.org
Date: Sun Sep 30 02:21:00 2012 +0200
Issue 2869: Regularize lyrics lexer mode
That makes lyrics mode rather similar to markup mode regarding how
words are formed. {} are never considered part of words unless
enclosed in quotes. Unquoted words do not contain whitespace,
braces,
quotes, backslashes, numbers or Scheme expressions. In addition,
they
cannot start with * . = and | since that would mess with duration,
assignment and barcheck syntax. This removes some remaining
TeX-oriented cruft in the lexer. The set of word-non-starters might
need revisiting, but at least the regtests seem to pass.
The text that is relevant here is In addition, [unquoted words] cannot
start with * . = and | since that would mess with duration, assignment
and barcheck syntax.
After the fix, the pattern _explicitly_ (rather than implicitly by
pattern order which did not work) states that unquoted words cannot
start with * . = and |. The pattern is now a literal rendition of the
description.
For me the regex itself required a few moments of thinking to
understand.
The problem is that you want a comment describing the problems with
code/patterns that is no longer there. I don't think that's helpful. A
comment is called for when you use a trick to avoid a problem. But in
this case, the problem was avoided by stopping to use a trick and
instead being boringly explicit in the pattern.
It's quite redundant now to state this pattern won't match something
starting with * . = or | since the pattern explicitly excludes those
characters in its first position. My first attempt was to give the
first single-char pattern priority back by using
[*.=]/.*
(a trailing context which did not actually work because of technical
restrictions). That would both have been fragile _and_ would have
called for a comment in order to explain its purpose. But the purpose
of a pattern
[^*.=| ...
is not to match * . = | in the first position of the pattern. That's
basic. Comments can't hope to explain everything that's basic. They
should tell the story that the code doesn't tell, at least not on its
most direct surface level. And the code now tells the story in the most
blunt way that is possible. Of course we can add a comment of the we
could do this in a trickier way that does not actually work kind, but
that's not helpful at all.
It does not belong in the code. It might belong in the issue tracker,
perhaps in the commit message. Just as a record of what went wrong.
But the code, as it is written, does not offer a temptation of changing
it back to the buggy previous version. It was not more elegant or
obvious or clearer.
Uh, David, thanks for this explanation, but i'm afraid it was not
needed. If the code doesn't need a comment, just say so.
Now, speaking in general: i don't understand that when Mike submits a
patch, you often complain that it's not commented well enough, but
when I ask you for comments, you usually say this doesn't need any
comment.
Apparently both you and Mike consider what you write to be self-explanatory.
Maybe you are right that for an experienced developer Mike's code
isn't self-explanatory, and your code is. All i know is that for me
neither is self-explanatory. Of course, i'm not an experienced
programmer. But then, i've been working on LilyPond since 3 years
now, and that seems a pretty long time.
I am sorry that (apparently) you don't care whether i can understand
your patches easily or not. Also, from my perspective, it seems that
you consider yourself to be always right:
i think this deserves a regtest no, it doesn't
i think this deserves a comment no, it doesn't
I suppose that you're not doing this intentionally. But it drives me
crazy anyway.
Anyway, it seems that when i try to review your patches the first and
foremost result is that we both loose time, so i suppose that i should
stop reviewing your patches :-(
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: David Kastrup d...@gnu.org; Janek Warchoł janek.lilyp...@gmail.com Cc: Phil Holmes m...@philholmes.net; LilyPond Development Team lilypond-devel@gnu.org; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 12:51 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Janek Warchoł writes: Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? You may want to study - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). 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
Re: improving our contributing tools and workflow
Hi, to make things clear: i do not intend to attack anyone personally, or imply that anyone has bad will or malicious intentions. I only want to explain how the situation looks like from my point of view. 2013/9/26 Phil Holmes m...@philholmes.net: Janek wrote: 2013/9/26 Phil Holmes m...@philholmes.net: Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. Because your message sounds pessimistic. It sounds like you consider it likely that my attempt to do something good will fail. It sounds like you are not concerned with ensuring that this initiative suceeds and brings benefit to all, but rather you are thinking about the damage and problems it can bring. Thinking about problems isn't bad in itself, but if there's more focus on problems rather than benefits, things get discouraging. Actually, it seems to me that this happens really often in lilypond discussions, and it's probably the main reason why people get demotivated and discouraged. When someone comes up with an initiative, the reaction often _sounds like_ oh no, another enthusiastic guy. his ideas can cause us trouble and drain our precious resources. how can we save lilypond from him? instead of it's nice that you want to help. let's think how we can ensure that this will indeed be a benefit for lilypond. Probably the intentions of the people who reply are different, but that's how it sounds like to me. A few examples. Keep in mind that this is just my impression (the intentions of people who replied were probably different, but i cannot read their minds), and of course not all replies were like this: - lilypond blog: let's not put it on the website, because it will soon die and make us look silly. and it will introduce a security danger. - smufl: the reply to Urs' suggestion was mostly that'll cause us trouble and additional work, and we will be exploited by evil Steinberg - colorful make: the reaction was oh no, it will complicate our building process - snippets: the reaction was we don't need this, and it will be difficult, and we don't want to learn git. - github: changing our workflows will cause us trouble. I will participate as usual, although noting that my summer vacation ends this weekend. ok. I was simply reiterating something that Graham said to me on a number of occasions - don't assume that the work you do will be accepted - it's always possible that anything done on a collaborative project won't be. Patches are criticised, changed and occasionally junked, and the same can apply to proposals for changes in tools and processes - so don't become too committed and expend more work than you can afford to lose. Ever. Yes, i know. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stop \lyricmode { \skip 1.*3 } from failing. (issue 13256053)
On 2013/09/26 10:51:34, janek wrote: It does not belong in the code. It might belong in the issue tracker, perhaps in the commit message. Just as a record of what went wrong. But the code, as it is written, does not offer a temptation of changing it back to the buggy previous version. It was not more elegant or obvious or clearer. Uh, David, thanks for this explanation, but i'm afraid it was not needed. If the code doesn't need a comment, just say so. Now, speaking in general: i don't understand that when Mike submits a patch, you often complain that it's not commented well enough, but when I ask you for comments, you usually say this doesn't need any comment. Apparently both you and Mike consider what you write to be self-explanatory. git blame lily/lexer.ll|grep //\|/\*|wc -l 146 git blame lily/lexer.ll|grep //\|/\*|grep Kastrup|wc -l 120 git blame lily/lexer.ll|wc -l 1382 git blame lily/lexer.ll|grep Kastrup|wc -l 677 Are you sure that your characterization is fair? I'm responsible for less than half the lines in the lexer, but for more than 80% of the lines starting a comment in the lexer. It's a bit hard to do the same kind of check on a typical C++ file since superficially most lines are blamed on whoever ran the indenting tool last. lily/lexer.ll is not automatically indented, so it's somewhat more reliable. When my typical complaint with a commit from Mike focuses on the _number_ of comments, it's usually because there are about 10 lines of comments in 5000 lines of code (which seems indeed out of proportion based purely on the numbers, particularly when the whole _framework_ put together in those 5000 lines is non-trivial, opaque and mostly non-discoverable), and half of the comments are wrong. Now statistics can definitely be misleading as indeed a comment can be worthless and/or distracting and always is in danger of running out of sync with the code. So it needs to have value _separate_ from the code in order to be worth it. If it repeats the story spelled out in the code (and this is what you ask for here), it's useless. If it _summarizes_ a passage of code, it's already separately useful. If it puts code into context, it's _quite_ useful. Maybe you are right that for an experienced developer Mike's code isn't self-explanatory, and your code is. All i know is that for me neither is self-explanatory. So you say that a pattern written starting with [^.*|... does not tell you that it is supposed to match something not starting with a . * | and whatever else is listed here. That's a matter of not knowing Flex and/or regular expressions, not a matter of not being able to follow the logic of the code. That's like asking for a comment like x += 2; // increase x by 2 which is not helpful. Of course, i'm not an experienced programmer. But then, i've been working on LilyPond since 3 years now, and that seems a pretty long time. I am sorry that (apparently) you don't care whether i can understand your patches easily or not. You will understand a patch to the lexer _only_ if you know the language the lexer is written in. A code review that has to rely on _comments_ in order to understand every facet of the code (rather than larger contexts and/or its design) is basically useless as any divergence between code and comment can't be detected. Also, from my perspective, it seems that you consider yourself to be always right: i think this deserves a regtest no, it doesn't If you consider no, it doesn't as the same as a regtest in that area should at least cover that and that cases. Would you like to propose one?, sure. Can you point out to any case where I flat out stated that a regtest would not be warranted? i think this deserves a comment no, it doesn't Can you please propose a comment that does not a) talk about a state that's not actually in the code and won't get there accidentally b) is not _immediately_ _literally_ obvious from the code for anybody knowing the language that something is written in? Comments should increase the signal/noise ratio of a program, not decrease it. They need to tell the story that is _not_ explicitly coded. I suppose that you're not doing this intentionally. But it drives me crazy anyway. Anyway, it seems that when i try to review your patches the first and foremost result is that we both loose time, Does that mean that I can save myself the effort to _explain_ my decisions since you would consider it a loss of time to try understanding them? You _are_ aware that it takes much less effort to put in a useless comment rather than explain why it wouldn't help in a particular case? So obviously my main aim is not to reduce the amount of work. so i suppose that i should stop reviewing your patches Depends on your goals. https://codereview.appspot.com/13256053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org
Re: improving our contributing tools and workflow
Jan Nieuwenhuizen jann...@gnu.org writes: Janek Warchoł writes: Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? You may want to study - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). git's development itself is less dictator-specific than Linux' development, I think. This is also a bit of a red herring since our Contributor's Guide does _not_ ask for using the issue tracker (in fact, the issue tracker itself quite clearly states that users should not enter issues themselves). It can be argued that Email-based patch submission _is_ already what we propose, and we have the bug-squad as an interface into the issue tracking system from there. Part of the reason is actually that I started contributing patches a few years ago to LilyPond when there was nothing like the bug squad around, and after a while of contributions seemingly going down the drain without anybody who could be interested in them, getting really and quite obnoxiously pissed. So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reason is that any good mailing list citizen will, before contributing, study some of the mailing list archives to figure out how things are usually done. And of course, studying our mailing list histories does not suggest that just submit a git patch series is a viable thing to do. So should our finally selected issue/review tool try _faking_ that appearance? Maybe. No idea. Perhaps we are overthinking this. At any rate, looking at options for more Git-centric tools than Rietveld can't do much harm. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:26, David Kastrup wrote: So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reason is that any good mailing list citizen will, before contributing, study some of the mailing list archives to figure out how things are usually done. There may be another side to this. Post-GitHub there has been a pretty substantial increase in the user-friendliness of DVCS. What's currently advocated in the Contributors' Guide stands in stark contrast to the ease of contribution (and contribution management) that many people experience as the norm now. I'll give one example, because it's not clear to me that people have understood my past objections to git-cl etc. Here's a currently-open pull request of mine in another project that I contribute to: https://github.com/D-Programming-Language/phobos/pull/1533 You'll see that below the summary there is a report from the project auto-testing facility, with a link to a more detailed overview of the test results. What that means is that -- as a contributor -- I just submit a pull request via GitHub's UI. Testing is taken care of for me, and the feedback is there and integrated into my pull request for me to read and (if necessary) respond to. Or, if I were a reviewer, I again wouldn't need to worry about the testing, except as information useful for my review. In other words testing is a completely automated process that requires no manual intervention from anyone and no changes to the standard GitHub workflow. Contrast that with git-cl, and also bear in mind how user-friendly GitHub makes pull request submission and review. Unfortunately in this case the tool is a custom-written one for the project, because they had some very specific requirements and at the time no one tool supported all of them. It's possible of course that now the existing tools would satisfy what they needed. So, it's not likely to be directly useful for Lilypond, but it _is_ a very good model of how testing can be integrated into code review in a non-intrusive way. Similarly, the project's bugzilla listens in on pull requests and can be automatically updated when an appropriate pull request lands (the requirement is that the pull request title contain the issue number, so in this case it's not 100% automatic, but then, how could it be?). All of this is orders of magnitude more user-friendly than what Lilypond currently operates and I don't think I'm wrong in saying that this kind of easy DVCS experience is now the expected norm for many developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 13:56, Phil Holmes wrote: As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. Good. That should make the range of available solutions much broader. I'd see the way to approach this as in 3 stages: (1) propose the architecture of the solution and present a prototype with a toy project just so that everyone can try it out from a user perspective. (2) if people like it, work to get a prototype set up that works with the Lilypond codebase. (3) if people still like that, do any necessary work like importing issues, etc. and switch over to the new system. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 11:48, Janek Warchoł wrote: David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? GitLab: http://gitlab.org/ Looks more feature-complete and user-friendly than Gitorious (it's got issue tracking as well as code hosting built in). You can use a hosted version (gitlab.com) or host your own version. It's MIT-licensed. They do a Red Hat-y kind of thing where they have an Enterprise Edition as well as Community Edition, but so far as I can tell from this summary, it's still MIT-licensed: http://www.gitlab.com/features/ ... so there shouldn't be any GNU/FSF-related political objections here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 1:06 PM Subject: Re: improving our contributing tools and workflow Hi, to make things clear: i do not intend to attack anyone personally, or imply that anyone has bad will or malicious intentions. I only want to explain how the situation looks like from my point of view. 2013/9/26 Phil Holmes m...@philholmes.net: Janek wrote: 2013/9/26 Phil Holmes m...@philholmes.net: Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. Because your message sounds pessimistic. It sounds like you consider it likely that my attempt to do something good will fail. It sounds like you are not concerned with ensuring that this initiative suceeds and brings benefit to all, but rather you are thinking about the damage and problems it can bring. I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) Check the results of the grand regression test review. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stop \lyricmode { \skip 1.*3 } from failing. (issue 13256053)
2013/9/26 d...@gnu.org: On 2013/09/26 10:51:34, janek wrote: Uh, David, thanks for this explanation, but i'm afraid it was not needed. If the code doesn't need a comment, just say so. Now, speaking in general: i don't understand that when Mike submits a patch, you often complain that it's not commented well enough, but when I ask you for comments, you usually say this doesn't need any comment. Apparently both you and Mike consider what you write to be self-explanatory. git blame lily/lexer.ll|grep //\|/\*|wc -l 146 git blame lily/lexer.ll|grep //\|/\*|grep Kastrup|wc -l 120 git blame lily/lexer.ll|wc -l 1382 git blame lily/lexer.ll|grep Kastrup|wc -l 677 Are you sure that your characterization is fair? I'm responsible for less than half the lines in the lexer, but for more than 80% of the lines starting a comment in the lexer. That's very commendable, but i think you missed my point. I didn't say that you don't put comments in your code. I said that _what you write_ (i.e. code+comments that you write) is not self-explanatory for me. It's quite probable that i'm simply too dumb or unskilled to understand things that an average programmer should understand. When my typical complaint with a commit from Mike focuses on the _number_ of comments, it's usually because there are about 10 lines of comments in 5000 lines of code (which seems indeed out of proportion based purely on the numbers, particularly when the whole _framework_ put together in those 5000 lines is non-trivial, opaque and mostly non-discoverable), and half of the comments are wrong. Now statistics can definitely be misleading as indeed a comment can be worthless and/or distracting and always is in danger of running out of sync with the code. So it needs to have value _separate_ from the code in order to be worth it. If it repeats the story spelled out in the code (and this is what you ask for here), Note that only first two lines of my reply was about this particular patch. Everything else was said about my general experience. So, i'm not insisting that there should be a comment here. Maybe you are right that for an experienced developer Mike's code isn't self-explanatory, and your code is. All i know is that for me neither is self-explanatory. So you say that a pattern written starting with [^.*|... does not tell you that it is supposed to match something not starting with a . * | and whatever else is listed here. That's a matter of not knowing Flex and/or regular expressions, not a matter of not being able to follow the logic of the code. Yes, you're right. That's like asking for a comment like x += 2; // increase x by 2 which is not helpful. yes, you're right. Of course, i'm not an experienced programmer. But then, i've been working on LilyPond since 3 years now, and that seems a pretty long time. I am sorry that (apparently) you don't care whether i can understand your patches easily or not. You will understand a patch to the lexer _only_ if you know the language the lexer is written in. A code review that has to rely on _comments_ in order to understand every facet of the code (rather than larger contexts and/or its design) is basically useless as any divergence between code and comment can't be detected. yes, you're right. Also, from my perspective, it seems that you consider yourself to be always right: i think this deserves a regtest no, it doesn't If you consider no, it doesn't as the same as a regtest in that area should at least cover that and that cases. Would you like to propose one?, sure. Can you point out to any case where I flat out stated that a regtest would not be warranted? No, i don't have such example. i think this deserves a comment no, it doesn't Can you please propose a comment that does not a) talk about a state that's not actually in the code and won't get there accidentally b) is not _immediately_ _literally_ obvious from the code for anybody knowing the language that something is written in? No, i cannot. Comments should increase the signal/noise ratio of a program, not decrease it. They need to tell the story that is _not_ explicitly coded. yes, you're right. I suppose that you're not doing this intentionally. But it drives me crazy anyway. Anyway, it seems that when i try to review your patches the first and foremost result is that we both loose time, Does that mean that I can save myself the effort to _explain_ my decisions since you would consider it a loss of time to try understanding them? Not really. I think that you can save yourself the effort to explain your decisions - at least in this particular case - because that's an ineffective use of your time. Also, having me understand your decisions is not required for anything. In any case, i didn't ask for explanations in the first place. I just suggested adding a comment, without requiring you to explain yourself
Re: improving our contributing tools and workflow
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: There may be another side to this. Post-GitHub there has been a pretty substantial increase in the user-friendliness of DVCS. What's currently advocated in the Contributors' Guide stands in stark contrast to the ease of contribution (and contribution management) that many people experience as the norm now. Just to give some perspective: let's assume LilyPond development were entirely moved to GitHub. How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:52, Phil Holmes wrote: I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) Check the results of the grand regression test review. This risks becoming another corrosive discussion, so please understand that what I say next is not intended as an attack on anyone here and is meant in a spirit of hope for Lilypond's prosperous future. There is another possible response to such a situation, and it's: Oh wow, this person put a load of work in, they're obviously really committed and enthusiastic. OK, let's use these problems with what they've done as an opportunity to educate them better about how Lilypond works and how to avoid these kinds of problem in the future, and make them feel that we really value the time they've put in and want to repay them in kind. Now, I'm not assuming that no one has ever done this. I rather imagine it's been tried and that the resulting workload (probably mostly Graham's) has been overwhelming and that in fact there is no guarantee that it pays off in terms of another long-term contributor -- so people have been discouraged from this approach by hard experience. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. FWIW I think automated testing of pull requests is helpful here because test failures are impersonal and encourage the contributor to pro-actively sort out the problems in their code without having to be told -- there's not the same sense of personal rejection. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: enhancement request - new header field: movement
Hi David, lilypond has a header field piece, which is meant for movement names. To have this field centered - default is left above the score - one has to modify scoreTitleMarkup in paper. Perhaps other markups would be nice. (a markup is a template by itself, because it gets its title/coposer/etc names via \getProperty #'header:...) HTH Best, Jan-Peter On 25.09.2013 13:39, address@hidden wrote: I've been wanting a movement field in LilyPond's headers. I've managed to make something for myself that is working, more or less, but I'm sure it could be done much better by someone who actually knows what he's doing. My idea is that it should be centered horizontally and be lower on the page than the other fields. That is, the last header field before the printed music. I think having the font the same as the title or maybe on size smaller would work well. I think this would be of general utility for others as well. -David ___ lilypond-devel mailing list address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-devel I knew about piece. I thought it would also be useful to have the 'movement' field as I described. In most cases I see movement indications horizontally centered before separate movements, hence my request. -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. But in a way I think this is the point -- I'm likely to continue to be an occasional contributor, sending something in when I have something I'm enthusiastic about when I have time and space to work on it. As things stand it's difficult to get that enthusiasm because there's a load of finnicky and annoying things involved with making a submission. If the ease of contribution was comparable to GitHub, I'd feel a lot better about doing so. I do appreciate your offer to just send patchlists to the mailing list and let you guys handle them, and I will try and do that, but it's still not as nice as a good code-hosting system. By the way, I'm not advocating GitHub as a solution. I'm pointing out GitHub as a now typical example of typical user experience contributing to free software projects. I also think that kind of usability would also pay off for you and other core developers and code reviewers, even if there are is no substantial increase in patch submission. I can understand if you don't see things the same way, though. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: Now, I'm not assuming that no one has ever done this. I rather imagine it's been tried and that the resulting workload (probably mostly Graham's) has been overwhelming and that in fact there is no guarantee that it pays off in terms of another long-term contributor -- so people have been discouraged from this approach by hard experience. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. Well, you think that it's better to demoralize existing developers rather than hypothetical would-be contributors nobody knows. How many patches would you expect to be contributing per month to LilyPond when it would use the code management systems you prefer? FWIW I think automated testing of pull requests is helpful here because test failures are impersonal and encourage the contributor to pro-actively sort out the problems in their code without having to be told -- there's not the same sense of personal rejection. We have automated tests of contributions already. Before telling everybody how to do everything better, how about making yourself acquainted with how we are doing things? Perhaps easiest done by contributing a few patches to the lists in the manner you like, and see what progress they make through the system? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:23, David Kastrup wrote: Well, you think that it's better to demoralize existing developers rather than hypothetical would-be contributors nobody knows. This is going to be a toxic direction of discussion if we pursue it, so I won't respond, except to say that it is not my intention to demoralize anyone, and I'm sorry if anyone does feel attacked or demoralized by what I've said here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: David Kastrup d...@gnu.org Cc: Jan Nieuwenhuizen jann...@gnu.org; Janek Warchoł janek.lilyp...@gmail.com; LilyPond Development Team lilypond-devel@gnu.org; Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 2:22 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type git cl upload on your behalf, in order to get the patches reviewed. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Phil Holmes wrote Thursday, September 26, 2013 3:11 PM - Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type git cl upload on your behalf, in order to get the patches reviewed. Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let make-music accept existing music or alists as source (issue 13904043)
Thomas Morley thomasmorle...@gmail.com writes: 2013/9/26 thomasmorle...@gmail.com: LGTM https://codereview.appspot.com/13904043/ Let me add: I started custom-scheme-coding with LilyPond 2.12.3 and found it _very_ difficult to modify music-arguments those days, whereas affecting grobs was quite easy. Well, music objects are typically hierarchical objects whereas grobs don't contain other grobs (well, apart from some rather fuzzy parent relations which you usually don't want to touch). So it's natural that music objects tend to be more complex to manipulate. On the other hand, that's what a user will want to meddle with first, so it should be as simple as possible. There's still a lot of potential for that. Now we have 2.17 and after all your work in this area, modifying music has become _much_ easier and so it'll continue with this patch. The sad thing is that this one was pretty low-hanging fruit. I decided to look for instances of (map ...) instead of (for-each ...) and then there was some snippet using map that was annoyingly awkwardly coded in relation to the complexity of what it did. Simply because the available primitives/APIs worked with different data representations for no really convincing reason. I probably should spend a week each month just working _with_ LilyPond rather than _on_ LilyPond, just so that the right kind of thing is getting on my nerves enough to make me want to change it. Simply: Thanks a lot. Well, I'd have to thank you even if it only were for the large amount of work you provide to list readers in order to get LilyPond solve their problems. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: Trevor Daniels t.dani...@treda.co.uk; Phil Holmes m...@philholmes.net; David Kastrup d...@gnu.org Cc: LilyPond Development Team lilypond-devel@gnu.org Sent: Thursday, September 26, 2013 4:09 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Good job I didn't get discouraged by the problems with piano pedal notation. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:16, Phil Holmes wrote: I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. _Conceptually_, the problem is this: Lilypond's pitch model consists of PITCH = STAFF_POSITION + ALTERATION where alteration is some fraction of a whole tone. (Actually there's no theoretical limit. You could have 3/2 of a tone, 2 tones ... although because the current transposition rules have a hard-coded limit of +/- 1, it's actually impossible in practice to transpose into keys where you might have triple sharps or flats. Hey, they do exist...:-) That model works fine for the standard 12 chromatic pitches, and it works fine for microtonal notation where each microtonal alteration is represented by a unique accidental. It fails for microtonal notation that essentially consists of PITCH = STAFF_POSTION + ALTERATION_0 + ALTERATION_1 + ... + ALTERATION_n of which quarter-tone arrow notation is one example (you have a first-order alteration which is the regular accidental, and a second-order alteration which is the up- or down- arrows). Ben Johnston's notation for extended just intonation is another example that very strongly relies on this hierarchy of pitch shading -- see e.g.: https://www.youtube.com/watch?v=0kVdgCWFJzE ... and http://notesfromadefeatist.blogspot.it/2010/01/just-intonation-notation.html for some explanation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:35, Joseph Rushton Wakeling wrote: Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. I should add that despite being the author of the original enhancement request, I don't think I was ever invited to take part in that review, which is a shame, as a number of participants seem to have misunderstood what I asked for. It may have just passed me by, though. I was working in a very intense and stressful job at the time and not following discussion very closely. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 26/09/13 17:35, Joseph Rushton Wakeling wrote: Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. I should add that despite being the author of the original enhancement request, I don't think I was ever invited to take part in that review, which is a shame, as a number of participants seem to have misunderstood what I asked for. It may have just passed me by, though. I was working in a very intense and stressful job at the time and not following discussion very closely. You commented on the issue where this patch originated as late as July: URL:http://code.google.com/p/lilypond/issues/detail?id=1278#c7. So it's hard to argue that it was not discoverable to you. The creation of the issue tracker was pointed out to you in a direct reply by Valentin in URL:http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00424.html. The discussion thread containing this pointer consists of four mails. Three of those mails were written by yourself, only the final reply with the pointer to the tracker issue was written by Valentin. I doubt that using a different tool would have changed your perception of never having been invited to take part in that review. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. It is easily solved by not using E24, as it does not sound good anyway. :-) But the problem is similar to that of enharmonic equivalences in E12: the staff system is not designed to express that. So first engrave as though they are different, end apply enharmonic equivalences at the end according to taste. In mathematical terms, the staff system is generated by an (abstract) minor second m and a major second M, all formal combinations r*m + s*M, where r, s runs through all integers: a free abelian group of rank 2. The degree d = deg(r*m + s*M) is the staff position. Each staff position has a note also of this form: subtract it, and what remains is a note of of degree d = 0. A sharp raises with M - m, and a flat lowers with the same amount. If d = 0, then r + s = 0, then so if s 0, add s sharps, and if r 0, add r flats. Now, this works also with microtonality: just add neutrals n = n_0, n_1, ..., n_k, which will result in a rank 2 + (k + 1) free abelian group of the pitches r*m + s*M + t*n + ... + t_k*n_k. Engrave the same way: compute degree d = deg(r*m + s*M + t*n + ... + t_k*n_k) := r + s + t + ... + t_k, which is the staff position, subtract the staff note, and what remains is a note of degree 0. It can be expressed by a suitable combinations of accidentals, where those that involve a neutral n_i are microtonal. Now, if you add a quarter-note, that is, a neutral n that when assigning pitches should have the value n = (m + M)/2. However, there is no way to express that in the staff system, just as it is not possible to express that 2*m = M. So in the staff system, the accidental going from m to n, the raising quarter-tone, will always be different from the one going from M to n, the lowering quarter-tone. Summarizing: E12 and E24 are tuning systems, which the staff system does not express. If one wants them to be properly expressed, invent a new notation system. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 13-09-26 03:48 AM, Janek Warchoł wrote: Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Cheers, Colin -- A good juggler can always find work. - attributed to L. Pacioli (1445 - 1517) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. For one microtonal accidental, one needs, in addition to the minor/major seconds m and M, a neutral second n. For a pitch x = r*m + s*M + t*n, compute its degree deg(x) := r + s + t, which is its staff position, and subtract the staff pitch. There remains a new pitch, which I also call x, but now with r + s + t = 0. As sharps/flats alter with a multiple of r - s, reduce using them so that only one of r, s is non-zero. Assume first that t = 1, i.e., one n. Then it must be either n - M or n - m. We have six microtonal symbols, sharp/natural/flat with up/down arrows, but it will, as we shall see, suffice with four. One way to make a choice is to conceptualize n as below or above (m + M)/2: if it is a small or large neutral. This choice is purely formal at this point, but will be of importance when plugging in values. If one thinks of n as between m and M, which is possible with actual values by reducing using sharps and flats, then n' := (m + M) - n (the minor third m3 complement) is also a neutral between m and M. If n is small, then n' is large, and vice versa. Returning to the situation above, assume n to be small. The up/down arrows will be thought of as changing with a small amount: n - m. There are two possibilities: n - m, and n - M. In the first case, n - m represents a small positive amount, so it is the natural with up arrow. In the second case, it is a large negative amount, so it is the flat with up arrow. Assume now that t = -1, so the two cases are m - n and M - n. The first case lowers with the small amount n - m, so it is a natural with a down arrow. And M - n raises with a large amount, so it must be a sharp with a down arrow. If the absolute value |t| of t is larger than 1, then one needs as many arrows as |t|: up if t is positive, and down if t is negative. Two symbols where not used: sharp with up arrow and flat with down arrow. But they conceptually fall without the region of raising a sharp M - m or lowering with a flat -(M - m), and can in fact be reduced using a natural with up/down arrow plus a sharp/flat. So here, one would need notation simplification algorithm. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
arrow notation for quarter-tones, issue 1278 (was: improving contributing tools)
Hi, 2013/9/26 Hans Aberg haber...@telia.com: On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: Joseph Wakeling wrote: I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. For one microtonal accidental, one needs, in addition to the minor/major seconds m and M, a neutral second n. For a pitch x = r*m + s*M + t*n, compute its degree deg(x) := r + s + t, which is its staff position, and subtract the staff pitch. [...] Thanks for your input, Hans :) However, please create a new thread when starting a new topic; having microtonal emails mixed with maintenance discussion is inconvenient. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/26 Colin Campbell c...@shaw.ca: On 13-09-26 03:48 AM, Janek Warchoł wrote: Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Excellent! We'll probably start by creating some test repositories on gitorious.org and gitlab.org, you may create an account already and look around. Meanwhile i'm going back to my little lilypond-vacation. see you soon, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/27 Janek Warchoł janek.lilyp...@gmail.com: 2013/9/26 Colin Campbell c...@shaw.ca: Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Excellent! We'll probably start by creating some test repositories on gitorious.org and gitlab.org, This should be gitlab.com (gitlab.org is a website about the software that runs gitlab.com). Sorry for confusion. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote: On 26/09/13 14:52, Phil Holmes wrote: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) This risks becoming another corrosive discussion, Then WTF are you starting it? There is another possible response to such a situation, and it's: Oh wow, this person put a load of work in, they're obviously really committed and enthusiastic. OK, let's use these problems with what they've done as an opportunity to educate them better about how Lilypond works and how to avoid these kinds of problem in the future, and make them feel that we really value the time they've put in and want to repay them in kind. Great answer! I'm so happy that YOU STEPPED FORWARD TO DO THIS IN THE PAST. The main developers owe NOTHING to somebody just because they did some work. I try to warn people NOT to waste their time, and Phil helpfully carries these warnings forward, and people criticize us for being demotivating. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. I breathlessly await the time when YOU do this, instead of complaining that existing developers don't do whatever you think they should be doing. Of course, first you need to learn how stuff works, and so far you've shown minimal interest in doing so. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote: - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). Are you volunteering to be that benevolent dictator? Spend, say, 15 hours a week reviewing and approving patches? I have no quarrel if you want to do that. The whole system is set up to minimize the demands on main developers. Any solution which shifts the burden away from contributors and onto main developers is IMO bad for LilyPond. We do *not* have an active body of main developers who want to spend time on administration. Does this place more burden on new contributors? yep. Do I think that's fair? yep. At least, it's certainly more fair than giving contributors expectations that the main developers are not willing to meet. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
