Re: T1349 - Fix load order for running with Guile V2 (issue 4849054)

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 https:/

Re: oops! I've changed files in the `snippet' directory

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 y

oops! I've changed files in the `snippet' directory

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, proba

Re: Check for null pointer

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 large amount of input spread across many files, which is wh

Re: Uninitialized SCM variables

On 2011-08-17, at 13:03 , Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > To: "Carl Sorensen" > Cc: "lilypond-devel Development" > Sent: Wednesday, August 17, 2011 5:48 PM > Subject: Re: Uninitialized SCM variables > > >> On Wed, Aug 17, 2011 at 05:53:40AM -060

PATCH: 48-hour countdown 21:00 MDT 2011-08-19

For 21:00 MDT Friday August 19 Issue 1349 : Guile 2.0 compat: Scheme macros (repeated due to revisions since the Monday list) Issue 1779 : accidentaled notes too far from the bar

DOC: Revise CG 3.4 Commit Access (issue 4898058)

LGTM, one suggestion. 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#newcode1574 Documentation/contributor

Re: Likely a good frog project for someone with C knowledge

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 would be rather irrelevant as a des

Fix 1805: AmbitusAccidental needs avoid-slur, needed when the notes in the ambitus have a slur (issue 4904049)

http://codereview.appspot.com/4904049/diff/1/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/4904049/diff/1/scm/define-grobs.scm#newcode125 scm/define-grobs.scm:125: (avoid-slur . inside) I think it would make more sense for the engravers to ignore an Ambitu

Re: T1349 - Fix load order for running with Guile V2 (issue 4849054)

LGTM. http://codereview.appspot.com/4849054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GOP-PROP 8: issue priorities (probable 2)

On Tue, Aug 16, 2011 at 11:20:02AM +0100, Ian Hulin wrote: > 1. Some nit-picky stuff to make the proposal crystal-clear to > skim-readers like me. > See comments below embedded in the your original message text. Thanks, all fixed. > 2. I'd like to consider two types to use as additional info to t

Re: New engraver for braces (issue 4807053)

Most of my comments below resemble each other, but up here I want to suggest that if you go down the road of generalizing the arpeggio grob, the places you'd have to do work are in the rhythmic column engraver and in the several NoteColumn functions that look for an arpeggio. Instead, this would

GOP-PROP 9: behavior of make doc (probable decision)

Not much discussion, not much change from the last version. http://lilypond.org/~graham/gop/gop_9.html Proposal summary If there are build problems, then it should be easier to find out why it’s failing. This will be achieved with log files, as well as possibly including scripts which automatic

Re: Fixes issue 1628. (issue 4876051)

LGTM Now string numbers move around slurs as well. That didn't work in the old patch, nor in 2.14. The old regtest string-number-around-slur.ly avoided collisions only by accident. Different pitches would cause collisions with the string numbers, but after this patch they really move #'around t

Re: Doc: NR Warning added to para for cueduring (issue 4850051)

LGTM. Recently the same issue came up with \quoteDuring (that bug report has other issues as well) That is, starting a Staff with a quote prints nothing. \addQuote "A" {c' d' e' f' c' d' e' f'} \new Staff{ \quoteDuring "A"

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)? > > It looks like I'd need to subscribe to another mailing list to do > that. Is this true, or can input be made without being subscribed? You ca

New short and long lyric ties. (issue 4912041)

Reviewers: , Message: Hi everyone, This follows 8d148ea05fa4b34f8cc3407e112363d715b27ad8 This is fully working, except for a small issue in make doc. The two examples I put in the doc are working alone, but not with make doc: there should be short ties in "~è~", but we mysteriously get medium t

Re: Uninitialized SCM variables

On Wed, Aug 17, 2011 at 07:26:19PM +0200, David Kastrup wrote: > Graham Percival writes: > > > [1] or rather, the C standard does not specify that an uninitalized > > variable should be set to 0, so I do not blame gcc in the least; it > > was the programmer at fault. > > The C standard guarantee

Re: Uninitialized SCM variables

"Phil Holmes" writes: > In C-style languages, uninitialised variable are uninitialised and > therefore have an indeterminant value. Wrong for statically allocated variables. > Hence the danger of uninitialised pointers. Some other languages do > initialise them to 0 - visual basic is an example

Re: Uninitialized SCM variables

Graham Percival writes: > On Wed, Aug 17, 2011 at 05:53:40AM -0600, Carl Sorensen wrote: >> \On 8/16/11 10:25 PM, "Dan Eble" wrote: >> >> > Is there a reason that these variables in lily/profile.cc don't need to be >> > initialized? I don't have experience with guile, but it looks dangerous. >

Re: Uninitialized SCM variables

- Original Message - From: "Graham Percival" To: "Carl Sorensen" Cc: "lilypond-devel Development" Sent: Wednesday, August 17, 2011 5:48 PM Subject: Re: Uninitialized SCM variables On Wed, Aug 17, 2011 at 05:53:40AM -0600, Carl Sorensen wrote: \On 8/16/11 10:25 PM, "Dan Eble" wrote

Re: Uninitialized SCM variables

On Wed, Aug 17, 2011 at 05:53:40AM -0600, Carl Sorensen wrote: > \On 8/16/11 10:25 PM, "Dan Eble" wrote: > > > Is there a reason that these variables in lily/profile.cc don't need to be > > initialized? I don't have experience with guile, but it looks dangerous. > > I guess the code in this sec

Re: New engraver for braces (issue 4807053)

That wasn't working 'cause I forgot to add some files to git... This is now fixed. Bertrand http://codereview.appspot.com/4807053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Likely a good frog project for someone with C knowledge

Han-Wen Nienhuys writes: > On Wed, Aug 17, 2011 at 5:19 AM, David Kastrup wrote: > >> That would be scm_is_null (x).  It is not exactly like the code gets >> less readable by that substitution. > > it's not the same though. scm_is_null expands to > > pairs.h:#define scm_is_null(x)

Re: Likely a good frog project for someone with C knowledge

On 17/08/11 07:41, Graham Percival wrote: > On Tue, Aug 16, 2011 at 11:14:35PM -0300, Han-Wen Nienhuys wrote: >> On Tue, Aug 16, 2011 at 7:17 PM, David Kastrup >> wrote: >>> So what does relying on undefined behavior buy us apart from >>> the inability to debug type errors? >> >> It buys us time

Re: Likely a good frog project for someone with C knowledge

On Wed, Aug 17, 2011 at 5:19 AM, David Kastrup wrote: > --- a/lily/general-scheme.cc > +++ b/lily/general-scheme.cc > @@ -381,7 +381,7 @@ LY_DEFINE (ly_stderr_redirect, "ly:stderr-redirect", >   string m = "w"; >   string f = ly_scm2string (file_name); >   FILE *stderrfile; > -  if (mode != SCM_U

Re: Uninitialized SCM variables

Carl Sorensen writes: > \On 8/16/11 10:25 PM, "Dan Eble" wrote: > >> Is there a reason that these variables in lily/profile.cc don't need to be >> initialized? I don't have experience with guile, but it looks dangerous. >> >> SCM context_property_lookup_table; >> SCM grob_property_lookup_table

Re: Uninitialized SCM variables

Am Wednesday, 17. August 2011, 13:53:40 schrieb Carl Sorensen: > \On 8/16/11 10:25 PM, "Dan Eble" wrote: > > Is there a reason that these variables in lily/profile.cc don't need to > > be initialized? I don't have experience with guile, but it looks > > dangerous. > > > > SCM context_property_lo

Re: Check for null pointer

On 8/16/11 11:15 PM, "Dan Eble" wrote: > I think the following code should check that ev is not null before > dereferencing it. This might be a factor in a segfault I saw. (Sorry to be > so vague, but I am not going to build lilypond to test the theory. It would > take a credible threat of

Re: And another frog task

Am Wednesday, 17. August 2011, 13:42:50 schrieb Carl Sorensen: > On 8/17/11 5:35 AM, "David Kastrup" wrote: > > So it would seem like another worthwhile frog task to get rid of > > SCM_CDRLOC in the source tree when feasible (when the list is being > > consulted front-to-back while it is in the pr

Re: Uninitialized SCM variables

\On 8/16/11 10:25 PM, "Dan Eble" wrote: > Is there a reason that these variables in lily/profile.cc don't need to be > initialized? I don't have experience with guile, but it looks dangerous. > > SCM context_property_lookup_table; > SCM grob_property_lookup_table; > SCM prob_property_lookup_tab

Re: And another frog task

On 8/17/11 5:35 AM, "David Kastrup" wrote: > > So it would seem like another worthwhile frog task to get rid of > SCM_CDRLOC in the source tree when feasible (when the list is being > consulted front-to-back while it is in the process of being created, > this would not be possible. However, si

And another frog task

I just profiled the following code: #include #include void *test1(void *n) { for (int i=0; i<(int)n; i++) { SCM list = SCM_EOL; SCM *tail = &list; for (int k=0; k<(int)n; k++) { *tail = scm_cons (SCM_BOOL_F, SCM_EOL); tail = SCM_CDRLOC(*tail); } } return 0; }

Re: Fixes issue 1628. (issue 4876051)

New patchset uploaded w/ minimal changes made (just the engravers). http://codereview.appspot.com/4876051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix for Issue 620. (issue 4814041)

Pushed as ac7aef03ab9d459a6ea6f03d9c127be150871dd4. Cheers, MS http://codereview.appspot.com/4814041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Prevents nested tuplets from colliding. (issue 4808082)

I haven't gotten around to making the other changes you pointed out yet, but I will either tonight or tomorrow. Cheers, MS Changes are up and ready for review. Cheers, MS http://codereview.appspot.com/4808082/ ___ lilypond-devel mailing list l

Re: Likely a good frog project for someone with C knowledge

Reinhold Kainhofer writes: > On Mi., 17. Aug. 2011 10:19:33 CEST, David Kastrup wrote: >> I mean, look at the bad code I dug up.   Pretty early in the list there >> was: >> -   if (mode != SCM_UNDEFINED && scm_string_p (mode)) >> +   if (scm_is_string (mode)) > > > Yes, that's code that shoul

Re: Likely a good frog project for someone with C knowledge

Reinhold Kainhofer writes: > On Mi., 17. Aug. 2011 10:19:33 CEST, David Kastrup wrote: >> I mean, look at the bad code I dug up.   Pretty early in the list there >> was: >> -   if (mode != SCM_UNDEFINED && scm_string_p (mode)) >> +   if (scm_is_string (mode)) > > > Yes, that's code that shoul

Re: Likely a good frog project for someone with C knowledge

On Mi., 17. Aug. 2011 10:19:33 CEST, David Kastrup wrote: > I mean, look at the bad code I dug up.   Pretty early in the list there > was: > -   if (mode != SCM_UNDEFINED && scm_string_p (mode)) > +   if (scm_is_string (mode)) Yes, that's code that should really be fixed. > > If you feel co

Re: Likely a good frog project for someone with C knowledge

David Kastrup writes: > Bertrand Bordage writes: > >> 2011/8/17 David Kastrup >> >> Bertrand Bordage writes: >> >> >> > This would be great if Han-Wen decides to keep it like that. >> > Otherwise there is really a lot of work, with many shortcuts to >> > define. >>

Re: Likely a good frog project for someone with C knowledge

Bertrand Bordage writes: > 2011/8/17 David Kastrup > > Bertrand Bordage writes: > > > > This would be great if Han-Wen decides to keep it like that. > > Otherwise there is really a lot of work, with many shortcuts to > > define. > > to_boolean (scm_is_pair (x)) >

Re: Likely a good frog project for someone with C knowledge

Han-Wen Nienhuys writes: > On Tue, Aug 16, 2011 at 7:17 PM, David Kastrup wrote: >>> (and I am speaking as a GUILE developer here as well) >> >> So what does relying on undefined behavior buy us apart from the >> inability to debug type errors? > > It buys us time to work on more interesting and

Re: Likely a good frog project for someone with C knowledge

Graham Percival wrote Wednesday, August 17, 2011 7:41 AM On Tue, Aug 16, 2011 at 11:14:35PM -0300, Han-Wen Nienhuys wrote: On Tue, Aug 16, 2011 at 7:17 PM, David Kastrup wrote: > So what does relying on undefined behavior buy us apart from > the > inability to debug type errors? It buys u

Re: Likely a good frog project for someone with C knowledge

2011/8/17 David Kastrup > Bertrand Bordage writes: > > > This would be great if Han-Wen decides to keep it like that. > > Otherwise there is really a lot of work, with many shortcuts to > > define. > > to_boolean (scm_is_pair (x)) > > That one would be wrong since scm_is_pair already returns a C