Folks,
while doing some doc fixes I've also changed files directly in the
`snippet' directory by accident. But this is not me alone, others do
the same :-)
My question: Is this really a problem? Are such fixes lost if someone
is running makelsr? Or is someone taking care of such fixes,
On Thu, Aug 18, 2011 at 08:09:29AM +0200, Werner LEMBERG wrote:
My question: Is this really a problem? Are such fixes lost if someone
is running makelsr?
Depends, and yes. Files are completely rewritten from a makelsr
import. Whether or not this is a problem depends on the changes
that
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 need to be, but that's beyond the scope of this
patch.
Thanks,
Patrick
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 it a
- Original Message -
From: Werner LEMBERG w...@gnu.org
To: m...@philholmes.net
Cc: lilypond-devel@gnu.org
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
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
Han-Wen Nienhuys hanw...@gmail.com writes:
On Wed, Aug 17, 2011 at 9:41 AM, David Kastrup d...@gnu.org 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
Hi Han-Wen,
On 18/08/11 03:16, Han-Wen Nienhuys wrote:
On Wed, Aug 17, 2011 at 9:41 AM, David Kastrup d...@gnu.org
wrote: [snip...] I should probably start using sarcasm tags.
No, you're too nice a guy for that, how about
irony
.
.
.
/irony :-)
Cheers,
Ian
Dan Eble d...@faithful.be 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
Am Thursday, 18. August 2011, 11:45:25 schrieb David Kastrup:
Dan Eble d...@faithful.be 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
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:
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 need
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
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,
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/
___
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
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
test missing.
On Thu, Aug 18, 2011 at 8:03 AM, mts...@gmail.com 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:
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
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):
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
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 such
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 Thu, Aug 18, 2011 at 9:27 AM, mts...@gmail.com 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
On Aug 18, 2011, at 2:51 PM, Han-Wen Nienhuys wrote:
On Thu, Aug 18, 2011 at 9:27 AM, mts...@gmail.com 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
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
LGTM :)
Bertrand
http://codereview.appspot.com/4875054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
(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
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
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
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.
On 8/17/11 11:32 PM, Dan Eble d...@faithful.be 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,
On 8/17/11 10:41 PM, Dan Eble d...@faithful.be wrote:
Carl Sorensen c_sorensen at 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://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
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
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
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,
On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin ianhuli...@gmail.com 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
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
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_boolean(
On 18/08/11 17:06, Patrick McCarty wrote:
On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin ianhuli...@gmail.com
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
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
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
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 replace
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 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
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 demonstrate
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
all
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-fixed
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
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 only
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
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 about
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
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
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
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 use
57 matches
Mail list logo
