Reviewers: Keith,
Message:
Thanks for the review!
http://codereview.appspot.com/6302097/diff/1/lily/line-spanner.cc
File lily/line-spanner.cc (right):
http://codereview.appspot.com/6302097/diff/1/lily/line-spanner.cc#newcode373
lily/line-spanner.cc:373: me-warning (_ (Line spanner's left
http://codereview.appspot.com/6302097/diff/1/lily/line-spanner.cc
File lily/line-spanner.cc (right):
http://codereview.appspot.com/6302097/diff/1/lily/line-spanner.cc#newcode373
lily/line-spanner.cc:373: me-warning (_ (Line spanner's left point is
to the right of its right point.));
On
Hi David,
... moving this to devel ...
I had a look into tie-column.cc:
In the scheme-callback calc_positioning_done all ties in a chord are
assigned control-points in a loop. So it might be possible to define a
scheme-callback calc_control_point_column, that returns a list of a
list of a
As a followup to
URL:http://code.google.com/p/lilypond/issues/detail?id=2607#c9
I have used \displayLilyMusic (and hand-insertion of whitespace) to
format the programmatic source in a manner where it can be used without
that particular issue.
The output is really nothing to be proud of. There
David Kastrup d...@gnu.org writes:
As a followup to
URL:http://code.google.com/p/lilypond/issues/detail?id=2607#c9
I have used \displayLilyMusic (and hand-insertion of whitespace) to
format the programmatic source in a manner where it can be used without
that particular issue.
Sorry,
Hi Janek,
there has been discussion on your patch.
I see your point, that you want to discriminate graphical, logical and
perhaps some other extents. I also agree with Keith, that we shouldn't
fill our RAM with redundant or unused data.
What about an extent-map, where extents can be stored by
- Original Message -
From: Graham Percival gra...@percival-music.ca
To: Phil Holmes m...@philholmes.net
Cc: lilypond-devel@gnu.org
Sent: Wednesday, June 20, 2012 4:51 AM
Subject: Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 03:51:21PM +0100, Phil Holmes wrote:
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: Graham Percival gra...@percival-music.ca
To: Phil Holmes m...@philholmes.net
Cc: lilypond-devel@gnu.org
Sent: Wednesday, June 20, 2012 4:51 AM
Subject: Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19,
http://codereview.appspot.com/6308093/diff/1/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
http://codereview.appspot.com/6308093/diff/1/lily/self-alignment-interface.cc#newcode206
lily/self-alignment-interface.cc:206: grob_alignment = scm_to_double
(scm_cdr
I've been having a think about how LSR snippets and the translations are
managed in our build system. At present, I understand the system works as
follows.
We would start with a downloaded tarball of snippets, and run makelsr.py
using that as an argument. This takes the snippets from the
Hello list,
I decided to split the bar line issue in two parts.
The first step is to move the main routines from c++ to Scheme,
the second step covers the user interface.
Some issues with the patch:
(*) Please have a look at lily/span-bar.cc.
Is Span-bar::center_on_spanned_callback used
2012/6/20 Phil Holmes em...@philholmes.net:
I'd like to propose a pretty radical change to this process. I propose that
/Documentation/snippets/ is a straight copy of a recent LSR tarball. It's
the task of the LSR meister to keep this up to date. We have a new
directory:
On 2012-06-20 05:51, Graham Percival wrote:
do not recommend any non-Free programs
We have a list of non-free ones on the easier editing page - e.g.
Noteworthy and my converter. However, it seems daft to me to remove
these. I would think for the long list we could disclaim with
- Original Message -
From: Francisco Vila paconet@gmail.com
To: Phil Holmes em...@philholmes.net
Good, I like it in principle, but how will be changes being tracked
using SHA IDs?
Currently, translations have a SHA ID which is that of the snippet it
is a translation of. Any change
Hi Francisco,
Il giorno mer, 20/06/2012 alle 12.04 +0200, Francisco Vila ha scritto:
Good, I like it in principle, but how will be changes being tracked
using SHA IDs?
Currently, translations have a SHA ID which is that of the snippet it
is a translation of. Any change to the original
On Wed, Jun 20, 2012 at 10:26 AM, David Kastrup d...@gnu.org wrote:
The output is really nothing to be proud of. There are several issue
likely relevant for it, like
URL:http://code.google.com/p/lilypond/issues/detail?id=1126 or
URL:http://code.google.com/p/lilypond/issues/detail?id=590, but
Hi Phil,
Il giorno mer, 20/06/2012 alle 10.50 +0100, Phil Holmes ha scritto:
I'd like to propose a pretty radical change to this process. I propose that
/Documentation/snippets/ is a straight copy of a recent LSR tarball. It's
the task of the LSR meister to keep this up to date. We have a
- Original Message -
From: m...@apollinemike.com
To: Phil Holmes em...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
Sent: Wednesday, June 20, 2012 11:38 AM
Subject: Re: LSR updates and translations
On 20 juin 2012, at 12:29, Phil Holmes wrote:
- Original Message - From:
Original Message -
From: Graham Percival gra...@percival-music.ca
To: Federico Bruni fedel...@gmail.com
Currently, makelsr.py adds different amounts of blank lines to
some .ly files depending on whether you run it as a full import
vs. when you run it locally. It would be nice if that
Hi,
After rereading the code i see that you are totally right! I don't know
why i wanted to use dim_cache so much. It's scrapped now.
Joe, thanks to your suggestion it is now possible to read extent from
any property, including user-defined ones!
many thanks,
Janek
2012/6/20 Phil Holmes em...@philholmes.net:
- Original Message - From: Francisco Vila paconet@gmail.com
To: Phil Holmes em...@philholmes.net
Good, I like it in principle, but how will be changes being tracked
using SHA IDs?
Currently, translations have a SHA ID which is that of
On Wed, Jun 20, 2012 at 11:08 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:
Hi Janek,
there has been discussion on your patch.
I see your point, that you want to discriminate graphical, logical and
perhaps some other extents. I also agree with Keith, that we shouldn't fill
our RAM with
Le 20/06/2012 11:50, Phil Holmes disait :
I'd like to propose a pretty radical change to this process. I propose
that /Documentation/snippets/ is a straight copy of a recent LSR
tarball. It's the task of the LSR meister to keep this up to date. We
have a new directory:
2012/6/20 Phil Holmes em...@philholmes.net:
My idea would be that, using the new system, changed snippets would look
exactly like changed documentation files. If I modify, say,
/Documentation/notation/ancient.itely, how do the translators pick up that
this has been changed?
Sorry, this is
LGTM
http://codereview.appspot.com/6310065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Good work - two overall things.
1) In Scheme, try to avoid `do'. Use map and reduce.
2) Have you tested performance hits on large scores? It may be worth it
to leave bar-line.cc as the default and have your script as a Scheme
implementation, not unlike the way we do bezier curves.
Cheers,
MS
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-colon-bar-line grob)
I'm afraid this defun doesn't match the relevant part of current
On 2012/06/20 03:04:21, aleksandr.andreev wrote:
It seems to be used that way throughout the ancient.itely file.
However, if someone can confirm that it's not necessary, I'd be
happy to fix it throughout the file as part of this patch.
fragment is no longer necessary. Please do fix it
Works good for me.
(I was obviously confused earlier about which warning() was being
called.)
http://codereview.appspot.com/6302097/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
29 matches
Mail list logo
