Am 19.10.2010 10:26, schrieb Werner LEMBERG:
I did the faulty varsegno sign. I read the tracker and wanted to
reproduce your observations, but I am unable to run mf2pt1, this
command doesn't seem to exist. How can I obtain it?
It's part of lilypond. Here the relevant lines from my log
e the varsegno in there.
Now my mf knowledge is a bit rusty, so all I can come
up with
is attached in the patch.
Marc
Werner
From 1fa7fdb7d035eea56f406489a09dd496937c6474 Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Tue, 19 Oct 2010 11:44:07 +0200
Subject: [PATCH] Font: rem
Am 19.10.2010 12:06, schrieb Carl Sorensen:
On 10/19/10 3:48 AM, "Marc Hohl" wrote:
Am 19.10.2010 11:14, schrieb Werner LEMBERG:
So the advice
---
The recommended calling sequence of mf2pt1 is
mf2pt1 --rounding=0.0001
You need mf2pt1 version 2.
Am 19.10.2010 21:00, schrieb Carl Sorensen:
On 10/19/10 12:52 PM, "Werner LEMBERG" wrote:
Um, that's what I tried before, but I still got intersections
(which were smaller than before, but still visible in fontforge at
200%), so I had to introduce the tensions.
When I applied an
Am 20.10.2010 09:50, schrieb Werner LEMBERG:
This is probably overkill. FontForge is quite good in doing this for
you, provided the intersections are well defined. `fill' is necessary
because you can't exactly control the direction of the outline by
using `penstroke'.
But if I change f
Am 18.09.2010 22:21, schrieb n.putt...@gmail.com:
[...]
I think the only sane method would be to use a scheme engraver, since
you could acknowledge interesting grobs and make typesetting decisions
for the TabNoteHead based on the grobs present at a particular timestep.
Done.
> This doesn't be
Am 20.10.2010 15:30, schrieb Werner LEMBERG:
The README also says that we shouldn't apply transformations to
fills, but instead transform the path then fill the path. The
current varsegno transforms the penstroke, which I think is contrary
to this instruction.
Yep. For this glyph it
Am 24.10.2010 00:58, schrieb Carl Sorensen:
[...]
varsegno is now fixed, with commit bd4bb4efdb7e3a3e7ff23dbf35a33efb9b296bbc.
Thanks a lot, Carl - I was just about to have a closer look at the
definition of draw_bulb ... I owe you.
Marc
___
li
Am 25.10.2010 23:43, schrieb Richard Fournier:
Dear lilypond developpers,
I am a physicist envolved in research studies dealing with self-organisation
mecanismes and I find myself following a project concerning the statistical
analysis of musical improvisation.
We have the need to transform one
Am 20.10.2010 11:12, schrieb Marc Hohl:
Am 18.09.2010 22:21, schrieb n.putt...@gmail.com:
[...]
I think the only sane method would be to use a scheme engraver, since
you could acknowledge interesting grobs and make typesetting decisions
for the TabNoteHead based on the grobs present at a
Am 27.10.2010 12:14, schrieb Valentin Villenave:
On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohl wrote:
I know, most developers are extremely busy right now.
This particular feature isn't listed on the tracker, but since 2.14 will
provide
a major change concerning the tablature handli
Am 28.10.2010 20:34, schrieb tdanielsmu...@googlemail.com:
I've not reviewed the code but I share Carl's concern about scheme
engravers if there is no way of documenting them in the IR. If the
grobs have any user-servicable properties they must be properly
documented.
Ok, I see the point, but in
Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com:
LGTM.
However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver. Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.
I think you misunderstood the TODO.
Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com:
LGTM.
However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver. Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.
Currently, I view Scheme engravers a
Am 29.10.2010 11:05, schrieb Neil Puttock:
On 28 October 2010 23:55, Carl Sorensen wrote:
Well, as far as I can see, Scheme engravers are really engravers, so they
ought to be documented in the IR along with the C++ engravers, not in an
appendix of the NR along with Scheme functions.
Altho
Am 31.10.2010 00:07, schrieb Neil Puttock:
On 30 October 2010 22:40, Marc Hohl wrote:
File "/home/marc/git/lilypond/python/out/book_snippets.py", line 561, in
compose_ly
if self.global_options.safe_mode:
AttributeError: Values instance has no attribute 'safe_mode&
Am 31.10.2010 23:24, schrieb n.putt...@gmail.com:
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme engraver).
Thank you, Neil, for pointing this out!
I was referring to your engraver example which checked for slurs, too,
and I overlooked the fact that the slu
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to only acknowledge tab-note-head, not note-head.
Makes perfect sense to me.
Thanks for your work!
Marc
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mai
Hello list, hello Valentin (I think you are the master of the tracker),
Federico Bruni raised this issue long ago, see
http://lists.gnu.org/archive/html/lilypond-user/2010-05/msg00355.html
I made some attempts to get this done, but the "almost" solution I
reached didn't satisfy me completely (i
Am 03.11.2010 15:11, schrieb Carl Sorensen:
On 11/3/10 7:03 AM, "Marc Hohl" wrote:
Hello list, hello Valentin (I think you are the master of the tracker),
Federico Bruni raised this issue long ago, see
http://lists.gnu.org/archive/html/lilypond-user/2010-05/msg00355.html
I
Am 03.11.2010 15:10, schrieb Carl Sorensen:
On 11/3/10 6:50 AM, "Marc Hohl" wrote:
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to only acknowledge tab-note-head, not note-head.
Makes perfect sense to me.
Thanks for your work!
You&
Am 03.11.2010 21:22, schrieb Neil Puttock:
On 3 November 2010 19:33, Carl Sorensen wrote:
But the tie callback *should* make the notehead transparent if there's no
slur or gliss (or bend, in the future). In the absence of slur, gliss, or
split tie the notehead is transparent. In the pres
Am 03.11.2010 20:33, schrieb Carl Sorensen:
On 11/3/10 10:15 AM, "Marc Hohl" wrote:
Am 03.11.2010 15:10, schrieb Carl Sorensen:
On 11/3/10 6:50 AM, "Marc Hohl" wrote:
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to
Am 04.11.2010 00:03, schrieb Carl Sorensen:
On 11/3/10 9:34 AM, "Marc Hohl" wrote:
Am 03.11.2010 15:11, schrieb Carl Sorensen:
On 11/3/10 7:03 AM, "Marc Hohl" wrote:
Hello list, hello Valentin (I think you are the master of the tracker),
Federi
Am 07.11.2010 08:47, schrieb carl.d.soren...@gmail.com:
This patch has revised the callbacks in scm/tablature.scm. It appears
to work properly.
The tab-tie-follow-engraver is still using SCM calls to analyze the
grobs. I will get that worked out soon, I hope (although I seem to have
gone backw
Am 07.11.2010 23:51, schrieb Valentin Villenave:
On Thu, Nov 4, 2010 at 9:38 AM, Marc Hohl wrote:
I came up with the idea to parenthesize the Harmonic brackets instead of the
TabNoteHead and thus provide the possibility to left-parenthesize or
right-parenthesize an item, but your approach
Am 08.11.2010 11:59, schrieb Valentin Villenave:
On Mon, Nov 8, 2010 at 9:21 AM, Marc Hohl wrote:
Carl has some good ideas about this issue, but meanwhile, I think
we (you :-) should put it on the tracker, so it doesn't get lost.
There you go!
http://code.google.com/p/lil
Am 12.11.2010 05:07, schrieb carl.d.soren...@gmail.com:
On 2010/11/07 09:21:45, marc wrote:
http://codereview.appspot.com/2723043/diff/57001/scm/define-grob-properties.scm#newcode1021
scm/define-grob-properties.scm:1021: (display-cautionary ,boolean?
"Display in
cautionary form.")
Hey, good
Am 13.11.2010 06:21, schrieb carl.d.soren...@gmail.com:
Thanks for the help on the null pointer. I was thinking that it was
some *other* kind of variable than a Grob, and that I was casting it
wrong.
Got that all taken care of -- no scheme calls at all.
On 2010/11/12 17:40:42, Neil Puttock wro
Am 13.11.2010 15:29, schrieb Carl Sorensen:
On 11/13/10 3:18 AM, "Marc Hohl" wrote:
Am 13.11.2010 06:21, schrieb carl.d.soren...@gmail.com:
I can think of no way to simplify this code further. If you have any
ideas I'd be happy to hear them.
There
Am 13.11.2010 18:29, schrieb Graham Percival:
Guys,
There's been a simply German doc patch waiting for review for a few weeks:
http://code.google.com/p/lilypond/issues/detail?id=1344
http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00329.html
I don't know if the change to the English
Am 15.11.2010 11:08, schrieb Francisco Vila:
2010/11/13 Marc Hohl:
Am 13.11.2010 18:29, schrieb Graham Percival:
Guys,
There's been a simply German doc patch waiting for review for a few weeks:
http://code.google.com/p/lilypond/issues/detail?id=1344
http://lists.gnu.org/archive
Am 15.11.2010 18:27, schrieb Till Paala:
Am 15.11.10 13:23, schrieb Francisco Vila:
2010/11/15 Marc Hohl:
I don't have push privileges, sorry. But as this part of the docs
has been reworked, the english part of the patch wouldn't
apply cleanly.
Moreover, since the changes to the en
Am 16.11.2010 09:18, schrieb Francisco Vila:
2010/11/16 Marc Hohl:
I asked once how to get the lilypond/translation branch on my local
repository, but
nobody could explain; I tried the code described in
http://lilypond.org/doc/v2.13/Documentation/contributor/downloading-remote-branches
Am 16.11.2010 11:52, schrieb Till Paala:
Hi Marc,
I would remember I just had to do "git checkout
origin/lilypond/translation" to obtain the lilypond/translation
branch, so the origin was the critical thing here.
Hm, when I do this, I get:
m...@olivia:~/git/lilypond$ git checkout origin/lily
From a34ec51095cdc2f5e06e847c85fcd86b95ae7b1e Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Tue, 23 Nov 2010 21:18:25 +0100
Subject: [PATCH] tablature: provide custom fret labels
---
scm/tablature.scm | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scm/tablatur
for the fret numbers, so I removed the font stuff.
I attached a patch to remove the unnecessary markup definition.
Regards,
Marc
Cheers,
Neil
From 87fc9dbd0217658c85fa120c8e2aa0afcf3b492a Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Wed, 24 Nov 2010 08:37:07 +0100
Subject: [PATCH] Tablat
Am 27.11.2010 09:22, schrieb Trevor Daniels:
Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM
Neil found a bug in the code. What happens when someone requests an
open string that isn't present
in the tuning?
I've got the code fixed to issue a warning. After
issuing the warning, we
Am 27.11.2010 02:41, schrieb Carl Sorensen:
On 11/24/10 12:40 AM, "Marc Hohl" wrote:
Am 24.11.2010 00:41, schrieb Neil Puttock:
On 23 November 2010 23:30, Carl Sorensen wrote:
Pushed, thanks.
That was quick, thanks!
I'm sorry I&#x
Am 27.11.2010 10:17, schrieb David Kastrup:
carl.d.soren...@gmail.com writes:
Yes, the assumption is that the string specification needs to be in
the same order as the note specification. When the documentation is
done, we'll need to be sure that is mentioned. If you specify the
notes and
Am 27.11.2010 15:27, schrieb Carl Sorensen:
[...]
TabNoteHead supports the text-interface, which has a 'text property. It's
in the Internals reference.
Thanks for clarification - I just saw that you included this in your
recent patch,
in combination with the harmonic/parentheses stuff - gr
Am 27.11.2010 14:36, schrieb Carl Sorensen:
[...]
No, it's not a syntax error, any more than
\time 4/4 c4 c c |
is a syntax error.
I'm fine to throw an error instead of a warning, so that the output will say
the file failed. But it's a music error, not a syntax error.
Thanks for your exam
Am 27.11.2010 21:19, schrieb Carl Sorensen:
On 11/27/10 1:03 PM, "Marc Hohl" wrote:
Am 27.11.2010 14:36, schrieb Carl Sorensen:
[...]
No, it's not a syntax error, any more than
\time 4/4 c4 c c |
is a syntax error.
I'm fine to throw an error instead of a
Am 28.11.2010 05:23, schrieb carl.d.soren...@gmail.com:
Reviewers: marc, p.l.schmidt_gmx.de,
Message:
I've taken Marc's harmonic.ly and moved the scheme functions into
scm/tablature.scm, the music functions into ly/engraver-init.ly, and the
test music into input/regression/tablature-harmonic-fun
Am 27.11.2010 21:12, schrieb Carl Sorensen:
Marc,
Do you have a regtest file that uses the custom fret label?
Now I do ;-)
Thanks,
Marc
>From a34ec51095cdc2f5e06e847c85fcd86b95ae7b1e Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Tue, 23 Nov 2010 21:18:25 +0100
Subject: [PA
e one per stave, which doesn't seem needed? I'll check this
later.
It should be one per unterminated tie.
There should be no unterminated ties at all ;-)
The attached patch fixes this.
Marc
>From bc7b6b77f5b1bdab87a44a8eb1d1084d94208b84 Mon Sep 17 00:00:00 2001
From
Am 05.12.2010 02:19, schrieb carl.d.soren...@gmail.com:
On 2010/12/05 00:58:13, Neil Puttock wrote:
I don't know, but they're consistently shifted to the right unless
there are double-digit notes present.
I wanted your opinion on the spacing in the .png I sent. I adjusted the
offset, but it w
Am 05.12.2010 23:12, schrieb Carl Sorensen:
[...]
Perhaps the left edge of a number should be aligned to the left edge of
a note head
when the fret number is a single digit, whereas fret numbers> 9 should
be centered
according to the center of the left-aligned single digits (I don't know how
Am 07.12.2010 00:56, schrieb Carl Sorensen:
[...]
I'm happy to go with 3/5, as you recommend.
I've added the head-offset property to TabNoteHead 'details, set its default
value to 3/5, and pushed the changes.
Thanks! It's great to see how older lilypond input files are now
compiled and
the
Am 15.12.2010 00:18, schrieb Carl Sorensen:
On 12/14/10 4:15 PM, "Graham Percival" wrote:
I only just realized that I should have done
git add input/regression/*.ly
after apply Neil's patches with patch -p1< foo.diff
Sorry about that.
Well, I don't think that either of Neil's patches in
Hello list,
I tried to add this in the bug tracker, but obviously,
it got lost somewhere...
\version "2.13.44"
noteTrills = \relative c' {
\pitchedTrill c2\startTrillSpan d bes2\stopTrillSpan
}
\score {
<<
\new Staff { \clef "treble_8" \noteTrills }
\new TabStaff { \noteTrills }
>
Hello all,
attached is a small patch to handle Issue 1035.
Instead of giving an error, it raises a warning when negative frets
are calculated in tablature staves or in fret diagrams.
Regards,
Marc
From 4a1a80c4be5426e5b4c34beee19656f85aa52ba9 Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date
Am 22.12.2010 09:48, schrieb Carl Sorensen:
On 12/22/10 1:30 AM, "Marc Hohl" wrote:
Hello all,
attached is a small patch to handle Issue 1035.
Instead of giving an error, it raises a warning when negative frets
are calculated in tablature staves or in fret diagrams.
Marc,
If
Am 22.12.2010 22:02, schrieb Carl Sorensen:
On 12/22/10 4:16 AM, "Marc Hohl" wrote:
Am 22.12.2010 09:48, schrieb Carl Sorensen:
On 12/22/10 1:30 AM, "Marc Hohl" wrote:
Hello all,
attached is a small patch to handle Issue 1035.
Instead of giving an error, it r
Am 24.12.2010 06:39, schrieb Colin Campbell:
On Mon, 2010-12-20 at 11:09 +0100, Marc Hohl wrote:
Hello list,
I tried to add this in the bug tracker, but obviously,
it got lost somewhere...
\version "2.13.44"
noteTrills = \relative c' {
\pitchedTrill c2\startT
Am 23.12.2010 12:38, schrieb Carl Sorensen:
[...]
I can see your point here.
I suspect that our major reason for disagreeing on this is that you are
mostly concerned about tablature, while I'm mostly concerned about fret
diagrams.
Probably. I must confess that I didn't use fret diagrams very oft
Am 29.12.2010 06:18, schrieb k-ohara5...@oco.net:
[...]
The order for the chord entry was requested by the users. Chords are
generally
entered lowest note first.
Yes, but were the users right? I would have asked for that order of
entry, too, but would have changed my mind for fear of bugs
Am 29.12.2010 19:22, schrieb Marc Hohl:
[...]
But for duitar,
I meant "guitar", of course - don't know how a "duitar" is tuned and
played ;-)
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists
Am 23.06.2012 11:11, schrieb Marc Hohl:
Am 23.06.2012 11:06, schrieb Benkő Pál:
hi Marc,
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make
Am 27.06.2012 14:14, schrieb Graham Percival:
On Tue, Jun 26, 2012 at 11:13:21PM +0200, David Kastrup wrote:
Düsseldorf -- Dortmund --> 45 minutes hourly
Sounds good. Ok, I'm in as long as we have at least 3 developers
other than myself. So far there's David and Werner.
Well, I do not count
Am 29.06.2012 08:05, schrieb m...@apollinemike.com:
On 26 juin 2012, at 18:26, David Kastrup wrote:
Graham Percival writes:
Mailing list arguments are a trickier issue. It’s clearly a big
problem, but this isn’t something we can fix by waving a change of
policy. I’ll schedule a time to discu
Hello list,
while still working on Issue 1320, I found out that
the functions defined in lily/span-bar.cc
Span_bar::center_on_spanned_callback
and
Span_bar::get_spanned_interval
are apparently not used since
SHA1 ID 4995fea559cd5399b4f462de546a15195d76f4c3
dated 2001-06-29.
Is it ok to remov
Marc
Original-Nachricht
Betreff: Re: Questions about Issue 1320: Scheme bar line interface
(issue 6305115)
Datum: Wed, 4 Jul 2012 06:48:56 +0200
Von:m...@apollinemike.com
An: Marc Hohl
Hey Mark,
This is because, in this instance, you need to pass the function a
point
Am 04.07.2012 13:29, schrieb David Kastrup:
Marc Hohl writes:
Hello list,
the topic is somewhat over my head, but perhaps someone with more
insight can answer this question?
I think that gcc likely can, don't know about g++, and we don't want to
rely on it anyhow.
Ok.
Well then
Hello Mike,
Am 05.07.2012 00:37, schrieb m...@apollinemike.com:
[...]
I just realized that there's an easier way to do this w/ existing code
conventions. You can overload Pointer_group_interface::find_grob so that it
accepts a simple closure as the third argument. Then, wrap the Scheme funct
Am 05.07.2012 08:14, schrieb Joe Neeman:
On Thu, Jul 5, 2012 at 12:37 AM, m...@apollinemike.com
<mailto:m...@apollinemike.com> <mailto:m...@apollinemike.com>> wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:
> Am 04.07.2012 13:29, schrieb David Kastrup:
>
pollinemike.com
<mailto:m...@apollinemike.com> mailto:m...@apollinemike.com>> wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:
Why not just leave the function in C++? I have nothing against
porting things to scheme, but in this case it just seems like an
exe
Am 06.07.2012 09:51, schrieb David Kastrup:
Joe Neeman writes:
I think it's exercises like that that help strengthen the Scheme
bindings and thus lead to more customizability/extensibility.
In this case, I disagree. The function in question is used in 2 places
in the C++ code, neit
Am 06.07.2012 18:06, schrieb Joe Neeman:
[...]
The semi-trivial C++ function is _not_ useful for the scheme code. It
is used in two parts of the C++ code. However, because it belonged to
the same file as various other functions that were being ported, Marc
was planning to port this semi-trivi
with harm6 and Marc Hohl on this toppic, I had a look to the 'end
hook suppression on the volta brackets based on the barline type'. There I
worked to move the 'list of bar lines' from C++ source code to a staff
context property.
Next I had the idea to suppress the 'repea
Am 16.07.2012 19:31, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #30 on issue 1320 by colinpkc...@gmail.com: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c30
Patchy the
Am 17.07.2012 00:58, schrieb k-ohara5...@oco.net:
Wherever there is an empty bar-line, \bar"" , this patch reserves too
much space for the bar-line. Possibly the extent of empty bar-lines is
computed wrongly.
Obviously, I swapped the x- and y-coordinates within the definition
of make-empty-barl
Hello list,
I tried to follow the instructions on
http://lilypond.org/doc/v2.15/Documentation/contributor/working-with-remote-branches
Since I have now push access and I am supposed to push to staging,
I tried to create a local branch called 'staging' and I did
git config --add remote.origin.fe
Am 17.07.2012 21:48, schrieb m...@hohlart.de:
The regression test
span-par-allow-span-bar.ly
Should read
span-bar-allow-span-bar.ly
;-)
After
make test-redo; make check
I still see some small differences between master and my patch.
I think the differences concerning MIDI output can safel
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
What makes it safe to ignore them?
Well, I don't know.
But diffs like
@@ -1,4 +1,5 @@
Parsing...
+Renaming input to: `out-test/voice-5-midi.
Am 20.07.2012 12:26, schrieb Phil Holmes:
[...]
It might be worth your comparing the differing output by eye - the
regtest checker only gives a rough idea of where the differences lie.
Failing that, I think I could create a windows .exe if the patch was
in an accessible branch on git, and coul
Am 20.07.2012 20:17, schrieb Marc Hohl:
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
Thinko – IIUC, not the MIDI output is changed, only the log file.
Regards,
Marc
http
Am 17.07.2012 17:51, schrieb Keith OHara:
On Mon, 16 Jul 2012 22:42:55 -0700, wrote:
regtest
I'm expanding `alignment-order.ly` after the patchy test.
I think that my current redefinition already includes the sorting
(see lines 578/579 of
http://codereview.appspot.com/6305115/diff/30001/scm
Am 20.07.2012 20:28, schrieb David Kastrup:
Marc Hohl writes:
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
What makes it safe to ignore them?
Well, I don't know.
But diffs
Am 20.07.2012 21:15, schrieb Benkő Pál:
Marc, please don't throw the whole 2533 issue stuff out;
look at the newer version at
http://codereview.appspot.com/6431044
p
Pál, thanks for the hint – I stored the changes I made
before the revert of your patch ;-)
Obviously, I have do rework some det
Am 20.07.2012 23:43, schrieb Keith OHara:
On Fri, 20 Jul 2012 11:38:34 -0700, Marc Hohl wrote:
I think that my current redefinition already includes the sorting
(see lines 578/579 of
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm)
I don't read Scheme, but it does se
Am 20.07.2012 23:16, schrieb k-ohara5...@oco.net:
Works fine for me, but it will need updated to synchronize with the
patches soon-to-be-pushed to the C version.
Ok.
Since the C code is getting bug-fixes and improvements at the same time
as you port to Scheme, you should incorporate the improv
Am 20.07.2012 21:03, schrieb d...@gnu.org:
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm#newcode649
scm/bar-line.scm:649:
Empty line at end of file makes git complain about wh
Am 21.07.2012 15:02, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #35 on issue 1320 by d...@gnu.org: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c35
Patchy the autobot
Am 23.07.2012 10:30, schrieb Marc Hohl:
[...]
The x-extent of all bar lines is identical except for the dashed
bar line (the newer version is centered around x=0, but the width is
identical),
so IIUC, rounding errors may not a problem here.
Corrected in the latest patch set.
Interestingly
Am 23.07.2012 23:45, schrieb k-ohara5...@oco.net:
Looks like LilyPond defines two line-thicknesses,
one for staff-line thickness in each StaffSymbol,
and one (confusingly called staffline in C) for bar-line width in
paper.scm.
Thanks for your explanation! Indeed, staffline is not the
best variab
Am 24.07.2012 13:53, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-review
Comment #40 on issue 1320 by d...@gnu.org: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c40
Patchy the autobot says
Am 26.07.2012 09:51, schrieb benko@gmail.com:
Marc, please don't throw the whole 2533 issue stuff out; look at the
latest version at
http://codereview.appspot.com/6431044
in particular bar-line.cc and repeat-sign.ly.
I really don't mind if your patch goes before mine (it would even be
better
Am 26.07.2012 10:31, schrieb Keith OHara:
On Thu, 26 Jul 2012 00:51:56 -0700, wrote:
Marc, please don't throw the whole 2533 issue stuff out; look at the
latest version at
http://codereview.appspot.com/6431044
in particular bar-line.cc and repeat-sign.ly.
I really don't mind if your patch goe
Hi list,
this is the time for my first patch to be pushed by myself ;-)
... and it doesn't work.
I followed the instructions at
http://lilypond.org/doc/v2.15/Documentation/contributor/git-for-the-impatient
My work is on barlineI, so I did
(on master)
git pull
git checkout barlineI
git rebase
Am 27.07.2012 08:45, schrieb David Kastrup:
Marc Hohl writes:
this is the time for my first patch to be pushed by myself ;-)
... and it doesn't work.
I followed the instructions at
http://lilypond.org/doc/v2.15/Documentation/contributor/git-for-the-impatient
My work is on barlineI, so
Am 27.07.2012 09:01, schrieb David Kastrup:
Marc Hohl writes:
[remote "origin"]
url = git://git.sv.gnu.org/lilypond.git/
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/staging:refs/remotes/origin/staging
So I think I am not using http, rig
Am 27.07.2012 09:16, schrieb Trevor Daniels:
Marc Hohl wrote Friday, July 27, 2012 8:11 AM
I must admit that I am not very familiarwith the whole ssh stuff – is
there anything I can do
to make it work? The git instructions on
http://lilypond.org/doc/v2.15/Documentation/contributor
don't
Am 27.07.2012 11:07, schrieb Phil Holmes:
- Original Message - From: "Marc Hohl"
To: "Trevor Daniels"
Cc: "David Kastrup" ;
Sent: Friday, July 27, 2012 8:28 AM
Subject: Re: git push doesn't work
I have saved my public key on savannah, and the inst
Am 27.07.2012 12:28, schrieb David Kastrup:
Marc Hohl writes:
After Trevor's mail, I found out that I already *had*
.ssh/config|id_rsa|id_rsa.pub etc.
due to some ssh connections to other servers a friend of mine created for me
(I was sitting next to him, but apparently he can type com
Am 27.07.2012 12:35, schrieb David Kastrup:
David Kastrup writes:
Try calling
ssh -v -v @git.sv.gnu.org/srv/git/lilypond
This won't ever get you in (because you are not allowed to execute a
normal shell), but it should fail in more informative ways.
Oops. Of course just
ssh -v -v @git.sv.
Am 27.07.2012 21:14, schrieb Trevor Daniels:
Marc
If git push is still not working one thing to check is how you copied your
public key to Savannah. It must contain no embedded newlines, so you need to
display it using a program that doesn't word-wrap.
If that's not the problem try generatin
Am 28.07.2012 15:27, schrieb David Kastrup:
"Phil Holmes" writes:
Ok, I'll be backing this out. If someone with horsepower can produce a
relevant log file for the problem (possibly the one listed above is
still around which might be a good start), this would likely be quite
helpful.
--
David
Am 28.07.2012 19:43, schrieb Marc Hohl:
Am 28.07.2012 15:27, schrieb David Kastrup:
"Phil Holmes" writes:
Ok, I'll be backing this out. If someone with horsepower can
produce a
relevant log file for the problem (possibly the one listed above is
still around which might
Am 29.07.2012 08:12, schrieb David Kastrup:
"Phil Holmes" writes:
Sorry, Marc. To do this completely, you will need to add the changed
file to snippets/new. The files in snippets get over-written when we
import from the LSR, so this update would be lost. However, to make
current git compile
201 - 300 of 651 matches
Mail list logo
