Re: GOP-PROP 6: private mailing lists

[m...@apollinemike.com]

On Jul 22, 2011, at 1:59 AM, Graham Percival wrote:

> ** Private list membership?
> 
> If we want to pursue a private mailing list, rather than “whoever
> Graham thinks/remembers to cc”, then the obvious question is “who
> should be on it?”.
> 
> My initial thought is to keep it small – say, 5 people. Other than
> me, Han-Wen, and Jan, I have no firm ideas about who else.
> 
> The list of members should be public.
> 
> 

I actually like the solution "whoever Graham thinks/remembers to cc."
If someone wants to have a private discussion about accordion symbols versus 
vertical spacing, those are two different lists of people that would bring the 
most useful contributions (with a bit of overlap).

Otherwise, I don't mind private lists at all (be they ad hoc or recurrent) - it 
is an extension of free speech and free assembly, both of which seem to be in 
keeping with the idea of "free" software.  So long as the entirety of the git 
repo remains cloneable, modifiable, and resetable, I'm happy.

Cheers,
MS


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

Re: GOP-PROP 6: private mailing lists

[David Kastrup]

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

> On Jul 22, 2011, at 1:59 AM, Graham Percival wrote:
>
>> ** Private list membership?
>> 
>> If we want to pursue a private mailing list, rather than “whoever
>> Graham thinks/remembers to cc”, then the obvious question is “who
>> should be on it?”.
>> 
>> My initial thought is to keep it small – say, 5 people. Other than
>> me, Han-Wen, and Jan, I have no firm ideas about who else.
>> 
>> The list of members should be public.
>
> I actually like the solution "whoever Graham thinks/remembers to cc."
> If someone wants to have a private discussion about accordion symbols
> versus vertical spacing, those are two different lists of people that
> would bring the most useful contributions (with a bit of overlap).
>
> Otherwise, I don't mind private lists at all (be they ad hoc or
> recurrent) - it is an extension of free speech and free assembly, both
> of which seem to be in keeping with the idea of "free" software.

When there is a fixed mailing list/alias, members of that list are not
free to decide who to communicate with.

Now of course, if people choose to communicate in a private circle of
their choosing, there is nothing wrong with that.  And if there is a
Lilypond meeting somewhere, its circle of members is established (and on
multiple meetings, "round up the usual suspects" applies).  But that is
local, non-organized, non-formal.

I should certainly think that there are things one can discuss more
easily in a limited circle.  But establishing a mailing list like that,
however, means splitting the user community into a group one can and
will discuss anything with, and a group that will never be consulted
when there is at least one person in the entire public not fit for the
respective discussion.

> So long as the entirety of the git repo remains cloneable, modifiable,
> and resetable, I'm happy.

If there were plans to make this otherwise, you would not hear about
them until it is too late.

You may consider this ridiculous, but things like a GPLv3+ discussion
might result in something that may throw a spanner into somebody's
personal plans.

Other projects have "steering committees" and similar which is somewhat
more formal, in particular with regard to who enters and leaves.

-- 
David Kastrup


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

Re: Postscript printer errors with rounded barlines?

[Karl Hammar]

Han-Wen Nienhuys:
> On Thu, Jul 21, 2011 at 12:31 PM, Karl Hammar  wrote:
...
> > After "dup" there is two "blot"s, "gt" consumes one and "setlinewidth"
> > the other.
> 
> I'm sorry - I misunderstood; I thought you saw a problem with the code
> rather than the comments.

No problem. I see no problem with the code, it was just the comment
that didn't match the code.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: GOP-PROP 6: private mailing lists

[m...@apollinemike.com]

On Jul 22, 2011, at 10:21 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Jul 22, 2011, at 1:59 AM, Graham Percival wrote:
>> 
>>> ** Private list membership?
>>> 
>>> If we want to pursue a private mailing list, rather than “whoever
>>> Graham thinks/remembers to cc”, then the obvious question is “who
>>> should be on it?”.
>>> 
>>> My initial thought is to keep it small – say, 5 people. Other than
>>> me, Han-Wen, and Jan, I have no firm ideas about who else.
>>> 
>>> The list of members should be public.
>> 
>> I actually like the solution "whoever Graham thinks/remembers to cc."
>> If someone wants to have a private discussion about accordion symbols
>> versus vertical spacing, those are two different lists of people that
>> would bring the most useful contributions (with a bit of overlap).
>> 
>> Otherwise, I don't mind private lists at all (be they ad hoc or
>> recurrent) - it is an extension of free speech and free assembly, both
>> of which seem to be in keeping with the idea of "free" software.
> 
> When there is a fixed mailing list/alias, members of that list are not
> free to decide who to communicate with.
> 

I disagree - members of that list are free to choose to subscribe subject to 
the list and therefore its terms.  The freedom to selectively desabjugate one's 
freedoms is a freedom.

> Now of course, if people choose to communicate in a private circle of
> their choosing, there is nothing wrong with that.  And if there is a
> Lilypond meeting somewhere, its circle of members is established (and on
> multiple meetings, "round up the usual suspects" applies).  But that is
> local, non-organized, non-formal.
> 

Even when it is formal, it is a choice.  I receive the lilypond-devel e-mails 
because I chose to.

> I should certainly think that there are things one can discuss more
> easily in a limited circle.  But establishing a mailing list like that,
> however, means splitting the user community into a group one can and
> will discuss anything with, and a group that will never be consulted
> when there is at least one person in the entire public not fit for the
> respective discussion.
> 
>> So long as the entirety of the git repo remains cloneable, modifiable,
>> and resetable, I'm happy.
> 
> If there were plans to make this otherwise, you would not hear about
> them until it is too late.

The presence or absence of a list would have no impact on this.  I think that 
putting limits on who talks to who and in what conditions is not a fruitful 
debate.  If Bertrand and I decide to establish a private LilyPond list that 
no-one but use two uses, GOP-PROP 6 will have no bearing on what we do.  The 
sole issue of trust is one of representation, and I think that Graham 
represents the project very well and can decide who to pass certain discussions 
onto.

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

Re: GOP-PROP 6: private mailing lists

[Trevor Daniels]

Graham Percival wrote Friday, July 22, 2011 12:59 AM



What should we do with potentially sensitive or private matters in
lilypond? I see two possible solutions:

  1. Pick one person to manage private discussions. Whenever
there is a potentially sensitive topic, send an email to that
person. He will then decide who should discuss the issue on an
ad-hoc basis, and forward or CC them on future emails.
  2. Have a private mailing list with a known list of people who
will discuss such matters. That list may still have a single
“secretary” who receives initial emails, but that person will then
have a set list of people to discuss such topics with.


I would be in favour of a fixed private mailing list with publicly
known members to decide a publicly known list of issues,
including the obvious granting/withdrawing git push access,
but probably little else.  Membership should be either Graham,
Han-Wen and Jan, or these three supplemented by two others.
Requests for a private discussion would be sent to this list,
avoiding the single-Graham point of failure.

Other issues which are better discussed in private should be
conducted by an ad hoc group chosen to suit the issue, since
these are likely to be rare and diverse.  The membership of
such groups could be on the list of issues decided on the
private mailing list described above.

Trevor



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

Re: stable/2.14 can't make doc

[Francisco Vila]

2011/7/22 Graham Percival :
> Could somebody try to make doc in stable/2.14, and fix whatever's
> necessary to fix?  I don't know exactly what the problem is, but
> since it's a doc build problem, the problem is hidden somewhere in
> a 49480-line logfile, but I'm not going to dig through an 8-thread
> build on a computer that's behind three ssh connections to try to
> figure out what it is.
>
> I know it died in snippets.texi, but that's all I can find in 5
> minutes of looking at the log files.  (at that point, the ssh
> connection died (or at least had a lag of more than 60 seconds),
> so I gave up)

generating-custom-flags.ly blocks my whole system for some minutes,
then aborts with

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Postscript printer errors with rounded barlines?

[Francisco Vila]

2011/7/22 Graham Percival :
> On Thu, Jul 21, 2011 at 11:45:51PM -0300, Han-Wen Nienhuys wrote:
>>
>> This should be backported.  Do we have a special procedure for that nowadays?
>
> Yes, add "backport" to a google tracker issue about it.  But I
> think you just missed the deadline for 2.14.3

You mean 2.14.2

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)

[Phil Holmes]

- Original Message - 
From: 
To: ; ; 


Cc: ; 
Sent: Tuesday, July 12, 2011 3:39 PM
Subject: Re: Adds redirect-lilypond-output option to 
lilypond-book(issue4664060)




in light of the growing consensus for "combined" logfiles for the build
system -- and given that lilypond only produces stuff on stderr and
apparently this isn't going to change -- I wonder if it might be better
to redirect both stdout and sterr to a single .log file.

I'm happy with pushing this patch as-is and changing this later, though.

http://codereview.appspot.com/4664060/


This was pushed as 23cdda9506931d5b9a1e75ee8be8b74f9084a7c0


--
Phil Holmes



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

Re: Issue 1724 -> 620 : workaround?

[Xavier Scheuer]

On 20 July 2011 21:15, m...@apollinemike.com  wrote:
>
> I ran into the exact same thing in a score I'm working on and proposed
> a patch to devel - lemme know what ya'll think!

Thanks a lot Mike (and Neil too, of course)!

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: stable/2.14 can't make doc

[Francisco Vila]

2011/7/22 Francisco Vila :
> 2011/7/22 Graham Percival :
>> Could somebody try to make doc in stable/2.14, and fix whatever's
>> necessary to fix?  I don't know exactly what the problem is, but
>> since it's a doc build problem, the problem is hidden somewhere in
>> a 49480-line logfile, but I'm not going to dig through an 8-thread
>> build on a computer that's behind three ssh connections to try to
>> figure out what it is.
>>
>> I know it died in snippets.texi, but that's all I can find in 5
>> minutes of looking at the log files.  (at that point, the ssh
>> connection died (or at least had a lag of more than 60 seconds),
>> so I gave up)
>
> generating-custom-flags.ly blocks my whole system for some minutes,
> then aborts with
>
> terminate called after throwing an instance of 'std::bad_alloc'
>  what():  std::bad_alloc

Which is absurd, I must add; no meaningful changes to this file are
made since sep 2010.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

LilyPond releases and GLISS roadmap

[Xavier Scheuer]

On 22 July 2011 05:47, Graham Percival  wrote:
>
> Yes, add "backport" to a google tracker issue about it.  But I
> think you just missed the deadline for 2.14.3, and I'm not certain
> if we'll have any more 2.14 releases.  First 2.16 release
> candidate is in 10 days.

Hi Graham,

Is there a roadmap of future releases of LilyPond (2.16, 2.18, 3.0),
as well as a roadmap for the GLISS available somewhere on the LilyPond
website?

Actually there has been a request on the French users mailing list that
is actually issue #1316, which is currently "Priority-Postponed" waiting
for the GLISS.

On CG 14.5 "Grand LilyPond Input Syntax Standardization (GLISS)" it is
said that

  [GLISS will start] sortly after 2.14 comes out, which is currently
  estimated to happen in January 2011.

sic!

Where could we find up-to-date information about future LilyPond
releases and "Grand Projects" roadmaps?

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: PATCH: 48-hour countdown

[Xavier Scheuer]

On 21 July 2011 04:24, Colin Campbell  wrote:
>
> Issue 1735: modifying default behaviour of tremolo slashes - Rietveld Issue
> 4636081: modifying default behaviour of tremolo slashes

[Not sure how it works, but]
Please wait for issue 1735.
Joe reviewed it yesterday and made some changes, about which Janek has
not replied back yet.
http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode42

And I asked to keep current settings as default (and suggested not to
blindly follow Elaine Gould, but instead see real practices and/or make
a little user survey about what should be default tremolo slashes
settings).
http://code.google.com/p/lilypond/issues/detail?id=1735#c5

Thanks in advance.

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: stable/2.14 can't make doc

[Francisco Vila]

2011/7/22 Francisco Vila :
> 2011/7/22 Francisco Vila :
>> 2011/7/22 Graham Percival :
>>> Could somebody try to make doc in stable/2.14, and fix whatever's
>>> necessary to fix?  I don't know exactly what the problem is, but
>>> since it's a doc build problem, the problem is hidden somewhere in
>>> a 49480-line logfile, but I'm not going to dig through an 8-thread
>>> build on a computer that's behind three ssh connections to try to
>>> figure out what it is.
>>>
>>> I know it died in snippets.texi, but that's all I can find in 5
>>> minutes of looking at the log files.  (at that point, the ssh
>>> connection died (or at least had a lag of more than 60 seconds),
>>> so I gave up)
>>
>> generating-custom-flags.ly blocks my whole system for some minutes,
>> then aborts with
>>
>> terminate called after throwing an instance of 'std::bad_alloc'
>>  what():  std::bad_alloc
>
> Which is absurd, I must add; no meaningful changes to this file are
> made since sep 2010.

I have found a probable cause in anglican-psalm-template.ly which has
remains of << HEAD conflict marks in that branch.  I could make a
patch or else wait for confirmation.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: stable/2.14 can't make doc

[Francisco Vila]

2011/7/22 Francisco Vila :
> I have found a probable cause in anglican-psalm-template.ly which has
> remains of << HEAD conflict marks in that branch.  I could make a
> patch or else wait for confirmation.

A patch.  It applies to stable/2.14 only.

Sorry for the chat style.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From 92206afcb3073b8b7e9c8be01bafd3181084f3a2 Mon Sep 17 00:00:00 2001
From: Francisco Vila 
Date: Fri, 22 Jul 2011 12:45:35 +0200
Subject: [PATCH] Stable build fix.

---
 Documentation/snippets/anglican-psalm-template.ly |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/Documentation/snippets/anglican-psalm-template.ly b/Documentation/snippets/anglican-psalm-template.ly
index 83e78b5..056f2d1 100644
--- a/Documentation/snippets/anglican-psalm-template.ly
+++ b/Documentation/snippets/anglican-psalm-template.ly
@@ -20,11 +20,6 @@ le varie possibilità.
   lsrtags = "vocal-music, template"
 
 
-<<< HEAD
-===
-
-
->>> c3b519f... Doc-it: fix translations in snippets. Run makelsr.
 %% Translation of GIT committish: 144cd434d02e6d90b2fb73899119a7c5e1d2
 
   texidocde = "
-- 
1.7.4.1

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

Re: GOP-PROP 6: private mailing lists

[Werner LEMBERG]

>> If we want to pursue a private mailing list, rather than “whoever
>> Graham thinks/remembers to cc”, then the obvious question is “who
>> should be on it?”.
> 
> I actually like the solution "whoever Graham thinks/remembers to
> cc."

Me too.  I've subscribed to far too much mailing lists already...


Werner

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

Re: stable/2.14 can't make doc

[Carl Sorensen]

I found the same thing, patched it, built docs, and pushed it.

Thanks,

Carl



On 7/22/11 4:49 AM, "Francisco Vila"  wrote:

> 2011/7/22 Francisco Vila :
>> I have found a probable cause in anglican-psalm-template.ly which has
>> remains of << HEAD conflict marks in that branch.  I could make a
>> patch or else wait for confirmation.
> 
> A patch.  It applies to stable/2.14 only.
> 
> Sorry for the chat style.
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com


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

Re: PATCH: 48-hour countdown

[Colin Campbell]

On 11-07-22 04:00 AM, Xavier Scheuer wrote:

On 21 July 2011 04:24, Colin Campbell  wrote:

Issue 1735: modifying default behaviour of tremolo slashes - Rietveld Issue
4636081: modifying default behaviour of tremolo slashes

[Not sure how it works, but]
Please wait for issue 1735.
Joe reviewed it yesterday and made some changes, about which Janek has
not replied back yet.
http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode42

And I asked to keep current settings as default (and suggested not to
blindly follow Elaine Gould, but instead see real practices and/or make
a little user survey about what should be default tremolo slashes
settings).
http://code.google.com/p/lilypond/issues/detail?id=1735#c5

Thanks in advance.

Cheers,
Xavier




Thanks, Xavier!  I've taken it off the list and set it to "patch needs 
work".


Cheers,

Colin

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

 



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

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

[reinhold . kainhofer]

On 2011/07/21 18:38:04, Neil Puttock wrote:

Those are recent doc changes added by Joe.  If you look elsewhere,
you'll see that all nested overrides use list syntax (I converted all
the docs when I add the support back in 2008).


Okay, I have changed that back and pushed to git master.


http://codereview.appspot.com/4805043/

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

Re: PATCH: 48-hour countdown

[Reinhold Kainhofer]

Am Donnerstag, 21. Juli 2011, 04:24:07 schrieb Colin Campbell:
> Issue 1770: \displayLilyMusic causes error with \oneVoice - Rietveld Issue
> 4805043: Fix 1770: revert caused a crash in displayLilyMusic.

I have already pushed this after fixing Neil's concerns, because I'm going on 
vacation tomorrow morning for a week and I don't know if I'll be able to do 
any LilyPond work during that time.

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

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

Re: Fix issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none over a line break) (issue4630070)

[reinhold . kainhofer]

Uploaded new patch that fixes all of Neil's concerns and clean up the
regtests a bit. AFAICT, this should now be the final patch.


http://codereview.appspot.com/4630070/diff/17001/input/regression/dynamics-alignment-breaker-linebreak.ly
File input/regression/dynamics-alignment-breaker-linebreak.ly (right):

http://codereview.appspot.com/4630070/diff/17001/input/regression/dynamics-alignment-breaker-linebreak.ly#newcode5
input/regression/dynamics-alignment-breaker-linebreak.ly:5: dynamic
spanner is across a line break.
On 2011/07/21 18:48:50, Neil Puttock wrote:

crosses a line break


Changed, thanks.

http://codereview.appspot.com/4630070/diff/17001/input/regression/dynamics-alignment-breaker-linebreak.ly#newcode9
input/regression/dynamics-alignment-breaker-linebreak.ly:9: % Both lines
should give the same output, although the \breakDynamicSpan
On 2011/07/21 18:48:50, Neil Puttock wrote:

should go in texidoc



Edit: actually, I'm a bit confused since there are three lines and

they're all

different


I have now completely redone the regtests, splitting them up into
several smaller tests. In this test I was actually checking three
different things at once (line breaks, exact position of
\breakDyanmicSpan, and that the break does not have an effect on
subsequent spanners).

http://codereview.appspot.com/4630070/diff/17001/input/regression/dynamics-alignment-breaker.ly
File input/regression/dynamics-alignment-breaker.ly (left):

http://codereview.appspot.com/4630070/diff/17001/input/regression/dynamics-alignment-breaker.ly#oldcode12
input/regression/dynamics-alignment-breaker.ly:12: \dimTextDim
Added that again, so make check should not show and difference to
before.

http://codereview.appspot.com/4630070/diff/17001/lily/dynamic-align-engraver.cc
File lily/dynamic-align-engraver.cc (right):

http://codereview.appspot.com/4630070/diff/17001/lily/dynamic-align-engraver.cc#newcode49
lily/dynamic-align-engraver.cc:49: Spanner *ended_line_; // Spanner was
manually broken, create a new one, but store the old so we can properly
finish it.
On 2011/07/21 18:48:50, Neil Puttock wrote:

comment is a bit long


Shortened

http://codereview.appspot.com/4630070/diff/17001/lily/dynamic-align-engraver.cc#newcode93
lily/dynamic-align-engraver.cc:93: programming_error ("Already have a
force-ended DynamicLineSpanner.");
On 2011/07/21 18:48:50, Neil Puttock wrote:

"already have a force-ended DynamicLineSpanner"


Changed

http://codereview.appspot.com/4630070/diff/17001/lily/dynamic-align-engraver.cc#newcode134
lily/dynamic-align-engraver.cc:134: // TODO: Compare the direction of
the existing spanner with
On 2011/07/21 18:48:50, Neil Puttock wrote:

remove



(issue #)


Actually, I explicitly added it because of issue # to mark the
possible entry point for a fix.

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

http://codereview.appspot.com/4630070/diff/17001/scm/define-grob-properties.scm#newcode780
scm/define-grob-properties.scm:780: (spanner-broken ,boolean? "Indicates
whether dynamics spanner
On 2011/07/21 18:48:50, Neil Puttock wrote:

internal?


Okay, made it internal.


I'd remove any reference to dynamics here, since this is generic

enough to be

useful elsewhere (e.g. pedals)


Good idea.

http://codereview.appspot.com/4630070/

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

Re: Music functions with pitch and duration arguments

[Han-Wen Nienhuys]

On Fri, Jul 22, 2011 at 3:32 AM, David Kastrup  wrote:

>>> Anyway, this is not particularly complex either.  Could possibly pave
>>> the way for a nicer function for setting up strings for tabulatures.
>>> Also stuff like \transpose can be implemented by users with a
>>> straightforward syntax accepting just pitches where pitches are asked
>>> for, without the user needing to disassemble music in order to get at
>>> the pitch somewhere in the center of the mess.
>>
>> It would be awesome to implement \transpose (and relative, for that
>> matter) as a music function.
>
> Not likely a speed gain.


It's not for speed. I have always been annoyed by the special parser
rules for those, so it would be neat to be able to drop those.


>> It seems to be missing the init for the _proc variables you added,
>> though.
>
> No.  They are created by the existing calls of IMPLEMENT_TYPE_P in
> pitch.cc and duration.cc and initialized there.

Ah, I forgot.  LGTM then.

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

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

Re: LilyPond releases and GLISS roadmap

[Valentin Villenave]

On Fri, Jul 22, 2011 at 11:49 AM, Xavier Scheuer  wrote:
>  [GLISS will start] sortly after 2.14 comes out, which is currently
>  estimated to happen in January 2011.
>
> sic!

I may be mistaken, but I believe that GOP takes precedence over GLISS;
as far as roadmaps go, you can try this one on for size:
http://lilypond.org/~graham/gop/index.html

Cheers,
Valentin.

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

Re: GOP-PROP 6: private mailing lists

[Valentin Villenave]

On Fri, Jul 22, 2011 at 10:49 AM, Trevor Daniels  wrote:
> I would be in favour of a fixed private mailing list with publicly
> known members to decide a publicly known list of issues,
> including the obvious granting/withdrawing git push access,
> but probably little else.  Membership should be either Graham,
> Han-Wen and Jan, or these three supplemented by two others.
> Requests for a private discussion would be sent to this list,
> avoiding the single-Graham point of failure.

Once again, you make some excellent points.However if said list has to
be limited to *five* people, I do question the need for a mailing list
at all, rather than merely CCing whomever needs to be CCed.

The whole point of mailing lists, in my opinion, is archives: if this
list's archives are not meant to be made public, ever, then I'm
certainly missing the point (assuming there's one) of having a mailing
list.
I personally have been spending days browsing through the LilyPond and
Guile mailing list archives, including very old (sometimes heated or
controversial) discussions that nobody really cares about today.
Therefore I have been suggesting that archives could be "declassified"
after a given amount of time (five or seven years seem quite enough
for any sensitive debate to cool off and lose any potential
disruptiveness).

No matter how, a key issue, as you pointed out, is that the list of
people in charge, as well as the general topics they discuss, should
be made public. And first off, obviously, it should be officially
acknowledged that such non-public discussions exist.

(Mild) cheers,
Valentin.

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

Re: GOP-PROP 6: private mailing lists

[Trevor Daniels]

Valentin Villenave wrote Friday, July 22, 2011 7:20 PM


On Fri, Jul 22, 2011 at 10:49 AM, Trevor Daniels 
 wrote:


I would be in favour of a fixed private mailing list with 
publicly

known members to decide a publicly known list of issues,
including the obvious granting/withdrawing git push access,
but probably little else. Membership should be either Graham,
Han-Wen and Jan, or these three supplemented by two others.
Requests for a private discussion would be sent to this list,
avoiding the single-Graham point of failure.


Once again, you make some excellent points.However if said list 
has to
be limited to *five* people, I do question the need for a mailing 
list

at all, rather than merely CCing whomever needs to be CCed.


Well, a list serves at least two purposes.  The list name is made
public so external organisations as well as LilyPond users can
easily mail it.  And it removes the single point of failure.

I'm less sure about making archives public.  Do we really want to
know five years later what discussions went on before so-and-so
was granted git push access?  What purpose would that serve?

Trevor


Trevor



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

Re: DOC: fix NR 1.6.3 Formatting Cue Notes (Issue 1762) (issue4808051)

[percival . music . ca]

http://codereview.appspot.com/4808051/diff/1/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):

http://codereview.appspot.com/4808051/diff/1/Documentation/notation/staff.itely#newcode1319
Documentation/notation/staff.itely:1319: In the above example, the
@code{Voice} context had to be
I'm ok with this change on temporary measure, but we normally place all
material above examples (i.e. you should never refer to "the above
example", for precisely this kind of reason).

Either email the patch to James for pushing right now, or slightly
reword this sentence and put it above the example (at the end of the
existing paragraph).

http://codereview.appspot.com/4808051/

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

Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)

[pkx166h]

Make works but fails on reg test check.

---snip--
Processing
`/home/jlowe/lilypond-git/build/out/lybook-testdb/aa/lily-c55a6eaf.ly'
Parsing...
Renaming input to:
`/home/jlowe/lilypond-git/input/regression/quote-cyclic.ly'
Interpreting music...
Interpreting music...
Interpreting music... ERROR: Value out of range: 0

--snip--

\sourcefilename
"/home/jlowe/lilypond-git/input/regression/quote-cyclic.ly"

James

http://codereview.appspot.com/4816044/

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

Re: Music functions with pitch and duration arguments

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jul 22, 2011 at 3:32 AM, David Kastrup  wrote:
>
 Anyway, this is not particularly complex either.  Could possibly pave
 the way for a nicer function for setting up strings for tabulatures.
 Also stuff like \transpose can be implemented by users with a
 straightforward syntax accepting just pitches where pitches are asked
 for, without the user needing to disassemble music in order to get at
 the pitch somewhere in the center of the mess.
>>>
>>> It would be awesome to implement \transpose (and relative, for that
>>> matter) as a music function.
>>
>> Not likely a speed gain.
>
>
> It's not for speed. I have always been annoyed by the special parser
> rules for those, so it would be neat to be able to drop those.
>
>
>>> It seems to be missing the init for the _proc variables you added,
>>> though.
>>
>> No.  They are created by the existing calls of IMPLEMENT_TYPE_P in
>> pitch.cc and duration.cc and initialized there.
>
> Ah, I forgot.  LGTM then.

I'll try fudging up documentation for it, and I'll check the
perspectives for minimizing the combinations of duration and music
arguments that are not either accepted or flagged with a proper error
message rather than a generic syntax error.

With regard to merging: this is an incompatible change since arguments
of type ly:pitch? or ly:duration? previously asked for Scheme arguments
like
#(ly:make-pitch ... or #(ly:make-duration

The Lilypond codebase does not contain such music function arguments I
think.  It should actually work to convert them to
#(ly:export (ly:make-pitch ...
so there is a straightforward (but more likely than not untowardly
awkward) migration path.

Apart from this change in semantics, this should not cause regressions.

-- 
David Kastrup


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

Fix 732: center-column ignored left half of stencil extent -> collision with previous stencil (issue4798050)

[pkx166h]

Passes Make - two reg tests showed differences but these are trivial I
think.

See http://code.google.com/p/lilypond/issues/detail?id=732#c6

http://codereview.appspot.com/4798050/

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

Fix 1111: Break dynamic line spanner if different direction is explicitly given (issue4810048)

[pkx166h]

Assuming the patch for issue 1433 and issue 1259 is ok, I have applied
this patch on top of that one and make works fine, I get one reg test
difference (see
http://code.google.com/p/lilypond/issues/detail?id=#c4) but am
guessing that this is ok.

http://codereview.appspot.com/4810048/

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

Re: git-cl is down

[Bertrand Bordage]

What are we doing then? We only update git-cl's repository in the CG?

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

Re: Fix 153: \once\set properly restores the context property (issue4810042)

[pkx166h]

pass make and reg tests.

James

http://codereview.appspot.com/4810042/

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

Review music functions with pitch and duration arguments (was: Music functions with pitch and duration arguments)

[David Kastrup]

David Kastrup  writes:

> Han-Wen Nienhuys  writes:
>
>> Ah, I forgot.  LGTM then.
>
> I'll try fudging up documentation for it,

Frankly, music function docs are awful.  I've polished them up somewhat
with the new info.  The result is not really satisfactory but better
than before.

> and I'll check the perspectives for minimizing the combinations of
> duration and music arguments that are not either accepted or flagged
> with a proper error message rather than a generic syntax error.

Looks pretty good now with regard to accepting stuff as long as a music
argument is not followed by a duration argument.  If it is, the current
reaction is still a syntax error.  Not all too pretty, but not a
regression either.

> With regard to merging: this is an incompatible change since arguments
> of type ly:pitch? or ly:duration? previously asked for Scheme arguments
> like
> #(ly:make-pitch ... or #(ly:make-duration
>
> The Lilypond codebase does not contain such music function arguments I
> think.  It should actually work to convert them to
> #(ly:export (ly:make-pitch ...
> so there is a straightforward (but more likely than not untowardly
> awkward) migration path.
>
> Apart from this change in semantics, this should not cause
> regressions.

I put the current state up on Rietveld at
http://codereview.appspot.com/4811047>

I don't have a usage example to go with the patch though.  If somebody
has something nice to offer...

-- 
David Kastrup


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

Re: LilyPond releases and GLISS roadmap

[Graham Percival]

On Fri, Jul 22, 2011 at 11:49:40AM +0200, Xavier Scheuer wrote:
> Is there a roadmap of future releases of LilyPond (2.16, 2.18, 3.0),

That discussion will happen in GOP:
http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions

> as well as a roadmap for the GLISS available somewhere on the LilyPond
> website?

That is not yet written.

> Actually there has been a request on the French users mailing list that
> is actually issue #1316, which is currently "Priority-Postponed" waiting
> for the GLISS.

It will wait some more.

> On CG 14.5 "Grand LilyPond Input Syntax Standardization (GLISS)" it is
> said that
> 
>   [GLISS will start] sortly after 2.14 comes out, which is currently
>   estimated to happen in January 2011.

I suppose I should change that.

> Where could we find up-to-date information about future LilyPond
> releases and "Grand Projects" roadmaps?

You can't.

I do 10 hours a week.  I'm not going to start GLISS until I have
at least 4 weeks of GOP policy questions prepared for discussion,
and at least 2 weeks of GLISS material prepared.  The more
"mundane tasks" people do, the more time I'll have for "unusual"
stuff like GOP and GLISS.

Admittedly, Colin and James are doing a fantastic job of keeping
patches rolling along for the past few weeks.  I've fallen behind
because I'm at the annual family music camp.
  http://wcams.com/
which we do a lot of organizing for, in addition to attending for
about 20 years now (I missed 2 years in that period, so I'm only
at 18 years so far).

This year, I'm skipping the main orchestra in order to keep
up-to-date with lilypond emails (much to the disgust of some other
violinists here who feel that I'm "letting down the team" by not
playing in the orchestra).  So I still have 10 hours left this
week, and that will carry over into next week.

With that extra time, I hope to schedule GOP stuff for all of
August and even reaching into Sep.  Once that's done, I'll do more
preparation for GLISS, but I would be surprised if we start that
in August.  Depends a lot of how many release issues there are for
2.16.

Cheers,
- Graham

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

Re: PATCH: 48-hour countdown

[Colin Campbell]

On 11-07-22 06:50 AM, Reinhold Kainhofer wrote:

Am Donnerstag, 21. Juli 2011, 04:24:07 schrieb Colin Campbell:

Issue 1770: \displayLilyMusic causes error with \oneVoice - Rietveld Issue
4805043: Fix 1770: revert caused a crash in displayLilyMusic.

I have already pushed this after fixing Neil's concerns, because I'm going on
vacation tomorrow morning for a week and I don't know if I'll be able to do
any LilyPond work during that time.

Cheers,
Reinhold



Works for me, Reinhold.  Have a great time away!

Cheers,
Colin

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

 



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

PATCH: 72 hour countdown

[Colin Campbell]

New today, for 21:00 MDT Monday July 25

   Issue 153 : 
\once \set fails to restore previous setting - Rietveld Issue 4810042 
: Fix 153: \once\set properly 
restores the context property
   Issue 620 : 
It should be possible to specify more specific spanner bounds. - 
Rietveld Issue 4814041 : Fix for 
Issue 620.
   Issue 1678 
: Midi gives 
false warnings - Rietveld Issue 4757043 
: MIDI: reset channel counters 
when done; issue 1678
   Issue 1433 
: 
\breakDynamicSpan breaks with \break ("bounds of spanner are invalid") - 
Rietveld Issue 4630070 : Fix 
issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none 
over a line break)
  Issue 1259 : 
DynamicTextSpanner #'style = #'none doesn't work over \break


And a couple of Rietveld-only patches:

  Issue 4754054 : Fixes note 
column skylines by adding a stem tremolo pure height function.
  Issue 4801045 : Produces 
better error messages when programmers forget to document a property.


And finally, my hearfelt thanks to you all: there are no "holdovers" 
from the last patch batch!


cheers,

Colin

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

 

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

stable/2.14 still can't make doc

[Graham Percival]

Presumably a different problem this time?

I know that Carl is either flying to Korea, or just about to fly
to Korea, so could somebody else look into this?  You should be
able to "make doc" on stable/2.14 from scratch.  It doesn't work
in plain old git.

Cheers,
- Graham

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