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

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 to work on more interesting and more valuable impr

Re: Add hihat halfopen glyph to font (issue 4714043)

Thanks Werner. Fixed. http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf#newcode633 mf/feta-scripts.mf:633: height# / 2, height# / 2); On 2011/08/17 05:25:36, lemzwerg wrote:

Re: Add hihat halfopen glyph to font (issue 4714043)

LGTM. http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf#newcode633 mf/feta-scripts.mf:633: height# / 2, height# / 2); Vertical align mismatch. http://codereview.appspot.com/47

Check for null pointer

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 violence to change my mind.) A grep suggests tha

Re: Add hihat halfopen glyph to font (issue 4714043)

I've got a new patch set up. I changed the name to halfopenvertical. I think that the halfopen symbol currently in the font is used for french horn, but Gould does use it for hihat. So I decided to just describe the symbol, rather than specify its use. Also, I shortened up the vertical stroke.

Uninitialized SCM variables

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_table; -- Dan ___

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

> Speaking as a long-time lilypond developer, it is my experience that > the errors you point out are not a problem (except for the SCM => > bool conversion). GUILE's API uses data that can be passed into C > functions efficiently as parameters. This means that the SCM type > must be a machine w

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

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 more valuable improvements. Speaki

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

Reinhold Kainhofer writes: > On Mi., 17. Aug. 2011 00:51:03 CEST, David Kastrup wrote: >> All of the following would have been caught by this project (I >> hand-sifted through a git grep with a few patterns catching only a small >> subset of what the debug option would have). > > Yes, seems like

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

On Mi., 17. Aug. 2011 00:51:03 CEST, David Kastrup wrote: > All of the following would have been caught by this project (I > hand-sifted through a git grep with a few patterns catching only a small > subset of what the debug option would have). Yes, seems like those are real problems. Doing a "gi

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

Han-Wen Nienhuys writes: > The only real problem are boolean conversions because they are very wrong, > ie, > > SCM x = ... > if (x) { > .. > } > > for the rest, making lilypond SCM typing clean is just a lot of work > with no benefits at all. All of the following would have been ca

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

Han-Wen Nienhuys writes: > On Tue, Aug 16, 2011 at 3:38 PM, David Kastrup wrote: >> >> Compile Lilypond with >> -DSCM_DEBUG_TYPING_STRICTNESS=2 >> >> The guile documentation states quite clearly >> >>  -- C Type: SCM >>     `SCM' is the user level abstract C type that is used to represent >>    

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

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 boolean. -- C Function: int scm_is_pa

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

On Tue, Aug 16, 2011 at 3:38 PM, David Kastrup wrote: > > Compile Lilypond with > -DSCM_DEBUG_TYPING_STRICTNESS=2 > > The guile documentation states quite clearly > >  -- C Type: SCM >     `SCM' is the user level abstract C type that is used to represent >     all of Guile's Scheme objects, no mat

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

Reinhold Kainhofer writes: > Am Tuesday, 16. August 2011, 23:36:15 schrieb Reinhold Kainhofer: >> However, I'm not sure if this will really work out or give us much benefit. >> In particular, we have lots of checks for == SCM_EOL or == SCM_BOOL_T. E.g. >> very deep inside the core of lilypond: >>

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

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)) to_boolean (scm_list_p (x)) && !to_boolean (scm_null_p (x)) etc Bertrand ___ lilypond-devel

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

Reinhold Kainhofer writes: > However, I'm not sure if this will really work out or give us much benefit. > In particular, we have lots of checks for == SCM_EOL or == SCM_BOOL_T. E.g. > very deep inside the core of lilypond: > > inline bool ly_cheap_is_list (SCM x) {return scm_is_pair (x) || x==

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

Am Tuesday, 16. August 2011, 23:36:15 schrieb Reinhold Kainhofer: > However, I'm not sure if this will really work out or give us much benefit. > In particular, we have lots of checks for == SCM_EOL or == SCM_BOOL_T. E.g. > very deep inside the core of lilypond: > > inline bool ly_cheap_is_list (S

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

Am Tuesday, 16. August 2011, 23:08:04 schrieb David Kastrup: > Bertrand Bordage writes: > > > Compile Lilypond with > > > -DSCM_DEBUG_TYPING_STRICTNESS=2 > > > > I don't understand how you're applying this setting. > > I tried > > ./configure -DSCM. > > and > > make -DSCM. > > wit

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

David Kastrup writes: > Bertrand Bordage writes: > >> > Compile Lilypond with >> > -DSCM_DEBUG_TYPING_STRICTNESS=2 >> >> >> I don't understand how you're applying this setting. >> I tried >> ./configure -DSCM. >> and >> make -DSCM. >> without success. > > ./configure CXXFLAG

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

Bertrand Bordage writes: > > Compile Lilypond with > > -DSCM_DEBUG_TYPING_STRICTNESS=2 > > > I don't understand how you're applying this setting. > I tried > ./configure -DSCM. > and > make -DSCM. > without success. ./configure CXXFLAGS=-DSCM_DEBUG_TYPING_STRICTNESS=2 shoul

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

On Tue, Aug 16, 2011 at 10:34:54PM +0200, Bertrand Bordage wrote: > > Compile Lilypond with > > -DSCM_DEBUG_TYPING_STRICTNESS=2 > >I don't understand how you're applying this setting. >I tried >./configure -DSCM. My first guess would be to try CFLAGS="-DSCM_..." ../co

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

> > > Compile Lilypond with > > -DSCM_DEBUG_TYPING_STRICTNESS=2 > I don't understand how you're applying this setting. I tried ./configure -DSCM. and make -DSCM. without success. > *cough* Bertrand? ;) > You're right! Cécile Hauchemaille has started working on this! Bertrand _

GUB build failure for darwin-x86::cross/gcc target [Re: probably no releases until 2011 Sep]

Am Montag, 15. August 2011, 23:51:51 schrieb Graham Percival: > I also > ignored GUB master not working on my machine in favor of using the > older stable-2.14 branch to compile all the 2.15 releases. But > since we've hit this snag, we might as well start afresh by trying > to make GUB master wor

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

On Tue, Aug 16, 2011 at 08:38:18PM +0200, David Kastrup wrote: > > Compile Lilypond with > -DSCM_DEBUG_TYPING_STRICTNESS=2 ... > But with the current code base, cleaning this all up is going to be a > lot of work. Not hard to do, but a lot. I like it! It's something that's not challenging, it e

Likely a good frog project for someone with C knowledge

Compile Lilypond with -DSCM_DEBUG_TYPING_STRICTNESS=2 The guile documentation states quite clearly -- C Type: SCM `SCM' is the user level abstract C type that is used to represent all of Guile's Scheme objects, no matter what the Scheme object type is. No C operation except assi

Re: GOP-PROP 10: scheme indentation

On 8/16/11 4:31 AM, "Ian Hulin" wrote: > On 16/08/11 08:51, Trevor Daniels wrote: >> LGTM >> >> Graham Percival wrote Tuesday, August 16, 2011 5:53 AM >> >>> There seems to be general happiness with Carl's work; a few minor >>> tweaks here and there may still be necessary, but hopefully this

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

LGTM. Carl From: lilypond-devel-bounces+c_sorensen=byu@gnu.org [lilypond-devel-bounces+c_sorensen=byu@gnu.org] On Behalf Of Graham Percival [gra...@percival-music.ca] Sent: Monday, August 15, 2011 10:51 PM To: lilypond-devel@gnu.org Subject: GOP-

Re: Issue 1821 in lilypond: GUB argument list too long

Am Tuesday, 16. August 2011, 13:56:26 schrieben Sie: > On Aug 16, 2011, at 1:51 PM, Reinhold Kainhofer wrote: > > Am Tuesday, 16. August 2011, 13:06:11 schrieben Sie: > >> On Aug 16, 2011, at 12:58 PM, Reinhold Kainhofer wrote: > >>> Am Tuesday, 16. August 2011, 12:47:13 schrieb Mike Solomon: > >>>

Re: Fixes issue 1628. (issue 4876051)

On Aug 16, 2011, at 1:06 PM, Han-Wen Nienhuys wrote: > Your patch is doing much more than address issue 1628. Can you do > just the change to the engraver to close issue 1628? Any ensuing > collisions should be made into a new issue. > OK. The reason that I added all that extra stuff was for

Re: cartouche collides with heading

- Original Message - From: "Werner LEMBERG" To: Cc: Sent: Monday, August 15, 2011 5:10 PM Subject: Re: cartouche collides with heading Updating the current delivered texinfo.tex with this patch fixes our problem. Good! However, we need to be careful accepting a new version of te

Re: Fixes issue 1628. (issue 4876051)

Your patch is doing much more than address issue 1628. Can you do just the change to the engraver to close issue 1628? Any ensuing collisions should be made into a new issue. Are you sure exclude_extra_objects_outside_x_range() is really needed? We already have Real x = info.extents_

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Tue, Aug 16, 2011 at 4:38 AM, wrote: > 2)  Create a Flag grob (less trivial, I'd say two hours of work to > create the grob in define-grobs.scm, get it made in a new finalize > method for the stem engraver, copy and paste all of the flag stuff in > stem.cc into a new flag.cc, create an X-offse

Re: GOP-PROP 10: scheme indentation

On 16/08/11 08:51, Trevor Daniels wrote: > LGTM > > Graham Percival wrote Tuesday, August 16, 2011 5:53 AM > >> There seems to be general happiness with Carl's work; a few minor >> tweaks here and there may still be necessary, but hopefully this >> discussion will pretty much be rubber-stamping

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

Lgtm. Some scheme indentation errors as artifacts from the old file, bit these will be fixed automatically when fix-scheme.sh is run after GOP-Prop 10 is accepted. http://codereview.appspot.com/4849054/ ___ lilypond-devel mailing list lilypond-devel@g

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

Hi Graham, 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. 2. I'd like to consider two types to use as additional info to the current ones: Type-User-development and Type-Developer-development. 2.1

Re: Fixes heights and pure heights of stems. (issue 4898044)

On 2011/08/15 21:33:07, Neil Puttock wrote: On 15 August 2011 13:31, wrote: That's every users who wants cross-staff stems for chords. Unless you can come up with a better interface for dealing with cross-staff stems, I'd rather you keep 'length for this case. I

Re: how many patches can we review?

On Aug 16, 2011, at 10:08 AM, Graham Percival wrote: > We're up to 59 patches now, plus 17 patches on the "plz review; no > known problems" list. We're losing ground quickly, and this will > soon become a serious problem for developers and contributors (if > it isn't already). > > This is not an

Re: Fixes heights and pure heights of stems. (issue 4898044)

- Original Message - From: "Han-Wen Nienhuys" To: ; ; Sent: Monday, August 15, 2011 10:48 PM Subject: Re: Fixes heights and pure heights of stems. (issue 4898044) On Sun, Aug 14, 2011 at 1:25 PM, wrote: THE UGLY: Because this patch effects stem extents across the board, the reg

how many patches can we review?

We're up to 59 patches now, plus 17 patches on the "plz review; no known problems" list. We're losing ground quickly, and this will soon become a serious problem for developers and contributors (if it isn't already). This is not an official proposal, so don't worry about trying to "get it right".

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

Graham Percival wrote Tuesday, August 16, 2011 5:51 AM Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html LGTM Trevor - No virus found in this message. Checked by AVG - www.

Re: GOP-PROP 10: scheme indentation

LGTM Graham Percival wrote Tuesday, August 16, 2011 5:53 AM There seems to be general happiness with Carl's work; a few minor tweaks here and there may still be necessary, but hopefully this discussion will pretty much be rubber-stamping. [snip] ** Implementation notes The C++ change went qu

Re: Fixes heights and pure heights of stems. (issue 4898044)

I see what you mean about flags, and I think there are two ways to go with it. 1) Reinstate stem-begin-position and stem-end-position in this patch (trivial: would take 10 minutes). 2) Create a Flag grob (less trivial, I'd say two hours of work to create the grob in define-grobs.scm, get it ma