Hi all,
As mentioned in the title, git-cl's repository on neugierig.org is down.
It looks like this project isn't supported anymore.
I suggest we rewrite the last part of CG 3.3.4 Uploading a patch for
review.
In fact, why were we using git-cl ? What is git-cl providing that can't be
done with
We've decided on python formatting and C++ formatting; the most
important part for me was no tabs for indentation. Why not
implement this policy in all source files?
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
passes make, but some reg tests are different. Trillspanner ones (trill
is shorter than before). And he 'Black box' test is showing up,
see: http://code.google.com/p/lilypond/issues/detail?id=1766#c2
for screenshots.
http://codereview.appspot.com/4747045/
Passes Make tests - I still get:
--snip--
@ -1,8 +1,6 @@
Parsing...
Renaming input to:
`/home/jlowe/lilypond-git/input/regression/midi-volume-equaliser.ly'
Interpreting music...
-warning: MIDI channel wrapped around
-warning: remapping modulo 16
MIDI output to
On Jul 16, 2011, at 3:39 AM, hanw...@gmail.com wrote:
http://codereview.appspot.com/4747045/diff/2001/lily/grob.cc
File lily/grob.cc (right):
http://codereview.appspot.com/4747045/diff/2001/lily/grob.cc#newcode528
lily/grob.cc:528: Grob::in_own_family_tree (Grob *g, Grob *orig)
I think
On Sat, Jul 16, 2011 at 10:56:28AM +0200, Bertrand Bordage wrote:
In fact, why were we using git-cl ? What is git-cl providing that can't be
done
with upload.py from Rietveld codereview ?
I'm not certain that upload.py allowed us to use git patches in
the past; I definitely did not think that
Reviewers: ,
Message:
On Jul 1, 2011, at 5:50 PM, Han-Wen Nienhuys wrote:
On Thu, Jun 30, 2011 at 12:46 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
can you show png examples of what you're trying to do?
Honestly, I cannot allow this patch in its current design. I don't see
a
On Sa., 16. Jul. 2011 17:42:36 CEST, Graham Percival gra...@percival-music.ca
wrote:
On Sat, Jul 16, 2011 at 10:56:28AM +0200, Bertrand Bordage wrote:
In fact, why were we using git-cl ? What is git-cl providing that
can't be done with upload.py from Rietveld codereview ?
git-cl stored the
On Jul 1, 2011, at 5:50 PM, Han-Wen Nienhuys wrote:
On a tangent: what is the glissando-index property for? I can't see
it being read anywhere.
\relative c' {
\override Glissando #'style = #(lambda (grob) (if (eq? (ly:grob-property grob
'glissando-index) 1) 'zigzag 'dashed-line))
c e
On Jul 1, 2011, at 5:50 PM, Han-Wen Nienhuys wrote:
On a tangent: what is the glissando-index property for? I can't see
it being read anywhere.
\relative c' {
\override Glissando #'style = #(lambda (grob) (if (eq? (ly:grob-property grob
'glissando-index) 1) 'zigzag 'dashed-line))
c e
Would it be possible to make upload.py sent multiple commits? For
casual contributors, a single commit is fine, but serious
developers like Mike require the ability to upload multiple
commits for a single issue.
Yes, this will be possible.
Do you mean something like this ?
git-cl stored the issue number inside each git branch, so that you can
easily update an issue with a new pathcset without having to look up the
issue number.
Hum, this is true.
Plus, you don't have to create a patch file on disk that you can then
upload. So, git-cl is basically only half
On Sat, 16 Jul 2011 08:11:02 -0700, pkx1...@gmail.com wrote:
Passes Make tests - I still get:
--snip--
Interpreting music...
-warning: MIDI channel wrapped around
-warning: remapping modulo 16
MIDI output to
The test output shows the change from the old behavior. Lines with '-' in
On Sat, Jul 16, 2011 at 03:23:34PM +0200, Janek Warchoł wrote:
We've decided on python formatting and C++ formatting; the most
important part for me was no tabs for indentation. Why not
implement this policy in all source files?
We have not yet decided on C++ formatting. The proposal will
On Fri, Jul 15, 2011 at 05:20:02PM +0100, Phil Holmes wrote:
- Original Message - From: Graham Percival
gra...@percival-music.ca
On Fri, Jul 15, 2011 at 02:20:51PM +0100, Phil Holmes wrote:
I'm not certain if it's possible to cause make(1) to automatically
put its output into a
2011/7/16 Bertrand Bordage bordage.bertr...@gmail.com:
Hi all,
As mentioned in the title, git-cl's repository on neugierig.org is down.
It looks like this project isn't supported anymore.
I suggest we rewrite the last part of CG 3.3.4 Uploading a patch for
review.
In fact, why were we using
New patch set uploaded.
\override Staff.Clef #'style = #'old tells Lily to use previous clef
glyph instead of my new clef.
(dedicated to James)
http://codereview.appspot.com/4664070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
2011/7/16 Han-Wen Nienhuys hanw...@gmail.com:
2011/7/15 Janek Warchoł lemniskata.bernoull...@gmail.com:
Surprisingly, CueClef currently uses regular clef glyph scaled down
1.5874 times (font-size -4), not a scaled down change clef. Maybe we
Almost; IIRC the -4 will end up in another font, so
I would like to rewrite the CG, but first I would like somebody
(not me) to change upload.py
- ideally the changes should be sent upstream
- I'm willing to have a temporary fork of upload.py while we're
waiting for a new official version of upload.py
I finally made a good patch
could you do a git pull, and then make a new commit for this? I've run
makelsr.py locally.
http://codereview.appspot.com/4751045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
\override Staff.Clef #'style = #'old tells Lily to use previous
clef
glyph instead of my new clef.
(dedicated to James)
This is exactly the thin edge of the \override glyph
wedge I was worried about earlier :( We already have
too many overrides. If the majority want to change
the clef
Reviewers: Graham Percival,
Message:
On 2011/07/16 20:41:43, Graham Percival wrote:
could you do a git pull, and then make a new commit for this? I've
run
makelsr.py locally.
Done. Second draft attached. Thanks.
Description:
Doc: NR Added new Node for Footnotes
This is for Trackr issue
On Sat, Jul 16, 2011 at 09:42:10PM +0200, Bertrand Bordage wrote:
I finally made a good patch (bug-free), but we need to update codereview's
server.
The temporary fork option can't work.
hmm, that makes things more complicated.
Fortunately, Google code now supports git, so this could be an
2011/7/16 Trevor Daniels t.dani...@treda.co.uk:
\override Staff.Clef #'style = #'old tells Lily to use previous clef
glyph instead of my new clef.
(dedicated to James)
This is exactly the thin edge of the \override glyph
wedge I was worried about earlier :( We already have
too many
you need to do
git add Documentation/snippets/new/*.ly
git commit Documentation/snippets/new/
to get your new files included in this commit.
http://codereview.appspot.com/4751045/diff/2001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
On 2011/07/16 21:06:34, Graham Percival wrote:
you need to do
git add Documentation/snippets/new/*.ly
git commit Documentation/snippets/new/
to get your new files included in this commit.
no wait, sorry, ignore that. My eyes (and the sorting order in
rietveld) mislead me.
On Sa., 16. Jul. 2011 21:05:37 CEST, Janek Warchoł
lemniskata.bernoull...@gmail.com wrote:
2011/7/16 Han-Wen Nienhuys hanw...@gmail.com:
2011/7/15 Janek Warchoł lemniskata.bernoull...@gmail.com:
Surprisingly, CueClef currently uses regular clef glyph scaled down
1.5874 times (font-size
On 7/16/11 10:38 AM, Bertrand Bordage bordage.bertr...@gmail.com wrote:
Would it be possible to make upload.py sent multiple commits? For
casual contributors, a single commit is fine, but serious
developers like Mike require the ability to upload multiple
commits for a single issue.
Yes,
On Sat, Jul 16, 2011 at 08:34:56PM +0200, Jan Warchoł wrote:
2011/7/16 Bertrand Bordage bordage.bertr...@gmail.com:
Furthermore, there's something we should solve : upload.py is just uploading
diffs instead of full git commit patches.
By changing a line on upload.py, we can easily change
On Sat, Jul 16, 2011 at 04:53:15PM -0600, Carl Sorensen wrote:
Why are we trying to eliminate git-cl? What is the problem it causes?
git-cl isn't the problem.
The problem is that when I click on download raw patch set on a
codereview issue, I get a raw patch set. This loses the commit
message
On 7/16/11 5:00 PM, Graham Percival gra...@percival-music.ca wrote:
On Sat, Jul 16, 2011 at 04:53:15PM -0600, Carl Sorensen wrote:
Why are we trying to eliminate git-cl? What is the problem it causes?
git-cl isn't the problem.
The problem is that when I click on download raw patch set
On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote:
IMO, we should be aiming at one commit per Rietveld issue, rather than a
series of commits per Rietveld issue.
That's beside the point, at least as far as I understand it.
- Bertrand writes some code.
- Bertrand makes a git
Third Draft
http://codereview.appspot.com/4751045/diff/2001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4751045/diff/2001/Documentation/notation/input.itely#newcode1016
Documentation/notation/input.itely:1016: @funindex
On 7/16/11 5:37 PM, Graham Percival gra...@percival-music.ca wrote:
On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote:
IMO, we should be aiming at one commit per Rietveld issue, rather than a
series of commits per Rietveld issue.
That's beside the point, at least as far as I
On 7/16/11 4:55 PM, Graham Percival gra...@percival-music.ca wrote:
On Sat, Jul 16, 2011 at 08:34:56PM +0200, Jan Warchoł wrote:
2011/7/16 Bertrand Bordage bordage.bertr...@gmail.com:
Furthermore, there's something we should solve : upload.py is just uploading
diffs instead of full git
Graham Percival graham at percival-music.ca writes:
NB: if anybody wants to start looking at various command-line
scheme indenters (whether that's extracting the elisp
scheme-indent and making it work with guile,
Ooh, that would be very nice if it is possible !
Standalone programs that did
36 matches
Mail list logo
