Re: What's the deal with String_convert::reverse?

2011-08-24 Thread David Kastrup 
k...@aspodata.se (Karl Hammar) writes:

 Reinhold:
 Am Tuesday, 23. August 2011, 22:30:24 schrieb David Kastrup:
 ...
  Is this used anywhere?
 A git grep didn't show any usage, but maybe I'm missing something.

 Make does not complain about this patch (on my box).

 -  static string reverse (string s);
 +  static string reverseX (string s);

 -String_convert::reverse (string s)
 +String_convert::reverseX (string s)

Maybe we should just throw it out.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix memleak: temporary skyline objects for systems were never deleted (issue 4923048)

2011-08-24 Thread David Kastrup 
reinhold.kainho...@gmail.com writes:

 Reviewers: ,

 Message:
 This patch fixes a memleak: Some temporary skylines were never
 deleted...
 Please review

 Description:
 Fix memleak: temporary skyline objects for systems were never deleted

 Please review this at http://codereview.appspot.com/4923048/

 Affected files:
M lily/skyline.cc


 Index: lily/skyline.cc
 diff --git a/lily/skyline.cc b/lily/skyline.cc
 index  
 b6ea6b791bbbfa09aaa28e91da0a619c33085890..8f62710b0947fa8e48ffcbc7e181cba4709c96de
   
 100644
 --- a/lily/skyline.cc
 +++ b/lily/skyline.cc
 @@ -514,6 +514,7 @@ Skyline::distance (Skyline const other, Real  
 horizon_padding) const

 Skyline const *padded_this = this;
 Skyline const *padded_other = other;
 +  bool created_tmp_skylines = false;

 /*
   For systems, padding is not added at creation time.  Padding is
 @@ -525,6 +526,7 @@ Skyline::distance (Skyline const other, Real  
 horizon_padding) const
   {
 padded_this = new Skyline (*padded_this, horizon_padding, X_AXIS);
 padded_other = new Skyline (*padded_other, horizon_padding, X_AXIS);
 +  created_tmp_skylines = true;
   }

 listBuilding::const_iterator i = padded_this-buildings_.begin ();
 @@ -544,6 +546,13 @@ Skyline::distance (Skyline const other, Real  
 horizon_padding) const
   j++;
 start = end;
   }
 +
 +  if (created_tmp_skylines)
 +{
 +  delete padded_this;
 +  delete padded_other;
 +}
 +
 return dist;
   }

Skylines are smobs.  The usual way to delete them would be to unprotect
them once they have been registered by some garbage-collectable object
(or a SCM variable that is being used for accessing them).

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-08-24 Thread Mike Solomon 
On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote:

 2011/8/16 Han-Wen Nienhuys hanw...@gmail.com:
 #2) sounds neat, but maybe Janek (who has spent some time messing
 around with flags) wants to weigh in.
 
 As i've said in a private mail to Mike, i don't have anything against doing 
 so.
 
 Mike, i understand that your patch changes some beams.  I'd like to
 check what effect does it have on my scores, but i'm not sure if i can
 do it now or rather should i wait until flag grob is pushed.

You can check it now - the flag grob won't really have an effect, and will 
break the patch until I upload a new set.

 I also
 don't understand what '\override Stem #'stencil = #(lambda (grob) ...'
 is about.

Where was this lambda function talked about?

Cheers,
MS



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lilypond's SVG output

2011-08-24 Thread Marek Klein 
Hello,

2011/8/18 Sandor Spruit a.g.l.spr...@uu.nl


 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 scores on web pages, and they
 immediately
 referred to Lilypond because of its quality output. While browsing this
 list's archives, and
 other on-line discussions for that matter, two questions came up:

 - In what version, exactly, did Lilypond drop the use of groups (svg:g) in
 its output?

   I read a debate on this issue, where the key argument against groups was
 the trouble
   people have in editing grouped SVG elements in Inkscape. I can, however,
 imagine all
   sorts of situations in which group elements could be very useful - from a
 developer's
   point of view at least. This leads to the second question:

 - For what purpose are people putting music up on the web; what's the
 typical use case?

   Just publishing it for others to read? Hyperlinking to it, from it?
 Annotations? Keeping
   bits and pieces of music for later reference? Learning? Studying?
 Comparing versions?

 I may, at some point, be in the position to do some work on this. But I'm
 hesitant to dive
 in at the deep end - meaning Lilypond tens of thousands of lines of code
 ...

 A bit of guidance might help though :)
 cheers,

 Sandor Spruit
 Information and Computing Sciences, Utrecht University

 __**_
 lilypond-user mailing list
 lilypond-u...@gnu.org
 https://lists.gnu.org/mailman/**listinfo/lilypond-userhttps://lists.gnu.org/mailman/listinfo/lilypond-user


I can not answer your questions, but maybe developers list is better place
to ask... forwarding.

Marek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Feta flag problem

2011-08-24 Thread Janek Warchoł 
2011/8/24 Mike Solomon mike...@ufl.edu:
 Hey all,

 I recently finished a new work for harpsichord and had forgotten about the 
 feta flag problem I reported before until I saw the printed output.

 On Mac OS X, the output looks good (see attached).

you mean the pdf?  It looks bad viewed on my Lilydev, for the record.

 The same output on my lilydev shows the problem (also see attached).

 When I sent the work to print (from a PC) the bad version came out.

 I know nothing about MetaFont, but could someone have a quick look at the 
 downstemtriple function and see if anything strikes them as being odd?

I've run into similar problems when i was working at flag stuff.  It
turned out that it wasn't metafont's fault, but rather fontforge's,
which postprocesses metafont files.  Using latest fontforge for
building Lily always solved these problems for me.

HTH,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread Ian Hulin 
Hi  Graham, Carl,

On Tue 23 Aug 2011 19:34:37 BST, Carl Sorensen wrote:
 On 8/23/11 12:21 PM, ianhuli...@gmail.com ianhuli...@gmail.com wrote:
 
 LGTM

 Maybe we should have some GOP rules for C++ about this?
 Only have multiple exit points from routines if you absolutely have to.
 
 Multiple exit points is a standard idiom of the LilyPond code.  Basically,
 the idiom is If this routine doesn't apply for some reason, leave now,
 instead of If this routine doesn't apply, skip to the end or If this
 routine applies, do the body.
 
 As imbedded as this idiom is in our code, I don't think it would be wise to
 change it.
 
... a sort of legal precedent argument.  Just because it's precedent, 
doesn't make it right.
leave now is an optimisation: it means you're assuming everything is 
safe and you know for certain that the code you have executed up to the 
point of exit *including any routines it has called* has done no harm.
Branching to a final single exit point allows you to clean up any 
side-effects/damage/half-completed stuff your code changed thus far.
Current practice didn't work in this case.  

I'm not asking for a grand re-write on this, but for single-exit to be 
the preferred style for new code and patches where this would not 
provoke changes on a GCR (Grand Code Re-write) scale.

 Make sure any output parameters are declared and initialized at the top
 of a routine so that however a routine exits, they are left in a defined
 state
 
 IIRC, we used to have a statement that said to declare variables as close as
 possible to where they are used.  I generally agree with that.
 
 However, I think a simple statement that says variables should be
 initialized when they are declared would be clearly welcome.  And fixes to
 the code to ensure this would also be welcome.
 
OK, maybe take the point above as a stylistic preference.  

Declaring variables nearest to where they are used + insisting they are 
initialised may work, providing we spell it out the if they are 
declared as parameters to the routine, that's the first place they're 
used, so if they're output parameters, they need to be initialized 
either at the top of the routine, or in the parameter declaration.

Tightening up this statement may do the trick.  We need to feed back 
things we pick up on like this into the development/reviewing process.

Cheers,
Ian


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread David Kastrup 
Ian Hulin ianhuli...@gmail.com writes:

 I'm not asking for a grand re-write on this, but for single-exit to be
 the preferred style for new code and patches where this would not
 provoke changes on a GCR (Grand Code Re-write) scale.

I disagree.  Structured exits decrease the level of nesting and
contortion and make code more straightforward to follow.

if (!precondition)
  {
 return 0;
  }
// Do the real work, 200+ lines of code, 5 levels of nesting
return zappa (whatever);

is much much more cleaner to follow than

zappadap result;

if (precondition)
  {
 // Do the real work, 200+ lines of code, 5 levels of nesting
 result = zappa (whatever);
  }
else
  {
 result = 0;
  }
return result;


Get the trivial cases out of the way, completely, first.  That way, you
don't need to keep yellow tabs on braces to track even the trivial code.
Write and read code like a man!  Juggling a dozen open ends at once is
the special skillset of childraisers, not programmers.  And if you do
both at once, you'll be glad you don't need to track large contexts even
for the trivial tasks, when you have a spare minute for programming.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread Reinhold Kainhofer 
Am Wednesday, 24. August 2011, 10:49:30 schrieben Sie:
 Hi  Graham, Carl,
 
 On Tue 23 Aug 2011 19:34:37 BST, Carl Sorensen wrote:
  On 8/23/11 12:21 PM, ianhuli...@gmail.com ianhuli...@gmail.com wrote:
  Maybe we should have some GOP rules for C++ about this?
  Only have multiple exit points from routines if you absolutely have to.

There is really not much difference in

if (some_condition)
  return;

and

if (!some_condition)
  {

  }

Except that if you have many conditions the indentation in the second example 
will be terrible and make the whole thing hard to read.

You can mess up equally with both.

 Declaring variables nearest to where they are used + insisting they are
 initialised may work, providing we spell it out the if they are
 declared as parameters to the routine, that's the first place they're
 used, so if they're output parameters, they need to be initialized
 either at the top of the routine, or in the parameter declaration.

Please note that in this case we are talking about a function that is expected 
to modify its arguments, this is NOT about variable declarations. These 
variables, passed-by-reference, should be initialized as soon as possible.

For variable declarations, of course I'm all for moving the declaration 
immediately before the first use.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-08-24 Thread Janek Warchoł 
2011/8/24 Mike Solomon mike...@ufl.edu:
 On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote:

 2011/8/16 Han-Wen Nienhuys hanw...@gmail.com:
 #2) sounds neat, but maybe Janek (who has spent some time messing
 around with flags) wants to weigh in.

 As i've said in a private mail to Mike, i don't have anything against doing 
 so.

 Mike, i understand that your patch changes some beams.  I'd like to
 check what effect does it have on my scores, but i'm not sure if i can
 do it now or rather should i wait until flag grob is pushed.

 You can check it now - the flag grob won't really have an effect, and will 
 break the patch until I upload a new set.

 I also
 don't understand what '\override Stem #'stencil = #(lambda (grob) ...'
 is about.

 Where was this lambda function talked about?

In your first mail,
http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00572.html

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-08-24 Thread Mike Solomon 

On Aug 24, 2011, at 1:46 PM, Janek Warchoł wrote:

 2011/8/24 Mike Solomon mike...@ufl.edu:
 On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote:
 
 2011/8/16 Han-Wen Nienhuys hanw...@gmail.com:
 #2) sounds neat, but maybe Janek (who has spent some time messing
 around with flags) wants to weigh in.
 
 As i've said in a private mail to Mike, i don't have anything against doing 
 so.
 
 Mike, i understand that your patch changes some beams.  I'd like to
 check what effect does it have on my scores, but i'm not sure if i can
 do it now or rather should i wait until flag grob is pushed.
 
 You can check it now - the flag grob won't really have an effect, and will 
 break the patch until I upload a new set.
 
 I also
 don't understand what '\override Stem #'stencil = #(lambda (grob) ...'
 is about.
 
 Where was this lambda function talked about?
 
 In your first mail,
 http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00572.html
 
 cheers,
 Janek
 

Ah, I see.
These lambda functions allow you to see heights and/or pure heights next to the 
stems.  Throw them into a regtest with lots of stems (beamed and unbeamed), run 
it with current master, and then run it with my patch.  You'll see that the 
pure height approximations and the heights are more accurately represented w/ 
this patch (at least I think they are...I haven't yet heard any feedback to the 
contrary).

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

bug reports for valgrind warnings?

2011-08-24 Thread Reinhold Kainhofer 
I let valgrind run lilypond (both with optimization turned on and off) on all 
our regtests, and some of them (3-4) showed some warnings like invalid read 
access or uninitialized values. 

Shall I open a bug report for each regtest where valgrind shows a warning (the 
guile GC warnings are of course filtered out using a suppressions file)?

Some might really point to bugs (like the uninitialized variables that I fixed 
yesterday) or even to heisenbugs (which are not possible to track down, the 
more you narrow the area of the bug, the less you can reproduce it - you know, 
Heisenberg's uncertainty principle).

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread Dan Eble 
On 2011-08-24, at 05:10 , Reinhold Kainhofer wrote:

 Am Wednesday, 24. August 2011, 10:49:30 schrieben Sie:
 Hi  Graham, Carl,
 
 On Tue 23 Aug 2011 19:34:37 BST, Carl Sorensen wrote:
 On 8/23/11 12:21 PM, ianhuli...@gmail.com ianhuli...@gmail.com wrote:
 Maybe we should have some GOP rules for C++ about this?
 Only have multiple exit points from routines if you absolutely have to.
 
 There is really not much difference in
 
 if (some_condition)
  return;
 
 and
 
 if (!some_condition)
  {

  }
 
 Except that if you have many conditions the indentation in the second example 
 will be terrible and make the whole thing hard to read.


There can be a run-time performance difference between branching or not 
branching.  For the times you actually care, if you're not going to use 
compiler-specific features to mark conditions as likely or unlikely, you should 
test the likely case first so that there is no branching most of the time.

 You can mess up equally with both.

Some of us have. :-)

You can also write functions that are equally difficult to read with both.  The 
readability depends more on what is inside your ellipsis above than whether the 
unexpected condition is handled before or after it.
-- 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread David Kastrup 
Dan Eble d...@faithful.be writes:

 There can be a run-time performance difference between branching or
 not branching.  For the times you actually care, if you're not going
 to use compiler-specific features to mark conditions as likely or
 unlikely, you should test the likely case first so that there is no
 branching most of the time.

Modern compilers pay very little attention to how you arrange the source
code of equivalent constructs.

 You can also write functions that are equally difficult to read with
 both.

No.  Humans begin reading at the beginning and go forward from there.
There is a difference between having one case dealt with completely, and
having to keep it in mind while reading something else.

Basically you are saying juggling with one ball can be equally
difficult to juggling with two and conclude from that dubious premise
that juggling any number of balls is equally hard.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread Han-Wen Nienhuys 
On Tue, Aug 23, 2011 at 3:21 PM,  ianhuli...@gmail.com wrote:
 LGTM

 Maybe we should have some GOP rules for C++ about this?

Can we not? Professionally, I work with an enormous style guide, and
having a lot of style prescribed needlessly complicates code reviews,
because it makes people hammer on unimportant syntactical details.

We could adopt the following GOP rule about writing functions:

 Use your brain when you write and arrange a function.


-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix memleak: temporary skyline objects for systems were never deleted (issue 4923048)

2011-08-24 Thread Han-Wen Nienhuys 
On Wed, Aug 24, 2011 at 3:38 AM, David Kastrup d...@gnu.org wrote:
 reinhold.kainho...@gmail.com writes:

 Reviewers: ,

 Message:
 This patch fixes a memleak: Some temporary skylines were never
 deleted...
 Please review

 Description:
 Fix memleak: temporary skyline objects for systems were never deleted

 Please review this at http://codereview.appspot.com/4923048/

 Affected files:
    M lily/skyline.cc


 Index: lily/skyline.cc
 diff --git a/lily/skyline.cc b/lily/skyline.cc
 index
 b6ea6b791bbbfa09aaa28e91da0a619c33085890..8f62710b0947fa8e48ffcbc7e181cba4709c96de
 100644
 --- a/lily/skyline.cc
 +++ b/lily/skyline.cc
 @@ -514,6 +514,7 @@ Skyline::distance (Skyline const other, Real
 horizon_padding) const

     Skyline const *padded_this = this;
     Skyline const *padded_other = other;
 +  bool created_tmp_skylines = false;

     /*
       For systems, padding is not added at creation time.  Padding is
 @@ -525,6 +526,7 @@ Skyline::distance (Skyline const other, Real
 horizon_padding) const
       {
         padded_this = new Skyline (*padded_this, horizon_padding, X_AXIS);
         padded_other = new Skyline (*padded_other, horizon_padding, X_AXIS);
 +      created_tmp_skylines = true;
       }

     listBuilding::const_iterator i = padded_this-buildings_.begin ();
 @@ -544,6 +546,13 @@ Skyline::distance (Skyline const other, Real
 horizon_padding) const
           j++;
         start = end;
       }
 +
 +  if (created_tmp_skylines)
 +    {
 +      delete padded_this;
 +      delete padded_other;
 +    }
 +
     return dist;
   }

 Skylines are smobs.  The usual way to delete them would be to unprotect
 them once they have been registered by some garbage-collectable object
 (or a SCM variable that is being used for accessing them).

They are simple smobs, though, so this pattern here is not uncommon.
You could also try to allocate them on the stack.

--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix memleak: temporary skyline objects for systems were never deleted (issue 4923048)

2011-08-24 Thread David Kastrup 
Han-Wen Nienhuys hanw...@gmail.com writes:

 Skylines are smobs.  The usual way to delete them would be to
 unprotect them once they have been registered by some
 garbage-collectable object (or a SCM variable that is being used for
 accessing them).

 They are simple smobs, though, so this pattern here is not uncommon.
 You could also try to allocate them on the stack.

I think it would make me less uncomfortable than using explicit delete.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Broken beams' slopes

2011-08-24 Thread Mike Solomon 
Hey all,

I'll be leaving on vacation in a week-ish, and as my summer-of-lily comes to a 
close, I can likely do one more medium-scale thing before I have to start 
correcting parallel fifths.
I'd like to work on broken beam slopes such that a beam can break across lines 
and pick up where it left off at the same slope and y-offset

The approach would be:

1)  Get rid of the chained callbacks to calculate Beam #'position.
2)  Work on the Beam_scoring_problem class such that it does everything that 
all of the chained callbacks used to do.
3)  Make the calculations in Beam_scoring_problem such that they always unfold 
in a coordinate space where the origin is at the X and Y offset of the first 
normal stem (the latter of which should, aside from really esoteric cases, 
always be 0.0).

This way, it is relatively trivial to tack on information from extra systems 
(or not) - grobs on subsequent systems have their x-displacement added onto the 
combined spanner lengths of previous systems plus the tiny part of the broken 
beam between its left bound and the first stem on a new system.

I estimate that this will take me two days of work, so please respond in the 
next 48ish hours if you think this is a bad idea.  Otherwise, I'm gonna give it 
a go.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken beams' slopes

2011-08-24 Thread David Kastrup 
Mike Solomon mike...@ufl.edu writes:

 Hey all,

 I'll be leaving on vacation in a week-ish, and as my summer-of-lily
 comes to a close, I can likely do one more medium-scale thing before I
 have to start correcting parallel fifths.
 I'd like to work on broken beam slopes such that a beam can break
 across lines and pick up where it left off at the same slope and
 y-offset

The problem I see with this approach is that one does not, in general,
want the same slope and y-offset because it does not make sense to view
the broken beam as a single visual entity.  Creating a single visual
entity often means compromises like having over-long or -short stems in
between.  When in between moves right adjacent to the break, you don't
want the stems there to be overlong and overshort just to make y
positions match those of the next line.  The next line is far away.

So you will generally want to preserve the beam slope roughly, and
preferably the beam orientation.  That means that if the unbroken beam
would have a _knee_ at the break, you would, when splitting it, tend to
prefer _unkneed_ beams with similar slope, even though that would mean a
significant jump in y-offset.  But that makes the visual connection
easier to make than a jump in beaming direction.

So thea esthetic decisions need to work under different constraints than
in the unbroken case.

We have the same almost, but not quite as if unbroken situation with
slurs and ties.  And it does not just occur with line breaks, but also
in connection with repeats and da capo.

Do we have a sound general strategy for tackling this sort of controlled
discontinuity?  Maybe it would be worth thinking about.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken beams' slopes

2011-08-24 Thread Mike Solomon 
On Aug 24, 2011, at 5:42 PM, David Kastrup wrote:

 Mike Solomon mike...@ufl.edu writes:
 
 Hey all,
 
 I'll be leaving on vacation in a week-ish, and as my summer-of-lily
 comes to a close, I can likely do one more medium-scale thing before I
 have to start correcting parallel fifths.
 I'd like to work on broken beam slopes such that a beam can break
 across lines and pick up where it left off at the same slope and
 y-offset
 
 The problem I see with this approach is that one does not, in general,
 want the same slope and y-offset because it does not make sense to view
 the broken beam as a single visual entity.

All the pdfs associated with my response are up at 
http://www.apollinemike.com/response_to_david

See chords2.pdf versus chords.pdf.  In chords.pdf, I use an override to make 
all beams flat.  In chords2.pdf, I remove this override and let lily run her 
course.  I think that, in chords2.pdf, the disparity in slopes across line 
breaks makes for really ugly typsetting.  I would much rather have long stems 
and continuity than more even stems and divergent slopes.

 Creating a single visual
 entity often means compromises like having over-long or -short stems in
 between.  When in between moves right adjacent to the break, you don't
 want the stems there to be overlong and overshort just to make y
 positions match those of the next line.  The next line is far away.

In the case of beams, I actually think people often want this.  Check out 
measure 6 of broken.pdf.  I would gladly take a long stem before the line break 
(the same length, for example, as that of the D natural in the previous beam) 
such that the slope and Y-offset are continuous.  I think that it is important 
to make a scorer that can work on a per-line or all-line basis (like the one 
I'm proposing) so that people can decide between the two with a property (Beam 
#'preserve-slop-across-line-breaks).

 
 So you will generally want to preserve the beam slope roughly, and
 preferably the beam orientation.

I think that in the included PDFs, even roughly wouldn't work (I haven't tried 
though) - as a performer, especially at fast tempos, the consistency of slope 
would actually help me anticipate what is coming after the line break so that 
my hands can move in the right direction.

 That means that if the unbroken beam
 would have a _knee_ at the break, you would, when splitting it, tend to
 prefer _unkneed_ beams with similar slope, even though that would mean a
 significant jump in y-offset.

Agreed.

 But that makes the visual connection
 easier to make than a jump in beaming direction.
 

Agreed.

 So thea esthetic decisions need to work under different constraints than
 in the unbroken case.
 

Agreed.

 We have the same almost, but not quite as if unbroken situation with
 slurs and ties.  And it does not just occur with line breaks, but also
 in connection with repeats and da capo.
 

True, but I think these grobs are different because they hover over or under 
early columns like clefs and key signatures, whereas beams start after these 
columns.  This allows beam continuity to be a lot better, as it does not have 
to compete with the presence of a giant clef at the beginning of the barline 
that would cause its y-offset to be very high or low.

 Do we have a sound general strategy for tackling this sort of controlled
 discontinuity?  Maybe it would be worth thinking about.
 

Not really, although I'm way for this (my vector graphics spanner does this 
sorta thing).

I think implementing this type of continuity for beams may be a good test case 
from which a general strategy (if appropriate) can be extrapolated and applied 
elsewhere.

Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: bug reports for valgrind warnings?

2011-08-24 Thread Graham Percival 
On Wed, Aug 24, 2011 at 02:08:41PM +0200, Reinhold Kainhofer wrote:
 Shall I open a bug report for each regtest where valgrind shows a warning 
 (the 
 guile GC warnings are of course filtered out using a suppressions file)?

I wouldn't be surprised if you get some duplicate bugs, though --
I mean, if there was one line in the slur code that produced a
memory error, I'd expect it to show up in dozens of regtests.
I definitely want to see all valgrind-reported bugs fixed (or at
least, explained why it's a false positive), but I'm not certain
that reporting bugs for every regtest is the best way.

Instead, could you post your suppression file and command-line (or
add it to the CG?), so that other people can easily see those
errors?  Then maybe we can have a few people each working on
different regtests.  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken beams' slopes

2011-08-24 Thread David Kastrup 
Mike Solomon mike...@ufl.edu writes:

 On Aug 24, 2011, at 5:42 PM, David Kastrup wrote:

 Mike Solomon mike...@ufl.edu writes:
 
 I'll be leaving on vacation in a week-ish, and as my summer-of-lily
 comes to a close, I can likely do one more medium-scale thing before I
 have to start correcting parallel fifths.
 I'd like to work on broken beam slopes such that a beam can break
 across lines and pick up where it left off at the same slope and
 y-offset
 
 The problem I see with this approach is that one does not, in general,
 want the same slope and y-offset because it does not make sense to view
 the broken beam as a single visual entity.

 See the attached chords2.pdf versus chords.pdf.  In chords.pdf, I use
 an override to make all beams flat.  In chords2.pdf, I remove this
 override and let lily run her course.  I think that, in chords2.pdf,
 the disparity in slopes across line breaks makes for really ugly
 typsetting.

Agreed.

 I would much rather have long stems and continuity than more even
 stems and divergent slopes.

But the continuity demands are less stringent across the break.  You can
fuzz with beam slope somewhat (things should likely stay rising,
straight, or falling, but the degree is likely more flexible than
without a break), and you can fuzz quite a bit with y position when
needed before you get negative returns.  Of course, without a good
reason there is no point to change either.  Being able to keep them
identical is a good start.  I am just pointing out that it is not the
optimum, and one should likely not try to lose sight of the optimum
entirely, even if it may not make it into code right away.

 That means that if the unbroken beam would have a _knee_ at the
 break, you would, when splitting it, tend to prefer _unkneed_ beams
 with similar slope, even though that would mean a significant jump in
 y-offset.

 Agreed.

 But that makes the visual connection easier to make than a jump in
 beaming direction.

 Agreed.

 So the aesthetic decisions need to work under different constraints
 than in the unbroken case.

 Agreed.

 We have the same almost, but not quite as if unbroken situation
 with slurs and ties.  And it does not just occur with line breaks,
 but also in connection with repeats and da capo.

 True, but I think these grobs are different because they hover over or
 under early columns like clefs and key signatures, whereas beams start
 after these columns.  This allows beam continuity to be a lot better,
 as it does not have to compete with the presence of a giant clef at
 the beginning of the barline that would cause its y-offset to be very
 high or low.

Agreed.  I guess we are in violent agreement.  Just wanted to be sure
that this point was not accidentally overlooked completely, possibly
making things harder to do better at a later point of time.

 Do we have a sound general strategy for tackling this sort of
 controlled discontinuity?  Maybe it would be worth thinking about.
 

 Not really, although I'm way for this (my vector graphics spanner does
 this sorta thing).

 I think implementing this type of continuity for beams may be a good
 test case from which a general strategy (if appropriate) can be
 extrapolated and applied elsewhere.

Thanks for keeping an alert mind.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: bug reports for valgrind warnings?

2011-08-24 Thread Reinhold Kainhofer 
Am Mittwoch, 24. August 2011, 18:18:33 schrieben Sie:
 On Wed, Aug 24, 2011 at 02:08:41PM +0200, Reinhold Kainhofer wrote:
  Shall I open a bug report for each regtest where valgrind shows a warning
  (the guile GC warnings are of course filtered out using a suppressions
  file)?
 
 I wouldn't be surprised if you get some duplicate bugs, though --
 I mean, if there was one line in the slur code that produced a
 memory error, I'd expect it to show up in dozens of regtests.

You'd be surprised: With the --disable-optimising configure option, there are 
basically just two relevant warnings!

One in grid-lines.ly and one in laissez-vibrer-tie-beam.ly. I'm attaching my 
suppressions file and the output of valgrind.

I have the following alias in my ~/.bashrc (or rather in ~/.aliases, which I 
source from .bashrc):
alias valgrind-ly='valgrind --trace-children=yes --
suppressions=/home/reinhold/lilypond/guile_supp --track-origins=yes --num-
callers=25 lilypond '

Then call valgrind in input/regression/ as:
valgrind-ly grid-lines.ly laissez-vibrer-tie-beam.ly



There is, however, one caveat with the suppressions: Some uninitialized 
variables might be handled to guile (e.g. scm_from_int) and they will only 
show up as uninitialized variables in the garbage collection handling.

The (suppressed) output would then look something like:
»mozart-hrn-3.ly« wird verarbeitet
[...]
==14418== Use of uninitialised value of size 4
==14418==at 0x827C877: Stencil::mark_smob(scm_unused_struct*) 
(stencil.cc:54)
==14418==by 0x409F48B: scm_gc_mark (in /usr/lib/libguile.so.17.3.1)
==14418==by 0x409F639: scm_mark_locations (in /usr/lib/libguile.so.17.3.1)
==14418==by 0x40F6001: scm_threads_mark_stacks (in 
/usr/lib/libguile.so.17.3.1)
[...]
Text_interface::interpret_string(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:64)
==14418==by 0x8290045: 
Text_interface::interpret_markup(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:95)
[...]
==14418==  Uninitialised value was created by a stack allocation
==14418==at 0x828FA36: 
Text_interface::interpret_string(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:58)

I don't see whether in this case where are some uninitialized values in the 
lilypond code, though.


Such a case were the uninitialized variables that I fixed yesterday, which 
were immediately passed to scm_from_int and triggered the warning only in the 
GC. Unfortunately, most warnings in the GC are really from guile.



An optimized build basically gives basically the same warnings.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
{
   guile1
   Memcheck:Cond
   ...
   fun:scm_i_gc
}

{
   guile2
   Memcheck:Value4
   ...
   fun:scm_i_gc
}

{
   guile3
   Memcheck:Cond
   ...
   fun:scm_gc_mark
}

{
   guile4
   Memcheck:Value4
   ...
   fun:scm_gc_mark
}

{
   guile5
   Memcheck:Cond
   fun:scm_i_sweep_card
}

==28412== Memcheck, a memory error detector
==28412== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28412== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28412== Command: /home/reinhold/.bin/lilypond grid-lines.ly 
laissez-vibrer-tie-beam.ly
==28412== 
==28412== Memcheck, a memory error detector
==28412== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28412== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28412== Command: /home/reinhold/lilypond/lilypond/out/bin/lilypond --relocate 
grid-lines.ly laissez-vibrer-tie-beam.ly
==28412== 
GNU LilyPond 2.15.9
»grid-lines.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...==28412== Invalid read of size 4
==28412==at 0x8074823: 
Axis_group_interface::adjacent_pure_heights(scm_unused_struct*) 
(axis-group-interface.cc:254)
==28412==by 0x4090F18: scm_dapply (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x4097807: scm_apply (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x4099160: scm_call_1 (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x812748A: Grob::try_callback_on_alist(scm_unused_struct**, 
scm_unused_struct*, scm_unused_struct*) (grob-property.cc:227)
==28412==by 0x81271D6: Grob::internal_get_property(scm_unused_struct*) 
const (grob-property.cc:184)
==28412==by 0x8073D5A: 
Axis_group_interface::part_of_line_pure_height(Grob*, bool, int, int) 
(axis-group-interface.cc:147)
==28412==by 0x8073F23: 
Axis_group_interface::begin_of_line_pure_height(Grob*, int) 
(axis-group-interface.cc:171)
==28412==by 0x8073B6F: 
Axis_group_interface::sum_partial_pure_heights(Grob*, int, int) 
(axis-group-interface.cc:130)

Re: Fix memleak: temporary skyline objects for systems were never deleted (issue 4923048)

2011-08-24 Thread Reinhold Kainhofer 
Am Mittwoch, 24. August 2011, 15:38:21 schrieb Han-Wen Nienhuys:
 On Wed, Aug 24, 2011 at 3:38 AM, David Kastrup d...@gnu.org wrote:
  Skylines are smobs.  The usual way to delete them would be to unprotect
  them once they have been registered by some garbage-collectable object
  (or a SCM variable that is being used for accessing them).
 
 They are simple smobs, though, so this pattern here is not uncommon.
 You could also try to allocate them on the stack.

So, what do you think would be the appropriate fix for this memleak? 
I don't see how I could allocate the skylines on the stack just for the case 
of systems (notice that the new Skyline allocations are inside an if!). We 
don't want to allocate a new skyline for all Skyline::distance() calls, just 
for those, where the padding has not been added yet.

OTOH, I don't know anything about how guile is able to handle C++ class 
instances and how to tell it to delete a class instance allocated with new.


However, currently valgrind says the skyline memory is definitely lost:

==28530== 2,040 (24 direct, 2,016 indirect) bytes in 2 blocks are definitely 
lost in loss record 6,104 of 6,263
==28530==at 0x402641D: operator new(unsigned int) 
(vg_replace_malloc.c:255)
==28530==by 0x8234A28: Skyline::distance(Skyline const, double) const 
(skyline.cc:526)
==28530==by 0x81BCC8F: Page_layout_problem::append_system(System*, Spring 
const, double, double) (page-layout-problem.cc:496)
==28530==by 0x81BC37D: 
Page_layout_problem::Page_layout_problem(Paper_book*, scm_unused_struct*, 
scm_unused_struct*, int) (page-layout-problem.cc:411)
==28530==by 0x81ABCD8: 
Page_breaking::get_page_configuration(scm_unused_struct*, int, int, bool, 
bool) (page-breaking.cc:537)
==28530==by 0x81AC2B0: Page_breaking::make_pages(std::vectorunsigned int, 
std::allocatorunsigned int , scm_unused_struct*) (page-breaking.cc:617)
==28530==by 0x81A3891: Optimal_page_breaking::solve() (optimal-page-
breaking.cc:211)
==28530==by 0x81B9ADE: ly_optimal_breaking(scm_unused_struct*) (page-
breaking-scheme.cc:42)
==28530==by 0x4090F18: scm_dapply (in /usr/lib/libguile.so.17.3.1)


Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Memleaks or not?

2011-08-24 Thread Reinhold Kainhofer 
Running lilypond on a lot of files in one run, I observe that lilypond's 
memory usage slowly goes up with time, i.e. it seems that lilypond does not 
properly free all memory used for one score, before it starts with the next 
one. 

In particular, running lilypond on all 1010 regtests the output of ps is (as 
time goes on):
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
reinhold 28946  127  4.7 108432 97856 pts/3R+   19:27   0:01 lilypond 
reinhold 28946 74.4  5.4 121564 110988 pts/3   R+   19:27   0:18 lilypond 
reinhold 28946 72.6  5.9 137168 123036 pts/3   R+   19:27   0:39 lilypond 
reinhold 28946 73.4  6.4 151544 133308 pts/3   R+   19:27   0:59 lilypond 
reinhold 28946 73.8  6.7 159784 139320 pts/3   S+   19:27   1:11 lilypond 
reinhold 28946 72.1  8.1 199532 166512 pts/3   R+   19:27   1:54 lilypond 
reinhold 28946 72.6 11.2 271932 230260 pts/3   R+   19:27   2:28 lilypond 
reinhold 28946 72.0 12.0 316108 247232 pts/3   R+   19:27   2:56 lilypond
reinhold 28946 72.0 12.6 341956 259276 pts/3   R+   19:27   3:25 lilypond
...
reinhold 28946 72.1 15.4 423400 315956 pts/3   S+   19:27   5:35 lilypond
reinhold 28946 72.4 18.8 526744 387140 pts/3   R+   19:27   7:47 lilypond
reinhold 28946 72.5 27.9 747168 572740 pts/3   R+   19:27   9:59 lilypond


Using the memcheck tool of valgrind, there are some lost memory warnings that 
might be leaks. Can anyone confirm that these are really leaks?

However, the leaks reported by valgrind do not explain why lilypond's memory 
increases on average per regtest file by ~650kB VSZ and ~475kB RSS.

All valgrind warnings in this mail are obtained by running valgrind on just 
two files. Most of the reportedly lost memory numbers go up practically linear 
in the number of files processed.



1) In Pango_font::text_stencil we have
PangoLayout *layout = pango_layout_new (context_);
but after using the layout, we never call g_object_unref (layout).


==28530== 4,080 bytes in 2 blocks are possibly lost in loss record 6,178 of 
6,263
==28530==at 0x402517B: memalign (vg_replace_malloc.c:581)
==28530==by 0x40251D8: posix_memalign (vg_replace_malloc.c:709)
==28530==by 0x43B3546: ??? (in /lib/i386-linux-
gnu/libglib-2.0.so.0.2800.6)
==28530==by 0x43B4A4C: g_slice_alloc (in /lib/i386-linux-
gnu/libglib-2.0.so.0.2800.6)
==28530==by 0x43B4B74: g_slice_alloc0 (in /lib/i386-linux-
gnu/libglib-2.0.so.0.2800.6)
==28530==by 0x432C8C6: g_type_create_instance (in /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0.2800.6)
==28530==by 0x4309674: ??? (in /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0.2800.6)
==28530==by 0x430CCE6: g_object_newv (in /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0.2800.6)
==28530==by 0x430DA3F: g_object_new (in /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0.2800.6)
==28530==by 0x42224C5: pango_layout_new (in /usr/lib/i386-linux-
gnu/libpango-1.0.so.0.2800.4)
==28530==by 0x81D02D3: Pango_font::text_stencil(Output_def*, std::string, 
bool) const (pango-font.cc:312)
==28530==by 0x8292E68: 
Text_interface::interpret_string(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:79)
==28530==by 0x82932BE: 
Text_interface::interpret_markup(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:95)



2) In includable-lexer.cc we use
  yy_switch_to_buffer (yy_create_buffer (file-get_istream (), YY_BUF_SIZE));
and in Source_file::~Source_file we have delete istream_;. On the other 
hand, running valgrind with 2 and with 3 .ly files shows that the memory 
recorded as possibly lost really increases.
Still, valgrind reports:


==28530== 118,852 bytes in 18 blocks are possibly lost in loss record 6,257 of 
6,263
==28530==at 0x402641D: operator new(unsigned int) 
(vg_replace_malloc.c:255)
==28530==by 0x44B89F7: std::string::_Rep::_S_create(unsigned int, unsigned 
int, std::allocatorchar const) (in /usr/lib/i386-linux-
gnu/libstdc++.so.6.0.14)
==28530==by 0x44BAC33: char* std::string::_S_constructchar const*(char 
const*, char const*, std::allocatorchar const, std::forward_iterator_tag) 
(in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14)
==28530==by 0x44BAD20: std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::basic_string(char const*, unsigned int, 
std::allocatorchar const) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14)
==28530==by 0x44B2B27: std::basic_istringstreamchar, 
std::char_traitschar, std::allocatorchar 
::basic_istringstream(std::string const, std::_Ios_Openmode) (in 
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.14)
==28530==by 0x824A340: Source_file::get_istream() (source-file.cc:163)
==28530==by 0x8136886: Includable_lexer::new_input(std::string, Sources*) 
(includable-lexer.cc:93)
==28530==by 0x814B3A5: Lily_lexer::new_input(std::string, Sources*) (lily-
lexer.cc:269)
==28530==by 0x82D26AF: Lily_lexer::yylex() (lexer.ll:305)
==28530==by 0x82E4599: yylex(YYSTYPE*, Input*, void*)

limited access to e-mail

2011-08-24 Thread Janek Warchoł 
Hi all,

i am on choral workshops for a week.  I hope to be able to set up a
remote desktop to connect to my Lilydev-enabled machine and do some
work, but nevertheless my access to development process will be
limited.
Therefore please don't feel ignored if i answer only to some e-mails
for the time being.

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix memleak: temporary skyline objects for systems were never deleted (issue 4923048)

2011-08-24 Thread Han-Wen Nienhuys 
On Wed, Aug 24, 2011 at 10:57 AM, David Kastrup d...@gnu.org wrote:
 Han-Wen Nienhuys hanw...@gmail.com writes:

 Skylines are smobs.  The usual way to delete them would be to
 unprotect them once they have been registered by some
 garbage-collectable object (or a SCM variable that is being used for
 accessing them).

 They are simple smobs, though, so this pattern here is not uncommon.
 You could also try to allocate them on the stack.

 I think it would make me less uncomfortable than using explicit delete.

I don't think in the end neither choice matters very much; the stack
is also awkward, because the instantiation happens in a if(){}.  I
would probably write as follows

  Skyline *withpadding = 0;
  ...
  if ( .. )  {
 withpadding = new Skyline( .. )
  }

  delete withpadding;

this still has a leak-risk if someone adds a return in the middle. To
fix that, you'd have to use  something like Boost's scoped_ptr.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Deprecate \fermataMarkup for full-bar rests. (issue 4672059)

2011-08-24 Thread pkx166h 

passes make and reg tests

http://codereview.appspot.com/4672059/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Jan Nieuwenhuizen 
Pierre THIERRY writes:

[cc lilypond-devel]

 If memory serves, so far we have US$200, C$100 and €200. If I were to
 work alone on this bounty, that would allow me to allocate
 approximately 20hrs, which should clearly be enough to write a nice
 XML exporting in some schema mimicking Lilypond's representation, and
 probably also the XSLT transformation to MusicXML (I'm not sure how
 much time figuring it and then debugging it will take, it has been
 ages since I played with XSLT).

To fix this bug, what we need is a very clear bug report to know when we
can close it.  Actually, we require that for all bugs, so #665 should
never have been entered into the bug database like this.

What I would like to see attached to #665 is at least one .ly with
corresponding .xml with bonusses attached.

Possibly it's best to delay #665 and split it up into several different
issues (and attached bounties), each with it's own .ly -- and starting
with a most simple one.

It's only about an hour of work (see below) to convert a simple and
prepared .ly score to musicxml, see below.

Jan

From 8dd82d867fcf9b7b9a554016de02109ab6486a0c Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen jann...@gnu.org
Date: Wed, 24 Aug 2011 15:46:34 +0200
Subject: [PATCH 1/3] [MusicXML]: Hello world xslt stylesheet for MusicXML output.

---
 xml/GNUmakefile |2 ++
 xml/test-1.xml  |   28 
 xml/to-xml.html |   17 +
 xml/xml.ly  |   16 
 xml/xml.xml |   38 ++
 5 files changed, 101 insertions(+), 0 deletions(-)
 create mode 100644 xml/GNUmakefile
 create mode 100644 xml/test-1.xml
 create mode 100644 xml/to-xml.html
 create mode 100644 xml/xml.ly
 create mode 100644 xml/xml.xml

diff --git a/xml/GNUmakefile b/xml/GNUmakefile
new file mode 100644
index 000..83d803c
--- /dev/null
+++ b/xml/GNUmakefile
@@ -0,0 +1,2 @@
+test:
+	xsltproc to-xml.html test-1.xml 
\ No newline at end of file
diff --git a/xml/test-1.xml b/xml/test-1.xml
new file mode 100644
index 000..3c33cc8
--- /dev/null
+++ b/xml/test-1.xml
@@ -0,0 +1,28 @@
+music
+NoteEvent
+pitch
+   octave=1
+   notename=0
+   alteration=0
+/pitch
+duration
+   log=2
+   dots=0
+   numer=1
+   denom=1
+/duration
+/NoteEvent
+NoteEvent
+pitch
+   octave=2
+   notename=1
+   alteration=0
+/pitch
+duration
+   log=2
+   dots=0
+   numer=1
+   denom=1
+/duration
+/NoteEvent
+/music
\ No newline at end of file
diff --git a/xml/to-xml.html b/xml/to-xml.html
new file mode 100644
index 000..f1da85a
--- /dev/null
+++ b/xml/to-xml.html
@@ -0,0 +1,17 @@
+?xml version=1.0 encoding=ISO-8859-1?
+xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+
+  xsl:template match=/
+xml
+  score-partwise
+	xsl:for-each select=music
+	  xsl:for-each select=NoteEvent
+	pitchxsl:value-of select=pitch/
+	  octavexsl:value-of select=pitch//octave
+	/pitch
+	  /xsl:for-each
+	/xsl:for-each
+  /score-partwise
+/xml
+  /xsl:template
+/xsl:stylesheet
diff --git a/xml/xml.ly b/xml/xml.ly
new file mode 100644
index 000..2ade547
--- /dev/null
+++ b/xml/xml.ly
@@ -0,0 +1,16 @@
+\version 2.14.0
+
+testMusic =  {  c''4 \\ g'4  }
+
+#(use-modules (scm to-xml))
+
+#(ly:progress \nXML:\n\n~A\n (call-with-output-string (lambda (p) (music-to-xml testMusic p
+
+
+\header {
+  texidoc =
+  The input representation is generic, and may be translated to XML. 
+}
+
+
+{ \testMusic }
diff --git a/xml/xml.xml b/xml/xml.xml
new file mode 100644
index 000..12ca68a
--- /dev/null
+++ b/xml/xml.xml
@@ -0,0 +1,38 @@
+music
+   type=score
+SequentialMusic
+SimultaneousMusic
+EventChord
+NoteEvent
+pitch
+   octave=1
+   notename=0
+   alteration=0
+/pitch
+duration
+   log=2
+   dots=0
+   numer=1
+   denom=1
+/duration
+/NoteEvent
+/EventChord
+VoiceSeparator
+/VoiceSeparator
+EventChord
+NoteEvent
+pitch
+   octave=0
+   notename=4
+   alteration=0
+/pitch
+duration
+   log=2
+   dots=0
+   numer=1
+   denom=1
+/duration
+/NoteEvent
+/EventChord
+/SimultaneousMusic
+/SequentialMusic/music
-- 
1.7.4.1

From ec8bf2adb089f4c1c38462afc1e8ec3fb0e33a60 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen jann...@gnu.org
Date: Wed, 24 Aug 2011 15:58:33 +0200
Subject: [PATCH 2/3] [MusicXML]: use apply-templates.

---
 xml/to-xml.html |   35 ---
 1 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/xml/to-xml.html b/xml/to-xml.html
index f1da85a..3768641 100644
--- a/xml/to-xml.html
+++ b/xml/to-xml.html
@@ -4,14 +4,35 @@
   xsl:template match=/
 xml
   score-partwise
-	xsl:for-each select=music
-	  xsl:for-each select=NoteEvent
-	pitchxsl:value-of select=pitch/
-	  octavexsl:value-of select=pitch//octave
-	/pitch
-	  /xsl:for-each
-	/xsl:for-each
+	xsl:apply-templates/
   /score-partwise
 /xml
   /xsl:template
+
+
+  xsl:template match=EventChord
+xsl:apply-templates/
+  /xsl:template
+
+  xsl:template match=NoteEvent

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Michael Ellis 
On Wed, Aug 24, 2011 at 5:14 PM, Jan Nieuwenhuizen jann...@gnu.org wrote:

 Pierre THIERRY writes:

 [cc lilypond-devel]

  If memory serves, so far we have US$200, C$100 and €200. If I were to
  work alone on this bounty, that would allow me to allocate
  approximately 20hrs, which should clearly be enough to write a nice
  XML exporting in some schema mimicking Lilypond's representation, and
  probably also the XSLT transformation to MusicXML (I'm not sure how
  much time figuring it and then debugging it will take, it has been
  ages since I played with XSLT).

 To fix this bug, what we need is a very clear bug report to know when we
 can close it.  Actually, we require that for all bugs, so #665 should
 never have been entered into the bug database like this.

 What I would like to see attached to #665 is at least one .ly with
 corresponding .xml with bonusses attached.

 Possibly it's best to delay #665 and split it up into several different
 issues (and attached bounties), each with it's own .ly -- and starting
 with a most simple one.

 It's only about an hour of work (see below) to convert a simple and
 prepared .ly score to musicxml, see below.

 Jan



That sounds encouraging.  So how far away are we from being able to handle a
more realistic score, say a string quartet or a 4-part choral score with
with lyrics and piano reduction?

Cheers,
Mike
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue 4837050)

2011-08-24 Thread pkx166h 

On 2011/08/08 22:09:09, Trevor Daniels wrote:

LGTM
Although I'm not sure about editing the other language files.  Best

wait for

Francisco to comment.


Francisco, can you tell me if this patch is ok to go as I have touched
some of the translated docs to remove this snippet.

Thanks



http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GOP-PROP 10: scheme indentation (probable decision)

2011-08-24 Thread Neil Puttock 
On 24 August 2011 22:26, Graham Percival gra...@percival-music.ca wrote:
 No complaints from last time, with the possible exception of Neil
 wanting a different behavior for (else...)

I haven't had time to test it thoroughly since my last comments, but
there are some other issues which will need fixing before we can apply
it globally (e.g., handling of comments, several missing special
cases).  I hope to have time to do some more testing at the weekend,

Cheers,
Neil

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue 4837050)

2011-08-24 Thread pkx166h 

On 2011/08/08 22:09:09, Trevor Daniels wrote:

LGTM
Although I'm not sure about editing the other language files.  Best

wait for

Francisco to comment.


Francisco, can you tell me if this patch is ok to go as I have touched
some of
the translated docs to remove this snippet.

Thank

http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Creates a Flag grob. (issue 4922042)

2011-08-24 Thread n . puttock 


http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc
File lily/flag.cc (right):

http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc#newcode147
lily/flag.cc:147: what style of flag glyph is typeset on a
 what

http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc#newcode148
lily/flag.cc:148: @code{Stem}.  Valid options include @code{'()}
 @code{Stem}.

http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc#newcode149
lily/flag.cc:149: for standard flags, @code{'mensural} and
 for

http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc#newcode150
lily/flag.cc:150: @code{'no-flag}, which switches off the flag.,
 @code{'no-flag}

http://codereview.appspot.com/4922042/diff/17001/lily/flag.cc#newcode154
lily/flag.cc:154: stem 
unused

http://codereview.appspot.com/4922042/diff/17001/lily/stem-engraver.cc
File lily/stem-engraver.cc (right):

http://codereview.appspot.com/4922042/diff/17001/lily/stem-engraver.cc#newcode191
lily/stem-engraver.cc:191: if (scm_is_string (get_property
(whichBar)))
doc whichBar as read property

http://codereview.appspot.com/4922042/diff/17001/lily/stem.cc
File lily/stem.cc (left):

http://codereview.appspot.com/4922042/diff/17001/lily/stem.cc#oldcode1110
lily/stem.cc:1110: flag 
restore

http://codereview.appspot.com/4922042/diff/17001/ly/engraver-init.ly
File ly/engraver-init.ly (right):

http://codereview.appspot.com/4922042/diff/17001/ly/engraver-init.ly#newcode678
ly/engraver-init.ly:678: (Voice Flag font-size -3)
also add to make-voice-props-set

http://codereview.appspot.com/4922042/diff/17001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (left):

http://codereview.appspot.com/4922042/diff/17001/scm/define-grob-properties.scm#oldcode275
scm/define-grob-properties.scm:275: (flag ,ly:stencil? A function
returning the full flag stencil
move to internal properties and change type-predicate and docstring,
e.g.,

(flag ,ly:grob? A pointer to a @code{Flag} object.)

http://codereview.appspot.com/4922042/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Reinhold Kainhofer 
Am Wednesday, 24. August 2011, 23:33:02 schrieb Michael Ellis:
 On Wed, Aug 24, 2011 at 5:14 PM, Jan Nieuwenhuizen jann...@gnu.org wrote:
  It's only about an hour of work (see below) to convert a simple and
  prepared .ly score to musicxml, see below.
 
 That sounds encouraging.  So how far away are we from being able to handle
 a more realistic score, say a string quartet or a 4-part choral score with
 with lyrics and piano reduction?

I don't think it's that easy, in particular if you want to get output that you 
can send to a publisher without being thrown out of the office... 

Jan, you can take a look at the ~100 MusicXML files in 
input/regression/musicxml/ and at the corresponding output of musicxml2ly. 

The current approach is to modify the source file to add a \convertToMusicXML 
(or some similarly named function) to the music expression that you want to 
convert.
However, I see several problems with this approach, which I might discuss 
separately. In short, the only way to make it extendable for the future (so 
that one day we can also export the layout) is to handle (MusicXML) export 
similar to MIDI generation, namely via translators that collect all events and 
all settings as they appear in the score.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Kieren MacMillan 
Hi all,

 In short, the only way to make it extendable for the future (so 
 that one day we can also export the layout) is to handle (MusicXML) export 
 similar to MIDI generation, namely via translators that collect all events 
 and 
 all settings as they appear in the score.

+1.
KMac.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Michael Ellis 
On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan 
kieren_macmil...@sympatico.ca wrote:

 Hi all,

  In short, the only way to make it extendable for the future (so
  that one day we can also export the layout) is to handle (MusicXML)
 export
  similar to MIDI generation, namely via translators that collect all
 events and
  all settings as they appear in the score.

 +1.
 KMac.


This makes sense.  A standalone converter would, essentially, have to
duplicate Lily's internal logic.  Why write the same code twice?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Carl Sorensen 
On 8/24/11 5:31 PM, Michael Ellis michael.f.el...@gmail.com wrote:

 
 On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan
 kieren_macmil...@sympatico.ca wrote:
 Hi all,
 
 In short, the only way to make it extendable for the future (so
 that one day we can also export the layout) is to handle (MusicXML) export
 similar to MIDI generation, namely via translators that collect all events
  and
 all settings as they appear in the score.
 
 +1.
 KMac.
 
 
 This makes sense.  A standalone converter would, essentially, have to
 duplicate Lily's internal logic.  Why write the same code twice?


Hence the importance of Jan's original comment.  We need to clarify what is
wanted.

Do you want

1) XML that captures only the music (and could be imported into some other
program which will make the layout decisions)?

2) XML that captures both the music and the layout (and could therefore be
printed by some as-yet-unknown MusicXML printer)?

3) Some other XML that I haven't thought of?

My sense is that item 1) is relatively inexpensive (as Jan has discussed),
but that item 2) is relatively expensive (I think it's more than 100 expert
hours, but that's just a wild stab).

For me, item 1) is what we ought to be aiming at, at least initially.  It
seems strange to use Finale to print a layout defined by LilyPond.  If you
want to use a LilyPond layout and tweak a few things graphically, you should
be using the svg output, IMO, and editing the svg.

I think that holding out for 2) will probably delay completion of 1).

But having a well-defined enhancement request will at least allow a
developer to make a decision as to what they wish to attempt.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Kieren MacMillan 
Hi Carl,

 Do you want
 
 1) XML that captures only the music (and could be imported into some other
 program which will make the layout decisions)?

No: this is trivial to obtain from #2 or #3, via XSLT.

 2) XML that captures both the music and the layout (and could therefore be
 printed by some as-yet-unknown MusicXML printer)?

Yes: since Lilypond already generates this entire set of data, why not include 
it in the output?

 My sense is that item 1) is relatively inexpensive (as Jan has discussed),
 but that item 2) is relatively expensive (I think it's more than 100 expert
 hours, but that's just a wild stab).

Maybe true… but that's what we should be going for, IMO.

 For me, item 1) is what we ought to be aiming at, at least initially.

My question is this: In what format is the final, typeset music stream such 
that extracting the music information only would be massively easier than 
extracting the music and layout information?

 It seems strange to use Finale to print a layout defined by LilyPond.  If you
 want to use a LilyPond layout and tweak a few things graphically, you should
 be using the svg output, IMO, and editing the svg.

I think there are many things in the cracks that don't come through with just 
the music, but would be critical for translation to another program — for 
example, the cross-staff information that started this thread is clearly layout 
related, and not just music-specific.

 I think that holding out for 2) will probably delay completion of 1).

Possibly… If we're talking about 10 hours for #1 (truly well done) and 500 
hours for #2, then of course we should do that. If we're talking about 100 
hours for #1, and 250 hours for #2 where the first 100 hours must be redone 
(assuming, for argument's sake, the two are radically different in execution), 
then I would say no.

 But having a well-defined enhancement request will at least allow a
 developer to make a decision as to what they wish to attempt.

+1.
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread David Kastrup 
Kieren MacMillan kieren_macmil...@sympatico.ca writes:

 Do you want
 
 1) XML that captures only the music (and could be imported into some other
 program which will make the layout decisions)?

 No: this is trivial to obtain from #2 or #3, via XSLT.

You are using trivial like a mathematician, strictly interchangeable
with doable.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Carl Sorensen 
On 8/24/11 6:00 PM, Kieren MacMillan kieren_macmil...@sympatico.ca
wrote:

 Hi Carl,
 
 
 My question is this: In what format is the final, typeset music stream such
 that extracting the music information only would be massively easier than
 extracting the music and layout information?
 

I don't believe there *is* a final, typeset music stream.  There is an input
.ly code stream, which is converted to a stream-event stream.  The
stream-event stream generates a set of grobs.  The grobs generate stencils.
The stencils are printed on the page.

IIUC, grobs have information about their cause, but stencils do not.  And
there is not a one-to-one correspondence between stencils and music events.

For example, a chord made of three dotted quarter notes will generate three
note-head stencils, one stem stencil, and one dots stencil.  But as I read
it, the XML would require three note objects, each having its own dot
attribute.  And the only layout information for the dot is whether the dot
should be above or below the staff line.

Perhaps it's possible to merge these two distinct views.  But I think that
Reinhold is exactly right, and that the only way to do it extensibly is with
XML performers that will take stream events and convert them to XML.  But
how do we synchronize the performers and the engravers (which are setting
things up to make the layout decisions)?  That's the part I don't see right
now.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML exporter (was Re: Lilypond lobbying?)

2011-08-24 Thread Kieren MacMillan 
David,

 No: this is trivial to obtain from #2 or #3, via XSLT.
 You are using trivial like a mathematician, strictly interchangeable with 
 doable.

Actually, I was using trivial in two ways:
1. As a mathematician (yes, I've had several papers published in peer-reviewed 
journals), I was — as you noted — using it as a synonym for doable.
2. As a professional XSLT programmer (yes, some of my income comes from writing 
stylesheets), I was using it in the sense of extracting a strict subset of a 
XML tree is quite easy.

Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Nested context properties -- an implementation sketch

2011-08-24 Thread Reinhold Kainhofer 
Am Sunday 14 August 2011, 17:31:11 schrieb David Kastrup:
 a) a revert will only cancel the last _matching_ override, and the match
includes the complete specified property path, _and_ the prospective
use of \once.  \revert will not cancel \once\override and vice versa.
 b) At the end of a timestep, all \once\override are reverted.  All
non-\once overrides remain in effect and on the stack as if none of
the \once\override had ever happened.

That makes sense. Isn't this how it should have worked so far, too?

 I have no clear view about \set yet.  It would seem to me that \unset
 should be equivalent to \revert, and \set should be equivalent to
 \revert+\override.

 This is a change of existing semantics and will likely require changes
 to some Lilypond scores.  

Which cases exactly do change?

BTW, about \once\revert: Urs Liska's tutorial brought up a nice use of it.

\voiceOne [notes...] \once \revert Stem #'direction [...]

I.e. \voiceOne sets the direction of several grobs. If there is one note where 
you want one of the grobs return to the default setting, \once\revert is the 
best solution. Otherwise one would have to look up the default value in the 
IR, explicitlly override it and hope that the default will never change in the 
future (because then this will break completely).

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
 * LilyPond music typesetting software, http://www.lilypond.org/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: 48-hour countdown to 20:00 MDT 20110826

2011-08-24 Thread Colin Campbell 

For Friday, August 26 (and where did the Summer go?)

Issue 509 http://code.google.com/p/lilypond/issues/detail?id=509: 
collision nested tuplet numbers - R Issue 4808082 
http://codereview.appspot.com/4808082/: Prevents nested tuplets from 
colliding.


Issue 1328 http://code.google.com/p/lilypond/issues/detail?id=1328: 
Slurs collides with fermata - R Issue 4860042 
http://codereview.appspot.com/4860042/: Does better polynomial 
calculations for avoid objects.


Issue 1816 http://code.google.com/p/lilypond/issues/detail?id=1816: 
Lilypond-book music runs off right side of the page - R Issue 4888046 
http://codereview.appspot.com/4888046/: Fix 1816: Lilypond-Book:


Issue 1735 http://code.google.com/p/lilypond/issues/detail?id=1735: 
modifying default behaviour of tremolo slashes - R Issue 4636081 
http://codereview.appspot.com/4636081/: modifying default behaviour of 
tremolo slashes


Issue 1787 http://code.google.com/p/lilypond/issues/detail?id=1787: 
Hide ends of barlines inside staff lines. - R Issue 4809057 
http://codereview.appspot.com/4809057/: Ends of barlines are hidden in 
staff lines


Issue 1742 http://code.google.com/p/lilypond/issues/detail?id=1742: 
print transposed guitar chords on piano sheets - R Issue 4800051 
http://codereview.appspot.com/4800051/


Issue 1688 http://code.google.com/p/lilypond/issues/detail?id=1688: 
New half-closed hihat symbol for drum mode - R Issue 4714043 
http://codereview.appspot.com/4714043/


Of the 14 patches for review, 6 are less than 48 hours old and too young 
to be on this list, and the oldest of those above is Aug. 9, the rest 
being within the last 4 days.  Great work, developers!


Cheers,
Colin
--

The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix uninitialized variables when Source_file::get_counts returns early due to !contains (pos_str0) (issue 4940047)

2011-08-24 Thread Dan Eble 
On 2011-08-24, at 09:25 , David Kastrup wrote:

 Modern compilers pay very little attention to how you arrange the source
 code of equivalent constructs.


My experience trying to finagle optimized code out of gcc was more than a year 
ago, and the compiler was probably a bit older than that (not much though--I 
remember it was upgraded shortly before I was given the assignment).

I see in the documentation for gcc 4.7.0 that by default it tries to guess the 
probability of branching, so it seems you are right about 'modern' compilers 
(one of them anyway).  What a difference a few years makes.

Thanks for the lesson,
-- 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel