Re: git repository for osx-lilypond

[Janek Warchoł]

Carl,

2012/2/11 Carl Sorensen c_soren...@byu.edu:
 I'm trying to see if it's possible to keep support for OSX 10.4, and at
 the same time, have the proper version of lilypond shown in the About box.

You are _amazing_!  You do everything and help everyone.

 In order to try to track this down, I'd like to have a git history to see
 how things have changed. [...]
 Can anybody tell me where I might find an up-to-date repository?

repository of lilypad, you mean?  Maybe this will help:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/macos-lilypad
http://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00883.html

I think this is a lesson for us all.  It's a shame to waste Carl's
time on searching for source code; in my opinion we should keep as
much things as possible in one place.
Git-cl, for example: a patch was written for git-cl so that all
LilyPond-related codereviews on Rietveld can be seen in one place.
Yet few people use new git-cl.
It is possible to merge two repositories, for example add git-cl to
lilypond git repository *together with all commit history*.  I think
we should do this, i'll investigate how it's done.

cheers,
Janek

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

m...@apollinemike.com m...@apollinemike.com writes:

 On Feb 10, 2012, at 7:35 PM, David Kastrup wrote:

 m...@apollinemike.com m...@apollinemike.com writes:
 
 The problem is that the Pango API does not allow multiplication
 between two arbitrary matrices.
 
 Hm?  What's wrong with pango_matrix_concat ?


 Missed that.
 New dev/skylines-cached up that uses pango affine transforms.

Mike,

I really appreciate it that you let my probably sometimes excessive
sense of project aesthetics influence the direction your large creative
energy is taking.

I'll try taking a look later and see whether I can think of some things
that might be of more than cosmetic nature.  So far, the improvements on
your original approach have not been algorithmical: they are still doing
the same operations, just with less overhead.  Of course, if that adds
just 5% to the overall runtime, the motivation to look for algorithmic
improvements is not as pressing as it seemed before.

-- 
David Kastrup


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

Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[David Kastrup]

Carl Sorensen c_soren...@byu.edu writes:

 On 2/10/12 12:52 PM, David Kastrup d...@gnu.org wrote:

Sure thing.  When this will be going on countdown, I was also going to
copy it to the user list.  I also plan on mentioning it in the next
LilyPond Report (no idea about when I'll be working seriously on that,
hopefully soon), whether before or after 2.16 has been released.  But
as long as no users are seriously worrying about OSX 10.4 (and the
only one actually offering a bounty was not doing this out of personal
need, but because of sympathy with possibly mythical legacy users),
there does not seem much of a point to expend the work, even if it is
just few hours, for caring.

 I will take a stab at the two-line patch tomorrow.

Thanks.  I still think we need some process for figuring out how much
sense it makes to invest time and energy into platforms that might not
see relevant actual use.  Our end of line procedures cost too much
energy.

-- 
David Kastrup


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

Re: google summer of code

[David Kastrup]

Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/2/9 Graham Percival gra...@percival-music.ca:
 Does anybody feel like submitting a proposal to google summer of
 code?  IIRC students must be registered at a school, so this isn't
 something that would help any senior developer, but it's still
 $5500 for any student that ends up working on lilypond over the
 summer, plus $500 for the organization.

 http://www.google-melange.com/gsoc/homepage/google/gsoc2012

 [some discussion]

 So, are there any reasons not to do it?

I don't think so.

 In particular, do you think we might have problems with availability
 of mentors?

If the student does not expect the mentor to be dragging him all the way
(and LilyPond is not exactly beginner's terrain), I don't see much of a
problem here.  Maybe I am naive.

-- 
David Kastrup


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

Re: some comments and complaints on the code (issue 5651069)

[David Kastrup]

carl.d.soren...@gmail.com writes:

 Thanks for taking this on, Janek.

 I don't know what the response will be to for_UP_and_DOWN(d).  The last
 time somebody proposed a change, it was resisted because the do{}
 flip(d)!=UP idiom seemed simple enough to be acceptable.

 But I think the new idiom is more readable, and if there are no
 performance issues with it, I'd be in favor of it.

More like code size (I have not actually looked).  But one could
consider using the flip idiom inside of the macro.

-- 
David Kastrup


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

Re: Dubious recommendation about ragged-last-bottom in spacing.itely

[David Kastrup]

Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/2/10 Pavel Roskin pro...@gnu.org:
 Hello!

 There is a strange suggestion in Documentation/notation/spacing.itely:

 
 @item ragged-last-bottom
 @funindex ragged-last-bottom

 If set to false, systems will spread vertically down the last
 page.  Pieces that amply fill two pages or more should have this
 set to true.
 

 I believe the opposite should be suggested.  Large scores should set
 ragged-last-bottom to false.  For a large score, it's easy to fill a
 whole number of pages without much distortion.  Doing so increases
 readability of the piece without increasing the number of the page
 turns.

It depends on how well our penalty system works.  If you fill three
pages anyway, you want your breaks at places where a page turn makes
good sense.  Even if one page is short.  If LilyPond has no way to
figure out one page break being better than another, it might as well
spread the material evenly over pages.  But other than that, I don't see
that filling the last page should necessarily increase readability.

Just having choices #f and #t is also not really optimal.

-- 
David Kastrup


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

Re: google summer of code

[Łukasz Czerwiński]

2012/2/10 David Kastrup address@hidden:

* Don't get me wrong: it is probably quite enough work for getting someone*
* started.  I'm just not sure whether it will be easy to sell it off.  The*
* largest part of the work would realistically consist in digging oneself*
* into sparsely documented areas, just in order to be able to come up with*
* a good plan and implementation that would, if you discounted all dead*
* corners, take two days to do.*
**
* It seems a bit like visiting a term of art classes in order to make a*
* convincing sketch at its end.  The real deal is not the sketch, but the*
* ability to do so.  And if all you are going to do is that one sketch,*
* the exercise seems a bit pointless.*
**
* But of course, if you want to turn sketches into a living, having*
* someone pay what it takes to do the first sketch is going to be a _big_*
* help.*


Like Janek, I'm also thinking of participating in GSoC. If one of us works
on that bug during GSoC and moreover while coding also adds some
documentation to the poorly commented code, this will result in far more
than one sketch, because we will stay connected with Lilypond after the
end of GSoC 2012.

If you think that Issue #34 is too little for GSoC, you could add to that
some other similar issues with MIDI or grace notes in a form similar to:
http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_observation_planner_and_logging_feature

Best wishes,
Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: some comments and complaints on the code (issue 5651069)

[janek . lilypond]

On 2012/02/10 23:49:24, Carl wrote:

Thanks for taking this on, Janek.



I don't know what the response will be to for_UP_and_DOWN(d).  The

last time

somebody proposed a change, it was resisted because the do{}

flip(d)!=UP idiom

seemed simple enough to be acceptable.


It took us a while to figure out what's going on with the do{}
flip(d)!=UP thing.
If it was up to me, i'd just write everything twice, following the rule
1, 2, many :)

Some of your comments will be better addressed by Luke - i leave them to
him.

Thanks for review!
Janek


http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc#newcode211
lily/accidental-placement.cc:211: * @return A vector of
Accidental_placement_entrys
On 2012/02/11 00:09:00, joeneeman wrote:

Please don't just comment on the type (unless it's SCM in which case

you can say

which scheme type it is).


Well, the main point of the comment is not describing parameters, but
the function itself.  Believe me or not, we spent 10 minutes figuring
out _what the hell_ are apes doing here and whether there are any
bananas involved.
It's stupid, i know.  But there must exist a way of writing code that is
understandable for the newcomers after second reading, not after 10
minutes.

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode316
lily/note-collision.cc:316: shift_amount *= 1.25;
this must be a mistake actually.  We didn't intend to do anything with
the working code yet.

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode369
lily/note-collision.cc:369: -set_property (direction, scm_from_int
(dir));
On 2012/02/10 23:49:24, Carl wrote:

I think the indentation in the old code is correct.  The - should be

indented,

since it's not the start of a statement.


+1


But if this spacing is what's produced by fixcc.py, then we should

keep it.

It was done by fixcc indeed.

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode552
lily/note-collision.cc:552: for_UP_and_DOWN (d) // please, make a
comment to this loop (better than the above one...)
On 2012/02/10 23:49:24, Carl wrote:

To whom is the please directed?  Is there anybody who is better than

you right

now to comment the loop?


Yes: the author of the code.  There are also other people in our team
who will understand this at second reading; i still don't understand how
exactly this works.
(of course i don't demand that anyone does anything about it)

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode588
lily/note-collision.cc:588: {
On 2012/02/10 23:49:24, Carl wrote:

I don't know that we have a specification for this, or if it can be

handled by

fixcc.py, but for consistency with the way we indent braces with loops

and if,

the braces should be indented two spaces, IMO.


+10

However, the result was produced with fixcc.  At the moment i don't know
how to fix fixcc; i've looked at its code and it contains a lot of

('([\w\)\]]) *(--|\+\+)', '\\1\\2')

which look nice but i have absolutely no idea how they work, and no time
to learn at the moment :(

http://codereview.appspot.com/5651069/

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

Re: some comments and complaints on the code (issue 5651069)

[janek . lilypond]

Forgot about one thing, sorry


http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode552
lily/note-collision.cc:552: for_UP_and_DOWN (d) // please, make a
comment to this loop (better than the above one...)
I've just realized that the correct answer for your question is

On 2012/02/10 23:49:24, Carl wrote:

To whom is the please directed?  Is there anybody who is
better than you right now to comment the loop?


Me in the future :)  When we finish this bugfix, we'll hopefully
understand everything well, and this comment will remind us to write
down this knowledge :D

http://codereview.appspot.com/5651069/

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

Re: google summer of code

[David Kastrup]

Łukasz Czerwiński milimet...@gmail.com writes:

 2012/2/10 David Kastrup address@hidden:
 Don't get me wrong: it is probably quite enough work for getting someone
 started.  I'm just not sure whether it will be easy to sell it off.  The
 largest part of the work would realistically consist in digging oneself
 into sparsely documented areas, just in order to be able to come up with
 a good plan and implementation that would, if you discounted all dead
 corners, take two days to do.

 It seems a bit like visiting a term of art classes in order to make a
 convincing sketch at its end.  The real deal is not the sketch, but the
 ability to do so.  And if all you are going to do is that one sketch,
 the exercise seems a bit pointless.

 But of course, if you want to turn sketches into a living, having
 someone pay what it takes to do the first sketch is going to be a _big_
 help.

 Like Janek, I'm also thinking of participating in GSoC. If one of us
 works on that bug during GSoC and moreover while coding also adds some
 documentation to the poorly commented code, this will result in far
 more than one sketch, because we will stay connected with Lilypond
 after the end of GSoC 2012.

 If you think that Issue #34 is too little for GSoC, you could add to
 that some other similar issues with MIDI or grace notes in a form
 similar
 to: http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_
 observation_planner_and_logging_feature

I was just thinking of a story I wanted to share in this context.  In my
high school days, I was in some sort of school band.  I played
electrical guitar, another one (with a classical guitar education I
believe) bass, I somehow managed to get the son of a resident music
school director to play drums, and we had a flutist who had just changed
from recorder to regular flute and was rather fond of experimenting
around.

Not much came off that, but the flutist kept the first real piece we
had been doing in his repertoire for quite a while.

Now fast forward a dozen years, and the younger brother of the flutist,
the unmusical brother, calls me.  The flutist is getting married, and
the younger brother has the idea that at his wedding, he'll play that
old first piece on the flute.  It is my job to write down the notes (it
would be nice to put in some LilyPond angle in here, but in truth I just
wrote them by hand on notepaper) and to play the guitar.  I write down
the notes (still know them by heart more or less) and start thinking.

Several phone calls and letters later it turns out that the drummer is
living in Ireland by now, but will be in Aachen because of a friend's
wedding.  So if we organize a drum kit...  The bass player is living in
Munich, but considers the gag worth his trouble to drive a whole day
just to make an entrance, if we are getting him a bass guitar for the
occasion.  I actually still have my own guitar, so I'm the one actually
playing on original material.

Three days before the wedding, the brother makes his first appearance at
my house.  He has taken the notes to a friend playing flute, and has
been working for close to half a year getting the scale he needs into
shape.  Rhythm and interplay are all wrong.  After the first day, he got
the rhythm more or less right.  After the second day, we are playing
this together smoothly and I stop worrying about this becoming a total
catastrophe.  On the third, he starts improvising solos.  It was like
high school all over again.  Unmusical or not, it was obvious which
family he was from.

On the wedding, I made some sort of lame speech, put the flutist (who
can play pretty much everything) at the bass and picked up the guitar,
then we started, and I stopped, saying that is not good.  Take the
drums instead, I think I have a bass player here.  Who actually arrived
just 20 minutes ago, having been stuck in traffic almost all the way, so
we had no real practice together.  The same game with the drums, and we
had the original drummer pick up the drums instead, and gave the flutist
a flute.  His brother was doing the PA stuff all the while (actually,
that was stuff he was good at in his youth as well), and was now holding
the mic for his brother.  And then the same that is not good.  Take the
mic instead, give the flute to your brother.  Of course everyone knew
that the flutist was being led on all the while, but nobody had a clue
just where.  And the brother stood there with a puzzled look at the
flute while the flutist now held the mic, while we others played the
intro.  And then the brother played.

A few days after the wedding, he handed back the borrowed flute and
stopped doing music again.

It was pretty much the single sketch equivalent, but it was something
that a lot of people won't forget.  It was totally silly but worth doing
for some reason, and a number of people put in their smaller (but still
considerable) contributions of letting it happen.

-- 
David Kastrup

Re: google summer of code

[Janek Warchoł]

2012/2/11 David Kastrup d...@gnu.org:
 Łukasz Czerwiński milimet...@gmail.com writes:

 2012/2/10 David Kastrup address@hidden:
 Don't get me wrong: it is probably quite enough work for getting someone
 started.  I'm just not sure whether it will be easy to sell it off.  The
 largest part of the work would realistically consist in digging oneself
 into sparsely documented areas, just in order to be able to come up with
 a good plan and implementation that would, if you discounted all dead
 corners, take two days to do.

 It seems a bit like visiting a term of art classes in order to make a
 convincing sketch at its end.  The real deal is not the sketch, but the
 ability to do so.  And if all you are going to do is that one sketch,
 the exercise seems a bit pointless.

 But of course, if you want to turn sketches into a living, having
 someone pay what it takes to do the first sketch is going to be a _big_
 help.

 Like Janek, I'm also thinking of participating in GSoC. If one of us
 works on that bug during GSoC and moreover while coding also adds some
 documentation to the poorly commented code, this will result in far
 more than one sketch, because we will stay connected with Lilypond
 after the end of GSoC 2012.

 If you think that Issue #34 is too little for GSoC, you could add to
 that some other similar issues with MIDI or grace notes in a form
 similar
 to: http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_
 observation_planner_and_logging_feature

 I was just thinking of a story I wanted to share in this context.  In my
 high school days, I was in some sort of school band.  I played
 electrical guitar, another one (with a classical guitar education I
 believe) bass, I somehow managed to get the son of a resident music
 school director to play drums, and we had a flutist who had just changed
 from recorder to regular flute and was rather fond of experimenting
 around.

 Not much came off that, but the flutist kept the first real piece we
 had been doing in his repertoire for quite a while.

 Now fast forward a dozen years, and the younger brother of the flutist,
 the unmusical brother, calls me.  The flutist is getting married, and
 the younger brother has the idea that at his wedding, he'll play that
 old first piece on the flute.  It is my job to write down the notes (it
 would be nice to put in some LilyPond angle in here, but in truth I just
 wrote them by hand on notepaper) and to play the guitar.  I write down
 the notes (still know them by heart more or less) and start thinking.

 Several phone calls and letters later it turns out that the drummer is
 living in Ireland by now, but will be in Aachen because of a friend's
 wedding.  So if we organize a drum kit...  The bass player is living in
 Munich, but considers the gag worth his trouble to drive a whole day
 just to make an entrance, if we are getting him a bass guitar for the
 occasion.  I actually still have my own guitar, so I'm the one actually
 playing on original material.

 Three days before the wedding, the brother makes his first appearance at
 my house.  He has taken the notes to a friend playing flute, and has
 been working for close to half a year getting the scale he needs into
 shape.  Rhythm and interplay are all wrong.  After the first day, he got
 the rhythm more or less right.  After the second day, we are playing
 this together smoothly and I stop worrying about this becoming a total
 catastrophe.  On the third, he starts improvising solos.  It was like
 high school all over again.  Unmusical or not, it was obvious which
 family he was from.

 On the wedding, I made some sort of lame speech, put the flutist (who
 can play pretty much everything) at the bass and picked up the guitar,
 then we started, and I stopped, saying that is not good.  Take the
 drums instead, I think I have a bass player here.  Who actually arrived
 just 20 minutes ago, having been stuck in traffic almost all the way, so
 we had no real practice together.  The same game with the drums, and we
 had the original drummer pick up the drums instead, and gave the flutist
 a flute.  His brother was doing the PA stuff all the while (actually,
 that was stuff he was good at in his youth as well), and was now holding
 the mic for his brother.  And then the same that is not good.  Take the
 mic instead, give the flute to your brother.  Of course everyone knew
 that the flutist was being led on all the while, but nobody had a clue
 just where.  And the brother stood there with a puzzled look at the
 flute while the flutist now held the mic, while we others played the
 intro.  And then the brother played.

 A few days after the wedding, he handed back the borrowed flute and
 stopped doing music again.

 It was pretty much the single sketch equivalent, but it was something
 that a lot of people won't forget.  It was totally silly but worth doing
 for some reason, and a number of people put in their smaller (but still
 considerable) 

Re: Thinking about putting together a grant to support development onLilyPond

[pls]

Am 09.02.2012 um 17:26 schrieb Phil Holmes:

 - Original Message - From: Han-Wen Nienhuys hanw...@gmail.com
 To: Carl Sorensen c_soren...@byu.edu
 
 C) Development of score_ocr2ly, which would take a score pdf and turn it
 into .ly files matching the lilypond scoring standard
 
 Heh.  This is a known problem, and the OCR part is very, very
 difficult. It also has nothing to do with lilypond.
 
 
 There are a number of commercial products that, given a perfect 
 representation of a score, convert it to perfect musicXML - so it can't be 
 that hard.  
Hm, could you name some, please? I haven't come across such a product, yet.
 It may simply be that the OS community do not generally have these skills.
 
 --
 Phil Holmes 
 
 ___
 lilypond-user mailing list
 lilypond-u...@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-user


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

Re: Thinking about putting together a grant to support development onLilyPond

[Phil Holmes]

- Original Message - 
From: pls p.l.schm...@gmx.de

To: Phil Holmes m...@philholmes.net

 There are a number of commercial products that, given a perfect 
 representation of a score, convert it to perfect musicXML - so it can't 
 be that hard.


Hm, could you name some, please? I haven't come across such a product, 
yet.


Sharpeye.

--
Phil Holmes



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

Re: some comments and complaints on the code (issue 5651069)

[milimetr88]

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc#newcode211
lily/accidental-placement.cc:211: * @return A vector of
Accidental_placement_entrys
Do you mean @param and @return or the comment to the function? What
comment would you propose?

On 2012/02/11 00:09:00, joeneeman wrote:

Please don't just comment on the type (unless it's SCM in which case

you can say

which scheme type it is).


http://codereview.appspot.com/5651069/diff/1/lily/include/note-column.hh
File lily/include/note-column.hh (right):

http://codereview.appspot.com/5651069/diff/1/lily/include/note-column.hh#newcode39
lily/include/note-column.hh:39: /**
Ok, I'll correct that.

On 2012/02/10 23:49:24, Carl wrote:

IMO, this comment belongs in the definition, not the declaration


http://codereview.appspot.com/5651069/diff/1/lily/include/note-column.hh#newcode39
lily/include/note-column.hh:39: /**
On 2012/02/10 23:49:24, Carl wrote:

IMO, this comment belongs in the definition, not the declaration


Done.

http://codereview.appspot.com/5651069/diff/1/lily/include/staff-symbol-referencer.hh
File lily/include/staff-symbol-referencer.hh (right):

http://codereview.appspot.com/5651069/diff/1/lily/include/staff-symbol-referencer.hh#newcode53
lily/include/staff-symbol-referencer.hh:53: /**
Ok, I'll correct that.

On 2012/02/10 23:49:24, Carl wrote:

Again, comment in the definition, not the declaration


http://codereview.appspot.com/5651069/diff/1/lily/include/staff-symbol-referencer.hh#newcode53
lily/include/staff-symbol-referencer.hh:53: /**
On 2012/02/10 23:49:24, Carl wrote:

Again, comment in the definition, not the declaration


Done.

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode377
lily/note-collision.cc:377: /**
AFAIK, not really. In Contributor's Guide there are only 2 short
paragraphs:

Comments may not be needed if descriptive variable names are used in the
code and the logic is straightforward. However, if the logic is
difficult to follow, and particularly if non-obvious code has been
included to resolve a bug, a comment describing the logic and/or the
need for the non-obvious code should be included.

There are instances where the current code could be commented better. If
significant time is required to understand the code as part of preparing
a patch, it would be wise to add comments reflecting your understanding
to make future work easier.

(http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#code-comments)

I just wanted to introduce JavaDoc comment style for autodocumenting.
Maybe style of comments should be discussed on lilypond-devel?

On 2012/02/10 23:49:24, Carl wrote:

I don't like the double * following the /.  Is this a standard

anywhere else in

lilypond?


http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode552
lily/note-collision.cc:552: for_UP_and_DOWN (d) // please, make a
comment to this loop (better than the above one...)
On 2012/02/10 23:49:24, Carl wrote:

To whom is the please directed?  Is there anybody who is better than

you right

now to comment the loop?


Yes - someone who knows this code :] Possibly one day someone will try
to refactor this code, what will mean that he understands it well.
For me it's really hard to understand whats going on here. Me and Janek
recently spent a couple of hours trying to understand several files
including this one and we still don't know if clash_groups[d] is one
single note or a group of notes.

Do you have a tip, how to work it out? Unfortunately it's not state in
the code.

http://codereview.appspot.com/5651069/

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

Re: git repository for osx-lilypond

[Graham Percival]

On Sat, Feb 11, 2012 at 09:32:11AM +0100, Janek Warchoł wrote:
 2012/2/11 Carl Sorensen c_soren...@byu.edu:
  In order to try to track this down, I'd like to have a git history to see
  how things have changed. [...]
  Can anybody tell me where I might find an up-to-date repository?

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/macos-lilypad

but the two-line fix for 10.4 ppc support would occur in GUB, not
in osx-lilypad.

 I think this is a lesson for us all.

Yes, and that lesson is when Graham tries to off-load mundane
administrative tasks, somebody do it, because you want him to take
care of *non-mundane* administrative tasks.

I've known about this problem for years.  I've been thinking about
taking care of it for years.  A sketch of a solution is already
present in the GOP issue.  But I've always had more important
things to do; some of them complicated stuff that it only makes
sense to take care of myself, but a lot of it is routine boring
stuff that anybody could do.

 It's a shame to waste Carl's time on searching for source code;

Yes.

 I think we should do this, i'll investigate how it's done.

Don't waste your time.  Just take care of the ordinary
administrative tasks.

- Graham

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

Re: some comments and complaints on the code (issue 5651069)

[janek . lilypond]

new patch set uploaded, please review.


http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode588
lily/note-collision.cc:588: {
On 2012/02/11 12:32:57, Milimetr88 wrote:

On 2012/02/10 23:49:24, Carl wrote:
 I don't know that we have a specification for this, or if it can be

handled by

 fixcc.py, but for consistency with the way we indent braces with

loops and if,

 the braces should be indented two spaces, IMO.



Done. Janek will push it soon. Maybe fixcc will not change it back...


I've checked that fixcc will change this if it's ran on the file.  No
need to do this, though.
I'll add an issue about fixing fixcc.

http://codereview.appspot.com/5651069/

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

Re: google summer of code

[Janek Warchoł]

W dniu 11 lutego 2012 13:33 użytkownik Graham Percival
gra...@percival-music.ca napisał:
 Time+effort required to write a proposal.  Would you be happy
 delaying the 2.16 for, say, a month, while we spend effort writing
 that proposal (which may or may not be accepted) ?  When all's
 said and done, I wouldn't be surprised if it worked out to that
 much effort.

I'll gladly spend some time on preparing the proposal.

 The mentor is expected to spend some amount of time with the
 student.  Maybe it's one hour per week; maybe it's an hour each
 working day.  I'm not certain -- check their FAQ.

They suggest it turns out to be more like 5 hrs/week, although i think
it's about the case when the student is completely new to the project.
We can set prerequisites like C++, git and music (notation) knowledge,
so that we won't have to mentor people about this (takes a lot of
time).
Also, we have a nice CG, it's possible that it'll cut mentoring time
substantially.

W dniu 11 lutego 2012 14:00 użytkownik Graham Percival
gra...@percival-music.ca napisał:
 On Sat, Feb 11, 2012 at 01:43:06PM +0100, David Kastrup wrote:
 It would be rather pointless to recruit people not already
 familiar with LilyPond development.

 But that's the whole point of GSoC.

In the FAQ Google explicitly says that people familiar with the
project can participate.

cheers,
Janek

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

Re: google summer of code

[Graham Percival]

On Sat, Feb 11, 2012 at 02:32:31PM +0100, Janek Warchoł wrote:
 W dniu 11 lutego 2012 13:33 użytkownik Graham Percival
 gra...@percival-music.ca napisał:
  Time+effort required to write a proposal.  Would you be happy
  delaying the 2.16 for, say, a month, while we spend effort writing
  that proposal (which may or may not be accepted) ?  When all's
  said and done, I wouldn't be surprised if it worked out to that
  much effort.
 
 I'll gladly spend some time on preparing the proposal.

Ok, maybe spend an hour or two and see what you come up with.

 We can set prerequisites like C++, git and music (notation) knowledge,
 so that we won't have to mentor people about this (takes a lot of
 time).

Agreed about git.  Not certain about music notation; there's a lot
of good work that somebody can do even if they have difficulty
finding FACE on a treble cleff.  OTOH, it might be nice
advertising for us -- it would make lilypond stand out in the
list of project requirements.

I'm very uncertain about listing C++.  There's a ton of stuff that
people can do with scheme only.  If anything, we might want to
list scheme... but then again, there's a lot of things that can be
done without scheme.

  But that's the whole point of GSoC.
 
 In the FAQ Google explicitly says that people familiar with the
 project can participate.

ok, but the application definitely shouldn't say that previous
experience with lilypond is required.

- Graham

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

Translation request

[Phil Holmes]

Please see commit:

6c6f97dcb49afb3aaa9480eece124d11a6c48975

This changes the words around an illustration of the syntax of printing 
woodwind key lists, replacing an inline snippet with text.  The benefit of 
this is that the snippet is no longer run during a make doc, and therefore 
the key lists no longer appear in the terminal output during make doc. 
There are some translated versions of this part of the manual - could a 
translator update these to gain the full benefit, please?


--
Phil Holmes



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

Re: git repository for osx-lilypond

[Janek Warchoł]

W dniu 11 lutego 2012 13:30 użytkownik Graham Percival
gra...@percival-music.ca napisał:
 On Sat, Feb 11, 2012 at 09:32:11AM +0100, Janek Warchoł wrote:
 I think this is a lesson for us all.

 Yes, and that lesson is when Graham tries to off-load mundane
 administrative tasks, somebody do it, because you want him to take
 care of *non-mundane* administrative tasks.

point for you.  I'll continue working on Patchy and hopefully git-cl
too when i finish with funding thingy.

 I think we should do this, i'll investigate how it's done.

 Don't waste your time.

I like playing with git, you know.

cheers,
Janek

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

Final redirection of texi output (issue 5650064)

[PhilEHolmes]

Reviewers: dak, Graham Percival, Julien Rioux,

Message:
Latest GOP 9 make doc reduction - please review.

Description:
I've opened a new issue to avoid confusion.  AFAICS this redirects all
the output from texi2pdf, makeinfo and tex2html to logfiles.  I've used
Julien and David's suggestion of getting rid of --batch and --quiet, and
it turns of the  /dev/null isn't needed when texi2pdf is run like this.
 make; make doc is good.  If I edit notation.tely to put a load of
random @ \ in, make doc fails with this on the terminal:

extract_texi_filenames.py: Processing out-www/notation.texi
writing:
/media/IntelSSD/lilypond/lilypond-git/build/./out-www/xref-maps/notation.xref-map
lilypond-book.py (GNU LilyPond) 2.15.30

Please check the logfile notation.texi2pdf.log for errors

make[2]: *** [out-www/notation.pdf] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/media/IntelSSD/lilypond/lilypond-git/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/media/IntelSSD/lilypond/lilypond-git/build'
make: *** [doc-stage-1] Error 2

The contents of the logfile are:

cat notation.texi2pdf.log
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
(./notation.texi (/home/phil/lilypond-git/tex/texinfo.tex
Loading texinfo [version 2009-08-14.15]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/share/texmf-texlive/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.)
(./notation.aux) (/home/phil/lilypond-git/tex/txi-en.tex)
Runaway argument?
@@\\@\\\\
./notation.texi:17: Paragraph ended before @\ was complete.
to be read again
   @par
l.17

?
./notation.texi:17: Emergency stop.
to be read again
   @par
l.17

./notation.texi:17:  == Fatal error occurred, no output PDF file
produced!
Transcript written on notation.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.

I'm hoping this is this part of GOP 9 complete.

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

Affected files:
  M Documentation/GNUmakefile
  M make/doc-i18n-root-rules.make
  M make/doc-i18n-root-vars.make
  A scripts/build/run-and-check.sh
  M stepmake/stepmake/texinfo-rules.make
  M stepmake/stepmake/texinfo-vars.make


Index: Documentation/GNUmakefile
diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile
index  
22da2d8fa8d73a3746c11f5d9d64f641fb45fda1..511b19a2d17286b038dd0ad27342193044a1971b  
100644

--- a/Documentation/GNUmakefile
+++ b/Documentation/GNUmakefile
@@ -195,7 +195,7 @@ endif
 ### Rules

 $(outdir)/lilypond-%.info: $(outdir)/%.texi  
$(outdir)/$(INFO_IMAGES_DIR).info-images-dir-dep $(outdir)/version.itexi  
$(outdir)/weblinks.itexi

-   $(MAKEINFO) -I$(src-dir) -I$(outdir) --output=$@ $
+	$(buildscript-dir)/run-and-check $(MAKEINFO) -I$(src-dir) -I$(outdir)  
--output=$@ $  $*.makeinfo.log


 txt-to-html: $(OUT_TXT_FILES) $(OUT_TXT_FILES:%.txt=%.html)

@@ -231,11 +231,11 @@ endif
 # Ugh, using '%' twice not possible
 $(outdir)/notation/notation.xml: $(outdir)/notation.texi
mkdir -p $(dir $@)
-   $(MAKEINFO) -I$(src-dir) -I$(outdir) --output=$(dir $@) --docbook $
+	$(buildscript-dir)/run-and-check $(MAKEINFO) -I$(src-dir) -I$(outdir)  
--output=$(dir $@) --docbook $  $*.makeinfo.log


 $(outdir)/internals/internals.xml: $(outdir)/internals.texi
mkdir -p $(dir $@)
-   $(MAKEINFO) -I$(src-dir) -I$(outdir) --output=$(dir $@) --docbook $
+	$(buildscript-dir)/run-and-check $(MAKEINFO) -I$(src-dir) -I$(outdir)  
--output=$(dir $@) --docbook $  $*.makeinfo.log


 $(outdir)/learning.texi $(outdir)/notation.texi: $(OUT_PDF_IMAGES)

Index: make/doc-i18n-root-rules.make
diff --git a/make/doc-i18n-root-rules.make b/make/doc-i18n-root-rules.make
index  
3cdd664471ffc6541a413c2c4c019950c3d77a9f..e240334b36e145e62f8c591d42b2009f109bf1d7  
100644

--- a/make/doc-i18n-root-rules.make
+++ b/make/doc-i18n-root-rules.make
@@ -7,19 +7,17 @@ $(outdir)/web.texi: $(outdir)/weblinks.itexi
 $(top-build-dir)/Documentation/$(outdir)/%/index.$(ISOLANG).html:  
$(outdir)/%.texi $(XREF_MAPS_DIR)/%.$(ISOLANG).xref-map  
$(TRANSLATION_LILY_IMAGES)

mkdir -p $(dir $@)
mkdir -p $(outdir)/$*
-	DEPTH=$(depth)/../ $(TEXI2HTML) $(TEXI2HTML_SPLIT) $(TEXI2HTML_FLAGS)  
--output=$(outdir)/$* $ $*.splittexi.log 21
+	$(buildscript-dir)/run-and-check DEPTH=$(depth)/../ $(TEXI2HTML)  
$(TEXI2HTML_SPLIT) $(TEXI2HTML_FLAGS) --output=$(outdir)/$*  
$ $*.splittexi.log
 	find $(outdir)/$* -name '*.html' | xargs grep -L 'UNTRANSLATED NODE:  
IGNORE ME' | sed 's!$(outdir)/!!g' | xargs $(buildscript-dir)/mass-link  
--prepend-suffix .$(ISOLANG) hard $(outdir)  
$(top-build-dir)/Documentation/$(outdir)


 $(top-build-dir)/Documentation/$(outdir)/%-big-page.$(ISOLANG).html:  
$(outdir)/%.texi 

Re: Final redirection of texi output (issue 5650064)

[David Kastrup]

philehol...@googlemail.com writes:

 Reviewers: dak, Graham Percival, Julien Rioux,

 Message:
 Latest GOP 9 make doc reduction - please review.

 Description:
 I've opened a new issue to avoid confusion.  AFAICS this redirects all
 the output from texi2pdf, makeinfo and tex2html to logfiles.  I've used
 Julien and David's suggestion of getting rid of --batch and --quiet, and
 it turns of the  /dev/null isn't needed when texi2pdf is run like this.
  make; make doc is good.

You might be mistaken here.  make -j... calls some processes with closed
stdin, but it is not predictable which processes these are.  So before
you come to this conclusion, try it with a single-job make.

-- 
David Kastrup

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

Re: Final redirection of texi output (issue 5650064)

[Phil Holmes]

- Original Message - 
From: David Kastrup d...@gnu.org

To: philehol...@googlemail.com
Cc: re...@codereview-hr.appspotmail.com; julien.ri...@gmail.com; 
lilypond-devel@gnu.org

Sent: Saturday, February 11, 2012 5:20 PM
Subject: Re: Final redirection of texi output (issue 5650064)



philehol...@googlemail.com writes:


Reviewers: dak, Graham Percival, Julien Rioux,

Message:
Latest GOP 9 make doc reduction - please review.

Description:
I've opened a new issue to avoid confusion.  AFAICS this redirects all
the output from texi2pdf, makeinfo and tex2html to logfiles.  I've used
Julien and David's suggestion of getting rid of --batch and --quiet, and
it turns of the  /dev/null isn't needed when texi2pdf is run like this.
 make; make doc is good.


You might be mistaken here.  make -j... calls some processes with closed
stdin, but it is not predictable which processes these are.  So before
you come to this conclusion, try it with a single-job make.

--
David Kastrup



Great catch, thanks.  without -jX it froze, as you say, waiting keyboard 
input.  New patch set uploaded including /dev/null which does not have this 
problem.


--
Phil Holmes



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

Re: musicexp.py: Fix for issue 1985 (issue 5303063)

[ptrcklschmdt]

On 2011/10/24 09:47:45, Reinhold wrote:

LGTM.


Hi,

I know it's only a one-liner but it still fixes a bus error. Is there
any specific reason why this patch has never been pushed?

Thanks
patrick

http://codereview.appspot.com/5303063/

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

Re: musicexp.py: Fix for issue 1985 (issue 5303063)

[graham]

On 2012/02/11 20:55:34, pl_s wrote:

I know it's only a one-liner but it still fixes a bus error. Is there

any

specific reason why this patch has never been pushed?


It was pushed a week ago?
http://code.google.com/p/lilypond/issues/detail?id=1985

You're the only person that can close this codereview issue.

- Graham

http://codereview.appspot.com/5303063/

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

Re: musicexp.py: Fix for issue 1985 (issue 5303063)

[ptrcklschmdt]

On 2012/02/11 21:01:04, Graham Percival wrote:

On 2012/02/11 20:55:34, pl_s wrote:
 I know it's only a one-liner but it still fixes a bus error. Is

there any

 specific reason why this patch has never been pushed?



It was pushed a week ago?
http://code.google.com/p/lilypond/issues/detail?id=1985



You're the only person that can close this codereview issue.



- Graham


Thanks, will close it.

http://codereview.appspot.com/5303063/

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

Re: Translation request

[Francisco Vila]

2012/2/11 Phil Holmes em...@philholmes.net:
 Please see commit:

 6c6f97dcb49afb3aaa9480eece124d11a6c48975

 This changes the words around an illustration of the syntax of printing
 woodwind key lists, replacing an inline snippet with text.  The benefit of
 this is that the snippet is no longer run during a make doc, and therefore
 the key lists no longer appear in the terminal output during make doc. There
 are some translated versions of this part of the manual - could a translator
 update these to gain the full benefit, please?

Push this patch to staging. I forward your message to the translators
list and recomment others to do a similar patch in their languages.
It's a matter of touching a paragraph.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From 120cd2fe4b14e2622dc3473498fb30981592b6c0 Mon Sep 17 00:00:00 2001
From: Francisco Vila francisco.v...@hispalinux.es
Date: Sat, 11 Feb 2012 23:43:45 +0100
Subject: [PATCH] Doc-es: remove inline snippet in translation.

---
 Documentation/es/notation/wind.itely |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/Documentation/es/notation/wind.itely b/Documentation/es/notation/wind.itely
index 6227e5a..0454775 100644
--- a/Documentation/es/notation/wind.itely
+++ b/Documentation/es/notation/wind.itely
@@ -397,15 +397,10 @@ c1^\markup {
 @end lilypond
 
 La lista de todas las tonalidades y ajustes posibles para un
-instrumento dado, se pueden relacionar sobre la consola o en el
-archivo de registro de salida, aunque no se pueden mostrar en la
-salida de música impresa:
-
-@lilypond[verbatim,quote]
-
-#(print-keys-verbose 'flute)
-
-@end lilypond
+instrumento dado se puede imprimir en la consola usando
+@code{#(print-keys-verbose 'flute)} o en el archivo de registro
+usando @code{#(print-keys-verbose 'flute (current-error-port))},
+aunque no se pueden mostrar en la salida de música impresa.
 
 Se pueden crear diagramas nuevos siguiendo los patrones que están en
 @file{scm/define-woodwind-diagrams.scm} y en
-- 
1.7.5.4

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 11, 2012, at 9:49 AM, David Kastrup wrote:

 m...@apollinemike.com m...@apollinemike.com writes:
 
 On Feb 10, 2012, at 7:35 PM, David Kastrup wrote:
 
 m...@apollinemike.com m...@apollinemike.com writes:
 
 The problem is that the Pango API does not allow multiplication
 between two arbitrary matrices.
 
 Hm?  What's wrong with pango_matrix_concat ?
 
 
 Missed that.
 New dev/skylines-cached up that uses pango affine transforms.
 
 Mike,
 
 I really appreciate it that you let my probably sometimes excessive
 sense of project aesthetics influence the direction your large creative
 energy is taking.

You're very welcome!  It was a good call on your part - I just didn't 
completely get the Pango thing, but it was a painless transition.

Less painless was sorting out outside-staff-priority, which now works correctly 
on:

dev/skylines-cached

It'll go up on Rietveld in a couple days unless anyone has any other global 
suggestions.  Many thanks to Han-Wen, David, and Janek for their feedback.

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

Re: some comments and complaints on the code (issue 5651069)

[k-ohara5a5a]

http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc#newcode191
lily/note-collision.cc:191: */
Protect the comment formatting with a column of '*'s
Otherwise, someone might let emacs re-align the comment, as happened at
line 543.

http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc#newcode536
lily/note-collision.cc:536: s[LEFT]--;  // why LEFT and RIGHT instead of
UP and DOWN?
These lines first appeared in version 1.1.49, thirteen years ago.  If
you do not get answers to your questions during this review, you will
probably have to find the answers yourself.

http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc#newcode551
lily/note-collision.cc:551:
You can use `git blame` to find the original form of this comment
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=lily/note-collision.cc;h=0354950a535f3856234e47a4e7904b2800cc9c09#l437

http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc#newcode587
lily/note-collision.cc:587: for_UP_and_DOWN (d)
Now we have both for_UP_and_DOWN and the while(flip()) idioms in
LilyPond, so every time I forget what the difference is, I have to
search for the definition, open a different file, and study an even more
complicated loop construction.

If you think that for_UP_or_DOWN was self-documenting, then better to :
 do  // for d = UP, then DOWN
   {
   ...

http://codereview.appspot.com/5651069/

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