Re: markup-command and markup-command-list signatures
Boris Shingarov b...@shingarov.com writes: I am working on a system of markups which allows to specify more flexible formatting rules. WE are using it for things like multi-line embedded scores, mixing them with markup lines, rules about what things / combinations of things should not start / end a line, also there are rules like no line break between certain words and beginning ebmbedded score, that kind of formatting rules. I had described some of these ideas in my earlier posts on this list. Markup functions being able to return a list of stencils. Markup lists don't do the trick here? Much more importantly, markups need to be aware of what was placed before, and what is to follow, therefore when processing the markup-list, we need to pass a continuation at each step, instead of iterating over the list. This kind of ideas. It even sort of works. Well, works enough for production use by non-programmer users. But still far from being a general Lilypond improvement. The other, easier improvements (orphan-avoiding functionality, page-breaking fixes), are making it fine into the upstream repo: for those, going from the happy state of having the user's problem fixed, to the happier state of fixing it for everyone, is of a reasonable proportion compared to the whole amount of work. But with my markup changes, it's much different. Even the first and simplest of these changes (patch 207105), to go from the current state to an actual submittable patch, will take like 2x the time it took to get it to solve the user's probem. I don't see that you stand a chance with the standard processes here. You don't have commit access. The gold standard here (to the exclusion of all other workflows) is a patch review on Rietveld. That basically limits feedback to persons with a Google developer account. At the point of acceptance, the change is pulled in as a single commit touching lots of areas simultanously. Since mainline development continues, there is no sensible strategy for merging/rebasing for anybody without a branch history. So the only person able to work on this will be yourself. People will be able to check your work only when the patch set applies. But that means that mainline changes in the same areas need to be tracked by you and will also pollute the Rietveld review area. I don't see that a task like this can be sensibly done except in a separate branch. But working like that is a git workflow rather than a Subversion one, and does not fit with the Rietveld processes. Of course you can set up your own Lilypond repository for pulling, but the way I see it, the relevant developers would refuse to participate in non-standard processes like that. I don't see that humongous changes like that can be usefully integrated in a single non-merge commit. There must be infrastructure changes and so on, and you'll need to set up reviews for each of them, without an apparent goal being accomplished before the last commits make it. Basically you'll be on your own going against the tide until you are finished. The work flows here are designed to achieve code quality by making it harder for a would-be contributor to get sub-par code through, not by making others participate with the work. I'd like to see me proven wrong. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't hardcode a limited set of markup signatures. (issue969046)
Han-Wen Nienhuys hanw...@gmail.com writes: On Sun, May 2, 2010 at 6:19 PM, David Kastrup d...@gnu.org wrote: For one reason or another, whenever I review code from you it degrades into a fight. I am not quite sure why this always happens. Because you don't bother taking the contributions of other people seriously. You don't read the code comments, even after you asked for Thanks for explaining this; it's obviously my fault. I'll go back to where I came from. Nice touch, but it's not your work going in the bin. cheers, Same. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't hardcode a limited set of markup signatures. (issue969046)
On 2010/05/02 16:34:12, hanwenn wrote: On Sun, May 2, 2010 at 8:04 AM, mailto:d...@gnu.org wrote: http://codereview.appspot.com/969046/diff/7001/8002 File lily/lexer.ll (right): http://codereview.appspot.com/969046/diff/7001/8002#newcode545 lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS. On 2010/05/01 19:56:08, hanwenn wrote: wouldnt it be clearer to have a function nbsp; void translate_markup_signature(SCM predicate_list, nbsp; nbsp; nbsp;vectorint expect_tokens); The quality of the current code is not an argument to not improve over it. The current code is largely from my hand, but there are many things I would do differently today for many reasons. Patches will be thoughtfully considered. http://codereview.appspot.com/969046/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't hardcode a limited set of markup signatures. (issue969046)
On Mon, May 3, 2010 at 4:22 AM, David Kastrup d...@gnu.org wrote: For one reason or another, whenever I review code from you it degrades into a fight. I am not quite sure why this always happens. Because you don't bother taking the contributions of other people seriously. You don't read the code comments, even after you asked for Thanks for explaining this; it's obviously my fault. I'll go back to where I came from. Nice touch, but it's not your work going in the bin. Just for the record: I am ok with the current form of the patch. I take issue with the way you interact with me on the mailing-list, and I have had enough of it. -- 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: Don't hardcode a limited set of markup signatures. (issue969046)
Hi Han-Wen, I take issue with the way you interact with me on the mailing-list, and I have had enough of it. For the record, I am appalled at David's etiquette -- which is to say, complete lack thereof -- and understand your reaction completely. While I appreciate and (at a basic level) value every- and anyone's input into Lilypond, I certainly value yours more than his, in no small part because of the bad spirit with which his is constantly contributed. There are undoubtedly others that feel the same way. Just wanted to let you know -- and say it in this public forum -- so that you don't feel unappreciated or unsupported against David's regular and unnecessary negativity. Best regards, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: Boris Shingarov b...@shingarov.com writes: Markup functions being able to return a list of stencils. Markup lists don't do the trick here? No; if you look at patch 207105, you'll see what I mean. I don't see that you stand a chance with the standard processes here. [...] Basically you'll be on your own going against the tide until you are finished. The work flows here are designed to achieve code quality by making it harder for a would-be contributor to get sub-par code through, not by making others participate with the work. I guess even that assessment is overly optimistic. The real problem here is not of process, but of fundamental interests. I am scratching *my* itch, which is, make top-publication-grade work possible with Lilypond. Lilypond did not reach this grade before. So this work is beneficial to the Lilypond community in two ways: proving we can go on that territory, as well as purely technical contributions. Now, with technical contributions that are easy enough to integrate back upstream, ok I can spend the extra 30% effort to integrate; but 500% does not seem justifiable and then we take the GPL as the guideline: here is the new code, enjoy doing whatever you please with it. But I am open to any suggestion how to make it more useful to the community. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please add patches to the tracker if they're getting lost
Hi Graham, I would like to ask for some advices concerning tracking of patches: 1. Is there an easy way to find out if some patch was pushed? 2. I guess there are some developers who's patches I don't need to follow, because they can push patches themselves. Is there a list of them? 3. should I track documentation patches as well? Marek 2010/4/28 Marek Klein ma...@gregoriana.sk Hi Graham, 2010/4/28 Graham Percival gra...@percival-music.ca A few months ago, Marek voluteered to record patches. The guideline is that if there was no activity for 3 days, he'd add it to the tracker. Marek, are you still willing to do this? Yes, I am. It is not clear enough in every case and I was quite busy last two months, but it should be better again. If someone sees some delay, please drop me a line, if you don't like to make tracker item by yourself. Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: LM: Reformat ly code. (issue1056041)
I'm out of time to finish this review today, so I thought it would be best to publish what I have. My overall thought is that in the Learning Manual, we shouldn't enforce yet-to-be-explained coding standards. Instead, we ought to format the examples to do the best job possible of explaining the particular item the example is trying to explain. Later in Learning, when we talk about larger projects, we should introduce the code standards and even give a link to Contributors. In fact, I might prefer to have the coding standards mentioned in Learning and linked to from Contributors, but I'm not positive about that. Thanks, Carl http://codereview.appspot.com/1056041/diff/1/2 File Documentation/learning/common-notation.itely (right): http://codereview.appspot.com/1056041/diff/1/2#newcode101 Documentation/learning/common-notation.itely:101: aeses1 During the GDP, we established the policy that simple lines such as this could be on one line, even though they had multiple bars. Perhaps we could just change the durations in this to 4, and we wouldn't even be having a discussion. http://codereview.appspot.com/1056041/diff/1/2#newcode226 Documentation/learning/common-notation.itely:226: c4~ c8 a~ a2 I don't think a requirement to eliminate unnecessary durations is wise. Extra durations cause no problem at all, and may even make the music more readable. Making sure we have a minimum set of specified durations (start of measure or start of line) makes sense to me. http://codereview.appspot.com/1056041/diff/1/2#newcode253 Documentation/learning/common-notation.itely:253: b'2 a4 cis,\) Add bar check, IMO. In terms of the core concept for this snippet, the slur and the phrasing slur, I think the original snippet shows the structure more clearly, with the () nested inside the \( \). So on a strictly pedagogical basis, I would tend to violate the general code formatting rules for this case and leave it as-is. http://codereview.appspot.com/1056041/diff/1/2#newcode271 Documentation/learning/common-notation.itely:271: fis2 g) Same comment as for the previous snippet. http://codereview.appspot.com/1056041/diff/1/2#newcode299 Documentation/learning/common-notation.itely:299: c4-+ c-_ Since the objective here is to show the articulations, we may not want to worry about splitting the line. If we do want to split the line, we should find two more articulations and add them, so we get two complete bars, and put a bar check in the middle. http://codereview.appspot.com/1056041/diff/1/2#newcode365 Documentation/learning/common-notation.itely:365: c2 c\! See my comment at line 289 http://codereview.appspot.com/1056041/diff/1/2#newcode390 Documentation/learning/common-notation.itely:390: a1_legato Repeat of 289 http://codereview.appspot.com/1056041/diff/1/2#newcode982 Documentation/learning/common-notation.itely:982: d4 b8 g4. Bar checks here. Pedagogically, it may be nice to have the notes and the lyrics have lines of the same length. http://codereview.appspot.com/1056041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 3. Mai 2010 15:12:56 schrieb Boris Shingarov: The real problem here is not of process, but of fundamental interests. I am scratching *my* itch, which is, make top-publication-grade work possible with Lilypond. Lilypond did not reach this grade before. Well, yes and no. I'm generating top-grade publications (critical editions) myself to be printed and sold (just gave a presentation about this very subject three hours ago at the LAC conference). Most things are working very well, but there are several rough edges, where you need to find workarounds (fixes would be better;-) ). BTW, I'm applauding your efforts and also that you can be paid from a research project! It would be quite interesting to see your list of things that need to (or will be ;-) ) improved for professional editions. Here's my list of things that I need for editions, and that need fixing: - -) Part combination absolutely unusable - -) Footnotes (for editorial comments) - -) Automated lyrics to cue nots ( cue lyrics) - -) Order of bass figures exactly as entered - -) it needs to be easier to move dynamics inside the staff (I have a workaround, but that needs the y position for every dynamic sign moved!) - -) dynamic spanners with hidden line should ignore collisions with the invisible line. - -) ETC... Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/ * LilyPond music typesetting software, http://www.lilypond.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkve1jYACgkQTqjEwhXvPN1DygCfVW+QeQ4mYCqUQV8ODqNoOPsJ g3YAoKIOAl8GYEwSUvlFs0oBYi5uw1Hj =7AX4 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
Boris Shingarov b...@shingarov.com writes: On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: Boris Shingarov b...@shingarov.com writes: Markup functions being able to return a list of stencils. Markup lists don't do the trick here? No; if you look at patch 207105, you'll see what I mean. I don't see that you stand a chance with the standard processes here. [...] Basically you'll be on your own going against the tide until you are finished. The work flows here are designed to achieve code quality by making it harder for a would-be contributor to get sub-par code through, not by making others participate with the work. I guess even that assessment is overly optimistic. The real problem here is not of process, but of fundamental interests. I am scratching *my* itch, which is, make top-publication-grade work possible with Lilypond. If you take a look at Lilypond documentation at the web page, you'll see that this focus is supposed to be a major goal of Lilypond. So that should not be an impediment. Lilypond did not reach this grade before. So this work is beneficial to the Lilypond community in two ways: proving we can go on that territory, as well as purely technical contributions. Now, with technical contributions that are easy enough to integrate back upstream, ok I can spend the extra 30% effort to integrate; but 500% does not seem justifiable The main problem I see with Lilypond is that its development processes are falling apart due to the high complexity it has gained through the mixture of flex/bison/C++/Scheme/PostScript and the consequence that very few people are knowledgable with all of its parts and interoperations (in particular the details of tying together contexts, translators and interfaces, hidden deep in the bowels of C++). And those that are, are busy. Catering for your requirements without bogging separate material on in inconsistent and intractable ways is going to take deep surgery. The resulting code needs to be tied in as well as if it was originally designed in that manner, or nobody will be able to learn dealing with it in sensible amounts of time. You see the current state of page breaking: the appearance is that not more than one person, possibly less, understands it fully at the current point of time. Or at least can be bothered about looking at it. But I am open to any suggestion how to make it more useful to the community. The code alone will not be useful would be my guess. It sounds like it might be viewed like a proverbial Trojan horse where tearing down the walls to let it in will weaken the project's defenses against unmaintainability. My personal advice to you is to consider it and treat and value it like a proof of concept: it shows that something _can_ be done to address your problem space. Even by a single person that is not a core developer. A proof of concept is a whole lot better than nothing in your hands. Presenting its design and results achieved with it will be a good step forward to make others move with you. Trying to make the proof of concept code changes as self-contained as possible so that people have less work understanding what you are doing will also help for getting others interested and to understand, even though the end product is desired to be well-integrated into the overall design. That's my take on it, but of course you are aware of my standing here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
On 3 May 2010 15:04, Carl Sorensen c_soren...@byu.edu wrote: I've reviewed the patch; the only problems I see are minor indentation and formatting issues. I'm surprised, because the patch set says it's 2 months old, but I can't find any reference to issue 207105 in the -devel or the -user archives. So this is the first time I've known that the patch is available for review. If I've missed it, I'm sorry. See this thread: http://lists.gnu.org/archive/html/bug-lilypond/2010-02/msg00150.html Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi Han-Wen, I take issue with the way you interact with me on the mailing-list, and I have had enough of it. For the record, I am appalled at David's etiquette -- which is to say, complete lack thereof Thanks for that important observation. It is likely to improve the quality of contributions. -- and understand your reaction completely. While I appreciate and (at a basic level) value every- and anyone's input into Lilypond, I certainly value yours more than his, in no small part because of the bad spirit with which his is constantly contributed. Most certainly. In the five days I'm tearing my hairs out in order to get the work of two days accepted, he can do the same amount of work twice over and commit it. Without needing to bother about those parts of reviews which he does not consider thoughtful as in patches will be thoughtfully considered. You'd be a fool to pick otherwise. Having my chains yanked is not something I deal with gracefully. There are undoubtedly others that feel the same way. There is no shortage of them: they are easier to recruit than coders. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make Completion_heads_engraver respect tuplets and scaling
On 1 May 2010 23:58, PálBenkő benko@gmail.com wrote:
hi all,
patch and an example below.
this may look academical, but I need this feature when
transcribing renaissance music - for real life examples see
http://wiki.lilynet.net/index.php/Benkop_projects
the Ockeghem and la Rue examples.
This looks OK to me. Can you add a short regression test to go in
input/regression?
I want to handle rests also; could someone help me
with advice? in particular, should I add a listen_rest
or handle it fully within note handling?
It should be done with a new engraver, which replaces Rest_engraver
and Multi_measure_rest_engraver.
I had a go at creating a Completion_rests_engraver last year (see the
attached patch), but it needs some more work to fix problems when
skipBars = ##t.
Thanks,
Neil
From b50e8ca24526b40d3ad2c382649679fe309132b7 Mon Sep 17 00:00:00 2001
From: Neil Puttock n.putt...@gmail.com
Date: Sat, 14 Nov 2009 13:50:56 +
Subject: [PATCH] Add Completion_rests_engraver.
---
lily/completion-rests-engraver.cc | 282 +
1 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 lily/completion-rests-engraver.cc
diff --git a/lily/completion-rests-engraver.cc b/lily/completion-rests-engraver.cc
new file mode 100644
index 000..45a78d6
--- /dev/null
+++ b/lily/completion-rests-engraver.cc
@@ -0,0 +1,282 @@
+/*
+ completion-rests-engraver.cc -- Completion_rests_engraver
+
+ (c) 2009 Han-Wen Nienhuys han...@xs4all.nl
+*/
+
+#include duration.hh
+#include global-context.hh
+#include output-def.hh
+#include paper-column.hh
+#include pitch.hh
+#include rhythmic-head.hh
+#include score-engraver.hh
+#include spanner.hh
+#include staff-symbol-referencer.hh
+#include stream-event.hh
+#include warn.hh
+
+#include iostream
+using namespace std;
+
+#include translator.icc
+
+/*
+ How does this work?
+
+ When we catch the note, we predict the end of the note. We keep the
+ events living until we reach the predicted end-time.
+
+ Every time process_music () is called and there are note events, we
+ figure out how long the note to typeset should be. It should be no
+ longer than what's specified, than what is left to do and it should
+ not cross barlines.
+
+ We copy the events into scratch note events, to make sure that we get
+ all durations exactly right.
+*/
+
+class Completion_rests_engraver : public Engraver
+{
+ vectorGrob * rests_;
+ vectorGrob * prev_rests_;
+
+ vectorStream_event * rest_events_;
+
+ Moment rest_end_mom_;
+ bool is_first_;
+ Rational left_to_do_;
+ Rational do_nothing_until_;
+
+ Moment next_barline_moment ();
+ Grob *make_rest (Stream_event *);
+
+ int start_measure_;
+
+
+public:
+ TRANSLATOR_DECLARATIONS (Completion_rests_engraver);
+
+protected:
+ virtual void initialize ();
+ void start_translation_timestep ();
+ void process_music ();
+ void stop_translation_timestep ();
+ DECLARE_TRANSLATOR_LISTENER (rest);
+};
+
+void
+Completion_rests_engraver::initialize ()
+{
+ is_first_ = false;
+ start_measure_ = 0;
+}
+
+IMPLEMENT_TRANSLATOR_LISTENER (Completion_rests_engraver, rest);
+void
+Completion_rests_engraver::listen_rest (Stream_event *ev)
+{
+ rest_events_.push_back (ev);
+
+ is_first_ = true;
+ Moment now = now_mom ();
+ Moment musiclen = get_event_length (ev, now);
+
+ rest_end_mom_ = max (rest_end_mom_, (now + musiclen));
+ do_nothing_until_ = Rational (0, 0);
+}
+
+/*
+ The duration _until_ the next bar line.
+*/
+Moment
+Completion_rests_engraver::next_barline_moment ()
+{
+ Moment *e = unsmob_moment (get_property (measurePosition));
+ Moment *l = unsmob_moment (get_property (measureLength));
+
+ if (!e || !l || !to_boolean (get_property (timing)))
+return Moment (0, 0);
+ else
+return (*l - *e);
+}
+
+Grob *
+Completion_rests_engraver::make_rest (Stream_event *ev)
+{
+ Grob *rest = 0;
+ if (*unsmob_moment (ev-get_property (length))
+ % *unsmob_moment (get_property (measureLength)) == Moment (0, 0))
+{
+ rest = make_spanner (MultiMeasureRest, ev-self_scm ());
+ start_measure_ = scm_to_int (get_property (internalBarNumber));
+}
+ else
+{
+ rest = make_item (Rest, ev-self_scm ());
+ Pitch *pit = unsmob_pitch (ev-get_property (pitch));
+
+ if (pit)
+ {
+ int pos = pit-steps ();
+ SCM c0 = get_property (middleCPosition);
+ if (scm_is_number (c0))
+ pos += scm_to_int (c0);
+ rest-set_property (staff-position, scm_from_int (pos));
+ }
+}
+ return rest;
+}
+
+void
+Completion_rests_engraver::process_music ()
+{
+ if (!is_first_ !left_to_do_)
+return;
+ is_first_ = false;
+
+ Moment now = now_mom ();
+ if (do_nothing_until_ now.main_part_)
+return;
+
+ Duration rest_dur;
+ Duration *orig = 0;
+ if (left_to_do_)
+{
+ rest_dur = Duration (left_to_do_, false);
+}
+ else
+{
+ orig = unsmob_duration (rest_events_[0]-get_property (duration));
+ rest_dur = *orig;
+}
+ Moment
Re: Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))
Hi David, For the record, I am appalled at David's etiquette -- which is to say, complete lack thereof Thanks for that important observation. It is likely to improve the quality of contributions. Choose your own response here: #1 if [by some fluke of mao] you're not being your usual sarcastic, condescending, and socially-inept self, and #2 if you're being your usual sarcastic, condescending, socially-inept self. #1. That's great! #2. It may not improve your interest in contributing -- which you appear to believe is the only way of improving the quality of contributions overall -- but it had a small chance of improving the interaction between you and the other Lilypond developers, which had a small chance of improving the flow of contributions into Lilypond, which had a small chance of improving the overall base code. Having my chains yanked is not something I deal with gracefully. Funny... I'm still waiting to see one thing that you *do* deal with gracefully. There is no shortage of them: they are easier to recruit than coders. I'd rather have a civil community built around an excellent but slightly-defective and slowly-improving Lilypond than an uncivil bitchfest built around an excellent but only-slightly-less-defective and slight-more-quickly-improving Lilypond, which is what you are in danger of fostering. Regards, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Multiline score patch
On 5/3/10 8:40 AM, Neil Puttock n.putt...@gmail.com wrote: On 3 May 2010 15:04, Carl Sorensen c_soren...@byu.edu wrote: I've reviewed the patch; the only problems I see are minor indentation and formatting issues. I'm surprised, because the patch set says it's 2 months old, but I can't find any reference to issue 207105 in the -devel or the -user archives. So this is the first time I've known that the patch is available for review. If I've missed it, I'm sorry. See this thread: http://lists.gnu.org/archive/html/bug-lilypond/2010-02/msg00150.html Thanks, Neil. I'm not sure why Gmane didn't find it. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ousting bad people
There are undoubtedly others that feel the same way. There is no shortage of them: they are easier to recruit than coders. Please, PLEASE! All parties, calm down! Meanwhile the list members should know how to tackle David; basically, I don't see hostility in his replies but rather the wish to improve lilypond. He provides valuable input; sitting on the side and arguing about his (well, usually pointed) tone is not helpful IMHO. On the other hand, you obviously have too much time, David, to write such long replies which often tend to be ad-hominem remarks, and your assumption that we don't value your contributions is plain wrong. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ousting bad people
Kieren MacMillan kieren_macmil...@sympatico.ca writes: [...] Having my chains yanked is not something I deal with gracefully. Funny... I'm still waiting to see one thing that you *do* deal with gracefully. There is no shortage of them: they are easier to recruit than coders. I'd rather have a civil community built around an excellent but slightly-defective and slowly-improving Lilypond than an uncivil bitchfest built around an excellent but only-slightly-less-defective and slight-more-quickly-improving Lilypond, which is what you are in danger of fostering. I am not in danger of fostering anything. Nobody considers me a role model, and I don't advertise myself as one. That's your job. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Page breaking fails for multiline embedded scorelocalhost/
Boris wrote: Right now, we start from the list of markups, and for-each markup, apply the markup function and destructively append! the resulting stencil to the result list under construction. The procedural nature of this design, is somewhat limiting in terms of expressive power. For what I am trying to do -- building a more flexible/general markup formatting facility -- the formatting of a markup may sometimes be context-controlled, i.e. formatting of the next piece of markup may depend on how the previous markups were formatted. For this, the design where the markup's stencil is completely defined by the single markup element in the list fed into interpret-markup-list, is not sufficient. One way to address it, is simply to pass another argument to the markup procedure, containing the context where we are along the way. A more elegant way is to do it in continuation passing style: the markup function, which represents one step in building of the stencils list, takes the tail of the markup list (the head is the current markup function itself) and the partially-built list of stencils, formats the current piece pf markup, tucks it on to to the stencils-list being built, and tail-recursively executes the rest of the markup with list of stencils grown by the just-now-formatted stencil. This way, each step can reason about what has been already built, looking backward (although only in terms of stencils), and what is yet to be built, looking forward (although only in terms of markups). I'm not sure what you have in mind here, but I would agree with this being a more elegant way of doing it. I always look at ! functions in Scheme as something that would be best avoided if possible, because there's generally a more expressive way to do things that avoids the ! function. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't hardcode a limited set of markup signatures. (issue969046)
On 5/3/10 5:01 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Just for the record: I am ok with the current form of the patch. Would anybody else care to review this before it gets pushed? http://codereview.appspot.com/969046/show Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
our development mess
On Mon, May 03, 2010 at 05:16:09PM +0200, Werner LEMBERG wrote: Please, PLEASE! All parties, calm down! Meanwhile the list members should know how to tackle David; basically, I don't see hostility in his replies but rather the wish to improve lilypond. Agreed on both points. Look, lilypond development is a mess: - we have way too few people reviewing patches; people are lucky if somebody glances at it within a week. - we have a mixture of programming languages. - the code base is complicated, with many parts that even Han-Wen and Jan say are garbage. - much of the code isn't documented. - we don't even agree about code formatting (in various languages), and/or the code formatting isn't documented. I suspect that a portion of patches that are accepted only get in because we don't notice the formatting problems. - contributors understandably squeamish about trying to review patches in areas they haven't looked at, and even more squeamish about trying to fix bugs in those areas. - we'll be passing 400 open issues soon, with no indication that we'll soon start closing more issues than opening them. In short, we need a loan from the IMF to get our issue-debt+deficit under control. (err, if people read this in the archives in a few months and don't get it, I'm making a joke about the Greece financial meltdown in April 2010) - the build system is horribly out of date and consists of more duct tape than original material. - we had a thousand-hour Grand Documentation Project to train people to handle docs so I could work on other stuff, but a year after GDP, I was back to being the main doc person. On the other hand, we're better off than we were a year ago: - due to the Frogs, we have a growing number of people reviewing patches and working on issues. I said *growing*, not *growed*. We still have a critical shortage of really knowledgeable developers (and/or a shortage of time/energy from knowledgeable developers), but at least we're moving in the right direction. - new issues sometimes get patches fairly quickly; our issue deficit is going down. Even better is that the higher-priority issues are getting more attention. - we have regular releases. - the two new doc editors show no indication of wanting to run off and learn scheme and work on new features, so I'm hopeful that by the end of the year I can start working on code bugs. The question is now what's the best way to improve things? There's a lot of things we could try. Many people want to talk about syntax and input file formatting; we could start GLISS. There's a lot of jobs that normal users could handle to free up developer time for other tasks; we could start GOP to recruit them. The build system needs a complete overhaul; we could start the 100+ hour task of writing a new build system. We could start modifying/writing a python or scheme program to handle source code formatting so that at the very least we can stop wasting time arguing about that stuff. We could try to think of ways to encourage more people to review patches... maybe turn it into a game, maybe make a concerted effort to encourage *everybody* to review patches and ask any questions, even silly ones, and be super-polite to any scheme newbies who ask stupid questions about a patch, etc... etc. At the moment, though, I think the best way to improve things is to put all that on hold and get 2.14 out the door. Limp along with the current system, with all its faults, for another few weeks. Once 2.14 is out (well, maybe 2.14.1) and things seem settled down, *then* we can start a big discussion about project management. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ousting bad people
Werner LEMBERG w...@gnu.org writes: On the other hand, you obviously have too much time, David, to write such long replies I wish I did. So you suggest I'd rather _not_ make point-to-point replies to negative reviews and hope that eventually somebody else figures out that the points are not valid with respect to the reviewed code? Fat chance. But anyway, ignoring a negative review basically _was_ my second attempt after commenting the original code did not help _anything_ at all (and nothing Han-Wen wrote would suggest he even looked at the comments I wrote to address his concerns): I completely junked the whole verification and moved its functionality elsewhere, in a different language, because the first reply made clear that there was no chance that I could get the C++ code doing the task in the most straightforward and efficient way matched to the task at hand accepted before blowing my top. So I scrapped the whole thing (pretty annoyed because it was already working perfectly and documented extensively _on_ request) rather than bothering to argue about it, and it helped exactly zilch. After three iterations, one of them a complete change of strategy, nothing in the reviews suggests that anything but the very first version was even being looked at. Do you really think I have the time to spare to do three times the necessary work without people even noticing? No, I haven't. I also don't have the time to rant and have everybody spit on me. But I was pretty much out of other options. I know _no_ other project that makes it so absurd and hard to be permitted to contribute. There are double standards for insiders and outsiders, and it is hell for outsiders to get anything but trivial code accepted. Most other people just go away, or they behave themselves long enough (or don't venture beyond trivial code long enough) to become insiders. I prefer getting work _done_, but it does not seem like this option is available to me within this project. I'll likely stop using the Rietveld process since it restricts reviews mostly to inside people with Google accounts, and is mostly not making people actually try out the code. Instead I'll just post patches on the list again. git is tailored to this workflow and it's dead easy to let it process patch series with git am, in a different branch or otherwise. Perhaps that will lead to a more diversified response. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: syntax change for \cresc
Am Montag, 26. April 2010 22:29:21 schrieb Carl Sorensen: On 4/26/10 2:24 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Am Sonntag, 25. April 2010 14:10:40 schrieben Sie: Should I say that it would be useful for many people to see this in the LSR and in the doc? Yes, I totally understand. However, the LSR is (still?) based on lilypond 2.12, so it's not possible to submit it there currently. And when it switches to 2.13, probably noone will remember submitting such snippets that show new functionality... But you can put it in Documentation/snippets/new right now, and it will go into the LSR when it's upgraded to 2.14, can't you? I already added the two snippets documenting postfix dynamic text spanners to Documentation/snippets/new back in August, when I committed the backend functionality (see commit a1fa0e63b1bf2c61a9c19a33b7034989fb3fac05 on 22.08.09 00:47). So, let's just hope that someone will take care of adding all those snippets to the lsr once it gets updated... Cheers, Reinhold PS: Thanks for reminding me about snippets/new, even though things were already done in this case. I have completely forgotten by now, and would not have added other new snippets there... -- -- 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] Re: syntax change for \cresc
2010/5/3 Reinhold Kainhofer reinh...@kainhofer.com: Yes, this is the way around the issue. BTW, I pushed that patch a minute ago. Seen it. BTW sorry for having polluted this thread with my selfish considerations about custom dynamics or text aligned on dynamics. This (and my syntax suggestions) should have waited for the GLISS. Thanks Reinhold for your great work. Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: syntax change for \cresc
Dear Xavier, Am Montag, 3. Mai 2010 22:40:01 schrieb Xavier Scheuer: 2010/5/3 Reinhold Kainhofer reinh...@kainhofer.com: Yes, this is the way around the issue. BTW, I pushed that patch a minute ago. Seen it. BTW sorry for having polluted this thread with my selfish considerations about custom dynamics or text aligned on dynamics. No, I don't accept your apologies ;-) To the contrary: It is important to discuss stuff! After all, it is quite possible to have a civilized discussion here on lilypond-devel (even though at times things seem to heat up unnecessarily). Just because someone suggests something different from what I'm proposing doesn't mean he is wrong or that he tries to diminish the value of my thoughts or my work. To the contrary, your comments made me think once again how the commands are exactly supposed to work. In this case, I had good facts (and thus good arguments). In other cases, I don't, and then we can find a solution together. This (and my syntax suggestions) should have waited for the GLISS. No, in this particular case, it was better to clear up all confusion now, since they are quasi-new commands (undocumented/unsupported before, so we could easily change them...). 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
Rietveld review (was: markup-command and markup-command-list signatures)
On 5/3/10 1:02 AM, David Kastrup d...@gnu.org wrote: I don't see that you stand a chance with the standard processes here. You don't have commit access. The gold standard here (to the exclusion of all other workflows) is a patch review on Rietveld. That basically limits feedback to persons with a Google developer account. I don't have a Google developer account. I did need to use a gmail account. So yes, if you want to comment, you need to have some kind of google account. But I didn't find it difficult to establish a gmail account and have that account forward mail to my standard email address. At the point of acceptance, the change is pulled in as a single commit touching lots of areas simultanously. Since mainline development continues, there is no sensible strategy for merging/rebasing for anybody without a branch history. So the only person able to work on this will be yourself. People will be able to check your work only when the patch set applies. But that means that mainline changes in the same areas need to be tracked by you and will also pollute the Rietveld review area. Mainline changes don't need to pollute the Rietveld review area. The post to Rietveld is in the form of a git diff, and you are free to specify any commit as the head point for the diff. It's pretty simple to do the work in git, and merge/rebase with the main tree as necessary, and use git-cl to upload the diff of where your branch diverges from the main branch. I haven't had problems with this is the past. I'm not saying they don't exist (it's impossible to prove a negative), but in my experience the system works pretty well. I don't see that a task like this can be sensibly done except in a separate branch. But working like that is a git workflow rather than a Subversion one, and does not fit with the Rietveld processes. Of course you can set up your own Lilypond repository for pulling, but the way I see it, the relevant developers would refuse to participate in non-standard processes like that. In the past we have had developers with an individual branch hosted on Savannah that were not part of the main tree; we didn't find them useful. Why do you need to set up your own Lilypond repository for pulling? Why not just create a branch in your local repository and go ahead and do the rebase/merge as necessary? I don't see that humongous changes like that can be usefully integrated in a single non-merge commit. I don't understand this emphasis on a single non-merge commit. If you want to propose a patch set that requires multiple commits, you can do so. It won't show up on Rietveld that way, but you can email a patch as a series of commits leading of the main trunk. There must be infrastructure changes and so on, and you'll need to set up reviews for each of them, without an apparent goal being accomplished before the last commits make it. I agree that this can be an issue. Infrastructure changes that are not needed are asked to be postponed until the need is apparent. But they're not rejected. Basically you'll be on your own going against the tide until you are finished. The work flows here are designed to achieve code quality by making it harder for a would-be contributor to get sub-par code through, not by making others participate with the work. I think this is an interesting comment. Do you believe that it would be preferable to let sub-par code through? Or do you believe that there are other workflows that would be as effective at blocking sub-par code but would be more inviting to a new contributor? This is a serious question I'd like to ask you. If you were the king of LilyPond, what would you establish as the workflow? I'd really like to hear your opinion. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nasty header positioning issues
Neil Puttock n.puttock at gmail.com writes: It looks like \vspace has horizontal extent, which is skewing the text string. Thomas morgan fixed the analogous problem with hspace earlier. Patch posted on Rietveld: http://codereview.appspot.com/40122 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: LM: Reformat ly code.
Trevor Daniels wrote: I think we should always use bar-checks when the piece is more than one bar long. That's a good habit to get into; we ought to start it right from the first. I would agree with this. In fact I put bar checks into quite a few of the examples in the LM originally, but they seem to have been removed. Perhaps the reason for removing the bar checks was that they're not explained at all in the LM. Do you think we should mention bar checks (briefly) near the beginning of the LM, without going into detail? Then we'd be justified using them in the examples. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: LM: Reformat ly code. (issue1056041)
http://codereview.appspot.com/1056041/diff/1/2 File Documentation/learning/common-notation.itely (right): http://codereview.appspot.com/1056041/diff/1/2#newcode101 Documentation/learning/common-notation.itely:101: aeses1 On 2010/05/03 14:19:08, Graham Percival wrote: On 2010/05/03 13:48:52, Carl wrote: Perhaps we could just change the durations in this to 4, and we wouldn't even be having a discussion. Already thought of that, but the 1 durations are so that we avoid having cancellation naturals. And we definitely don't want to add \override Voice #'accidental-cancelletional = ##f (or whatever the command is) here! We don't have a key signature, and the notes aren't repeated , so there aren't any cancellations in this snippet. I just ran it to make sure. In Notation, we had a cancellation problem with chords, which caused us to use whole notes. But I don't think that applies here. THanks, Carl http://codereview.appspot.com/1056041/diff/1/2#newcode253 Documentation/learning/common-notation.itely:253: b'2 a4 cis,\) On 2010/05/04 04:41:46, Mark Polesky wrote: Bar checks have not yet been introduced in the text. I'd like to rewrite it using a single measure. Would you be okay with this? g4\( g8( a) b( c) b4\) Absolutely, as long as it looks reasonable. But I think we should focus on *good examples* here, not *good source code formatting*. So since bar checks haven't been introduced, I withdraw all my suggestions about bar checks. http://codereview.appspot.com/1056041/diff/1/2#newcode271 Documentation/learning/common-notation.itely:271: fis2 g) On 2010/05/04 04:41:46, Mark Polesky wrote: On 2010/05/03 13:48:52, Carl wrote: Same comment as for the previous snippet. Okay to change it to this single measure example? c4~( c8 d~ d4 e) I haven't compiled it, but I think a short example is better than a long example. http://codereview.appspot.com/1056041/diff/1/2#newcode365 Documentation/learning/common-notation.itely:365: c2 c\! On 2010/05/04 04:41:46, Mark Polesky wrote: On 2010/05/03 13:48:52, Carl wrote: See my comment at line 289 Can I make them all quarter notes? Absolutely, as far as I'm concerned. Unless the spacing gets too close... http://codereview.appspot.com/1056041/diff/1/2#newcode982 Documentation/learning/common-notation.itely:982: d4 b8 g4. On 2010/05/04 04:41:46, Mark Polesky wrote: On 2010/05/03 13:48:52, Carl wrote: Bar checks here. Pedagogically, it may be nice to have the notes and the lyrics have lines of the same length. Bar checks have still not been explained at this point. WRT the lyrics line lengths, I thought about it, but the *poetic* meter gets mangled by the *musical* meter. Maybe this makes it easier to see the note/word correspondence, but it just looks weird: No, you misunderstood my request. I don't want to change the lyrics, I want to change the notes. Put one lyric line's worth of notes on a line. And go ahead and omit the bar check. The pedagogy here should be focused on getting lyrics to align with notes, not on proper formatting for LilyPond files. Let that pedagogy trump for each of these Learning examples; add a section for style that explains the recommended style for complex music. http://codereview.appspot.com/1056041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: LM: Reformat ly code. (issue1056041)
http://codereview.appspot.com/1056041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nasty header positioning issues
It looks like \vspace has horizontal extent, which is skewing the text string. Thomas morgan fixed the analogous problem with hspace earlier. Patch posted on Rietveld: http://codereview.appspot.com/40122 Are you sure this is a link to the right patch set? I see nothing related in the description. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nasty header positioning issues
On 5/3/10 11:23 PM, Werner LEMBERG w...@gnu.org wrote: It looks like \vspace has horizontal extent, which is skewing the text string. Thomas morgan fixed the analogous problem with hspace earlier. Patch posted on Rietveld: http://codereview.appspot.com/40122 Are you sure this is a link to the right patch set? I see nothing related in the description. Oops. I made a mistake an pasted the wrong link. I'm sorry. Try this one instead: http://codereview.appspot.com/1089041 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nasty header positioning issues
Try this one instead: http://codereview.appspot.com/1089041 Thanks. Is this change sufficient? Or does the presence of this token (I mean the \vspace itself, regardless of its dimensions) trigger an insertion of a space between this and the next element of the argument list of fill-line? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
