Re: git on Windows (was: Re: git not fetching from origin...)
Johannes Schindelin wrote Tuesday, May 26, 2009 12:05 AM Hi, On Mon, 25 May 2009, Mark Polesky wrote: 1.5.2 Installing git 0) Full installer or portable application? This is my fault; PortableGit is a recent addition. I'd recommend the installer (but not the "full" installer available from msysgit.googlecode.com). Yes, PortableGit wasn't there when I wrote this section. I'll try to find some words that distinguish the options clearly, but the names are so similar it's not easy. 1) Describe Windows Explorer integration. something like: Selecting and/or will add the option(s) to the pop-up menu when you right-click on a folder. And I thought this was really well described in the Git Installer. I never did this myself; I simply start bash and cd to the repo. But I can see it would be useful. I'll add a bit referring to the instructions in the installer. 2) Recommend a command line option. Use Git Bash only? Run Git from the Windows Command Prompt? Run Git and included Unix tools from the Windows Command Prompt? Is there really a need to recommend anything else than the default? No, but I can see this can be made clearer. 3) Recommend an SSH executable. OpenSSH or PLink? Or maybe briefly describe the difference or link to a description? Both have their own set of problems; it is basically up to you which poison you choose. SSH is required only if you have authority to push to remote/origin. I've assumed the reader (as someone new to git) would not have this, so it's not mentioned. How to get write access to the remote repository would need a whole section to itself! 4) Recommend a CR/LF behavior. Use Unix style line endings? Use Windows style line endings? Commit line endings as they are? Again, I think the default is sane here (unless somebody fscks up and commits files with CR/LF line endings). Or Mac line endings. It is essential to use the default in my opinion, so I'll make this clear. Perhaps I should also mention that any files pushed (by others) to remote/origin/master with Mac line endings screw up a Windows respository when pulled. The only way out, as far as I have been able to discover, is for someone with write access to fix them immediately. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Hi, On Tue, 26 May 2009, Trevor Daniels wrote: > Johannes Schindelin wrote Tuesday, May 26, 2009 12:05 AM > > > On Mon, 25 May 2009, Mark Polesky wrote: > > > > > 1.5.2 Installing git > > > > > > 0) Full installer or portable application? > > > > This is my fault; PortableGit is a recent addition. I'd recommend the > > installer (but not the "full" installer available from > > msysgit.googlecode.com). > > Yes, PortableGit wasn't there when I wrote this section. > I'll try to find some words that distinguish the options > clearly, but the names are so similar it's not easy. I'd just say: don't use PortableGit. It is not a full installation and meant to enable you to take Git on a USB stick with you. Hardly the setup with LilyPond. > > > 1) Describe Windows Explorer integration. > > > > > > something like: > > > Selecting and/or > > > will add the option(s) to the pop-up menu when you > > > right-click > > > on a folder. > > > > And I thought this was really well described in the Git Installer. > > I never did this myself; I simply start bash and cd to > the repo. But I can see it would be useful. I'll > add a bit referring to the instructions in the installer. > > > > 2) Recommend a command line option. > > > Use Git Bash only? > > > Run Git from the Windows Command Prompt? > > > Run Git and included Unix tools from the Windows Command > > > Prompt? > > > > Is there really a need to recommend anything else than the default? > > No, but I can see this can be made clearer. > > > > 3) Recommend an SSH executable. OpenSSH or PLink? Or maybe > > > briefly describe the difference or link to a description? > > > > Both have their own set of problems; it is basically up to you which > > poison you choose. > > > > SSH is required only if you have authority to push > to remote/origin. I've assumed the reader (as someone > new to git) would not have this, so it's not mentioned. > How to get write access to the remote repository would need > a whole section to itself! Exactly. So why not say "it does not matter what you choose here until you have direct push permissions to the Git repository"? > > > 4) Recommend a CR/LF behavior. > > > Use Unix style line endings? > > > Use Windows style line endings? > > > Commit line endings as they are? > > > > Again, I think the default is sane here (unless somebody fscks up and > > commits files with CR/LF line endings). > > Or Mac line endings. > > It is essential to use the default in my opinion, > so I'll make this clear. Perhaps I should also > mention that any files pushed (by others) to > remote/origin/master with Mac line endings screw > up a Windows respository when pulled. The only > way out, as far as I have been able to discover, > is for someone with write access to fix them > immediately. Mac line endings will pretty much screw everybody, including Mac users, as Git's diff engine (which is responsible for merging, too) relies on LF being the last byte in every line. But then, I am not aware of anyone managing to get LilyPond to run on MacOS < 10.*, and on MacOSX, the native line ending is LF. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Johannes Schindelin wrote Tuesday, May 26, 2009 8:53 AM Hi, On Tue, 26 May 2009, Trevor Daniels wrote: Johannes Schindelin wrote Tuesday, May 26, 2009 12:05 AM > On Mon, 25 May 2009, Mark Polesky wrote: > > > 1.5.2 Installing git > > > > 0) Full installer or portable application? > > This is my fault; PortableGit is a recent addition. I'd > recommend the > installer (but not the "full" installer available from > msysgit.googlecode.com). Yes, PortableGit wasn't there when I wrote this section. I'll try to find some words that distinguish the options clearly, but the names are so similar it's not easy. I'd just say: don't use PortableGit. It is not a full installation and meant to enable you to take Git on a USB stick with you. Hardly the setup with LilyPond. OK, that's what I had in mind. Thanks for the confirmation. > > 3) Recommend an SSH executable. OpenSSH or PLink? Or maybe > > briefly describe the difference or link to a description? > > Both have their own set of problems; it is basically up to you > which > poison you choose. > SSH is required only if you have authority to push to remote/origin. I've assumed the reader (as someone new to git) would not have this, so it's not mentioned. How to get write access to the remote repository would need a whole section to itself! Exactly. So why not say "it does not matter what you choose here until you have direct push permissions to the Git repository"? Or maybe, "SSH is not required until you have direct push permissions to the Git repository."? > > 4) Recommend a CR/LF behavior. > > Use Unix style line endings? > > Use Windows style line endings? > > Commit line endings as they are? > > Again, I think the default is sane here (unless somebody fscks > up and > commits files with CR/LF line endings). Or Mac line endings. It is essential to use the default in my opinion, so I'll make this clear. Perhaps I should also mention that any files pushed (by others) to remote/origin/master with Mac line endings screw up a Windows respository when pulled. The only way out, as far as I have been able to discover, is for someone with write access to fix them immediately. Mac line endings will pretty much screw everybody, including Mac users, as Git's diff engine (which is responsible for merging, too) relies on LF being the last byte in every line. But then, I am not aware of anyone managing to get LilyPond to run on MacOS < 10.*, and on MacOSX, the native line ending is LF. Even so, Mac line endings have found their way into Lily's remote/origin/master several times in the last couple of years. I thought only Windows was affected, as no one else seemed to be concerned about it. I fixed them as soon as they appeared. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Hi, On Tue, 26 May 2009, Trevor Daniels wrote: > Johannes Schindelin wrote Tuesday, May 26, 2009 8:53 AM > > > On Tue, 26 May 2009, Trevor Daniels wrote: > > > > > Johannes Schindelin wrote Tuesday, May 26, 2009 12:05 AM > > > > > > > On Mon, 25 May 2009, Mark Polesky wrote: > > > > > > > > > 1.5.2 Installing git > > > > > > > > > > 0) Full installer or portable application? > > > > > > > > This is my fault; PortableGit is a recent addition. I'd recommend the > > > > installer (but not the "full" installer available from > > > > msysgit.googlecode.com). > > > > > > Yes, PortableGit wasn't there when I wrote this section. > > > I'll try to find some words that distinguish the options > > > clearly, but the names are so similar it's not easy. > > > > I'd just say: don't use PortableGit. It is not a full installation and > > meant to enable you to take Git on a USB stick with you. Hardly the setup > > with LilyPond. > > OK, that's what I had in mind. Thanks for the confirmation. Heh, you're welcome! > > > > > 3) Recommend an SSH executable. OpenSSH or PLink? Or maybe > > > > > briefly describe the difference or link to a description? > > > > > > > > Both have their own set of problems; it is basically up to you which > > > > poison you choose. > > > > > > > > > > SSH is required only if you have authority to push > > > to remote/origin. I've assumed the reader (as someone > > > new to git) would not have this, so it's not mentioned. > > > How to get write access to the remote repository would need > > > a whole section to itself! > > > > Exactly. So why not say "it does not matter what you choose here until > > you have direct push permissions to the Git repository"? > > Or maybe, "SSH is not required until you have direct push permissions to > the Git repository."? Much better. > > > > > 4) Recommend a CR/LF behavior. > > > > > Use Unix style line endings? > > > > > Use Windows style line endings? > > > > > Commit line endings as they are? > > > > > > > > Again, I think the default is sane here (unless somebody fscks up and > > > > commits files with CR/LF line endings). > > > > > > Or Mac line endings. > > > > > > It is essential to use the default in my opinion, > > > so I'll make this clear. Perhaps I should also > > > mention that any files pushed (by others) to > > > remote/origin/master with Mac line endings screw > > > up a Windows respository when pulled. The only > > > way out, as far as I have been able to discover, > > > is for someone with write access to fix them > > > immediately. > > > > Mac line endings will pretty much screw everybody, including Mac users, as > > Git's diff engine (which is responsible for merging, too) relies on LF > > being the last byte in every line. > > > > But then, I am not aware of anyone managing to get LilyPond to run on > > MacOS < 10.*, and on MacOSX, the native line ending is LF. > > Even so, Mac line endings have found their way > into Lily's remote/origin/master several times > in the last couple of years. I thought only > Windows was affected, as no one else seemed to be > concerned about it. I fixed them as soon as > they appeared. Oh... Well, you probably did not do much merging on these files as long as they were CR-only, I guess... ;-) Thanks, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Johannes Schindelin Tuesday, May 26, 2009 9:37 AM > > > > 4) Recommend a CR/LF behavior. > > > > Use Unix style line endings? > > > > Use Windows style line endings? > > > > Commit line endings as they are? > > > > > > Again, I think the default is sane here (unless somebody > > > fscks up and > > > commits files with CR/LF line endings). > > > > Or Mac line endings. > > > > It is essential to use the default in my opinion, > > so I'll make this clear. Perhaps I should also > > mention that any files pushed (by others) to > > remote/origin/master with Mac line endings screw > > up a Windows respository when pulled. The only > > way out, as far as I have been able to discover, > > is for someone with write access to fix them > > immediately. > > Mac line endings will pretty much screw everybody, including > Mac users, as > Git's diff engine (which is responsible for merging, too) > relies on LF > being the last byte in every line. > > But then, I am not aware of anyone managing to get LilyPond to > run on > MacOS < 10.*, and on MacOSX, the native line ending is LF. Even so, Mac line endings have found their way into Lily's remote/origin/master several times in the last couple of years. I thought only Windows was affected, as no one else seemed to be concerned about it. I fixed them as soon as they appeared. Oh... Well, you probably did not do much merging on these files as long as they were CR-only, I guess... ;-) Exactly so! The first time it happened was quite traumatic. Now I know what to do it's just a nuisance. Fortunately they show up in my repo as soon as I try to merge after fetching from remote, so I spot them right away and push a fix. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
When I installed git, I selected Unix style line endings. Now every time I or even I get this warning for *each* modified file: warning: CRLF will be replaced by LF in . - Mark - Original Message > From: Trevor Daniels > To: Johannes Schindelin > Cc: Mark Polesky ; Jonathan Kulp > ; Carl D. Sorensen ; > lilypond-devel > Sent: Tuesday, May 26, 2009 1:57:07 AM > Subject: Re: git on Windows (was: Re: git not fetching from origin...) > > > Johannes Schindelin Tuesday, May 26, 2009 9:37 AM > > >> > > > > 4) Recommend a CR/LF behavior. > >> > > > > Use Unix style line endings? > >> > > > > Use Windows style line endings? > >> > > > > Commit line endings as they are? > >> > > > > >> > > > Again, I think the default is sane here (unless somebody > > > fscks > >> > > > up > and > >> > > > commits files with CR/LF line endings). > >> > > > >> > > Or Mac line endings. > >> > > > >> > > It is essential to use the default in my opinion, > >> > > so I'll make this clear. Perhaps I should also > >> > > mention that any files pushed (by others) to > >> > > remote/origin/master with Mac line endings screw > >> > > up a Windows respository when pulled. The only > >> > > way out, as far as I have been able to discover, > >> > > is for someone with write access to fix them > >> > > immediately. > >> > > >> > Mac line endings will pretty much screw everybody, including > Mac > >> > users, > as > >> > Git's diff engine (which is responsible for merging, too) > relies on LF > >> > being the last byte in every line. > >> > > >> > But then, I am not aware of anyone managing to get LilyPond to > run on > >> > MacOS < 10.*, and on MacOSX, the native line ending is LF. > >> > >> Even so, Mac line endings have found their way > >> into Lily's remote/origin/master several times > >> in the last couple of years. I thought only > >> Windows was affected, as no one else seemed to be > >> concerned about it. I fixed them as soon as > >> they appeared. > > > > Oh... Well, you probably did not do much merging on these files as long as > > they were CR-only, I guess... ;-) > > Exactly so! The first time it happened was > quite traumatic. Now I know what to do it's > just a nuisance. Fortunately they show up in > my repo as soon as I try to merge after fetching > from remote, so I spot them right away and push a > fix. > > Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR 2.12
2009/5/25 Jonathan Kulp : > Valentin, the tarball is ready and will be coming in a private email. Mats has changed a couple of snippets since you sent me the tarball. What do we do about it? (I'm afraid we'll have to take the LSR offline until it's updated, to make sure nothing gets lost in the process.) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Hi, On Tue, 26 May 2009, Mark Polesky wrote: > When I installed git, I selected Unix style line endings. > Now every time I or even > I get this warning for *each* modified file: > > warning: CRLF will be replaced by LF in . Please do not top-post. At least remove the stuff you are not replying to. I think you could replace the "input" with "true" in you /etc/gitconfig's autocrlf setting in the [core] section. This should take care of the issue. If not, please report, then I will give you the whole story so that you can fix it on your side. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR 2.12
On Tue, May 26, 2009 at 11:36:55AM +0200, Valentin Villenave wrote: > 2009/5/25 Jonathan Kulp : > > Valentin, the tarball is ready and will be coming in a private email. > > Mats has changed a couple of snippets since you sent me the tarball. > What do we do about it? (I'm afraid we'll have to take the LSR offline > until it's updated, to make sure nothing gets lost in the process.) What you do about it is use your own best judgement and get the bloody thing finished. OBVIOUSLY Mats is completely incompetent, so ignore anything he sent you and take Jonathan's complete tarball. Alternately, if you think he just /might/ know what he's doing, then compare the snippets and go with whatever you think is best. Then add them back to the tarball, and send it to Sebastiano. Or maybe ignore them for now, dump the complete tarball in the new LSR, then update the snippets that Mats sent you manually. And fine, take LSR offline. For a maoing week. Just get it done! What precisely was the question here? You're in charge of this project, but if you keep on asking about every maoing step, the job will take, oh, 5 months. Sometimes you need to just make a decision by yourself. If you're right, people thank you for a job well done. If you're wrong, then people complain at you, and you explain why you chose what you did. It's like a game; you gain or lose reputation by how successful your decisions are. Of course, deciding not to make any decisions is *itself* a decision... and one which doesn't precisely add to your glory. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where to put useful lists in the docs?
On Mon, May 25, 2009 at 12:38:57PM -0700, Mark Polesky wrote: > > Here are two generic functions that could be incorporated into IR > 4 "Scheme functions" (though if C++ is required, someone else > would have to help). Looks great! If there's problems getting it into the IR, it could be added to NR 6 instead. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
traveling back to Canada
I'm flying back to Canada the day after tomorrow, but due to concerns about waking up early and/or finding a taxi at 4am and/or curiosity about "it's such a great airport", I'm going to the airport tomorrow. The airport is supposed to have free wireless access, but this access may or may not allow me to send emails. Consider me absent until May 29 (US time -- I arrive on the 28th, but I'll probably spend the rest of the day sleeping). I've updated the htaccess on lilypond.org, but I don't know if that fixed anything. (ok, I don't need the next 6 hours to pack, but after that, consider me absent. If I'm around, consider yourselves blessed :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Werner LEMBERG wrote: If there is at least one blank (on a german Windows the home directory is called "c:\Dokumente und Einstellungen\") searching does not work. I suggest that you contact the help-m...@gnu.org mailing list, providing a minimal (trivial) example demonstrating the VPATH problem. Either this is a bug in the Windows port of GNU make, or they know a solution. This is a known issue. I found this (old but apparently still relevant) posting about it: Pathnames and white space: Unlike Unix, Windows 95/NT systems encourage pathnames which contain white space (e.g. C:\Program Files\). These sorts of pathnames are legal under Unix too, but are never encouraged. There is at least one place in make (VPATH/vpath handling) where paths containing white space will simply not work. There may be others too. I chose to not try and port make in such a way so that these sorts of paths could be handled. I offer these suggestions as workarounds: 1. Use 8.3 notation 2. Rename the directory so it does not contain white space. If you are unhappy with this choice, this is free software and you are free to take a crack at making this work. The code in w32/pathstuff.c and vpath.c would be the places to start." In the meantime I'll be sure there's a warning about this issue in the docs. I had the directory on the desktop, and there are no spaces in that path so it worked. When I tried to rename the "Documents and Settings" directory on XP, I got a warning saying it was a system folder and it was dangerous to rename. Windows 7 must have a different directory structure--now the "My Documents" directory is a subdirectory of my user directory. It allowed me to change "My Documents" to "Documents" without warning. # The pattern rule to create PDF and MIDI files from a LY input # file. The .pdf output files are created in the `PDF' # subdirectory, and the .midi files are put into the `MIDI' # subdirectory. %.pdf %.midi: %.ly $(LILY_CMD) $< if exist "$*.pdf" move /Y "$*.pdf" PDF/ if exist "$*.mid" move /Y "$*.mid" MIDI/ Uuh, you are using `%.midi' in the rule but you are moving *.mid files! You should use `%.mid' too since this is what lilypond creates if run on Windows, right? The comment should be updated accordingly. You're right, but oddly, it worked as expected even without fixing the pattern rule. The .mid files were put into the MIDI directory. I had forgotten the different suffixes until I saw them in there. I'll fix it in the Windows Makefile though. Thanks Werner, Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR 2.12
Graham Percival wrote: On Tue, May 26, 2009 at 11:36:55AM +0200, Valentin Villenave wrote: 2009/5/25 Jonathan Kulp : Valentin, the tarball is ready and will be coming in a private email. Mats has changed a couple of snippets since you sent me the tarball. What do we do about it? (I'm afraid we'll have to take the LSR offline until it's updated, to make sure nothing gets lost in the process.) Valentin, I created the tarball *after* incorporating Mats' changes to the snippet with polymeter. Is that the one you're talking about? He posted a fix on the mailing list, so I put it in the appropriate snippet, tested it, then created the tarball and mailed it to you. That's the only change I'm aware of. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> Uuh, you are using `%.midi' in the rule but you are moving *.mid >> files! You should use `%.mid' too since this is what lilypond >> creates if run on Windows, right? The comment should be updated >> accordingly. > > You're right, but oddly, it worked as expected even without fixing > the pattern rule. The .mid files were put into the MIDI directory. Well, if you don't mention the MIDI file somewhere else in the Makefile, the `%.midi: %.ly' rule never gets executed -- it is the `%.pdf: %.ly' part which creates both PDF and MIDI output (and which subsequently gets renamed afterwards). For testing purposes, you might try to add foo: $(piece)I.mid to the make file, retaining the incorrect rule. Now saying make foo won't work at all. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
On 5/26/09 2:57 AM, "Trevor Daniels" wrote: > > > Johannes Schindelin Tuesday, May 26, 2009 9:37 AM > >>> 4) Recommend a CR/LF behavior. >>> Use Unix style line endings? >>> Use Windows style line endings? >>> Commit line endings as they are? >> >> Again, I think the default is sane here (unless somebody >> fscks up and >> commits files with CR/LF line endings). > > Or Mac line endings. > > It is essential to use the default in my opinion, > so I'll make this clear. Perhaps I should also > mention that any files pushed (by others) to > remote/origin/master with Mac line endings screw > up a Windows respository when pulled. The only > way out, as far as I have been able to discover, > is for someone with write access to fix them > immediately. Mac line endings will pretty much screw everybody, including Mac users, as Git's diff engine (which is responsible for merging, too) relies on LF being the last byte in every line. But then, I am not aware of anyone managing to get LilyPond to run on MacOS < 10.*, and on MacOSX, the native line ending is LF. >>> >>> Even so, Mac line endings have found their way >>> into Lily's remote/origin/master several times >>> in the last couple of years. I thought only >>> Windows was affected, as no one else seemed to be >>> concerned about it. I fixed them as soon as >>> they appeared. >> >> Oh... Well, you probably did not do much merging on these files as >> long as >> they were CR-only, I guess... ;-) > > Exactly so! The first time it happened was > quite traumatic. Now I know what to do it's > just a nuisance. Fortunately they show up in > my repo as soon as I try to merge after fetching > from remote, so I spot them right away and push a > fix. I suppose that CR-only endings might come from me, using a Mac with Entourage as my email client. When I save a patch file from Entourage as text, it shows up as CR-only endings. When I make my own patches, they're Unix line endings. Trevor, could you do a quick search for the fixes you've pushed, and identify the patches that caused the problem? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Hi, On Tue, 26 May 2009, Carl D. Sorensen wrote: > When I make my own patches, they're Unix line endings. > > Trevor, could you do a quick search for the fixes you've pushed, and > identify the patches that caused the problem? You can let Git search for you: $ git log -S"$(printf "\r")" If you want to see the corresponding patches, too, say $ git log -S"$(printf "\r")" -p Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
On 5/26/09 7:10 AM, "Johannes Schindelin" wrote: > Hi, > > On Tue, 26 May 2009, Carl D. Sorensen wrote: > >> When I make my own patches, they're Unix line endings. >> >> Trevor, could you do a quick search for the fixes you've pushed, and >> identify the patches that caused the problem? > > You can let Git search for you: > > $ git log -S"$(printf "\r")" > > If you want to see the corresponding patches, too, say > > $ git log -S"$(printf "\r")" -p Thanks, Dscho. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mac OS Line endings (was Re: git on Windows (was: Re: git not fetching from origin...))
Hi, In checking this out, it appears that nearly all of the MacOS line endings (CR-only) were in musicxml regression test files from Reinhold. So apparently my hypothesis/concern was invalid. Fortunately, I haven't been adding CR-only endings when I pushed other people's patches. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR 2.12
2009/5/26 Jonathan Kulp : > I created the tarball *after* incorporating Mats' changes to the snippet > with polymeter. Is that the one you're talking about? He posted a fix on > the mailing list, so I put it in the appropriate snippet, tested it, then > created the tarball and mailed it to you. That's the only change I'm aware > of. Oh, great. I was referring to http://lists.gnu.org/archive/html/lilypond-user/2009-05/msg00615.html as well, but this one can certainly be added manually. I'll go ahead and use your tarball then! Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: traveling back to Canada
2009/5/26 Graham Percival : > Consider me absent until May 29 (US time -- I arrive on the 28th, > but I'll probably spend the rest of the day sleeping). I've > updated the htaccess on lilypond.org, but I don't know if that > fixed anything. Have a nice flight! Looking forward to seeing you (on the list, and maybe later in France :-) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Johannes Schindelin wrote: > Please do not top-post. At least remove the stuff you are not > replying to. oops - sorry. > I think you could replace the "input" with "true" in you > /etc/gitconfig's autocrlf setting in the [core] section. This > should take care of the issue. It does, thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git on Windows (was: Re: git not fetching from origin...)
Hi, On Tue, 26 May 2009, Mark Polesky wrote: > Johannes Schindelin wrote: > > > I think you could replace the "input" with "true" in you > > /etc/gitconfig's autocrlf setting in the [core] section. This should > > take care of the issue. > > It does, thanks. Great! Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Am 26.05.2009, 04:13 Uhr, schrieb Jonathan Kulp :
I had to comment out one more thing before it would run properly,
though--the "-djob-count" option, something we put in on the Linux
version to take advantage of dual processors. It choked on that saying
"unbound variable 'primitive-fork'". This could be because I'm running
on a virtual machine, though. Did it work properly for you with the
multiple jobs option?
Hi Jon,
it worked properly for me. Maybe you got the long line cut like I saw
it on the gmane web interface. Below I put a version with three lines
for the lilypond command (as attachement also).
BTW: I got no difference with the "-djob-count" or without it.
With the option: 2:45.218
without: 2:45.000(!)
(On a 2.2GHz Athlon 64 X2 Dual Core Processor--is that a normal time?)
Seems as if the option should be omitted on Windows for simplicity.
I also got a way to work around the path-with-blank(s) problem.
Instead of CURDIR I fill and use a variable "workdir" in VPATH.
(Change the name if you like, I'm not a native speaker.) The used
technique for getting the 8.3 version of CURDIR is explained near
the end of the help for the command for ("for /h" on the Windows
commandline).
Instead of %%b %%a could be used, but as a German I don't like sa...
I am looking for a way to distinguish from within the makefile
if make is running on Linux or Windows. Perhaps we could use the
environment variable "OS" which is OS=Windows_NT on my computer.
make has "ifdef variable-name" and "ifeq (arg1, arg2)", so there
should be a chance. Then perhaps it could be possible to have the
same makefile for Linux (and OSX?) and Windows.
Does Linux have a varialble OS? If not, we can check for
existence, if yes we check the value.
Regarding the mid/midi thing:
We could use -dmidi-extension to set the default file extension
for MIDI output file to midi, but that touches the question of
the proper extension for midi.
(http://news.gmane.org/find-root.php?message_id=%3c20090408193658.GA2963%40zonnet.nl%3e)
Could we let lilypond give us the answer itself?
On Windows:
MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
('lilypond -dhelp 2^>nul^|find "midi-extension"') \
do echo %%a)
How can this be achived on Linux? You would have to build a
command that gives
midi
and nothing else.
Henning
# the name stem of the output files
piece = stamitz
# The command to run lilypond
LILY_CMD = lilypond -ddelete-intermediate-files \
-dno-point-and-click \
-djob-count=$(NUMBER_OF_PROCESSORS)
#get the 8.3 name of CURDIR
workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
do @echo %%~sb)
# let lilypond tell us the default midi extension
MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
('lilypond -dhelp 2^>nul^|find "midi-extension"') \
do echo %%a)
#remove all doublequotes
MidiExt = $(subst ",,$(MidiExtWithQuotes))
# The suffixes used in this Makefile.
.SUFFIXES: .ly .ily .pdf .$(MidiExt)
# Input and output files are searched in the directories listed in
# the VPATH variable. All of them are subdirectories of the current
# directory (given by the workdir variable which is the 8.3 version
# of the GNU make variable `CURDIR').
VPATH = \
$(workdir)/Scores \
$(workdir)/PDF \
$(workdir)/Parts \
$(workdir)/Notes
# The pattern rule to create PDF and MIDI files from a LY input file.
# The .pdf output files are created in the `PDF' subdirectory, and the
# .midi files are put into the `MIDI' subdirectory.
%.pdf %.$(MidiExt): %.ly
$(LILY_CMD) $<
if exist "$*.pdf" move /Y "$*.pdf" PDF/
if exist "$*.$(MidiExt)" move /Y "$*.$(MidiExt)" MIDI/
notes = \
cello.ily \
figures.ily \
horn.ily \
oboe.ily \
trioString.ily \
viola.ily \
violinOne.ily \
violinTwo.ily
# The dependencies of the movements.
$(piece)I.pdf: $(piece)I.ly $(notes)
$(piece)II.pdf: $(piece)II.ly $(notes)
$(piece)III.pdf: $(piece)III.ly $(notes)
$(piece)IV.pdf: $(piece)IV.ly $(notes)
# The dependencies of the full score.
$(piece).pdf: $(piece).ly $(notes)
# The dependencies of the parts.
$(piece)-cello.pdf: $(piece)-cello.ly cello.ily \
figures.ily \
trioString.ily
$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
# Say `make score' to generate the full score of all four
# movements as one file.
.PHONY: score
score: $(piece).pdf
# Say `make parts' to generate all parts.
# Say `make foo.pdf' to generate the part for instrument `foo'.
# Example: `make cello.pdf'.
.PHONY: parts
parts: $(piece)-cello.pdf \
$(piece)-violinOne.pdf \
$(piece)-violinTwo.pdf \
$(piece)-v
Re: LSR 2.12
Quoting Valentin Villenave : 2009/5/26 Jonathan Kulp : I created the tarball *after* incorporating Mats' changes to the snippet with polymeter. Is that the one you're talking about? He posted a fix on the mailing list, so I put it in the appropriate snippet, tested it, then created the tarball and mailed it to you. That's the only change I'm aware of. Oh, great. I was referring to http://lists.gnu.org/archive/html/lilypond-user/2009-05/msg00615.html as well, but this one can certainly be added manually. I'll go ahead and use your tarball then! I just added a new LSR item today, "Setting the mimimum length of a fall/doit", which should work equally well on 2.10 and 2.12 without modifications. /Mats Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
2009/5/25 Andrew Hawryluk : > Yes, I'll take a look at it. Thanks, Neil for catching those! No problem. I'm sorry I didn't respond earlier; though I'd taken a cursory look at the patch (and noticed the backquote issue), I didn't expect it to be committed so soon. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
2009/5/24 Carl D. Sorensen : > On a more general note, do you have any suggestions for how to check > convert-ly rules? For code, we have regression tests. For convert-ly, as > far as I know, we have nothing. Should we be establishing convert-ly > regression tests? I'm not sure how that would work. Convert rules are unlikely to break unless there are drastic changes between Python versions, so I think the best option is to keep each rule as specific as possible and test it thoroughly before it's committed. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Henning Plumeyer wrote:
Am 26.05.2009, 04:13 Uhr, schrieb Jonathan Kulp :
I had to comment out one more thing before it would run properly,
though--the "-djob-count" option, something we put in on the Linux
version to take advantage of dual processors. It choked on that
saying "unbound variable 'primitive-fork'". This could be because I'm
running on a virtual machine, though. Did it work properly for you
with the multiple jobs option?
Hi Jon,
it worked properly for me. Maybe you got the long line cut like I saw
it on the gmane web interface. Below I put a version with three lines
for the lilypond command (as attachement also).
Hmm. It still doesn't work for me with the job-count option. It must
be because I'm using virtual machines. I installed a virtual XP machine
today for testing. It has the annoying "Documents and Settings" with
spaces in the dirname. Windows 7 at least doesn't have this problem.
BTW: I got no difference with the "-djob-count" or without it.
With the option: 2:45.218
without: 2:45.000(!)
(On a 2.2GHz Athlon 64 X2 Dual Core Processor--is that a normal time?)
Seems as if the option should be omitted on Windows for simplicity.
I also got a way to work around the path-with-blank(s) problem.
Instead of CURDIR I fill and use a variable "workdir" in VPATH.
(Change the name if you like, I'm not a native speaker.) The used
technique for getting the 8.3 version of CURDIR is explained near
the end of the help for the command for ("for /h" on the Windows
commandline).
I like this. It's probably essential for Windows versions earlier than
Vista that have the spaces in the dirnames. Thanks for figuring this
out. It works great.
Instead of %%b %%a could be used, but as a German I don't like sa...
I am looking for a way to distinguish from within the makefile
if make is running on Linux or Windows. Perhaps we could use the
environment variable "OS" which is OS=Windows_NT on my computer.
make has "ifdef variable-name" and "ifeq (arg1, arg2)", so there
should be a chance. Then perhaps it could be possible to have the
same makefile for Linux (and OSX?) and Windows.
Does Linux have a varialble OS? If not, we can check for
existence, if yes we check the value.
When I run "env" I don't get a value for OS. In my shell scripts that I
want to run on either Linux or Mac OSX, I check OS with this:
OS=$(uname)
Really, though, I think it's probably best to have two different
Makefiles to avoid complication. These are intended to give noobs
direction in creating their own, and for me it's better to reduce the
complications.
Regarding the mid/midi thing:
We could use -dmidi-extension to set the default file extension
for MIDI output file to midi, but that touches the question of
the proper extension for midi.
(http://news.gmane.org/find-root.php?message_id=%3c20090408193658.GA2963%40zonnet.nl%3e)
Could we let lilypond give us the answer itself?
On Windows:
MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
('lilypond -dhelp 2^>nul^|find "midi-extension"') \
do echo %%a)
How can this be achived on Linux? You would have to build a
command that gives
midi
and nothing else.
This is a pretty cool feature you've written but I'm inclined just to
live with .mid for the sake of simplicity.
At one point I had a target to create only midi, but now I'm letting the
midi files be created by the "movements" target. None of the other
targets create midi files. It would be easy to have a midi-only target
with the -dno-print-pages option, I guess. Do you think it would be
better to separate midi into its own target?
Jon
# the name stem of the output files
piece = stamitz
# The command to run lilypond
LILY_CMD = lilypond -ddelete-intermediate-files \
-dno-point-and-click \
-djob-count=$(NUMBER_OF_PROCESSORS)
#get the 8.3 name of CURDIR
workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
do @echo %%~sb)
# let lilypond tell us the default midi extension
MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
('lilypond -dhelp 2^>nul^|find "midi-extension"') \
do echo %%a)
#remove all doublequotes
MidiExt = $(subst ",,$(MidiExtWithQuotes))
# The suffixes used in this Makefile.
.SUFFIXES: .ly .ily .pdf .$(MidiExt)
# Input and output files are searched in the directories listed in
# the VPATH variable. All of them are subdirectories of the current
# directory (given by the workdir variable which is the 8.3 version
# of the GNU make variable `CURDIR').
VPATH = \
$(workdir)/Scores \
$(workdir)/PDF \
$(workdir)/Parts \
$(workdir)/Notes
# The pattern rule to create PDF and MIDI files from a LY input file.
# The .pdf output files are created in the `PDF' subdirectory, and the
# .midi files are put into the `MIDI' subdirectory.
%.pdf %.$(MidiExt): %.ly
$(LILY_CMD) $<
if exist "$*.pdf" move /Y "$*.pdf"
Re: DOCS: revising LM "Score and Parts"
Am 27.05.2009, 04:41 Uhr, schrieb Jonathan Kulp :
Henning Plumeyer wrote:
Am 26.05.2009, 04:13 Uhr, schrieb Jonathan Kulp
:
I had to comment out one more thing before it would run properly,
though--the "-djob-count" option, something we put in on the Linux
version to take advantage of dual processors. It choked on that
saying "unbound variable 'primitive-fork'". This could be because I'm
running on a virtual machine, though. Did it work properly for you
with the multiple jobs option?
Hi Jon,
it worked properly for me. Maybe you got the long line cut like I saw
it on the gmane web interface. Below I put a version with three lines
for the lilypond command (as attachement also).
Hmm. It still doesn't work for me with the job-count option. It must
be because I'm using virtual machines.
What do you get if you type "set n" (Without the quotes)? It gives all
environment variables beginning with n or N. Is there
NUMBER_OF_PROCESSORS?
BTW: I got no difference with the "-djob-count" or without it.
With the option: 2:45.218
without: 2:45.000(!)
(On a 2.2GHz Athlon 64 X2 Dual Core Processor--is that a normal time?)
Seems as if the option should be omitted on Windows for simplicity.
The numbers 2:45.xxx are seconds of command duration (sorry, I didn't
write a unit after them). As you see, the "-djob-count" option has no
use at least for me.
I also got a way to work around the path-with-blank(s) problem.
Instead of CURDIR I fill and use a variable "workdir" in VPATH.
(Change the name if you like, I'm not a native speaker.) The used
technique for getting the 8.3 version of CURDIR is explained near
the end of the help for the command for ("for /h" on the Windows
commandline).
I like this. It's probably essential for Windows versions earlier than
Vista that have the spaces in the dirnames. Thanks for figuring this
out. It works great.
Fine.
Instead of %%b %%a could be used, but as a German I don't like sa...
I am looking for a way to distinguish from within the makefile
if make is running on Linux or Windows. Perhaps we could use the
environment variable "OS" which is OS=Windows_NT on my computer.
make has "ifdef variable-name" and "ifeq (arg1, arg2)", so there
should be a chance. Then perhaps it could be possible to have the
same makefile for Linux (and OSX?) and Windows.
Does Linux have a varialble OS? If not, we can check for
existence, if yes we check the value.
When I run "env" I don't get a value for OS. In my shell scripts that I
want to run on either Linux or Mac OSX, I check OS with this:
OS=$(uname)
Really, though, I think it's probably best to have two different
Makefiles to avoid complication. These are intended to give noobs
direction in creating their own, and for me it's better to reduce the
complications.
I agree, as it is an example it should be as simple as possible.
Regarding the mid/midi thing:
We could use -dmidi-extension to set the default file extension
for MIDI output file to midi, but that touches the question of
the proper extension for midi.
(http://news.gmane.org/find-root.php?message_id=%3c20090408193658.GA2963%40zonnet.nl%3e)
Could we let lilypond give us the answer itself?
On Windows:
MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
('lilypond -dhelp 2^>nul^|find "midi-extension"') \
do echo %%a)
How can this be achived on Linux? You would have to build a
command that gives
midi
and nothing else.
This is a pretty cool feature you've written but I'm inclined just to
live with .mid for the sake of simplicity.
Yes.
At one point I had a target to create only midi, but now I'm letting the
midi files be created by the "movements" target. None of the other
targets create midi files. It would be easy to have a midi-only target
with the -dno-print-pages option, I guess. Do you think it would be
better to separate midi into its own target?
No, because I think midi is often used to check if everything is correct.
If you then hear a mistake you need the pdf to see what is written. For
this purpose, pdf and mid belong together.
I think you will modify the file as you want. Ask me if you want me to
do that.
Henning
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
