Re: Require path separators in assignments/overrides (issue 286680043 by d...@gnu.org)

2016-03-14 Thread dak

Reviewers: thomasmorley651, lemzwerg,

Message:
On 2016/03/14 06:40:27, lemzwerg wrote:

LGTM.



I assume that convert-ly already does the right thing...


Somewhere in the leadup to 2.18.  However, i kept \override Context.Grob
property.subproperty (without the dot in the middle) working.  It's just
the subproperty subdivision dot that is no longer optional.

Description:
Require path separators in assignments/overrides

Historical assignments/overrides like
Variable #'x #'y = 7
or
\override Glissando.bound-details #'left #'Y = #3
without dots between the various path components do not match the syntax
of
\revert and music functions or other uses.  Disallow the non-separation
by '.' or ',' of such path components.

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

Affected files (+1, -9 lines):
  M lily/parser.yy


Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
29ecf1c3222f88e4d8a7b6325486d24c098fa605..2b2f16d1dc61bda7010f44804ed1f551fd585a14  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -644,11 +644,6 @@ assignment:
parser->lexer_->set_identifier ($1, $3);
 $$ = SCM_UNSPECIFIED;
}
-   | assignment_id property_path '=' identifier_init {
-   SCM path = scm_cons (scm_string_to_symbol ($1), $2);
-   parser->lexer_->set_identifier (path, $4);
-$$ = SCM_UNSPECIFIED;
-   }
| assignment_id '.' property_path '=' identifier_init {
SCM path = scm_cons (scm_string_to_symbol ($1), $3);
parser->lexer_->set_identifier (path, $5);
@@ -2558,9 +2553,6 @@ property_path:
symbol_list_rev  {
$$ = scm_reverse_x ($1, SCM_EOL);
}
-   | symbol_list_rev property_path {
-   $$ = scm_reverse_x ($1, $2);
-   }
;

 property_operation:
@@ -2570,7 +2562,7 @@ property_operation:
| UNSET symbol {
$$ = scm_list_2 (ly_symbol2scm ("unset"), $2);
}
-   | OVERRIDE property_path '=' scalar {
+   | OVERRIDE revert_arg '=' scalar {
if (scm_ilength ($2) < 2) {
parser->parser_error (@2, _("bad grob property path"));
$$ = SCM_UNDEFINED;



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


Re: GSoC mentors once more

2016-03-14 Thread Urs Liska
Hi Jan-Peter,

Am 14.03.2016 um 07:54 schrieb Jan-Peter Voigt:
> Hi Urs,
>
> you asked me off-list, if I would be a mentor (in hogwards they are
> called dementor, aren't they?) - I didn't answer yet, so I do it
> on-list now. I would be generally ready with being a mentor for the
> cross-voice-spanner-application.

That would be great!
I don't know how many slots we might eventually get, but we will never
get more slots than stated mentors.

> Still, I would like to know, how much effort would come up with it to me?
> Well, answering questions (or delegating them) and reviewing code
> should be no problem :-)

Lacking experience I actually don't know. Maybe David Kastrup might want
to drop in some comments here?
From what I read in the guidelines (and thinking about it) one should
not underrate it. But we may well try to share significant parts of the
work as a developer community (which is of course the spirit of GSoC).
IISC the most important (and least predictable) task of the mentor is to
keep an eye on the project, to keep in touch with the student and ensure
that his work is proceeding sufficiently.

Any coding issues may freely be shared among developers, and Google
explicitly endorses to have code review shared by the devs and not only
been done by the mentor.

So depending on the project and the student it *may* be a rather easy
task. Or not.

Urs

>
> Cheers
> Jan-Peter
>
> Am 14. März 2016 01:08:09 MEZ, schrieb Urs Liska :
>
> Given the advent of a fifth potential applicant I find it inacceptable 
> that we don't seem to make any progress in raising our mentor number beyond 
> two.
>
> Is it really true that I am the only one pushing this?
>
> Urs
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet. 

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


Re: Let the parser interpret alist variables (issue 290560043 by d...@gnu.org)

2016-03-14 Thread dak

Reviewers: thomasmorley651, lemzwerg,


https://codereview.appspot.com/290560043/diff/1/lily/nested-property.cc
File lily/nested-property.cc (right):

https://codereview.appspot.com/290560043/diff/1/lily/nested-property.cc#newcode137
lily/nested-property.cc:137: for (;scm_is_pair (prop_path); prop_path =
scm_cdr (prop_path))
On 2016/03/14 06:46:51, lemzwerg wrote:

s/;scm/; scm/


Done.  Not uploading a separate review just for this, however.

Description:
Let the parser interpret alist variables

After

x.y = { c d e f }

this allows using

\x.y

instead of #(assoc-ref x 'y) in most places where the latter would work.


Also contains commit:

Create nested_property function

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

Affected files (+33, -1 lines):
  M lily/include/context.hh
  M lily/nested-property.cc
  M lily/parser.yy


Index: lily/include/context.hh
diff --git a/lily/include/context.hh b/lily/include/context.hh
index  
c4af7bce0579255dea4919f034065a00b3640bf8..ab89593d1bbad317b38de9e5b58a865224bc085b  
100644

--- a/lily/include/context.hh
+++ b/lily/include/context.hh
@@ -193,6 +193,7 @@ void set_context_property_on_children (Context *trans,  
SCM sym, SCM val);

   } while (0)

 SCM nested_property_alist (SCM alist, SCM prop_path, SCM value);
+SCM nested_property (SCM alist, SCM prop_path, SCM fallback = SCM_EOL);
 SCM nested_create_alist (SCM prop_path, SCM value);
 SCM partial_list_copy (SCM alist, SCM tail, SCM newtail);
 SCM assq_tail (SCM key, SCM alist, SCM alist_end);
Index: lily/nested-property.cc
diff --git a/lily/nested-property.cc b/lily/nested-property.cc
index  
7c8b13047d726e8f8d45fc2e44300402e038d31a..514935a93cf73bb070e43a83c9b52d6328244749  
100644

--- a/lily/nested-property.cc
+++ b/lily/nested-property.cc
@@ -131,6 +131,19 @@ nested_property_alist (SCM alist, SCM prop_path, SCM  
value)

   return scm_acons (key, value, alist);
 }

+SCM
+nested_property (SCM alist, SCM prop_path, SCM fallback)
+{
+  for (;scm_is_pair (prop_path); prop_path = scm_cdr (prop_path))
+{
+  SCM tail = assoc_tail (scm_car (prop_path), alist);
+  if (scm_is_false (tail))
+return fallback;
+  alist = scm_cdar (tail);
+}
+  return alist;
+}
+
 void
 set_nested_property (Grob *me, SCM big_to_small, SCM value)
 {
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
29ecf1c3222f88e4d8a7b6325486d24c098fa605..62cf8301e34fa54b03f656d0a31bfb49fcc72bc4  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -119,6 +119,7 @@ FIXME:
 using namespace std;

 #include "book.hh"
+#include "context.hh"
 #include "context-def.hh"
 #include "context-mod.hh"
 #include "dimensions.hh"
@@ -353,6 +354,7 @@ If we give names, Bison complains.
 %token EVENT_IDENTIFIER
 %token EVENT_FUNCTION
 %token FRACTION
+%token LOOKUP_IDENTIFIER
 %token LYRIC_ELEMENT
 %token MARKUP_FUNCTION
 %token MARKUP_LIST_FUNCTION
@@ -492,6 +494,15 @@ toplevel_expression:
}
;

+lookup:
+   LOOKUP_IDENTIFIER
+   | LOOKUP_IDENTIFIER '.' symbol_list_rev
+   {
+   $$ = loc_on_music (parser, @$,
+  nested_property ($1, scm_reverse_x ($3, 
SCM_EOL)));
+   }
+   ;
+
 embedded_scm_bare:
SCM_TOKEN
{
@@ -503,6 +514,7 @@ embedded_scm_bare:
 embedded_scm_active:
SCM_IDENTIFIER
| scm_function_call
+   | lookup
;

 embedded_scm_bare_arg:
@@ -520,6 +532,7 @@ embedded_scm_bare_arg:
| book_block
| bookpart_block
| output_def
+   | lookup
;

 /* The generic version may end in music, or not */
@@ -527,6 +540,7 @@ embedded_scm_bare_arg:
 embedded_scm:
embedded_scm_bare
| scm_function_call
+   | lookup
;

 /* embedded_scm_arg is _not_ casting pitches to music by default, this
@@ -4034,8 +4048,12 @@ Lily_lexer::try_special_identifiers (SCM  
*destination, SCM sid)

} else if (unsmob (sid)) {
*destination = unsmob (sid)->clone ()->unprotect ();
return SCM_IDENTIFIER;
+   } else if (scm_is_pair (sid)
+  && scm_is_pair (scm_car (sid))
+  && scm_is_symbol (scm_caar (sid))) {
+   *destination = sid;
+   return LOOKUP_IDENTIFIER;
}
-
return -1;
 }




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


Re: Let the parser interpret alist variables (issue 290560043 by d...@gnu.org)

2016-03-14 Thread dak

On 2016/03/13 23:39:29, thomasmorley651 wrote:

Even from description the consequences are not clear to me.
Can you give a little verbose example?


Basically, you can now use x.y for defining and \x.y for using a
variable like you could previously use x_y and \x_y but the value is
really stored in an alist.

That's not all that exciting, except that in connection with issue 4798
this will also permit violin.1 or violin.#x which some people might
consider almost what they want.

However, the slightly nicer looking assignment

violin1 = ...

is going to be ruled out by issue 4800 since I could not make the
corresponding \violin1 work.

It's sort of funny why \violin1 could not be made to work: I first let
an alist like \violin always grab the next expression and use it as an
index.  This caused \key c \major to stop working since \major has
_exactly_ the form of an alist indexed by a number.  So the indexing
operation must be made explicit (dot or comma), and in order to make it
explicit for the assignment as well, issue 4800.

As a corollary, \minor.2 is equivalent to #-1/2 after this issue and
issue 4798.

https://codereview.appspot.com/290560043/

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


Re: GSoC mentors once more

2016-03-14 Thread Paul Morris
Hi Jan-Peter,

Glad to hear you’re interested in being a mentor.

> On Mar 14, 2016, at 2:54 AM, Jan-Peter Voigt  wrote:
> 
> Still, I would like to know, how much effort would come up with it to me? 
> Well, answering questions (or delegating them) and reviewing code should be 
> no problem :-)

You might want to look at the GSOC “Mentoring Manual”:
http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/

Here’s its description of the mentor role:

Mentor: Mentors are people from the community who volunteer to work with a 
student. Mentors provide guidance such as pointers to useful documentation, 
code reviews, etc. In addition to providing students with feedback and 
pointers, a mentor acts as an ambassador to help student contributors integrate 
into their project's community. Some organizations choose to assign more than 
one mentor to each of their students. Many members of the community provide 
guidance to their project's GSoC students without mentoring in an "official" 
capacity, much as they would answer anyone's questions on the project's mailing 
list or IRC channel.

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


Re: difference between ly:context-now and ly:context-current-moment

2016-03-14 Thread David Kastrup
Jan-Peter Voigt  writes:

> Hi developers,
>
> can anybody please tell me:
> What is the difference between (ly:context-now context) and
> (ly:context-current-moment context) ?
>
> Or are they two names for the same thing?

Different code, different documentation string, different place in
lily/context-scheme.cc, absolutely the same functionality.

Probably somebody overlooked one when creating the other.

-- 
David Kastrup

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


difference between ly:context-now and ly:context-current-moment

2016-03-14 Thread Jan-Peter Voigt

Hi developers,

can anybody please tell me:
What is the difference between (ly:context-now context) and
(ly:context-current-moment context) ?

Or are they two names for the same thing?

Cheers
Jan-Peter

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


Re: difference between ly:context-now and ly:context-current-moment

2016-03-14 Thread Jan-Peter Voigt

OK
Thank you!

Am 14.03.2016 um 18:15 schrieb David Kastrup:

Jan-Peter Voigt  writes:


Hi developers,

can anybody please tell me:
What is the difference between (ly:context-now context) and
(ly:context-current-moment context) ?

Or are they two names for the same thing?


Different code, different documentation string, different place in
lily/context-scheme.cc, absolutely the same functionality.

Probably somebody overlooked one when creating the other.




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


Admit lists starting with UNSIGNED as music function arguments (issue 291190043 by d...@gnu.org)

2016-03-14 Thread lemzwerg

LGTM.

https://codereview.appspot.com/291190043/

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


Re: Admit lists starting with UNSIGNED as music function arguments (issue 291190043 by d...@gnu.org)

2016-03-14 Thread Carl . D . Sorensen

Looks good to me.  Very clear.  Easy to understand, and powerful.

A few years ago I was messing around in the override / revert space, and
it was driving me crazy.  You have rationalized the behavior.  Thanks!


Thanks,

Carl


https://codereview.appspot.com/291190043/

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