Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[m...@apollinemike.com]

On 26 avr. 2012, at 07:28, Graham Percival wrote:

> 
> Well, right now we have nobody running the automated tests to
> check that new patches are ok.  So there will be no patches
> accepted to lilypond.
> 

I have a meeting in mid-May w/ the University of Paris VIII.  They're donating 
a computer to LilyPond and I'll set patchy up on it.

Cheers,
MS


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

Re: 30 day webathon for kickstarter support (issue 6068045)

[Graham Percival]

I like the content of the announcement.

I still don't like the idea of manually editing index.html.  I was
expecting/hoping for something like

Documentation/web/twits.txt:
-
The Ensemble 101 is going on a European tour where they'll sing
music typeset using LilyPond.  Click http://www.ensemble101.fr\";>here to learn more!
-
The Birmingham Amateur Theatre is presenting "Penzance Pirates",
starring our documentation editor Trevor Daniels as the talking lion![1]
-
Project manager Graham Percival has successfully defended his PhD
thesis.  Only two days of edits left to go before he hands in the
final version![2]
-
Valentin is trying soy milk with his cereal.  Still on the fence
about it.[3]
-

and then the javascript would parse that file.  I'm not picky
about the file format (it could be "each line is a separate
announcement; lines can be up to 256 chars long" since that's
probably easier to handle in javascript).

[1] this is (probably) not true.
[3] this is (definitely) not true.
[2] joke blantly stolen from Canadian politics.  Also, probably
not true.

- Graham


On Wed, Apr 25, 2012 at 11:28:59AM +, m...@mikesolomon.org wrote:
> Why wouldn't this be a general solution?  I think that anyone who wants
> to add an announcement would have to:
> 
> a) Add an entry to the array.
> b) Build the website and make sure that their entry fits.
> 
> Also, in the most recent patchset I've changed my text to get rid of the
> kickstarter bit.  I'll change the issue names as well.
> 
> http://codereview.appspot.com/6068045/

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Graham Percival]

On Wed, Apr 25, 2012 at 03:14:33PM +0200, Łukasz Czerwiński wrote:
>  I know that this is not a very positive message, but I am trying
>  to save you yet more anguish. Â The lilypond project currently does
>  not even function smoothly between senior developers with more
>  than 100 commits each; there is very little chance for a new
>  contributor to have a smooth and pleasant time helping us.
> 
>Oh, I didn't know about that. I'm reading some Lilypond mails and they
>made me the impression that you *urge* new contributors.

Some people encourage new contributors.  I encourage new
contributors who want to work on administrative tasks.  I try to
discourage new programmers, precisely because they almost always
end up in situations like yours.

>By the way, Janek stated in the mail regarding GSoC in February:
> 
>  Why is your organization applying to participate in Google Summer of
>  Code 2012? What do you hope to gain by participating?
>     Most importantly: more contributors

That's because Janek is wrong.

Last January, I warned him that he should not try to recruit any
new programmers unless he was willing to mentor them because it is
very difficult for new programmers to get started.  I think you
have seen that my prediction was correct.

>I don't understand what's not working smoothly between senior
>developers. Could you describe in a pair of sentences? Is it a
>situation without a solution?

Well, right now we have nobody running the automated tests to
check that new patches are ok.  So there will be no patches
accepted to lilypond.

- Graham

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

Re: What's with the test-patches volunteers?

[Graham Percival]

On Wed, Apr 25, 2012 at 03:06:00PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > I agree.  Given your limited computing power, you are the very
> > last person who should be running Patchy.
> 
> It is not just my computing resources that make me unsuitable.

I was tactfully not mentioning the other part.  :)

> you'll see that I am also damaging the project by alienating new
> contributors.

Actually, we _should_ be alienating new contributors.  At least,
new programming contributors.  Anything else is dishonest and
unfair to them.
(we still need more admin people, though, in order to smooth out
the process of programming such that we can eventually be fair to
new programmers)


> So in order to stop damaging the project, I will stop doing any reviews
> except on patches of myself: I am getting paid for work on LilyPond, and
> it would not be conscionable for me to forego those parts of general
> work required to let my own work go forward.

Please keep on reviewing -- at least, review to the extent of "you
haven't fixed everything." or "problems in x, y, and z".  I'm not
asking you to give any details, I'm not asking you to repeat
yourself, and I'm certainly not asking you to be nice to patch
submitters.  But we really need to stop questionable patches
getting into lilypond -- you know this even better than I.

> > PS if you want to run Patchy on your own patches, then by all
> > means do so.  But please refuse to check other people's patches,
> > no matter how urgent the bug or how much the contributor pleads
> > for reviews.
> 
> I see you are thinking ahead of me again.

It's my job to think ahead of people.  I told Janek in January
that he should not try to recruit anybody unless he was going to
take care of them, because it would end badly.

- Graham

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[tdanielsmusic]

Almost there, if the regtests run clean, but the added 'for' loops are
still not in GNU style - they need a space after 'for'.  This must be
corrected before pushing.  See
http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/46312 where
Keith explained this earlier.

http://codereview.appspot.com/6109046/

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

Re: hideNotes should hide also TabNoteHead (issue 2480). (issue 6105049)

[fedelogy]

Reviewers: Graham Percival, Keith, Neil Puttock, dak,

Message:
On 2012/04/23 12:20:36, Neil Puttock wrote:

Nevertheless, the voicing should be fixed
even if it means adding explicit \voiceOne commands at appropriate

places.  It

looks bad with both voices stem-down.



voiceOne and voiceTwo were already present.
The stem direction was messed up by the grace at the beginning of the
piece. I removed it and now stems look good.


Description:
hideNotes should hide also TabNoteHead (issue 2480).
Tablature example updated accordingly.

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

Affected files:
  M Documentation/ly-examples/tab-example.ly
  M ly/property-init.ly


Index: Documentation/ly-examples/tab-example.ly
diff --git a/Documentation/ly-examples/tab-example.ly  
b/Documentation/ly-examples/tab-example.ly
index  
c2be0d7b5961ff03e165a341b835ec153ca26c4e..a6822231f77f301875aaf2b76ef55bf44d1cab17  
100644

--- a/Documentation/ly-examples/tab-example.ly
+++ b/Documentation/ly-examples/tab-example.ly
@@ -14,17 +14,6 @@
  (- (ly:pitch-alteration right-pitch) (ly:pitch-alteration  
left-pitch))

  0 )))

-% Hide fret number: useful to draw slide into/from a casual point of
-% the fretboard.
-hideFretNumber = {
-  \once \override TabNoteHead #'transparent = ##t
-  \once \override TabNoteHead #'whiteout = ##f
-  \once \override NoteHead #'transparent = ##t
-  \once \override Stem #'transparent = ##t
-  \once \override Flag #'transparent = ##t
-  \once \override NoteHead #'no-ledgers = ##t
-}
-
 \paper {
   indent= #0
   line-width= #180
@@ -36,7 +25,7 @@ upper= \relative c' {
   \set Staff.midiInstrument = #"acoustic guitar (steel)"
   \set fingeringOrientations = #'(left)

-  \partial 4. \acciaccatura c16 \glissando cis8 e4
+  \partial 4. cis8 e4
   < cis-1 g'-3 >2 s8 \grace a16 ( \glissando < b-2 >8\3 ) < d-1 > ( b )
   < e-3 >\2 (  b ) \grace < ais-2 >16 ( \glissando a8 g ) s4.
   s4. < d'\3 g\2 >8 < gis,\4  d'\3 fis\2 >2\arpeggio ~
@@ -49,7 +38,7 @@ lower= \relative c {
   \partial 4. s4.
   s4 e,4 s2
   s2 s8 < e'-3 >4. ~
-  e4 \hideFretNumber \grace { b8 \glissando s4 } < e-2 >4\5 e,2 ~
+  e4 \hideNotes \grace { b8 \glissando s4 } \unHideNotes < e-2 >4\5 e,2 ~
   e2 < e'\6\harmonic >
 }

Index: ly/property-init.ly
diff --git a/ly/property-init.ly b/ly/property-init.ly
index  
cec33d9a42530e46a9a26f712c4cc08506924cd6..c0b352254ad0f195cb20d99465180ca5c706440a  
100644

--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -248,6 +248,7 @@ hideNotes = {
   \override Beam #'transparent = ##t
   \override Accidental #'transparent = ##t
   \override Rest #'transparent = ##t
+  \override TabNoteHead #'transparent = ##t
 }
 unHideNotes = {
   \revert Accidental #'transparent
@@ -258,6 +259,7 @@ unHideNotes = {
   \revert NoteHead #'no-ledgers
   \revert Dots #'transparent
   \revert Rest #'transparent
+  \revert TabNoteHead #'transparent
 }





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

Re: what should go into the website news?

[David Kastrup]

Janek Warchoł  writes:

> On Wed, Apr 25, 2012 at 11:53 AM, Graham Percival
>  wrote:
>> On Tue, Apr 24, 2012 at 09:33:03PM +0200, Janek Warchoł wrote:
>>> On Fri, Apr 20, 2012 at 11:54 PM, Graham Percival
>>>  wrote:
>>
>>> Well then, let's have some important project news posted. I'll write a
>>> note about GSoC,
>>
>> yes.
>
> Done.  Wow, i'm mentioned on the front page - 2 times!  Awesome!
>
>>> and i think we can make an announcement when Mike&Joe
>>> finish new skylines - that's a fairly important project news.
>>
>> No.  Information like that goes into the Changes document.
>
> You are the project administrator, so the decision is yours.  However,
> please consider that many software projects highlight the most
> important changes - to bring visitors' interest and to inform them
> better about the software.

Well, it certainly is frontpage news that due to nobody willing to
review patches, no new patches are going to be accepted in the near
future.

-- 
David Kastrup

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

what should go into the website news? (was: announcing things like ...)

[Janek Warchoł]

On Wed, Apr 25, 2012 at 11:53 AM, Graham Percival
 wrote:
> On Tue, Apr 24, 2012 at 09:33:03PM +0200, Janek Warchoł wrote:
>> On Fri, Apr 20, 2012 at 11:54 PM, Graham Percival
>>  wrote:
>
>> Well then, let's have some important project news posted. I'll write a
>> note about GSoC,
>
> yes.

Done.  Wow, i'm mentioned on the front page - 2 times!  Awesome!

>> and i think we can make an announcement when Mike&Joe
>> finish new skylines - that's a fairly important project news.
>
> No.  Information like that goes into the Changes document.

You are the project administrator, so the decision is yours.  However,
please consider that many software projects highlight the most
important changes - to bring visitors' interest and to inform them
better about the software.
Personally, i find the Changes document a sort of emergency checklist:
when something doesn't work in a new release, i search it to see if it
was a deliberate change and what to do with it.  It's just too long to
be an interesting lecture, and when i read it, i find that most of the
entries are irrelevant to me.  I cannot see how this could be of much
interest to average user, let alone a casual visitor (whom we want to
invite to LilyPond, that's one of the most important goals of the
website).

>> Another example: a new edition (created using LilyPond) of some
>> significant work is released (for example something similar to Open
>> Goldberg Variations) - i'd say that it's important news for the
>> project itself.
>
> I don't agree.

ok, hopefully editions professionally published with LilyPond will
become so commonplace that they won't be important at all.  But if
(hopefully /when/) we launch our own Kickstarter, i'd say that'd be
relevant and important to the LilyPond project itself.

>> > I think it needs to come from people other than the main
>> > developers, though.  We're all too burnt out and overworked to get
>> > enthusiastic about something like this.
>>
>> Maybe.
>> As for the news, i suggest a following solution: when someone feels
>> like posting some news, he puts the note up for review, which will
>> work mostly as a vote (whether to post it or not).
>
> That means that only git people can submit news items?

It looks that currently you have to be Graham to submit news ;) or at
least have his blessing ;)  Being a 'git human' is way easier :)
Seriously, though, i just wanted to remind us that it's not only
Graham who can write news.  It'd be nice to have more than Lily/Report
release news on the website, but we cannot require you to be our
reporter in addition to being administrator - so, let's join our
efforts.

> If you really really want to have fluff pieces on the main
> lilypond website, I could imagine us using the top right-hand
> corner (Mike's "wasted space") for twitter-like announcements of
> concerts and editions.

+1
it would show not only that our project is alive (release news do
that) and usable (productions show that), but also that it's /active/
and /useful/, not just an academic invention of some nerds.


On Wed, Apr 25, 2012 at 12:00 PM, m...@apollinemike.com
 wrote:
> I'm a fan!  I think the no-man's-land @ the top right can be used for all
> sorts of announcements no longer than a tweet: new LilyPond reports,
> concert, tours, engraving projects, etc..  It can be a rotating thing so
> that every time someone signs on, something different pops up.

+1

cheers,
Janek

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

Re: measure counter engraver

[David Nalesnik]

Hi,

Unrelated issue: I notice that the original post with attached files hasn't
> shown up on archive 2 on either -user or -devel, even though I sent that
> post 13 hours ago.  It appears on archive 1, but there the .ly file appears
> as a binary data file, which I cannot open.  Am I guilty of top-posting
> here, or have I exceeded some attachment size limit (48K and 9K)?  I wonder
> if I should repost the .ly file so it isn't lost to the archives.
>
>
Well, the original post along with the attachments still hasn't shown up in
lilypond-user, so I'm attaching the .ly file to this email.  Hopefully, it
will show up in the archives,

-David


measureCounterEngraver.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Łukasz Czerwiński]

On 25 April 2012 17:06, David Kastrup  wrote:

> Łukasz Czerwiński  writes:
>
> > I have never ever get an email from Google Code. I have just checked
> > that triple. That's the reason for ignoring your comments. I'm sorry
> > that my new patch made you run your tests twice to give me the same
> > list of errors...
> >
> > Do you run tests for each patch uploaded to Rietveld?
>
> I won't any more.  It is high time somebody else pitches in.  Neither my
> computing power nor my personality make me suitable for that job.
>

I see... Unfortunately I won't be any help in that.


>  > Ok, thank you. But compiling and running regtests took approx. 2.5
> > hours. It's very long...
>
> Half of that is setting the baseline.  It should be somewhat less: I
> think it took about 2 hours on my previous laptop (10 years old).  When
> it broke down, another senior developer sent me the money for a model
> that is 5 years old (Intel Core 2 Duo at 1.8GHz).  A full comparison
> including baseline is now something short of 40 minutes (if there are
> several patches in the queue, only a single baseline gets made).  Pretty
> much every other developer has more powerful hardware available: some
> even has been explicitly bought for LilyPond work, and the fully
> automated tests for pushing to master, quite more expensive than the
> patch testing, are run on such a system.
>

I run that on a virtual machine which makes it slower and it uses one core
instead of two, so it's slower again... I will think of using native
Ubuntu, but I really like working using Windows 7, so that will be hard
choice :)


Should I take in account diffs that got printed after make check?
They look like this:

(...)
+++ out/voice-5-midi.ly 2012-04-25 16:24:51.779884744 +0200
@@ -10,14 +10,8 @@
 \consists "Completion_rest_engraver"
   }
 }
-\midi {
-  \context {
-\Score
-midiChannelMapping = #'instrument
-  }
-}

-% included from ./out-www/voice-5.header
+% included from ./out/voice-5.header
 \header {
 texidoc="midi2ly still produces output for a staff with five voices.
 However, in such cases, most probably the the correct \voiceOne,
\voiceX... mapping is lost."
 options=""
@@ -43,39 +37,71 @@ trackA = <<
 >>


-trackBchannelA = \relative c {
-  \voiceOne
+trackBchannelA = {
+
+  \set Staff.instrumentName = "trackB:voiceA"
+
+}
+
+trackBchannelB = {
+  \skip 1
+  | % 2
+
+  \set Staff.instrumentName = "trackB:voiceE"
+
+}
+
+trackBchannelC = {

-  \set Staff.instrumentName = ":1"
+  \set Staff.instrumentName = "trackB:voiceD"
+
+}
+
+trackBchannelD = {
+
+  \set Staff.instrumentName = "trackB:voiceC"
+
+}
+
+trackBchannelE = {
+
+  \set Staff.instrumentName = "trackB:voiceB"
+
+}
+
+trackBchannelF = \relative c {
+  \voiceOne
   2 b
   | % 2

 }

-trackBchannelB = \relative c {
+trackBchannelG = \relative c {
   \voiceThree
   c''4. d8 e4 f
   | % 2

 }

-trackBchannelC = \relative c {
+trackBchannelH = \relative c {
   \voiceFour
   d'1
   | % 2

 }

-trackBchannelD = \relative c {
+trackBchannelI = \relative c {
   \voiceTwo
   c'4 c2 c4
   | % 2

 }

-trackBchannelE = \relative c {
-  s1 d1
+trackBchannelJ = \relative c {
+  r1
   | % 2
+  d
+  | % 3

 }

@@ -85,6 +111,11 @@ trackB = <<
   \context Voice = voiceC \trackBchannelC
   \context Voice = voiceD \trackBchannelD
   \context Voice = voiceE \trackBchannelE
+  \context Voice = voiceF \trackBchannelF
+  \context Voice = voiceG \trackBchannelG
+  \context Voice = voiceH \trackBchannelH
+  \context Voice = voiceI \trackBchannelI
+  \context Voice = voiceJ \trackBchannelJ
 >>

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[David Kastrup]

Łukasz Czerwiński  writes:

> I have never ever get an email from Google Code. I have just checked
> that triple. That's the reason for ignoring your comments. I'm sorry
> that my new patch made you run your tests twice to give me the same
> list of errors...
>  
> Do you run tests for each patch uploaded to Rietveld?

I won't any more.  It is high time somebody else pitches in.  Neither my
computing power nor my personality make me suitable for that job.

> > I'd like to know how to run regtests. Should I
> > follow:
> http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison
> >
> > and compare all those tests that differ?
> 
> 
> Yes, that is the respective instruction.  You get a visual
> comparison
> for the tests that differ significantly.
> 
>
> Ok, thank you. But compiling and running regtests took approx. 2.5
> hours. It's very long...

Half of that is setting the baseline.  It should be somewhat less: I
think it took about 2 hours on my previous laptop (10 years old).  When
it broke down, another senior developer sent me the money for a model
that is 5 years old (Intel Core 2 Duo at 1.8GHz).  A full comparison
including baseline is now something short of 40 minutes (if there are
several patches in the queue, only a single baseline gets made).  Pretty
much every other developer has more powerful hardware available: some
even has been explicitly bought for LilyPond work, and the fully
automated tests for pushing to master, quite more expensive than the
patch testing, are run on such a system.

The patch testing, however, requires humans to actually examine the test
results.

> Now I have them, but don't know, how to read the details.

Neither do I.

> Could you give me some tips what those numbers in HTML from the
> attachment are?  Probably some distances, but why there are 7 times:
> Stem: 1.0 and then Barline, while there are only 4 notes before
> the first barline?

Most stuff of interest is the visual comparison.  The numbers are only
interesting if you _know_ that there should be no difference whatsoever,
and you can't figure out visually what changed.  The logs are important
if warnings or similar stuff changes.  And so on.

There is one always-changing regtest designed to change, and there are a
few regtest outputs that tend to change for no discernible reason (like
the graphviz output).  Hopefully we figure them out one day.

But sometimes there is a _lot_ of change when something goes wrong.
Ignoring that is not a good idea.

-- 
David Kastrup

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Łukasz Czerwiński]

On 25 April 2012 14:52, David Kastrup  wrote:

> (...)
> To me, that does not look like you particularly value getting a review.
> You have not fixed a single thing I pointed out.  You have not checked
> your submission yourself for the problems.
> > I didn't notice that comment. I'm not used yet to checking comments on
> > Google Code.
>
> You got the respective messages by personal mail as well unless
> something went very wrong.
>

I have never ever get an email from Google Code. I have just checked that
triple. That's the reason for ignoring your comments. I'm sorry that my new
patch made you run your tests twice to give me the same list of errors...

Do you run tests for each patch uploaded to Rietveld?

> Code reviews take time, effort, and diligence.  Patch testing can
> > be done by yourself easily.  If it isn't, it again takes time,
> > effort, and diligence.
> >
> > It is a matter of courtesy not to waste those lightly, and treat
> > the resources of your coworkers with the respect you want to have
> > them treat yours.
> >
> >
> > For me it sounds like blaming me that I'm a beginner developer on
> > Lilypond project, so my work isn't as optimized as it should be.
>
> No, it is blaming you for ignoring feedback and mails sent to you with
> reviews.
>

As I explained above, I didn't know that you have run tests and wrote a
comment. And it was a really big unkind surprise, that my patch caused any
problems - I thought that it would be simple and without any glitches.


This is not motivating.  And it does not help if the work gets ignored

and one gets called a bugbear for it, to boot.

I'm really sorry for that.

> It's not nice for me, really, and it doesn't encourage me to submit my
> > patches either.
> >
> > I'd like to know how to run regtests. Should I
> > follow:
> http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison
> >
> > and compare all those tests that differ?
>
> Yes, that is the respective instruction.  You get a visual comparison
> for the tests that differ significantly.
>

Ok, thank you. But compiling and running regtests took approx. 2.5 hours.
It's very long...

Now I have them, but don't know, how to read the details. Could you give me
some tips what those numbers in HTML from the attachment are? Probably some
distances, but why there are 7 times: Stem: 1.0 and then Barline, while
there are only 4 notes before the first barline?

Łukasz
Title: comparison details for input/regression/pedal-ped




system
output
orphan
geo


10.000.0029.1333171Stem:
 1.00, Stem: 1.00, Stem: 1.00, Stem: 1.00, Stem: 
1.00, Stem: 1.00, Stem: 1.00, BarLine: 1.00, BarLine: 
1.00, BarLine: 1.00, Stem: 1.00, Stem: 1.00, Stem: 
1.00, Stem: 1.00, Stem: 1.00, Stem: 1.00, Stem: 
1.00, Stem: 1.00, Stem: 1.00, Stem: 1.00, Stem: 
1.00, SustainPedal: 0.564575, NoteHead: 0.360337, NoteHead: 
0.360337, NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 0.360337, 
NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 
0.360337, NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 0.360337, 
NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 0.360337, NoteHead: 
0.360337, SustainPedal: 0.304886, SustainPedal: 0.304886, SustainPedal: 
0.284560, NoteHead: 0.240224, SustainPedal: 0.189199, SustainPedal: 
0.136597, NoteHead: 0.120112, SustainPedal: 0.094333, Beam: 0.085016, 
Beam: 0.040775, StaffSymbol: 0.002743, Stem: 0.24




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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Łukasz Czerwiński]

>
> I know that this is not a very positive message, but I am trying

 to save you yet more anguish.  The lilypond project currently does
> not even function smoothly between senior developers with more
> than 100 commits each; there is very little chance for a new
> contributor to have a smooth and pleasant time helping us.


Oh, I didn't know about that. I'm reading some Lilypond mails and they made
me the impression that you *urge* new contributors.

By the way, Janek stated in the mail regarding GSoC in February:

> Why is your organization applying to participate in Google Summer of
> Code 2012? What do you hope to gain by participating?
>Most importantly: more contributors


I don't understand what's not working smoothly between senior developers.
Could you describe in a pair of sentences? Is it a situation without a
solution?

On 25 April 2012 15:02, Graham Percival  wrote:

>
> >For me it sounds like blaming me that I'm a beginner developer on
> >Lilypond project, so my work isn't as optimized as it should be. It's
> >not nice for me, really, and it doesn't encourage me to submit my
> >patches either.
>
> *sigh*
> yes, this is a huge problem.  You really need a mentor to guide
> you through this process.  Janek Warcho did this for a few months,
> but he gave up due to university work.
>
> I believe that you're both Polish, so I really *really* wish that
> he would offer to guide you.  You're in the same time zone, you
> presumably speak the same native language, etc.


Yes, we are both Polish, yes, we are both in the same time zone, moreover
in the same city and we know each other. From time to time I call Janek and
he instructs me how to do this and that, but I thought it would be better
for lilypond to ask using an official channel - this list. In the present
situation, I'll talk with Janek and get to know if he could offer me more
help (yes, I know he is CC'd, but I'll talk him on my own).

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Graham Percival]

On Wed, Apr 25, 2012 at 01:44:14PM +0200, Łukasz Czerwiński wrote:
>As I understand, fixxcc.py will correct that automatically, so I don't
>have to bother about that? Nevertheless I'll remember that for my
>future patches.

fixcc.py can correct those, but this adds "noise" to the git
commit history.  We generally prefer it if commits already follow
the correct style.

>For me it sounds like blaming me that I'm a beginner developer on
>Lilypond project, so my work isn't as optimized as it should be. It's
>not nice for me, really, and it doesn't encourage me to submit my
>patches either.

*sigh*
yes, this is a huge problem.  You really need a mentor to guide
you through this process.  Janek Warcho did this for a few months,
but he gave up due to university work.

I believe that you're both Polish, so I really *really* wish that
he would offer to guide you.  You're in the same time zone, you
presumably speak the same native language, etc.

Honestly, if you don't have a mentor, I would actually recommend
that you stop trying to help lilypond for the next few months.
This is our fault, not yours -- the lilypond project unfortunately
cannot offer you a "fair" chance to help out.  It might be better
in late summer.

I know that this is not a very positive message, but I am trying
to save you yet more anguish.  The lilypond project currently does
not even function smoothly between senior developers with more
than 100 commits each; there is very little chance for a new
contributor to have a smooth and pleasant time helping us.


>I'd like to know how to run regtests. Should I
>follow:Â [6]http://lilypond.org/doc/v2.15/Documentation/contributor/reg
>test-comparison and compare all those tests that differ?

Yes.  You should be able to state confidently that any differences
between those comparisons are intentional.

- Graham

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

Re: What's with the test-patches volunteers?

[David Kastrup]

Graham Percival  writes:

> On Wed, Apr 25, 2012 at 07:17:06AM +0200, David Kastrup wrote:
>> David Kastrup  writes:
>> 
>> > It is close to two months that I have been the only person running
>> > test-patches, even though several volunteers claimed they would do so.
>> > It has been the main reason I shelled out €20 for a week of internet
>> > access during my spring vacation.
>> 
>> And to add insult to injury, people don't even run "make check" on
>> submitted patches even if they are _supposed_ to change the typeset
>> result.
>
> I agree.  Given your limited computing power, you are the very
> last person who should be running Patchy.

It is not just my computing resources that make me unsuitable.  If you
check up on
http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/46346>,
you'll see that I am also damaging the project by alienating new
contributors.  I quote:

For me it sounds like blaming me that I'm a beginner developer
on Lilypond project, so my work isn't as optimized as it should
be. It's not nice for me, really, and it doesn't encourage me to
submit my patches either.

So in order to stop damaging the project, I will stop doing any reviews
except on patches of myself: I am getting paid for work on LilyPond, and
it would not be conscionable for me to forego those parts of general
work required to let my own work go forward.

> If there are any new contributors who want to get reviews, they will
> be turned away disappointed.

They are already turning away disappointed because of having gotten
reviews, so there is no change in that department.

> PS if you want to run Patchy on your own patches, then by all
> means do so.  But please refuse to check other people's patches,
> no matter how urgent the bug or how much the contributor pleads
> for reviews.

I see you are thinking ahead of me again.

-- 
David Kastrup


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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[David Kastrup]

Łukasz Czerwiński  writes:

> On 25 April 2012 11:57,  wrote:
>
> It would appear that you ignored
> ,
> ,
>
>
> No - just look at dates - the comments are newer than my third patch
> set.

Please take a look at
http://code.google.com/p/lilypond/issues/detail?id=2491> (as the
reporter of this issue, you are copied with every message as well).


The order of code review and resubmission is:

Comment 1 by project member d...@gnu.org, Apr 23 (44 hours ago)

Patchy the autobot says: LGTM.  But bad formatting everywhere: should be "for 
(UP_and_DOWN (d))"

Labels: -Patch-new Patch-review
Comment 2 by project member milimetr88, Yesterday (19 hours ago)

Macro for(UP_and_DOWN) and 3 similar. 
Replaces do{ ... } while(flip (&d) != DOWN/UP/... with a macro 
for(DOWN_and_UP/UP_and_DOWN/) { }

http://code.google.com/p/lilypond/issues/detail?id=2491

http://codereview.appspot.com/6109046

Labels: -Patch-review Patch-new
Delete comment
Comment 3 by project member d...@gnu.org, Yesterday (17 hours ago)

Patchy the autobot says: Lots of regtest differences.  Example: irregular right 
border for compound-time-signatures.ly (particularly bar 8 sticks out to the 
right), also programming errors "Adding reverse rod" like in ambitus-gap.ly

Labels: -Patch-new Patch-needs_work

Comment 4 by project member milimetr88, Today (15 hours ago)

Macro for(UP_and_DOWN) and 3 similar. 
Replaces do{ ... } while(flip (&d) != DOWN/UP/... with a macro 
for(DOWN_and_UP/UP_and_DOWN/) { }

Labels: -Patch-needs_work Patch-new


So I do a code review in comment #1 and tell you that the formatting is
wrong, and how.  You resubmit a patch _without_ changing that and set
the status to Patch-new, asking for another review in comment #2.  I
tell you that this patch does not pass the review because of _lots_ of
regtest differences, and tell you examples in comment #3.  Two hours
later, you resubmit a patch in comment #4 that shows the _same_ regtest
differences that I rejected the patch for.

To me, that does not look like you particularly value getting a review.
You have not fixed a single thing I pointed out.  You have not checked
your submission yourself for the problems.

My time (and my computer's time) on this issue has been totally wasted
up to now.

We have a review process for a reason.

> As I understand, fixxcc.py will correct that automatically, so I
> don't have to bother about that? Nevertheless I'll remember that
> for my future patches.

Automated changes like that of fixxcc.py make problems when merging and
rebasing.  So we usually try to catch stuff like that in advance.  There
is no point in creating more problems when one _knows_ about them
already.

> .
> 
> I didn't notice that comment. I'm not used yet to checking comments on
> Google Code.

You got the respective messages by personal mail as well unless
something went very wrong.

> Code reviews take time, effort, and diligence.  Patch testing can
> be done by yourself easily.  If it isn't, it again takes time,
> effort, and diligence.
> 
> It is a matter of courtesy not to waste those lightly, and treat
> the resources of your coworkers with the respect you want to have
> them treat yours.
> 
>
> For me it sounds like blaming me that I'm a beginner developer on
> Lilypond project, so my work isn't as optimized as it should be.

No, it is blaming you for ignoring feedback and mails sent to you with
reviews.

> It's not nice for me, really, and it doesn't encourage me to submit my
> patches either.
>
> I'd like to know how to run regtests. Should I
> follow: 
> http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison
>
> and compare all those tests that differ?

Yes, that is the respective instruction.  You get a visual comparison
for the tests that differ significantly.

But even if you don't run "make check" yourself: if I go to the pains of
listing bad files and symptoms in a review, submitting a patch without
checking at least those files means that the time and effort I spent on
the review is worth crap to you.

If your submission was treated like that, you'd be right to complain.
Instead you complain that your patches get tested, evaluated, and
repeated errors reported to you.  This takes work to do, work that
several people have volunteered for, and which nobody except myself has
actually done for several months now.

This is not motivating.  And it does not help if the work gets ignored
and one gets called a bugbear for it, to boot.

-- 
David Kastrup


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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[milimetr88]

http://codereview.appspot.com/6109046/diff/9001/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (left):

http://codereview.appspot.com/6109046/diff/9001/lily/ledger-line-spanner.cc#oldcode68
lily/ledger-line-spanner.cc:68: while (flip (&d) != DOWN);
On 2012/04/25 11:47:07, Milimetr88 wrote:

On 2012/04/25 09:57:48, dak wrote:
> This was a _one_-iteration loop.  After the change, it is a

_two_-iterations

> loop.



In http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/46279

Keith asked me

to change that in a separate commit, so I did so. Did he wanted me to

do

something else?


Ah, sorry - a mistake. The third patch set was about something else. Ok,
I'll make a commit without correcting this loop.

http://codereview.appspot.com/6109046/

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[Łukasz Czerwiński]

On 25 April 2012 11:57,  wrote:

> It would appear that you ignored
> 
> >,
> 
> >,


No - just look at dates - the comments are newer than my third patch set.

the end

of 
>
>

I have even written an answer on Keith's mail, but by mistake sent it only
to him. I wrote there:

As I understand, fixxcc.py will correct that automatically, so I don't have
to bother about that? Nevertheless I'll remember that for my future patches.



> 
> >.
>
I didn't notice that comment. I'm not used yet to checking comments on
Google Code.


> Code reviews take time, effort, and diligence.  Patch testing can be
> done by yourself easily.  If it isn't, it again takes time, effort, and
> diligence.
>
> It is a matter of courtesy not to waste those lightly, and treat the
> resources of your coworkers with the respect you want to have them treat
> yours.
>

For me it sounds like blaming me that I'm a beginner developer on Lilypond
project, so my work isn't as optimized as it should be. It's not nice for
me, really, and it doesn't encourage me to submit my patches either.

I'd like to know how to run regtests. Should I follow:
http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison and
compare all those tests that differ?


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

Re: 30 day webathon for kickstarter support (issue 6068045)

[mike]

On 2012/04/25 11:25:02, Graham Percival wrote:

First, editing embedded javascript is not a general solution.



Second, I'm not at all certain we want to have commercial

announcements in that

area.  I'm sorry if I gave the impression that this was to be a green

light for

any kind of announcement.


Why wouldn't this be a general solution?  I think that anyone who wants
to add an announcement would have to:

a) Add an entry to the array.
b) Build the website and make sure that their entry fits.

Also, in the most recent patchset I've changed my text to get rid of the
kickstarter bit.  I'll change the issue names as well.

http://codereview.appspot.com/6068045/

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

Re: 30 day webathon for kickstarter support (issue 6068045)

[graham]

First, editing embedded javascript is not a general solution.

Second, I'm not at all certain we want to have commercial announcements
in that area.  I'm sorry if I gave the impression that this was to be a
green light for any kind of announcement.

http://codereview.appspot.com/6068045/

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

Re: Brings beamed rest closer to cross staff beam. (issue 5908043)

[mike]

On 2012/04/25 11:10:40, Milimetr88 wrote:

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc
File lily/beam.cc (right):



http://codereview.appspot.com/5908043/diff/1/lily/beam.cc#newcode1326
lily/beam.cc:1326: || beam->get_property_data ("direction") ==

ly_symbol2scm

("calculation-in-progress"))
On 2012/04/25 06:29:14, mike7 wrote:
> On 2012/04/25 06:21:54, Keith wrote:
> > Mike, any idea why you added this?
> > It just adds to the cases where we lie and say the beam is on the
centerline.
> > It causes this to go wrongly
> > << {b''8[ r16. g''32] } \\ {r8 16. r } >>
> >
> > Take a look at today's patchset at
> > http://codereview.appspot.com/6035053/
>
> If this bit isn't there, a circular dependency could be called up

later on in

> the function while looking for the direction.  I forget the exact

reason for

the
> circular dependency, but it crept up in several regtests.  Like

several other

> pure functions, I have it cowardly fail if a pure estimation is not

possible

> because of circular dependencies, which usually has a minimal impact

on the

> typeset result.



I'm not well-placed to say.  I try to let the code act as its own
commentary as much as possible.  Here, I think that a person who knows
the code base knows that if the function exits because a property's
calculation is in progress, it is to avoid triggering that calculation.
However, if anyone feels that this is not pick-upable upon reading,
please add the comment!

http://codereview.appspot.com/5908043/

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

Re: Brings beamed rest closer to cross staff beam. (issue 5908043)

[milimetr88]

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc#newcode1326
lily/beam.cc:1326: || beam->get_property_data ("direction") ==
ly_symbol2scm ("calculation-in-progress"))
On 2012/04/25 06:29:14, mike7 wrote:

On 2012/04/25 06:21:54, Keith wrote:
> Mike, any idea why you added this?
> It just adds to the cases where we lie and say the beam is on the

centerline.

> It causes this to go wrongly
> << {b''8[ r16. g''32] } \\ {r8 16. r } >>
>
> Take a look at today's patchset at
> http://codereview.appspot.com/6035053/



If this bit isn't there, a circular dependency could be called up

later on in

the function while looking for the direction.  I forget the exact

reason for the

circular dependency, but it crept up in several regtests.  Like

several other

pure functions, I have it cowardly fail if a pure estimation is not

possible

because of circular dependencies, which usually has a minimal impact

on the

typeset result.


Isn't it a good idea to make a comment in the code to this part of if
condition? This would make that fragment of code clear for other
developers.

http://codereview.appspot.com/5908043/

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

Re: announcing things like Mike's tour in News column?

[m...@apollinemike.com]

On 25 avr. 2012, at 12:08, Graham Percival wrote:

> On Wed, Apr 25, 2012 at 12:00:43PM +0200, m...@apollinemike.com wrote:
>> On 25 avr. 2012, at 11:53, Graham Percival wrote:
>>> 
>>> If you really really want to have fluff pieces on the main
>>> lilypond website, I could imagine us using the top right-hand
>>> corner (Mike's "wasted space") for twitter-like announcements of
>>> concerts and editions.  Or maybe even using the entire right-hand
>>> sidebar (and moving the "quick links" horizontally between the
>>> "what is lilypond" and the news).
>>> 
>> 
>> I'm a fan!  I think the no-man's-land @ the top right can be
>> used for all sorts of announcements no longer than a tweet: new
>> LilyPond reports, concert, tours, engraving projects, etc..  It
>> can be a rotating thing so that every time someone signs on,
>> something different pops up.  I can implement that in 10 minutes
>> if people are down.
> 
> I'm down with that.  But it'll take you at least 2 hours to make
> it play nice with our entire website build system, and I'm not
> volunteering to pick up pieces if you get bored halfway through.

A cursory glance proves you to be right.  On it...

Cheers,
MS

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

Re: announcing things like Mike's tour in News column?

[Graham Percival]

On Wed, Apr 25, 2012 at 12:00:43PM +0200, m...@apollinemike.com wrote:
> On 25 avr. 2012, at 11:53, Graham Percival wrote:
> > 
> > If you really really want to have fluff pieces on the main
> > lilypond website, I could imagine us using the top right-hand
> > corner (Mike's "wasted space") for twitter-like announcements of
> > concerts and editions.  Or maybe even using the entire right-hand
> > sidebar (and moving the "quick links" horizontally between the
> > "what is lilypond" and the news).
> > 
> 
> I'm a fan!  I think the no-man's-land @ the top right can be
> used for all sorts of announcements no longer than a tweet: new
> LilyPond reports, concert, tours, engraving projects, etc..  It
> can be a rotating thing so that every time someone signs on,
> something different pops up.  I can implement that in 10 minutes
> if people are down.

I'm down with that.  But it'll take you at least 2 hours to make
it play nice with our entire website build system, and I'm not
volunteering to pick up pieces if you get bored halfway through.

> Then, the "news" bit can just be about
> releases.  It can even be renamed to "release news" so as not to
> be confused with "news news."

Nah, leave that alone.  I think that things like Janek's GSoC are
important enough that they should be in the "main news" that
doesn't rotate.

- Graham

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

Re: announcing things like Mike's tour in News column?

[David Kastrup]

Graham Percival  writes:

> On Tue, Apr 24, 2012 at 09:33:03PM +0200, Janek Warchoł wrote:
>> On Fri, Apr 20, 2012 at 11:54 PM, Graham Percival
>>  wrote:
>
>> Well then, let's have some important project news posted. I'll write a
>> note about GSoC,
>
> yes.
>
>> and i think we can make an announcement when Mike&Joe
>> finish new skylines - that's a fairly important project news.
>
> No.  Information like that goes into the Changes document.

Once it is finished, it will go there.  It is still newsworthy beyond a
technical notice, and certainly would also warrant an article (LR or
somewhere else) even while being work in progress.  It is not like that
we can't use more proofreaders on changes like that.

>> Another example: a new edition (created using LilyPond) of some
>> significant work is released (for example something similar to Open
>> Goldberg Variations) - i'd say that it's important news for the
>> project itself.
>
> I don't agree.

We do list some items of that sort somewhere, I believe.

-- 
David Kastrup

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

Re: Regarding LSR translation work

[Graham Percival]

On Tue, Apr 24, 2012 at 02:28:21PM +0200, Federico Bruni wrote:
> 2012/4/24 Graham Percival :
> >> 2) ask the LSR author to add the possibility to insert translated
> >> titles and descriptions (the website itself could benefit from this,
> >> since it may enable language negotiation). But managing the updates
> >> may be a problem..
> >
> > You'd be asking him to do about 30 hours of unpaid work.
> 
> Yes, I'm aware of it. There's nothing to lose in asking politely for a
> new feature.

You're right.  Ok, go ahead and ask Sebastiano if he would be
interested in adding multi-language support to LSR, where the
alternate languages would be output in texidoc strings inside the
.ly file.

For bonus points, ask him in Italian.  :)

> I want the documentation to look exactly the same as it does right now.
> And most of all I'd like the documentation maintainance for
> translators to be not buggy like it is now.
> 
> Python is the only requirement for this task, right?

Python, make, maybe texinfo, maybe stepmake, etc.  Depends on
exactly what you're trying to do.

> I'm trying to learn Python and I'd like to contribute to some frog
> tasks requiring python (I've starred some frog issues in the tracker).
> Probably this is too much difficult for a newbie.

Actually, I've got a good suggestion on how you could get started
with python and all this stuff.

Currently, makelsr.py adds different amounts of blank lines to
some .ly files depending on whether you run it as a full import
vs. when you run it locally.  It would be nice if that didn't
happen.  i.e. if you ran

  makelsr.py lsr-downloaded-today-date/
once, then did:
  makelsr.py
  makelsr.py lsr-downloaded-today-date/
  makelsr.py
... etc...
it shouldn't change between after each makelsr.py


As far as this type of build system stuff goes, this is a pretty
easy task.  But if you're beginning python now, I'd expect it to
take 5-10 hours for you to fix.  On the plus side, once you've
done this you'll understand the current system much better.

- Graham

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

Re: announcing things like Mike's tour in News column?

[m...@apollinemike.com]

On 25 avr. 2012, at 11:53, Graham Percival wrote:
> 
> If you really really want to have fluff pieces on the main
> lilypond website, I could imagine us using the top right-hand
> corner (Mike's "wasted space") for twitter-like announcements of
> concerts and editions.  Or maybe even using the entire right-hand
> sidebar (and moving the "quick links" horizontally between the
> "what is lilypond" and the news).
> Alternately, the top-right corner could just be a link to the
> latestlilypond report.
> 

I'm a fan!  I think the no-man's-land @ the top right can be used for all sorts 
of announcements no longer than a tweet: new LilyPond reports, concert, tours, 
engraving projects, etc..  It can be a rotating thing so that every time 
someone signs on, something different pops up.  I can implement that in 10 
minutes if people are down.  Then, the "news" bit can just be about releases.  
It can even be renamed to "release news" so as not to be confused with "news 
news."

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

Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)

[dak]

It would appear that you ignored
,
, the end
of  and
.

Code reviews take time, effort, and diligence.  Patch testing can be
done by yourself easily.  If it isn't, it again takes time, effort, and
diligence.

It is a matter of courtesy not to waste those lightly, and treat the
resources of your coworkers with the respect you want to have them treat
yours.


http://codereview.appspot.com/6109046/diff/9001/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (left):

http://codereview.appspot.com/6109046/diff/9001/lily/ledger-line-spanner.cc#oldcode68
lily/ledger-line-spanner.cc:68: while (flip (&d) != DOWN);
This was a _one_-iteration loop.  After the change, it is a
_two_-iterations loop.

http://codereview.appspot.com/6109046/diff/9001/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/6109046/diff/9001/lily/slur.cc#newcode105
lily/slur.cc:105: ret.add_point (d[dir]);
The loop does not appear to use the index downup.  Anybody have an idea
what's up with that?  This is a faithful reproduction of the original
loop, but does not appear to make sense.

http://codereview.appspot.com/6109046/

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

Re: what shall we do with GSOC subpage on the website?

[Graham Percival]

On Tue, Apr 24, 2012 at 10:14:24PM +, Carl Sorensen wrote:
> On 4/24/12 2:31 PM, "Janek Warchoł"  wrote:
> 
> >I see two possibilities:
> >- change it to "projects" or something like that.  I think it would be
> >useful to have such a list

No.  Such "projects" lists are a pain to maintain and so they're
always out of date.  I would be amazed if I saw any open-source
project with an accurate, up-to-date project list.

> Why not leave it as GSoC subpage?  We could start recruiting for 2013 at
> any time, it seems to me.

I agree, although I'd like to get "2012" onto the current page to
indicate that it's old.  That way, if nobody touches it again
until 2014, the reader at least has a clue that it may not be
accuate.

- Graham

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

Re: announcing things like Mike's tour in News column?

[Graham Percival]

On Tue, Apr 24, 2012 at 09:33:03PM +0200, Janek Warchoł wrote:
> On Fri, Apr 20, 2012 at 11:54 PM, Graham Percival
>  wrote:

> Well then, let's have some important project news posted. I'll write a
> note about GSoC,

yes.

> and i think we can make an announcement when Mike&Joe
> finish new skylines - that's a fairly important project news.

No.  Information like that goes into the Changes document.

> On the other hand, look at
> http://www.gnome.org/news/
> http://www.freebsd.org/ - they even list new contributors in the news!

New committers are not the same thing as new contributors.

> > Bottom line: I think our website should be a place of solid
> > technical details and project news.  For more "community" news, I
> > suggest that the LilyPond Report is the best venue.
> 
> I roughly agree, but how would you classify something like premiere of
> Valentin's opera?

Totally a lilypond report item.

> It was clearly a community news, but at the same
> time i think it was important for the project, as AFAIK it was the
> first such big, public project done with Lily.

That is absolutely false, and I'm sure that Valentin would agree.
The fact that nobody bothered to record concerts before that opera
doesn't mean they didn't exist.

> Another example: a new edition (created using LilyPond) of some
> significant work is released (for example something similar to Open
> Goldberg Variations) - i'd say that it's important news for the
> project itself.

I don't agree.

> > I think it needs to come from people other than the main
> > developers, though.  We're all too burnt out and overworked to get
> > enthusiastic about something like this.
> 
> Maybe.
> As for the news, i suggest a following solution: when someone feels
> like posting some news, he puts the note up for review, which will
> work mostly as a vote (whether to post it or not).

That means that only git people can submit news items?  No, I
think that sending text to Valentin for the next report is a much
easier thing for non-technical contributors to do.


If you really really want to have fluff pieces on the main
lilypond website, I could imagine us using the top right-hand
corner (Mike's "wasted space") for twitter-like announcements of
concerts and editions.  Or maybe even using the entire right-hand
sidebar (and moving the "quick links" horizontally between the
"what is lilypond" and the news).
Alternately, the top-right corner could just be a link to the
latestlilypond report.

- Graham

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

Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[Keith OHara]

On Tue, 24 Apr 2012 23:29:02 -0700,  wrote:


http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc#newcode1328
lily/beam.cc:1328: return scm_from_double (0.0);
On 2012/04/25 06:21:29, Keith wrote:

It would seem we do not want an early return in this case; if the beam
direction is not yet know, we would prefer to estimate the rest position
to returning the wrong value.


What would the "wrong value" be here?


0.0, indicating rest on centerline, is the wrong value.  If there is another 
voice, the first approximation for the rest is to avoid the other voice.  The 
only case where I see it cause trouble is when dots on a rest try to avoid dots 
in another voice, as if the rest needed to stay at centerline.


http://codereview.appspot.com/5908043/diff/1/lily/beam.cc#newcode1326
lily/beam.cc:1326: || beam->get_property_data ("direction") ==
ly_symbol2scm ("calculation-in-progress"))
On 2012/04/25 06:21:54, Keith wrote:

Mike, any idea why you added this?


If this bit isn't there, a circular dependency could be called up later
on in the function while looking for the direction.


Thanks.  Now I see.  Later on we get_grob_direction(beam) so we can pick the 
head closest to the beam.
I'll move this test down there to protect the get_grob_direction() next time I 
have Linux up.


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