Re: Google Code shutting down
On 03/05/15 16:53, Phil Holmes wrote: I'd be willing to start a draft "requirements for issue handling" document tomorrow, if no-one else is desperate. That'd be great, though it'd be even better if there could be clear requirements beyond merely those of issue handling -- code hosting, code review, automated testing, the full works. Anyway, whenever you have something to share, I'll try and follow up on whether it's feasible with Launchpad. (BTW I recognize there are concerns about switching to another 3rd-party service, even if free software; so please do treat anything I come back with simply as an FYI. I figure it's useful to have the information even if the choice goes another way in the end.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
On 10/04/15 09:34, Werner LEMBERG wrote: So the question is whether Launchpad has a usable API, right? Joseph, do you know more?c Just to follow up on this, I exchanged a few messages on Reddit with Colin Watson (who's leading the git-support effort) following this announcement: http://blog.launchpad.net/general/git-code-hosting-beta Looks like right now, git hosting is available in beta version, but webooks (e.g. to trigger automated testing) are not yet. Colin's expectation was that these would arrive soon, but for obvious reasons he wasn't willing to provide a concrete ETA. I'm going on the assumption that, with fully featured git support fully in place, Launchpad could host code, and handle both issue tracking and the review of merge requests (including automated testing); its issues allow the attachment of files (which ought to take care of Lilypond examples attached to issues, but I'd need to check that any file size limits meet Lilypond's issue requirements). However, I'd like to be sure I'm not missing any requirements, given Lilypond's rather particular needs. Any chance someone with a more detailed understanding of requirements than me could prepare a list of "must have" features for any new hosting service? Just something that I can run past launchpad folks on IRC or suchlike as a sanity-check that this really would be a workable solution. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
On 10/04/15 09:34, Werner LEMBERG wrote: While I don't like bzr, the launchpad interface for reporting bugs and the like looks OK to me. So yes, this is a possible solution. I think this has already been mentioned but just to chip in that it isn't just about reviewing patches, patches have to be tested too. While I can (and have) done manual patch testing in the past before the patchy scripts were created - it does add significant amounts of time on my part to test patches this way and would mean that the times during a given day of the week when I could test any random new patch (or three) would be severely reduced. So the question is whether Launchpad has a usable API, right? Joseph, do you know more?c It's certainly possible to do automated testing with Launchpad, but I'm afraid I don't know any firm details. I have asked a question via AskUbuntu that will hopefully result in some productive answers: https://askubuntu.com/questions/608379/how-do-i-add-automatic-testing-of-merge-proposals-to-a-launchpad-project ... and the Launchpad API docs are here: https://help.launchpad.net/API I did also find the following blog post on integrating Jenkins and Launchpad, but it's not really detailed enough to be useful: https://qualityhour.wordpress.com/2012/06/14/continuous-integration-with-jenkins-and-launchpad/ I'll keep looking into it and let you know when I have any more directly useful info (I have limited internet access at the moment, so not able to chase up on this as readily as I'd like). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Google Code shutting down
On 13/03/15 12:51, David Kastrup wrote: GitLab (like GitHub) does not run on free software. They have some "community" version of their software freely available at least. Gitorious was "eating its own dog food" with regard to running on their free software version, but they have just been acquired by GitLab, and due to licensing differences, Gitorious software will not be mixed with either version of GitLab. So the outlook for further company development of Gitorious is somewhat dim. Now Savannah is running on a continuation of the last free version of SourceForge if I remember correctly, so that would not be a real showstopper for picking up there. But the situation overall is a nuisance. Might be worth keeping a weather eye on Launchpad, as this is free software and is currently in the process of gaining git support: https://help.launchpad.net/Code/Git It's been a while since I last used it, but it has a nice combination of issue tracking, code review and hosting features. AFAICS it'll also support file attachments to issues, so should be able to support copying the .png's from Lilypond's current issue tracker. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 21:05, David Kastrup wrote: That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. I'm not sure that I feel happy about your benchmark for comparison. I think Lilypond's user base is a bit smarter than that ... ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some audicious hand-engraved slurs compared to LilyPond
On 03/12/13 14:25, David Nalesnik wrote: The problem is that the position of the tuplet number is tied to the placement of the tuplet bracket, whether it is drawn or not. I would argue that probably here the _real_ problem is that the tuplet bracket is designed to always place itself "outside" all the notes, whereas if you look at hand-engraved scores, you'd see that the likely way this would be handled would be for the number _and_ the bracket to be close to the beam, and for the bracket to be broken to let the couple of opposing stems through. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some audicious hand-engraved slurs compared to LilyPond
On 03/12/13 13:16, David Kastrup wrote: LilyPond's rendition of the slurs is actually reasonable readable. However, the measures take probably 40% more width. That's not necessarily a bad thing. My impression is that older scores are often more horizontally (and vertically) compact in order to save on the number of plates that need to be engraved and corrected. And the tuplet numbers are definitely awful. I tried it with 2.16.2, and the results were either equally awful, or one of the tuplet numbers was written in the middle of the beams. Can't reproduce this right now with -dpreview, however, so whether the tuplet numbers are in the clouds or the beams probably depends on some internal evaluation order. The tuplet number placement is bizarre. There's no reason why it shouldn't be close to the beams. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 23/10/13 18:22, David Kastrup wrote: Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost version of 1.802. Consequently, all the included fonts look like crap. The fix for this should now be released: https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments/19 We owe a vote of thanks to Iain Lane and Brian Murray for making this fix happen. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-voice slurs
On 09/11/13 11:10, Janek Warchoł wrote:
Hmm. Good question. Maybe it could be attached to NoteHeads, not NoteColumns?
(As i understand it, the problem with attachments results from the
fact that slurs are attached to notecolumns (the bound of the slur
spanner is the NoteColumn), and at staff-level the NoteColumns from
different voices are joined which makes them not specific enough.
However, if the bound was the notehead, the information should remain
specific enough).
I'd wondered for quite some time whether it would be possible to give slur
beginnings and endings some kind of identifier, so that one could mark the
beginning of a specific slur in one part, the end of it in another, and have it
Just Work; something like,
partI = { c4 d("foo" r2 }
partII = { r2 e)"foo" }
... but I'd assumed that this kind of thing must have already been considered
and rejected. (N.B. the particular notation chosen here is just for
illustration, not a serious suggestion.)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 07/11/13 22:21, Keith OHara wrote: The use of two alterations, natural-up and sharp-down, for the same pitch where the note-head is on the same staff-position is problematic to read. I would hope that composers choose one glyph and use it consistently within a piece. Your notational preferences (and mine) aren't really relevant here. The fact of the matter is that this arrowed notation is one of the two major "standard" forms of quarter-tone notation, so it's a good idea for Lilypond to support it properly in a way that is simple for the user. This is what I looked into. It seems to me that systems with finer intervals are necessarily more frugal and more systematic with the symbols they use to denote the alterations. I found no other cases where two symbols are conventionally used to represent the same alteration. Some composers have used the half/three-quarter sharp and flat accidentals for quarter-tones while using arrows for eighth-tones. The same issue arises, just for a different set of pitches. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PowerPC build of Lilypond 2.16.2 on Ubuntu 13.10
Hello all, It looks like there's a blocking factor in releasing the fixed Lilypond 2.16.2 on Ubuntu 13.10: the PowerPC build of the updated package is failing. Here's the build log: https://launchpadlibrarian.net/155579346/buildlog_ubuntu-saucy-powerpc.lilypond_2.16.2-2build0.1_FAILEDTOBUILD.txt.gz Does anyone have any idea why this error should be present? Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 07/11/13 07:26, Keith OHara wrote: The arrow notation also gives two options for the half-flat: natural-down- arrow and flat-up-arrow. If someone uses both options for the half-flat in the same piece, LilyPond can keep track of the choice by using a tuning system that has them at slightly different pitches. I've discussed at length why that is problematic. It also rapidly becomes unworkable once you start dealing with intervals finer than quarter-tones, simply because of the number of cases you have to deal with. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 03/11/13 13:53, David Kastrup wrote: We've been fingerpointing back and forth for years over this. Without an actual user/musician like Hans at least teaming up with a programmer, nothing will happen. It's not meant to be fingerpointing -- I'm not blaming anyone for development not moving on this item. I just think that re-awakening the discussion occasionally at least helps keep awareness of the issue in place, so if a developer thinks it's something they'd like to work on, we can take the conversation further. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 03/11/13 17:55, Hans Aberg wrote: As a preparation, LilyPond might get intervals: it is going to be too complicated to write out names for all pitch combinations. A pitch is defined by a written pitch plus a sequence of intervals added to it. Accidentals are a special case: intervals not changing the scale degree. You've raised a very important point that I was going to mention myself in slightly different wording. There needs to be a way of defining pitches that separates the work of defining staff notes from the work of defining alterations, and constructs pitch names as a combination of the two. The current method where (using English names) c, cf, cs, d, df, ds, e, ef, es, f, ff, fs, g, gf, gs, a, af, as and b, bf, bs are all defined, just doesn't scale when you are dealing with many different kinds of microtonal alteration. It's just about feasible, if you really want to, to define a quarter-tone scale this way. You can see this in the answer that I gave last year to a user who was interested in defining a 16th-tone scale: https://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00443.html So, there needs to be a way of saying: these are the staff pitches and the staff positions they correspond to (define c, d, e, f, g, a, b) and these are the alterations and the accidentals they correspond to (define -s, -f, etc.), now give me my list of available pitch names ... That isn't a precondition of solving the microtonal notation issue but it would be strongly complementary. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 13:36, Mike Solomon wrote: Doesn’t work, but all the files in flower compile fine with gcc, so I’m a happy camper. Apple’s home cooked clang is not free software, so there’s no reason to expect free software to compile with it. I don’t mind giving up on it. It's difficult to see how they could have cooked it to the point where what is AFAICS fairly standard C/C++ fails to compile with it. Anyway, if you want to leave it here, no worries. I just thought it might be useful for other people if we could tie down what the source of the problem is. Just for reference, do you have a log of what happens when you try running ./configure with CC=clang and CXX=clang++? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 03/11/13 12:34, Hans Aberg wrote: I know how to do it from the theoretical point of view, but somebody who knows the internals of LilyPond must do it. Of course. I'm just raising it as pertinent to the discussion. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 12:33, Mike Solomon wrote: [ ... snip ... ] …these fonts are always a pain, but I usually figure out some way to cheat and get them in there. But that shouldn’t have anything to do with the compiler. Well, what's odd is that your ./configure script says that it finds gcc: checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes and g++: checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking whether we are using the GNU C++ compiler... (cached) yes Yet your compile-time errors suggest that it is in fact clang that's being used. So, I suggest instead of just running ./configure, try instead: CC=clang CXX=clang++ ./configure ... and then see if the build works. (You can also add your custom CPPFLAGS to that.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 03/11/13 11:42, Joseph Rushton Wakeling wrote: For Lilypond in particular, the problem of supporting microtonal notation is less about symbols per se and more about the underlying representation of pitch, and how that relates both to accidentals and transposition. Specifically in relation to the Helmholtz-Ellis notation -- some of those accidentals would play very badly with existing Lilypond transposition rules. The double-sharp-up-arrow (i.e. approx +5/4 tone) and double-flat-down-arrow (approx. -5/4 tone) would clash with the hardcoded transposition rule that sees any accidental pitch alteration greater than 1 tone rewritten to a new staff pitch with smaller alteration. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 11:18, Mike Solomon wrote: Yeah, the output is fine (clean bill of health, all systems go). I had to specifically set CPPFLAGS to deal w/ some homebrew issues, but otherwise nothing out of the ordinary. Ahh, OK. That's odd; OK, I accept that the clang you have has been a little Applified, but I can't see an obvious reason why it should be fine to compile Lilypond with clang 3.3 on Ubuntu, and not on Mac OS. Obviously, do whatever you need to get things working and compiling again, but if you're so inclined I think it'd be worth trying to work out what the problem is -- it's better for Lilypond if it works with default Xcode. Could you try doing a fresh clone of the Lilypond git repo and build in there, just to test? Oh, and -- could you copy-paste the output of running ./configure, just so I can see? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal accidentals
On 03/11/13 11:20, Hans Aberg wrote: FYI, some "Extended Helmholtz-Ellis JI” accidentals [1-2], in fact designed quite recently, but a nice input. There is also a Unicode font at [3]. Notation also mentioned at [4]. The arrow accidentals that LilyPond has, are used for syntonic comma 81/81 alterations (staff system in Pythagorean tuning). LilyPond does not have those for double sharps and double flats. In addition, there are accidentals with double arrows, for double syntonic comma alterations, which LilyPond does not have. (And even triple arrows.) Some traditional quartertone accidentals end up on the 11-limit rational interval 33/32, which seems to be a good idea: in E72, it is approximated with E24 quartertones. 1. http://www.newmusicbox.org/assets/72/HelmholtzEllisLegend.pdf 2. http://www.marcsabat.com/pdfs/notation.pdf 3. http://www.marcsabat.com/ 4. https://en.wikipedia.org/wiki/Just_intonation Interesting references, thank you! It's worth bearing in mind that those symbols are far from absolute in their meaning -- different composers have used them to indicate different things. For Lilypond in particular, the problem of supporting microtonal notation is less about symbols per se and more about the underlying representation of pitch, and how that relates both to accidentals and transposition. Short version: in many microtonal notations, the number of enharmonic pitches is expanded -- but Lilypond has no way to represent these enharmonics. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 11:00, Mike Solomon wrote: That’s fine, I’ll download gcc. From what I understand from friends who've experienced the same, you'll have to manually remove/rewrite some of the symlinks. Just to check -- before you rework everything -- did you manually re-run the configure script before building? If so, what does it output? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 10:37, David Kastrup wrote: We committed a few Clang-related fixes in the past, I think mostly due to Graham's insistence/testing, but I think at some point of time the "compile with Clang" ambition just faded. I just tried a clang-based build on my Ubuntu 13.10 system, just to see what would happen: make clean CC=clang CXX=clang++ ./configure make -j2 It built fine, and also quite a bit faster than a GCC build. Version info: Ubuntu clang version 3.3-5ubuntu4 (branches/release_33) (based on LLVM 3.3) Target: x86_64-pc-linux-gnu Thread model: posix FWIW I've found it a good idea to test C/C++ codebases against clang if nothing else because clang is rather better at identifying ambiguities and potential errors and providing instructions for how to fix them. Mike, can you try typing on a terminal prompt both: g++ --version clang++ --version ... and tell us what you see? AFAIK Xcode 5 should include clang 3.3, i.e. the same version as my GNU/Linux system. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation errors from Xcode's new standard library
On 03/11/13 10:09, Mike Solomon wrote: Looks like some files in flower don't play nice with the most recent version of the standard library bundled with Xcode… Any ideas for how to proceed? If I understand right (I'm not a Mac user), latest Xcode has clang as default compiler, and symlinks the gcc/g++ commands to clang/clang++. So, these errors most likely arise because Lilypond compilation has never been tested with clang (apologies if I'm wrong, but I imagine Lilypond development has always assumed GCC). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3631 in lilypond: 2.17 does a worse job with vertical spacing and/or the page layout than 2.16
On 02/11/13 15:12, Mike Solomon wrote: Not sure what a git formatted patch is…I can, however, download the Rietveld patch and send it to you if you want. Git can extract text patch files from your version history, which can then be sent by email. It's a simpler way of getting patches to/from people than needing to publish branches. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 01/11/13 16:29, Joseph Rushton Wakeling wrote: There's now an updated texlive-binaries package in the saucy-proposed repository, which can be used to test Lilypond builds: https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments/11 The saucy-proposed repository now also has rebuilt lilypond packages (the full range -- lilypond, lilypond-data, lilypond-doc*). I've checked them out and AFAICS they are all now correct. Anyone else want to take a look? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where is PDF documentation typically installed (in Ubuntu)?
On 02/11/13 11:13, Joseph Rushton Wakeling wrote: I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the ones that have the fix for the mpost bug) and I'm finding something odd: I installed the PDF docs to check the fonts, but I can't find the actual PDF files anywhere in /usr/share/doc. Where are they typically located? Found it. I was expecting to find .pdf files but they're .pdf.gz, hence my searches didn't find them. Checking the contents of the .deb file itself indicated they are located in subdirectories of /usr/share/doc/lilypond/html. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Where is PDF documentation typically installed (in Ubuntu)?
Hi all, I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the ones that have the fix for the mpost bug) and I'm finding something odd: I installed the PDF docs to check the fonts, but I can't find the actual PDF files anywhere in /usr/share/doc. Where are they typically located? Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 25/10/13 13:45, Joseph Rushton Wakeling wrote: Just FYI -- I've had a response from someone at Canonical who has asked me to check a couple of things for them. Will update as/when I have more info. There's now an updated texlive-binaries package in the saucy-proposed repository, which can be used to test Lilypond builds: https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments/11 I've tested it out, and Lilypond rebuilt with the new package now has what look to me like the correct clefs, flags, etc. But it's probably best if others check too. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
More verbose doc build
Hello all, The building of the various manuals takes quite a long time, but the build process itself is silent so it's not easy to tell if they're actually progressing or have somehow hung. e.g. currently I'm just seeing: LILYPOND_VERSION=2.17.29 /usr/bin/python -tt ../scripts/lilypond-book.py -I . -I ./out-www -I /home/joseph/code/lily/pond/Documentation/snippets/out -I /home/joseph/code/lily/pond/Documentation/included -I /home/joseph/code/lily/pond/Documentation/pictures -I /home/joseph/code/lily/pond/Documentation -I /home/joseph/code/lily/pond/input/regression --process='/home/joseph/code/lily/pond/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlezh --header=texidoc --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2' --output=./out-www --format=texi-html --loglevel=WARN --info-images-dir=lilypond --lily-output-dir /home/joseph/code/lily/pond/out/lybook-db --redirect-lilypond-output learning.tely ... and no change, despite the fact that top reveals various changes of different tools being called. Is there a way to get slightly more verbose output? Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 25/10/13 19:31, Colin Campbell wrote: FWIW, after installing Ubuntu 13.10 and seeing my ../configure choke on the mpost version, I followede Werner Lemberg's suggestion from here: http://article.gmane.org/gmane.comp.gnu.lilypond.devel/55828/match=mpost+broken and all seems to be well. At least, I was able to make and install lilypond, then make and install the docs with no apparent errors, and that resulted in no obviously broken glyphs or flags in a quick test compile. Since the fix involves a quick download and replace, I'm wondering if it's *too* easy, but so far so good! Thanks :-) I think there should be a fix landing in Ubuntu soon, I managed to get the ear of the person responsible for the upload of the Ubuntu 13.10 texlive-bin and he has been very responsive and helpful. Fingers crossed ... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 23/10/13 18:22, David Kastrup wrote: Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost version of 1.802. Consequently, all the included fonts look like crap. Just FYI -- I've had a response from someone at Canonical who has asked me to check a couple of things for them. Will update as/when I have more info. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 25/10/13 12:09, David Kastrup wrote: Who knows? If they go with "TeXlive2013" as released for lack of a compelling reason... This is the version they have in the current development repositories: https://launchpad.net/ubuntu/+source/texlive-bin/2013.20130729.30972-2 That's the fixed version from Debian Unstable, isn't it? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 25/10/13 11:36, David Kastrup wrote: More like out-of-stylized. At any rate, incomplete flags actually impede the readability more than once per line. Again, if it makes any difference -- remember that this is a release with only 6-month max lifecycle, and that non-LTS (long-term-support) Ubuntus tend to really be favoured only by the more tech-savvy users. Next release will be LTS and should have the fixed metapost. So, this probably isn't quite as disastrous as it could be. Ubuntu development releases tend to be pretty stable these days, especially in the buildup to LTS, so it's almost tempting to upgrade immediately anyway ... Hmm, maybe wait 'til Alpha 1 in December. :-P ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 23/10/13 18:22, David Kastrup wrote: This can seriously affect LilyPond's reputation. Anybody putting together a comparison of various typesetting programs under GNU/Linux will more likely be using this version than any other. I don't know about other glyphs, but for what it's worth, the treble clef doesn't actually look _bad_ to me, just quite stylized. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 24/10/13 17:24, David Kastrup wrote: But they take the source package and compile themselves. I think it likely that's an automated process. Debian has already taken a fixed Metapost long ago, but Ubuntu has not updated the TeXlive binaries in spite of me reporting the problem. When did Debian get the fix? The Debian import freeze for 13.10 was July 25th: https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule Well, they upgraded to latest stable alright this time, and the packaging looks pretty convincing. But whether or not they upgraded LilyPond would have made no difference to the situation with the broken fonts: it would have just been the same if they had compiled an older version of LilyPond with that version of Metapost. Yup. It looks like the development version of Ubuntu has landed the updated texlive-bin packages: https://launchpad.net/ubuntu/+source/texlive-bin/2013.20130729.30972-2 ... so maybe it can be backported. I'll look into who might be able to help with this. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The catastrophe has arrived.
On 23/10/13 18:22, David Kastrup wrote: Of course, this was sort of predictable. Would we have been in time if we had immediately created a backport of the configure patch and named the result 2.16.3? I think it would depend on when you got it out by. As far as I can tell Ubuntu just imports Lilypond direct from Debian Unstable and doesn't make any direct intervention in it. I don't think there's even a volunteer contributor who takes any responsibility (which there is for e.g. Frescobaldi). There have been a bunch of occasions in the past when Ubuntu hasn't picked up on an upgraded stable release of Lilypond despite it being available, for exactly this reason. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 14:30, Carl Sorensen wrote: In our current workflow, once I submit a patch, it's a fixed submission. I have to resubmit a different patch in order to change it. In the gitlab workflow, when I submit a merge request, it's a dynamic thing. Any time I push my merge-request branch to origin, I'm changing the merge request. (Oh -- I just saw the protection against unintended changes -- don't push the branch to origin!) I found the opposite -- that whereas with GitHub any push to the feature branch updates the corresponding pull request, with GitLab that _doesn't_ happen; I had to manually click on the "Edit" button for GitLab to recognize that the head of the branch had changed, and then click "Save Changes" to update it. But maybe this is a cosmetic issue and actually if I approved the merge, it would be the branch head that got merged. I'll test. On GitHub personally I find this auto-update of the pull request useful. Apart from anything else, if you realize there's some small issue with what you submitted, it makes it trivial to fix, and it means you can have a fast turnaround between receiving reviewer feedback and responding to it with patches. If you wind up with too many patches in the pull request, you can always rebase and squash stuff before the branch is merged. More broadly, in the GitHub-style workflow (which GitLab is copying) it's a good rule of thumb to assume, "Don't push anything to any public branch unless you intend for other people to see and use it." ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 14:25, Carl Sorensen wrote: And based on Joseph's comments, it appears that I may be misusing GitLab a little bit -- we've not been using good descriptions of the merge requests (in fact, we may have not been using *any* descriptions of the merge requests) so the merge commits only have the git-generated statement about the merge. I'll try doing a better job on merge request descriptions and see if I like that better. No, you were right -- it's a current limitation of GitLab, and a very irritating one at that. See: http://feedback.gitlab.com/forums/176466-general/suggestions/3489764-allowing-custom-commit-message-for-merge-requests I think one workaround might be to perform the merge manually -- I'll let you know how this goes. GitHub does this in a much nicer way: the merge commit message references the pull request ID and includes at least the title of the pull request, so that you can always find the associated discussion and have at least an overview of what the merge does. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 11:11, David Kastrup wrote: Now it's rather hard to do a proper balance of the merits: basically we are not aiming for a "I could discipline myself into using xxx" verdict but rather for "this will definitely make things quite easier for me in the long run" for a majority of existing and potential contributors. Now testing a setup is, in a way, sort of an intellectual challenge, costs energy, and one is understandably proud if one masters such a challenge and does not want this work to go to waste. Well, it depends on the overall outcome. There's no shame in coming to the conclusion "OK, I spent a lot of time mastering that tool and in so doing I proved definitively that it doesn't work as well as other stuff I know." I may be very critical of Lilypond's existing tools, but I'm not going to try and push you towards an inadequate development environment just because I spent time trying to get it to work. But in the end, of course we are interested most in those experiments which ended up not challenging at all, at least from the user side. I'd rather have people try out five tools in a rather shallow fashion and report back their relative impressions than have five different people involve themselves deeply with a particular setup. That way we lose the focus on "easy for the casual user" and lose the comparison. Casual impressions of GitLab: it seems to offer broadly the same scope of functionality as GitHub (it's much more feature-complete and user-friendly compared to Gitorious). There are lots of little ways in which it is less user-friendly than GitHub; none of them are showstoppers, but any of them would be annoying to someone used to GitHub workflows. One single example: if you rebase and force-push a branch, open merge requests won't automatically pick up on the new code; you have to manually edit the merge request. It's two mouse clicks -- click "Edit", click "Save changes" -- but that's two mouse clicks you don't need in GitHub. It's a promising tool but not a perfect one, and it's playing catch-up with the state-of-the-art. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 10:01, Trevor Daniels wrote: The vast majority of my contributions are single-commit, and I suspect most other contributions are the same. They are easy to manage and generate a clean history with merge commits appearing only when they are appropriate. Our git repository was not always managed in this way, so the advantages of a clean history are obvious, at least to me. I wouldn't want to do anything to disrupt having a clean git history. Our current workflow already enforces: "No one pushes directly to master". Why is it "ultimately worth it" to lose a real advantage only to regain something we already have? It's not just about "no one pushes ..." but also about having, in the version history, a visible log of both who authored code and who approved its inclusion. I don't think the result is fundamentally less "clean" than the alternative of single-commits-plus-merges-when-necessary; what you actually ought to see is a linear history of one-merge-commit-per-new-feature. But I accept it's a matter of taste. Having worked with Carl for some years I respect his opinion, and for me his bottom line: "I'm seriously thinking of junking Gitlab because the benefit seems to be more promised than realized", based on his experience of actually using Gitlab on a real project clinches the matter. Before we risk people getting demotivated, I think we should be clear that at this stage it's unlikely that the advantages of any alternative will be obvious. If they were obvious, all of you would be leaping and jumping to get things set up this way and Janek, Colin and I wouldn't be having to do this exploratory work! The onus is clearly on us to make the case to you -- I'd simply like to ask that you all keep an open mind while we explore the possibilities. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
A couple of messages accidentally went off-list, forwarding them back here with Werner's agreement :-) On 21/10/13 08:02, Werner LEMBERG wrote: The other advantage is that the merge commit is "authored" by the person with master commit access who approves the merge request. So, you have in history not just who wrote what, but also who took the decision to include it. That can be valuable. Hmm. In case this is important, you have to GPG-sign patches, possible since git version 1.7.9. I think that lilypond doesn't belong into the category of programs where this is necessary. Yes, GPG-signed patches can be used to track authorization, approval etc., but as you say, it's overkill for something like Lilypond. I'm just talking instead about having an easily visible record of "Who reviewed/approved this?". It's surely a matter of taste, but personally on a large-ish project with lots of contributors, I find the "only merge commits in the master branch" approach to be quite useful as a way of keeping a clean overview of changes to the codebase, with the option to drill deeper if necessary. You might read http://mikegerwitz.com/papers/git-horror-story.html on this topic. Thanks for that -- had not come across it before. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 09:09, Werner LEMBERG wrote: Good to know, thanks. [I assume that `overwrite' still somehow retains the previously version for reference, right?] In the short term I think so (you'll see stuff in the comment history like "so-and-so commented on an outdated diff"). In the long run it seems to be discarded. You may recall that git periodically collects garbage from the version history, but on a time frame so that even "deleted" material is preserved for at least 1 month -- see: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html So I'm guessing that GitHub preserves this data until git collects the garbage from the repo. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 07:58, Werner LEMBERG wrote: I don't see a major simplification for the maintainer. The most important action IMHO for contributing a patch is to rebase, ensuring that the patch compiles with master. As far as I can see, github's ticketing system doesn't allow to simply update the patch; instead, you have to open a new ticket. Not true at all. Rebase your branch, then, git push -f origin my-branch ... will overwrite the contents of the pull request branch, and so update the request itself. I've done it many times. :-) Hopefully GitLab allows for similar functionality -- I will be checking this. Lilypond's two-level approach with separating issues from actual patches gives more consistency here. Please correct me if I'm wrong. GitHub has separate issues and pull requests, but there's automated coordination between the two -- so submit a pull request titled "Fix Issue #102" (or with a reference to Issue #102 in the description) the issue tracker will pick up on the fact that such-and-such a pull request has referenced that issue; and vice-versa if in an issue, I make reference to a commit or pull request. As Carl noted, GitLab doesn't have that automated relationship yet, but it should be arriving in the next release. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 07:41, Werner LEMBERG wrote: This latter thing bothered me too initially (with GitHub) as I was used to just pulling from the main repo to my local machine and submitting patches via email; but I quickly realized that it was actually sensible, and that those user repos are just places to publish one's own branches, which can then be submitted to the central project for merging. What me drives crazy is the structure of the main git repository. If you follow github style, the graph gets littered with zillions of `merge request' commits, one per pull request, which makes it quite hard to follow the development IMHO. It's true it can get annoying if you have lots of one-commit contributions. On the other hand it lends itself to being able to split your contributions into multiple separate commits for which the main git history simply gets a summary (the merge commit). I still think it's ultimately worth it for the discipline of "No one pushes directly to master", which helps enforce a requirement that everything gets tested and reviewed, even stuff by core developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 06:13, Carl Sorensen wrote: Even though it can be a pain to rebase commits, when it's done on the current Lilypond process I feel like the commit messages are much better than the ones that show up by default on Gitlab (merging branch xyz). I'll test this out on GitLab just to see what it's like. Working on GitHub I have never had any particular issue with rebases, but what I see as an issue may not be what you see as an issue, and vice versa ... :-) I don't like the proliferation of branches on Gitlab. I realize they can be automatically deleted when the merge is accepted (and that's the workflow I've been following, at least some of the time). But then that leaves an unmerged branch on the local system that it can be hard to tell when it is safe to delete. I don't like lots of branches hanging around in my local repository. I only like to have branches for issues I'm currently working on. I don't really understand the concern here, there's no reason why there should be more branches than for features/issues that are currently being worked on. Or do you mean that it bothers you that users are encouraged to clone the repo so there is a proliferation of project repositories? This latter thing bothered me too initially (with GitHub) as I was used to just pulling from the main repo to my local machine and submitting patches via email; but I quickly realized that it was actually sensible, and that those user repos are just places to publish one's own branches, which can then be submitted to the central project for merging. A consequence of that is that you don't need many people to have commit access to the main repo, and that can be kept very clean -- in fact, in well-managed project, the only writes to the main repository should be merges, with everything getting reviewed before it's committed. As for when it's safe to delete a branch: when it's been merged. GitLab should auto-detect that and recommend it via the UI, while on your local machine, git branch -d branchname will only carry out the deletion if it's safe. I don't like the fact that the commit message is different on origin that it is on my remote. Can you elaborate? This is odd for me because one reason I reacted badly to the existing Lilypond setup was that the commits I sent were being rewritten (e.g. my patch was automatically rebased with different author info, using my gmail address). I don't anticipate any similar problems with GitLab. Is it that, because GitLab asks for a merge request summary, you find that this gets used in the mainline commit history? But that's natural given that it's the summary for the _merge_; the commits that are merged in should preserve their own commit messages. I find the Rietveld interface for reviewing patches friendlier than the Gitlab interface, but that may be just because of my familiarity. Any particular features that you have in mind here? I haven't found a nice connection between issues and merge requests. I guess there isn't a nice connection in the current LilyPond toolset, either, but I was hoping that using an integrated system would make it easier. I didn't find it so. That's disappointing, but looks like it's a known issue that should be fixed soon: https://github.com/gitlabhq/gitlabhq/pull/4507 I had hoped that I could use the milestone facility in Gitlab to help with the connection between issues and merge requests, but haven't found a good way to do so. I suspect it's down to the same problem referenced above. As an overview (not really specific), I only have about 25 issues on my Gitlab project, but I feel more out of control about it than I do with the thousands of issues on LilyPond. I recognize that much of this could just be familiarity. It's difficult to teach an old dog new tricks, and I'm turning into an old dog. I'd be happy to take a look at how you're organizing things and see if I can suggest some better solutions. Out of curiosity, what were you using before you tried GitLab? Or is it a new project? I'm not opposed to having you and Janek work on an improved system. But for my little project (3 developers), I'm seriously thinking of junking Gitlab because the benefit seems to be more promised than realized. What kind of workflow are you trying to achieve? I wonder with so few developers if you're used to a setup where everyone is trusted and just has push access to the main repository, and GitHub, GitLab etc. do rather militate against that. I think that's a feature, but obviously not everyone is going to feel the same. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 21/10/13 04:00, Carl Sorensen wrote: I have to say that I much prefer the Lilypond method for handling tasks and reviews to the Gitlab method. Can you describe in more detail what it is that you like about how Lilypond does things, and how that is missing (or inferior) in GitLab? However, it is much easier to submit a merge request on gitlab than to submit a patch on Rietveld. Yes, that's the principal reason to want to pursue something like this. The goal is a situation where the handling of merge requests is as easy as possible, and all other necessary parts of code review (like testing) are automated behind the scenes, so contributors and patch reviewers just have to worry about their results. This latter part will most likely involve hooking some auto-testing tool into GitLab via its public API. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 20/10/13 11:15, James wrote: Yes, although I don't want to be considered arrogant that it should only be 'acceptable to me'; but when the last Patch-nanny decided he was going 'spend more time with his family' (so to speak speaking) and wanted to pass on the role to someone else, the silence from the LilyPond community was deafening. I know that real developers would pitch in if need be, but it has taken me away from doing documentation patches - my original role - as I simply do not have time to do this and any documentation that is of any significant size or that may require a lot of back-and-forth as we polish and refine some explanatory section that needs an overhaul. You may want to take a look at: https://gitlab.com/lilypond/lilylibrary/merge_requests/1 I submitted a trial merge request just so we could all explore the experience of reviewing a proposed change to the library. It's as near the GitHub experience as makes almost no difference (although there are a couple of tiny ways in which it seems to be different -- the most obvious is that there's no preview functionality for comments, which is cosmetic but still annoying). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 19/10/13 10:16, James wrote: The point is that when I am managing 15 patch reviews I don't (won't) read the email thread [1] I look at tracker, see what has been said, I click on Rietveld see what has been said; it's all there in front of me, no extra windows to click or open, one single application (web browser) to use, it's two tabs on my browser. Quick, easy, simple. Anyone who can read English can do it. Would the kind of thing you see here be acceptable to you? https://github.com/D-Programming-Language/phobos/pull/1332 https://github.com/D-Programming-Language/phobos/pull/1533 Note that the GitHub comment threads can also include extracts from the patch(es) under consideration, with comments directly under relevant lines of code. As per previous discussion, GitHub itself shouldn't be used for Lilypond, but I'm reasonably confident we can get similar functionality out of other tools. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
On 16/10/13 00:11, Janek Warchoł wrote: I need at least 2 people who'd like to experiment with me - doing this alone doesn't make sense. Colin, Joe - are you still interested? Anyone else? Yup, still in. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
On 05/10/13 19:01, David Kastrup wrote: Maybe you can use tlmgr for updating your Metapost. Well, you saw the error I encountered when trying to use tlmgr to do that. (Maybe I'm just misunderstanding how it works, I've never used it before.) No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Done. :-) Maybe downgrading Metapost is an option if you can't figure out how to upgrade. If Ubuntu don't do anything I'll try installing sid packages as you suggested. Can you confirm that my list of missing build dependencies is accurate? I'd be happy to send a CG patch about this (assuming I get to the point of a working build:-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 20:08, Joseph Rushton Wakeling wrote: In my experience it can help if more than one person reports the bug as affecting them (I've just done so). So, fingers crossed. By the look of it though, they just copy over from Debian rather than having any dedicated TeXlive maintainers themselves :-( Yup, their janitor bot has updated the bug's status to "Confirmed" now that I've asserted the bug affects me too. Hopefully that will prompt some action. There is an Ubuntu TeX team <https://launchpad.net/~ubuntu-tex>, and I've written to them to see if there's anything they can do. If not I'll try installing the sid packages as you suggest, but better to get it actually fixed in Ubuntu if possible. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 19:39, David Kastrup wrote: Joseph Rushton Wakeling writes: Unfortunately, nobody seems to be interested in https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653> Thanks ever so much for looking into the problem in this depth. In my experience it can help if more than one person reports the bug as affecting them (I've just done so). So, fingers crossed. By the look of it though, they just copy over from Debian rather than having any dedicated TeXlive maintainers themselves :-( ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 17:24, David Kastrup wrote: That's not a "workaround" since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? Currently trying to get it to set up a local texmf tree -- running any tlmgr command, e.g. tlmgr init-usertree or tlmgr update --list, results in the following error (I'm running on Ubuntu 13.10): (running on Debian, switching to user mode!) cannot setup TLPDB in /home/joseph/texmf at /usr/bin/tlmgr line 5308. ... any suggestions? Googling around isn't proving much help other than to find that it was a "known issue" earlier this year. :-( tlmgr --version gives: tlmgr revision 31259 (2013-07-22 00:07:38 +0200) tlmgr using installation: /usr/share/texlive TeX Live (http://tug.org/texlive) version 2013 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond build dependencies
Hello all, I'm trying to build Lilypond from git-HEAD source for the first time in a while and running into some curiosities from the ./configure script. This is on Ubuntu 13.10. First of all: ./configure requests a number of build dependencies that are not listed on the pages here: http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-running-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-compiling-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-building-documentation ... which included dblatex, epsf.tex (contained in texlive-generic-recommended) and lh (contained in texlive-lang-cyrillic). At a guess, perhaps these would typically be installed as recommended by the packages that are listed, so anyone (like me) installing _only_ what's listed (and its strict dependencies) will come up against this issue. I'm sure that if I'd just run apt-get build-dep lilypond all would have been fine, but the listed dependencies are the first thing one reads. The blocker to building is the metapost version currently in Ubuntu 13.10. ./configure reports: ERROR: Please install required programs: mpost (due to a bug in metapost, versions 1.600 <= x < 1.803 are not supported; installed: 1.802) What's the problem here, and is it possible to work around (i.e. tell ./configure "I don't care, go ahead and accept working with 1.802) or is the bug sufficiently show-stopping that nothing can be done bar install the updated metapost? Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 27/09/13 03:44, Graham Percival wrote: On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote: This risks becoming another corrosive discussion, Then WTF are you starting it? Because I had hoped that what I said was sufficiently qualified not to create bad feeling. Obviously I was wrong. I am happy to answer any of the questions you've asked, but I will not do so on-list, because it's obvious this will just perpetuate an unnecessarily divisive discussion. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 18:38, David Kastrup wrote: You commented on the issue where this patch originated as late as July: http://code.google.com/p/lilypond/issues/detail?id=1278#c7>. So it's hard to argue that it was not discoverable to you. This July I got an email update from the issue, and responded. The creation of the issue tracker was pointed out to you in a direct reply by Valentin in http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00424.html>. I was never unaware of the _issue_, it's the code review that I was not involved in (and did not receive email updates from). Most likely it's because the issue update with the link to the code review arrived on 30 December 2010, with subsequent updates going up to February 21, which was a period when I was completely snowed under with work issues. By the time I caught up with progress, the code review was long over and the patch had been abandoned. The discussion thread containing this pointer consists of four mails. Three of those mails were written by yourself, only the final reply with the pointer to the tracker issue was written by Valentin. I doubt that using a different tool would have changed your perception of never having been invited to take part in that review. There is a difference between getting auto updates on an issue and getting an invitation to participate or give feedback. When I've submitted code to a project that attempts to resolve a user's issue, I've usually written to them directly asking for their input and involvement. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:35, Joseph Rushton Wakeling wrote: Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. I should add that despite being the author of the original enhancement request, I don't think I was ever invited to take part in that review, which is a shame, as a number of participants seem to have misunderstood what I asked for. It may have just passed me by, though. I was working in a very intense and stressful job at the time and not following discussion very closely. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:16, Phil Holmes wrote: I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. _Conceptually_, the problem is this: Lilypond's pitch model consists of PITCH = STAFF_POSITION + ALTERATION where alteration is some fraction of a whole tone. (Actually there's no theoretical limit. You could have 3/2 of a tone, 2 tones ... although because the current transposition rules have a hard-coded limit of +/- 1, it's actually impossible in practice to transpose into keys where you might have triple sharps or flats. Hey, they do exist...:-) That model works fine for the standard 12 chromatic pitches, and it works fine for microtonal notation where each microtonal alteration is represented by a unique accidental. It fails for microtonal notation that essentially consists of PITCH = STAFF_POSTION + ALTERATION_0 + ALTERATION_1 + ... + ALTERATION_n of which quarter-tone arrow notation is one example (you have a first-order alteration which is the regular accidental, and a second-order alteration which is the up- or down- arrows). Ben Johnston's notation for "extended just intonation" is another example that very strongly relies on this hierarchy of pitch shading -- see e.g.: https://www.youtube.com/watch?v=0kVdgCWFJzE ... and http://notesfromadefeatist.blogspot.it/2010/01/just-intonation-notation.html for some explanation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:23, David Kastrup wrote: Well, you think that it's better to demoralize existing developers rather than hypothetical would-be contributors nobody knows. This is going to be a toxic direction of discussion if we pursue it, so I won't respond, except to say that it is not my intention to demoralize anyone, and I'm sorry if anyone does feel attacked or demoralized by what I've said here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. But in a way I think this is the point -- I'm likely to continue to be an occasional contributor, sending something in when I have something I'm enthusiastic about when I have time and space to work on it. As things stand it's difficult to get that enthusiasm because there's a load of finnicky and annoying things involved with making a submission. If the ease of contribution was comparable to GitHub, I'd feel a lot better about doing so. I do appreciate your offer to just send patchlists to the mailing list and let you guys handle them, and I will try and do that, but it's still not as nice as a good code-hosting system. By the way, I'm not advocating GitHub as a solution. I'm pointing out GitHub as a now typical example of typical user experience contributing to free software projects. I also think that kind of usability would also pay off for you and other core developers and code reviewers, even if there are is no substantial increase in patch submission. I can understand if you don't see things the same way, though. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:52, Phil Holmes wrote: I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: "We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in "the project would have received more benefit from the 10-minute job instead of the 5-hour work")" Check the results of the grand regression test review. This risks becoming another corrosive discussion, so please understand that what I say next is not intended as an attack on anyone here and is meant in a spirit of hope for Lilypond's prosperous future. There is another possible response to such a situation, and it's: "Oh wow, this person put a load of work in, they're obviously really committed and enthusiastic. OK, let's use these problems with what they've done as an opportunity to educate them better about how Lilypond works and how to avoid these kinds of problem in the future, and make them feel that we really value the time they've put in and want to repay them in kind." Now, I'm not assuming that no one has ever done this. I rather imagine it's been tried and that the resulting workload (probably mostly Graham's) has been overwhelming and that in fact there is no guarantee that it pays off in terms of another long-term contributor -- so people have been discouraged from this approach by hard experience. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. FWIW I think automated testing of pull requests is helpful here because test failures are impersonal and encourage the contributor to pro-actively sort out the problems in their code without having to be told -- there's not the same sense of personal rejection. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 11:48, Janek Warchoł wrote: David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? GitLab: http://gitlab.org/ Looks more feature-complete and user-friendly than Gitorious (it's got issue tracking as well as code hosting built in). You can use a hosted version (gitlab.com) or host your own version. It's MIT-licensed. They do a Red Hat-y kind of thing where they have an Enterprise Edition as well as Community Edition, but so far as I can tell from this summary, it's still MIT-licensed: http://www.gitlab.com/features/ ... so there shouldn't be any GNU/FSF-related political objections here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 13:56, Phil Holmes wrote: As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. Good. That should make the range of available solutions much broader. I'd see the way to approach this as in 3 stages: (1) propose the architecture of the solution and present a prototype with a "toy" project just so that everyone can try it out from a user perspective. (2) if people like it, work to get a prototype set up that works with the Lilypond codebase. (3) if people still like that, do any necessary work like importing issues, etc. and switch over to the new system. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:26, David Kastrup wrote: So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reason is that any good mailing list citizen will, before contributing, study some of the mailing list archives to figure out how things are usually done. There may be another side to this. Post-GitHub there has been a pretty substantial increase in the user-friendliness of DVCS. What's currently advocated in the Contributors' Guide stands in stark contrast to the ease of contribution (and contribution management) that many people experience as the norm now. I'll give one example, because it's not clear to me that people have understood my past objections to git-cl etc. Here's a currently-open pull request of mine in another project that I contribute to: https://github.com/D-Programming-Language/phobos/pull/1533 You'll see that below the summary there is a report from the project auto-testing facility, with a link to a more detailed overview of the test results. What that means is that -- as a contributor -- I just submit a pull request via GitHub's UI. Testing is taken care of for me, and the feedback is there and integrated into my pull request for me to read and (if necessary) respond to. Or, if I were a reviewer, I again wouldn't need to worry about the testing, except as information useful for my review. In other words testing is a completely automated process that requires no manual intervention from anyone and no changes to the standard GitHub workflow. Contrast that with git-cl, and also bear in mind how user-friendly GitHub makes pull request submission and review. Unfortunately in this case the tool is a custom-written one for the project, because they had some very specific requirements and at the time no one tool supported all of them. It's possible of course that now the existing tools would satisfy what they needed. So, it's not likely to be directly useful for Lilypond, but it _is_ a very good model of how testing can be integrated into code review in a non-intrusive way. Similarly, the project's bugzilla listens in on pull requests and can be automatically updated when an appropriate pull request lands (the requirement is that the pull request title contain the issue number, so in this case it's not 100% automatic, but then, how could it be?). All of this is orders of magnitude more user-friendly than what Lilypond currently operates and I don't think I'm wrong in saying that this kind of easy DVCS experience is now the expected norm for many developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: "Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket..." Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 20:16, David Kastrup wrote: Well, let's just say that our track record with "I'll contribute once everything is exactly like I want it, I could not expect to bother you with my help before" is not unlike that spelled out in Wilde's "The Devoted Friend" http://www.online-literature.com/wilde/176/>. Hmm, I think you do me a _little_ injustice there. :-P But thanks for reminding me about that story. It's far too long since I last read it. If you already find the suggestion offensive of working yourself on your preferred way of contributing, that does not make for a very encouraging outlook regarding other contributions. No, I don't find the suggestion offensive per se. We came to it in a bad conversational context. That said, I think I'd have reacted rather differently if you'd said something like, "Look, we'd love to see something better in place -- if you would like to try prototyping something or if you can point us to some examples of this working in practice we'd look at it with interest." There is some history to Graham saying "good!" for our current tools looking discouraging as indeed the complexity of working on LilyPond and its documentation system itself dwarves that of the contribution process, and so it's not necessarily ill intent that stops contributors short after the "VCS tool" hurdle has been placed aside. Agreed, Lilypond is inherently complex to contribute to, but I don't think that's ever an argument for complex tools. It feels a bit like saying that because rock climbing is inherently dangerous, no one should ever climb with ropes, because it'll stop the unskilled from trying to go to high ... On the contrary, my feeling is that the more complex the project, the greater the need for tools that are easy and pleasurable to use, because people need their mental energy _for the project_. I tend to find it a bit of a demotivator if a project is not strongly pro-active about ease of use both of their software and of their contribution mechanisms, because that usually means that there is tolerance of unnecessary (rather than necessary) difficulty, and that in turn means that often there are going to be unnecessary frustrations in getting things done. So don't worry about contributing only "nice and responsible". After enough naughty and irresponsible contributions of code and documentation, people will be more willing to listen to suggestions how your contributions could be made involving less manual work by others. I'll see what I can do. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 18:59, David Kastrup wrote: How about not worrying about the tools then and just doing your contribution any old way you prefer to work? We have procedures in place for picking up from there. I can give a detailed response here, but ... it's got a bit heated today. Shall we pick up tomorrow? :-) Short version: I like working with a project's tools where possible (it's the nice and responsible thing to do), and I don't like the idea of asking someone else to do manual labour in place of my using those tools. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 18:19, Janek Warchoł wrote: Whatever is meant by those saying it, at the end of the day it comes across as: "Hey, we don't care about your usability issues, we don't care that it's difficult and finnicky to contribute to us, we only care about solving that problem if you solve it for us." I believe that you are unjust to them. I chose my words carefully here, but perhaps not carefully enough. I wrote "whatever is meant" because I understand full well that it's extremly unlikely that anyone here really would not care. It's quite clear that much of this disagreement stems from concern over the practical impact of any changes to Lilypond's workflow and tools, and it's completely understandable that people would want to be cautious about changing from something that has flaws but works, to something that is unproven. Anyway, I sincerely apologize for this remark, although it was meant to be a comment on how to avoid unproductive discussion, in retrospect it rather serves as an example of how to engage in such ... :-( PS this will sound silly, but here's a smiley for you all: :-) I like you! Right back. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 18:05, James wrote: The fact our documentation is (even if I do say so myself) very comprehensive, is precisely because patches get reviewed and discussed before they are incorporated (this wouldn't happen with a wiki). Things like users reporting typos and simple changes often get fixed by other developers very quickly, if not tracker items get put up and it isn't long before they get fixed. Yes, a "raw" wiki like Wikipedia can be vulnerable to rubbish, but you don't have to operate like that. There's a nice balance in the solution found by Citizendium, where you have a "public" article which is stable and updated rarely, and a "draft" article which anyone can edit, but which is carefully reviewed and revised before its updates are copied over to the public page. That has a few advantages. If someone posts something that is in poor English, it doesn't have to be cut straight away (it hasn't changed the public page), and anyone watching that page can step in and correct it. Ditto if what has been written is unclear -- someone can make some revisions, there can be some back-and-forth, etc. And finally, review of changes isn't just limited to one patch, it's on a Talk page which everyone can read and follow, so the lessons learned there can be more broadly spread. Basically it means there can be more creativity and spontaneity in the drafting process, users' editing procedures are much more nice and simple, and you can still be rigorous in final review. But I understand that there can be other reasons why wikis etc. are not a desirable solution. Just out of curiosity -- was a wiki ever actually seriously attempted, or was it rejected because of the reasons you mention? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 17:10, Phil Holmes wrote: Poor syntax; poor explanation; unnecessary; failure to compile; failure to follow standards. OK. What are the typical patch-reviewer reactions to each of these? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 17:05, David Kastrup wrote: No, you are not just "asking". You are throwing diagnoses around and proposing solutions that are known not to work. I keep asking you questions because I want to correct my ideas and impressions if they are wrong. Still, I'm curious -- what is it about making a Windows development environment for Lilypond that doesn't make sense? Is it just the hassle with the dependencies, or are there other factors? You are probably assuming that Windows is the market leader for desktop operating systems because it the choice of engineers, picking the best product made by the best engineers to be found. OK, now I _know_ that your impression of me is false. :-) I did originally have some further remarks and questions about Windows development, but to be honest, I don't think they're helpful or relevant at this point. I never meant to sidetrack the discussion in that way. But what follows is I think relevant. My response to Phil wasn't meant to be cheap pontification, it was meant to be simply: "Here are a list of reasons why you shouldn't be complacent about the usability of your tools." It's always fun to suggest eating humble pie to others. But I really recommend getting some experience _before_ lecturing them. Forget big-picture pontification -- I never intended to engage in that. What it comes down to is this. I've contributed code and documentation to a variety of different free software projects. Lilypond stands out among them in being _astonishingly_ difficult to contribute to, and this difficulty is almost entirely down to the choice of tools and the way in which certain procedures are managed. In every case, whether it's git-cl, whether it's the way the bug squad duties are to be carried out, or whether it's how pull requests are managed, it almost always seems to come down to involving unnecessary mental and manual and custom-built work where for years there have been standard automated tools that would handle those problems. That makes me very, very sad because I love so many aspects of Lilypond and I want very much to contribute. But -- I'm sorry -- I don't want to tolerate unnecessary obstacles to contribution. I want the time I spend on contributions to be spend on writing code or documentation, not on working around finnicky tool problems. I'd be much more willing to temporarily put in that effort to work around those issues, if I felt that at least there was recognition of the usability issues I (and others) have raised. But every time there is this reaction: "Why don't you do it, then, since you know so well how it ought to be." Whatever is meant by those saying it, at the end of the day it comes across as: "Hey, we don't care about your usability issues, we don't care that it's difficult and finnicky to contribute to us, we only care about solving that problem if you solve it for us." And ultimately, that's very demotivating and makes everything about contribution feel bad. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 23/09/13 12:59, Graham Percival wrote: Reviewing patches? Explaining why we reject a patch (I don't think we can fairly reject a patch unless we explain why)? Those are significant costs. What are the most common reasons for doc patch rejection? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 15:45, David Kastrup wrote: "you" is you. So start fixing it. You know better than everybody else what is in need of fixing, so go ahead. Every time I raise usability issues related to the contribution tools, I run into this big wall of denial that there is actually a problem. And rather than recognizing this as a concern of someone who wants to contribute, you throw it back at me as somehow a sign of inadequate commitment, that I complain without solving the problem. I freely admit that I don't have all the technical skills needed to provide a solution to this problem. But I _do_ know what user experience I have contributing to other projects, and it is very, very different to what I have when trying to contribute to Lilypond. I don't think that it is wrong (or unhelpful) of me to point out that difference. The thing is, even if I _did_ have all the technical skills required, or if I invested time and effort to learn them, do I have any guarantee that my work would be rewarded with acceptance of my solution? The hostile reception to my saying, "Here are a set of usability problems" doesn't exactly encourage my hope that a solution would be welcomed. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 15:41, David Kastrup wrote: What about "Try it" did you not understand? Windows does not just allow you to say sudo apt-get build-dep lilypond Instead you have several dozens of dependencies you have to satisfy by hand, and then the fun with registry entries and other stuff starts. I didn't need to try it -- I already anticipated that it would involve huge amounts of hassle setting up the dependencies. I asked you simply because it was important to me to understand the problem as _you_ saw it. No doubt about that, but we're not in the situation to fix Windows. Is the problem Windows, or that many of the GNU dependencies are difficult to install on Windows? Look, before you have experience _maintaining_ a cross-platform software project, stop the pontification. At my last regular job, we had a publishing project with a TeX core and Java control logic and some scripting/packaging. All cross-platform technology, so we decided to offer a Windows version because everybody wants Windows and how hard can it be. A few man-years later (as there were several people working on it), we had the thing working. Deployments? Some. Eventually replaced by virtual machines running GNU/Linux since they were far more robust and unproblematic. LilyPond is doing _amazingly_ well. At least we deliver working packages that run on Windows. If you think that a development environment running under Windows for LilyPond makes any sense, I have the strong impression that you have no experience whatsoever what you are talking about. Note that I never said that Lilypond's delivered packages were inadequate. I don't know what kind of issues you have in practice with debugging and diagnosing Windows-related issues. Given other factors I can imagine that it might be less of a problem than the hassle involved in setting up development on Windows. Still, I'm curious -- what is it about making a Windows development environment for Lilypond that doesn't make sense? Is it just the hassle with the dependencies, or are there other factors? Pretty thinking gets us only so far. Well, I was responding to a post that said, "We have X, Y and Z set up to let users contribute, what's so difficult about that?" But there _are_ difficulties that result -- some of them quite explicit, some of them more conjectural. My impression here is that you're strongly locked in to certain difficulties because of historical choices about the design and architecture of Lilypond. In other cases I think those difficulties can be resolved, and fairly simply. My response to Phil wasn't meant to be cheap pontification, it was meant to be simply: "Here are a list of reasons why you shouldn't be complacent about the usability of your tools." git-cl does nothing that you can't do directly in the web browser, so why don't you use the web browser directly? Saves you complaining about git-cl. Do it for a few weeks of serious work, and you'll be glad git-cl saves you most of the typery/clickery. Your documentation says nothing about web browser-based submission of patches. Perhaps if it did, I would not have had the bad reaction I did. Suffice to say that what's easier for someone doing full-time work on a project, and what's easier for an occasional contributor, is not necessarily the same. I would also add: I have found GitHub pull request submission and review to be much, much easier than git-cl. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 15:34, Phil Holmes wrote: I imagine that one problem of using a VM is that it makes it much more difficult/slow to run such local tests? Not with current servers. GUB is built in a VM, much faster than most people could do it natively. Running on servers, sure. I was thinking of the case where people wanted to run the test suite on their own machine before submitting. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 14:22, Graham Percival wrote: I've done #1. I spent a WHOLE YEAR doing #1. It was an experiment. I was absolutely committed to teaching people how to do docs. However, #1 gives a net penalty of 25 minutes. One thing to add. I completely get how frustrating and annoying it must be to have someone like me, who has made a handful of small contributions in total, come and have a go at how the project handles things. I understand how that must feel relative to the huge commitment and effort you have put into the project. So, I'd like to make it clear that I'm not saying these things to have a go at you. I'm saying it because it seriously bothers me that certain tool choices place an unnecessarily large burden not just on contributors but also on you and other maintainers, who have to sort out that hassle. It's my personal belief that a couple of months spent really, seriously thinking about the tools used to manage contribution, and the ease of the contribution process, would really, really pay off in the long run. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 14:22, Graham Percival wrote: Suppose somebody sends you a bad patch that would take you 5 minutes to re-implement from scratch. Do you: 1) spend 30 minutes explaining how to fix the patch 2) tell them to go screw themselves 3) ignore the patch silently and give the person no indication of what went wrong. I've done #1. I spent a WHOLE YEAR doing #1. It was an experiment. I was absolutely committed to teaching people how to do docs. However, #1 gives a net penalty of 25 minutes. "oh, but maybe that person will do better next time" Yes. In many cases they did. So the next patch only took me 20 minutes to explain how to fix it. The one after that took 10 minutes. Then, on the 4th patch, it was ok without needing any fixes. So... currently we're at a deficit of 45 minutes. If they send in another 9 patches, each one doing a 5-minute fix, then we've broken even. If the problem is so persistent, I would suggest that this is a fundamental issue with the usability of your documentation tools and submission procesures, and that _this_ is the issue you consider fixing. Look at it this way. If you were starting a new software project from scratch, now, would you choose TeXinfo as your documentation format? Almost certainly not -- you'd probably create a MediaWiki instance and have people contribute there, and write a few plugins that would enable Lilypond input to be entered into the Wiki page and auto-generated into the desired PNG for display. Now, do you think you'd be having half the problems you have with tweaks to that wiki, as you are having with patches to your TeXinfo docs? Almost certainly not, because (i) the wiki gives immediate preview feedback during editing so that users can _see_ that their tweaks don't work; (ii) wiki markup is much simpler than TeXinfo; (iii) wiki markup is much more widely used these days, so many more people are already familiar with it; (iv) contributing to a wiki doesn't have to involve the command-line complication of handling git or any other VCS tool. TL;DR I think you spent a whole year _solving the wrong problem_, because you were attempting to train people to become long-term contributors who could work round the issues of the existing tools, rather than solving the real issue, which is: "How can I get things set up so that docs contributors GET IT RIGHT FIRST TIME even if they've never contributed to Lilypond docs before?" [*] [* Corollary: "... and so that if they get it wrong, they can see it and work out how to fix it themselves before it becomes my problem."] Your "suppose" and "maybe" does not trump my empirical evidence. Your empirical evidence reflects the fact that your docs setup makes it difficult for the 75% to easily create value. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 14:14, Graham Percival wrote: Umm, the whole point of the VM is to ensure that the contributor's setup is *right*. As far as I can see, the whole point of the VM is to get round the fact that the range of environments you can use to hack on Lilypond is severely restricted. I'm suggesting to you that this restriction is in itself a problem. That's way more fragile than having them use a VM. I don't know if I understand the history here. Were custom package repos tried as a first solution before the VM? Was it a practical history of failure, or a pre-judgement? I accept that faced with the situation of most devs being on Windows but Windows being impossible as a dev environment, a VM must be the only reliable solution. (5) In the specific case of git-cl, my own experience was that it was an absolute pain. Multiple (custom) commands to be typed; err, the whole point of the VM is that we provided a GUI to take care of patch submission. Compare that with GitHub: push patches to my own repo. Click on "Submit pull request." Type a brief description and click a button ... done. and then somebody else needs to check if it compiles or not. Yes, and repositories can be set up to automatically run test suites on submitted pull requests. This is how it should be done -- it makes no sense for a contributor to have to take any manual responsibility for submitting to the testing system. Of course, it's a good habit as a contributor to run the test suite on one's own machine before submitting a pull request (I always did this with LP submissions, even though they were docs not code). I imagine that one problem of using a VM is that it makes it much more difficult/slow to run such local tests? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 14:09, David Kastrup wrote: You _are_ aware that the _majority_ of current contributors is running Windows? Try setting up a native development environment for LilyPond on Windows. Come back when you are done. What is the reason for it being so difficult? and the risk is that users are failed because developers weren't aware of the needs and requirements in cases outside their own setup. Please compare LilyPond's track record to that of _any_ other project delivering binaries for Linux, FreeBSD, MacOSX (PowerPPC _and_ Intel, I might add) and Windows. We make a working development release every 2 weeks for all platforms. Which other project does that? Can you please get more specific about how we are failing our users here? Well, there could be a point of view that the fact that you can't set up a native dev environment on Windows is a pretty serious design failure. I don't know how much of a practical impact that has on developers' ability to diagnose, debug and test Windows-related problems. But the point wasn't that Lilypond is specifically failing on some particular point, the point was that by not designing to enable easy development and contribution access across multiple platforms, you wind up with a situation where the contributor base is constrained to those who can cope with your restrictions. I found the git-cl experience absolutely inexplicable given that at the time not only was GitHub offering the service it did, but similar experiences were available via Bitbucket, Launchpad and Gitorious. They don't offer command line interfaces into issue trackers, do they? Off the top of my head, I don't know. Why does that matter? The web-browser-based tools are much more user-friendly. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 24/09/13 13:58, David Kastrup wrote: Well, the usage conditions prohibit mimicking them, but then I have my doubts that this will stand before a court. So the worst that can happen realistically is that they kick you out. Which they can for any reason at all anyway. Hmm, I'd like to see the day when they start trying to enforce that condition. :-) The git-cl work was genuinely necessary for making it tolerable for command-line people to deal with the web interfaces of Google Code chosen for hosting and maintenance of the issue tracker, as far as I understand. You go mad if you have to do serious amounts of stuff in the "as intended" way without it. [... snip ...] So how do you set up Google Code properly? It's always easy to blame people for the things they had to do in order to work with the limited options available in the past. No, I understand that it was a workaround for limited options. What I don't understand was why, when faced with the need to make that workaround, the reaction wasn't, "This is an unacceptable complication given the functionality available elsewhere, we need to find new platforms." Again, I don't mean to sound intolerant, but it seems to me that many issues with Lilypond (and particularly contributing to Lilypond) derive from workarounds built on top of workarounds built on top of workarounds. That kind of situation is very easy to get used to and creates a lot of unnecessary difficulty for newcomers or occasional contributors. Heh. Are you sure you have an accurate view of what Savannah is and does? Not at all sure. Happy to be educated. :-) My impression was that it's a code-hosting and issue-tracking service dedicated to GNU projects, but I have never used it and so know nothing of the details. I do seem to recall that they were very slow at getting set up to work with git, bzr, and other DVCS's. The main obstacle is not making decisions but rather putting in the work required to follow through with them. What I'm getting at is that I don't see any detailed summary of pros, cons and how-this-will-work that might form the basis of a decision. For example: was Rietveld chosen on the basis of a thorough review of the code-hosting and testing services available, or was it chosen because it was the easy thing to get working with Google Code issue tracking, which you were already using? If the latter, then to my mind that was a workaround rather than an optimal decision, and it's obviously resulted in long-term problems (albeit that it clearly also fulfilled a need). What I'm concerned about is that future tool choices take Lilypond away from that sort of workaround-on-top-of-workaround situation. I honestly feel that the project will be saved a lot of long-term grief by choices of contribution tools that are future-proof, easy to use and easy to leave, rather than just something that most readily fits with the current setup. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 23/09/13 14:15, David Kastrup wrote: At any rate, I think the first thing we would likely want to experiment with would just be Gerrit. May be useful to you, if you haven't already read it: http://feeding.cloud.geek.nz/posts/code-reviews-with-gerrit-and-gitorious/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 23/09/13 08:59, David Kastrup wrote: It may be that something like Gitorious would obsolete Gerrit (as well as the Google issue tracker), but then we need to start somewhere. Gitorious has no in-built issue tracker. I think the normal thing is to integrate it with a project-specific Trac instance. Redmine can also be integrated with it AFAIK. If there are no objections in the next few days, I'll try bringing the topic up on the Savannah hackers list. I am surprised that Savannah doesn't already have a nice pull submission and review management system already in place. It's something they should implement. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 22/09/13 17:21, Phil Holmes wrote: IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a single command (possibly 2 commands, depending on what you were doing earlier). When the review is passed, it can be pushed to staging with 4 simple commands; or mailed to -devel for any active developer without push access - these are very rare. How hard is that? (1) If you need to install a VM or a custom distro flavour to hack on a project, your design setup is very likely to be wrong. If you really, really need contributors to use certain custom packages, you're almost certainly better off making custom package repos for the minimal set of dependencies. (2) If your developers are working on maintaining a custom distro flavour, that's a maintenance burden that is very likely a distraction from useful work. (3) If your developers all converge around a particular install setup, then you are missing out on important usability information from other platforms, and the risk is that users are failed because developers weren't aware of the needs and requirements in cases outside their own setup. (4) If your submission process involves non-standard software tools that are custom written for the project, you're probably doing something wrong (and again creating a maintenance burden for your devs). A distributed VCS should be sufficient out of the box. (5) In the specific case of git-cl, my own experience was that it was an absolute pain. Multiple (custom) commands to be typed; multiple _different_ issue numbers to be remembered (Google Code issue number, Riedveld number...), problems if they got mixed up ... and at the end of the day, it wasn't my patch that was applied -- the system rebased on a new patch using the email associated with my Google account, rather than simply applying the patch I'd submitted. Compare that with GitHub: push patches to my own repo. Click on "Submit pull request." Type a brief description and click a button ... done. I found the git-cl experience absolutely inexplicable given that at the time not only was GitHub offering the service it did, but similar experiences were available via Bitbucket, Launchpad and Gitorious. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 23/09/13 03:16, Graham Percival wrote: The experience from the Grand Documentation Project is that only 25% of new doc contributors ended up being a net benefit. Having an up-front hurdle, provided that it's well-explained, is a useful way to weed out people who are likely to fall into the remaining 75%. Granted, some of the 25% might also be turned away. So it's a question of the sum of values from all E(contributor | uses git-cl) % noting that the value from a contributor can be positive % or negative vs. sum of values from all E(contributor) I'm confident that the sum of the first is greater than the second. There is research on Wikipedia which suggests that many of the most useful contributions to articles come from "Good Samaritans" who show up once, make one or two crucial improvements, and never touch the article again. So, you should not consider the 75% to be without value -- you may find there is a better docs experience from many, many more people submitting rare patches, than from having a few more people submitting patches regularly. If you have a bad experience dealing with volume, I'd suggest that might be more to do with your choice of documentation system than a problem with volume per se. Finnicky problems with TeXinfo markup, Lilypond's custom extensions of it and so on will generate a lot of noise. On the other hand, if your docs were hosted on a Wiki with a couple of custom plugins to allow users to insert Lilypond source and auto-display the compiled image, you might find there to be far more people making _useful_ contributions without noise; and also, far more people being capable of offering supervision and management of the docs. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 23/09/13 14:15, David Kastrup wrote: GitHub's usage conditions are so aggressively proprietary and disenfranchising that it's not suitable for our regular processes. They reserve the right of shutting accounts and projects down if they don't like their bandwidth usage or for any other reason. They prohibit mimicking the "look and feel" of the GitHub web interfaces, and their software is proprietary. So they are pretty unfit for a GNU project like LilyPond aligning itself with them. That does not mean that individual contributors might not use GitHub for their personal workflows, but I would consider it highly inappropriate to move parts of the project-wide infrastructure there. Yes, I completely agree with that. They are very aggressively trying to colonize the "collaboration space" online, and it's very much at odds with any project concerned with freedom. However, it's worth looking into the technical side of how GitHub manages things like automated testing. The user experience of using GitHub to manage submission, review and automated testing of pull requests is extremely nice. If you don't have personal experience of that, it's worth looking into, just in order to appreciate what people are looking for. So I think the options we might be thinking about is seeing whether Savannah could host Gerrit (which covers just the review part of our processes as far as I could tell) and/or something like Gitorious which would cover more. Gitorious offers hosting, but it seems like that would mainly be interesting for getting a good first impression. If that's an option, it would likely be much preferable to run their software (it's AGPL) off Savannah. Of course, as a GNU project you could always switch your VCS to Bazaar and use Launchpad. Yes, I am joking. :-) More seriously -- can I humbly suggest that as a first port of call it's better to let someone else deal with the hosting and maintenance of whatever code-hosting/pull management solution you choose, and only roll your own if it turns out to be genuinely necessary? My personal experience is that Lilypond already suffers from too many custom-made and custom-hosted tools. In some cases this is obviously necessary, in other cases it seems to be a workaround for problems that are best solved in other ways. E.g. git-cl: http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review ... which in my experience is an annoying and cumbersome workaround for the code submission and code testing services either not working well together or not being set up properly. Code submission and testing shouldn't be more difficult than, "Push branch to public location, send public branch location to testing system." (In any decent code-hosting system, submitting a pull request should _automatically_ link in with the testing system.) I apologize if that sounds harsh or inconsiderate of the particular issues Lilypond development has faced, but I think it would be a good idea to factor into this decision how many custom tools and custom-hosted solutions can be completely eliminated [*]. That should both reduce the maintenance burden and also remove unnecessary obstacles for contributors. [* Without locking you in to anything. E.g. with Gitorious you _can_ roll your own, you just shouldn't need to.] At any rate, I think the first thing we would likely want to experiment with would just be Gerrit. I think before making any experiments or decisions, it's best to make sure that the following things are well known: (i) What Savannah offers _out of the box_ in terms of code hosting, easy web interface for submission, management & review of pull requests, hooks into issue tracking services (Google Code?) and hooks into automated testing services. (ii) Same for Gitorious. (iii) Any other code-hosting services out there that meet the free-as- in-freedom requirements? If the pros and cons of all of that are written up so that everyone can review it, then everyone is in a much better position to make a decision. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On 22/09/13 17:53, David Kastrup wrote: Yup. So we are talking about creating untested patches here that eventually travel into the usual testing pipeline we use. The main GitHub-hosted project that I'm involved with has auto-testing set up for pull requests, that's obviously integrated to some degree with GitHub itself (as the pull requests display info about test pass/failures). I don't know how much work might be involved or what tools would be needed, but there's certainly no problem in principle with using GitHub and having rigorous testing of all submitted code. In fact it should be easier for contributors to use than Rietveld because it entirely avoids the need for the custom tools that Lilypond currently uses for Riedveld submission. The major problems that I can see with GitHub are a mix of GNU (it's a non-free online tool) and the potential for lockin (GitHub is very obviously positioning itself to be _the_ online collaboration space and is developing a whole load of functionality that is only available via its web service and not offline). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: References to publications in the docs
On 07/13/2013 07:52 PM, Mark Polesky wrote: > Personally, I'd prefer to remove all mention of Gardner > Read's book. Many of his recommendations are not good at > all, and I've found a fair number of them that are just > wrong. Better to say that it's out of date. But its datedness is one reason it's valuable, because some of its notational suggestions will be found in actual works of the time, but not in more modern notation manuals. > Kurt Stone's book addresses everything that Gardner > Read's book covers, and is much more carefully written, and > far better for reference, though one or two things might be > a little outdated (like percussion pictograms, which are > discouraged nowadays). Yes, Kurt Stone's advice is generally better and more in touch with standard practice. It was after all the result of the Ghent conference which standardized a lot of contemporary notations. > Regarding your actual question about listing these in the > LM, I wouldn't be opposed, though you might consider putting > the list at the end of the "Common notation" chapter > instead. The reason for putting them there was to ensure that the reader had some clear recommendation: "These are books to look at if you are interested in particular in the notation of avant-garde contemporary music." But do as you think best. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: References to publications in the docs
On 07/13/2013 02:11 PM, Federico Bruni wrote: > It was ignored from the very beginning (perhaps a kind of todo list): Pretty much. At the actual time of writing there was some discussion of whether or not to include info on interesting scores to look at, the general feeling was against, but no conclusion was reached and so nothing got updated. I should apologize that the whole contemporary notation section isn't fuller and more fleshed out. Motivation on it kind of got lost when I realized that certain very simple contemporary notations (e.g. arrowed quarter-tone notation) were unacceptably complex in practice, and though some people did attempt to work on that, AFAIK nothing came of it. See: https://code.google.com/p/lilypond/issues/detail?id=1278 ... for some of the details. But the main reason was that I took up a new job which had me too busy to focus on following up on the work. :-( ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 05/09/2013 02:52 PM, zepadovani.li...@gmail.com wrote: > just installed 2.17.17 and it seems that the new (and nice!) angled > hairpins are not compatible with the circled tip I think this should be considered a bug, as the two notations are clearly compatible. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
On 03/26/2013 06:27 PM, David Kastrup wrote: > It might even make sense to try getting Steinberg on board. They have > just acquired the old Sibelius developers. Now the focus I see for > LilyPond itself is bringing it into line for operating it with a growing > corpus of public domain music. We'd bring in music academic partners > for the sake of entering music into a MusicXML based database. We'd > want to move to a Mutopia 2 web framework that makes it easy to check in > music in either LilyPond or MusicXML form. This sounds like something well worth pursuing. However, a note of caution -- building this kind of conversion functionality into LP and other software, and building a MusicXML archive of public-domain music, are unlikely in themselves to be things that would excite a research funding organization. If you want to secure research funding, the main part of the proposal should be on the things it is possible to do _on top_ of such functionality and archival material -- you can see this very clearly in the call which is talking very much about media/device use, user interfaces, interactivity, etc. etc. In other words your starting point has to be a pitch for what you want students, teachers, etc. to be able to _do_, the _functionality_ that you want them to have and the ways in which it will be beneficial educationally. And you need to bear in mind that some of our ethical concerns and desire to free music, etc., are unlikely to be worthwhile considerations for the funding body. That's not to say you can't provide them, it's just that the focus of the project proposal should be on the factors which are of research interest, and these technical details should be a (probably minor) part of the proposed delivery mechanism. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
On 03/26/2013 11:52 AM, Han-Wen Nienhuys wrote: > Take in mind that EU research programmes come with an incredible > amount of burocracy and require both academic and industry partners, > the more the merrier. The projects that get funded are buzzword > compliant, but often nobody knows what they set out to do, except > divert EU money into the partnering institutions. Buzzword compliance is not particularly a problem, except for the fact that you want to chew your own head off after writing all those sickening words ;-) And the bureaucracy is mainly a matter of time and effort -- it helps very much if you have some people who can effectively be full time preparing the grant proposal. But I agree that the academic/industry partnership is the key thing to get right. There is a bias towards prestigious institutions, and towards pan-European and cross-disciplinary projects that also bring in industry partners. So ideally I think that what you'd want to have is _at least_ two fairly prominent music colleges in different countries together with _at least_ two different computer science departments in different countries, _at least_ one reasonably well known music publisher, and preferably at least one other research group from a different discipline (in this case, educational research seems like an obvious choice). Reading not too deeply between the lines it looks like what they are really after is tablet and smartphone based learning solutions, with the goal being to get apps on popular devices. So you could also look for another industry partner in the form of developers for mobile/touch platforms. In fact the ideal might be an app that allows a well-known publisher to disseminate their published works on tablet/smartphone in a way that allows a great deal of interaction with those works. Would I be right in assuming that this is quite a UK-driven call for participation? It sounds like the sort of thing which is being pushed in British education. And, sad to say, it wouldn't surprise me if this call has been issued in anticipation of a preconceived product development by Sibelius (despite UK office defunct-ness), Finale or Steinberg, in collaboration with already selected academic partners ... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 03/17/2013 06:47 PM, thomasmorle...@googlemail.com wrote: > And while above the staff dynamic brackets have the hook down. As I said before, I'd have argued for that feature even in the absence of a Ferneyhough example, as it makes musical/notational sense. But I think the example settles it. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 03/17/2013 05:28 PM, m...@mikesolomon.org wrote: > My suggestion was flairpin, which is infinitely cheesier and thus way cooler. I know, but ... at the end of the day, less clear in meaning than either ferneyhough-hairpin or flared-hairpin. Sad but IMO true. :-P ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 03/13/2013 12:22 AM, Janek Warchoł wrote: this reminds me of an idea i had that would probably play nicely with this: make it possible to manipulate hairpins' ends separately. The point would be that you could specify a vertical offset for one end and thus easily achieve a slanted hairpin (without going into hassle of figuring out rotation angle, doing trigonometry etc). Would be even better if LP could figure out optimal height for the ends of a hairpin based on surrounding dynamic marks and note positions, and calculate angle accordingly. One of my (minor) frustrations with Lilypond is that the ends of hairpins don't necessarily line up with nearby dynamic marks -- calculating the optimal vertical position of dynamic marks and hairpin ends could probably be better interrelated. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Feta font license
On 10/18/2012 09:38 AM, Han-Wen Nienhuys wrote: The idea behind this is twofold: first, the GPL does not make sense for a font. That's not entirely true. Obviously it's not a good condition for use of a font in a document, and you _can't_ copyright the _appearance_ of the font, but it makes sense for GPL to be applied to the underlying "code" of a font so long as you have an exception in place that permits embedding in a document -- see: https://www.gnu.org/licenses/gpl-faq.html#FontException https://www.fsf.org/blogs/licensing/20050425novalis Second, the font can be used independently of LilyPond, and thus it is in a sense a standalone work, the use of which does not create a derivative work. Yea, this seems a broadly correct assertion with respect to fonts although the precise interpretation might differ depending on whether (and how) you bundle the font together with other software. On a related note, this raises the issue of how Lilypond itself bundles the fonts -- as an internal part of Lilypond, or to install as a system font? See: https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/174369 AFAICS this latter issue is why e.g. if you open up a Lilypond-generated SVG, PS, etc. in Inkscape, all the Feta font characters display as gobbledegook. Although, this project in particular is not GPLd, questions about using Feta have popped up from time to time before from others, and the OFL is a way to answer all these questions in one fell swoop. Even with just GPL+exception (the embedding exception is important; is it in place for Feta?), it's most likely possible for a non-GPL, even proprietary, application to use the Feta font, and even distribute it as part of a collection of software, so long as the font is included as a standalone element and not integrated into the code in other ways. It may be worth touching base with FSF and related bodies on this. But (GPL+exception)+OPF is a fairly standard way to licence a font and does remove uncertainties on the part of other software developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On 10/13/2012 11:44 PM, David Kastrup wrote: \once creates a one-time-step temporary change, \temporary an unterminated temporary change which can be terminated element-wise with \revert or, again using a converter, en bloc from the original overrides with \undo. Forgive me for coming into this without the background, but what's the difference between \temporary and the existing \override? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 10/10/2012 09:52 AM, David Kastrup wrote:
However, forcing a certain form of input representation for a certain
form of output is a nuisance for programmatically generated music.
I'd rather recommend using something separate like
\tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".
That's fair enough, but I'm still inclined to think that whatever the display
style used, there may be some value in allowing tuplets to be entered not just
as ratios of numbers, but as ratios of musical durations: e.g. {8*7}/{4*3}, or
{16*6}/{8.~8}.
Note that unlike my earlier suggestion I'm _not_ proposing this as a way to
force a particular display style, although it might be useful in _enabling_ some
display choices (hope that distinction is clear).
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clefs and transposition [was: Re: [proposal] easy triplets and tuplets - Draft 3]
On 10/10/2012 12:08 AM, Joseph Rushton Wakeling wrote: Yes, definitely a bad idea. Use 8va. brackets instead when you want to send everything up an octave like that. It was fine for _you_ because you wrote it and knew what you wanted anyway, but it would have probably been confusing for anyone else who had to read it, at least at initial glance. Anyway, _most_ of the time you shouldn't need to do any such octave shifts -- it's only at the very extreme upper end of the instrumental register (and sometimes lower, e.g. on piano) that you would bother. All of this (and what follows) seems rather aggressive and blunt on a second reading -- wasn't meant to be. Apologies. :-\ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
