Re: sustainable development in LilyPond
Graham Percival wrote Tuesday, August 03, 2010 3:31 AM As you might recall, I gave a talk at RMLL 2010 about sustainable development in F/OSS. Nice talk. It prompted me to think about my own involvement with LilyPond. I volunteered for doc development due to the guilt pressure at the start of GDP, IIRC. I continued because I enjoyed it, spending around a year working several hours most days on the LM. Eventually pressure of other things which I'd been neglecting caused me to back off, and recurring RSI prevents long sessions at the keyboard, so now I do little more than keep in touch :( On the main point I can see two dangers to sustainability. 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that only experienced and expert coders able to deduce the design from the source code are able to contribute significantly, ensuring high quality. But there are very few such people, and it is conceivable the number might decline to zero at some point. 2) There is no overall design plan to guide future development. New features are added in an ad hoc fashion at the whim of individual developers. The danger is that the overall structure will lose coherence, properties will increasingly behave in inconsistent ways, and the complexity of the user interface and the barriers to new developers will increase. At present we rely on Neil and other core developers to maintain the integrity of the design by reviewing patches, but that is not guided development. We have an opportunity within GLISS and GOP to tackle these dangers, although their terms of reference would need to be widened to embrace them. GLISS would need also to consider future needs and how they would be accommodated in the input syntax, and GOP would have to break down the barriers which new developers currently have to overcome themselves. Trevor Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote: > > 1) There is no architectural overview and no program logic manual to > guide new developers through the early stages. > This has the advantage that No; there's no advantage to this. It's simply due to an imbalance of high skill, available time/interest, and an overwhelming number of other concerns. I'm quite aware of the problems that this causes for new developers, but as long as we have over 10 patches waiting for review for the past few months, the current bottleneck is *not* in the initial "getting started" stages. The current bottleneck is reviewing patches. The CG section on programming has been improving slowly but surely, as have the Frogs. I wish that we had more Frogs submitting doc patches to the CG explaining the stuff they've learned instead of leaving that task to the already over-burdened Carl, but I didn't think it was worth raising this point directly. > 2) There is no overall design plan to guide future development. > New features are added in an ad hoc fashion at the whim of individual > developers. The danger is that the overall structure will lose > coherence, properties will increasingly behave in inconsistent ways, and > the complexity of the user interface and the barriers to new developers > will increase. > At present we rely on Neil and other core developers to > maintain the integrity of the design by reviewing patches, > but that is not guided development. This part and parcel with the general way that volunteer open-source projects work, though. Projects with large commercial backing (like mozilla and openoffice.org) can give a roadmap with the knowledge that they have 20/50/100 developers to assign as they wish. Even something as "simple" as documentation writing was a huge challenge to manage for the guided development in GDP. I can't imagine any such system working in lilypond [1]. [1] the single exception would be if we got a 50,000+ research grant to do some notation project. But that's not at all likely, and I can't see this working with individual donations. I'm comfortable with the "herding cats" style. Most of the time, we let people wander around at will; once in a while, we'll have a Grand Project that attempts to capture people's imagination and make them all move in (approximately) the same direction. > We have an opportunity within GLISS and GOP to tackle these > dangers, although their terms of reference would need to be > widened to embrace them. GLISS would need also to consider > future needs and how they would be accommodated in the > input syntax, and GOP would have to break down the barriers which new > developers currently have to overcome themselves. This is possible, but I don't think it's realistic. In particular, it would need: 1. a large amount of developer time being placed under the control of a benevolent dictator (or council of dictators), and 2. the "mundane" development tasks to be sustainable, and to have enough effort to cover those tasks without needing to distract any minions working on #1. I'd say that we're at least a year away from having sustainable mundane tasks... the Bug Squad will probably be sustainable in 2-4 months, but GDP utterly failed at creating a sustainable doc team, and I'm not certain if anybody in the world other than Jan and me can build releases. (I know that Patrick's been working on some stuff, but I don't know if he can build everything) However, IMO we shouldn't be fussing too much about these long-term issues until 2.14 is out. We need a stable foundation. (it's a bit unfortunate that the talk was when it was) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Graham Percival wrote Wednesday, August 04, 2010 9:41 AM On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote: 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that No; there's no advantage to this. It's simply due to an imbalance of high skill, available time/interest, and an overwhelming number of other concerns. I'm quite aware of the problems that this causes for new developers, but as long as we have over 10 patches waiting for review for the past few months, the current bottleneck is *not* in the initial "getting started" stages. The current bottleneck is reviewing patches. That's true; but I didn't say this was a current bottleneck, I said it was a danger to sustainability, the topic we were discussing. The CG section on programming has been improving slowly but surely, as have the Frogs. I wish that we had more Frogs submitting doc patches to the CG explaining the stuff they've learned instead of leaving that task to the already over-burdened Carl, but I didn't think it was worth raising this point directly. I think it is worth pushing. Most of LM 3 was written as I learned how to use the IR. It doesn't matter if a doc patch is incorrect - it would almost certainly illicit a rapid response from a core developer and we would all learn. 2) There is no overall design plan to guide future development. New features are added in an ad hoc fashion at the whim of individual developers. The danger is that the overall structure will lose coherence, properties will increasingly behave in inconsistent ways, and the complexity of the user interface and the barriers to new developers will increase. At present we rely on Neil and other core developers to maintain the integrity of the design by reviewing patches, but that is not guided development. This part and parcel with the general way that volunteer open-source projects work, though. I know. It is probably the greatest defect of OSP. Projects with large commercial backing (like mozilla and openoffice.org) can give a roadmap with the knowledge that they have 20/50/100 developers to assign as they wish. True and of course we can't do this. But we could set out some desirable directions and goals. Consistently thought-out ones, rather than individual feature requests. If such a roadmap existed it might prompt contributors, frogs even, to work on those items. We have an opportunity within GLISS and GOP to tackle these dangers, although their terms of reference would need to be widened to embrace them. GLISS would need also to consider future needs and how they would be accommodated in the input syntax, and GOP would have to break down the barriers which new developers currently have to overcome themselves. This is possible, but I don't think it's realistic. In particular, it would need: 1. a large amount of developer time being placed under the control of a benevolent dictator (or council of dictators), and Yes. All the most successful OSP have this. 2. the "mundane" development tasks to be sustainable, and to have enough effort to cover those tasks without needing to distract any minions working on #1. I'd say that we're at least a year away from having sustainable mundane tasks... the Bug Squad will probably be sustainable in 2-4 months, but GDP utterly failed at creating a sustainable doc team, Don't run this down. The docs were immeasurably improved by GDP. This was beneficial dictatorship in action. It was and still is unrealistic to expect people to work several hours a day on LP for more than a year or so (with one or two dedicated exceptions). So the goal should be to accommodate a flow of people coming in, working a while, and then leaving. So we have to make it as easy as possible for newcomers to contribute easily and quickly, to both docs and development. The concept of permanent teams is fine, but not teams with permanent members - there will always be a flow. However, IMO we shouldn't be fussing too much about these long-term issues until 2.14 is out. We need a stable foundation. (it's a bit unfortunate that the talk was when it was) OK, agreed. I've made my comments while they were in my mind. I'll back off now. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
"Trevor Daniels" writes: > 1) There is no architectural overview and no program logic manual to > guide new developers through the early stages. > This has the advantage that only experienced and expert > coders able to deduce the design from the source code are > able to contribute significantly, ensuring high quality. I consider that reverse logic. The problem is that you are likely to have people reinventing the wheel, leading to a loosely connected garden of code written by x, code written by y where everybody has his own ways and subroutines for solving particular subtasks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
David Kastrup wrote Wednesday, August 04, 2010 11:27 AM "Trevor Daniels" writes: 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that only experienced and expert coders able to deduce the design from the source code are able to contribute significantly, ensuring high quality. I consider that reverse logic. The problem is that you are likely to have people reinventing the wheel, leading to a loosely connected garden of code written by x, code written by y where everybody has his own ways and subroutines for solving particular subtasks. Yes; I worded it badly. I meant, "The only advantage this has is that ...". You correctly point out the outweighing disadvantages. It was clear, I hope, that I am advocating better documentation, not less. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Which css file should the new web be using?
Graham While looking into the @help in download.itexi (the font size used for smallexample) I noticed that the css file currently being used to build the web is css/lilypond-web.css. Is this correct? The css title is "Patrick McCarty's design" and there is a beautifully-laid out css file called css/lilypond-mccarty.css, but this seems not to be used. Patrick's file has entries for smallexample but lilypond-web does not. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch-reviewing and the i-ching (was Re: sustainable development in LilyPond)
On 8/4/10 1:25 PM, "Trevor Daniels" wrote: > > David Kastrup wrote Wednesday, August 04, 2010 11:27 AM > > >> "Trevor Daniels" writes: >> >>> 1) There is no architectural overview and no program logic manual >>> to >>> guide new developers through the early stages. >>> This has the advantage that only experienced and expert >>> coders able to deduce the design from the source code are >>> able to contribute significantly, ensuring high quality. >> >> I consider that reverse logic. The problem is that you are likely >> to >> have people reinventing the wheel, leading to a loosely connected >> garden >> of code written by x, code written by y where everybody has >> his own >> ways and subroutines for solving particular subtasks. > > Yes; I worded it badly. I meant, "The only advantage this has > is that ...". You correctly point out the outweighing > disadvantages. > > It was clear, I hope, that I am advocating better documentation, > not less. > > Trevor I am a bit lost with respect to what has to be done and who's working on what, but I've been chipping away as best I can on issues that, to me, seem under-commented-upon. I think that Graham's sustainable development presentation is excellent, especially the part about swag, as I am moving from a wine-drinking country to a beer-drinking country in two weeks and could use a lilypond bottle opener. In parallel to what he says, I feel that another way to get things done on a more short-term basis (i.e. before 2.14 and before Graham puts a sustainable plan into place) is to randomly assign issues to willing participants via a lottery. Said participant would then be responsible for stewarding the issue until resolution, which could involve anything from coordinating efforts on an untouched problem to simply running a test on a patch that is quite evolved and signaling to one of the developers that it is ready to be pushed. It would also be a great way for new folks (like me) to learn - I chose to work on issue 1173 at pseudo-random (Python's random library) and learned a great deal in doing so. If there is sufficient interest in this idea, I think it would be a good way for newcomers and experienced lilyponders alike to move forward with outstanding issues. ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Which css file should the new web be using?
On Wed, Aug 04, 2010 at 12:45:09PM +0100, Trevor Daniels wrote: > While looking into the @help in download.itexi (the font size used for > smallexample) Only if you're certain that it shouldn't be fixed in the texinfo, btw. I mean, it might be better to rewrite something, or end the itemized list sooner, or something like that. > I noticed that the css file currently being used to build the > web is css/lilypond-web.css. Is this correct? This is correct. Patrick has worked on lilypond-web.css > The css title is "Patrick McCarty's design" and there is a > beautifully-laid out css file called css/lilypond-mccarty.css, > but this seems not to be used. I believe that this file was left-over from GDP. Nobody bothered cleaning up the 5 or 6 css files we had at the end of it, and when I started the new website, I just started a new one. We have an open issue for "clean up all our css files", which would start by figuring out which ones are actually used or not. > Patrick's file has entries for smallexample but > lilypond-web does not. I'm quite willing to believe that bits and pieces of useful info has been lost in all the css games we've played, and with the lack of any interested party seriously taking care of css. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch-reviewing and the i-ching (was Re: sustainable development in LilyPond)
On Wed, Aug 04, 2010 at 02:33:30PM +0200, Mike Solomon wrote: > I am a bit lost with respect to what has to be done and who's working on > what, but I've been chipping away as best I can on issues that, to me, seem > under-commented-upon. In theory, the Status:Started, Owner:foo indicates that. In some cases, it only indicates that foo is responsible for shepherding it. Exceptions: we don't always keep those updated, and anything marked with percival.music.ca or Valentin is likely to be a historical inaccuracy. > I think that Graham's sustainable development presentation is excellent, > especially the part about swag, btw, adapted from http://www.daemonology.net/blog/2009-07-14-a-call-for-schwag.html > In parallel to what he says, I feel that another way to get things > done on a more short-term basis (i.e. before 2.14 and before Graham puts a > sustainable plan into place) is to randomly assign issues to willing > participants via a lottery. I don't think we need any policy change to deal with 15 issues (expected: 30 Criticals before 2.14). In fact, any change is likely to result in mythical-man-month problems. On an individual basis, it would be great if you chose a few Critical issues to investigate, make comments, and maybe even produce a patch. The balance of "investigate new Critical issues vs. review a patch for a low-priority enhancement" is a tricky one, but I'd like to encourage people to do more patch-reviewing and *less* work on new (or un-investigated) issues. Yes, this delays 2.14, but I think that having better discussion of post-initial-patch development effort will pay off more in the long run. My hope is that Marek (the guy who adds ignored patches to the tracker) job is supposed to be a failsafe -- he should have nothing to do. Once a patch is sent to lilypond-devel, we should have a discussion starting within 3 days, and continue discussing it until the patch is committeed or withdrawn. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Which css file should the new web be using?
On Wed, Aug 4, 2010 at 4:45 AM, Trevor Daniels wrote: > > While looking into the @help in download.itexi (the font size used for > smallexample) I > noticed that the css file currently being used to > build the web is css/lilypond-web.css. Is this > correct? The css title is "Patrick McCarty's design" > and there is a beautifully-laid out css file called > css/lilypond-mccarty.css, but this seems not to be used. The file "lilypond-mccarty.css" is used for the docs (everything except the website), and "lilypond-web.css" is used for the website. There is quite a bit of overlap between the two CSS files, and as Graham mentioned, combining them into one CSS file would be an ideal solution. > Patrick's file has entries for smallexample but > lilypond-web does not. We did do some copy-and-paste between CSS files about a year ago, IIRC, so "smallexample" must have been overlooked. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds announce-end-grob to engraver-scheme.cc (issue1914043)
LGTM, pushed to master. Cheers, Neil http://codereview.appspot.com/1914043/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Scheme binding for announce_end_grob
On 2 August 2010 13:35, Mike Solomon wrote: > http://codereview.appspot.com/1914043 Applied: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=4ed35e481389eaddd6e07002f0b5ccad31994169 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds scheme binding for Side_position_interface::set_axis (issue1880050)
On 2010/08/03 09:57:27, MikeSol wrote: I created a binding for chain_callback in grob-scheme.cc. Please see http://codereview.appspot.com/1890044 . I'm fine using this and then maybe making a scheme version of set_axis (i.e. side-position-interface::set-axis) in the appropriate .scm file. First, let me know if this is what you had in mind. That's exactly what I was thinking. Once we're using Guile 2.0 we might even contemplate moving chain_callback to scheme too (all it needs is a slight tweak to property checking and a binding for simple_closure_expression). Cheers, Neil http://codereview.appspot.com/1880050/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Create ly:grob-chain-callback from chain_callback (issue1890044)
http://codereview.appspot.com/1890044/diff/1/2 File lily/grob-scheme.cc (right): http://codereview.appspot.com/1890044/diff/1/2#newcode407 lily/grob-scheme.cc:407: 3, 0, 0, (SCM grob, SCM proc, SCM sym), 0, (SCM grob http://codereview.appspot.com/1890044/diff/1/2#newcode415 lily/grob-scheme.cc:415: LY_ASSERT_SMOB (Grob, grob, 1); + LY_ASSERT_TYPE (ly_is_procedure, proc, 2); http://codereview.appspot.com/1890044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
joining the frogs?
Hello. I'd like to join the Frogs but my mailing list subscription hasn't gone through. Is it just a matter of waiting for someone's manual input, or is something wrong with the listserv? - William Bajzek williambaj...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Create ly:grob-chain-callback from chain_callback (issue1890044)
Reviewers: Neil Puttock,
http://codereview.appspot.com/1890044/diff/1/2
File lily/grob-scheme.cc (right):
http://codereview.appspot.com/1890044/diff/1/2#newcode407
lily/grob-scheme.cc:407: 3, 0, 0, (SCM grob, SCM proc, SCM sym),
On 2010/08/04 18:50:59, Neil Puttock wrote:
0, (SCM grob
Done.
http://codereview.appspot.com/1890044/diff/1/2#newcode415
lily/grob-scheme.cc:415: LY_ASSERT_SMOB (Grob, grob, 1);
On 2010/08/04 18:50:59, Neil Puttock wrote:
+ LY_ASSERT_TYPE (ly_is_procedure, proc, 2);
Done.
Description:
Create ly:grob-chain-callback from chain_callback
Create ly:grob-chain-callback from chain_callback
Whitespace fix
Please review this at http://codereview.appspot.com/1890044/show
Affected files:
M lily/grob-scheme.cc
Index: lily/grob-scheme.cc
diff --git a/lily/grob-scheme.cc b/lily/grob-scheme.cc
index
199e6fb9b3410da8d6355aaea07782577f170223..c27a9ee8bdab5ff3dbe941a0e9bc6533857ca264
100644
--- a/lily/grob-scheme.cc
+++ b/lily/grob-scheme.cc
@@ -402,3 +402,20 @@ LY_DEFINE
(ly_grob_common_refpoint_of_array, "ly:grob-common-refpoint-of-array",
Grob *refp = common_refpoint_of_array (ga->array (), gr, Axis
(scm_to_int (axis)));
return refp ? refp->self_scm () : SCM_BOOL_F;
}
+
+LY_DEFINE (ly_grob_chain_callback, "ly:grob-chain-callback",
+ 3, 0, 0, (SCM grob, SCM proc, SCM sym),
+ "Find the callback that is stored as property"
+ " @var{sym} of grob @var{grob} and chain @var{proc}"
+ " to the head of this, meaning that it is called"
+ " using @var{grob} and the previous callback's result.")
+{
+ Grob *gr = unsmob_grob (grob);
+
+ LY_ASSERT_SMOB (Grob, grob, 1);
+ LY_ASSERT_TYPE (ly_is_procedure, proc, 2);
+ LY_ASSERT_TYPE (ly_is_symbol, sym, 3);
+
+ chain_callback (gr, proc, sym);
+ return SCM_UNSPECIFIED;
+}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: joining the frogs?
nevermind, it seems to be working now. On Aug 4, 2010, at 12:54 PM, William Bajzek wrote: > Hello. I'd like to join the Frogs but my mailing list subscription hasn't > gone through. Is it just a matter of waiting for someone's manual input, or > is something wrong with the listserv? > > - William Bajzek > williambaj...@gmail.com > > > > - William Bajzek williambaj...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix for issue 1173 to fails when asked to showLastLength on partial measures. (issue1741060)
Reviewers: , Message: Hi Mike, Here are some general comments following testing: -) showFirstLength still doesn't work -) probably related to the above, but the combination of showFirstLength and showLastLength doesn't work -) if there's no time signature, showLastLength is ignored; this breaks several regtests (should assume 4/4 in this case) On a more serious note, I tested some real-world files, and one of them crashed with an infinite loop in libguile (I can post the file if it helps): Program received signal SIGSEGV, Segmentation fault. 0x77931bdc in ?? () from /usr/lib/libguile.so.17 (gdb) bt #0 0x77931bdc in ?? () from /usr/lib/libguile.so.17 #1 0x77932299 in ?? () from /usr/lib/libguile.so.17 #2 0x77932f90 in ?? () from /usr/lib/libguile.so.17 #3 0x77932299 in ?? () from /usr/lib/libguile.so.17 #4 0x7793231d in ?? () from /usr/lib/libguile.so.17 (etc.) Cheers, Neil Description: Fix for issue 1173 to fails when asked to showLastLength on partial measures. Fixes 1173 no error message rounds up to the next measure Patch from Mike Solomon. Please review this at http://codereview.appspot.com/1741060/show Affected files: M scm/define-woodwind-diagrams.scm M scm/lily-library.scm M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1173 to fails when asked to showLastLength on partial measures. (issue1741060)
http://codereview.appspot.com/1741060/diff/1/4 File scm/music-functions.scm (right): http://codereview.appspot.com/1741060/diff/1/4#newcode534 scm/music-functions.scm:534: (set! (ly:music-property m 'den) den) These should come from the music (which means you'll be needing a fix for issue #1198: \time requires a synthetic music object to generate the context property settings). We already have two music properties called `numerator' and `denominator' which could be used (it even appears that they might originally have had this purpose, judging by the docstrings, even though they're currently used for \times) http://codereview.appspot.com/1741060/diff/1/4#newcode932 scm/music-functions.scm:932: (define (generate-timing-alist music) needs a docstring (+ others below) http://codereview.appspot.com/1741060/diff/1/4#newcode936 scm/music-functions.scm:936: (define (time-helper music) Following a fix for #1198, this could be simplified http://codereview.appspot.com/1741060/diff/1/4#newcode1035 scm/music-functions.scm:1035: (integrated-measures This looks rather costly, since it will be called for all scores, even if show(First|Last)Length isn't set (skip-as-needed is a top-level music function, so it's applied automatically whenever the parser encounters music) http://codereview.appspot.com/1741060/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Enhancement: Internal ledger lines. (issue1855056)
what's the plan for this patch/functionality ? the code looks a bit out of style. would it be possible to group all the internal-ledger code together? Without wanting to trample on feet, this looks like a feature that could easily bitrot due to lack of use, so it's good to make it easy to remove again. http://codereview.appspot.com/1855056/diff/1/2 File lily/ledger-line-spanner.cc (right): http://codereview.appspot.com/1855056/diff/1/2#newcode52 lily/ledger-line-spanner.cc:52: Internal_ledgers () : halfspace_ (1) we usually do = 1 in the body. http://codereview.appspot.com/1855056/diff/1/2#newcode63 lily/ledger-line-spanner.cc:63: * is this a new coding style? - if not follow the rest of the code? http://codereview.appspot.com/1855056/diff/1/2#newcode87 lily/ledger-line-spanner.cc:87: return ledger_extent_.contains (pos / halfspace_); ? should be * rather than / http://codereview.appspot.com/1855056/diff/1/2#newcode146 lily/ledger-line-spanner.cc:146: Real &left_shorten); IIRC, we use pointers rather than refs for modifying arguments. http://codereview.appspot.com/1855056/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Internal ledger lines. (issue1855056)
Reviewers: hanwenn, Message: On 2010/08/04 21:44:58, hanwenn wrote: what's the plan for this patch/functionality ? the code looks a bit out of style. It's an old patch which Kevin Dalley posted ages ago: http://lists.gnu.org/archive/html/lilypond-devel/2007-03/msg00038.html I've removed the code relating to chromatic staves, since that was added separately (with a cleaner implementation). Cheers, Neil Description: Enhancement: Internal ledger lines. Please review this at http://codereview.appspot.com/1855056/show Affected files: M lily/ledger-line-spanner.cc M scm/define-grob-properties.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix 442. (issue1888042)
Hi Joe,
LGTM.
I'd be quite happy with this method, even though it loses a bit of
flexibility in comparison with your original patch.
Cheers,
Neil
http://codereview.appspot.com/1888042/diff/1/5
File lily/keep-alive-together-engraver.cc (right):
http://codereview.appspot.com/1888042/diff/1/5#newcode69
lily/keep-alive-together-engraver.cc:69: "All the
Hara_kiri_group_spanners that lie below "
Could this docstring be a bit more user-friendly?
http://codereview.appspot.com/1888042/diff/1/7
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/1888042/diff/1/7#newcode956
scm/define-grob-properties.scm:956: (keep-alive-with ,ly:grob-array? "An
array of other VerticalAxisGroups.
@code{VerticalAxisGroup}s
http://codereview.appspot.com/1888042/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
On 01/08/10 22:37, Patrick McCarty wrote:
> On Sun, Aug 1, 2010 at 2:02 PM, Neil Puttock wrote:
>> On 1 August 2010 21:49, Patrick McCarty wrote:
>>
>>> I think I found the problem.
>>>
>>> With Guile 1.9, `module-public-interface' doesn't return an interface
>>> for `the-scm-module', which we rely on:
>>>
>>> scheme@(guile-user)> (module-public-interface the-scm-module)
>>> $1 = #f
>>> scheme@(guile-user)>
>>>
>>> I'll report this upstream.
>>
>> OK. I was just about to reply, since I've seen that error using 1.8
>> (trying to use `resolve-interface' instead of
>> module-public-interface).
>
> This is quite interesting. :)
>
> I just did a little more research, and these three calls all return
> the same interface, but the last one doesn't work with Guile 1.9:
>
> guile> (resolve-interface '(guile))
> #
> guile> (module-public-interface the-root-module)
> #
> guile> (module-public-interface the-scm-module)
> #
> guile>
>
> So, it looks like we might want to do this:
>
> - SCM scm_module = ly_lily_module_constant ("the-scm-module");
> + SCM scm_module = ly_lily_module_constant ("the-root-module");
>
>
I'll ensure this change is in the next patch set for T1055.
À propos of which, I've just hacked things so it gets through the
regression tests without the call using %module-public-interface woot! :-).
However, to do this I've had to change one regression test and one other
.scm file used in initialization to add
(use modules (scm clip-region)).
It looks like the reason is that we have been using a side-effect of the
call to %module-public-interface to pick up a call to the above
use-modules in init.ly. It looks like the side-effect was pick up not
only the public interface (all the (define-public) declarations etc. of
the current module, but also all the public interfaces on the uses list
for the current module [i.e. our sole and only (scm clip-region)]. This
allowed us to code as if all the public scheme declarations in
clip-region.scm had been declared in lily.scm - but they weren't.
I have hacked two .scm files input/regression/clip-systems.ly and
scm/define-grob-properties.scm to include the calls.
The downside of this is the change to the regression test. The upside
is that this module is being used as a module where it is needed.
Another possibility is that we forget using the module, and hurl all the
code from clip-region.scm into a section of lily.scm. This feels messy
to me, and Han-Wen collected a consistent related set of procedures and
predicates in the guile module.
Another possibility is add a scm_c_use_module ("scm clip-region") call
to ly_make_module e.g.
if (!safe)
{
/* Look up (evaluate) Scheme make-module function and call it */
SCM maker = ly_lily_module_constant("make-module");
mod = scm_call_0 (maker);
/* Look up and call Guile module-export-all! or Lilypond-defined
compatible version when using Guile V1.8 */
SCM module_export_all_x = ly_lily_module_constant
("module-export-all!");
scm_call_1 (module_export_all_x, mod);
scm_c_use_module ("scm clip-region")
//
/* Evaluate Guile module "the-root-module",
and ensure we inherit definitions from it and the "lily" module
N.B. this used to be "the-scm-module" and is deprecated in
Guile V1.9/2.0
*/
SCM scm_module = ly_lily_module_constant ("the-root-module");
ly_use_module (mod, scm_module);
ly_use_module (mod, global_lily_module);
}
else
{
/* Evaluate and call make-safe-lilypond-module */
SCM proc = ly_lily_module_constant ("make-safe-lilypond-module");
mod = scm_call_0 (proc);
}
But this seems like untidy special-casing and we'd need a more extensive
and consistent mechanism in case we wanted to declare other modules
which were globally available to the lily code base, perhaps using an a
scheme list or alist. Nice idea, but I think the subject of a separate
task and tracker if anyone thinks it's worth doing.
I'd like to go ahead with the hack I've got and I'll upload this for
review. Please respond if you think this is a bad idea.
Cheers,
Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMWfQjAAoJEBqidDirZqASVLgH/13QZ7SG3quS3N2iifVzxRwd
RHPoPRPTURbTIMi7JoOgu/9BZWgPLZWw6qShJy1oN28Ds5+ASYAunzgML6993LHG
RDSpSlgs5oyXcOoM+JgNvqJvi5DWmYrUN324kb/XYBpaxcJSkU7T6lrXV8HOjZSY
qmnnFsGtVfo234RVIZKGsZYUfPXLW16dDEfvO+BJVX5xZyx9sh3fpeDq6Zx8PmRC
cNy91eesidxcvcyqYI2hmR/YKH402PpA8x65wTEAkSq7YQn1dggwsmDxKIqSUXV+
6HIX9pwkbZWuC7OW55f9Mx8yB2MNNAGJRfpiVzjpsx4JvDwJvRHxCBvgSaBUVJE=
=63Ti
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
On Wed, Aug 4, 2010 at 8:13 PM, Ian Hulin wrote:
> On 01/08/10 22:37, Patrick McCarty wrote:
>> On Sun, Aug 1, 2010 at 2:02 PM, Neil Puttock wrote:
>>> On 1 August 2010 21:49, Patrick McCarty wrote:
>>>
I think I found the problem.
With Guile 1.9, `module-public-interface' doesn't return an interface
for `the-scm-module', which we rely on:
scheme@(guile-user)> (module-public-interface the-scm-module)
$1 = #f
scheme@(guile-user)>
I'll report this upstream.
>>>
>>> OK. I was just about to reply, since I've seen that error using 1.8
>>> (trying to use `resolve-interface' instead of
>>> module-public-interface).
>>
>> This is quite interesting. :)
>>
>> I just did a little more research, and these three calls all return
>> the same interface, but the last one doesn't work with Guile 1.9:
>>
>> guile> (resolve-interface '(guile))
>> #
>> guile> (module-public-interface the-root-module)
>> #
>> guile> (module-public-interface the-scm-module)
>> #
>> guile>
>>
>> So, it looks like we might want to do this:
>>
>> - SCM scm_module = ly_lily_module_constant ("the-scm-module");
>> + SCM scm_module = ly_lily_module_constant ("the-root-module");
>>
>>
> I'll ensure this change is in the next patch set for T1055.
>
> À propos of which, I've just hacked things so it gets through the
> regression tests without the call using %module-public-interface woot! :-).
>
> However, to do this I've had to change one regression test and one other
> .scm file used in initialization to add
> (use modules (scm clip-region)).
>
> It looks like the reason is that we have been using a side-effect of the
> call to %module-public-interface to pick up a call to the above
> use-modules in init.ly. It looks like the side-effect was pick up not
> only the public interface (all the (define-public) declarations etc. of
> the current module, but also all the public interfaces on the uses list
> for the current module [i.e. our sole and only (scm clip-region)]. This
> allowed us to code as if all the public scheme declarations in
> clip-region.scm had been declared in lily.scm - but they weren't.
>
> I have hacked two .scm files input/regression/clip-systems.ly and
> scm/define-grob-properties.scm to include the calls.
>
> The downside of this is the change to the regression test. The upside
> is that this module is being used as a module where it is needed.
Your approach sounds good to me. The regression test is not holy, we
can change it if there are good reasons.
Congrats on making this work. I had a todo item in the back of my mind
to resolve this, but you got me to 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
