Re: Multiple clefs in one Staff
On Fri, 2023-10-27 at 11:46 +0200, David Kastrup wrote: > > On the other hand, I think I have seen some mensural(?) clef that > > combined two equal-weight different clefs (possibly both C clefs on > > different staff lines) in order to put two singing voices into one > > staff. That's sort of a related problem space but with a > > differently-weighted solution. I think that one would be more > > special, > > though. A famous example is Ockeghem's Missa Prolationum (in the Chigi Codex: https://imslp.org/wiki/Special:ReverseLookup/327083 at pp.44-59 of the PDF) in which each line of music encodes a mensuration canon in two voices at an interval determined (usually) by the pair of clefs. The first kyrie is at the unison, the Christe at the second, the second kyrie at the third, etc.
Re: Gregorian Divisiones
> On 2 Jan 2021, at 19:45, Dan Eble wrote: > > Is there an ancient music expert lurking who is willing to clarify a couple > of things about divisiones for me? (I don't claim to be an expert but then, fools rush in...) > > The LilyPond Notation Reference says, "A divisio . . . is a staff context > symbol that is used to indicate the phrase and section structure of Gregorian > music." I see that these are implemented as breathing signs, which makes > sense except that LilyPond engraves them in voice context. Which one is it, > staff or voice? Or doesn't it matter? In modern usage, it doesn't matter. I'm not aware of any modern example with >1 voice per staff... > Is this notation ever used with more than once voice per staff? It is ever > used for polyphonic music at all? ... however there are some very early examples. One is the conductus "congaudeant catholici" from the Codex Calixtinus (early 12th century) in which the discant is entered in red ink on the same staff as the tenor. Given the note-against-note nature of this example, any divisiones would not be affected. Other polyphonic examples in this notation, such as the Notre Dame sources, have AFAIK the tenor and (sometimes a choice of) discant written separately, even distantly. Yet other examples, such as the four part "viderunt omnes" of Perotin, appear in what is effectively vocal score format, one voice to a staff, with the divisio maxima roughly aligned. > > The NR also describes a "finalis" in the same section. Is a finalis as much > like a breathing sign as the divisiones are, or is it more appropriate to > consider a finalis the ancient equivalent of modern section and final bar > lines? > Yes and no. If one assigns any weight to the front matter of the Liber Usualis, 1961, then "a double line [finalis] closes either a piece of the Chant or one of its principal parts. In books of Chant another role is also assigned to this double line: for it is used in addition to mark the place where after the beginning the whole choir takes up the singing ... but ... it [has been replaced herein] with an asterisk." The implication being that there exist sources where that usage may be found. Bottom line: with a few rather recondite exceptions, I think that for practical purposes it doesn't matter whether the divisiones are at staff or voice level. HTH -- Graham > Thanks, > -- > Dan > >
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
I think Gould's positioning looks _slightly_ better, except at line-beginnings where I definitely prefer lilypond's. Moreover, the position immediately after a bar line is heavily-contested real-estate, as your examples make clear. Therefore it would be good to retain the option to preserve the status quo, especially where convert-ly might otherwise cause skyline changes to existing scores. > On 15 Nov 2020, at 11:02, Kevin Barry wrote: > > Dear Developers, > > I am continuing Jean Abou Samra's work on bar number alignment > (https://gitlab.com/lilypond/lilypond/-/merge_requests/447) and would > like to request your comments on the proposed change. There doesn't > seem to be an established standard for aligning bar numbers (see the > various examples posted at the merge request link for some of the > different ways publishers do them), but there did seem to be some > consensus that LilyPond places bar numbers too far to the left. > > Attached is a pdf that shows four different options: how LilyPond does > things currently, Jean's proposal, Elaine Gould's recommendation (from > the book Behind Bars), and an extra option showing things even further > to the right. I would like to hear people's comments: > - if you have a preference for one of the four, please indicate which > - if you prefer something else, please describe it > - please feel free to introduce evidence in the form of hand-engraved > scores or recommendations by authors (e.g. Ted Ross, whose book I > don't have a copy of to consult) > > NB: I am deliberately not addressing the subject of whether or not bar > numbers should be italicised; I intend to request the list's opinions on > that after this merge request is dealt with. > > Thanks all (especially Jean Abou, who did the hard work) > > Kevin >
Re: non web_version of web.texi ?
On Mon, Jul 06, 2020 at 11:26:46AM +0200, Han-Wen Nienhuys wrote:
> Just for clarity, I'm not against having web.texi as an info file or
> PDF file. It's just that I want to get rid of the special casing of
> web_version, which (when switched) off produces a doc with less links.
Ah sorry, it's been a while. It looks like web_version is
essentially:
if web_version
LilyPond looks amazing, for example
@uref{examples.html#Classical-Music, classical music}
@uref{examples.html#Complex-Notation, complex notation},
else
LilyPond looks amazing and can display classical music.
endif
Do the @uref lines look reasonable in info and pdf output?
It's possible that I just assumed that it wouldn't work, and added
an unnecessary "fix".
(Come to think of it, it might be possible to replace those lines
with simple @ref{}s.)
if web_version
@divIf{homepage-sidebar}
... links to download and manuals page...
@html
... some kind of javascript...
@end html
endif
I added the latter in e343a09657b87891893a4cca13e6c1a3d775f34f,
probably because the pdf looked weird, but I can't recall the
exact circumstances. Unfortunately the commit messages don't
explain much, as you've probably noticed. :(
Sorry I couldn't help more,
- Graham
Re: non web_version of web.texi ?
On Sun, Jul 05, 2020 at 10:38:50PM +0200, Han-Wen Nienhuys wrote: > is there any other function of web.texi besides producing the > lilypond.org website? I would like to get rid of the "-D web_version" > distinction, that is making web_version always be true for the web > document. Is there any reason to not do this? IIRC there was an argument that all lilypond docs should be available via info(1) and pdfs, and some parts of the website qualified as "docs". The general intro to our manuals, for example. Related commits: ac3d9e3f836a56977ca09f89e7ffcfc189711743 a060fc94b65dbc25a7e1ec20f2f79a58036a2546 (general.texi was later renamed to web.texi) The argument on the mailing list was probably in 2009, although just possibly it was late 2008 instead. I think that my original idea was to just produce the html, while the person(s) who wanted to have all docs available offline where you, Jan, John Mandereau, and/or David Kastrup. (It was definitely an emacs user!) A few months later, I was glad that I lost that argument, as it provided a "starting point" to the dozen or so pdf manuals. I'm not aware of the current state & usage of lilypond docs, so I have no position on whether it's worth keeping the "full offline capability". If there's a serious desire to make web.texi HTML-only, then it might even be worth adding that to the tarball of pdfs (if those are still being distributed). Cheers, - Graham
Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)
> On 9 Feb 2020, at 13:23, lilyp...@ptoye.com wrote:
>
> -
> Friday, February 7, 2020, 8:39:36 PM, you wrote:
>
>> Am 06.02.2020 um 22:55 schrieb
>> thomasmorle...@gmail.com:
>>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
>>> File Documentation/learning/common-notation.itely (right):
>>>
>>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
>>> Documentation/learning/common-notation.itely:162: @notation{note names}
>>> and @notation{accidentals},
>>> Here I disagree.
From wikpedia https://en.wikipedia.org/wiki/Alteration
>>> "In music, alteration is the use of a neighboring pitch in the chromatic
>>> scale in place of its diatonic neighbor."
>>> An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
>>> alteration.
>>> Thus "accidentals" is plain wrong here. Please keep "alterations"
>> That were my thoughts, too.
>> But I ascribe more importance to Peter's
>> opinion (as a native speaker)
>> than to mine, so
>> it is difficult for me to decide now...
>
> Is 'alteration' an American English term? I've never heard it in British
> English. But our languages diverge... Are there any US speakers in this
> discussion? Wikipedia tends to have a US bias IMHO.
+1, with respect to accidentals. I'm an en_GB speaker.
>
> 'Alteration' does not appear at all as a heading in the Oxford Companion to
> Music. However, 'accidental' is defined as a 'sign used in musical notation',
> which rather leaves open the question of how to describe a change to a note
> in the abstract. Something I've not really thought about. Hmmm...
From a speed-reading of Gould, it appears that she uses the verb "alter" and
the adjective "altered", but _not_ the noun "alteration" in this context.
It is worth noting that "alteration" has a very specific and well-established
meaning in early music. This meaning has nothing whatsoever to do with pitch.
I've, ahem, altered that Wikipedia disambiguation page accordingly.
The original section header in the LM seemed fine to me, but if it needs to
change, how about "Note names and use of accidentals" ? It seems to me that a
user wanting to use the document to figure out how to specify an accidental, is
quite likely to search for that word.
>
> But this leaves me very unhappy about NR 1.1.1.4, which is called
> 'accidentals' when the first sentence is describing alterations: cis in D
> major is an alteration, not an accidental.
>
>>>
>>> Probably:
>>> @notation{note names} and their @notation{alterations},
>>>
>>> https://codereview.appspot.com/579280043/
Re: Add Code of Conduct [Another RFC or not now?]
On Sat, Feb 08, 2020 at 11:41:11PM +0100, David Kastrup wrote: > Graham Percival writes: > > Within 2-3 weeks, I had squandered all of the good feelings and energy > > sparked from that meeting. I view that as my worst blunder from all > > my years of involvement with LilyPond. > > Hey, I had chalked this up to my slate. Oh my goodness, I sincerely hope not! I've always had very high regard for your programming ability and diligence, and I can't recall taking offense at any "harsh truths" that you threw my way. (I was sometimes disappointed that they *were* true, but I never blamed the messenger!) No, there were a lot of other things happening in my life at the end of 2012: - I had finished writing my PhD dissertation, and I always viewed "completing a degree" as a chance to take stock of my life. I started the grand documentation project in 2007, 1 year before finishing my Masters', with the explicit goal of training my replacements so that I could quit in good conscience. That new project was an attempt at another big project as I left lilypond again. - I knew that my first postdoc job was at a university which had the "charming" idea of laying claim to all the intellectual property that I created, so I would be legally unable to contribute to lilypond. (At least, not able to contribute code. Given that my main contribution at the time was emails and organization, I could have completed a bit, but it might have been awkward.) - I knew that my publication record was not stellar, and no amount of time spent on lilypond would lead to a publication (of the type that mattered in my branch of academia, i.e. a "tier 1" IEEE or ACM journal). - it had been almost ten years since I'd actually composed any music, so I was increasingly wondering why I was spending 10-15 hours a week on LilyPond. > In retrospect, I saw LilyPond in need to grow roots and you saw > it in need to grow wings. Yeah, that was another big mistake on my part. In almost every other instance of "hopeful wings" from 2009 to 2012, I'd argued in favour of stability and keeping things moving (albeit slowly), instead of taking risks. > You've clearly been the much better organiser and motivator: the people > who still keep the "shop running" are doing so in processes originally > set up by you and given meaning by you. Yes -- that's the "stability" part that I'm good at. > And I am basically drawing blanks when thinking about how to > make people pick up the slack when someone ultimately leaves. My dream was always to have a "volunteer funnel". For non-programmers, find people willing to reliably do small tasks, such as LSR, bug reports, translations, and documentation edits. Then, after a few months of that, encourage them to move on to more complicated tasks. The tricky thing is: - you need to expect at least 50% of people to flake out. It's not because they're bad people, it's not because the lilypond community are bad people... that's just the nature of volunteer organizations. I see it offline, too. People understimate the difficulty of tasks, overestimate their time & energy, and underestimate the possibilty of other demands on their time (jobs, families, hobbies, etc). - so the person organizing the volunteers (or ideally, the volunteers in a specific area such as bugs) needs to constantly be recruiting. Well, not necessarily *constantly*, but if you ever think "ok, we've got all 7 days of bug reporters handled so I can relax", that's a danger sign. If they're working well, then encourage 1 or 2 to move to a different task, and recruit new volunteers to fill the gaps. - equally important, the "volunteer wrangler" needs to be emotionally prepared to see a lot of effort walk out the door when volunteers realize that they can't continue. > I still think we should have been able to make this work better between > us but have no idea how. No, there was no fault on your side. And to be fair to myself, it wasn't really a "fault" on my side -- it was definitely time for me to move on. I should have handled it more gracefully (so yes, I blame myself for that). But there was nobody to blame for my leaving the project; if anything, I should have left a year or two earlier. It was simply not a good fit with my life at the time. Cheers, - Graham
Re: Add Code of Conduct [Another RFC or not now?]
On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote: > Phil Holmes wrote 08/02/2020 17:24:56 > Subject: Re: Add Code of Conduct [Another RFC or not now?] > > > - Original Message - From: "Karlin High" > > However, I'd like to hear from David Kastrup and James Lowe first. To me, > > > their opposition registered as the strongest. > > I remain strongly opposed to a CoC. > > > As do I. I'm quite sure we on this list are all perfectly capable of civil > and caring behaviour without having it spelled out in nanny-ish terms. I've stayed silent since I'm not a contributor any more, but if there's an "I'm sparticus" moment happening, then I will go on record as saying that I think the proposed CoC is a mistake. I don't have any reasons that haven't been mentioned already, other than one meta-reason: proposals like this are very divisive. Trying to have this discussion in the middle of a "final sprint towards 2.20" was unfortunate. I speak from experience on that last point: after the 2012 developer meeting at David's ranch (I think that was the year), I was all fired up and started a round of divisive discussions (I think it was the "grand lilypond input syntax standardization"). Within 2-3 weeks, I had squandered all of the good feelings and energy sparked from that meeting. I view that as my worst blunder from all my years of involvement with LilyPond. Cheers, - Graham
Re: ’Pond Jobs & Their Descriptions
On Wed, Feb 05, 2020 at 09:24:37PM -0500, Kieren MacMillan wrote: > Job: Patch Formatter > Tasks: Ensure that a submitted patch conforms to the Lilypond code standards > (found and and ). > Requirements: a text editor; working knowledge of the programming language(s) > used in a given patch (possibilities: C++, Scheme, python). > Estimated Time Commitment: 5 minutes (per average patch), currently an > average of 7 patches per week > References & Links: , tools here>, etc. > Receives From: Patch Submitter or Patch Reviewer > Passes To: Patch Reviewer Oh, that would definitely be a good idea! (I'm not quite certain about the "Receives From" and "Passes To" lines, as I think that implies a more formalized process than LilyPond has, but the rest would be *fantastic*!) Cheers, - Graham
Re: development process
On Wed, Feb 05, 2020 at 08:59:33PM -0500, Kieren MacMillan wrote: > > LilyPond has had a lot of patches get dropped because > > nobody feels comfortable reviewing / shepherding them. > > Seems to me like one solution to that problem might be a subtle > variant on extreme programming: All features/fixes must be > signed out for "patch-ing" by two developers, at least one of > which has committed to and is capable of being the mentor > (shepherding/reviewing). If LilyPond development were a job (which it isn't), and I was the manager/boss (which I'm not), then I would be totally on board with ordering experienced developers to spend 20%-30% of their time mentoring. This "pair programming" solution is one such version. But LilyPond isn't a job. It's a volunteer effort, and people are free to donate their time (or not) as they see fit. Let's pick one person: Han-Wen. He's said that he has a few hours to spend on LilyPond on Friday afternoon. Would he prefer to work on resolving comments about his latest patch on scheme internals (or whatever he's working on) ? Or would he prefer to spend time communicating with his "paired" developer, who's excited about the shape of the alto clef and wants to work on that instead? I can't answer that question, and neither can you. Han-Wen is the only person who can decide how he'd like to spend his time. I would *love* to see more developers collaborating together. But if the current landscape is anything like it was from 2000 - 2012, then I fear that any policy which *required* such collaboration would likely lead to a collapse of development effort. My $0.02: developers can already form pairs, or take newcomers under their wing, or do any number of activities that involve collaborating off-list. I tried to set up "programming mentoring" at least twice, and it always fizzled out. If there's more developers interested in mentoring, and if they can get a real community of mentoring going for a few months, *then* I think it might be worth formalizing such arrangements in policy. But unless / until that happens, I would be reluctant to have a policy that required collaboration which we don't see happening already. Thought experiment: suppose that a complete newcomer posts to the email list tomorrow, saying that he was interested in working on bug #5542 cross-staff slur hides text in eps backend (I picked randomly). Would anybody jump up and say "great! Let me help you get started. I'll work on this with you!"? Or would there be silence for a few days? If you say "I expect that a developer (but not me) would step forward and offer to mentor him"... then you would be expected extra volunteer effort from developers. Cheers, - Graham
Re: ’Pond Jobs & Their Descriptions
On Wed, Feb 05, 2020 at 06:55:38PM -0500, Kieren MacMillan wrote: > I’m curious as to all the various jobs/tasks required to keep > Lilypond development moving forward at the fastest possible pace > and in the most efficient possible way. Is there a single list > compiled anywhere, written with an eye to extreme granularity? If you want "extreme granularity", then wouldn't that be the whole Contributor's Guide? > If not, I’ll start a list, brainstormed from my naïve perspective. I suspect that you want a "less extremely granular" list, in which case I suggest: 1) summarize the jobs that are described in the CG 2) check if those descriptions are still accurate > (b) identify the most important gaps or under-addressed areas in the > pipeline; and I suspect that "automation tools" would be the most impactful improvements. > (c) help new developers find the best way in to the 'Pond. I'm not up to date on current LilyPond, but I suspect that the answer is "try to find developers willing to mentor". Cheers, - Graham
Re: development process
On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote: > Han-Wen Nienhuys writes: > > For context, I have a busy daytime job. I work 80% so I can set aside > > a couple of hours of concentrated hacking time on Friday. Yes. I expect that most people knowledgeable about lilypond code are in this situation, or have even less time available. The whole idea behind the "countdown" system introduced in the early 2010s (which I believe is still in effect) is to make maximum use out of LilyPond experts who only have a few free hours per week. Suppose that an expert has 2 hours of time on Friday, and maybe 10 minutes per day to skim emails for the rest of the week. The idea is that you can quickly see the patches that are nearing acceptance, review them, and warn if they make any bad changes. That's why the "countdown" system has multiple stages -- it was designed to take at least 72 hours (IIRC) from submission to git master, precisely to allow infrequent-but-expert developers a chance to spot mistakes before they got into git. > >We use “we’ll push if there are no complaints” for contributions. I > >think this is harmful to contributors, because it doesn’t give > > contributors > >a clear feedback mechanism if they should continue down a path. > > They get feedback when the code is getting reviewed. If code does not > get reviewed, having their changes dropped on the floor is not going to > increase their enthusiasm. Yes. And unfortunately, LilyPond has had a lot of patches get dropped because nobody feels comfortable reviewing / shepherding them. That could be avoided if the community demanded that expert developers spend more time reviewing patches and mentoring beginners... but that would be horribly insulting to those developers. If somebody has volunteered x hundred hours, then wishes to follow other persuits, the community should thank them for their effort and wish them well. > >It is harmful to the project, because we can end up adopting code > >that we don’t understand. - That's true. It's not an easy place to be in: - there's not enough experienced developers who want to mentor newcomers [1]. - if it's too easy to get code in, stuff will break. - if it's too hard to get code in, few people will want to contribute. I'm not claiming that the current situation is the ideal balancing point, but we were aware that it was a compromise solution. [1] there's good reason for that -- my experience from the grand documentation project is that approximately 25% of contributors reached the "break-even" point (compared to me simply writing all the docs myself) [2]. Based on my investigation into similar projects (GNOME, google summer of code, etc., around 2012), that figure is normal. [2] of course, some of those 25% have gone on to do an incredible amount of work, so I consider the project to have been a great success. Still, I can see how it can be demoralizing for a developer to put hours into mentoring a newcomer who ends up contributing only one or two small patches. > The current scripts were designed to work with Google Code, Yes. I wish that github was FSF or GNU approved, or that there were other tools of the same quality. Cheers, - Graham
Re: midi2ly on mac: midi.so wrong architecture
On Fri, Jul 28, 2017 at 08:01:06AM +0200, David Kastrup wrote: > ElRay <raymond.degenn...@ourfamilyinter.net> writes: > > > FYI: This has been reported as a bug -- in 2012.I will see if this is > > something I can take-on in the next month or two. > > I am pretty sure that Graham posted a patch for this on one of the lists > one of the last times this was being discussed. The patch was accepted in 2.19.55, and midi.c was removed: d8677d345032752b564878e5da0ea17b112afcad 37893d923c65a5f1aec6c78f7225704d2ccec666 That said, the 2.18.2 release was (obviously) not updated, so anybody using the stable release would still see the same error. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Discussed here: (issue 321830043 by fedel...@gmail.com)
Cute solution, I like it. Cheers, - Graham On Fri, Mar 31, 2017 at 10:49:27AM +0200, Federico Bruni wrote: > It won't be in english only. It's up to translators. With this patch they can: > > a) not translate the file, so the content of that section will be in english > _within a translated page_. No maintenance needed. > > b) translate the file and maintain it across updates > > I think I forgot to add a better comment at beginning of gsoc.itexi. > I will do it in the coming days. > > Sorry for the bad email subject. I didn't realize until today how Rietveld > creates it. > > Il 31 marzo 2017 09:31:20 CEST, Urs Liska <u...@openlilylib.org> ha scritto: > >I don't really know what that technically means, but I'm OK with having > >the GSoC page in English only. > > > >This page is being heavily edited for a certain period each year, and > >the "target audience" has to be able to read it in English anyway. > > > >Urs > > > > > >Am 31.03.2017 um 09:06 schrieb fedel...@gmail.com: > >> Reviewers: , > >> > >> Message: > >> Please review > >> > >> Description: > >> Discussed here: > >> > >https://lists.gnu.org/archive/html/lilypond-devel/2017-03/msg00277.html > >> > >> web: move Google Summer of Code information in included/ > >> > >> So translators can choose not to translate this node of > >community.itexi. > >> GSoC page gets quite frequent updates and keeping the translations > >> up-to-date may be cumbersome and not worth the effort (as GSoC > >> applicants are required to speak english). > >> > >> Please review this at https://codereview.appspot.com/321830043/ > >> > >> Affected files (+401, -385 lines): > >> A Documentation/included/gsoc.itexi > >> M Documentation/web/community.itexi > >> > >> > >> > >> ___ > >> lilypond-devel mailing list > >> lilypond-devel@gnu.org > >> https://lists.gnu.org/mailman/listinfo/lilypond-devel > > > >-- > >u...@openlilylib.org > >https://openlilylib.org > >http://lilypondblog.org > > > > > >___ > >lilypond-devel mailing list > >lilypond-devel@gnu.org > >https://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Additions in event-listener.ly (issue 152600043 by pkx1...@gmail.com)
On 2017/03/22 10:24:21, dak wrote: ly/event-listener.ly:69: (eq? 0 (ly:moment-grace-numerator moment)) Why this change for the worse? Numbers need to be compared with eqv? rather than eq? and I don't see that anything was wrong with zero? here since ly:moment-grace-numerator certainly cannot return a non-number. I suspect that this arose from "git rebase". You changed this in 2013 in 1c869295b643d256a99de90f67d32b442f6f0586; if the original patch was made from a branch that happened before that, it would of course have the previous (eq? 0 ...). [incidently, the (eq? 0 ... was part of the first version I wrote, in 2011.] https://codereview.appspot.com/152600043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)
Could you separate the "Run script xyz" changes from the changes to script(s)? That would help to see exactly what's happening here. https://codereview.appspot.com/320390043/diff/1/scripts/auxiliar/update-copyright.sh File scripts/auxiliar/update-copyright.sh (right): https://codereview.appspot.com/320390043/diff/1/scripts/auxiliar/update-copyright.sh#newcode3 scripts/auxiliar/update-copyright.sh:3: echo "Update copyright dates in LilyPond sources" Sorry I didn't notice this earlier. How does this differ from make grand-replace ? http://lilypond.org/doc/v2.19/Documentation/contributor/unsorted-policies https://codereview.appspot.com/320390043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release issues?
Proposed fix: https://codereview.appspot.com/316350043 In order to test it, I did upload website.make to the server and build the website, and that version is still in use for the hourly cronjob. I figured that since the previous one wasn't doing anything, there was no point waiting. Cheers, - Graham On Tue, Mar 21, 2017 at 12:16:05AM +, Graham Percival wrote: > Sorry, my bad. For some reason it didn't twig with me that this > would be release-blocking. I'll upload a fix in 4-6 hours for > discussion. > > - Graham > > On Mon, Mar 20, 2017 at 11:17:29AM +0100, Federico Bruni wrote: > > I think that it's due to the "make website" problem described here: > > http://lists.gnu.org/archive/html/bug-lilypond/2017-03/msg00034.html > > > > > > > > Il giorno lun 20 mar 2017 alle 10:19, Urs Liska <u...@openlilylib.org> ha > > scritto: > > >Hi, > > > > > >are there any issues with the releases? The version bump commit to > > >2.19.57 is over a week old, but the website still claime 2.19.56. > > > > > >Urs > > > > > > > > >-- > > >u...@openlilylib.org > > >https://openlilylib.org > > >http://lilypondblog.org > > > > > > > > >___ > > >lilypond-devel mailing list > > >lilypond-devel@gnu.org > > >https://lists.gnu.org/mailman/listinfo/lilypond-devel > > > > > > ___ > > lilypond-devel mailing list > > lilypond-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/lilypond-devel > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release issues?
Sorry, my bad. For some reason it didn't twig with me that this would be release-blocking. I'll upload a fix in 4-6 hours for discussion. - Graham On Mon, Mar 20, 2017 at 11:17:29AM +0100, Federico Bruni wrote: > I think that it's due to the "make website" problem described here: > http://lists.gnu.org/archive/html/bug-lilypond/2017-03/msg00034.html > > > > Il giorno lun 20 mar 2017 alle 10:19, Urs Liska <u...@openlilylib.org> ha > scritto: > >Hi, > > > >are there any issues with the releases? The version bump commit to > >2.19.57 is over a week old, but the website still claime 2.19.56. > > > >Urs > > > > > >-- > >u...@openlilylib.org > >https://openlilylib.org > >http://lilypondblog.org > > > > > >___ > >lilypond-devel mailing list > >lilypond-devel@gnu.org > >https://lists.gnu.org/mailman/listinfo/lilypond-devel > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website upload
On Tue, Mar 07, 2017 at 11:47:31AM +0100, Davide Liessi wrote: > Maybe an HTTP permanent redirect (308) should be added instead of a symlink, > see > https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection Why 308 instead of 301? Google suggests 301: https://support.google.com/webmasters/answer/93633?hl=en I've added this to .htaccess: ## Temporary rule, pending larger examination of the setup Redirect 301 /gsoc.html /google-summer-of-code.html which should suffice for the current gsoc application process. I'll revisit this in a few weeks. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: nest GSOC project ideas under subsection/h3 (issue 314530043 by paulwmor...@gmail.com)
Sorry for the delay. My tool isn't public yet (hopefully tomorrow or Tuesday), but I just ran it on the lilypond website and it looks fine. This change LGTM. https://codereview.appspot.com/314530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: nest GSOC project ideas under subsection/h3 (issue 314530043 by paulwmor...@gmail.com)
On 2017/02/22 19:01:52, Graham Percival wrote: what else does this change on the webpage? I mean, don't we use @subheading anywhere else? On that note, I wrote a tool for my job that does regression testing for a website (very similar to our lilypond regression tests). I'll try to polish it and get my boss to OK open-sourcing it in the next few days. This will help future CSS development by giving us confidence that there's no unintended changes. Cheers, - Graham https://codereview.appspot.com/314530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: nest GSOC project ideas under subsection/h3 (issue 314530043 by paulwmor...@gmail.com)
Sorry, I disagree. I think the boxes make it easier to skim the page; there horizontal gap makes it absolutely clear that each proposal is distinct. I have no opinion about using bold vs. italics for the "difficulty", "requirements", etc. parts, though. https://codereview.appspot.com/314530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: nest GSOC project ideas under subsection/h3 (issue 314530043 by paulwmor...@gmail.com)
https://codereview.appspot.com/314530043/diff/1/Documentation/css/lilypond-website.css File Documentation/css/lilypond-website.css (right): https://codereview.appspot.com/314530043/diff/1/Documentation/css/lilypond-website.css#newcode709 Documentation/css/lilypond-website.css:709: font-size: 1.17em; what else does this change on the webpage? I mean, don't we use @subheading anywhere else? https://codereview.appspot.com/314530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: examples page: move more common use cases higher in the list (issue 318560043 by paulwmor...@gmail.com)
LGTM https://codereview.appspot.com/318560043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
HTML 4.01 requires "type" attribute for "script" element (issue 315540043 by d...@gnu.org)
LGTM https://codereview.appspot.com/315540043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Back in the Pond
On Thu, Jan 19, 2017 at 02:01:40PM +0100, David Kastrup wrote: > "Trevor Daniels" <t.dani...@treda.co.uk> writes: > > > David, you wrote Thursday, January 19, 2017 10:18 AM > > > >> it would appear that my excursion into a regular workplace ended up > >> somewhat shortlived. Ouch, that sucks. :( > Well, the 2.20 release stoppers of course should be tackled. Step 1 > IIRC was to contact the persons last having worked on three issues you > identified. Uhm, I'd be glad to leave that in Graham's hand, at least > until it's clear that addressing those issues will have to be done by > somebody else. Right, I haven't forgotten, but I likely won't get to this until Feb. I've had a poor (and rare) reaction to some recent vaccinations [1], and lost most of 5 days in the past two weeks. I'm not certain how much energy I'll have after catching up on work, and getting some work done for a Feb 4 board meeting for an (offline) amateur music organization. [1] I don't regret getting the vaccinations, since it's an important public health issue and most people with whom I go ballroom dancing are seniors. For me personally, I'd be willing to take my chances with the flu or even MMR, but for the elderly those illnesses could well be fatal. I just wish that I'd had a better idea that I'd be one of the unusual people who have bad side effects. :( Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
python include path oddity with "make install"
At the moment, doing: mkdir build cd build ../configure --prefix=$HOME/.local/ make make install results in python files which can't find lilylib. This is installed to: $(PREFIX)/share/lilypond/$(VERSION)/python/ The relocation is supposed to be handled by: python/relocate-preamble.py.in but it seems to assume that "current" is a valid $(VERSION). I know that GUB does add a symlink for "current", but that doesn't appear to happen for "make install". I can see a few different ways forward: - figure out why the @lilypond_datadir@ replacement is going to /usr/... instead of $(PREFIX) - add a "current" symlink - add some more directories to the system path in relocate-preamble.py.in Unfortunately, I've lost a lot of steam on this and am not likely to return to it until Feb. I'd rather not hold back the pure-python midi2ly change, so it would be awesome if somebody else could clarify matters and/or fix it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Replace midi.c with midi.py (issue 312300043 by gra...@percival-music.ca)
Reviewers: , Message: Please review. Running "make install" does *not* result in a usable midi2ly, but that's an existing problem not related to this (which I'll discuss separately). For testing purposes, you can use: PYTHONPATH=$HOME/.local/share/lilypond/2.19.55/python/ midi2ly (assuming that you installed to $HOME/.local/ ) Description: Remove midi.c midi2ly: replace unprintables with ~ midi2ly: fix non-printable in MIDI text Add rewrite of midi.c in python Work was done in 2012, and came from here: https://codereview.appspot.com/7016046/ Please review this at https://codereview.appspot.com/312300043/ Affected files (+211, -474 lines): M python/GNUmakefile D python/midi.c A python/midi.py M scripts/midi2ly.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: replace remaining occurrences of www.lilypond.org with lilypond.org (issue 313350043 by fedel...@gmail.com)
LGTM, feel free to push directly to staging. https://codereview.appspot.com/313350043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for January 8th
On Mon, Jan 09, 2017 at 03:17:38AM +0100, Simon Albrecht wrote: > I get a feeling we’re very good at producing misunderstandings right now… > :-) Yes. :) I have pushed the attached patch to staging. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for git-cl
On Sun, Jan 08, 2017 at 09:02:51PM +, Thomas Morley wrote: > attached a little patch for git-cl to replace googlecodeissue by > trackerissue in cl_settings.py, which will result in correct info in > .git/config > > How do we handle patches to git-cl? In general, I'd recommend a PR, but I've applied this directly and pushed. Thanks! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for git-cl
On Sun, Jan 08, 2017 at 10:15:24PM +, James wrote: > On Sun, 8 Jan 2017 21:02:51 + > Thomas Morley <thomasmorle...@gmail.com> wrote: > > > attached a little patch for git-cl to replace googlecodeissue by > > trackerissue in cl_settings.py, which will result in correct info in > > .git/config > > > > How do we handle patches to git-cl? > > > I imagine pull requests to > > https://github.com/gperciva/git-cl.git That certainly works, but in this case I can handle it manually in a few hours. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
converted font-size values from px and percentages to em values (issue 315310043 by gra...@percival-music.ca)
Reviewers: ,
Message:
The beginning of CSS cleanup; no visible changes so far. Please review.
Description:
converted font-size values from px and percentages to em values
Please review this at https://codereview.appspot.com/315310043/
Affected files (+9, -9 lines):
M Documentation/css/lilypond-website.css
Index: Documentation/css/lilypond-website.css
diff --git a/Documentation/css/lilypond-website.css
b/Documentation/css/lilypond-website.css
index
e018b49774186c5467fccb989b8f7df228e31c90..936af77b75f96a8085048231f2729a3dbed268a7
100644
--- a/Documentation/css/lilypond-website.css
+++ b/Documentation/css/lilypond-website.css
@@ -13,7 +13,7 @@ body {
width: 99%;
min-width: 42em;
max-width: 70em;
- font-size: 95%;
+ font-size: 0.95em;
line-height: 1.5;
text-align: justify;
padding: 0;
@@ -78,7 +78,7 @@ div#tocframe {
rgb(25, 115, 50),
rgb(45, 205, 115));
max-width: 70em;
- font-size: 100%;
+ font-size: 1em;
line-height: 1;
padding: 0;
border-bottom-left-radius: 7px;
@@ -120,7 +120,7 @@ div#tocframe {
#tocframe li form {
float: left;
width: 16%;
- font-size: 100%;
+ font-size: 1em;
padding: 0.5em 0.8%;
margin: 0 0 0 1%;
}
@@ -129,7 +129,7 @@ div#tocframe {
display: block;
float: left;
width: 92%;
- font-size: 90%;
+ font-size: 0.9em;
color: rgb(85, 85, 85);
background: rgb(235, 242, 232);
padding: 0.1em 0.1em 0.1em 0.6em;
@@ -178,7 +178,7 @@ div#tocframe {
top: 3.8em;
left: 0.5%;
right: 0.5%;
- font-size: 82%;
+ font-size: 0.82em;
padding: 0;
margin: 0;
}
@@ -237,7 +237,7 @@ div#tocframe {
position: absolute;
top: 2em;
left: 5%;
- font-size: 100%;
+ font-size: 1em;
}
#tocframe .toc .toc .toc li {
@@ -332,7 +332,7 @@ div#cmws {
div#quickSummary {
text-align: left;
margin: 3em 14em 25px 0;
- font-size: 19px;
+ font-size: 1.25em;
}
#quickSummary p {
@@ -390,7 +390,7 @@ div#quickSummary {
}
#homepage-sidebar .subheading {
- font-size: 15.2px;
+ font-size: 1em;
background: #5b7f64;
color: #fff;
padding: 0.2em 0.5em 0.1em 0.7em;
@@ -655,7 +655,7 @@ div.float-center a.clickable {
}
.news-item h3 {
- font-size: 15.2px;
+ font-size: 1em;
}
/* color3 */
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: official GNU LilyPond maintainer
On Tue, Dec 27, 2016 at 05:25:08AM +, Graham Percival wrote: > With David stepping down, LilyPond is left without an official GNU > maintanier. I have now resumed this position. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
web: fix HTML 4.01 validation (issue 316060043 by gra...@percival-music.ca)
Reviewers: ,
Message:
I don't think this needs a review; it's a trivial fix.
If you want to check it in
https://validator.w3.org/
then you can use
http://percival-music.ca/lilypond/index.html
http://lilypond.org/ fails the validation due to this.
Description:
web: fix HTML 4.01 validation
This was broken in 9580a231b3d3f912f46066009114a2929ecbb16a.
Please review this at https://codereview.appspot.com/316060043/
Affected files (+1, -1 lines):
M scripts/build/website_post.py
Index: scripts/build/website_post.py
diff --git a/scripts/build/website_post.py b/scripts/build/website_post.py
index
9fba75445fd86e0e219fc52a2ba60764972cf495..c31aa06cd9bc10d1c74254dae35e8563bc7c594f
100644
--- a/scripts/build/website_post.py
+++ b/scripts/build/website_post.py
@@ -198,7 +198,7 @@ for file in html_files:
### add google tracker header
if (line.find("") >= 0):
outfile.write("""
Re: LilyDev 5.0 released
On Wed, Dec 28, 2016 at 06:24:48PM +0100, Federico Bruni wrote: > The default should be httpredir: > httpredir.debian.org > > Have you tried again? I hope that it's just a temporary network problem. Yes, seems to have been temporary. I tried it 3 times yesterday, but now it's working. I currently have an awkward problem with virtualbox on Ubuntu 16.04; it keeps on resizing the window one step smaller, until it's something like 50 pixels high and 300 pixels wide. This doesn't happen if I maximize the window. Very odd, and not unique to lilydev; I see this when I virtualize ubuntu 16.04, but not other operating systems. Very odd. I've logged in, but it doesn't seem like like git-cl is installed? The Contributor Guide says that it should be there: http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl In a similar note, could we get a Terminal icon on the taskbar? Most people won't know that they can get an xterm by pressing ctrl-alt-t. In a related matter -- and please forgive me if we've discussed this before -- have we considered distributing an exported OS? In the virtualbox GUI, this is called "Export Appliance", but it can be done in a standard format so that (in theory) non-virtualbox people can run it. This would let people "get started" much faster, and without the intimidation of installing Linux. It might also be easier to customize a bunch of things, such as git-cl, and even putting a git clone of lilypond in there. I realize that this would increase the filesize; it looks like 1.8 Gb for the exported appliance, compared to 1.1 GB for the installer. (speaking of disk size, I see that the just-installed size is 3.1G. What's pushing it so high? texlive? I poked around a bit, but I couldn't find any packages that looks superfulous... maybe I'm just out of date with how large installed software is these days. I must admit that I'm shocked to see that my desktop /usr/ is 8.5G !) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
On Wed, Dec 28, 2016 at 08:21:58PM +0100, k...@aspodata.se wrote: > > At that point, an interested person -- perhaps yourself? -- could > > offer further patches which improved the quality of the lilypond > > code. > > Well, I'm working on theese: > http://turkos.aspodata.se/git/musik/bin/miditoly.pl > http://turkos.aspodata.se/git/musik/bin/midi_to_lilypond.tex Hmm. At the moment, there is no perl used in user scripts in lilypond, and thus we do not distribute a perl interpreter as part of our application bundle. Adding perl would be a significant complication. That said, I'm quite willing to believe that your experience with miditoly.pl could help inform the conversion process in midi2ly.py -- what types of quantization work best, or how to decide which accidental to use, etc. Once we have the basics working, Joe may want to investigate more advanced techniques. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Free alternatives to Rietveld?
On Wed, Dec 28, 2016 at 06:35:30PM +0100, Federico Bruni wrote: > It would be possible to add a configuration option in git-cl so > you can login in rietveld with a specific browser different from > the default one? Certainly! In the source, I see: - If your browser is on a different machine then exit and re-run upload.py with the command-line parameter --no_oauth2_webbrowser - IIRC that prints a URL string, which you can open with whatever browser you want (on whichever computer you want). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
On Tue, Dec 27, 2016 at 08:43:34AM +0100, k...@aspodata.se wrote: > Graham: > > That is correct; the python midi2ly conversion is quite > > independent of the rest of LilyPond. As a result, it is an > > excellent place to begin! :) > > So I propose that a better course of action would be to research Thank you for the suggestion. At the moment, it appears that midi.c is broken on at least one architecture. Fixing it would be a pain, and would do nothing to reduce the problem it poses. Moving to a completely python solution would represent a solid step forward, both in terms of reducing technical debt, and also in terms of a new contributor getting familiar with our development process. At that point, an interested person -- perhaps yourself? -- could offer further patches which improved the quality of the lilypond code. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Free alternatives to Rietveld?
On Tue, Dec 27, 2016 at 02:39:09PM +, James wrote: > On Tue, 27 Dec 2016 13:33:11 +0100 > Simon Albrecht <simon.albre...@mail.de> wrote: > > > Whatever the reason for this weirdness, I think it would really be > > better if we had a code review tool which didn’t rely on external > > login providers. Is there really no free alternative? > > We had a 'similar' discussion back in 2013 > > http://lists.gnu.org/archive/html/lilypond-devel/2013-09/msg00351.html Heh, yes! I'm aware of problems with the existing setup -- in fact, my first few patches were delayed by half a week because I had problems setting it up. Quite apart from the loss of time, that was a huge drain on my energy and motivation. A week ago, I started investigating alternatives. As always, my primary motivation is *not* adding any additional burden to our experienced developers. I have not yet reached the point at which it would be useful to discuss any proposals on -devel, though. (As we can see from the 2013 emails, a very wide-ranging discussion quickly becomes bogged down and fails to produce results. If anybody is very interested in the "alternatives" question and is willing to do 2-5 hours of work that will probably end up being discarded, feel free to contact me off-list.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev 5.0 released
On Wed, Dec 14, 2016 at 01:53:06PM +0100, Federico Bruni wrote: > Eventually I managed to build the new ISO. Thanks for all this work! I get an invalid network mirror when I try to install it. Do you have a default valid set, or is it failing to connect to the generic Canadian debian server? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
official GNU LilyPond maintainer
With David stepping down, LilyPond is left without an official GNU maintanier. Does anybody want to do fill this role? The relevant documentation is: https://www.gnu.org/prep/standards/html_node/index.html https://www.gnu.org/prep/maintain/html_node/index.htm If nobody is interested in the position, I am willing to take it up again. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can I develop with Raspberry Pi 3
On Mon, Dec 26, 2016 at 12:47:29PM -0500, Joseph Austin wrote: > Is it possible/practical to run LilyDev on Raspberry Pi 3? Unfortuantely not; LilyDev is compiled for x86 CPUs, whereas the Pi 3 has an ARM CPU. > In other words, is that a realistic alternative to setting up a > virtual machine or configuring a MacBook to run native? Unless your MacBook is 10 years old, it would be much faster to do LilyPond development within a virtual machine on your MacBook. That said, if you are only working on midi2ly, then you don't need the full LilyPond developer infrastructure. In fact, all you need a python interpreter (and arguably git for the source code); MacOS comes with python already. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
On Mon, Dec 26, 2016 at 11:44:15AM -0500, Joseph Austin wrote: > I am offering to help with the project of converting midi2ly > from C to Python, or more generally converting MIDI to Lilypond. Excellent! I'd be delighted to serve as your mentor. > I'm not sure if this is a good place for someone new to Lilypond > internals to start, but it seems this should be a relatively > independent utility so I shouldn't need a significant background > in the internals. That is correct; the python midi2ly conversion is quite independent of the rest of LilyPond. As a result, it is an excellent place to begin! :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Two small amendments to Doc/web/community.itexi (issue 319880043 by simon.albre...@mail.de)
LGTM https://codereview.appspot.com/319880043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
LGTM https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: remove www from lilypond.org URL (issue 312190043 by fedel...@gmail.com)
LGTM, and I'm happy with pushing it directly to staging. https://codereview.appspot.com/312190043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Point to \resetRelativeOctave in NR 1.1.1.b (issue 312210043 by simon.albre...@mail.de)
LGTM https://codereview.appspot.com/312210043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Two small amendments to Doc/web/community.itexi (issue 319880043 by simon.albre...@mail.de)
https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode434
Documentation/web/community.itexi:434: every bug can be demonstrated in
four lines of code or less!}
Hmm, I think "four notes" is shorter (and easier to understand) than
"four lines of codes". I mean, people can stuff a lot of extra material
into four lines of code!
The place that discusses "four lines of code" in Tiny examples is at the
bottom of a longer explanation about the process. As such, I think it
serves a different purpose. The main point of this @warning{} is to get
people to look at "Tiny examples".
https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode498
Documentation/web/community.itexi:498: any activity on the bug occurs.
For that, just click the envelope
I would replace ". For that, just click" with "by clicking". So that
area would be:
... any activity on the bug occurs, by clicking the envelope symbol...
https://codereview.appspot.com/319880043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
On Sun, Dec 11, 2016 at 04:44:40PM +0100, Hans Aikema wrote: > > The official requirements for building: > INSTALLING > > * You need > - about 9 GB of free space (for all platforms) > - standard unix shell utilities: cat, cp, install, mv, rm, sed, ... > - a standard unix development environment with GCC and G++ > - Python 2.4 or newer (2.5, 2.6, 3.0 are known to work) > > are rather vague (on points 2 and 3) and in a Dockerized linux env you > usually have the bare minimum available and all else needs to be added. Hence > the /usr/bin/file was missing on my system. On a regular CentOS I assume it > would’ve been present. Yes, absolutely. I've begun expanding the definition of "standard unix development environment" in the README; please make a branch and add to that list as you discover more missing items. We seem to have more interest in GUB these days, so making it easier to get started would be great. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website: texinfo macros for both ID and classes
On Mon, Dec 05, 2016 at 01:13:26PM -0500, Paul wrote: > On 12/05/2016 12:35 PM, Graham Percival wrote: > > >>This would be good to have in general and more intuitive for > >>those used to html. > >I'm not convinced. > > As someone who knew html and went through the process of figuring out how to > contribute to the LilyPond website, I would have found it more intuitive and > useful to have. There was a point where a div with both Id and class was > needed and there was no way to do it even though this is the most basic and > common thing in html. Sorry for the delay. I'm still not convinced that a div with ID and class is actually needed. Can you remember the specific example? > I'm just trying to smooth out a point of friction that I encountered, but > sure, there are probably other priorities. Right, and that's a great move! I'm just not convinced of the details in this case. I don't want this to be advertized on lilypond-user yet since it's still too soon after the latest website fracas, but I've prepared a repository so that people can easily experiment with CSS. It has the normal index.html, the pictures used by that file, and the original CSS. Anybody interested is encouraged to copy the "orig" directory into a new one, then edit the new CSS as much as they want. https://github.com/gperciva/lilypond-web-css You can see the results here: http://percival-music.ca/lilypond-web-css/orig/ http://percival-music.ca/lilypond-web-css/simple/ (yes, I ran out of patience when I got to the point of choosing a color for the "Beautiful Sheet Music" header) Over the next few days / weeks, I'll continue to edit the "simple" CSS, and maybe make one or two other examples. None of this is intended to be merged with lilypond; I just want to demonstrate how easy it is to make huge changes with only the CSS. This way, the next time somebody expresses interest in the website, they'll have a much clearer idea of what's involved and what the limitations are. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bypassing the patch countdown
On Wed, Dec 07, 2016 at 11:58:14PM +0100, Urs Liska wrote: > Am 7. Dezember 2016 23:34:39 MEZ, schrieb Graham Percival > <gra...@percival-music.ca>: > >(please note that I'm not suggesting that anybody should feel > >obligated to make such typo fixes -- instead, I'm checking that > >the "door is open". So that if we manage to get 1 or 2 users > > In the current case the point is not that it would take a > significant effort to update the news but rather that it's not > woth touching at all, given the temporary nature of the > information. Oh, absolutely, I'm not suggesting that anybody here should update the news! I'm just checking that if a user thinks they're capable of making such contributions, I can encourage and mentor them with a good conscience. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
bypassing the patch countdown
I was going to wait a month or two before suggesting this, just to make sure I was fully "up to date", but I'll jump in now. We instituted the policy of patch countdowns and Patchy after the lengthy wait for 2.14.0, which was due to a large number of regression bugs due to patches which either broke the compile, or broke previously-working output. However, even after that, I still pushed some commits directly to staging, bypassing the countdown. Obviously I did this for updating the VERSION when making a release, but I also did it for a few typo fixes as well. Is this still an accepted practice? If not, I suggest that it should be. If I had to formalize it, I'd say something like "if two developers with push ability agree that a fix is trivial and obvious, it can go straight to staging". (please note that I'm not suggesting that anybody should feel obligated to make such typo fixes -- instead, I'm checking that the "door is open". So that if we manage to get 1 or 2 users who are able to fix typos, and those fixes are very obvious, they wouldn't need to wait 2-4 days. In this case, the "two developers" would be "1 mentor, and the release or patch meister".) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)
On Mon, Dec 05, 2016 at 06:03:28PM +, Carl Sorensen wrote: > > On 12/5/16 10:28 AM, "lilypond-devel on behalf of Graham Percival" > <lilypond-devel-bounces+c_sorensen=byu@gnu.org on behalf of > gra...@percival-music.ca> wrote: > > >The website *is* tied to the documentation. That decision was > >made in 2009, and the reasons are just as valid today. > > I believe you when you say this. But I am having a hard time finding a > record of the decision. I expected to find it in the CG under > Administrative Policies or under Website work. I couldn't find it either > place. Can you help me find a pointer to the discussion and/or the > decision rationale? Good question, and I still don't have a good answer. This was before we started keeping records of any decisions. The earliest I found was this: http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00574.html which didn't spark a whole lot of discussion. The current website didn't start to become visible until late 2009. I had a vague memory of a much more in-depth discussion, but perhaps that was sometime in 2010 or 2011. I'll continue to trawl through the archives to see if there's more info. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website: texinfo macros for both ID and classes
On Mon, Dec 05, 2016 at 11:49:27AM -0500, Paul wrote: > For the website I'm thinking about adding a macro that can create a div with > both an ID and classes. Why? What problem would this solve? > This would be good to have in general and more intuitive for > those used to html. I'm not convinced. Before changing the underlying texinfo macros, much less the build system or language used (which is not what Paul is suggesting, but I know that those ideas are out there), I'd like to see somebody make an honest effort at working on the CSS. In particular, to make the website look acceptable on small screens. This would take 2-5 hours, depending on how familiar that person is with CSS and web browser testing. I don't think that's too much to ask. If nobody is prepared to even do that much, then we certainly don't want them to spend time and effort on larger redesigns that may never be completed. I'm available to mentor this task. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)
On Mon, Dec 05, 2016 at 09:24:54AM +0100, Urs Liska wrote: > > If this intends to codify the website being tied to the documentation I > don't really like that. The website *is* tied to the documentation. That decision was made in 2009, and the reasons are just as valid today. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)
Looks good to me, especially with Trevor's suggestion. https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi File Documentation/contributor/website-work.itexi (right): https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi#newcode21 Documentation/contributor/website-work.itexi:21: maintenance effort and ensures the contents of the website to be (proposed modification by Trevor): - ensures the contents of the website to be - up to date with the rest of the documentation. + ensures the website content is consistent + with the rest of the documentation. https://codereview.appspot.com/315130043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)
Reviewers: ,
Message:
Suggestion from Karlin High, modified by Simon Albrecht. Please review.
Description:
Doc CG 6.1: Add caveat on website work
Please review this at https://codereview.appspot.com/315130043/
Affected files (+19, -2 lines):
M Documentation/contributor/website-work.itexi
Index: Documentation/contributor/website-work.itexi
diff --git a/Documentation/contributor/website-work.itexi
b/Documentation/contributor/website-work.itexi
index
588d705f1b4facfbd11797a6122b95aae935d2b4..6e858f0c56788fafb4ab342c63787791c8099731
100644
--- a/Documentation/contributor/website-work.itexi
+++ b/Documentation/contributor/website-work.itexi
@@ -14,8 +14,25 @@
@section Introduction to website work
The website is @emph{not} written directly in HTML;
-instead, the source is Texinfo, which is then generated into HTML,
-PDF, and Info formats. The sources are
+instead it is autogenerated along with the documentation through a
+sophisticated setup, using Texinfo source files. Texinfo is the
+standard for documentation of GNU software and allows generating
+output in HTML, PDF, and Info formats, which drastically reduces
+maintenance effort and ensures the contents of the website to be
+up to date with the rest of the documentation. This makes the
+environment for improving the website rather different from common
+web development.
+
+If you have not contributed to LilyPond before, a good starting
+point might be incremental changes to the CSS file, to be found at
+@uref{http://lilypond.org/css/lilypond-website.css} or in the
+LilyPond source code at @file{./Documentation/css/lilypond-website.css}.
+
+Large scale structural changes tend to require familiarity with
+the project in general, a track record in working on LilyPond
+documentation as well as a prospect of long-term commitment.
+
+The Texinfo source file for generating HTML are to be found in
@example
Documentation/web.texi
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New LilyPond website
On Fri, Dec 02, 2016 at 07:50:50PM +0100, Jean-Charles Malahieude wrote: > I've already given it a try, but get stopped by some errors I don't know how > to resolve (I've no knowledge about perl). Three patches are available for > anybody willing to help me… I can compile the English version, except that I > don't get the TOC sidebar. Hmm, sounds like there's some duplicated effort there. In July 2015, we created: https://github.com/gperciva/lilypond-texinfo to try to update lilypond-texi2html-init. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stepping up, contributor mentoring
On Sat, Dec 03, 2016 at 11:34:01AM +, James Lowe wrote: > I have created > > https://sourceforge.net/p/testlilyissues/issues/5006/ > > For the 'CSS change' Rietveld that I see you uploaded on behalf of Mr. > Roper just so it gets on my radar (and the countdown, including the URL > that Phil kindly set up for developers to have a quick overview - > http://www.philholmes.net/lilypond/allura/) Thanks! Since Mr. Roper dropped out, I removed that issue, but it's good to know the process is in place. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
first draft of css changes from John Roper (issue 313170043 by gra...@percival-music.ca)
Reviewers: ,
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css
File Documentation/css/lilypond-website.css (right):
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css#newcode27
Documentation/css/lilypond-website.css:27: @import
url('https://fonts.googleapis.com/css?family=Cabin');
Please do not make multiple changes in a single commit; that makes it
harder to track what is changing.
I suggest that the first commit be purely for the navbar, but I'm
certainly open to discussing it.
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css#newcode64
Documentation/css/lilypond-website.css:64: color: #0c6be8;
This appears to make visited links /lighter/, which strikes me as a bit
odd. Isn't the default to make visited links darker?
Hmm, according to
http://stackoverflow.com/a/4774037
(which in turn cites W3C), the recommended unvisited link is #EE
(dark blue), while the recommended visited link is #551A8B (deep
purple).
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css#newcode83
Documentation/css/lilypond-website.css:83: margin-top: 15px;
I would feel more comfortable with em or rem here, instead of pixels. I
do see that the original file used 7px here, but I consider that a
mistake that we don't need to continue.
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css#newcode122
Documentation/css/lilypond-website.css:122: height: 20px;
Again, I suggest that we avoid px in this age of retina displays, cell
phone browsing, etc.
https://codereview.appspot.com/313170043/diff/1/Documentation/css/lilypond-website.css#newcode151
Documentation/css/lilypond-website.css:151:
Please do not add blank links.
Description:
FIXME DO NOT MERGE first draft of css changes
Please review this at https://codereview.appspot.com/313170043/
Affected files (+44, -88 lines):
M Documentation/css/lilypond-website.css
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stepping up, contributor mentoring
On Tue, Nov 29, 2016 at 11:37:04PM -, Trevor Daniels wrote: > > Graham Percival wrote Tuesday, November 29, 2016 11:11 PM > > > So, are there any vacancies on the Bug Squad? I've signed up for > > sourceforge (username: gperciva). > > I've added you to SF as a Developer (gives you Read, Create, Update > permissions for the LP Issues at > https://sourceforge.net/p/testlilyissues/issues/ ). Hmm. Sourceforge seems to have forgotten my account -- I couldn't log in, and the recovery emails didn't work. So I tried to create a new account with the same username, and it appeared to work. This is not encouraging. :( It could simply be that I used to have an account there, and it got confused because I created an account with the same name as a deleted account. Could you please try adding "gperciva" to the SF Developer list again? If my suspicions are correct, this account will also disappear, in which case I'll choose a different username. (I just tried to create a second account, but it recognized that I already had one tied to my email address and refused to add it.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Stepping up, contributor mentoring
Hi all, I'm back. So, are there any vacancies on the Bug Squad? I've signed up for sourceforge (username: gperciva). Other than that, my primary interest remains in organization / mentoring new contributors. Has anything changed in regards to that in the past four years? Or shall I jump straight in? I see that "Contributor 1.4 Mentors" hasn't changed. Anything else I should know? I've skimmed the past month of this mailing list. (I was planning on waiting until the new year, but David's news made me re-evaluate my health now, and I think I have the energy to take on more stuff. To make a long story short: depression, burnout, quit academia, moved back to Vancouver, recovery. Also, started ballroom and swing dancing! Great fun, absolutely recommended, *especially* for other shy, socially anxious computer geeks. Despite that help, I'm still not 100% recovered, but I'm content with my progress, and I think that doing more volunteer work will help.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3945: fix (De)crescendo with unspecified starting volume in MIDI (issue 294700043 by nine.fierce.ball...@gmail.com)
On Sat, 2016-06-04 at 14:16 -0700, nine.fierce.ball...@gmail.com wrote:
> https://codereview.appspot.com/294700043/
>
>From the bug tracker:
In order to avoid the midi-warning a workaround would be to
specify
the starting volume explicitly and hide or omit the
DynamicText.stencil.
{ c'1-\hide\mf\ c' c'\! }
{ c'1-\omit\mf\ c' c'\! }
Though, the Hairpin will start at the right of the now
invisible/non-existent DynamicText.
This might usefully be cross-referenced to issue 4837. Sorry, I don't
have a sourceforge account, or I'd do it myself.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
On Sun, Aug 30, 2015 at 05:57:45PM +0200, Jean-Charles Malahieude wrote: BTW, is there any difference between download/source and download/sources ? I'm pretty certain that one is a symlink of the other. If not, then one was a place to store some odd tarballs for GUB to download. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote: We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. I think it would be nice to keep the ancient history around; software archeology research sometimes look at open-source projects. That said, they don't necessarily need to be on that particular web server. Something like Amazon Glacier could work well for that, or maybe google drive... there are other storage platforms available. (and no, I'm not in a position to offer to take care of this) I fully support deleting all test-output for non-current development versions. (though again, in an ideal world they would be stored on some other server or service) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PDF date format
I think it is known as the PDF date format. A quick search for PDF date string standard throws up various references, including https://tinyurl.com/po9wqaj The format seems to be completely outwith the relevant standards (ISO 8601 and RFC 3339), but somewhat resembles them, of course. HTH -- Graham On Thu, 2015-08-13 at 13:52 +, Phil Holmes wrote: Looking inside PDF documents, the date is formatted like the one here: D:20150813145047+01'00' Does anyone know whether this style of abbreviation has a name? TIA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mentoring opportunity: anybody claiming to care about the website
Great to have you on board! I've sent a private email to you about the first few steps. Cheers, - Graham On Sat, Jul 25, 2015 at 03:02:36PM +0100, Kevin Barry wrote: I have some unexpected free time and would like to do this. Should I contact you off list? Kevin On Sun, Jul 19, 2015 at 4:31 PM, Graham Percival [1]gra...@percival-music.ca wrote: Add weight to your opinions by showing that you're not afraid of getting your hands dirty. texi2html is a vital part of the documentation. It's currently used for the website as well, but that is almost incidental to its use for the rest of the documentation. [2]https://code.google.com/p/lilypond/issues/detail?id=1000#c20 [3]https://code.google.com/p/lilypond/issues/detail?id=1000#c21 I cautiously estimate 20 hours of work for the non-translation portion[1]. I am willing to mentor. Programming ability is desirable, but not strictly required. [1] at the present time, I am not willing to look into the translation system in sufficient detail to offer an estimate of how much work it would take. If we complete the English part, and those involved wish to continue, then I promise to also mentor the translation part. - Graham ___ lilypond-devel mailing list [4]lilypond-devel@gnu.org [5]https://lists.gnu.org/mailman/listinfo/lilypond-devel References 1. mailto:gra...@percival-music.ca 2. https://code.google.com/p/lilypond/issues/detail?id=1000#c20 3. https://code.google.com/p/lilypond/issues/detail?id=1000#c21 4. mailto:lilypond-devel@gnu.org 5. https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
mentoring opportunity: anybody claiming to care about the website
Add weight to your opinions by showing that you're not afraid of getting your hands dirty. texi2html is a vital part of the documentation. It's currently used for the website as well, but that is almost incidental to its use for the rest of the documentation. https://code.google.com/p/lilypond/issues/detail?id=1000#c20 https://code.google.com/p/lilypond/issues/detail?id=1000#c21 I cautiously estimate 20 hours of work for the non-translation portion[1]. I am willing to mentor. Programming ability is desirable, but not strictly required. [1] at the present time, I am not willing to look into the translation system in sufficient detail to offer an estimate of how much work it would take. If we complete the English part, and those involved wish to continue, then I promise to also mentor the translation part. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)
On Tue, Jul 07, 2015 at 12:22:27PM +0200, Dave Plater wrote: On 7/7/15, Dave Plater dplater.l...@gmail.com wrote: Oh, there's a pretty big chunk of custom stuff in lilypond texi2html. See past discussion here: https://code.google.com/p/lilypond/issues/detail?id=1000 is this issue likely to be resolved soon or is it as complex as the guile 2.x issue and I'm going to have to create texi packages to build the documentation? See https://bugzilla.novell.com/show_bug.cgi?id=936870 It's not as complex as guile 2.x. If somebody has basic knowledge of perl (which isn't hard to acquire) and texinfo (essentially just knowing it's a doc format with @commands), and is good at diagnosing and communicating problems, then I would cautiously estimate 20 hours for this task. 10 hours of investigation and rewriting by oneself, plus another 10 hours of creating minimal examples, sending them to the texinfo list to ask for help, then integrating the solutions into the updated thing. This could very feasibly be done by somebody new to lilypond development. oh, two slight snags: 1) once it was updated to the new texinfo, our build scripts will probably need some slight adjustment. That is not do-able by somebody new to lilypond, but I'd estimate 1 hour from a current lilypond developer to get that done. 2) it is possible (or even likely) that texinfo will need to be changed in order for us to do what we want. I'm certain that if somebody has a minimal example of the problem, and a compelling justification for why we want to achieve the desired output, the texinfo people will be happy to add whatever features or bugfixes are required in texinfo. But this *would* add another delay for being able to build lilypond on a stock distribution with texinfo 5.x. (that said, if I'm correct about requiring texinfo changes, this will need to happen at some point so all the more reason to jump on this now) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improving the Contributors Guide and LilyDev
On Mon, May 04, 2015 at 03:02:32AM +, Carl Sorensen wrote: A. Suggestions for LilyDev3: All of these suggestions would actually probably be for LilyDev4. I'm not sure that we will make another release of LilyDev3. But if we did, I'm still happy to host it. If somebody is available and interested in preparing lilydev4, I suggest splitting the list of improvements into lilydev4-stuff and CG-stuff. (And/or in the CG walk the reader through the steps to change the editor settings.) This is an immediately-accessible thing to do. Yes, although the editor settings can be done in advance in lilydev4. (I believe that /etc/skel/ is the place to look at, but I know that somebody already figured this out and it wasn't me) The CG could also have a section for turning a typical ubuntu installation into lilypond development-ready (a shorter name would be better), which gives details about this, setting PS1, etc. But ideally LilyDev4 should have as much as possible done in advance, so that interested contributors can jump into contributing. In general avoid having sections that basically repeat each other in different ways, for example, consider merging: 1. Git for the impatient (3.2.2) and Basic Git procedures (3.3) There are reasons (perhaps historical) for this duplication. 3.2.2 is supposed to be briefer than 3.3. The main reason is that when I wrote 3.2.2, I forgot that 3.3 existed. Either that, or I thought that 3.3 was too long. I forget which. Either way, I don't think we need both sections. 2. Compiling with LilyDev (2.3) and Compiling (4.x) 2.3 is about getting it set up with LilyDev. 4.x is about general work whether with or without LilyDev. We are much stronger about recommending the use of LilyDev than we were when the CG was originally written, so perhaps it's time to make a change here. I think it's worth keeping a section about compiling for non-lilydev, but perhaps something like Advanced unix compiling (again, bad name) would be better. Basically, make sure that 4.x is clearly about general work. (as an advanced Linux user, I would be annoyed if I had to wade through lots of hand-holding in a discussion about how to compile an open source project) We certainly want to make the CG accessible for new users/developers. But we also want to have the CG useful for old developers and those experienced with other software development environments. Perhaps we need to clarify these two different use cases, and separate them out more carefully in the CG. But IMO we need to avoid making the CG only useful for newbies. Yes. Thanks again for looking at this. Certainly improving the CG is an important part of the health of LilyPond. Absolutely! - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Google Code shutting down
On Fri, Mar 13, 2015 at 11:33:22AM +0100, Han-Wen Nienhuys wrote: I can click the export button so all the issues are migrated to github. Thoughts, ideas? Didn't someone setup a lilypond organization at github? There was some discussion about that, which spilled over to gnu-hackers or gnu-devel or whatever it's called. Pending some investigation about the javascript libraries or scripts used on github.com, it's tentatively seen as reluctantly acceptable to host GNU software there. A few people spoke highly in favor of gitlab, but I'm not familiar with them so I can't say anything one way or the other. In addition to moving the issues, the issue handling scripts would need to be updated. Things like git-cl, patchy, and the whole patch-submission system. That will be a non-trivial effort. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)
On Mon, Mar 09, 2015 at 01:29:39PM +0100, David Kastrup wrote: Petr Gajdos pgaj...@suse.cz writes: If this is relevant, texi2html-5.0/texi2html.pl do not contain sub get_index in contrast of texi2html-1.82/texi2html.pl. Whoa. That one certainly looks like it will need attention soonish. I did not realize that we had what amounts to such a large modification of texi2html in our code base. Oh, there's a pretty big chunk of custom stuff in lilypond texi2html. See past discussion here: https://code.google.com/p/lilypond/issues/detail?id=1000 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB update
On Sun, Jan 04, 2015 at 04:33:05PM +, Phil Holmes wrote: I assume what is happening here is that the manual install places the mpc libraries where the gcc configur can't find them. In any case, doing this manually defeats the object of a self-building package builder. So what would be really helpful would be for someone who understands all the python stuff that GUB does could point me to how to add the new dependency to GUB for MPC. Wouldn't it be here? https://github.com/gperciva/gub/blob/master/gub/specs/gcc.py#L16 However, first you need to add a mpc.py in that directory. The contents of that file should start of being something like https://github.com/gperciva/gub/blob/master/gub/specs/tar.py (picked fairly randomly) Note the toolsAutoBuild part -- if MPC is autotools, then the configure should be relatively straightforward. Maybe even something like https://github.com/gperciva/gub/blob/master/gub/specs/faac.py (again chosen randomly) I'm sure that right now you're wondering why some (most?) of the spec files are much much nastier than faac.py. The answer is that pretty much all of that nastiness is working around bugs in the original package's build systems. After you add mpc.py, test that in isolation before trying make bootstrap. It's entirely plausible (or even likely!) that you'll be able to build mpc with the default ubuntu, but it'll fail on some cross-compilation step. But check the native build first. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)
On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com wrote: I've not followed the corresponding email discussion closely, and maybe I've missed something, but how is this better than simply using \obreak for an original break, and \nbreak for a new, required, break, having defined obreak = \break nbreak = ... That seems so simple anyone can do it without adding anything to the base code and almost a page to the documentation. This method is already in the documentation! At least, it used to be... Learning Manual, tips for typesetting or something like that? it's just possible it was moved to Notation or Usage at some point. But it was definitely in the docs ten years ago. (yes, literally 10 years ago. Mao, where did the time go?) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compact Chord Symbols Patch
On Tue, Oct 07, 2014 at 12:53:53PM +0100, James wrote: I think we could improve the notes in the contributor's Guide generally. Having had to help three or four people over the last few months with a patch or two, I get how the instructions are probably rather confusing if not intimidating. I think the most important point would be to have a single checklist for what should be done. Two years ago, the CG had at least three such lists, and I was aware of mistakes in two of them. I don't know what's changed sinc then, though. Having a single list has two advantages: it's an obvious thing to refer to, and since it focuses attention from both readers and CG-writers, mistakes should be more obvious (and thus easier to fix). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: es means ees???
On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote: Richard Shann rich...@rshann.plus.com writes: Here, instead of ees, is written es. I read In Dutch, aes is contracted to as, but both forms are accepted in LilyPond. Similarly, both es and ees are accepted. This also applies to aeses / ases and eeses / eses. Sometimes only these contracted names are defined in the corresponding language files. Yes. In case anybody was wondering, I deliberately moved the as and es contractions from the tutorial into the NR ages ago. For people unfamiliar with that notation, it's easier to remember letter name plus -es or -is rather than introducing all the contractions. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How can I change my email address for code reviews?
On Thu, Sep 18, 2014 at 07:01:02PM -0400, Dan Eble wrote: I’m using LilyDev. ~/.gitconfig says nine.fierce.ball...@gmail.com. I’ve tried removing ~/.last_code_review_email_address. I’ve even gone as far as running rm -f ~/lilypond-git and getting it again with lily-git.tcl. No go. git cl upload still uses the old address. What am I missing? Thanks in advance. Take a look at your ~/.gitconfig . If lily-git.tcl inherits your old address from somewhere, it must be a user setting such as $HOME/.gitconfig or an export GIT_EMAIL or something like that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
two patches for lilypad: accept?
Hi guys, I see that there's two patches for lilypad: https://github.com/gperciva/lilypad/pull/4 https://github.com/gperciva/lilypad/pull/3 Are these good? I think that Phil Holmes (and Christian Hitz) can accept them with the github interface, but if not, please let me know if I should accept them. Unfortunately I'm preparing for a presentation at work (I'm now at AIST, Tsukuba, Japan) on Monday, and in any case I've forgotten most of what I used to know about GUB / lilypad / etc. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)
On Fri, Aug 15, 2014 at 07:58:26AM +, d...@gnu.org wrote: At any rate, putting Graham in the Cc since event-listener.ly or equivalent code is purportedly used in Vivi. The change in event-listener.ly is independent of this issue itself and should be applied to any similar code in order to avoid getting flaky results. Thanks for the heads-up! Vivi turned out to be a dead end (the machine learning technique I used was really inappropriate for the problem), but I'm still doing things with lilypond output. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld with Google two-factor authentification
On Wed, Jul 16, 2014 at 03:11:31PM +0200, Alexander Kobel wrote: My usual password is not accepted (which is good), since git-cl does not ask for the second-factor token (which is bad). And obviously git-cl is not able to cache the credentials - I get Could not find stored credentials $HOME/.lilypond-project-hosting-login each time. That is correct, git-cl does no caching, no fancy authentication, etc. It attempts to read the above file, and it takes the first line in that file as the username and the second line in that file as the password. That's all it does. Patches to git-cl most welcome. :) I've heard of this two-factor authentication, but I've never used it (even in my personal life), and git-cl was my first foray into authentication on foreign servers. I was kind-of expecting that somebody familiar with python+google+authentication to take 30 minutes (rough estimate for somebody familiar with the above) to fix it after a few months, but obviously there's been no takers yet. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote: If badly formatted = different than what fixcc.py would produce, i would say that LilyPond often gets badly formatted code - as you wrote, running fixcc now results in 400 lines of changes. This could, of course, be completely automated. Once fixcc.py has been run on the whole source code, each patch could be tested to see if running fixcc.py on it produces any changes. If so, then the patch would be automatically rejected and the submitter would be asked to run fixcc.py before re-submitting the patch. A less strict method of this would be to simply produce an automated warning. Or this could be deferred to the merge staging side of things -- if fixcc.py produces any changing on staging, then it is not merged with master. The question to ask is where do you want the burden of producing properly formatted code? - a volunteer who runs fixcc.py manually once a year? (this also produces code reformatting commits which disrupt git blame) - an automated process which demands that the initial submitter format the patch? - an automated process which demands that the pusher format the patch? (note that with new or casual committers, the pusher is not the same as the committer) I favour the first or third option; people heavily involved in lilypond can set up a git hook and always have properly formatted code (whether they write the patch themselves or simply push somebody else's patch). Asking casual committers to have a specific version of astyle seems like a high burden. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
On Mon, Jun 23, 2014 at 09:28:24PM -0400, Devon Schudy wrote: The cases where 2.04 does worse than 2.02 are minor; I don't think they're enough that fixcc.py should refuse to use it. Thanks for the analysis of astyle 2.02 vs. 2.04. I support switching to 2.04. However, fixcc.py should reject any version other than the specific version we want. Otherwise, you could run it on your computer (and push it), then I could run it on my computer (and push it), then you could do the same thing, and basically we'd end up with an infinite sequence of formatting changes. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New ponding: Urs Liska Berne lectures (issue 94960043)
On Fri, May 02, 2014 at 06:02:48PM +, lilyli...@googlemail.com wrote: Updated patch, now applied to master. I hope you mean now applied to staging. You should never push anything directly to master. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Sun, Mar 16, 2014 at 04:41:46PM -0400, Julien Rioux wrote: I think the following would be a good 1-2 punch approach for the current development cycle: First, upgrade python in GUB and make sure we can build current dev and stable branches of lilypond from it. Then bump the python requirement in the dev branch and start migrating to a codebase that supports python 2.6+ and python 3+ Sounds great! Thanks for working on this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: long-term goals (was: Lines and Ties and Slurs oh my!)
On Sat, Mar 01, 2014 at 07:07:39PM -0500, Kieren MacMillan wrote: I’ve know someone at Carnegie-Mellon University who is well-connected in the computer and music departments (he is both a composer and a programmer). I approached him recently with the idea of getting involved with Lilypond. He said: One possibility is that sometimes there are software engineering projects looking for tasks, so I might be able to point a class project at Lilypond in the future. I'm curious if there's a short summary of the direction for large-scale work on Lilypond. With all due respect for everyone’s time, I am bringing what is in my opinion an unprecedented opportunity to the Lilypond team — and I’ve got no response worthy of bringing back to my contact. Can nobody give me an “official” answer for him? My guess is that people are leery of inviting newcomers who might expect mentoring, when there is clearly no mentoring spots available. Our code base is notoriously difficult to learn, and if we specifically send a list of tasks to a professor, in my mind there's an implicit offer to welcome (if not teach) a student who tries to work on one of those tasks. This doesn't bode well for the long-term survival of lilypond, but that's something that's been discussed off and on for at least the past 8 years, so I don't expect any immediate change on this matter. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Clarify repeats w\ partials and barchecks (issue 61530043)
https://codereview.appspot.com/61530043/diff/40001/Documentation/notation/repeats.itely File Documentation/notation/repeats.itely (right): https://codereview.appspot.com/61530043/diff/40001/Documentation/notation/repeats.itely#newcode186 Documentation/notation/repeats.itely:186: measure, measure, the same principles apply, except that a unless my old eyes are misleading me, you have measure, twice. I guess you're doing some carpentry at home? Measure twice, cut once? https://codereview.appspot.com/61530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: CG - Updated Bug Squad List (issue 64680043)
Nobody on Friday? anyway, LGTM https://codereview.appspot.com/64680043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR Clarify repeats w\ partials and barchecks (issue 61530043)
https://codereview.appspot.com/61530043/diff/1/Documentation/notation/repeats.itely File Documentation/notation/repeats.itely (right): https://codereview.appspot.com/61530043/diff/1/Documentation/notation/repeats.itely#newcode167 Documentation/notation/repeats.itely:167: If a repeat, that has no alternate endings, starts in the middle of a I believe these commas are superfluous https://codereview.appspot.com/61530043/diff/1/Documentation/notation/repeats.itely#newcode185 Documentation/notation/repeats.itely:185: If a repeat, that has no alternate endings, starts with a partial ditto https://codereview.appspot.com/61530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Point-and-Click has wrong default value and ref to SVG output needs adding (issue 61630045)
LGTM https://codereview.appspot.com/61630045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Added Aurelien's 100-min Ring Cycle for children (issue 61640044)
LGTM https://codereview.appspot.com/61640044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Authors.itexi - Updated Current Developers list (issue 61360043)
LGTM https://codereview.appspot.com/61360043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: 1.4.1 Replaced deprecated snippet w\ @lilypond (issue 60840048)
LGTM https://codereview.appspot.com/60840048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
LGTM https://codereview.appspot.com/60490050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: misplaced comment produces wrong HTML output. (issue 60880044)
Was this fix produced automatically by running import-lsr.py (or whatever the script is called), or was it done manually? Remember that this file begins with % DO NOT EDIT this file manually If there's a bug in the import script, then this bug will just re-appear the next time somebody imports LSR. https://codereview.appspot.com/60880044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: make real destructive code innocuous. (issue 54910044)
LGTM https://codereview.appspot.com/54910044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: clarify because a «command» is not always a lilypond command. (issue 59220045)
Can't see the diff, but I'm not too concerned about a 2-line change. https://codereview.appspot.com/59220045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Text-input: make LM reference more friendly. (issue 51460043)
https://codereview.appspot.com/51460043/diff/1/Documentation/web/introduction.itexi File Documentation/web/introduction.itexi (right): https://codereview.appspot.com/51460043/diff/1/Documentation/web/introduction.itexi#newcode1138 Documentation/web/introduction.itexi:1138: before they come up! Occasionally new users are unnecessarily I prefer keeping a paragraph break here, since that makes the next sentence easier to see. https://codereview.appspot.com/51460043/diff/1/Documentation/web/introduction.itexi#newcode1139 Documentation/web/introduction.itexi:1139: irritated by some aspects of LilyPond's behaviour. Please read I suggest using unnecessarily confused rather than irritated. https://codereview.appspot.com/51460043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pre-review questions about image(s) and translations
On Wed, Jan 15, 2014 at 08:33:37AM -0500, Carl Peterson wrote: My first instinct is to prepare an SVG file that could be processed with inkscape or another program as part of the make process. That is not do-able for the website due to our hostingbuild situation. I've commented on this twice before, so please read the CG chapter on the website before continuing in this direction. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On Sun, Jan 05, 2014 at 10:38:04AM +0100, Werner LEMBERG wrote: I do not believe that there is a notion of package copyright in most countries' laws. On page http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html I see this: To update the list of year numbers, add each year in which you have ... not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. This answers it, doesn't it? Indeed it does. My apologies for missing that paragraph. - does lilypond follow the GNU maintainers' guide? I hope so. If we don't, we should access our working routines. I don't think we discuss the copyright range format in our README.txt, so that's one instance in which we don't follow it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
