Re: make dist broken
On Wed, Feb 15, 2012 at 08:24:23PM -, Phil Holmes wrote: I did look, but in the end it was easier to find the problem by looking at what happened in make dist. Documentation/lang/GNUmakefile has a line like: SUBDIRS = essay learning notation texidocs usage web extending included which lists the subdirectories. I'm 99% certain that adding include to the new languages will fix the problem. So am I. You want me to do this, test and push to staging then master via patchy? Yes. FWIW I can't _really_ check, because my system doesn't have a rule for distcheck, but I can check the tarball from make dist. Don't bother checking. Just stick it in staging and run staging-merge. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make dist broken
On Wed, Feb 15, 2012 at 10:18:02PM -, Phil Holmes wrote: OK -as remarked in my previous mail patchy-merge fails with: I currently have no idea why this is. ok, I'll try running it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Mon, Feb 13, 2012 at 09:37:44PM +0100, Christian Hitz wrote: Am 13.02.2012 um 13:36 schrieb Graham Percival: Should I tune osx-lilypad-universal-0.6.tar.gz to be compatible with GUB's installer.py? Anyway, here is a patched version: http://klarinett.li/lilypond/osx-lilypad-universal-0.6.1.tar.gz Is that based on the code here? https://github.com/gperciva/lilypad I think we need to have fewer versions of this source code floating around. Could you send a patch for whatever it is you did to make 0.6.1.tar.gz ? or if you only edited the binaries after compiling it, could you document the changes you made in some file in that repository? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB failure
On Tue, Feb 14, 2012 at 04:40:54PM -, Phil Holmes wrote: ERROR: ld.so: object '/home/gub/gub/target/tools/root/usr/lib/librestrict.so' from LD_PRELOAD cannot be preloaded: ignored. hmm. Command barfed: tar -C /home/gub/gub/target/darwin-x86/installer -zxf What happens when you run this command manually? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Tue, Feb 14, 2012 at 09:38:15PM +0100, Christian Hitz wrote: See my pull request on GitHub: https://github.com/gperciva/lilypad/pull/1 Pulled, and I've made you a collaborator, so presumably you can push directly to that repo now. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Mon, Feb 13, 2012 at 09:37:44PM +0100, Christian Hitz wrote: Anyway, here is a patched version: http://klarinett.li/lilypond/osx-lilypad-universal-0.6.1.tar.gz Thanks, uploaded to lilypond.org in the usual place. I've made you a collaborator for the GUB repo so you can push a change to the installer builder like Mike did. Alternately, just make a pull request. https://github.com/gperciva/gub/commit/d68db61ba823ff2bb9e07b89d638e859704bdf21 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Final redirection of texi output (issue 5650064)
On Mon, Feb 13, 2012 at 11:05:56AM +, d...@gnu.org wrote: scripts/build/run-and-check.sh:2: eval $1 $2 21 Actually, it is totally basic shell scripting here. Well, apparently you don't need basic shell scripting for 7 years of full-time linux use and 4 years of macosx use, and thousands of hours of open-source work for multiple projects. I've called programs, I've used for loops, but anything fancier than that is done as a makefile or python. My rule of thumb is that if I don't understand something easily, then at least 50% of future lilypond contributors won't understand it either. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Sun, Feb 12, 2012 at 09:39:59PM +0100, Christian Hitz wrote: Am 11.02.2012 um 19:57 schrieb Carl Sorensen: Yes, and I'm aware of that two-line fix. It gives ppc support, but I think it also gives a bad version of LilyPond when the About menu item is checked. I may be wrong on this. I want to check the sources before I make the final decision. The app bundle contains the version that was current at the time of the creation of the bundle. If I understood GUB correctly the version should be corrected in the Info.plist file when building the installer package right here: https://github.com/janneke/gub/blob/master/gub/installer.py#L341 Hmm, that's a good place to start! It's possible that simple replacing that 2.11.41 with whatever the current build uses (2.14.2, I think?) would make it work. Granted, that's a fragile solution that requires changing whenever the osx-lilypad build is updated. But when I compare these instructions to the version strings I have put into the 0.6 bundle, it becomes clear why the version is not being updated: - for the Info.plist I omitted the build suffix (only 2.15.22 instead of 2.15.22-1) - at some time I have bumped the version string in Credits.html and Welcome-to-LilyPond-MacOS.ly to 2.14 but installer.py expects 2.12 Should I tune osx-lilypad-universal-0.6.tar.gz to be compatible with GUB's installer.py? I don't know. As an aside, another place to look is gub/specs/osx-lilypad.py I don't think that the darwin-related commands in gub/specs/lilypond.py are relevant, but I could be wrong. Not relevant to the osx stuff, but in case anybody is curious: the windows lilypad is buitl from gub/specs/lilypad.py - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Final redirection of texi output (issue 5650064)
On Mon, Feb 13, 2012 at 12:47:22PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: My rule of thumb is that if I don't understand something easily, then at least 50% of future lilypond contributors won't understand it either. eval is ugly and a little-travelled corner, and it might be necessary to write ... So I am really quite doubtful that we reduce complexity with this shell script which, after all, also needs to gets called with the correct path. I'm not talking about reducing complexity by changing the code. I'm talking about dumping a two-line # eval calls the command $1 and redirects it to the log file $2; # the !2 makes sure that both stderr and stdout are saved # to that log file. (if that's what's actually happening) It takes fewer key presses and less time that we've spent discussing this to add such a comment, yet it may save somebody an hour or more down the road. I think it's worth doing. Sure, you could argue that anbody who doesn't understand that much about shell scripting shouldn't be modifying our build scripts... but history has shown that often the only people who have time to work on our build scripts know very little about shell scripts (and build systems in general). The fact that we have Julien and Phil working on it, with active reviews from you and Reinhold, is a historical aberration. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regenarating png from svg files
On Mon, Feb 13, 2012 at 02:46:01PM -0500, Julien Rioux wrote: On Mon, Feb 13, 2012 at 2:38 PM, Francisco Vila paconet@gmail.com wrote: Images should be pushed along other changes, and also to our branch. Graham has to authorize something afterwards for those to be visible. Forwarding to him. Not any more. The whole point of lilypond-extra and $LILYPOND_WEB_MEDIA_GIT is that it just gets pngs directly from that repo. Anybody can update those. (if they have push access to the lilypond-extra repo, which I give very easily) If that's not clear from the CG website chapter, that's a bug. I didn't realize that. I pushed only the changes to these two .svg files: Documentation/pictures/text-input-parts-both-annotate-de.svg Documentation/pictures/text-input-parts-single-annotate-de.svg I wrongly though that .png files were created as part of the build. So: 1) New .png files should be generated from the two changed .svg files, Correct. IIRC there was some problem with fonts when trying to use imagemagick for the automatic build process? The last time somebody looked at this was 2008 or so, so maybe it's better now? 2) These files should be pushed to the main git repository, and Yes. 3) Same files should be pushed to lilypond-extra repository. I'm not certain about that. I think that for png files in Documentation/pictures/, there's no need for files in lilypond-extra. ... that said, I see those files in lilypond-extra/pictures/, so maybe they _are_ needed. Hmm, the only way to find out is to try reading make/website.make, and/or doing a few experiments. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor documentation nitpick
On Sun, Feb 12, 2012 at 12:47:36PM -, Phil Holmes wrote:
Automatic footnotes take three arguments; the @var{Layout Object} to be
annotated, the @var{(x . y)} position of the indicator and a
The texinfo manual says:
Use the @var command to indicate metasyntactic variables and so it
doesn't like the parentheses, since I assume a parenthesis cannot be
part of a variable name.
aha, that's where it comes from! this has been bugging me for 7
or 8 years.
Ignore, replace the @var with @code, or what?
Let's make it a
@c weird construct to avoid complaint about parentheses ()
@c inside @var
annotated, the @emph{@code{(x . y)}} position of the indicator and a
IIRC @var{} is displayed as @emph{@code{}}. I don't like using
formatting commands directly, but let's do it anyway.
(oh, it might be nice to send a feature request to the texinfo
guys... but it's been years and years since they last had a
release, so let's use the workaround)
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code - Ideas List, please discuss
On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
2) Adding comprehensive MusicXML import and export features, together
with test suites for it. Requirements: ? (no idea in which language
this would be written), MusicXML, basic LilyPond and music notation
knowledge; familiarity with other scorewriters would be a nice bonus
(for cross-testing). The goal would be considered achieved when a
(previously chosen) not-so-complicated score could be imported from
MusicXML and exported back with no (unintentional) loss of data.
umm, you know that we already have musicxml2ly import, right?
I agree with having this on the ideas list, but it should
definitely mention musicxml2ly.py and basic familiarity with
python. The export would most likely be in scheme, although it's
not impossible to imagine that somebody might write a relatively
simple scheme exporter to an intermediate format (or just use
\displaymusic{} ), then use python to construct the actual
musicxml file.
5) Build System Improvement: if we want to ever move away from make,
this would be a good opportunity. Issues like thousands of errors and
warnings during compilation should be removed, all dependancies fixed
(so that one doesn't need to remove fonts folder to have fonts
rebuilt). Requirements: Python, Make and (optionally) another build
system.
I think this item needs rewriting. If Phil and Julien want to
highlight exactly what is left, great; otherwise I'd be tempted to
leave it out.
Then again, it's just possible that Phil or Julien might be
interested in being student in GSoC, in which case we should
definitely include this as a project.
6) Grand SlurTie Project - quite often LilyPond produces bad-looking
Don't call it Grand. It would be a big chunk of work, sure, but
don't underestimate how much can be done in full-time work.
I'd add another item to the list:
n+1) clean up compiler warnings, static code analysis, and
valgrind warnings. Automatic code analysis tools (warnings in g++
and clang) and analysis tools like valgrind memory leak detection
and callgrind code profilers provide valuable information about
possible flaws in C++ code. It would be great if somebody could
clean up those warnings, as this would allow us to automatically
reject any patch which introduced extra warnings. Once compiler
warnings are fixed, analysis of memory leaks and profiling would
be great.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
alternate GUB repo giving out access
I've forked the GUB repo so I can easily give push access to people like Mike: https://github.com/gperciva/gub The CG has been updated. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
2012/2/11 Carl Sorensen c_soren...@byu.edu: In order to try to track this down, I'd like to have a git history to see how things have changed. [...] Can anybody tell me where I might find an up-to-date repository? https://github.com/gperciva/lilypad As of 2012 Feb 12, this is the latest repository for lilypad (the build-in editors for lilypond on OSX and windows). Notes: - this is the code which is used for our official GUB binaries. - does not contain work that Patrick did on 2010-01-19: http://repo.or.cz/w/lilypad-macos.git the same commits appear in this repository: https://github.com/pnorcks/lilypad-macos I am adding this to the CG, and I will then search for the windows lilypad code. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Sun, Feb 12, 2012 at 03:05:31PM +, Graham Percival wrote: https://github.com/gperciva/lilypad I knew I forgot something. :( I have renamed the macos-lilypad branch on savannah to: archive/macos-lilypad Please do not pull or fetch to that branch. I was reluctant to delete it entirely just in case I made a mistake when extracting the commits into the github repository. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
archive/ branches on savannah
In case it's not totally obvious, don't push anything to an archive/ branch. I've renamed a few old branches that might mislead people, namely: web- archive/web web-gop- archive/web-gop macos-lilypad - archive/macos-lilypad - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: extract-texi-filenames - missing directories
On Sun, Feb 12, 2012 at 03:44:31PM -, Phil Holmes wrote: When make doc is run, it complains about 3 missing directories - Documentation/hu/included; Documentation/cs/included and Documentation/zh/included. We could add these to the list of known missing directories in extract-texi-filename.py, but that would be bad if they were created. Anyone object if I create these as empty directories? I won't object, but git certainly will. You cannot have empty directories. ... actually, come to think of it, the build system itself would complain if you _did_ have an empty directory, because then it wouldn't be part of make dist. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: extract-texi-filenames - missing directories
On Sun, Feb 12, 2012 at 04:13:42PM -, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel Team lilypond-devel@gnu.org Sent: Sunday, February 12, 2012 4:04 PM Subject: Re: extract-texi-filenames - missing directories ... actually, come to think of it, the build system itself would complain if you _did_ have an empty directory, because then it wouldn't be part of make dist. Could put the standard Documentation/*/included/GNUmakefile in there? That's be ok. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository for osx-lilypond
On Sat, Feb 11, 2012 at 09:32:11AM +0100, Janek Warchoł wrote: 2012/2/11 Carl Sorensen c_soren...@byu.edu: In order to try to track this down, I'd like to have a git history to see how things have changed. [...] Can anybody tell me where I might find an up-to-date repository? http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/macos-lilypad but the two-line fix for 10.4 ppc support would occur in GUB, not in osx-lilypad. I think this is a lesson for us all. Yes, and that lesson is when Graham tries to off-load mundane administrative tasks, somebody do it, because you want him to take care of *non-mundane* administrative tasks. I've known about this problem for years. I've been thinking about taking care of it for years. A sketch of a solution is already present in the GOP issue. But I've always had more important things to do; some of them complicated stuff that it only makes sense to take care of myself, but a lot of it is routine boring stuff that anybody could do. It's a shame to waste Carl's time on searching for source code; Yes. I think we should do this, i'll investigate how it's done. Don't waste your time. Just take care of the ordinary administrative tasks. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: google summer of code
On Sat, Feb 11, 2012 at 02:32:31PM +0100, Janek Warchoł wrote: W dniu 11 lutego 2012 13:33 użytkownik Graham Percival gra...@percival-music.ca napisał: Time+effort required to write a proposal. Would you be happy delaying the 2.16 for, say, a month, while we spend effort writing that proposal (which may or may not be accepted) ? When all's said and done, I wouldn't be surprised if it worked out to that much effort. I'll gladly spend some time on preparing the proposal. Ok, maybe spend an hour or two and see what you come up with. We can set prerequisites like C++, git and music (notation) knowledge, so that we won't have to mentor people about this (takes a lot of time). Agreed about git. Not certain about music notation; there's a lot of good work that somebody can do even if they have difficulty finding FACE on a treble cleff. OTOH, it might be nice advertising for us -- it would make lilypond stand out in the list of project requirements. I'm very uncertain about listing C++. There's a ton of stuff that people can do with scheme only. If anything, we might want to list scheme... but then again, there's a lot of things that can be done without scheme. But that's the whole point of GSoC. In the FAQ Google explicitly says that people familiar with the project can participate. ok, but the application definitely shouldn't say that previous experience with lilypond is required. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)
On Fri, Feb 10, 2012 at 08:16:53PM +0100, David Kastrup wrote: gra...@percival-music.ca writes: However, there is clearly no desire to actually create that two-line patch, so I guess that removing support is the thing to do. Again: I don't have a clue about the involved work. But if it isn't happening, there is no point in never releasing something for those platforms which we _do_ actively support. Agreed; if you fix the other comments in my review, I'll give it a LGTM. I'm just giving one more chance to somebody to care about this. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
google summer of code
Does anybody feel like submitting a proposal to google summer of code? IIRC students must be registered at a school, so this isn't something that would help any senior developer, but it's still $5500 for any student that ends up working on lilypond over the summer, plus $500 for the organization. http://www.google-melange.com/gsoc/homepage/google/gsoc2012 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google analytics
On Thu, Feb 09, 2012 at 04:24:38PM -, Phil Holmes wrote: Are the results available anywhere? Not publicly, no. If I can find the password for an old gmail account from like 5 years ago, I can check them. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: google summer of code
On Thu, Feb 09, 2012 at 05:38:31PM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: Ooh. I think I qualify - I'm officially a full-time student. I'd be happy to share the bounty... I should be surprised if that is even permitted. Of course, it is unlikely that they are going to check your personal accounts, but in order not to make valuable offerings like this close down eventually (or add more onerous enforcement rules), I consider it fair to stay with the spirit of the thing. Yes. That said, if Phil is willing/interested in working a full-time job on lilypond for 3 months over the summer (IIRC -- it may be 4 or 2 months instead), then he's earned that money and can legitimately do whatever he wants with it, including sending the entire sum to somebody else. But the expectation *is* that the student is working a full-time job/internship. Of course, it sounds like the $500 for the organization would be fair game... The amount of mentoring happening on these lists alone is definitely not to be sneezed at. Yes. I'm confident that we prove more mentoring than at least 90% of the projects that get a GSoC. I'm not certain how they'd view mentoring a student who was already involve in the project -- I mean, technically I'm still a student. If there were serious interest in this, somebody would need to check the details. I don't think that we should aim this specifically at Phil (or at David); rather, we should ask if this is the kind of thing that we want to spend time on. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: google summer of code
On Thu, Feb 09, 2012 at 10:19:18PM +0100, Janek Warchoł wrote: I'm a student and i'd love to spend my summer working on LilyPond. The question is, do you think i qualify? I think so. Read their FAQ. It all comes down to whether you're registered at an accredited university (or IIRC high school) according to their specifications. Sorry, i don't understand. Do you think that grace timing is too small or too big for GSoC? I think that grace timing would be excellent for GSoC -- but it needs to be a real, good, solution, that works for pdf/midi/etc, with any kind of input. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
release blocked due to issues to verify
It might be nice to have a release later today, as there are 5 Critical fixes either pushed or waiting to be pushed. Unfortunately, http://code.google.com/p/lilypond/issues/list?can=7 shows some issues which do *not* contain fixed_2_15_29, so I will not make a release. In case you forgot, the requirements are here: http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00081.html - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release blocked due to issues to verify
On Wed, Feb 08, 2012 at 10:13:53AM -, Phil Holmes wrote: - Original Message - From: Graham Percival Those are all patches which only actually appear in 15.29 Then label them as fixed_2_15_29. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release blocked due to issues to verify
On Wed, Feb 08, 2012 at 11:22:44AM +0100, David Kastrup wrote: It is usually the responsibility of the person marking the issue fixed to also add the fixed_xx_xx label and mention the commit, but if that has not been done for some reason, I think we have keeping this info somewhat accurate also marked out as a janitorial task for the bug squad, sort of mopping up after the developers in case they did not entirely clean up the mess that might be _easiest_ for them to do right away, but which still constitutes an _additional_ effort on top of their real work. I don't care whether somebody on the bug squad does janitorial work cleaning up after developers (i.e. adding the fixed_x_y tags when a developer forgets), or if they just raise a stink (i.e. email -devel asking if Mike's 537496fcf6 was pushed after 2.15.28). I'm completely fine with either option. But somebody on the bug squad needs to do one of those two, or we're not having any more release. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directs makeinfo and texi2html output to logfiles (issue 5645046)
On Wed, Feb 08, 2012 at 01:23:06PM -, Phil Holmes wrote: The reason I was suggesting an early push was that cleaning up make doc is a cumulative affair, and I find it easier to manage changes/patches if I don't have multiple differences from master in my build system. I'd like to get one done and into master, then work on proving the next works. well... ok, I'm fine with that as long as Julien says it's ok. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Thinking about putting together a grant to support development on LilyPond
On Wed, Feb 08, 2012 at 02:29:00PM +, Carl Sorensen wrote: So I looked into the National Endowment for the Arts and the National Endowment for the Humanities. I could see this funding Americans to work on lilypond programming while living in America. I could see this potentially funding Americans to work on lilypond programming while living outside of America (i.e. Mike Solomon). I could see this potentially funding non-Americans to work on lilypond programming while living in America (i.e. hiring a foreign post-doc, which requires a work visa and all that fun stuff; it's probably a manageable inconvenience if you're talking about somebody with a PhD working at a university being funded from a research grant, but not manageable in other situations). I can not see this funding non-Americans working outside of America. This is cool information, but it can't be readily studied musically. There was a lot of work on MIR (music information retrieval) for symbolic music (i.e. sheet music) in the 90s. Most of that used MIDI, but for better or worse, these days almost all of that kind of work has been done with musicxml. I can imagine such a grant going through if we sell it as a backend rendering program for musicxml, relying on musicxml2ly. It would be much harder to sell it if we talked about lilypond input directly. So I'd like to ask the developers (and the users): Does this seem interesting to you? Is this something that is worth trying to put together? Is anybody interested in contributing to a grant proposal? I've said that grants are the best way to have commercial funding for lilypond. However, they tend to be country-specific. For David, an EU grant would be best; I am pessimistic that he could be funded with a US grant unless he was willing to move there. The other question is whether to aim the grant directly at lilypond, or instead include a bit of lilypond development as part of a different grant. Just like most (US) universities skim 10%-50% off of any grant for operating expenses, a grant could direct 10-20% of its money towards program development, ideally focused on its area. For example, I could imagine a grant to preserve the history of Spanish guitar music spending maybe 10% on general lilypond development, 10% on tablature-specific lilypond development, and the rest on students to typeset guitar music, make scores available online, write a book, etc etc. I know that some people have some amount of contact with IRCAM; I can definitely imagine a EU grant to support modern composition styles (or specifically graphical notation and the like). The EU tends to like grants being split over multiple countries, so I could totally see a grant being shared by Mike, David, and 2 or 3 other people (ideally in new member states, because a grant application to be spent all in France and Germany isn't likely to go far!). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Thinking about putting together a grant to support development on LilyPond
On Wed, Feb 08, 2012 at 07:11:26PM +, Carl Sorensen wrote: On 2/8/12 11:01 AM, Graham Percival gra...@percival-music.ca wrote: I can not see this funding non-Americans working outside of America. If you look at the links, many of the successful grants either invite or require multiple country involvement. ah, I'd missed that! I'd also forgotten about David's American citizenship. And before I got to that point, I'd need to put together some talks with musicological researchers so we could formulate a proposal that is even interesting to them. BTW, you might want to cc Jonathan Kulp directly, since he *is* a US musicologist. Even if his research interests aren't directly tied to lilypond, I'd expect him to at least know others US musicologists who would be directly interested in such a grant. But I won't even go that far if there's no interest from enough of the LilyPond community to cause me to believe that we might be able to put together an international team to do something. Depends on how international you want to go, how closely tied to music it needs to be, and how academic the people need to be. There's Peter Chubb in Australia; he worked on the robotic clarinet player. My supervisor in the UK had a recent phd student who did stuff on a database for musicology, combining sensor readings with lilypond scores. etc. The LilyPond work has to be supported based on achieving the desired academic goals. But I don't think that's unreasonable to propose. Oh, I definitely don't think that's unreasonable to propose! There's definitely potential; it just depends on how much real interest there is in actually coordinating the grant application. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: having trouble fetching all remote branches
On Tue, Feb 07, 2012 at 08:51:24AM +0100, Janek Warchoł wrote:
My local repository wasn't created with git clone, and i have only one
remote branch ('origin/master'); i cannot push to staging because of
that. I've tried 'git fetch --all', but the other remote branches do
not appear, and i don't see a solution in git fetch description. Any
help?
Delete your lilypond directory and start it fresh with a new git
clone. Of course, back up any work you have first by doing git
format-patch origin and double-check that you have the right
patches.
It is seriously not worth trying to change your .git/config.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors in examples
On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Sunday, February 05, 2012 3:08 PM Subject: Re: Errors in examples Users aren't supposed to look at these, but sure, go ahead and fix those warnings if you want. As long as the output looks the same, push directly to staging. Given the 2 chords/notes near the end, both with downstems, I think the only option is either use the ignore-collision override, or have the upper notes stem-up using voiceOne. It doesn't appear to be a famous piece of music - there's no title, etc., so I'd actually prefer the latter. ok, sure. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mon, Feb 06, 2012 at 07:45:47PM +0100, Werner LEMBERG wrote: In my opinion, these times are too high to justify the gain that one gets from using fine-tuned vertical skylines. Yes, unfortunately. +1 is it at all possible to make this a user-configurable option? I know this would add complexity to the code base, but how bad would it be? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging patchy problem.
On Sun, Feb 05, 2012 at 10:43:49AM +0100, David Kastrup wrote: for some reason unfathomable to me, the staging patchy contains the following code in compile_lilypond_test.py: The intent is that after doing staging-master, patchy's master should be updated so that a later run of test-patches.py doesn't miss any updates. For example, if somebody is pushing a whole bunch of syntax changes, you definitely need the material in patchset 1 before trying to test patchset 2. ### update its own master run(git fetch) run(git checkout master) run(git rebase origin/master) I make no claim that this is the proper way to do it in git. This is a _total_ nuisance. All of the rest of staging patchy's operation does not meddle with the work directory of the given repository, does not meddle with the index, and does not meddle with local branches (except for the two branches maintained explicitly for testing). If it were not for that nonsense, one would not need an extra repository for staging patchy on a cron job. ok. Maybe it's better to make test-patches.py run based off origin/master instead of master? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging patchy problem.
On Sun, Feb 05, 2012 at 11:31:52AM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: The intent is that after doing staging-master, patchy's master should be updated so that a later run of test-patches.py doesn't miss any updates. If test-patches.py needs a particular state of master/index, it should cater for it by itself rather than rely on the state left by some independent tool running asynchronously. I don't disagree. Maybe it's better to make test-patches.py run based off origin/master instead of master? test-patches.py as far as I remember is _not_ run based off _either_ origin/master or master, but rather the current _index_. Which is about as unreliable as one can get short of just copying the work directory. I don't disagree. One should make it clone origin/master. I don't disagree. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows welcome message
On Sun, Feb 05, 2012 at 11:36:47AM -, Phil Holmes wrote: The windows welcome.ly points users to http://lilypond.org/web/help which (I think) is an old implementation of the website, with old look and feel. There doesn't appear to be an identical page in the new website, but pointing them to http://lilypond.org/introduction.html must be better? I'll fix this if it's agreed. sure, push directly to staging. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where to document patchy?
On Sun, Feb 05, 2012 at 02:15:31PM -, Phil Holmes wrote: http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling ? http://lilypond.org/doc/v2.15/Documentation/contributor/pushing-to-staging ? http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches ? I think it would be best to document both versions of patchy in the same place, but where? Dump it in administration.itexi, @node @section Patchy the autobot. Push directly to staging. We can cutpaste and edit later on if necessary. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors in examples
On Sun, Feb 05, 2012 at 02:43:45PM -, Phil Holmes wrote: In the source for http://lilypond.org/ly-examples/tab-example.png I get the following compile errors: Seems to me these really ought to compile clean? Users aren't supposed to look at these, but sure, go ahead and fix those warnings if you want. As long as the output looks the same, push directly to staging. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Last Q for today?
On Sun, Feb 05, 2012 at 03:17:11PM -, Phil Holmes wrote: If I maker a change to a manual (in this case, notation; winds) and this has translations, should I make the same change into the translations, or leave it to be picked up by the translators later? Leave it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors in examples
On Sun, Feb 05, 2012 at 05:57:31PM +0100, Thomas Morley wrote: 2012/2/5 David Kastrup d...@gnu.org: Hardly surprising. From changes.tely: @item Flags are now treated as separate objects rather than as stem parts. @lilypond[fragment,quote,relative=2] \override Flag #'color = #red g8 @end lilypond Yes, and I remember Mike manually changing a bunch of files, then running convert-ly, then undoing his manual changes... or something. There was certainly something to do with Stem vs. Flag and transparency. In order not to change other output I simply added \override NoteColumn #'ignore-collision = ##t I'm not certain that's a great solution. Is there a good reason why they're colliding? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: failure rewriting Patchy
On Sat, Feb 04, 2012 at 11:57:24AM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: I've not looked at the attached file, but what were you trying to do and what caused problems, Jan? a) git management. test-patches.py basically takes whatever state its reference repository index is at as its starting point. In contrast, the staging patchy is pretty careful to rely not at all on whatever you happen to have checked out in which state in the reference repository. This is probably solvable by copypasting 2-4 lines of code from compile_lilypond_test.py to itself. If the solution isn't already in there, then it's a matter of adding 2-4 lines of code, most of which will be the git command. b) work tree management. test-patches.py checks out a git tree, makes a c) test baseline management. Since the test baseline output sits in An alternate idea is to improve the lilypond build system. If we don't have a make dep-clean then maybe it would be good to do that. I know that I always say that you cannot trust a partially-built tree and you should always completely remove your old build tree before starting a new build... but that's not precisely a good state of affairs. Also remember that the precise problem with 2240 was that my $LILYPOND_GIT was pointing to the wrong user and that nobody else could duplicate the behavior I was seeing (because it was an admin screw-up on my personal system). I'm still not certain if anything actually *needs* to change with respect to b) and c). I think the best way forward is to have documentation in the CG about how to run stable-merge, test it with a few people, then do the same for patch-new-testing. If multiple people have problems testing a certain commit, then obviously more investigation is needed. But until then, I think the best way forward it documentation and more widespread usage. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-git.tcl and git clone
On Sat, Feb 04, 2012 at 02:14:56PM +0100, Jean-Charles Malahieude wrote: * git clone learned --single-branch option to limit cloning to a single branch (surprise!). This might change things end be quite useful! Thanks for the news, but in this case it's actually the opposite: we _want_ all the branches. The only a single branch thing came from about 5 years ago, when I was 1) on dial-up, 2) didn't trust git, and 3) didn't even trust the numbers that said that downloading all branches was only 10 MB more than downloading a single branch. Unfortunately that's led to a lot of angst and problems by playing silly games to try to avoid my silly concerns from years ago. Hopefully we can put this right by changing lily-git.tcl just as I've changed the CG to tell people (in the advanced git section) to just do git clone. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: website should rely on $LILYPOND_GIT (issue 5630055)
On Sat, Feb 04, 2012 at 11:10:51PM +, julien.ri...@gmail.com wrote: Documentation/contributor/website-work.itexi:270: make -f website.make WEBSITE_ONLY_BUILD=1 -B website If we leave -B here, does it fix issue 2251? That's not the issue; once I'd boiled down the instructions and tested them on my own computer, I noticed that cron was complaining because LILYPOND_GIT wasn't set, because cron doesn't inherit the normal user env vars. :( This is the second totally stupid mistake I've made recently that's caused a lot of angst (the other was failing to properly set up an independent user to run Patchy and thus having it use an out-of-date lilypond git directory). But they're both the kind of thing that a second pair of eyes might have been able to catch in about 5 minutes. Moral of the story: we really need at least two people familiar with, and ideally actively performing, all administrative tasks. It's too easy for one person to have a little slip-up. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
issues to verify - no more releases
Now that the Patchy staging-merge is running ok, it's time to force the next issue: I will not be making any more releases, stable or unstable, as long as there are issues to verify relating to a previously-released version. At the time of this writing, this means that if *ANY* issue on this list: http://code.google.com/p/lilypond/issues/list?can=7 does *NOT* say fixed_2_15_28, there will be no release. Building a release means I need to reboot into a less-useful OS where I can't work on most of the stuff I need to work on, and it takes 3-4 hours. If the lilypond community cannot find **20 MINUTES** to clear out the old issues to verify, then I see no reason to impair myself for 4 hours. This is not a policy decision; it is not open to discussion or pleading. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Roadblock MacOSX 10.4 for release of LilyPond 2.16
On Fri, Feb 03, 2012 at 11:56:06AM +0100, David Kastrup wrote: in the list of critical issues the recent issue 2271 URL:http://code.google.com/p/lilypond/issues/detail?id=2271 is the only one I see without an obvious path forward. A quick glance at http://code.google.com/p/lilypond/issues/detail?id=1943 shows that Christian Hitz is the person who offers to do osx work, and a quick glance at the git history for GUB shows his email address. He's also farily busy and can take a few days before having time to reply. I'd suggest that you contact him as he may not have noticed the new 2271 as opposed to the old 1943. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues to verify - no more releases
On Fri, Feb 03, 2012 at 01:14:52PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: At the time of this writing, this means that if *ANY* issue on this list: http://code.google.com/p/lilypond/issues/list?can=7 does *NOT* say fixed_2_15_28, there will be no release. verifying an issue is not the same as giving a fixed_* marking. Yes. Programmers gives things fixed_* tags. Bug squad tests those fixes, or asks for help if necessary, then changes the status of those fixed items to Verified. So I don't quite understand what you expect here. I can put the respective fixed markers corresponding to the respective commits on (which is what I do unless I forget whenever marking an issue of mine fixed after pushing). From you: nothing (other than the in general category) From the bug squad: to do their job. This goes back years. http://lists.gnu.org/archive/html/bug-lilypond/2010-08/msg00417.html From the lilypond community in general, be they developers or users: if the current bug squad cannot handle this task, then either encourage (with moral support, monetary support, or immoral support) them to work for more than 20 minutes once a week, or offer to join the bug squad and do this work yourself. Or is your problem that you want to see Verified on every committed fix with a version earlier than 2.15.18, making sure that the commit did indeed make it into the mentioned release? 2.15.28, not 2.15.18, but yes. If we don't know that stuff that was claimed to be fixed in .27... or .25 or .23... is working, then I'm not going to bother putting out .28. Note that for a patch issue, verifying is as simple as checking that the commit is in git. For actual bug issues, just run the bloody minimal example in GUB 2.15.27. For other stuff, take bloody initative and ask for help. For example, 2239 google code only returns 20... is a bit outside of our normal bug range. So bring that to the attention of -devel, and I'll say it can just be marked Verified instantly because it's not worth fussing about it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues to verify - no more releases
On Fri, Feb 03, 2012 at 02:14:41PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Programmers gives things fixed_* tags. You wish. Heh. Normative vs. descriptive. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues to verify - no more releases
On Fri, Feb 03, 2012 at 01:40:49PM +, Colin Hall wrote: Looks like Dave has marked all the outstanding fixes as verified while I was busy testing 1416. almost; there's still 2149. My understanding is that they still all need to be tested. I'm travelling from Saturday but I'll try to get through as many as I can between now and then. tested? Nope, verification *is* testing. Once 2149 is handled, there is no need for Bug Squad members to do anything with the issues to verify list until 2.15.28 is out. Graham, when are you aiming to release 2.16? Exactly as specified in the CG: http://lilypond.org/doc/v2.15/Documentation/contributor/major-release-checklist - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy and staging
On Wed, Feb 01, 2012 at 10:00:30AM +0100, m...@apollinemike.com wrote: I got a Permission denied (publickey) message from patchy when trying to fiddle with it. I know that it is going to the correct directory because it succeeds in deleting the test branch but then it gives me this. Any ideas how I could get around this? savannah is telling you that you don't have git push ability set up. If you're running patchy as a separate user (recommended), or from a separate git directory, that git directory needs to be able to push. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy and staging
On Wed, Feb 01, 2012 at 11:41:22AM +0100, m...@apollinemike.com wrote: On Feb 1, 2012, at 11:33 AM, Graham Percival wrote: On Wed, Feb 01, 2012 at 10:00:30AM +0100, m...@apollinemike.com wrote: I got a Permission denied (publickey) message from patchy when trying to fiddle with it. savannah is telling you that you don't have git push ability set up. If you're running patchy as a separate user (recommended), or from a separate git directory, that git directory needs to be able to push. I am pointing patchy to /home/mikesol/lilypond-git (LILYPOND_GIT variable), which is the directory from which I push all of my patches to staging. I'll try tinkering some more tonight. hmm. Are you running patchy in a separate shell that doesn't have access to your $HOME ? I once had that problem; when patchy reached the git push stage, git couldn't find me $HOME/.ssh/ so it therefore couldn't get the ssh keys. The bottom line is that the Permission denied (publickey) message comes from git (called on line 229 of compile_lilypond_test.py), not Patchy itself. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Running patchy (merge staging)
On Wed, Feb 01, 2012 at 11:55:24AM -, Phil Holmes wrote: My draft instructions, based on my memory of what I did. Looks good! Here's a few little notes, including the reason why I couldn't test David's 2040 patch. (coincidently, I'm waiting for my supervisor to show up, so I spent 10 minutes looking into it just now) 1. Create a new user on your box - use this solely to run patchy. On my system it has admin privileges but I don't know if that's necessary. New users are created from System; Administration; Users and Groups. I recommend *not* giving the user admin privileges. The main reason to do this in a separate user is in case somebody sneaks a rm -rf into the build system -- that's not really a worry for staging (because we trust people with git push ability), but there's absolutely no checks for a Patch-new. Might as well get into the habit of good security now, so nobody is unpleasantly surprised if they use their merge-staging setup for test-patches and encounters a problem. (yes, the user should still be required to type in his password before he can do anything truly bad, but it's still good practice to give the minimum amount of privileges required when blindly running code that anybody on the internet can submit) Also, the big explanation for David: - I was always doing su lily to switch to my patchy user, so it would only occupy one terminal and I could use my computer for other stuff - I forgot that bash reads different files depending on whether it's an interactive shell vs. a new login vs. whatever. (this is that ~/.profile vs. ~/.bash_profile vs. ~/.bashrc nonsense) - when you do su username, apparently bash DOESN'T change your environment variables. - therefore, my lily user has $LILYPOND_GIT pointing to /home/gperciva/src/lilypond/ and since I very rarely touch that directory any more, I wasn't doing any git pull or git fetch there. Moral of the story: once you have a separate user set up, double-check that everything is actually happening for that separate user. and/or we might even give explicit instructions on what to put into your ~/. files. 2. Get the patchy scripts from https://github.com/gperciva/lilypond-extra/ patches 3. Put the scripts in a sensible place on your system I just run them from the git repo; that allows for easy updating. Alternatively, one could set up symlinks. 6. Edit lilypond-patchy-config-DEFAULT to provide working directories for your build directory, your results directory, compiler options and notification method. If you don't want to use email notification, then delete everything after smtp_command:. Save this without the -DEFAULT. -1 Don't change the -DEFAULT; instead, change ~/.lilypond-patchy-config after the -DEFAULT has been copied to that location. 7. Ensure that your new user has git push access. Follow the instructions in the CG. http://lilypond.org/doc/v2.15/Documentation/contributor/commit-access. I have not set password protection for the key - I assume that if I did I could not run patchy unattended. +1 8. python lilypond-patchy-staging.py. Not much happens except a lot of CPU gets used... Please let me know if you plan to do this - I won't run patchy myself. There's not much point trying it unless there something in staging to be merged to master. +1 9. Results are in a log*.txt file in the directory given by auto_compile_results_dir. Yes. Note that if you have email set up, you'll get those logs via email. Once somebody with a powerful, always-on computer sets this up, I'd suggest a 10. add this to your cronjob so that nobody needs to think about it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New Patchy thread
On Tue, Jan 31, 2012 at 12:03:17PM -, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Tuesday, January 31, 2012 11:55 AM Subject: Re: New Patchy thread Phil Holmes em...@philholmes.net writes: OK - I've now successfully run test-patches. It downloads and tests the patch associated with issue 2263 (and tests clean). However, there only appears to be a single patch in staging, and that's Carl's fix for 2256. Any idea why it's testing 2263 instead? test-patches.py and lilypond-patchy-staging.py are completely different. Also, FWIW, I've taken the email command out of config, and I now get no notification of what has resulted, except what's shown on the terminal. No Message for you in take a look at the auto_compile_results_dir in your ~/.lilypond-patchy-config. Even without any mail command, you'll get the patchy log there. test-patches was not supposed to be on-topic yet... +1 although if people can get that working, that'd be great. I'll probably stop running test-patches.py myself on Feb 15. Wait. That answer does not fit the problem. I leave it in for reference, but the answer to your original question: test-patchy tests the last Rietveld review it can find on any issue being marked with Patch-new state. 2263 presumably is marked as such, 2256 apparently is something else, likely countdown or push. lilypond-patchy-staging.py does *nothing* with the code.google.com tracker. It strictly operates on git: git origin/staging and origin/master. OK - so I really need to ensure that I can run lilypond-patchy-staging.py? Yes. It should be completely automatic and painless, once you have your ~/.lilypnod-patchy-config the way you like it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New Patchy thread
On Tue, Jan 31, 2012 at 12:37:33PM -, Phil Holmes wrote: I assume I need to do something to update my git repo. However, it's vanilla and created using lily-git, so we would need instructions on how to do this anyway. Anyone know what's needed? I'll bet you a tenner that you used the OLD lily-git.tcl[1], which only gets a subset of the repository. [1] by OLD, I unfortunately mean the lily-git.tcl in the latest lilydev, so you're doing completely what we expect from a good and conscientious developer [2]. [2] it would be really nice if lilydev 2.0 could come out soon. Could you: 1) delete your current lilypond dir, then run: git clone git://git.sv.gnu.org/lilypond.git 2) put the resulting lilypond in the location you want, quite possibly renaming it to lilypond-git as well 3) change that repo so you have push access 4) try again? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lily-git.tcl and git clone
The updated CG instructions for setting up git manually specify to use clone: http://lilypond.org/doc/v2.15/Documentation/contributor/setting-up but the latest patch for lily-git.tcl still appears to use the old git remote add... stuff to only get specific branches? If I understand git correctly, which I'm sure that I don't, wouldn't this make getting other branches (notably origin/staging, but also dev/whatever as well) much harder? Is there a compelling reason not to use git clone for lily-git.tcl as well? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New Patchy thread
On Tue, Jan 31, 2012 at 01:47:52PM -, Phil Holmes wrote: There you go. That seemed to work. Yep, looks good. I assume all I need to do is run patchy-staging daily? Yes and no. Running it daily would be great. Running it every 12 hours might be nicer, although maybe you could alternate with James or Reinhold? Note that if there's no new patches, Patchy staging-merge just quits and tells you there's nothing to do, so don't worry about it wasting resources compiling exactly the same thing over and over again. That said, if there's a one-line typo fix in the docs, it'll still rebuild absolutely everything. Another thing to consider is setting up a cronjob. Instead of running it manually, if your computer is always on, it'll just do its thing by itself. Great for 4am in the morning! Finally, occasionally staging breaks. That'll show up in the logs in your lilypond-patch-build-output-log-directory, or if you set up the mail stuff, you'll get an email warning you about the problem. When there's a problem it requires manual attention (although not necessarily from you, and it's theoretically possible to make patchy take care of this automatically, but that's a far-off idea). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: 2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') ... that's ALREADY how it works for the staging-merge. will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:59:57PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. I am not sure what the problem is with anybody else running it. ditto, other than the sheer it's something I haven't done before factor. Don't underestimate that: unix people have no problem running an unknown program and skimming the man page if necessary, but other people are reluctant to do this. You call it, and it complains about LILYPOND_GIT not being set. That's covered in the beginning of the CG now, and it's built-in to lilydev 2.0. (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. Yep. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. Yep. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. Yep. I have to admit to not even reading the CG here. Admittedly, none of the above is in the CG (other than the LILYPOND_GIT environment variable stuff). But really, it's just as you say: the instructions are pretty clear. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. Great! Hopefully somebody will see these emails and realize there's nothing to fear. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 02:07:44PM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, ah yes, I forgot about that. It's a replacement of smtp, specifically aimed at mutt users, but the mutt part is irrelevant. on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. err, yeah; I guess that part should be configurable, so staging-merge isn't completely finished. But at a pinch, one could just leave the smtp_command: blank, and then it won't do any mailing at all. I mean, that's sufficient to have the merge happening. For relevance, I have this: lily@gperciva-desktop:~$ more .msmtp-patchy account gmail host smtp.gmail.com port 587 auth on user lilypond.patchy.gra...@gmail.com password hunter2 tls on tls_trust_file /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt from lilypond.patchy.gra...@gmail.com account default: gmail ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 01:35:24PM -, Phil Holmes wrote: Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. Yes, I have patchy on a completely separate user. Configuration of the respective paths. In the scripts or in a config file? config file. smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. I don't have a mail account on that machine, so would need to configure it to use my normal SMTP provider, but don't know how to do that. I happened to send instructions for this about 60 seconds ago. :) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
On Mon, Jan 30, 2012 at 12:56:50PM +0100, m...@apollinemike.com wrote:
The problem is that the file in question is stencil.hh.
I got around it by using Drul_arraySCM and having the drul
arrayed populated with smobified stencils.
I hope that my
6e2e1d6a13aba88a3a8eecc0d46f96ad245c152a
didn't mess up anything?
Avoid deprecated access declarations
According the ANSI/ISO Standard, the use of access
declarations
is considered deprecated. Instead, you should use a using
declaration for that purpose
http://www.devx.com/tips/Tip/5707
-- flower/include/interval.hh
--
index 1ce6ac2..02bc791 100644
@@ -31,7 +31,7 @@
templateclass T
struct Interval_t : public Drul_arrayT
{
- Drul_arrayT::at;
+ using Drul_arrayT::at;
static T infinity ();
static string T_to_string (T arg);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 04:39:31PM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: My other current concern is to wonder whether lots of people trying to get patchy running might not collide with each other. I don't think so; once the first set of commits were pushed to master, I would expect that other people will just get a non-fast-forwarding reply when Patchy attempts to push to master. As I understand it, the key patchy function is to pull patches from staging, The current state of staging. It does not test individually. run make and make test, and check the regtest output. No regtest examination. It builds make, make test, and make doc, and if nothing fails -- using the make(1) definition of fails -- then it merges and pushes to master. If this is OK it sends a message saying LGTM. Is this correct? Nope, it bounces master to staging (or recommends doing it, depending on what Graham did). It bounces master to staging directly. It sends a personal mail saying it's done; if it fails, it sends a personal mail CC'd to -devel. But the mail can be dispensed with for the first few tests. Does it actually do any of the merging of patches from staging into master? I wouldn't want to do that without knowing I was doing it... (although my new user would presumably fail anyway, since I've not yet set it up for push access). Yes, but the whole point is that you don't need to know what you're doing. The script handles it (as long as your new user has git push access). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 06:56:08PM +0100, Janek Warchoł wrote: 2012/1/30 Graham Percival gra...@percival-music.ca: that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say everything gets done automatically. I think there's confusion between Patchy staging-merge and Patchy test-patches. They share the Patchy name because 90% of the code is the same, but the staging-merge is a much easier, and much better-tested, task. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, That's a problem with test-patches, not staging-merge. i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. Yes, and that's valuable for the future. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. I think you were working on the wrong problem -- a problem which *will* be important in the future. I haven't yet set a date for when I refuse to run test-patches yet, but I'm thinking about Feb 14. Why am I doing this? Because yelling about our bus factor and the problems of not automating things has not resulted in enough attention. If you doubt my yelling, check the email archives. I am very serious about potentially leaving for good at the end of March. That would leave a lot of maintenance tasks not getting done. And if I officially leave lilypond and somebody asks for help doing some maintenance task, I may not bother to reply. I make no guarantees. The time to panic about not knowing how to do those tasks is NOW, while I'm still available to give some guidance. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Sun, Jan 29, 2012 at 03:34:45PM +0100, David Kastrup wrote: Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. ??? if you look in the build dir, what logs does it have? I mean, I'd expect pretty much any laptop that still boots to be able to complete a full doc build in 6 hours. So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. Agreed, a laptop isn't great for long-term patchy-staging merge, but I'm still surprised it's taking this long. The compile is O(make doc), so asymptotically, any machine that can complete that task can be used in a pinch. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Sat, Jan 28, 2012 at 04:18:00AM -0800, lilypond.patchy.gra...@gmail.com wrote: *** FAILED BUILD *** nice make test -j3 CPU_COUNT=3 Previous good commit: 05efb98f2e3ff68f4bb8221db640b0174bfcde93 Current broken commit: b445e1b4207996eee2362187fa3e8b8af8ff05ba make[1]: *** [out-test/tex-fragment.tex] Error 1 make[1]: *** Waiting for unfinished jobs - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
updated git-cl
there's an improved git-cl on my github account now: https://github.com/gperciva/git-cl Thanks to Lukasz Czerwinski, it tracks all lilypond patches with the same base url. http://codereview.appspot.com/search?base=http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/ All contributors are still urged to allow git-cl to make an issue in the code.google.com issue tracker, but it's nice to have an extra layer of security. I suggest that everybody updates their git-cl repo. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Sat, Jan 28, 2012 at 08:31:04AM -0500, Julien Rioux wrote: On Sat, Jan 28, 2012 at 7:27 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 28, 2012 at 04:18:00AM -0800, lilypond.patchy.gra...@gmail.com wrote: make[1]: *** [out-test/tex-fragment.tex] Error 1 make[1]: *** Waiting for unfinished jobs Is there more to the log? I cannot reproduce the failure. Not that I can tell. :( remember that we still have all 3 jobs outputting info to the same logfile, so it's pretty confused. I'll send you the entire log privately just in case you can find anything interesting. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Sat, Jan 28, 2012 at 09:07:12AM -0500, Julien Rioux wrote: Thanks. Are there known issues about running multiple lilypond-book instances in parallel when they touch the same files? I'm guessing this is what's going on because a lot of the test files input the same snippets as example, which would have identical generated filenames. I can't think of any such issues off the top of my head, but I wouldn't be surprised if there were unknown issues about this. oh wait, I *do* remember something arises from the translations: the documentation has multiple copies of the same .ly file in various translations. The whole reason we have a out/lybook-db/ is to try to notice idential filenames and avoid rewriting them. A few years ago (sorry... between 2 and 5 years is as much as I can narrow it down from memory, and a few quick searches of -devel didn't pinpoint anything) that was a serious problem with doc compiles. actually, a quick look at the history for make/lydocs-make suggests 3a9c1df02fdb6846418c5794a7b04d07209e95b3 and I definitely remember that John Mandereau was working on this stuff. It would fit the time span. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Sat, Jan 28, 2012 at 09:18:03AM -0500, Julien Rioux wrote: I'll have to test again with -j3, sorry. I suggest we erase the last two commits from staging until this is resolved. The convert-ly commit should be pretty safe. oh, I did that an hour ago, and Patchy's finished merging it now. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
extra countdown for 2012-01-29
Since we didn't have any patches on the official countdown for next Sunday (2pm GST), let's add Carl's latest Critical fix: empty strings: tabStaff insists on stringnumbers and looses notes http://code.google.com/p/lilypond/issues/detail?id=2256 http://codereview.appspot.com/5576053 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tasks remaining for 2.16 release?
On Thu, Jan 26, 2012 at 12:33:31PM +0100, David Kastrup wrote: a) feature freeze. Nothing added that requires documentation changes. why bother? the two-week release candidate takes care of this. b) get rid of all critical issues yes c) release candidate(s) yes d) proofread the docs for obvious mistakes no, we've never bothered with that in the past, and this would push the release back to summer or later e) make sure all appropriate regtests are there no, we've never bothered with that in the past, and this would push the release back to summer or later f) update the snippets for stuff that could now be done easier no, we've never bothered with that in the past, and this would push the release back to summer or later g) get the translations up to par where there are translation workers no, we've never bothered with that in the past, and this would push the release back to 2013 or later h) release. yes I'd be tempted to add update LSR to 2.14, but: a) that's not likely to happen due to lack of interest amongst active users (this isn't a developer-only task!) b) we've never bothered with that before - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On Thu, Jan 26, 2012 at 05:57:43PM -0500, Julien Rioux wrote: On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? Wanted to do that for ages, but that's not something to get into now. But this shouldn't be an issue -- don't we split it into lists of IIRC 300 files? We had some kind of emergency bugfix like that. ... yeah, see make/lysdoc-rules.make You may want to look into that; perhaps changing the division from 300 to 50 would speed up the build? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Wed, Jan 25, 2012 at 09:10:16AM +, James wrote: Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly It wants to have a full git clone git://git.sv.gnu.org/lilypond.git command, as (now) specified in the CG and done in the updated lily-git.tcl. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bounties
On Wed, Jan 25, 2012 at 03:01:50AM -0800, m...@apollinemike.com wrote: 1) Create an e-mail address contrib...@lilypond.org (this I can't do - can someone please do this). Can't do. Seems simple, effective, and startable in the next two weeks. I'm sure it is not perfect, but LilyPond is not perfect, and it seems better to start something and change it as need be than to not do anything. Check your email archives for our discussion on 2011 Dec 2 for all the reasons I think this is a bad idea. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bounties
On Wed, Jan 25, 2012 at 03:38:21AM -0800, m...@apollinemike.com wrote: On Wed, 25 Jan 2012 11:24:40 +, Graham Percival wrote: Check your email archives for our discussion on 2011 Dec 2 for all the reasons I think this is a bad idea. Given that several users have already expressed the desire to give money this way and at least one developer has expressed the desire to take money this way, it seems that the only thing missing is the clearinghouse through which the exchange happens. You have not refuted /any/ of the concerns I gave against this idea in that previous email. I think we need to discuss this privately. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bounties
On Wed, Jan 25, 2012 at 02:29:22PM +0100, Janek Warchoł wrote: 2012/1/25 Graham Percival gra...@percival-music.ca: Check your email archives for our discussion on 2011 Dec 2 for all the reasons I think this is a bad idea. Sorry, but i'm searching for 10 minutes and haven't found relevant thread. Can you be more specific? The title was [lilypond private] sponsorships for programming It was sent to the email address that you have listed in this email. Hopefully it's in your archive mailbox, rather than being deleted. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Wed, Jan 25, 2012 at 08:29:51PM +0100, David Kastrup wrote:
That would be the 2240 work. I did a full make check and a build of the
info documentation which in my experience is pretty much the same as a
make doc but somewhat faster.
If it wasn't a build from scratch, it doesn't count.
I'll be fixing this, but it will take several hours to make a doc build
on my current setup. Do you have the log files for the failed runs,
perchance?
this fails:
\sourcefileline 99
tonic=fis'
{ \tonic \transpose c g \tonic }
I tried it manually:
foo.ly:101:10: error: not a rhythmic event
{ \tonic
\transpose c g \tonic }
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bounties
On Wed, Jan 25, 2012 at 12:09:25PM -0800, Don Armstrong wrote: There are already existing free software umbrella organizations that do this: one is SPI[1], another SFC[2]. Yes, I've considered suggesting (after Valentin suggested it to me) that we might want to approach SFC, but it hasn't been the right time yet. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Wed, Jan 25, 2012 at 09:20:18PM +0100, David Kastrup wrote: WTF? That's definitely something in the changes file. I checked this and it compiled and I had code that made sure it compiled. With all the rebasing to make this fit better I must have displaced the relevant commit that explicitly makes this compile somehow after all. I'll be pushing that ASAP and check the translations afterwards. I see your fix. However, I'm reluctant to run patchy-staging right now, since it would leave master broken in 1f0a00b69403290b7fc7527b9ab100f95533f954 and fixed in 75d0e8cf509685df2e0ed5722803622258673c07 True, we're unlikely to have git-bisect stop in between those two commits, but would it be possible for you to include the parser.yy fix in the relevant branch merge so that there isn't any danger when running git-bisect? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bounties
On Wed, Jan 25, 2012 at 02:29:28PM +0100, David Kastrup wrote: I would want to avoid the situation where I have money on my hand I can't spend in good conscience. In that case, only accept transfers which you feel cover existing work (provided the sender realizes this), or transfers which are an advance payment of future work. So I would attempt of using the next LilyPond report for fishing for _personal_ LilyPond funds, As long as nobody else has put their name on the Sponsorship page, sounds good to me. trying to present the results of the previous discussions about official channels and see what the responses in turns of better ideas as well as actual donations are. No. I am not interested in setting up any official channels for this. That is a barrel of worms that we do *not* need right now. :/ Once we get in the situation where I would tell prospective _personal_ _account_ donators that I already got myself covered, ... which will happen shortly after a princess reads my blog, falls madly in love with me, marries me, and gives me an allowance of a few million dollars. In short, it's not going to happen. Oh, but if it does, here's a message for my future bride: hey babe, I'm not proud. I'll happily be your kept man! or where we find that people are willing to provide money for LilyPond developments that someone else would be better suited to take up, we might have to rethink about putting something up that is less personal than currently you can support some LilyPond developments by supporting David. maybe. I would rather have interested parties add their name to the Sponsorship page. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote: has less potential to go wrong if there is a problem at any time. I actually don't really understand why we bother with restoring the tree anyway instead of removing it and doing the next test from a freshly created git clone directory. That loses the regtest baseline, and the whole point is to do a regtest comparison. It's certainly possible to move the baseline to a separate directory, remove the current build+src dirs, recreate the build+src dirs from scratch, then move the baseline back into the build dir and make a comparison. ETA: 10 hours for anybody other than Julien, because this touches some dark corners of the build system. I suppose we'll get to see the proof when this moves to staging. Not quite; staging doesn't do a regtest comparison. We'll see the proof once it's in master and there's a new official GUB release. So that this does not get needlessly messy in case anything _does_ go wrong, I am currently in the process of moving the non-controversial parts of 2240 into staging where they can get advance testing. If there _is_ something wrong with the patch -- and I'm not saying that there is, just that the only evidence I've seen that it's ok comes from your emails -- then the only other testing that staging provides is making sure that the docs compile from scratch. If regtests broke, we wouldn't see that until the official 2.15.28 release. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
user vs. user (was: User vs Developer: Round 2 (and half-time?) (was: Re: music font)
On Tue, Jan 24, 2012 at 01:50:13AM +0100, Janek Warchoł wrote: 2012/1/23 Xavier Scheuer x.sche...@gmail.com: why I never *demand* developers to fix an issue, even if it is one that is really annoying my ego in almost every score I typeset. One thing comes to my mind: you are talking about bugs that annoy many people, and they waste a lot of your own time. Have you considered organizing a collective bounty to fix that bug? We now have a webpage for this: http://lilypond.org/sponsoring.html My main goal was to attract attention to Emilio's nice project of music font with LilyPond. I attracted Graham's attention on me instead. Well, you asked for Graham's attention when you cc'd him. I think cc'ing him was a mistake, Me, and a bunch of other long-time developers. I'd have probably ignored the email if he hadn't done this. bitten by the red ants' queen! That's not a surprise. Graham's sensitivity is well-known, especially in this context. Yes, because it annoys me when people complain at the wrong target. Xavier mentioned having to submit a bug report 3 times because the emails kept on being lost/forgotten. That is indeed a serious problem -- but wait, that's a problem with users, not developers! The bug squad is composed (mainly) of users. It needs no technical skill, no git access, nothing like that. All it needs is people who can use email and a web browser and are willing to spend 20 minutes each week. Let's take a look at the current statistics, shall we? http://lilypond.org/~graham/maybe-missing-emails.html [from 2011 Dec 01 to 2012 Jan 24] Response category Number Percent of total Less than 24 hours 50 68.49% 24 to 48 hours 6 8.22% More than 48 hours 8 10.96% Never replied 9 12.33% Those numbers aren't great. Maybe Xavier could find 20 minutes each week to help improve them? hmm, looking at the never replied emails, I'd say that 3 were not actually bug reports. So things aren't quite as bad as those numbers suggest. Also, if we look at the later statistics, we see that of the 8 emails that were responded to later than 48 hours, 5 were done by Phil Holmes (who does bug squad on Sunday), 2 were done by Ralph Palmer, and 1 was done by Mark Klein. If we had somebody who was willing to seriously deal with emails that had gotten forgotten on Wednesdays and Thursdays (i.e. half a week away from Sunday), then we might be able to reliably respond to missing bug reports within 96 hours! Of course, a 96-hour reponse rate isn't precisely fantastic, but it's a start. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
somebody needs to run staging before 29 Jan
In order to reduce our bus factor[1] -- especially considering the distinctly non-zero possibility that I'll be gone at the end of March -- somebody else needs to run the Patchy staging-merge script. To make this more presssing, I am refusing to run this script myself after 29 Jan 2012. [1] http://en.wikipedia.org/wiki/Bus_factor Note that there are three separate issues here: 1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) 2. it would be good to have something in the CG about Patchy. 3. somebody needs to set up a cronjob to run it regularly (I suggest every 12 hours). We do not need to have one person doing all three tasks. I am willing to continue running the new patch tests for a bit longer. (probably 1 or 2 weeks after the deadline for staging-merge) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: user vs. user (was: User vs Developer: Round 2 (and half-time?)(was: Re: music font)
On Tue, Jan 24, 2012 at 12:27:56PM -, Phil Holmes wrote: Of course, a 96-hour reponse rate isn't precisely fantastic, but it's a start. Well - TBH time isn't of the essence as a general rule. Whether a bug gets added to the tracker in one day or 3 rarely affects the overall development. Our published materials says 24 hours: http://lilypond.org/bug-reports.html (step 4: wait for a response) If the norm is 72 hours, or 96, or 168 hours, we should update that accordingly. I don't mind what the number is, just as long as we give users an honest appraisal of how long they should wait. IMO taking a 95% cutoff is reasonable -- i.e. if 95% of emails are replied to within 80 hours, let's publish please allow up to 80 hours. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Tue, Jan 24, 2012 at 01:08:21PM +0100, m...@apollinemike.com wrote: 2. it would be good to have something in the CG about Patchy. ...you can do this. I have 3.5 hours remaining until Jan 29. Given how often we have emergencies come up, I think I need to reserve my time for those. If nothing horrible happens this week, I could start writing something for the CG next Sunday. (which is too late, obviously) Have you actually *tried* running staging? Patchy should print a message saying I'm copying my default config file to ~/.lilypond-patchy-config-or-something-like-that, you might want to edit a few variables. If you don't ctrl-c and edit that file, it'll probably fail after a few more seconds because I doubt your filesystem is set up the way I have mine... but still, editing that file is not hard. If you've tried those steps, and got stuck somewhere, I'm happy to point out what assumption(s) I made or clear up misunderstandings. But I really don't think you'll run into any major problems. I also think that Patchy needs to be part of the LilyPond source. Too much hassle. Which directory? why include patchy but not XYZ? do we need official countdowns for patches for it? etc. Let's just leave it in github for now. It can always be moved later, but that's not a priority. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Tue, Jan 24, 2012 at 05:33:28PM -0500, Julien Rioux wrote: On 22/01/2012 2:50 PM, Graham Percival wrote: try: autoCompile.configure() autoCompile.patch(patch_filename) autoCompile.build(quick_make=True, issue_id=issue_id) autoCompile.regtest_check(issue_id) Python exception handling is simple but it can trip you up. When any of patch, build, or regtest_check fails here, we exit the try: block and end up... ah, good catch. So there is a serious flaw in the patch-testing internals of this script. When every patch succeeds, everything is fine, but when one patch fails, everything snowballs. Yeah, when the testing run has a lot of failures, I generally look at patches manually, mark anything wrong that's obviously wrong, then try a new run. Another issue is that git master is not updated to the latest origin/master before starting the test runs. This might be just a matter of documentation, but I would actually have this happen in the script itself since the name of the game is automatic testing. hmm, I thought that I added an update to origin/master to the staging merge stuff... but even if I did that correctly, there's still no harm in doing it as part of the patch testing. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music-cause
On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote: Anybody actually using the music-cause? Inside of LilyPond, the only appearance (apart from its declaration) would be /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e-set_property (music-cause, self_scm ()); If it's used anywhere, it would be here: http://lilypond.org/website/pdf/thesis-erik-sandberg It may have been added just so he could produce some graphs or tables or something? I know that I have a ton of graph-producing code in Artifastring and Vivi like that. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
checking 2240 (was: 2.16 release candidate 3 imminent)
On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. We seem to have a failure to communicate here. I shall be blunt, although I am not angry with you. I will not be doing any manual investigations about 2240 (or any other patch, for that matter). Part of the reason that we're in this miss is that we keep on saying oh, I'll do it manually just this once. If we had gotten serious about automating development tasks a year ago, we'd have saved at least 100 hours of developer time. I'm totally serious about that estimate; if anything I think I'm being conservative. I will therefore not do any manual fiddling around to test a patch or staging. Anything that fails the automatic process is rejected; if the process needs to be fixed, then fix the process. With respect to this patch, you have 4 options: - modify Patchy to do the appropriate build stuff. - recruit somebody else to modify Patchy for you. (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) - skip the review process by manually marking it as Patch-review yourself. I do not object to this, but be aware that you are therefore vouching for the patch in a much more serious way. - abandon the patch. Choice is yours. (although of course there is no problem if nothing happens on this for a few days while you do other things) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's what I suspected. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Sure, go ahead. Can I push patches on the countdown for Jan 22 by now? Colin's in Alberta, so he's 2 hours behind you. :) His last email didn't specify an exact time, but IIRC he generally uses 20:00 MST. I think it would be nice to wait until he gives the ok. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 07:58:09PM +0100, Janek Warchoł wrote: In an old e-mail i've found a link to what looks like Patchy source code https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py Correct. and i'm preparing a patch addressing David's advice, but i haven't found how patches for Patchy are announced, reviewed and pushed. Do i need to create a github account? Ideally you'd create a github account and then I can let you push directly. Otherwise, just send me or Mike a patch and we can push it for you. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 08:16:59PM +0100, Janek Warchoł wrote: 2012/1/22 Graham Percival gra...@percival-music.ca: Ideally you'd create a github account Done: janek-warchol and then I can let you push directly. No review? I hope i won't screw anything up. ok, you have push ability now. You don't need to use it unless you want to; you can send a patch for people to look at. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 08:43:26PM +0100, Janek Warchoł wrote: One quick question: Patchy checks patches one at a time, doesn't it? I.e. applies a patch (doesn't commit), tests, unapplies and moves to another patch? ... why are you asking this question? Is the source code really *that* hard to read? It's 18 lines! https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L282 for patch in patches: issue_id = patch[0] patch_filename = patch[1] title = patch[2] print Trying %i with %s % (issue_id, patch_filename) try: autoCompile.configure() autoCompile.patch(patch_filename) autoCompile.build(quick_make=True, issue_id=issue_id) autoCompile.regtest_check(issue_id) autoCompile.copy_regtests(issue_id) autoCompile.make_regtest_show_script(issue_id, title) # reverse stuff autoCompile.patch(patch_filename, reverse=True) autoCompile.regtest_clean(issue_id) autoCompile.clean(issue_id) except Exception as err: print Problem with issue %i % issue_id print err - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.16 release candidate 3 imminent
All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. But I'm not going to kick up a fuss about it. I've marked 2240 as Critical. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I disagree. I think that stable should mean *stable*, i.e. no syntax changes necessary for *that series of major version numbers*. I reject the notion that we shouldn't release a new stable version after a few months if there's no regressions in the new version. Other tools can advertise works with lilypond versions 2.14.0 and 2.17.23 if necessary. Look, this reminds me of some essay I skimmed recently by an economist who was worried that if the US paid off its debt in full, the bond market would collapse and that would have negative consequences for the world economy. I see no reason to worry about what might happen if we have too many stable releases unless that actually becomes a possibility. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make sure that you actually try those version in 2.14.0 or 2.12.3 or whatever -- I wouldn't want to blindly assume that those tests actually worked when they were added to git. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music font
On Sun, Jan 22, 2012 at 12:05:46AM +0100, Xavier Scheuer wrote: I am not a developer, just a simple user. But I must say I am a bit disappointed no developer (except Janek) replied to your e-mail. And I'm a bit disappointed that you keep on whining about developers not doing what you want them to do. I am not your slave. The fact that I have volunteered thousands of hours working on lilypond does not make me your slave. I did not crawl out of my mother's womb knowing about lilypond internals, or even about programming at all. Any knowledge I have was from hard work: reading source code, reading public emails on the list archives, and learning about programming in general. I am a bit dissapointed that *you* have not done that. You want something done? Do it yourself. That's what open source means -- you have the legal right to do it yourself. It does not mean that other people are obligated to do it for you. You have la liberté, not royauté. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Wed, Jan 18, 2012 at 02:20:09AM -0800, lilypond.patchy.gra...@gmail.com wrote: *** FAILED BUILD *** nice make doc -j3 CPU_COUNT=3 Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e /main/large-tmp/lilypond-autobuild/build/out/lybook-db/d5/lily-6e11c268.ly:1115:4: error: unknown escaped string: `\autoFootnoteGrob' - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something like that.
The slash confused me a lot, because it's also used to separate a remote
name from the branch name, like in origin/master. I'm sure that if we
will adopt dev/blahblah naming, many people will mistakenly believe
that dev is something like origin, and they will be very confused.
Good point! I like it.
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
Documentation/contributor/source-code.itexi:297: git branch dev/cg
I think it would be good to be verbose, because it will give people more
information about using git (and they won't have to ask certain
questions). In this case i would suggest
git branch dev/cg --track origin/master
But we don't want it to track origin/master, do we? People should
merge from master manually (covered in this section).
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode318
Documentation/contributor/source-code.itexi:318: @qq{profit}, I mean
@qq{push stuff to staging}.
i think this fragment is irrelevant here. It confuses me.
I don't mind removing it...
I'd write something like
You can switch to your local branches and to the remote branches as
well
instead.
... but *this* confuses me. How can git switch to a remote
branch? Aren't all branches local? I mean, whenever you switch
to a remote branch, doesn't that just create a local copy of the
remote branch, then put you on that local branch?
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode345
Documentation/contributor/source-code.itexi:345: Add a file, then commit
it:
I'd write
by default, git commit -a only commits changes to the files that
existed before you made your changes. If you want to include a file
created by you in the commit, use git add:
That's much more verbose, and it only affects 1% of git usage.
There's certainly a better wording than what is written currently,
but I don't think this is it.
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode360
Documentation/contributor/source-code.itexi:360: @subsubheading Save
commits manually (optional)
I suggest changing this to
save commits to external files or sth. like that.
Good idea!
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode362
Documentation/contributor/source-code.itexi:362: Branches are
nerve-wracking until you get used to them. You can
Insert After you committed your changes, you can...
(format-patch doesn't work with uncommitted changes)
+1
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode463
Documentation/contributor/source-code.itexi:463: If everything looks
good, push it:
maybe push it to the staging branch located on remote origin? This
will give contributor more information about what he is doing (= less
questions to answer).
I think that mentioning local or remote will only add
confusion. The goal is not to explain how to use git; the goal is
to let people use git as painlessly as possible.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
