On 2011/08/19 23:03:37, Neil Puttock wrote:
On 2011/08/19 21:08:10, Carl wrote:
> As an aside, I think that we should change the definition of the
property
> align-dir. It should no longer be called a direction, since it's
not limited
to
> the values -1, 0, and 1.
It's unused. I think
We have a number of "maintainability" problems, such as an
inability to build releases and delayed implementation of some
previous accepted proposals.
I am therefore not introducing any new proposals for the next two
weeks. New proposals will tentatively start on the week of
2011-Sep-07, but this
On 8/19/11 4:35 PM, "Graham Percival" wrote:
> On Fri, Aug 19, 2011 at 06:04:38PM +, carl.d.soren...@gmail.com wrote:
>> I have some comments about the docs. I think they're too tutorial, and
>> I think the exhaustive lists are unwieldy and should be eliminated. THe
>> source should be t
On 2011/08/19 21:08:10, Carl wrote:
As an aside, I think that we should change the definition of the
property
align-dir. It should no longer be called a direction, since it's not
limited to
the values -1, 0, and 1.
It's unused. I think it's superseded by stacking-dir.
Cheers,
Neil
http
On 18 August 2011 13:44, Mike Solomon wrote:
> What about pure-container ?
It's all right, I suppose... but what about the unpure part? After
all, the container's not just about the pure callback.
Cheers,
Neil
___
lilypond-devel mailing list
lilypon
http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly
File input/regression/pure-closure.ly (right):
http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly#newcode18
input/regression/pure-closure.ly:18: #(ly:make-pure-closure
ly:stem::height '
On Fri, Aug 19, 2011 at 06:04:38PM +, carl.d.soren...@gmail.com wrote:
> I have some comments about the docs. I think they're too tutorial, and
> I think the exhaustive lists are unwieldy and should be eliminated. THe
> source should be the reference.
On the long term, I agree with Carl. In
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-broken.ly
File input/regression/tuplet-nest-broken.ly (right):
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-broken.ly#newcode5
input/regression/tuplet-nest-broken.ly:5: texidoc = "Broke
Han-Wen Nienhuys writes:
> On Fri, Aug 19, 2011 at 6:14 AM, Bertrand Bordage
> wrote:
>>> It is somewhat amusing, by the way, that Lilypond's to_boolean is
>>> required in order to let '() and #f be interpreted in the same manner.
>>> It would seem that Lisp's conflating them into `nil' is not t
LGTM.
http://codereview.appspot.com/4837050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc
File lily/general-scheme.cc (right):
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc#newcode110
lily/general-scheme.cc:110: if (scm_is_integer (s))
On 2011/08/19 20:20:12, Neil Puttock wrote:
On 2011/08/19 1
Carl Sorensen wrote Friday, August 19, 2011 5:38 PM
In fact, I think I would be in favor of removing \once \revert
from the
parser. The semantics of \once \revert can be confusing, and the
same
behavior could be achieved with a \once \override.
I agree - it would be better to return a synt
On Fri, Aug 19, 2011 at 6:14 AM, Bertrand Bordage
wrote:
>> It is somewhat amusing, by the way, that Lilypond's to_boolean is
>> required in order to let '() and #f be interpreted in the same manner.
>> It would seem that Lisp's conflating them into `nil' is not the worst
>> idea.
>
> This also mi
On 18 August 2011 22:46, Reinhold Kainhofer wrote:
> BTW, I managed to get the LSR-copy running on my machine:
> http://lsr.kainhofer.at/LSR/
>
> (the jail is set up but not yet used for compiling)
>
> HOWTO as usual at http://wiki.kainhofer.com/lilypond/lsr_setup
Wow, that's awesome work, Reinh
On 2011/08/19 18:04:38, Carl wrote:
THanks for doing this!
And thanks for this excellent review!
I have some comments about the docs. I think they're too tutorial,
and I think
the exhaustive lists are unwieldy and should be eliminated. THe
source should
be the reference.
You're right.
On 2011/08/19 20:20:12, Neil Puttock wrote:
http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh
File lily/include/lily-guile.hh (right):
http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh#newcode96
lily/include/lily-guile.hh:96: //
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc
File lily/general-scheme.cc (right):
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc#newcode110
lily/general-scheme.cc:110: if (scm_is_integer (s))
On 2011/08/19 18:04:38, Carl wrote:
I think the old code h
On Fri, 19 Aug 2011 01:33:56 -0700, Phil Holmes wrote:
- Original Message -
From: "Keith OHara"
I don't know until next time I look at Ted Ross' book in the library.
Mostly I was being rhetorical, calling to attention the vastly different
time-scales that Mike and I live in.
I'v
THanks for doing this!
I have some comments about the docs. I think they're too tutorial, and
I think the exhaustive lists are unwieldy and should be eliminated. THe
source should be the reference.
I think the code changes should be separated from the doc changes. I
disagree with your changes
Doc part LGTM. I can't speak about the scm / C++ stuff.
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Hi,
Graham asked me to document an small issue.
(http://codereview.appspot.com/4875054/)
And this became something bigger.
He also told me to push it directly, but I made a few changes in the
interface as I read the code and wrote the doc.
So the review concerns only the C
On 8/19/11 10:15 AM, "David Kastrup" wrote:
>
> Up to now, \once \revert is not really documented nor used. I have not
> yet dug through the existing code in order to figure out what it does if
> anything (most likely ignoring \once, but not sure).
I would expect that \once \revert would revert
Up to now, \once \revert is not really documented nor used. I have not
yet dug through the existing code in order to figure out what it does if
anything (most likely ignoring \once, but not sure).
In order to not have the override/revert stack get into unexpected
interactions, I want to change \
- Original Message -
From:
To: ;
Cc: ;
Sent: Friday, August 19, 2011 11:40 AM
Subject: Re: Corrects image size in web.pdf - issue 982 (issue 4916041)
LGTM, but do we still use the -small images for anything else now? I
mean, go ahead and push this, but then please investigate if we
LGTM, but do we still use the -small images for anything else now? I
mean, go ahead and push this, but then please investigate if we still
need the -small images, and if we don't need them, then please remove
them from the build system.
http://codereview.appspot.com/4916041/
___
>
> > I'm already writing a section called "C/Scheme interface" where I
> > explain that scm_integer_p (x) == SCM_BOOL_T isn't correct.
>
> Well, it works as long as scm_is_eq works the same as ==. But that's an
> implementation detail of Guile and not part of the Guile API. Bypassing
> the Guile
Bertrand Bordage writes:
> I think so.
>
>
> I'm already writing a section called "C/Scheme interface" where I
> explain that scm_integer_p (x) == SCM_BOOL_T isn't correct.
Well, it works as long as scm_is_eq works the same as ==. But that's an
implementation detail of Guile and not part of the
- Original Message -
From: "Keith OHara"
To: ; ;
; "Mike Solomon"
Sent: Friday, August 19, 2011 8:51 AM
Subject: Re: Has piano pedal brackets end on the right of a note
column.(issue 4899050)
On Thu, 18 Aug 2011 23:25:40 -0700, Mike Solomon wrote:
On Aug 19, 2011, at 5:01 AM, k
>> My conclusion is that it is quite safe to directly edit files in
>> the `snippets' directory. Relieved :-)
>
> No, it is not safe. Your changes will be elminated the next time
> Neil (or Valentin, or anybody who cares about LSR) does a "full
> import". Historically, this only happens every
On Aug 19, 2011, at 10:04 AM, Sandor Spruit wrote:
> Hello,
>
> I recently had an informal discussion with some collegues on the use of SVG,
> in
> general. They are in music research, I am a developer working on a completely
> unrelated topic - so please forgive me my ignorance w.r.t. music-rel
Hello,
I recently had an informal discussion with some collegues on the use of SVG, in
general. They are in music research, I am a developer working on a completely
unrelated topic - so please forgive me my ignorance w.r.t. music-related
terminology.
We discussed the possibilities to use music sc
On Aug 19, 2011, at 9:51 AM, Keith OHara wrote:
>
> You mean your new 'bound-alignment-interfaces. I didn't follow issue 620,
> but looking now I don't see how it helps. We would want to find the left
> extent of the note-heads in the main note column, excluding suspended
> note-heads. (Act
- Original Message -
From:
To:
Sent: Thursday, August 18, 2011 11:09 PM
Subject: Request to mailing list lilypond-devel rejected
Your request to the lilypond-devel mailing list
Posting of your message titled "Corrects image size in web.pdf -
issue 982 (issue 4916041)"
has been r
On Thu, 18 Aug 2011 23:25:40 -0700, Mike Solomon wrote:
On Aug 19, 2011, at 5:01 AM, k-ohara5...@oco.net wrote:
I think the correct fix is merely to ignore suspended heads, which could
be implemented as aligning to the stem for down-stems. I find good
evidence to back that up I'll post on the
I think so.
I'm already writing a section called "C/Scheme interface" where I explain
that scm_integer_p (x) == SCM_BOOL_T isn't correct.
I also start a list of functions like to_boolean explaining why and how to
use them.
As an expert of these issues, you will probably want to add some details
af
Thanks Joe!
New patchset uploaded.
Cheers,
MS
http://codereview.appspot.com/4860042/diff/1/flower/polynomial.cc
File flower/polynomial.cc (right):
http://codereview.appspot.com/4860042/diff/1/flower/polynomial.cc#newcode65
flower/polynomial.cc:65: Polynomial::minmax (Real l, Real r, bool dir)
36 matches
Mail list logo
