Re: Tie properties vs. slur properties.

2016-05-27 Thread David Kastrup
tisimst  writes:

> On Thu, May 26, 2016 at 12:50 AM, David Kastrup [via Lilypond] <
> ml-node+s1069038n190980...@n5.nabble.com> wrote:
>>
>> I'm not particularly enamored with the details either, but if you
>> take a look at stuff like the harp diagram details, they are really a
>> long long list.  Overriding all of them individually is effort.
>>
>
> Ah, yes. That makes sense. Thank you for making it possible to do both
> Grob.details.property and Grob.details = #'((property . ...))

That one wasn't my idea.  I merely reimplemented it in order to make it
work reliably with predictable semantics without putting too much of a
downer on performance.  It wasn't used heavily before partly because it
was a bit hit-and-miss once you tried combining it with reverts (and
since the default for \override is to revert before setting, this does
not exactly happen rarely).

-- 
David Kastrup

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


Protect Grob_interface<>::interface_symbol_ (issue 299170043 by d...@gnu.org)

2016-05-27 Thread dak

Reviewers: ,

Message:
Well, after lots of code analysis, I'm less sure about this making a
crucial difference (except for saving lots of code analysis which is
worthwhile in itself).

Description:
Protect Grob_interface<>::interface_symbol_

I suspect this to be the culprit for our recent patchy/stability
problem.

Please review this at https://codereview.appspot.com/299170043/

Affected files (+3, -2 lines):
  M lily/include/grob-interface.hh


Index: lily/include/grob-interface.hh
diff --git a/lily/include/grob-interface.hh b/lily/include/grob-interface.hh
index  
9c3eadb4b06b7deccf252f2cabfbe65f4cc91fa1..bde5f5263d4130091afbd44a803501ee9fc9da69  
100644

--- a/lily/include/grob-interface.hh
+++ b/lily/include/grob-interface.hh
@@ -21,6 +21,7 @@
 #define INTERFACE_HH

 #include "lily-guile.hh"
+#include "protected-scm.hh"

 class Grob;

@@ -57,14 +58,14 @@ private:
   friend bool has_interface(Grob *);

 private:
-  static SCM interface_symbol_;
+  static Protected_scm interface_symbol_;
   static char const *cxx_name_;
   static char const *description_;
   static char const *variables_;
 };

 template 
-SCM Grob_interface::interface_symbol_;
+Protected_scm Grob_interface::interface_symbol_;

 #endif /* INTERFACE_HH */




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


Patch

2016-05-27 Thread Steven Weber
Hey lily-dev!

 

Since I don't have an official mentor and the recommendation is that you
send your first couple of patches to your mentor first, I thought I'd send
it to the list and see if someone can take a look.

 

This patch adds the non-default property to the KeySignature grob - it
behaves exactly like the non-default property on the Clef grob.  I've tested
it out in my dev environment and it does what I expect it to do.

 

Any feedback or next steps I should take?

 

Thanks!

 

--Steven



0001-Added-non-default-property-to-the-key-signature-grob.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Patch

2016-05-27 Thread Urs Liska
Am 27.05.2016 um 06:11 schrieb Steven Weber:
> Hey lily-dev!
> 
>  
> 
> Since I don't have an official mentor and the recommendation is that you
> send your first couple of patches to your mentor first, I thought I'd send
> it to the list and see if someone can take a look.
> 

I think this is a good first step.

>  
> 
> This patch adds the non-default property to the KeySignature grob - it
> behaves exactly like the non-default property on the Clef grob.  I've tested
> it out in my dev environment and it does what I expect it to do.
> 
>  
> 
> Any feedback or next steps I should take?

provide us with a test file and explanations what it should do.

Go to the Contributor's Guide and try figuring out what is necessary to
upload your patch for review.

I think the first two pages should be

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

and

http://lilypond.org/doc/v2.19/Documentation/contributor/uploading-a-patch-for-review

Probably you'll need some more context from the chapters 2 and 3 as well.

When you have set up your system properly you should come back to us and
ask for the necessary accounts to upload the patch for review.

Once you have successfully uploaded your patch and passed the whole
review cycle someone else will have to push it for you. At some later
point, when you have submitted a certain number of patches you may ask
far push access yourself.

HTH
Urs

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


-- 
Urs Liska
www.openlilylib.org

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


Re: Still cannot make doc :(

2016-05-27 Thread David Kastrup
James  writes:

> Hello,
>
> I still cannot make doc and so cannot merge staging - and for those
> waiting on me to test new patches, I cannot do that with any great
> reliability either.

Fiddlesticks.  I was afraid that this would be the case but it was worth
a try.

> I am sorry this is incredibly frustrating.

Sorry.

> I don't have time right now to set up a LilyDev env to try it for
> myself and will not have the time until at least Saturday evening.

I don't think that the problem can be reduced to a code generation issue
(which would explain that it gets seen only on certain systems likely
depending on GCC version and/or machine architecture) because the
changes of the incriminated patch do not introduce markedly different
code from before.  If anything, it removes code.

-- 
David Kastrup

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


Re: Patch

2016-05-27 Thread Thomas Morley
2016-05-27 6:11 GMT+02:00 Steven Weber :
> Hey lily-dev!
>
>
>
> Since I don't have an official mentor and the recommendation is that you
> send your first couple of patches to your mentor first, I thought I'd send
> it to the list and see if someone can take a look.
>
>
>
> This patch adds the non-default property to the KeySignature grob - it
> behaves exactly like the non-default property on the Clef grob.  I've tested
> it out in my dev environment and it does what I expect it to do.
>
>
>
> Any feedback or next steps I should take?
>
>
>
> Thanks!
>
>
>
> --Steven



Hi Steven,

please ask Trevor or Phil for developer-status at source-forge. (cc-ing both)
Once this is done use git-cl to upload your patch. More in CG.
An issue at sourceforge will be opened automatically and the patch
itself will be put up on Rietveld.
Then the usual patch-review-circle will start.

Thanks,
  Harm

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


Still cannot make doc :(

2016-05-27 Thread James

Hello,

I still cannot make doc and so cannot merge staging - and for those 
waiting on me to test new patches, I cannot do that with any great 
reliability either.


I am sorry this is incredibly frustrating.

@Phil would it be possible for you to run Patchy Merge on your system 
and see if you can get this to work. I believe that you still use a 
LilyDev version rather than what I do - use another distribution - and 
that you are not seeing this problem. Other than LilyDev being 32bit, I 
thing you still use multiple cores?


I don't have time right now to set up a LilyDev env to try it for myself 
and will not have the time until at least Saturday evening.


Regards

James

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


Re: Still cannot make doc :(

2016-05-27 Thread David Kastrup
James  writes:

> Hello,
>
> I still cannot make doc and so cannot merge staging - and for those
> waiting on me to test new patches, I cannot do that with any great
> reliability either.
>
> I am sorry this is incredibly frustrating.
>
> @Phil would it be possible for you to run Patchy Merge on your system
> and see if you can get this to work.

I've started one just now on my laptop.  It just takes significantly
North of one hour to complete.

-- 
David Kastrup

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


Re: Still cannot make doc :(

2016-05-27 Thread Phil Holmes
- Original Message - 
From: "David Kastrup" 

To: "James" 
Cc: "lilypond-devel" 
Sent: Friday, May 27, 2016 3:36 PM
Subject: Re: Still cannot make doc :(



James  writes:


Hello,

I still cannot make doc and so cannot merge staging - and for those
waiting on me to test new patches, I cannot do that with any great
reliability either.

I am sorry this is incredibly frustrating.

@Phil would it be possible for you to run Patchy Merge on your system
and see if you can get this to work.


I've started one just now on my laptop.  It just takes significantly
North of one hour to complete.

--
David Kastrup



I'd already booted my machine and kicked patchy off, so it's likely your 
patch will be merged before your patchy completes.


--
Phil Holmes 



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


Re: Let define-session-public place variables natively into parser (issue 300110043 by d...@gnu.org)

2016-05-27 Thread Carl . D . Sorensen

On 2016/05/27 06:03:44, dak wrote:

On 2016/05/27 04:23:29, Carl wrote:
> Looks very nice to me.  I couldn't have done it, but I love how it

works.


Can you elaborate on the "couldn't have done it" part?

define-session-public

copies some ugly code (concerning undead structures or something) from
define-session.  Is it that, or the heavily underdocumented module

system of

Guile that's involved here?  Because I have a patch reorganizing the

session

stuff in limbo that would remove/replace the undead machinery with

something

saner.  Possibly giving fewer useful diagnostics, but we haven't had

any

_useful_ hint from that area for years.



It's the module system of Guile.  I have no idea how the module system
works.  I'm vaguely aware that there are modules, and that variables are
scoped locally to the modules, but that's about it.

To be fair, I haven't spent any time digging in to that aspect of
LilyPond.  I assume that if I dug into it I could learn it, but that's
beyond my current understanding.

Thanks,

Carl


https://codereview.appspot.com/300110043/

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


Re: Patch

2016-05-27 Thread Trevor Daniels
Hi Steven

Thomas Morley wrote Friday, May 27, 2016 3:07 PM


> 2016-05-27 6:11 GMT+02:00 Steven Weber :
>>
>> Since I don't have an official mentor and the recommendation is that you
>> send your first couple of patches to your mentor first, I thought I'd send
>> it to the list and see if someone can take a look.
>>
>> Any feedback or next steps I should take?
>
> please ask Trevor or Phil for developer-status at source-forge. (cc-ing both)
> Once this is done use git-cl to upload your patch. More in CG.
> An issue at sourceforge will be opened automatically and the patch
> itself will be put up on Rietveld.
> Then the usual patch-review-circle will start.

Happy to do this.  Just let me have your username at SourceForge if you
have one already, or go to 

https://sourceforge.net/p/testlilyissues/issues/

click "Join" in the top right and create a username to send to me.

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


Re: Patch

2016-05-27 Thread Trevor Daniels

Steven, you wrote Friday, May 27, 2016 9:22 PM

>>Thomas Morley wrote Friday, May 27, 2016 3:07 PM
>>
>>> 2016-05-27 6:11 GMT+02:00 Steven Weber :

 Since I don't have an official mentor and the recommendation is that you
 send your first couple of patches to your mentor first, I thought I'd send
 it to the list and see if someone can take a look.

 Any feedback or next steps I should take?
>>>
>>> please ask Trevor or Phil for developer-status at source-forge. (cc-ing 
>>> both)
>>> Once this is done use git-cl to upload your patch. More in CG.
>>> An issue at sourceforge will be opened automatically and the patch
>>> itself will be put up on Rietveld.
>>> Then the usual patch-review-circle will start.
>>
>>Happy to do this.  Just let me have your username at SourceForge if you
>>have one already, or go to 
>>
>>https://sourceforge.net/p/testlilyissues/issues/
>>
>>click "Join" in the top right and create a username to send to me.
> 
> My SF user name is steven-weber.

Thanks.  You're added as a developer as far as SourceForge is concerned.
That means you can read, create and update issues there.

However, to use git-cl you also need to have an account at Rietveld, and have
a SF bearer token.  How to do this is described under configuring git-cl here:

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

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


PATCHES: Countdown for May 28th

2016-05-27 Thread James Lowe

Hello,

Here is the current patch countdown list. The next countdown will be on
May 31st.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/

__


Push:


4857 update doc tarballs link (downloads/) - Federico Bruni
https://sourceforge.net/p/testlilyissues/issues/4857
http://codereview.appspot.com/296210043


4855 Move old news from news-front to news - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/4855
http://codereview.appspot.com/297300043


4854 Set minimum size dots for text spanner to be round. - Carl Sorensen
https://sourceforge.net/p/testlilyissues/issues/4854
http://codereview.appspot.com/295210043


Countdown:


4858 Let define-session-public place variables natively into parser - 
David Kastrup

https://sourceforge.net/p/testlilyissues/issues/4858
http://codereview.appspot.com/300110043


Review: No Patches in Review at this time.


New:


4862 Merge get_acknowledger and get_end_acknowledger - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/4862
http://codereview.appspot.com/296260043


4861 Update texinfo.tex from upstream - Masamichi Hosoda
https://sourceforge.net/p/testlilyissues/issues/4861
http://codereview.appspot.com/300820043


4860 Add halfopenvertical to script.scm - Carl Sorensen
https://sourceforge.net/p/testlilyissues/issues/4860
http://codereview.appspot.com/297340043


4751 Import Philomelos enhancements to musicxml2ly - John Gourlay
https://sourceforge.net/p/testlilyissues/issues/4751
http://codereview.appspot.com/295120043



Regards

James

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


Added property non-default to KeySignature (issue 300840043 by pant...@gmail.com)

2016-05-27 Thread panteck

Reviewers: ,

Message:
This patch adds the non-default property to the KeySignature grob.  It
works identically to the non-default property of the Clef grob.

Description:
Added property non-default to KeySignature
Added the property non-default to the KeySignature grob, and updated the
grob definition to indicate that it works for both Clefs and
KeySignatures now.

Please review this at https://codereview.appspot.com/300840043/

Affected files (+2, -1 lines):
  M lily/key-engraver.cc
  M scm/define-grob-properties.scm


Index: lily/key-engraver.cc
diff --git a/lily/key-engraver.cc b/lily/key-engraver.cc
index  
971f55317295e8a56387a6f508dc8a41f20cd96a..b6b57f92ce5b66c2fcfc37e980c214bcc909d178  
100644

--- a/lily/key-engraver.cc
+++ b/lily/key-engraver.cc
@@ -117,6 +117,7 @@ Key_engraver::create_key (bool is_default)
 {
   SCM visibility = get_property ("explicitKeySignatureVisibility");
   item_->set_property ("break-visibility", visibility);
+  item_->set_property ("non-default", SCM_BOOL_T);
 }
 }

Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index  
60b9d5b000c2e6896237aac6c9404857610719ac..cb9103a6fcda899fe88d459af846f724e5e01e92  
100644

--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -675,7 +675,7 @@ object.")
 get stems extending to the middle staff line.")
  (non-break-align-symbols ,list? "A list of symbols that determine
 which NON-break-aligned interfaces to align this to.")
- (non-default ,boolean? "Set for manually specified clefs.")
+ (non-default ,boolean? "Set for manually specified clefs and keys.")
  (non-musical ,boolean? "True if the grob belongs to a
 @code{NonMusicalPaperColumn}.")
  (nonstaff-nonstaff-spacing ,list? "The spacing alist



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


Re: Added property non-default to KeySignature (issue 300840043 by pant...@gmail.com)

2016-05-27 Thread pkx166h

On 2016/05/28 00:16:50, panteck wrote:

This patch adds the non-default property to the KeySignature grob.  It

works

identically to the non-default property of the Clef grob.


Does this have an Allura tracker number?

https://sourceforge.net/p/testlilyissues/issues/?source=navbar

I couldn't seem to find one that matched this issue.

https://codereview.appspot.com/300840043/

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