Reviewers: Keith,
Message:
On 2012/09/01 23:58:37, Keith wrote:
I might have a test case for you at
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1776
It seems you copy each slur into a slur-stub, and from those keep
only the
ones with cross-staff set. Then when figuring system
David Kastrup writes:
Using LilyPond for reading LilyPond files (as opposed to parsers written
in Python) has the advantage of being rather thorough, and the
disadvantage to be tied into a single version (not all that helpful if
you want to write something like convert-ly).
Maybe the time
Han-Wen Nienhuys writes:
I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters.
If we start doing this, that would solve the several of the issues
raised. It
- Original Message -
From: Federico Bruni fedel...@gmail.com
To: Lily-Devel List lilypond-devel@gnu.org
Sent: Saturday, September 01, 2012 4:40 PM
Subject: slides-in-tablature.ly snippets: string numbers of hided notes
arevisible
I've just realized that in this snippet the hidden
Il 02/09/2012 12:13, Phil Holmes ha scritto:
Well - I've done that, but it appears that the snippet actually only
works properly on 2.16. Using the LSR and on my own machine with 2.14 I
get no numerals over the normal staff, and little zeros on the
tabstaff. If you know how to fix that, please
Reviewers: Graham Percival,
Description:
I've checked Google and it is now indexing the 2.17 pages and returning
hundreds of results - so we should update the search boxes. There's no
issue tracker for this because my finger slipped when entering my google
credentials.
Please review this at
Jan Nieuwenhuizen jann...@gnu.org writes:
Han-Wen Nienhuys writes:
I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters.
If we start doing this, that would
Jan Nieuwenhuizen jann...@gnu.org writes:
David Kastrup writes:
Using LilyPond for reading LilyPond files (as opposed to parsers written
in Python) has the advantage of being rather thorough, and the
disadvantage to be tied into a single version (not all that helpful if
you want to write
David Kastrup writes:
What issues were raised?
Janek and Graham raised the `what is a music function / let's make
everything postfix' issue. Han-Wen raised the issue of [nameless]
optional arguments.
instead of
\relative { a \parenthesize b c }
we could have something* like
David Kastrup writes:
Maybe the time has finally come to drop convert-ly and implement and
fully supported conversions using LilyPond on music stream level.
You still need a parser of the appropriate version at the front end.
We have perfectly fine ly parsers of each available version
All in all, a large step backwards for making the lexer behave
predictably across modes regarding word and command syntax, connected
with several timing problems when parsing.
It looks like some _severe_ doctoring around with regard to notenames
was done to make regtests pass without an actual
Jan Nieuwenhuizen jann...@gnu.org writes:
David Kastrup writes:
Maybe the time has finally come to drop convert-ly and implement and
fully supported conversions using LilyPond on music stream level.
You still need a parser of the appropriate version at the front end.
We have perfectly
Jan Nieuwenhuizen jann...@gnu.org writes:
David Kastrup writes:
What issues were raised?
Janek and Graham raised the `what is a music function / let's make
everything postfix' issue.
That's rather vague as an issue description. Sort of the What is a
preposition / let's make everything a
Reviewers: John Mandereau,
Message:
Please check.
Description:
I've tested this with a full make, make doc, make test and diffed the
files created with make doc - all is exactly the same. Think this
should be good to go, but just want confirmation.
Please review this at
John,
I'm still finding my way round the new layout/organization of where
Patchy puts the output and test results, however it is not clear
sometimes what is failing, while I can just run reject patchy and say
'where' in the cycle it fails (make, make test etc.). It does help the
devs if I can be
- Original Message -
From: James pkx1...@gmail.com
To: John Mandereau john.mander...@gmail.com
Cc: Devel lilypond-devel@gnu.org
Sent: Sunday, September 02, 2012 3:31 PM
Subject: Trying to work out at what point patchy fails during make test
John,
I'm still finding my way round the
On Sun, Sep 2, 2012 at 5:04 AM, Jan Nieuwenhuizen jann...@gnu.org wrote:
Janek Warchoł writes:
thanks! Is there any explanation to these numbers other than digging
it myself from beam-quanting.cc? I've skimmed over it, but didn't
find it immediately helpful.
I've compiled with
http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode390
lily/axis-group-interface.cc:390: /*
Where is the point in putting a whole callback inside
http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213
lily/self-alignment-interface.cc:213: vector_sort (vais, lessint ());
Seriously?
On Sat, Sep 01, 2012 at 10:58:31PM +0200, Nicolas Sceaux wrote:
Le 1 sept. 2012 à 18:25, Graham Percival a écrit :
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
If a prefix music function is consistently
On Sun, Sep 02, 2012 at 12:58:47AM +0200, Janek Warchoł wrote:
For what it's worth, i'm ok with this discussion (and similar ones)
happening on devel, as long as we won't loose track of concrete
proposals (when they will appear, ofc.).
I think the direction we're moving in is to have
Thanks for the review!
http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode419
lily/axis-group-interface.cc:419: */
On 2012/09/02 15:59:00, dak
Reviewers: dak,
Message:
Thanks for the review!
http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213
http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc
File lily/phrasing-slur-engraver.cc (right):
http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode119
lily/phrasing-slur-engraver.cc:119: if (slur_stubs_.find (slurs_[j]) ==
Reviewers: dak,
http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly
File input/regression/page-spacing-nonstaff-lines-independent.ly (left):
On 2012/09/02 11:52:46, dak wrote:
It looks like some _severe_ doctoring around with regard to notenames
was done
to make regtests pass without an actual understanding of the failure
modes,
introducing some half-baked in-between modes that don't have a purpose
apart
from papering over the
LGTM
http://codereview.appspot.com/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
All in all, this creates so many loose ends and problems of the kind I
have been working to get tied up that I can basically start from scratch
with lexer/parser work. I am very strongly opposed to this, and it is
easy to come up with examples that fail for inexplicable reasons because
of the
Janek Warchoł janek.lilypond at gmail.com writes:
On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup dak at gnu.org wrote:
Graham Percival graham at percival-music.ca writes:
So far I don't feel that the discussion has been very fruitful.
And it will not be fruitful in the near future. One
Keith OHara k-ohara5...@oco.net writes:
Janek Warchoł janek.lilypond at gmail.com writes:
On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup dak at gnu.org wrote:
Graham Percival graham at percival-music.ca writes:
So far I don't feel that the discussion has been very fruitful.
And it will
Graham Percival graham at percival-music.ca writes:
Let's have a look at verbifying music functions.
[and special-cases that look just like music functions to the user]
Most pre-fix functions do seem to be verbs expressing what we want LilyPond
to do to the following music. The exceptions
Keith OHara k-ohara5...@oco.net writes:
Graham Percival graham at percival-music.ca writes:
Let's have a look at verbifying music functions.
[and special-cases that look just like music functions to the user]
Most pre-fix functions do seem to be verbs expressing what we want LilyPond
to do
More nit-picking:
http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py
File python/convertrules.py (right):
http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py#newcode3395
python/convertrules.py:3395: @rule ((2, 17, 2), rNew bar line
interface)
There's no
On 2012/09/02 06:25:58, MikeSol wrote:
It's not a copy of the original slur because it is using
pure heights and offsets.
I saw you interrogating SlurStub regarding its purity, but did not
notice that SlurStub took any different shape based on 'pure' estimates.
The SlurStubs in the regtest
Hi John,
i remember that you are investigating whether we could be using Gerrit
for Lily work. I may've asked this question already, but i don't
remember whether there was a definitive answer: does gerrit have a web
interface that allows to create new commits using only a web browser?
I've
For 20:00 MST Tuesday September 4
Critical:
Issue 2783
http://code.google.com/p/lilypond/issues/detail?id=2783: wrong
placement of timesignature - R 6494071
http://codereview.appspot.com/6494071/
Issue 1290
http://code.google.com/p/lilypond/issues/detail?id=1290: Skyline
compaction
LGTM
http://codereview.appspot.com/6458159/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
gra...@percival-music.ca wrote:
The meta-target is after spending 5 years very publicly telling
people *not* to talk about changing the syntax because we would do
so 'in a year or two', I think I should encourage such
discussions.. I mean,
On 2012/09/02 20:38:28, Keith wrote:
On 2012/09/02 06:25:58, MikeSol wrote:
It's not a copy of the original slur because it is using
pure heights and offsets.
I saw you interrogating SlurStub regarding its purity, but did not
notice that
SlurStub took any different shape based on
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
gra...@percival-music.ca wrote:
The meta-target is after spending 5 years very publicly telling
people *not* to talk about changing the syntax because we would do so
'in a year or two', I think I
On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen jann...@gnu.org wrote:
David Kastrup writes:
Maybe the time has finally come to drop convert-ly and implement and
fully supported conversions using LilyPond on music stream level.
You still need a parser of the appropriate version at the
Janek Warchoł janek.lilyp...@gmail.com writes:
Hi John,
i remember that you are investigating whether we could be using Gerrit
for Lily work. I may've asked this question already, but i don't
remember whether there was a definitive answer: does gerrit have a web
interface that allows to
On 2012/09/03 03:41:39, Patrick McCarty wrote:
LGTM
Let's not get this merged. ly_lily_module_constant (module-variable)
is available in _both_ Guile 1.8 as well as Guile 2.0. It may cause a
slight cell count hit in Guile 1.8, but we don't want Guile 1 to stick
around until the end of 2.17
On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup d...@gnu.org wrote:
I predict that a lot of discussions will be had, and we will end up
with virtually no changes. I guess that such is life.
Of course many of our ideas will not be good. That's fine!
That's how creative thinking works!
No;
45 matches
Mail list logo
