Graham Percival writes:
> On Thu, Aug 18, 2011 at 09:43:38PM +, carl.d.soren...@gmail.com wrote:
>> I think we ought to have a comment somewhere that describes why we don't
>> use scm_is_true. But I can't figure out where to put it -- I guess it
>> should be in the documentation that we hope
On Aug 19, 2011, at 5:01 AM, k-ohara5...@oco.net wrote:
> A swing and a miss, I'm afraid.
>
> See input/regression/pedal-bracket for what the original alignment goals
> were. (You could expand that reg-test to cover issue 723)
>
> I think the correct fix is merely to ignore suspended heads, whi
Werner LEMBERG wrote Friday, August 19, 2011 6:38 AM
In particular, many locations which I've fixed (at least in my
opinion) were talking about, say, `#t' and `#foo' at the same
time,
which I consider *very* confusing. There are two possiblities to
fix it: Either by saying `#t' and `foo', o
> In particular, many locations which I've fixed (at least in my
> opinion) were talking about, say, `#t' and `#foo' at the same time,
> which I consider *very* confusing. There are two possiblities to
> fix it: Either by saying `#t' and `foo', or by saying `##t' and
> `#foo'. I've decided to us
> Please read:
> http://lilypond.org/doc/v2.15/Documentation/contributor/lilypond-formatting
> in particular the point about #.
I did that. And there I can find
Try to avoid using #' or #` within when describing context or layout
properties outside of an @example or @lilypond, unless the
Hi Werner,
Please read:
http://lilypond.org/doc/v2.15/Documentation/contributor/lilypond-formatting
in particular the point about #. I am willing to reconsider this
policy if you make a good argument against it, but please revert
2763b2de261e4f6263e2d4751b45d7c40f1ef7ea
until/unless there is an
Reviewers: Graham Percival, phileholmes_googlemail.com, Reinhold,
reinhold_kainhofer.com, graham_percival-music.ca,
Message:
On 2011/08/19 03:11:15, graham_percival-music.ca wrote:
On Fri, Aug 19, 2011 at 03:21:03AM +0200, Reinhold Kainhofer wrote:
> Am Friday 19 August 2011, 02:29:22 schrieb
On Fri, Aug 19, 2011 at 03:21:03AM +0200, Reinhold Kainhofer wrote:
> Am Friday 19 August 2011, 02:29:22 schrieb percival.music...@gmail.com:
> > On 2011/08/18 11:42:13, Reinhold wrote:
> > > Why did you change all dsa to rsa?
> It's not only savannah, it's basically everone who knows a little bit
A swing and a miss, I'm afraid.
See input/regression/pedal-bracket for what the original alignment goals
were. (You could expand that reg-test to cover issue 723)
I think the correct fix is merely to ignore suspended heads, which could
be implemented as aligning to the stem for down-stems. I f
Am Friday 19 August 2011, 02:29:22 schrieb percival.music...@gmail.com:
> On 2011/08/18 11:42:13, Reinhold wrote:
> > Why did you change all dsa to rsa?
>
> Really?! this whole topic began because somebody said that savannah
> requested that people use dsa because it was more secure.
It's not on
On 2011/08/18 11:42:13, Reinhold wrote:
Documentation/contributor/source-code.itexi:1425: Generate an SSH
@q{rsa} key
pair. Enter the following at the
Why did you change all dsa to rsa? RSA is the older encryption
technology, which
is known not to be as secure as DSA...
Really?! this whol
On Thu, Aug 18, 2011 at 09:59:32AM +0200, Werner LEMBERG wrote:
>
> > Files are completely rewritten from a makelsr import. Whether or
> > not this is a problem depends on the changes that you've been
> > making.
>
> Well, I consider it a `problem' if fixes get completely overwritten by
> non-fi
On Thu, Aug 18, 2011 at 09:43:38PM +, carl.d.soren...@gmail.com wrote:
> I think we ought to have a comment somewhere that describes why we don't
> use scm_is_true. But I can't figure out where to put it -- I guess it
> should be in the documentation that we hope will arise as a result of
> al
Am Donnerstag, 18. August 2011, 08:25:48 schrieb Graham Percival:
> > It's really tedious to add fixed files to the `new' directory...
>
> This might be made easier with a script, or at least if we cleared
> out the old stuff from that "new" directory.
>
> Unfortunately, nobody is willing to demo
On 2011/08/18 21:04:21, dak wrote:
On 2011/08/18 18:01:36, Carl wrote:
> On 2011/08/18 15:46:43, dak wrote:
Well, if we have properties that should default to #t (do we really
have any of
those?) then we should likely use something like to_boolean_or_t and
to_boolean_or_f instead of scm_is_
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)
const
Perhaps "bool max" instead of "bool dir"?
On 2011/08/18 18:01:36, Carl wrote:
On 2011/08/18 15:46:43, dak wrote:
>
http://codereview.appspot.com/4875054/diff/8002/lily/bar-check-iterator.cc#newcode52
> lily/bar-check-iterator.cc:52: if (scm_is_true (tr->get_property
> ("ignoreBarChecks")))
> As I already explained: you can't replac
Thanks for your prompt and detailed reviews!
I applied the changes, especially dak's. I changed the type of side-axis
property to an integer.
Regards,
Cécile Hauchemaille
http://codereview.appspot.com/4875054/
___
lilypond-devel mailing list
lilypond-d
Am Samstag, 13. August 2011, 16:15:34 schrieben Sie:
> Assuming that there will not be major objections for the loglevels patch
> on the 48-hour countdown, here is a patch that documents the various
> logging functions in the contributor's guild.
I have committed both this patch for the CG and a p
On 18/08/11 17:06, Patrick McCarty wrote:
> On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin
> wrote:
>> On Thu 18 Aug 2011 07:50:28 BST, pnor...@gmail.com wrote:
>>
>> The load-order issue appears to be fixed, testing with git and
>> guile 1.8 and 2.0.2. Ignoring whitespace changes, this patch
>> LGTM
On 2011/08/18 15:46:43, dak wrote:
http://codereview.appspot.com/4875054/diff/8002/lily/bar-check-iterator.cc#newcode52
lily/bar-check-iterator.cc:52: if (scm_is_true (tr->get_property
("ignoreBarChecks")))
As I already explained: you can't replace to_boolean with scm_is_true,
since
to_boolea
Reviewers: Graham Percival,
Message:
Updates website search. Please review.
Description:
See Issue 1405 - this allows users to search the site as
well as the docs, and improves the way that Google is
used to search for docs. In the first instance this will
mean that the English site gets a dif
On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin wrote:
> On Thu 18 Aug 2011 07:50:28 BST, pnor...@gmail.com wrote:
>
> The load-order issue appears to be fixed, testing with git and guile 1.8
> and 2.0.2. Ignoring whitespace changes, this patch LGTM.
>
> Some more shuffling is needed to make sure we ha
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc#newcode177
lily/ambitus-engraver.cc:177: Rational sig_alter = !scm_is_false
(handle)
On 2011/08/18 14:18:45, Reinhold
http://codereview.appspot.com/4875054/diff/8002/lily/accidental-engraver.cc
File lily/accidental-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/8002/lily/accidental-engraver.cc#newcode319
lily/accidental-engraver.cc:319: if (scm_to_int
(left_objects_[i]->get_property ("side-axis
http://codereview.appspot.com/4875054/diff/8002/lily/accidental-engraver.cc
File lily/accidental-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/8002/lily/accidental-engraver.cc#newcode319
lily/accidental-engraver.cc:319: if (scm_to_int
(left_objects_[i]->get_property ("side-axis
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc#newcode177
lily/ambitus-engraver.cc:177: Rational sig_alter = !scm_is_false
(handle)
On 2011/08/18 14:03:06, Cécile H
On 8/17/11 10:41 PM, "Dan Eble" wrote:
> Carl Sorensen byu.edu> writes:
>
>> Do you have more information about the segfault that you'd be willing to
>> share with us?
>
> What I have so far is a backtrace:
> http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html
> and a larg
On 8/17/11 11:32 PM, "Dan Eble" wrote:
>
> Backing upS I believe the compiler will initialize the bits in the
> aforementioned variables to zero, but is zero a desirable default for SCM
> variables in general, and these in particular?
Yes. In this case, if we were to initialize it, it would b
You'll find that I don't consider all advice given to you valid. Which
shows that this is a difficult area to understand, and that we should
likely, as a byproduct of your work, do a writeup about "Guile and
Lilypond" to make it easier for others to just follow rules when writing
stuff.
http://
Patch updated.
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc#newcode177
lily/ambitus-engraver.cc:177: Rational sig_alter = !scm_is_false
(handle)
So, might scm_is
LGTM.
I haven't run the regtests, though, to make sure there are no
differences.
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/ambitus-engraver.cc#newcode177
lily/ambitus-engraver.cc
(Two minor comments however).
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc
File lily/auto-beam-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc#newcode172
lily/auto-beam-engraver.cc:172: return !scm_is_false (scm_call_4
(get
LGTM :)
Bertrand
http://codereview.appspot.com/4875054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Hi everyone,
I started working on this issue:
http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00646.html
Could you tell me if this is correct?
Regards,
Cécile Hauchemaille
Description:
Fixes boolean/SCM confusions, part 1.
Please review this at http://coderev
On Aug 18, 2011, at 2:51 PM, Han-Wen Nienhuys wrote:
> On Thu, Aug 18, 2011 at 9:27 AM, wrote:
>> I figured not making a regtest just cuz there will already be little
>> changes to several regtests. But, I can certainly add one.
>>
>> Cheers,
>> MS
>>
>>
>> http://codereview.appspot.com/4898
On Thu, Aug 18, 2011 at 9:27 AM, wrote:
> I figured not making a regtest just cuz there will already be little
> changes to several regtests. But, I can certainly add one.
>
> Cheers,
> MS
>
>
> http://codereview.appspot.com/4898060/diff/1/lily/ledger-line-spanner.cc
> File lily/ledger-line-span
On Aug 18, 2011, at 2:31 PM, n.putt...@gmail.com wrote:
> Hi Mike,
>
> I have reservations about the naming, since you're basically creating a
> smob which acts as a container for a pair of callbacks; it doesn't work
> like a simple-closure in that you can evaluate the closure and get
> something
On Aug 18, 2011, at 1:06 PM, Reinhold Kainhofer wrote:
> Am Thursday, 18. August 2011, 11:21:59 schrieb mts...@gmail.com:
>> This is a more extensible way to deal with pure properties. I'd like
>> this patch to be the first step, with the second step being rewriting
>> define-grob-properties.scm
Hi Mike,
I have reservations about the naming, since you're basically creating a
smob which acts as a container for a pair of callbacks; it doesn't work
like a simple-closure in that you can evaluate the closure and get
something useful back.
Cheers,
Neil
http://codereview.appspot.com/4894052/
I figured not making a regtest just cuz there will already be little
changes to several regtests. But, I can certainly add one.
Cheers,
MS
http://codereview.appspot.com/4898060/diff/1/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (right):
http://codereview.appspot.com/4898060/d
http://codereview.appspot.com/4898060/diff/1/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (right):
http://codereview.appspot.com/4898060/diff/1/lily/ledger-line-spanner.cc#newcode89
lily/ledger-line-spanner.cc:89: continue;
can't you check poss.find(max(0, lincount - *it)) ?
I d
test missing.
On Thu, Aug 18, 2011 at 8:03 AM, wrote:
> Reviewers: ,
>
> Description:
> Makes sure that ledger lines do not overlap with accidentals.
>
> Please review this at http://codereview.appspot.com/4898060/
>
> Affected files:
> M lily/ledger-line-spanner.cc
>
>
> Index: lily/ledger-lin
On 2011/08/18 11:06:57, reinhold_kainhofer.com wrote:
Wow, that would be VERY user-unfriendly. Just imagine explaining that
to
someone on -user...
(or even to the average lilypond developer... I still haven't
understood what
closures are).
I agree, though I do like the idea in principle si
http://codereview.appspot.com/4898058/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/4898058/diff/1/Documentation/contributor/source-code.itexi#newcode1425
Documentation/contributor/source-code.itexi:1425
On 2011/08/18 11:21:22, PhilEHolmes wrote:
LGTM too. My suggestion would be to add some instructions about
actually
pushing. It took me a while to convince myself that all that appears
to be
needed is to have an unpushed commit and type "git push".
Yes, it' s really that simple ;-)
We sho
LGTM too. My suggestion would be to add some instructions about
actually pushing. It took me a while to convince myself that all that
appears to be needed is to have an unpushed commit and type "git push".
http://codereview.appspot.com/4898058/
___
Am Thursday, 18. August 2011, 11:21:59 schrieb mts...@gmail.com:
> This is a more extensible way to deal with pure properties. I'd like
> this patch to be the first step, with the second step being rewriting
> define-grob-properties.scm such that it uses pure closures as much as
> possible. First
Reviewers: ,
Description:
Makes sure that ledger lines do not overlap with accidentals.
Please review this at http://codereview.appspot.com/4898060/
Affected files:
M lily/ledger-line-spanner.cc
Index: lily/ledger-line-spanner.cc
diff --git a/lily/ledger-line-spanner.cc b/lily/ledger-line-s
Hi Patrick,
On Thu 18 Aug 2011 07:50:28 BST, pnor...@gmail.com wrote:
>
> The load-order issue appears to be fixed, testing with git and guile 1.8
> and 2.0.2. Ignoring whitespace changes, this patch LGTM.
>
> Some more shuffling is needed to make sure we have markup commands
> defined where they n
Reviewers: ,
Description:
Has piano pedal brackets end on the right of a note column.
Please review this at http://codereview.appspot.com/4899050/
Affected files:
A input/regression/piano-pedal-bracket-end.ly
M lily/piano-pedal-bracket.cc
Index: input/regression/piano-pedal-bracket-end.ly
Am Thursday, 18. August 2011, 11:45:25 schrieb David Kastrup:
> Dan Eble writes:
> > Backing up… I believe the compiler will initialize the bits in the
> > aforementioned variables to zero, but is zero a desirable default for
> > SCM variables in general, and these in particular?
> >
> > It also
Dan Eble writes:
> Backing up… I believe the compiler will initialize the bits in the
> aforementioned variables to zero, but is zero a desirable default for
> SCM variables in general, and these in particular?
>
> It also just sank in that in another thread there was a statement that
> treating
Hi Han-Wen,
On 18/08/11 03:16, Han-Wen Nienhuys wrote:
> On Wed, Aug 17, 2011 at 9:41 AM, David Kastrup
> wrote: [snip...] I should probably start using tags.
>
No, you're too nice a guy for that, how about
.
.
.
:-)
Cheers,
Ian
___
lilypond-deve
Han-Wen Nienhuys writes:
> On Wed, Aug 17, 2011 at 9:41 AM, David Kastrup wrote:
>
>>> on the plus side, if we use this, we will be the first GNU program to
>>> be compatible with the elisp compatibility mode in GUILE that has been
>>> almost ready for the last 15 years.
>>
>> I should say that
Reviewers: ,
Message:
This is a more extensible way to deal with pure properties. I'd like
this patch to be the first step, with the second step being rewriting
define-grob-properties.scm such that it uses pure closures as much as
possible. First, create a procedure:
#(define-public (pure-wrap
- Original Message -
From: "Werner LEMBERG"
To:
Cc:
Sent: Wednesday, August 17, 2011 7:16 PM
Subject: Re: cartouche collides with heading
This looks like a bug. Could you please report it to bug-texinfo
(together with a confirmation that the cartouche problem has been
solved)?
>> My question: Is this really a problem? Are such fixes lost if
>> someone is running makelsr?
>
> Depends, and yes.
Hmm, hmm, hmm.
> Files are completely rewritten from a makelsr import. Whether or
> not this is a problem depends on the changes that you've been
> making.
Well, I consider i
58 matches
Mail list logo
