On Sun, Jul 03, 2011 at 03:45:09PM -0600, Colin Campbell wrote:
Given the above, perhaps it would be wise to defer any formal Patch
Meister role until we have decided how (and if) patches are to be
recorded. I can carry on with keeping an eye on the tracker, but
anything else would require
k-ohara5...@oco.net wrote Monday, July 04, 2011 4:33 AM
I really, really, wish Astyle had a fully gnu-compliant mode out of
the
box.
I went through the regexp's again and think this is good to go.
I agree. This is a big improvement, and would
give us control over the layout style
Reviewers: ,
Message:
Passes regtests - should be good to go!
Thanks to Neil Han-Wen for the help.
Cheers,
MS
Description:
Fixes multiple line glissandos the right way.
Please review this at http://codereview.appspot.com/4631086/
Affected files:
M lily/line-spanner.cc
M
Trevor Daniels writes:
I agree. This is a big improvement, and would
give us control over the layout style ourselves
(rather than what emacs does).
While the work being done here is possibly a good thing, let me remind
you once more that we are a GNU project and thus use the GNU standards
On Mon, Jul 04, 2011 at 11:28:19AM +0200, Jan Nieuwenhuizen wrote:
While the work being done here is possibly a good thing, let me remind
you once more that we are a GNU project and thus use the GNU standards
and thus we need no control over, we need not decide about, we need not
discuss
On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote:
Remarks from the CG:
Patch review tool: Reitveld is inconvenient in some respects: it
requires a google account, and there’s no way to see all patches
relating to lilypond. Should we switch to something like
gerritt?
Hello,
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Jonathan Kulp
)Sent: 03 July 2011 16:35
)To: Graham Percival
)Cc: lilypond-devel@gnu.org
)Subject: Re: compiling
Am Montag 04 Juli 2011, 11:28:19 schrieb Jan Nieuwenhuizen:
The GNU standards are implemented by Emacs, and if it makes an error,
then that's a serious bug that should be reported (to emacs). It seems
to me that someone is spending a lot of effort `just' to accomodate
people who haven't found
Reviewers: J_lowe,
Message:
On 2011/07/04 00:18:07, J_lowe wrote:
Hello, I get an error when I try to make:
That's fixed now.
Cheers,
Reinhold
Description:
Fix issue 75: Allow multiple concurrent slurs
Rewrite the Slur_engraver and the Phrasing_slur_engraver to support
multiple concurrent
Reviewers: ,
Message:
Fixes issue 1734.
Description:
Adds a warning for non-list fingeringOrientations settings.
Please review this at http://codereview.appspot.com/4650070/
Affected files:
M lily/new-fingering-engraver.cc
Index: lily/new-fingering-engraver.cc
diff --git
reinhold.kainho...@gmail.com writes:
Description:
Fix issue 75: Allow multiple concurrent slurs
Rewrite the Slur_engraver and the Phrasing_slur_engraver to support
multiple concurrent slurs. The default lilypond syntax using parentheses
still supports only one slur at a time, but by adding
On Mon, Jul 4, 2011 at 4:58 AM, James Lowe james.l...@datacore.com wrote:
)I'm running Linux Mint Debian Edition, which is based on Debian Testing
)branch. Not sure what consequences that might have for this situation. I
)just run apt-get build-dep lilypond when setting up build env. I also
On 11-07-04 03:54 AM, Graham Percival wrote:
On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote:
Remarks from the CG:
Patch review tool: Reitveld is inconvenient in some respects: it
requires a google account, and there’s no way to see all patches
relating to lilypond.
On 2011/07/04 12:38:06, MikeSol wrote:
Fixes issue 1734.
On 2011/07/04 12:38:06, MikeSol wrote:
Fixes issue 1734.
I think this covers up the real problem: context settings in a \layout
block have no type check.
Your addition simply duplicates Guile's error message for
fingeringOrientations
On Jul 4, 2011, at 2:47 PM, n.putt...@gmail.com wrote:
On 2011/07/04 12:38:06, MikeSol wrote:
Fixes issue 1734.
On 2011/07/04 12:38:06, MikeSol wrote:
Fixes issue 1734.
I think this covers up the real problem: context settings in a \layout
block have no type check.
I didn't realize
On 4 July 2011 13:53, m...@apollinemike.com m...@apollinemike.com wrote:
I didn't realize this was the real issue :)
Any tips as to how one would go about fixing this? Anything that happens
before engravers kick in (dispatchers, parsers, etc.) remains a mystery to
me...
On 7/4/11 7:14 AM, Neil Puttock n.putt...@gmail.com wrote:
On 4 July 2011 13:53, m...@apollinemike.com m...@apollinemike.com wrote:
I didn't realize this was the real issue :)
Any tips as to how one would go about fixing this? Anything that happens
before engravers kick in (dispatchers,
On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote:
Would a redundant check of settings from default context definitions be a
problem? I can't imagine that such a check would take 1% of the processing
time.
I don't know, though I agree is unlikely to be a significant overhead.
Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock:
On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote:
Plus, I don't think it's really a redundant check; I think it's a real
check. Absent such a check, we're trusting on the *-init.ly files being
correct, which admits a
On Jul 4, 2011, at 5:04 PM, Reinhold Kainhofer wrote:
Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock:
On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote:
Plus, I don't think it's really a redundant check; I think it's a real
check. Absent such a check, we're trusting on
- Original Message -
From: percival.music...@gmail.com
To: philehol...@googlemail.com; em...@philholmes.net
Cc: lilypond-devel@gnu.org; re...@codereview.appspotmail.com
Sent: Sunday, July 03, 2011 7:25 PM
Subject: Re: Adds redirect-lilypond-output option to lilypond-book
(issue4664060)
Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM
Trevor Daniels writes:
I agree. This is a big improvement, and would
give us control over the layout style ourselves
(rather than what emacs does).
While the work being done here is possibly a good thing, let me
remind
you once more
On 7/4/11 3:28 AM, Jan Nieuwenhuizen jann...@gnu.org wrote:
Trevor Daniels writes:
I agree. This is a big improvement, and would
give us control over the layout style ourselves
(rather than what emacs does).
While the work being done here is possibly a good thing, let me remind
you
On Mon, Jul 4, 2011 at 7:55 AM, Jonathan Kulp jonlancek...@gmail.com wrote:
However ./autogen.sh and/or ./configure should report any missing/old/wrong
dependencies. So do you get anything back from them (you will probably get
something about a 'recommended' Fontforge version as I do - the
On Mon, 04 Jul 2011 09:32:21 -0700, Trevor Daniels t.dani...@treda.co.uk
wrote:
Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM
It seems
to me that someone is spending a lot of effort `just' to
accommodate
people who haven't found how awesome Emacs is to edit code and
thus introduce
Reviewers: xratamacue_hotmail.com, reinhold_kainhofer.com,
Message:
Passes regtests.
Description:
modifying default behaviour of tremolo slashes
It turned out that tremolo slashes should have
quite constant slope (definately not depending
on beam slope), so i change that. I also changed
slash
Looks mostly good to me.
Thanks,
Carl
http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc
File lily/stem-tremolo.cc (right):
http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc#newcode42
lily/stem-tremolo.cc:42: that it's not proper notation.
We shouldn't keep
Reviewers: Graham Percival, james.lowe_datacore.com,
Message:
In response to
http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00060.html
Description:
an example of minimal example
for some people it's not clear enough how tiny
a tiny example should be. So i used a recently
discussed
As far as I can see, all bugfixes from the 2.15 branch are now backported to
stable/2.14
I plan to ask Graham to release a new version on Saturday, July 9.
There have been only minor documentation changes since 2.14.1, IIUC, but I
would invite the translators to check to see if there is any work
I like this, but I think it should have a little bit more information.
I don't think that the changes in the comments affect whether it is
minimal or not -- perhaps the comments should be the same in both cases.
What we wanted to get rid of is any unnecessary LilyPond input. In
this case that
Hi Janek,
I'm afraid I don't like this at all. While the authorities may be in
agreement that the slashes should be sloped, all the scores I've looked
at follow the same style as LilyPond (which I think reflects a more
traditional hand-engraved style).
It would be preferable to allow users to
LGTM!
Thank you, Carl!
http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf
File mf/feta-flags-generic.mf (right):
http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf#newcode4
mf/feta-flags-generic.mf:4: % Copyright (C) 1997--2011 Han-Wen Nienhuys
We need to be careful about adding stuff to the webpage; perfection is
when there's nothing left to remove, not when there's nothing left to
add.
I'm glad that you're working on it! I'm just warning you that there
will be many nitpicks.
On 2011/07/04 01:54:40, Carl wrote:
Instead of filtering out bad events, I chose to filter in only events
with
ligature interfaces.
That's a lot of internal_has_interface () calls. :) You might as well
create a new interface just for NoteHead (e.g.,
ligature-head-interface).
Cheers,
Neil
On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote:
I plan to ask Graham to release a new version on Saturday, July 9.
May or may not happen. That's the last day of the conference;
I'll probably be in the Venice airport for 2-3 hours, and then
London Heathrow terminal 5 for 14 hours.
On 2011/07/04 13:14:55, Neil Puttock wrote:
Context_def::add_context_mod () is where the assignment takes place
(and you can see from set_property () how the type-checking is done).
Where is set_property defined?
cheers,
Janek
http://codereview.appspot.com/4650070/
On 2011/07/04 20:02:59, Carl wrote:
I like this, but I think it should have a little bit more information.
I don't think that the changes in the comments affect whether it is
minimal or
not -- perhaps the comments should be the same in both cases.
Imo it's more readable when the comment
On 4 July 2011 21:33, lemniskata.bernoull...@gmail.com wrote:
Where is set_property defined?
lily/include/lily-guile-macros.hh
The actual type-checking occurs in Context::internal_set_property ().
Cheers,
Neil
___
lilypond-devel mailing list
On 2011/07/04 09:28:26, janneke_gnu.org wrote:
The GNU standards are implemented by Emacs,
Well, it looks like the problems with fixcc.py were caused by regexps,
not emacs.
Also, I tried to make the output of the modified fixcc+asytle pass
unchanged through emacs, but the very many cases of
On Mon, Jul 04, 2011 at 09:58:14PM +0200, Jan Nieuwenhuizen wrote:
Carl Sorensen writes:
I've tried Emacs, and I can't see the benefits justifying fighting through
the learning curve. It's not comfortable for me; I have 30+ years of
experience with vi(m), so it's hardwired in my bones.
On 7/4/11 2:30 PM, Graham Percival gra...@percival-music.ca wrote:
On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote:
I plan to ask Graham to release a new version on Saturday, July 9.
May or may not happen. That's the last day of the conference;
I'll probably be in the Venice
On 2011/07/04 20:30:10, Neil Puttock wrote:
On 2011/07/04 01:54:40, Carl wrote:
Instead of filtering out bad events, I chose to filter in only
events with
ligature interfaces.
That's a lot of internal_has_interface () calls. :)
I wondered about that. But I think the first one that is
I've almost forgotten: i checked that Carl's patch set passes regtests.
http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450
mf/feta-scripts.mf:1450: begingroup;
On
New patch set uploaded.
2011/7/4 percival.music...@gmail.com:
I'm glad that you're working on it! I'm just warning you that there
will be many nitpicks.
No problem. If they aren't about code style, i can handle them :)
Hello, all --
First of all, I hope that I'm asking this question on the appropriate list!
I'm trying to simplify the workaround relating to tuplet-number
position on kneed beams
http://lsr.dsi.unimi.it/LSR/Snippet?id=646
and I'm running into an unexpected problem.
My reasoning is that, since
On 4 July 2011 21:57, carl.d.soren...@gmail.com wrote:
The original way you suggested was to have two internal_has_interface ()
calls; this one only adds one.
But for the invalid heads, all three calls would be made (and of
course, for a NoteHead itself only the first interface check will
On 2011/07/04 21:01:44, Janek Warchol wrote:
2011/7/4 percival.music...@gmail.com:
this won't compile; it would have to be @example instead, and that
will
require
@{ @} escapes.
Umm.. is it right now?
why the mao are you asking me? Cutpaste this and tell me yourself:
cd build/
http://lilypond.org/~graham/gop/gop_3.html
** Proposal summary
Speaking academically, C++ code style is a solved problem. Let’s
pick one of the existing solutions, and let a computer deal with
this. Humans should not waste their time, energy, and creativity
manually adding tabs or spaces to
LGTM apart from some indentation infelicities (space before tab in
indent).
http://codereview.appspot.com/4631086/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/7/4 percival.music...@gmail.com:
On 2011/07/04 21:01:44, Janek Warchol wrote:
Umm.. is it right now?
why the mao are you asking me? Cutpaste this and tell me yourself:
cd build/
make website
It either compiles, or it doesn't.
Ooops, sorry... I didn't know that it's possible to
On 2011/07/04 12:17:46, Reinhold wrote:
On 2011/07/04 00:18:07, J_lowe wrote:
Hello, I get an error when I try to make:
That's fixed now.
Make succeeds, and reg tests look ok, but there is one note in one of
the .ly files that the reg test threw up that may or may not be
significant.
On 2011/07/04 21:22:58, Neil Puttock wrote:
On 4 July 2011 21:57, mailto:carl.d.soren...@gmail.com wrote:
We already have the unused ligature-interface. nbsp;What if I just
added
ligature-interface to NoteHead?
Sounds fine to me.
OK, so I've added ligature-interface to NoteHead,
On Di., 5. Jul. 2011 00:30:52 CEST, pkx1...@gmail.com wrote:
On 2011/07/04 12:17:46, Reinhold wrote:
On 2011/07/04 00:18:07, J_lowe wrote:
Hello, I get an error when I try to make:
That's fixed now.
Make succeeds, and reg tests look ok, but there is one note in one of
the .ly files
2011/7/4 Carl Sorensen c_soren...@byu.edu:
As far as I can see, all bugfixes from the 2.15 branch are now backported to
stable/2.14
I plan to ask Graham to release a new version on Saturday, July 9.
There have been only minor documentation changes since 2.14.1, IIUC, but I
would invite the
9780d79af0855706354029509cbb11464a63d901 is intended to be backported to
stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not.
On 2011.07.05., at 3:23, Francisco Vila wrote:
2011/7/4 Carl Sorensen c_soren...@byu.edu:
As far as I can see, all bugfixes from the 2.15 branch are now backported
On 7/4/11 7:23 PM, Francisco Vila paconet@gmail.com wrote:
2011/7/4 Carl Sorensen c_soren...@byu.edu:
As far as I can see, all bugfixes from the 2.15 branch are now backported to
stable/2.14
I plan to ask Graham to release a new version on Saturday, July 9.
There have been only minor
On 7/4/11 7:26 PM, Harmath Dénes harmathde...@gmail.com wrote:
9780d79af0855706354029509cbb11464a63d901 is intended to be backported to
stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not.
backported
Thanks,
Carl
___
lilypond-devel mailing
LGTM
Carl
http://codereview.appspot.com/4645077/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Carl
http://codereview.appspot.com/4631086/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Looking at the details of the code, it seems fine.
But I tend to agree with Han-Wen's concerns.
I'm wondering if it's possible to avoid code dup by making a
base_stem_engraver of which glissando_stem_engraver and stem_engraver
would be children.
I probably don't have the right terminology for
LGTM
Carl
http://codereview.appspot.com/4650052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lgtm
I can see how this will work well for defining a whole set.
Carl
http://codereview.appspot.com/4625067/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, with Neil's comments taken
Carl
http://codereview.appspot.com/4654063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Also, I tried to make the output of the modified fixcc+asytle pass
unchanged through emacs, but the very many cases of line-broken
asssignments will be different.
That's a problem.
long_variable_name = first_term
+ second_term; // emacs
This is correct.
Emacs users will forget to
LGTM, but I haven't explored the strange behavior you've identified.
Carl
http://codereview.appspot.com/4630070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
Ok, so you do not object us adopting fixcc-with-astyle as the
official formatter for C++ code?
It seems that this is a huge step forward; just don't change
the definition to `whatever astyle can currently handle';
rather than: fixcc is okay and we're working with the
LGTM, with one comment.
I do wonder if David is right, and we should be using spanner_id instead
of slur_id.
Carl
http://codereview.appspot.com/4643067/diff/3001/lily/slur-engraver.cc
File lily/slur-engraver.cc (right):
67 matches
Mail list logo
