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

[tdanielsmusic]

LGTM, but I'd prefer longer names for o, m and tg
(especially tg!).

Trevor


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

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

Re: GOP-PROP 5: build system output (probable decision)

[Jan Nieuwenhuizen]

Trevor Daniels writes:

>> Not much response from the previous GOP-PROP 5 (update); I'm not
>> certain if "silence is a form of consent" [1] in this context.
>
> In my case it's because I have difficulty in understanding precisely
> what the effect of this change will be on any work I do.

+1

I proposed to adopt the linux/git/automake convention of using silent
rules so that you get something like

  make
  CC lily/foo.c
  ..
  LB Documentation/web.texi
  LB Documentation/notation.texi

or what you currently get when doing: make V=1 .

That's what everyone understands.  If you want silence and logging, why
not just do something like

   nohup make &

or

   make >& mybuild.log

[optionally using tail -f, grep and sed -- or those rolled together in a
 nice python script -- to get info on progress]

It almost seems to me someone is trying to hammer two different concepts
into one system  Not only is that very non-unixy, it also seems this
is a very lilypond-specific adaptation of the build system, which makes
me suspicious.

Greetings,
Jan.   

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

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

OS X Lion - taking the plunge

[m...@apollinemike.com]

Does anyone building on Mac plan on upgrading to Lion and, if so, can they 
report back what happens when they try a build?

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

Re: stable/2.14 cannot compile regtests

[Carl Sorensen]

On 7/20/11 10:41 PM, "Graham Percival"  wrote:

> On Wed, Jul 20, 2011 at 09:40:01PM -0700, Graham Percival wrote:
>> Can somebody check if
>>   make test
>> works on stable/2.14, and if not, fix it?  The GUB build died,
>> apparently on
>>   input/regression/rest-polyphonic-2.ly
> 
> aha, of course.  That file is \version "2.15.0".
> 
> Could somebody fix those version strings in stable/2.14 ?  Any
> version 2.15.0 (or higher) in stable/2.14 should be changed to be
> 2.14.2.


Done.  I'm sorry I missed that on the last set of patches.  I did it on
several others.

Thanks,

Carl


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

Re: modifying default behaviour of tremolo slashes (issue4636081)

[joeneeman]

http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc
File lily/stem-tremolo.cc (right):

http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode42
lily/stem-tremolo.cc:42: style = ly_symbol2scm ("constant");
You can remove these two lines and use
style == ly_symbol2scm ("varying")
below

http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode93
lily/stem-tremolo.cc:93: style = ly_symbol2scm ("constant");
These two lines are redundant.

http://codereview.appspot.com/4636081/

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

Re: Fix for Issue 620. (issue4814041)

[mtsolo]

On 2011/07/21 06:16:27, mike_apollinemike.com wrote:

On Jul 20, 2011, at 10:22 PM, mailto:pkx1...@gmail.com wrote:



> It passes make, but I get a lot of reg test issues
>
> Mainly I can see:
> +programming error: Improbable offset for stencil: -nan staff space
> +Setting to zero.
> +continuing, cross fingers
> +programming error: Improbable offset for stencil: -nan staff space
> +Setting to zero.
> +continuing, cross fingers
>
> -- on a lot of tests
>
> actually looking down the list there are a lot of problems with this

reg

> test comparisons. Too many to list and I don't know how to attach

them

> all.
>
> http://codereview.appspot.com/4814041/




I'll be working more on the implementation today, thanks!



Cheers,
MS


It works now & passes regtest.  I've also added a regtest to show it in
action.

Cheers,
MS

http://codereview.appspot.com/4814041/

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

RE: PATCH: 48-hour countdown

[James Lowe]

Hello,

)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Colin Campbell
)Sent: 21 July 2011 03:24
)To: lilypond-devel@gnu.org
)Subject: PATCH: 48-hour countdown
)
)New today, for 21:00 MST Friday July 22
)
)Issue 1567  :
)Add documentation for footnotes - Rietveld Issue 4751045
) : Doc: NR Added new Node
)for Footnotes 

This still has some (minor) work to do by me - I've changed the Tracker Status 
back to 'needs work'.

James

___
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:
...
> Werner, can you have a look at http://codereview.appspot.com/4819041 ?

   /draw_round_box % width height x y blot
   {
  -   setlinewidth % w h x y
  -   0 setlinecap
  -   1 setlinejoin
  +dup
  +   0.0 gt {
  +   setlinewidth % w h x y
  +   0 setlinecap
  +   1 setlinejoin
  +

There is no blot on the stack below (as indicated by the comment),
it was swallowed by setlinewidth.

  +   rmoveto % b w h
  +   currentpoint % b w h x1 y1
  +   4 2 roll % b x1 y1 w h
  +   4 copy
  +   rectfill
  +   rectstroke
  +   } {
  +   pop % w h x y
  +   rmoveto % w h
  +   currentpoint % w h x1 y1
  +   4 2 roll % x1 y1 w h
  +   rectfill
  +   } ifelse
  +} bind def

You don't seem to use this, why defining it?

  +/draw_box % width height x y
  +{
  rmoveto % w h
  currentpoint % w h x1 y1
  4 2 roll % x1 y1 w h
  4 copy
  rectfill
  -   rectstroke
   } bind def

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: Postscript printer errors with rounded barlines?

[Han-Wen Nienhuys]

On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar  wrote:
> Han-Wen Nienhuys:
> ...
>> Werner, can you have a look at http://codereview.appspot.com/4819041 ?
>
>   /draw_round_box % width height x y blot
>   {
>  -       setlinewidth % w h x y
>  -       0 setlinecap
>  -       1 setlinejoin
>  +        dup
>  +       0.0 gt {
>  +               setlinewidth % w h x y
>  +               0 setlinecap
>  +               1 setlinejoin
>  +
>
> There is no blot on the stack below (as indicated by the comment),

there is; the dup puts it on the stack.  The comment indicate the
state after the call.


> You don't seem to use this, why defining it?
>
>  +/draw_box % width height x y
>  +{

debugging fart. Will remove.

-- 
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: Postscript printer errors with rounded barlines?

[Karl Hammar]

Han-Wen Nienhuys:
> On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar  wrote:
> > Han-Wen Nienhuys:
> >> Werner, can you have a look at http://codereview.appspot.com/4819041 ?
> > There is no blot on the stack below (as indicated by the comment),
> there is; the dup puts it on the stack.  The comment indicate the
> state after the call.

   /draw_round_box % width height x y blot
   {
w h x y b
 dup
w h x y b b
 0.0 gt
w h x y b a_bool  % the a_bool it consumed by the ifelse below
 {
w h x y b
 setlinewidth % w h x y
w h x y
 0 setlinecap
 1 setlinejoin
w h x y
 rmoveto % b w h
w h
 currentpoint % b w h x1 y1
 4 2 roll % b x1 y1 w h
 4 copy
 rectfill
 rectstroke
 } {
 pop % w h x y
 rmoveto % w h
 currentpoint % w h x1 y1
 4 2 roll % x1 y1 w h
 rectfill
 } ifelse
   } bind def

After "dup" there is two "blot"s, "gt" consumes one and "setlinewidth"
the other.

///

Also if there were a "blot" at "rmoveto" time due to a "dup", it would
be at top of stack, not below "w h" as indicated by the comment.

///

If it would behave as the comment indicate, then

 w h x y 0draw_round_box => -
 w h x y blot draw_round_box => blot

e.i. it would leave a lone "blot" at the top of the stack if it's > 0.

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 5: build system output (probable decision)

[Graham Percival]

On Thu, Jul 21, 2011 at 10:07:29AM +0200, Jan Nieuwenhuizen wrote:
> I proposed to adopt the linux/git/automake convention of using silent
> rules so that you get something like
> 
>   make
>   CC lily/foo.c
>   ..
>   LB Documentation/web.texi
>   LB Documentation/notation.texi
> 
> or what you currently get when doing: make V=1 .
> 
> That's what everyone understands.

I have no clue what you're talking about, but I'll investigate.

> If you want silence and logging, why
> not just do something like
> 
>nohup make &
> 
> or
> 
>make >& mybuild.log
> 
> [optionally using tail -f, grep and sed -- or those rolled together in a
>  nice python script -- to get info on progress]

Oh?  Go and make an error in a @lilypond somewhere, then compile
from scratch, and tell me how easy it was to find the cause of the
errror using grep and sed.

> It almost seems to me someone is trying to hammer two different concepts
> into one system  Not only is that very non-unixy, it also seems this
> is a very lilypond-specific adaptation of the build system, which makes
> me suspicious.

What I'd like is for the lilypond build system to be like GUB.
GUB has a fantastic set of logs.  There's log files for the build
process.  There's log files for each package.  GUB gives you a
short snippet of the failure, and tells you where to find more
info.

As far as I'm concerned, this whole proporsal could be: "make the
lilypond build system output like GUB".  But that wouldn't be
understood by anybody other than you and me, so I need to describe
what GUB does.  :)

Cheers,
- Graham

___
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)

[joeneeman]

If you do

\set #'foo = #1
c
\once \set #'foo = #2
c
\once \set #'foo = #3
c

then the final value of foo should be 1. But with this code, I think it
will be 2.

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

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

Re: guile debug package in Debian

[Joe Neeman]

On Wed, Jul 20, 2011 at 12:42 PM, Federico Bruni  wrote:
> Il giorno mar, 19/07/2011 alle 18.19 -0600, Colin Campbell ha scritto:
>> I'm pretty sure the stuff you need is in the guile-1.8-dev package,
>> Federico.  On my Ubuntu 11.04, the package contains files such as
>> debug.h and debug-malloc.h among others.
>
> Ok, thanks.
>
> That's a bad news for Joe, because I had it installed when I generated
> the backtrace with gdb.

No, I don't think the debugging information is there. In the backtrace
you sent me, you'll notice that functions in lilypond show their
arguments:

#19 0x08214a91 in Score::book_rendering (this=0x84e5538, layoutbook=0x859e220,
default_def=0x8575248) at /home/fede/lilypond-master/lily/score.cc:160

while functions from guile just show an empty pair of parentheses
(even when the function takes some arguments):

#13 0xb7f2a9f1 in scm_call_1 () from /usr/lib/libguile.so.17

If the debugging information were installed, there would be more
information inside the (). Since Debian doesn't seem to have a package
for it, the easiest way to get debugging information may be to compile
guile yourself. If you install it in /usr/local (which should be the
default) and you ensure that /usr/local/bin precedes /usr/bin in your
PATH, then re-./configure lilypond and rebuild so that it will use the
new guile.

Cheers,
Joe

>
> Maybe there's something I can do in gdb to improve the backtrace?
> This is what I've done:
>
> gdb out/bin/lilypond
> run ../input/regression/midi/key-initial.ly
> bt
>
>
> These are the guile packages on my system (i flag shows the packages
> installed):
>
> $ aptitude search guile
> p   dico-module-guile           - RFC 2229 compliant modular dictionar
> v   guile                       -
> p   guile-1.6                   - The GNU extension language and Schem
> p   guile-1.6-dev               - Development files for Guile 1.6
> p   guile-1.6-doc               - Reference and tutorial documentation
> p   guile-1.6-libs              - Main Guile libraries
> p   guile-1.6-slib              - Guile SLIB support
> i A guile-1.8                   - GNU extension language and Scheme in
> i   guile-1.8-dev               - Development files for Guile 1.8
> p   guile-1.8-doc               - Documentation for Guile 1.8
> i A guile-1.8-libs              - Core Guile libraries
> v   guile-1.8-slib              -
> i A guile-cairo                 - Guile bindings for Cairo
> i   guile-cairo-dev             - Guile bindings for Cairo, developmen
> p   guile-db                    - Berkeley DB module for Guile
> v   guile-doc                   -
> i   guile-g-wrap                - scripting interface generator for C
> p   guile-gnome2-canvas         - Guile bindings for libgnomecanvas
> i   guile-gnome2-dev            - Guile GObject binding support librar
> p   guile-gnome2-gconf          - Guile bindings for GConf
> i A guile-gnome2-glib           - Guile bindings for GLib
> p   guile-gnome2-gnome          - Guile bindings for libgnome
> p   guile-gnome2-gnome-ui       - Guile bindings for libgnome
> p   guile-gnome2-gtk            - Guile bindings for GTK+, libglade, P
> p   guile-gnome2-vfs            - Guile bindings for GnomeVFS
> p   guile-gnutls                - the GNU TLS library - GNU Guile bind
> i   guile-library               - Library of useful Guile modules
> p   guile-pg                    - Guile bindings for the PostgreSQL cl
> v   libguile-dev                -
> p   libguile-ltdl-1             - Guile's patched version of libtool's
> p   libgv-guile                 - Guile bindings for graphviz
> p   mailutils-guile             - GNU mailutils Guile interpreter and
> p   xchat-guile                 - Guile scripting plugin for XChat
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>

___
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)

[n . puttock]

On 2011/07/21 16:15:41, joeneeman wrote:

If you do



\set #'foo = #1
c
\once \set #'foo = #2
c
\once \set #'foo = #3
c



then the final value of foo should be 1. But with this code, I think

it will be

2.


The \once finalization occurs before the new \once \set is processed, so
it always returns to the original (or most recent) \set.

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

___
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)

[reinhold . kainhofer]

Reviewers: Trevor Daniels, joeneeman, Neil Puttock,

Message:
On 2011/07/21 16:15:41, joeneeman wrote:

If you do



\set #'foo = #1
c
\once \set #'foo = #2
c
\once \set #'foo = #3
c



then the final value of foo should be 1. But with this code, I think

it will be

2.


Why should it be 2? The finalization hook to reset the value to the
previous one is processed at the end of the current moment, long before
the next \once\set will be processed (at the begin of the next moment).
So when the second \once\set is processed, the value of #'foo has
already been reset to #1 and the finalization  hook installed for the
secnd \once\set will reset the property to 1.

BTW, things like

\set #'foo = #1
c
\once \set #'foo = #2
\once \set #'foo = #3
c
c

also work properly (at the end the value will be 1), because apparently
the finalization hooks are processed in the correct (reverse) order.

Anyway, thanks for thinking about this case. I have updated the regtest
to include it.



Description:
Fix 153: \once\set properly restores the context property

\once\set works by installing a finalization hook in the iterator.
To restore the context property value before the \once\set, we simply
cache the old value and pass it to the finalization hook as third
argument. The finalizatino hook then sends a SetProperty event with
the old value rather than an UnsetProperty event, which reverts the
value to the default.

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

Affected files:
  A input/regression/set-once.ly
  M lily/include/property-iterator.hh
  M lily/property-iterator.cc


Index: input/regression/set-once.ly
diff --git a/input/regression/set-once.ly b/input/regression/set-once.ly
new file mode 100644
index  
..46faf94a1632605cd4cdd1c5a029aa0bd0113087

--- /dev/null
+++ b/input/regression/set-once.ly
@@ -0,0 +1,29 @@
+\version "2.15.5"
+
+\header {
+
+  texidoc = "@code{\once\set} should revert the setting after the next  
moment

+to the previous value rather than the default."
+
+}
+\relative {
+  \set fingeringOrientations = #'(left)
+  < e -1>1 |
+  \once \set fingeringOrientations = #'(right)
+  < e -1> |
+  < e -1> -"left" |
+
+  \once \set fingeringOrientations = #'(right)
+  < e -1>
+  \once \set fingeringOrientations = #'(up)
+  
+  -"left"
+
+  \set fingeringOrientations = #'(left)
+  
+  \once \set fingeringOrientations = #'(up)
+  \once \set fingeringOrientations = #'(right)
+  -"right"
+
+  -"left"
+}
Index: lily/include/property-iterator.hh
diff --git a/lily/include/property-iterator.hh  
b/lily/include/property-iterator.hh
index  
8aa0cec11d23a64a3315dd60f1b13415a2f14193..c53a4d9648162c1a2aa07c78fbb9f8760b0ca1c0  
100644

--- a/lily/include/property-iterator.hh
+++ b/lily/include/property-iterator.hh
@@ -29,7 +29,7 @@ class Property_iterator : public Simple_music_iterator
 {
 public:
   DECLARE_SCHEME_CALLBACK (constructor, ());
-  DECLARE_SCHEME_CALLBACK (once_finalization, (SCM, SCM));
+  DECLARE_SCHEME_CALLBACK (once_finalization, (SCM, SCM, SCM));
   DECLARE_CLASSNAME(Property_iterator);

 protected:
Index: lily/property-iterator.cc
diff --git a/lily/property-iterator.cc b/lily/property-iterator.cc
index  
62f316b7f1b7220e12d9e8bf773aa5921337fd00..f84c67decc379727bb3ca46c69f05c85b2077e9f  
100644

--- a/lily/property-iterator.cc
+++ b/lily/property-iterator.cc
@@ -31,13 +31,26 @@ bool check_grob (Music *mus, SCM sym);
translation unit, and set the property.
 */
 void
-Property_iterator::process (Moment m)
+Property_iterator::process (Moment mom)
 {
-  send_stream_event (get_outlet (), "SetProperty", get_music ()->origin (),
-ly_symbol2scm ("symbol"), get_music ()->get_property 
("symbol"),
-ly_symbol2scm ("value"), get_music ()->get_property 
("value"));
+  Context *o = get_outlet ();
+  Music *m = get_music ();
+  SCM previous_value = o->get_property (m->get_property ("symbol"));
+  send_stream_event (o, "SetProperty", m->origin (),
+ly_symbol2scm ("symbol"), m->get_property ("symbol"),
+ly_symbol2scm ("value"), m->get_property ("value"));
+
+  /* For \once\set install a finalization hook to reset the property to  
the old

+   * value after the next timestep */
+  if (to_boolean (m->get_property ("once")))
+{
+  Global_context *tg = get_outlet ()->get_global_context ();
+  tg->add_finalization (scm_list_n (once_finalization_proc,
+   o->self_scm (), m->self_scm (),
+   ly_quote_scm (previous_value), 
SCM_UNDEFINED));
+}

-  Simple_music_iterator::process (m);
+  Simple_music_iterator::process (mom);
 }

 void
@@ -50,30 +63,25 @@ Property_unset_iterator::process (Moment m)
   Simple_music_iterator::process (m);
 }

-MAKE_SCHEME_CALLBACK (Property_iterator, once_finalization, 2);
+MAKE_SCHEME_CALLBACK (Property_iterator, once_finalization, 3);
 SCM
-Property_iterator::once_finali

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

[n . puttock]

LGTM.


http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly
File input/regression/set-once.ly (right):

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode1
input/regression/set-once.ly:1: \version "2.15.5"
2.15.6

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode5
input/regression/set-once.ly:5: texidoc = "@code{\once\set} should
revert the setting after the next moment
\once \set

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode6
input/regression/set-once.ly:6: to the previous value rather than the
default."
this sounds a bit ambiguous; could be misinterpreted

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode11
input/regression/set-once.ly:11: < e -1>1 |
1

etc.

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode14
input/regression/set-once.ly:14: < e -1> -"left" |
you could add an assert function (using ApplyContext) to verify that the
value returns to the original \set (if you're feeling paranoid :)

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc
File lily/property-iterator.cc (right):

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc#newcode43
lily/property-iterator.cc:43: /* For \once\set install a finalization
hook to reset the property to the old
\once \set

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc#newcode44
lily/property-iterator.cc:44: * value after the next timestep */
don't you mean at the end of the current timestep?

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc#newcode74
lily/property-iterator.cc:74: // restore the value before the \once\set
command
\once \set

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

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

Re: Fix #1507: Inconsistent \festival output in regression testing. (issue4693046)

[n . puttock]

On 2011/07/16 05:42:36, Keith wrote:

Works good for me.


Thanks, pushed: 14632519690052980d19fc75e4dbc759c480aac2

Cheers,
Neil

http://codereview.appspot.com/4693046/

___
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)

[n . puttock]

http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm
File scm/define-music-display-methods.scm (right):

http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm#newcode867
scm/define-music-display-methods.scm:867: ;; nested properties are
written #'prop1 #'prop2:
we encourage users to use list syntax for overrides, so I'd prefer this
to be left as it is

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

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

Re: Fix 1563: System start bars interpreted collapse-height as absolute length. (issue4693043)

[n . puttock]

On 2011/07/20 17:02:02, Reinhold wrote:

On 2011/07/18 20:24:43, Neil Puttock wrote:
> lily/system-start-delimiter.cc:117: staffspace =
> Staff_symbol_referencer::staff_space (sp);
> A mostly theoretical gripe, I guess: what about collapse-height

comparisons

> where multiple staves are involved?  If staff-space settings differ,

this only

> picks up the last stave's value.



Yes, that was a deliberate decision. After all, the collapse-height is

mainly

intended to hide/show the bracket for single-staff systems.
In my eyes it would make more sense to show/hide the bracked depending

on the

number or staves involved rather than the grob height.


I agree.


I can't imagine a situation, where using the last staff's staff-space

would lead

to unwanted output. Usually, collapse-height will be either 5.0 (the

default) or

something smaller as advocated in the documentation and the LSR. In

these cases,

the last staff alone (plus some spacing to the staff above for 5.0)

already

suffices to show the bracket, even if the other staves have a

different

staff-space.


OK, LGTM.

Cheers,
Neil



http://codereview.appspot.com/4693043/

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

Re: MIDI: reset channel counters when done; issue 1678 (issue4757043)

[n . puttock]

LGTM.


http://codereview.appspot.com/4757043/diff/1/lily/staff-performer.cc
File lily/staff-performer.cc (right):

http://codereview.appspot.com/4757043/diff/1/lily/staff-performer.cc#newcode69
lily/staff-performer.cc:69: // For now, ask the last Staff_performer
clean up during its finalize()
finalize ()

http://codereview.appspot.com/4757043/

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

Re: PATCH: 48-hour countdown

[Graham Percival]

On Wed, Jul 20, 2011 at 08:24:07PM -0600, Colin Campbell wrote:
> Countdown done, but still open/not fixed:
> 
> 21:00 MST Wednesday July 13
>  Reitveld Issue 4664060: Adds redirect-lilypond-output option to
> lilypond-book

sorry, that one was pushed but I forgot to update the google
tracker.  Phil, could you mark it fixed and add the git commit
hash?

Cheers,
- Graham

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

Re: GOP-PROP 5: build system output (probable decision)

[Graham Percival]

On Thu, Jul 21, 2011 at 07:49:01AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Thursday, July 21, 2011 6:37 AM
> 
> >Not much response from the previous GOP-PROP 5 (update); I'm not
> >certain if "silence is a form of consent" [1] in this context.
> 
> In my case it's because I have difficulty in understanding precisely
> what the effect of this change will be on any work I do.

The effect should be minimal if the build works; if the build
fails, it should make it easier to find out why it failed.  That
goes both for "make" (which isn't very difficult to decypher at
the moment) and "make doc" (which requires about 3 months of doc
work before somebody is competent at figuring out why something
failed).

> But I have one comment.  By far the commonest use of make
> by developers is to compile the most recent change to C++
> source during the development cycle.  To speed this cycle
> up one usually watches the console to follow progress.

I've noticed a speed-up in the build if I minimize the terminal
window.

> If the compile fails you need to immediately see the error
> messages on the console.  It would be a nuisance if you had
> to fish these out from a file somewhere.

That's the reason for the final point -- in the case of a plain
"make", printing the last 10 or 20 lines of the build log should
give you exactly the same info.

In the case of "make doc", you often have to fish the actual error
message from between 500 and 2000 lines after the end of the
console output.  That causes a lot of problems for new doc
contributors, and there's no good reason for it.  Again, the build
system should just print the relevant part of the relevant log
file... but if you want to look at other parts of the build log,
well, they're still on your disk.  In the current "console only"
output, that info is either lost in the limited terminal buffer,
or else in a monstrous 50 MB log file containing absolutely
everything.

> If the compile and link succeed, you usually ctrl-C out of make
> as soon as linking has finished so you can get on with testing.
> So you need to see the relevant messages on the console
> to determine this.

Hmm.  Perhaps we should have a separate "make bin" target, which
only rebuilds the binary?  i.e. no font rebuild, no doc makeinfo
calls?
(or, if such a target already exists -- which I find quite
plausible -- perhaps we should publicize it better in the CG?)

I don't think that anybody should be watching console output,
ever.  Whenever you type "make", people should get coffee or check
email or start writing other code.

> So, my question is, can you still operate like this with a straight
> make command (no options needed), as this, I believe, is the
> commonest requirement.

Under the proposal, a plain "make" would omit any warnings
produced by gcc / mftrace / makeinfo, but would otherwise behave
the same.  Those warnings would be saved in a file.

Cheers,
- Graham

___
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)

[reinhold . kainhofer]

Will also correct those spacing issues pointed out by Neil before I'll
push.


http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly
File input/regression/set-once.ly (right):

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode6
input/regression/set-once.ly:6: to the previous value rather than the
default."
On 2011/07/21 17:34:07, Neil Puttock wrote:

this sounds a bit ambiguous; could be misinterpreted


Yes, I'll reformulate it. How about
"@code{\once \set} should change a context property value for just one
timestep and then return to the previous value, rather than resetting
the property to its global default value."

http://codereview.appspot.com/4810042/diff/4001/input/regression/set-once.ly#newcode14
input/regression/set-once.ly:14: < e -1> -"left" |
On 2011/07/21 17:34:07, Neil Puttock wrote:

you could add an assert function (using ApplyContext) to verify that

the value

returns to the original \set (if you're feeling paranoid :)


Hehe... No, that would make our life harder should we ever break that,
because then the regtest build will fail for all of use, rather than
simply showing some differences in the images.

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc
File lily/property-iterator.cc (right):

http://codereview.appspot.com/4810042/diff/4001/lily/property-iterator.cc#newcode44
lily/property-iterator.cc:44: * value after the next timestep */
On 2011/07/21 17:34:07, Neil Puttock wrote:

don't you mean at the end of the current timestep?


Well, nice catch, I'm actually mixing two different views:
View 1) \set is not assigned to a note, but is written between two
notes, so the following note (to which it shall apply) will be the NEXT
timestep
View 2) \set is evaluated together with the next following note, so
during processing its value is for the CURRENT timestep.

You are right, I should probably stick to view 2 and use current
timestep here.

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

___
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]

Reviewers: Neil Puttock, J_lowe,


http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm
File scm/define-music-display-methods.scm (right):

http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm#newcode867
scm/define-music-display-methods.scm:867: ;; nested properties are
written #'prop1 #'prop2:
On 2011/07/21 17:47:24, Neil Puttock wrote:

we encourage users to use list syntax for overrides, so I'd prefer

this to be

left as it is


Really? The NR (section 5.3.6 "Modifying alists" as well as 4.4.1
"Flexible vertical spacing within systems") only gives examples of the
form #'staff-staff-spacing #'basic-distance... I didn't even know that
the list syntax was there, let alone that it is the syntax we are
advocating.

Description:
Fix 1770: revert caused a crash in displayLilyMusic.

Handle the property names similar to OverrideProperty (i.e. first check
grob-property-path and then grob-property to get the name of the
property).

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

Affected files:
  M input/regression/display-lily-tests.ly
  M scm/define-music-display-methods.scm


Index: input/regression/display-lily-tests.ly
diff --git a/input/regression/display-lily-tests.ly  
b/input/regression/display-lily-tests.ly
index  
620289dda3b87789d54a827bc3c59d36f21d4ce3..cda991945940a29d2248a2999254fa3e32f09a62  
100644

--- a/input/regression/display-lily-tests.ly
+++ b/input/regression/display-lily-tests.ly
@@ -219,6 +219,10 @@ stderr of this run."
 \test "" ##[ \once \override Beam #'beam-thickness = #0.6 #]
 \test "" ##[ \revert Staff . Stem #'thickness #] % RevertProperty
 \test "" ##[ \revert Beam #'beam-thickness #]
+\test "NOT A BUG" ##[ \oneVoice #]   % resetting a bunch of properties
+\test "" ##[ \override StaffGrouper #'staff-staff-spacing #'basic-distance  
= #7 #] % nested properties
+\test "" ##[ \revert StaffGrouper #'(staff-staff-spacing basic-distance)  
#] % nested properties

+

 %% \applyOutput
 \test "" ##[ \applyOutput #'Foo #(lambda (arg) (list)) #]
Index: scm/define-music-display-methods.scm
diff --git a/scm/define-music-display-methods.scm  
b/scm/define-music-display-methods.scm
index  
c0041ba2a98344efe4fdef5fe097a9e0f832e0cb..e762d099e62b6504ae69f8b4614f0f516db9fada  
100644

--- a/scm/define-music-display-methods.scm
+++ b/scm/define-music-display-methods.scm
@@ -854,16 +854,20 @@ Otherwise, return #f."

 ;;; Layout properties

+;; Convert a list of (nested) property names to a property string
+(define (format-properties-list props)
+  (string-join (map (lambda (p) (format #f "#'~a" p)) props) " "))
+
 (define-display-method OverrideProperty (expr parser)
   (let* ((symbol (ly:music-property expr 'symbol))
-(property-path   (ly:music-property expr 'grob-property-path))
-(properties  (if (pair? property-path)
- property-path
- (list (ly:music-property expr 'grob-property
+(properties   (ly:music-property expr 'grob-property-path
+ (list (ly:music-property  
expr 'grob-property

 (value   (ly:music-property expr 'grob-value))
-(once(ly:music-property expr 'once)))
+(once(ly:music-property expr 'once))
+ ;; nested properties are written #'prop1 #'prop2:
+ (prop-string (format-properties-list properties)))

-(format #f "~a\\override ~a~a #'~a = ~a~a"
+(format #f "~a\\override ~a~a ~a = ~a~a"
(if (or (null? once)
(not once))
""
@@ -872,23 +876,22 @@ Otherwise, return #f."
""
(format #f "~a . " (*current-context*)))
symbol
-   (if (null? (cdr properties))
-   (car properties)
-   properties)
+   prop-string
(property-value->lily-string value parser)
(new-line->lily-string

 (define-display-method RevertProperty (expr parser)
-  (let ((symbol (ly:music-property expr 'symbol))
-   (properties (ly:music-property expr 'grob-property-path)))
+  (let* ((symbol (ly:music-property expr 'symbol))
+ (properties (ly:music-property expr 'grob-property-path
+ (list (ly:music-property  
expr 'grob-property)

 (format #f "\\revert ~a~a #'~a~a"
(if (eqv? (*current-context*) 'Bottom)
""
(format #f "~a . " (*current-context*)))
symbol
(if (null? (cdr properties))
-   (car properties)
-   properties)
+   (car properties)
+   properties)
(new-line->lily-string

 (define-display-method TimeSignatureMusic (expr parser)



___
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)

[Neil Puttock]

On 21 July 2011 19:27,   wrote:

> Really? The NR (section 5.3.6 "Modifying alists" as well as 4.4.1
> "Flexible vertical spacing within systems") only gives examples of the
> form #'staff-staff-spacing #'basic-distance... I didn't even know that
> the list syntax was there, let alone that it is the syntax we are
> advocating.

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).

Cheers,
Neil

___
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)

[n . puttock]

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.
crosses a line break

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
should go in texidoc

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

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.
comment is a bit long

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.");
"already have a force-ended DynamicLineSpanner"

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
remove

(issue #)

http://codereview.appspot.com/4630070/diff/17001/lily/dynamic-align-engraver.cc#newcode189
lily/dynamic-align-engraver.cc:189: bool end = line_ && (running_.empty
());
&& running_.empty ();

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
internal?

I'd remove any reference to dynamics here, since this is generic enough
to be useful elsewhere (e.g. pedals)

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

http://codereview.appspot.com/4630070/diff/17001/scm/define-grobs.scm#newcode812
scm/define-grobs.scm:812: (spanner-broken . #f)
remove

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

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

GOP-PROP 6: private mailing lists

[Graham Percival]

We've had almost a day to recover from the C++ formatting issue,
so let's dive into the next massively contentious issue.

http://lilypond.org/~graham/gop/gop_6.html


** Proposal summary

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. 

In general, I favor the second option – but at the moment, I’m so
fed up with the topic that I have no objection to the first option
if that’s preferred.


** Status quo

At the moment, our custom seems to be the first option. Whenever
something comes up, somebody sends me a private email, and I pick
an ad-hoc collection of people to discuss it with. Always Han-Wen
and Jan, but often Carl, Trevor, and others.

Other than the obvious “giving git push ability”, recent questions
included a university project who wanted to have a focus group to
discuss development. I thought we could just discuss it on -devel,
but the university group wanted to keep it private. I didn’t see
any harm in that, so we arranged something privately with an
ad-hoc collection of lilypond developers.


** Rationale

As LilyPond becomes more widely used+known, we can expect more
requests for private communication. In many cases these requests
are a bit silly but harmless – sometimes external groups are shy
to have public archived discussions, even if there’s nothing of
real importance being discussed. We could tell those people “get
lost, we’ll only talk to you if it’s public”, but I think we lose
nothing by allowing a trusted group of people to have a private
discussion with those people.

The key is “a trusted group of people”. At the moment, it appears
that I am a single point of failure for this. I’m not convinced
that this is healthy for the project, so I’d like to have a wider
group of people for this task.

There is some unhappy history about this idea in our development
community:

http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00178.html
http://news.lilynet.net/spip.php?article121
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00076.html


** Other projects

The idea of private mailing lists is hardly uncommon in
open-source software. For example,

http://lwn.net/Articles/394660/   about debian-private
http://subversion.apache.org/mailing-lists.html  private@
http://www.freebsd.org/administration.html#t-core
http://foundation.gnome.org/legal/   board members pledge
to keep certain matters confidential

every security team of every linux distribution and OS

In fact, Karl Fogel’s “Producing Open Source Software” explicitly
suggests a private mailing list for some circumstances:

  [on granting commit/push access to a contributor]

  But here is one of the rare instances where secrecy is
  appropriate. You can't have votes about potential committers
  posted to a public mailing list, because the candidate's feelings
  (and reputation) could be hurt.

  http://producingoss.com/en/consensus-democracy.html#electorate


** 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.


** Board of governers, voting, etc?

Many projects have an official board of directors, or a list of
“core developers”, with set term limits and elections and stuff.

I don’t think that we’re that big. I think we’re still small
enough, and there’s enough trust and consensus decisions, that we
can avoid that. I would rather that we kept on going with
trust+consensus for at least the next 2-3 years, and spent more
time+energy on bug fixes and new features instead of
administrative stuff.


** Implementation notes

None yet. 


Cheers,
- Graham

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

Music functions with pitch and duration arguments (was: Creates a glissando stem grob that uses stems' functionality. (issue4777044))

[David Kastrup]

n.putt...@gmail.com writes:

> http://codereview.appspot.com/4777044/diff/7001/input/regression/glissando-stem.ly
> File input/regression/glissando-stem.ly (right):
>
> http://codereview.appspot.com/4777044/diff/7001/input/regression/glissando-stem.ly#newcode10
> input/regression/glissando-stem.ly:10: \xenakisStem #(ly:make-duration
> 3) #32
> This should be a music function, possibly incorporating the \glissando
> for the initial note.

Well, putting aside the issue at point (where an interesting solution
accepting music in a reasonably natural manner has been proposed), I
find it excruciatingly ugly to specify arguments as #(ly:make-duration
... or #(ly:make-pitch ...

So I tried out a patch that will accept pitches (via signature
ly:pitch?) and durations (signature ly:duration?) as music function
arguments.  Durations are not accepted everywhere since that would lead
to an awful number of shift/reduce conflicts.  There _are_ combinations
of music arguments and durations that can't be resolved otherwise (since
durations are often optional at the end of music), so there is a reason
for it.  Nevertheless, there is no error recovery built in right now, so
if you really cook up a forbidden music function signature (say
ly:music? ly:duration?) and call the respective function, Lilypond will
barf out with something like

/tmp/test.ly:4:5: error: syntax error, unexpected EXPECT_DURATION

Apart from the error recovery problem for bad music/duration
combinations in the signature, the patch would appear to work as
expected.  I am not sure whether the current situation is not already
susceptible to imprudent signatures triggering syntax errors.

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.

What do people think?  I've not yet bothered with markup, though things
like \note would be better off taking a duration argument rather than an
integer.

diff --git a/lily/include/duration.hh b/lily/include/duration.hh
index 003b9e8..69ac487 100644
--- a/lily/include/duration.hh
+++ b/lily/include/duration.hh
@@ -56,5 +56,7 @@ private:
 INSTANTIATE_COMPARE (Duration, Duration::compare);
 DECLARE_UNSMOB (Duration, duration);
 
+extern SCM Duration_type_p_proc;
+
 #endif // DURATION_HH
 
diff --git a/lily/include/pitch.hh b/lily/include/pitch.hh
index 1ef59f3..df829b2 100644
--- a/lily/include/pitch.hh
+++ b/lily/include/pitch.hh
@@ -106,5 +106,6 @@ INSTANTIATE_COMPARE (Pitch, Pitch::compare);
 
 extern SCM pitch_less_proc;
 Pitch pitch_interval (Pitch const &from, Pitch const &to);
+extern SCM Pitch_type_p_proc;
 
 #endif /* PITCH_HH */
diff --git a/lily/lexer.ll b/lily/lexer.ll
index 8824182..83a7940 100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -46,6 +46,7 @@
 using namespace std;
 
 #include "context-def.hh"
+#include "duration.hh"
 #include "identifier-smob.hh"
 #include "international.hh"
 #include "interval.hh"
@@ -58,6 +59,7 @@ using namespace std;
 #include "music-function.hh"
 #include "parse-scm.hh"
 #include "parser.hh"
+#include "pitch.hh"
 #include "source-file.hh"
 #include "std-string.hh"
 #include "string-convert.hh"
@@ -794,11 +796,17 @@ Lily_lexer::scan_escaped_word (string str)
 		push_extra_token (EXPECT_NO_MORE_ARGS);
 		for (; scm_is_pair (s); s = scm_cdr (s))
 		{
-			if (scm_car (s) == ly_music_p_proc)
+			SCM cs = scm_car (s);
+			
+			if (cs == ly_music_p_proc)
 push_extra_token (EXPECT_MUSIC);
-			else if (scm_car (s) == ly_lily_module_constant ("markup?"))
+			else if	(cs == Pitch_type_p_proc)
+push_extra_token (EXPECT_PITCH);
+			else if (cs == Duration_type_p_proc)
+push_extra_token (EXPECT_DURATION);
+			else if (cs == ly_lily_module_constant ("markup?"))
 push_extra_token (EXPECT_MARKUP);
-			else if (ly_is_procedure (scm_car (s)))
+			else if (ly_is_procedure (cs))
 push_extra_token (EXPECT_SCM);
 			else programming_error ("Function parameter without type-checking predicate");
 		}
diff --git a/lily/parser.yy b/lily/parser.yy
index 9b46bfe..057a0e8 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -270,6 +270,8 @@ If we give names, Bison complains.
 /* Artificial tokens, for more generic function syntax */
 %token  EXPECT_MARKUP;
 %token  EXPECT_MUSIC;
+%token  EXPECT_PITCH;
+%token  EXPECT_DURATION;
 %token  EXPECT_SCM;
 %token  EXPECT_MARKUP_LIST
 /* After the last argument. */
@@ -1081,6 +1083,9 @@ function_arglist_nonmusic_last:
 	| EXPECT_MARKUP function_arglist simple_string {
 		$$ = scm_cons ($3, $2);
 	}
+	| EXPECT_PITCH function_arglist pitch {
+	  	$$ = scm_cons ($3, $2);
+	}
 	| EXPECT_SCM function_arglist function_scm_argument {
 		$$ = scm_cons ($3, $2);
 	}
@@ -1095,6 +1100,12 @@ function_arglist_nonmusic: EXPECT_NO_MO

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

[ColinPKCampbell]

Reviewers: ,

Message:
Addresses Reinhold's comment re issue 1762

Description:
DOC: fix NR 1.6.3 Formatting Cue Notes

Moves comment about explicitly creating a Voice, to the proper example.

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

Affected files:
  M Documentation/notation/staff.itely


Index: Documentation/notation/staff.itely
diff --git a/Documentation/notation/staff.itely  
b/Documentation/notation/staff.itely
index  
5344ab2b866ba8181d93084f9df01c385740487b..d0d6da753649a38d09665ce71da27ac036946984  
100644

--- a/Documentation/notation/staff.itely
+++ b/Documentation/notation/staff.itely
@@ -1292,9 +1292,6 @@ oboeNotes = \relative c'' {
 @end lilypond

 @noindent
-In the above example, the @code{Voice} context had to be
-explicitly declared, or else the entire music expression would
-belong to the @code{CueVoice} context.

 It is possible to adjust which aspects of the music are quoted with
 @code{\cueDuring} by setting the @code{quotedCueEventTypes}
@@ -1319,6 +1316,10 @@ oboeNotes = \relative c'' {
 }
 @end lilypond

+In the above example, the @code{Voice} context had to be
+explicitly declared, or else the entire music expression would
+belong to the @code{CueVoice} context.
+
 Markup can be used to show the name of the quoted instrument.  Also,
 if the cue notes require a change in clef, this can be done manually but
 the original clef should also be restored manually at the end of the cue



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

Re: Postscript printer errors with rounded barlines?

[Han-Wen Nienhuys]

On Thu, Jul 21, 2011 at 12:31 PM, Karl Hammar  wrote:
> Han-Wen Nienhuys:
>> On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar  wrote:
>> > Han-Wen Nienhuys:
>> >> Werner, can you have a look at http://codereview.appspot.com/4819041 ?
>> > There is no blot on the stack below (as indicated by the comment),
>> there is; the dup puts it on the stack.  The comment indicate the
>> state after the call.
>
>   /draw_round_box % width height x y blot
>   {
> w h x y b
>         dup
> w h x y b b
>         0.0 gt
> w h x y b a_bool  % the a_bool it consumed by the ifelse below
>         {
> w h x y b
>                 setlinewidth % w h x y
> w h x y
>                 0 setlinecap
>                 1 setlinejoin
> w h x y
>                 rmoveto % b w h
> w h
>                 currentpoint % b w h x1 y1
>                 4 2 roll % b x1 y1 w h
>                 4 copy
>                 rectfill
>                 rectstroke
>         } {
>                 pop % w h x y
>                 rmoveto % w h
>                 currentpoint % w h x1 y1
>                 4 2 roll % x1 y1 w h
>                 rectfill
>         } ifelse
>   } bind def
>
> 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.

pushed as 5291daf785cd215145473781612732de94890ba0
-- 
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: Postscript printer errors with rounded barlines?

[Han-Wen Nienhuys]

On Thu, Jul 21, 2011 at 11:27 PM, Han-Wen Nienhuys  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.
>
> pushed as 5291daf785cd215145473781612732de94890ba0

This should be backported.  Do we have a special procedure for that nowadays?

-- 
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: Music functions with pitch and duration arguments (was: Creates a glissando stem grob that uses stems' functionality. (issue4777044))

[Han-Wen Nienhuys]

On Thu, Jul 21, 2011 at 10:01 PM, 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.

> What do people think?  I've not yet bothered with markup, though things
> like \note would be better off taking a duration argument rather than an
> integer.

The patch looks neat. I don't see any obvious problems, but are you
sure it compiles? It seems to be missing the init for the _proc
variables you added, though.

Can you use ly_lily_module_constant?  It memoizes, so it is efficient.

-- 
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: Postscript printer errors with rounded barlines?

[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, and I'm not certain
if we'll have any more 2.14 releases.  First 2.16 release
candidate is in 10 days.

Cheers,
- Graham

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

stable/2.14 can't make doc

[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)

Cheers,
- Graham

PS no, this isn't a made-up problem to demonstrate why
"GOP-PROP 5: build output" is a good idea.  I honestly cannot
build stable/2.14, my desktop is really 7000km away, the
university actually has requires me to log in to 2 intermediate
computers before I can ssh into my desktop, and the doc log file
really doesn't make it easy to find out exactly which filename
died.  Searching for "Error" and "error" doesn't find the
problematic file.


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

Re: guile debug package in Debian

[Federico Bruni]

Il giorno gio, 21/07/2011 alle 23.26 +0700, Joe Neeman ha scritto:
> If the debugging information were installed, there would be more
> information inside the (). Since Debian doesn't seem to have a package
> for it, the easiest way to get debugging information may be to compile
> guile yourself. 

I've downloaded the sources in the debian repository:

# apt-get build-dep guile-1.8
$ apt-get source guile-1.8
$ ./configure --enable-guile-debug

Everything ok, then I run make and I got the error below.
I thought I'd better use the debian sources, maybe should I use the
upstream sources? Where can I find it? (sorry, ATM few time and slow
connection)

$ make
make  all-recursive
make[1]: Entering directory `/home/fede/src/guile-1.8-1.8.8+1'
Making all in oop
make[2]: Entering directory `/home/fede/src/guile-1.8-1.8.8+1/oop'
Making all in goops
make[3]: Entering directory `/home/fede/src/guile-1.8-1.8.8+1/oop/goops'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/fede/src/guile-1.8-1.8.8+1/oop/goops'
make[3]: Entering directory `/home/fede/src/guile-1.8-1.8.8+1/oop'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/fede/src/guile-1.8-1.8.8+1/oop'
make[2]: Leaving directory `/home/fede/src/guile-1.8-1.8.8+1/oop'
Making all in libguile
make[2]: Entering directory `/home/fede/src/guile-1.8-1.8.8+1/libguile'
Generating libpath.h...
sed < ./version.h.in > version.h.tmp \
  -e s:@-GUILE_MAJOR_VERSION-@:1: \
  -e s:@-GUILE_MINOR_VERSION-@:8: \
  -e s:@-GUILE_MICRO_VERSION-@:8:
mv version.h.tmp version.h
if [ "no" = "yes" ]; then \
gcc -DHAVE_CONFIG_H  -I.. -I.. -I.. -c -o gen-scmconfig.o
gen-scmconfig.c; \
else \
gcc -DHAVE_CONFIG_H   -I.. -I.. -I..   -g -O2 -Wall
-Wmissing-prototypes -Werror -c -o gen-scmconfig.o gen-scmconfig.c; \
fi
if [ "no" = "yes" ]; then \
gcc -o gen-scmconfig gen-scmconfig.o; \
else \
/bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall
-Wmissing-prototypes -Werror   -o gen-scmconfig gen-scmconfig.o  -lgmp
-lcrypt -lm -lltdl ; \
fi
libtool: link: gcc -g -O2 -Wall -Wmissing-prototypes -Werror -o
gen-scmconfig gen-scmconfig.o  /usr/lib/libgmp.so -lcrypt
-lm /usr/lib/libltdl.so
rm -f scmconfig.h.tmp
cat ./scmconfig.h.top > scmconfig.h.tmp
./gen-scmconfig >> scmconfig.h.tmp
chmod 444 scmconfig.h.tmp
rm -f scmconfig.h
mv scmconfig.h.tmp scmconfig.h
./guile-snarf -o alist.x alist.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o arbiters.x arbiters.c -DHAVE_CONFIG_H -I.. -I.. -I..
-g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o async.x async.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o backtrace.x backtrace.c -DHAVE_CONFIG_H -I.. -I.. -I..
-g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o boolean.x boolean.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o chars.x chars.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o continuations.x continuations.c -DHAVE_CONFIG_H -I..
-I.. -I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o debug.x debug.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o deprecation.x deprecation.c -DHAVE_CONFIG_H -I.. -I..
-I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o deprecated.x deprecated.c -DHAVE_CONFIG_H -I.. -I..
-I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o discouraged.x discouraged.c -DHAVE_CONFIG_H -I.. -I..
-I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o dynl.x dynl.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o dynwind.x dynwind.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o environments.x environments.c -DHAVE_CONFIG_H -I.. -I..
-I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o eq.x eq.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2 -Wall
-Wmissing-prototypes -Werror
./guile-snarf -o error.x error.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o eval.x eval.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g -O2
-Wall -Wmissing-prototypes -Werror
./guile-snarf -o evalext.x evalext.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o extensions.x extensions.c -DHAVE_CONFIG_H -I.. -I..
-I..  -g -O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o feature.x feature.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o fluids.x fluids.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o fports.x fports.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-O2 -Wall -Wmissing-prototypes -Werror
./guile-snarf -o futures.x futures.c -DHAVE_CONFIG_H -I.. -I.. -I..  -g
-

Re: Music functions with pitch and duration arguments

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Thu, Jul 21, 2011 at 10:01 PM, 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.  But it might be nice to have this available
for other user-defined material.

>> What do people think?  I've not yet bothered with markup, though things
>> like \note would be better off taking a duration argument rather than an
>> integer.
>
> The patch looks neat. I don't see any obvious problems, but are you
> sure it compiles?

Yes.  The error message I quoted for a bad signature was not invented.

> 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.

> Can you use ly_lily_module_constant?  It memoizes, so it is efficient.

Where is the point?  The respective variables _are_ initialized and set
with the pristine values of the type checking functions.  Memoization
can't be faster than that, I should think.

It could conceivably make a difference when the user masks the
definitions of ly:pitch?  or ly:duration? (merely setting them to
different values should not be a problem) but that's not really
something I want to think about too much.

-- 
David Kastrup

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

Re: guile debug package in Debian

[Joe Neeman]

On Fri, Jul 22, 2011 at 1:32 PM, Federico Bruni  wrote:
> Il giorno gio, 21/07/2011 alle 23.26 +0700, Joe Neeman ha scritto:
>> If the debugging information were installed, there would be more
>> information inside the (). Since Debian doesn't seem to have a package
>> for it, the easiest way to get debugging information may be to compile
>> guile yourself.
>
> I've downloaded the sources in the debian repository:
>
> # apt-get build-dep guile-1.8
> $ apt-get source guile-1.8
> $ ./configure --enable-guile-debug

You don't need --enable-guile-debug here (it enables some internal
guile stuff, which is independent from the debug symbols that I want).
But you'll need to add --disable-error-on-warning; your compiler is
probably newer than the one that built the Debian package, and it's a
little more strict with warnings.

Cheers,
Joe

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