Re: Problem running makelsr.py
- Original Message - From: Graham Percival gra...@percival-music.ca To: James pkx1...@gmail.com; Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Sunday, April 15, 2012 10:24 PM Subject: Re: Problem running makelsr.py On Sun, Apr 15, 2012 at 10:18:41PM +0100, James wrote: james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py Traceback (most recent call last): File ./scripts/auxiliar/makelsr.py, line 56, in module TAGS = os.listdir (in_dir) OSError: [Errno 2] No such file or directory: '' I cannot see any change to this script recently, Phil made a recent change to avoid explicitly giving the tags, but that change isn't happy with a local makelsr.py update. He may be able to extend this to local files, but I suspect that the easiest fix will be to revert his change and just manually alter the TAGS definition. - Graham I'll fix this later. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
lilypond.patchy.jl...@gmail.com writes: Begin LilyPond compile, commit: f1defa51a982cf769172cfcdd6b2612608ba2746 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: f1defa51a982cf769172cfcdd6b2612608ba2746 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: f1defa51a982cf769172cfcdd6b2612608ba2746 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Both master and staging are fine and at f1defa51a982cf769172cfcdd6b2612608ba2746. I don't know how you managed (disk quota exceeded? unclean shutdown?) but I would think that the problem might be the bad repository I seem to remember you reported. Try git fsck or so. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hideNotes in tablature
Am 15.04.2012 12:06, schrieb Federico Bruni: Il 15/04/2012 11:00, James ha scritto: Federico, it seems you have the ability (and knowledge) to create a tracker yourself so I suggest that if issue 1459 is fixed you change the label to fixed - someone else will verify - and then create a new tracker for the enhancement - whatever it is. Else whoever comes back to the old tracker has to puzzle their way through and often this puts people off (unless you yourself are going to work and create the patch). Yes, issue 1459 is fixed. How can I change the label to fixed in the tracker? The patch itself is very easy and I could create it, but I think that I'd better just create the issue in the tracker. Here it is: http://code.google.com/p/lilypond/issues/detail?id=2480 Hey Federico, if you create a patch, I think you can remove the Stem #'transparent = ##t in the definition of TabVoice in ly/engraver-init.ly, because the stems have now length zero, so this is superfluous (and will be reverted by the first call of \unHideNotes anyway). Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem running makelsr.py
- Original Message - From: James pkx1...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: Phil Holmes em...@philholmes.net; Devel lilypond-devel@gnu.org Sent: Sunday, April 15, 2012 10:29 PM Subject: Re: Problem running makelsr.py Graham, On 15 April 2012 22:24, Graham Percival gra...@percival-music.ca wrote: On Sun, Apr 15, 2012 at 10:18:41PM +0100, James wrote: james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py Traceback (most recent call last): File ./scripts/auxiliar/makelsr.py, line 56, in module TAGS = os.listdir (in_dir) OSError: [Errno 2] No such file or directory: '' I cannot see any change to this script recently, Phil made a recent change to avoid explicitly giving the tags, but that change isn't happy with a local makelsr.py update. He may be able to extend this to local files, but I suspect that the easiest fix will be to revert his change and just manually alter the TAGS definition. Thanks, I thought I was going mad. I haven't done a snippet/new for a while and couldn't recall anything changing. This will hold up Pavel's checkin but there is nothing riding on it, so it can wait. james I've updated this into staging, and this version work on my repo. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
git fetch with Lily-git.tcl
Hello, I was struggling a bit this morning getting my lilydev env to work with patchy, once I had deleted my $LILYPOND_GIT (because git was reporting read errors on a hash). After a bit of head scratching and then realising I hadn't set up the ssh part, I still was struggling to get patchy to even start. It kept complaining abuot the old 'shallow repository' :) gitk and git index only showed the last two commits in both staging and master (which happened to be identical). I kept a few mails that David sent a few months back and he suggested git fetch --depth=100 Which seemed to do the trick, gitk showed everything and patchy worked again - huzzah! Now I looked at Lily-git and found the lines where the 'update' button doubles as 'get source' and it has the following --snip-- ... git remote add -t $originHead \ origin git://git.sv.gnu.org/lilypond.git git fetch git reset --hard origin/$originHead ... --snip-- I wondered if we should inspite (or because of?) Lily-git being aimed beginner devs that adding the extra --depth command? or would that be harmful? It seems Patchy needs it (or did in my case) if you jump right in and follow the CG and then try to get patchy running. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git fetch with Lily-git.tcl
On Mon, Apr 16, 2012 at 09:01:15PM +0100, James wrote: I kept a few mails that David sent a few months back and he suggested git fetch --depth=100 David was wrong. [correction: or rather, David was answering the question you asked, not the question you should have been asking] In that case, you should have deleted your git repository and done a fresh git clone. It's simply not worth trying to play games with git unless you know what you're doing (or unless you'd rather play games with git tutorials rather than working on lilypond, which is perfectly fair!). --snip-- git remote add -t $originHead \ origin git://git.sv.gnu.org/lilypond.git git fetch git reset --hard origin/$originHead --snip-- I hope this does exactly the same thing as git clone git://git.sv.gnu.org/lilypond.git if not, we should fix it. I wondered if we should inspite (or because of?) Lily-git being aimed beginner devs that adding the extra --depth command? or would that be harmful? There should be no --depth command. lily-git.tcl should get all the history, for all branches. I'm not certain if it actually does this or not, but that's the plan. A long time ago, I asked for a different setup (only one branch, only a little bit of history), and people humored me. The evidence from the past few years shows that this was a mistake; it's simply not worth trying to play games with git unless you know what you're doing. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hideNotes in tablature
Il 16/04/2012 12:24, Marc Hohl ha scritto: if you create a patch, I think you can remove the Stem #'transparent = ##t in the definition of TabVoice in ly/engraver-init.ly, because the stems have now length zero, so this is superfluous (and will be reverted by the first call of \unHideNotes anyway). Mmmmh, in that file I can read that stems in TabVoice are made as short as possible, but they are still there: %% make the Stems as short as possible to minimize their influence %% on the slur::calc-control-points routine \override Stem #'no-stem-extend = ##t \override Flag #'style = #'no-flag \override Stem #'details = #'((lengths 0 0 0 0 0 0) (beamed-lengths 0 0 0) (beamed-minimum-free-lengths 0 0 0) (beamed-extreme-minimum-free-lengths 0 0) (stem-shorten 0 0)) %% after all, the stubs of the stems may still be visible, so ... \override Stem #'stencil = ##f I found just the override above (can't find Stem #'transparent = ##t). If I comment it, stems are displayed in TabStaff. BTW, there's no more need to override the whiteout property, right? I can see that hideNotes hide the whiteout even if no specific override is included. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hideNotes in tablature
Am 16.04.2012 23:25, schrieb Federico Bruni: Il 16/04/2012 12:24, Marc Hohl ha scritto: if you create a patch, I think you can remove the Stem #'transparent = ##t in the definition of TabVoice in ly/engraver-init.ly, because the stems have now length zero, so this is superfluous (and will be reverted by the first call of \unHideNotes anyway). Mmmmh, in that file I can read that stems in TabVoice are made as short as possible, but they are still there: %% make the Stems as short as possible to minimize their influence %% on the slur::calc-control-points routine \override Stem #'no-stem-extend = ##t \override Flag #'style = #'no-flag \override Stem #'details = #'((lengths 0 0 0 0 0 0) (beamed-lengths 0 0 0) (beamed-minimum-free-lengths 0 0 0) (beamed-extreme-minimum-free-lengths 0 0) (stem-shorten 0 0)) %% after all, the stubs of the stems may still be visible, so ... \override Stem #'stencil = ##f I found just the override above (can't find Stem #'transparent = ##t). If I comment it, stems are displayed in TabStaff. Oh, sorry, you are right - I stay corrected. BTW, there's no more need to override the whiteout property, right? I can see that hideNotes hide the whiteout even if no specific override is included. That's right, when a grob is set transparent, the whiteout is removed automatically. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
