date:20101022


Reviewers: ,

Message:
I was about to push this, but then I started thinking that
the change was big enough to ask you guys for approval.
Any opposition?  I'm aiming for clarity, accuracy, and
comprehensiveness.  The idea is to reduce the amount of
time users spend being confused, and reduce the number of
questions on the mailing list.

Comments?  Okay to push?

Thanks.
- Mark

Description:
Doc: NR 4.1.2: Setting alist keys properly.

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

Affected files:
  M Documentation/notation/spacing.itely



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

Segfault with define-music-function

The following code causes a segfault.
LilyPond 2.13.36, GNU/Linux x86_64.

toto =
#(define-music-function (parser location arg) (ly:music?)
   (display (ly:event-property arg 'name))
   (make-sequential-music arg))

{ \toto a }

Also reproduced with today's git.
--verbose output isn't of any help:

[/usr/local/lilypond/usr/share/lilypond/current/ly/init.ly
 [/usr/local/lilypond/usr/share/lilypond/current/ly/declarations-init.ly
  [/usr/local/lilypond/usr/share/lilypond/current/ly/music-functions-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/toc-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/nederlands.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/drumpitch-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/chord-modifiers-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/script-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/chord-repetition-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/scale-definitions-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/grace-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/midi-init.ly
   [/usr/local/lilypond/usr/share/lilypond/current/ly/performer-init.ly]]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/paper-defaults-init.ly
   [/usr/local/lilypond/usr/share/lilypond/current/ly/titling-init.ly]]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/engraver-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/dynamic-scripts-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/spanners-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/property-init.ly]
  
[/usr/local/lilypond/usr/share/lilypond/current/ly/predefined-fretboards-init.ly]]
 [toto.lySegmentation fault.

Cheers,
Valentin.

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

comment in #{ ... #}


[current git]

It seems that it is not possible to have a comment within #{ ... #}.

In this example

  T = #(define-music-function (parser location music) (ly:music?)
#{
   \times 2/3 $music   ; $
#}
  )   

  \relative {
\T { c c c }
  }

lilypond complains about a syntax error.  Replacing the `;' with `%' I
get a syntax error also...

Is it possible at all to have a comment within #{...#}?  It would be
quite useful: For example, if you write a LaTeX document with lilypond
environments, and your editor supports syntax coloring, the unbalanced
`$' in the above macro causes incorrect coloring.

BTW, according to the docs (section 3.1.5, File structure), `%' should
be possible.


Werner

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

Re: comment in #{ ... #}

On Fri, Oct 22, 2010 at 12:10 PM, Werner LEMBERG  wrote:
> It seems that it is not possible to have a comment within #{ ... #}.

I believe it is (using %, as you point out). #{ #} introduces a
LilyPond syntax mode, so I wouldn't expect the ; character to suddenly
behave otherwise than in plain LilyPond syntax. Wouldn't you see that
as an inconsistency?

(Granted, the # character may be replaced with $ in a #{ #} construct.
But still, that's the only difference I can think of.)

Cheers,
Valentin.

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

Re: comment in #{ ... #}


>> It seems that it is not possible to have a comment within #{ ... #}.
> 
> I believe it is (using %, as you point out).

Have you tried it?  For me, it doesn't work.


Werner

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

Re: Doc: NR 4.1.2: Setting alist keys properly. (issue2670041)


I think it looks very nice.  Great job!

Carl



http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode232
Documentation/notation/spacing.itely:232: @subsubheading Alist structure
Perhaps this would be better titled "Spacing alist"

http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode244
Documentation/notation/spacing.itely:244: @item @code{space} -- the
default vertical distance, measured in
I thought 'space was going to be renamed to 'base-distance or
'default-distance or something similar.

http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode289
Documentation/notation/spacing.itely:289: @subsubheading Modifying
alists
Modifying spacing alists

http://codereview.appspot.com/2670041/

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

Re: comment in #{ ... #}

On Fri, Oct 22, 2010 at 1:16 PM, Werner LEMBERG  wrote:
> Have you tried it?  For me, it doesn't work.

This does work:

foo =
#(define-music-function (parser location music) (ly:music?)
   #{ $music % comment
   #})

{ \foo a }

Cheers,
Valentin.

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

Re: Segfault with define-music-function

2010-10-22 Thread Carl Sorensen

On 10/22/10 3:10 AM, "Valentin Villenave"  wrote:

> The following code causes a segfault.
> LilyPond 2.13.36, GNU/Linux x86_64.
> 
> toto =
> #(define-music-function (parser location arg) (ly:music?)
>(display (ly:event-property arg 'name))
>(make-sequential-music arg))
> 
> { \toto a }

As near as I can tell, this code is triggering an infinite loop that fails
when the scheme heap overflows.

arg is *not* a stream-event, it's a music-event.

(display (ly:music-property arg 'name))

will give you the name EventChord.

Also, (make-sequential-music arg) generates an error, because
make-sequential-music needs a list as an argument.

(make-sequential-music (list arg))

will work fine.

So here's your code working properly:

toto =
#(define-music-function (parser location arg) (ly:music?)
   (display (ly:music-property arg 'name))
   (make-sequential-music (list arg)))

{ \toto a4 }

Segfaults are supposed to always be critical errors, but I think that in the
case of incorrect Scheme code, we shouldn't label it as a LilyPond error.

HTH,

Carl

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

Re: Segfault with define-music-function

On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen  wrote:
> As near as I can tell, this code is triggering an infinite loop that fails
> when the scheme heap overflows.

Interesting.

> arg is *not* a stream-event, it's a music-event.

Indeed. But I wasn't expecting it to cause a segfault.

> Segfaults are supposed to always be critical errors, but I think that in the
> case of incorrect Scheme code, we shouldn't label it as a LilyPond error.

I agree. That's why I didn't open a tracker page.

Thanks!

Valentin.

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

Re: Doc: NR 4.1.2: Setting alist keys properly. (issue2670041)



http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode244
Documentation/notation/spacing.itely:244: @item @code{space} -- the
default vertical distance, measured in
On 2010/10/22 12:10:16, Carl wrote:

I thought 'space was going to be renamed to
'base-distance or 'default-distance or something similar.


It will be, but that change is beyond me.  I'll need to ask
Joe to do it, but I wanted to clear up everything else that
I can do on my own first.  Besides, I've grown to dislike
even "base-distance" because it sounds too much like the
distance between "bases", however that might be
interpreted.  Even if that particular thought doesn't occur
to a user, it's still ambiguous.  What do you think about
"unstretched-distance"?

- Mark

http://codereview.appspot.com/2670041/

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

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

2010-10-22 Thread Ian Hulin

Hi Patrick,


On 21/10/10 01:12, pnor...@gmail.com wrote:
> Hi Ian,
>
> I just tested your patch.
>
> In addition to the small tweak that is needed (see my comment below), it
> seems that the `(use-modules (ice-9 curried-definitions))' statement
> does not carry over to display-lily.scm.  I am a bit puzzled by this.
>
> This is the error message, in context:
>
> ;;; compiling
> /home/pnorcks/usr/share/lilypond/2.13.37/scm/music-functions.scm
> ;;; compiling
> /home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm
> ;;; WARNING: compilation of
> /home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm failed:
> ;;; key syntax-error, throw args (macroexpand "~a in ~a" ("source
> expression failed to match any pattern" (define
> ((make-music-type-predicate-aux mtypes) expr) (if (null? mtypes) #f (or
> (eqv? (car mtypes) (ly:music-property expr (quote name)))
> ((make-music-type-predicate-aux (cdr mtypes)) expr) #f)
> ;;; WARNING: compilation of
> /home/pnorcks/usr/share/lilypond/2.13.37/scm/music-functions.scm failed:
> ;;; key wrong-type-arg, throw args (#f "Wrong type to apply: ~S" (#f)
> (#f))
>
>
> Fortunately, it seems that the Scheme interpreter in Guile 1.9 is used
> as a fallback when compilation fails, since this doesn't interpret the
> make process.
>
> Can you reproduce this with Guile 1.9.13?
>

Rats!  I had a patched version of display-lily.scm with this as the star
of the module on my VM with guile 1.9 installed:

(define-module (scm display-lily)
  #:use-module (ice-9 optargs)
  #:use-module (ice-9 format)
  #:use-module (ice-9 regex)
  #:use-module (ice-9 pretty-print)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-13)
  #:use-module (srfi srfi-39)
  #:use-module (lily)
  #:use-syntax (srfi srfi-39)
  #:use-syntax (ice-9 optargs))

;;; (ice-9 curried-definitions) does not exist in Guile V1.8,7
;;;   TODO change this to
;;;   #:use-module (ice-9 curried-definitions)
;;;   once Guile V1.8 support is dropped so it's consistent

(if (string>? (version) "1.9.10")
(use-modules (ice-9 curried-definitions)))

I'd obviously got to this bit and forgot to copy it back to my main
machine's environment and retest before my recent dose of flu. 

> Thanks,
> Patrick
>
>
> http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
> File scm/lily.scm (right):
>
> http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode227
> scm/lily.scm:227: (use-modules (ice-9 curried-definitions
> In this section, the parenthesis nesting needs some adjustment.
>
> It should be
>
>   ((guile-v2)
>(if (ly:get-option 'verbose)
>(ly:message  (_ "Using (ice-9 curried-definitions) module\n")))
>(use-modules (ice-9 curried-definitions)))
>
> http://codereview.appspot.com/2219044/
Nice catch, ta.

Cheers,

Ian


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

chord naming

2010-10-22 Thread Janek Warchoł

Hi,

I'm from Poland and we use here a different chord naming convention: the
main difference is that minor chords are written with lowercase and major
chords are written with uppercase. I'd like to add this to Lily.
I found .ly files with alternative note names (used in other languages) in
\LilyPond\usr\share\lilypond\current\ly and hoped that adding another chord
naming style would be similar to adding another file with note names.
Unfortunately all i found is four .scm files in
\LilyPond\usr\share\lilypond\current\scm, but i'm not sure what should i do
with them (i have only basic C and Pascal skills) especially because i
cannot experiment on them (system prohibits modifying them). Can you give me
some instructions? Or is it too complicated and it would be wasting your
time?

cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: T1265 - Remove deprecation warnings when running with Guile V2 (issue2204044)

2010-10-22 Thread Ian Hulin

 Hi Patrick,

Patch is attached.

Cheers,

Ian

On 18/10/10 21:31, pnor...@gmail.com wrote:
> LGTM.
>
> Ian, please send me the git patch, and I'll apply it for you.
>
> Thanks,
> Patrick
>
> http://codereview.appspot.com/2204044/

>From a12cb1e44df280a1f4320d2be1ebb34711f979f4 Mon Sep 17 00:00:00 2001
From: Ian Hulin 
Date: Mon, 18 Oct 2010 20:20:07 +0100
Subject: [PATCH] T1265 - Remove deprecation warnings when running with Guile V2
 Replace scm_str2symbol with scm_from_locale_symbol,
  scm_symbol2_string with scm_to_locale_symbol,
  also scm_num2int, scm_int2num, scm_num2double

---
 flower/include/guile-compatibility.hh |   85 ++---
 lily/dispatcher.cc|6 +-
 lily/grob-array-scheme.cc |4 +-
 lily/include/lily-guile-macros.hh |   12 ++--
 lily/open-type-font.cc|6 +-
 lily/paper-book.cc|6 +-
 lily/paper-def.cc |2 +-
 lily/parse-scm.cc |2 +-
 lily/parser.yy|6 +-
 lily/percent-repeat-iterator.cc   |6 +-
 lily/piano-pedal-engraver.cc  |6 +-
 lily/translator.cc|2 +-
 12 files changed, 44 insertions(+), 99 deletions(-)

diff --git a/flower/include/guile-compatibility.hh b/flower/include/guile-compatibility.hh
index f18c182..bab8325 100644
--- a/flower/include/guile-compatibility.hh
+++ b/flower/include/guile-compatibility.hh
@@ -20,75 +20,20 @@
 #ifndef GUILE_COMPATIBILITY_HH
 #define GUILE_COMPATIBILITY_HH
 
-#if SCM_MINOR_VERSION < 7
-/* guile-1.6.x compatibility */
-
-inline SCM scm_cdr (SCM x)
-{
-  if (SCM_NCONSP (x))
-abort ();
-  return SCM_CDR (x);
-}
-inline SCM scm_car (SCM x)
-{
-  if (SCM_NCONSP (x))
-abort ();
-  return SCM_CAR (x);
-}
-#define SCM_I_CONSP(x) SCM_CONSP (x)
-inline SCM scm_caar (SCM x) { return SCM_CAAR (x); }
-inline SCM scm_cdar (SCM x) { return SCM_CDAR (x); }
-inline SCM scm_cadr (SCM x) { return SCM_CADR (x); }
-inline SCM scm_cddr (SCM x) { return SCM_CDDR (x); }
-inline SCM scm_caddr (SCM x) { return SCM_CADDR (x); }
-inline SCM scm_cdadr (SCM x) { return SCM_CDADR (x); }
-inline SCM scm_caadr (SCM x) { return SCM_CAADR (x); }
-inline SCM scm_cadar (SCM x) { return SCM_CADAR (x); }
-#define scm_gc_unregister_collectable_memory(a, b, c) scm_done_free (b)
-#define scm_gc_register_collectable_memory(a, b, c) scm_done_malloc (b)
-#define scm_is_vector(x) (SCM_VECTORP ((SCM) x))
-#define SCM_HASHTABLE_P(x) (SCM_VECTORP ((SCM) x))
-#define SCM_VECTOR_REF(v, i) (SCM_VELTS ((v))[ (i)])
-#define scm_from_bool(x) (x ? SCM_BOOL_T : SCM_BOOL_F)
-#define scm_from_int(x) SCM_MAKINUM (x)
-#define scm_from_unsigned_integer(x) scm_uint2num (x)
-#define scm_from_unsigned(x) scm_uint2num (x)
-#define scm_from_uint32(x) scm_uint2num (x)
-#define scm_is_integer(x) SCM_INUMP (x)
-#define scm_is_string(x) SCM_STRINGP (x)
-#define scm_hash_table_p scm_vector_p
-#define scm_from_locale_stringn(s, n) scm_mem2string (s, n)
-#define scm_from_locale_string(x) scm_makfrom0str (x)
-#define scm_i_string_chars(x) SCM_STRING_CHARS (x)
-#define scm_i_string_length(x) SCM_STRING_LENGTH (x)
-inline int ly_c_number_p (SCM x) { return SCM_NUMBERP (x); }
-#define scm_is_number(x) (scm_number_p (x) == SCM_BOOL_T)
-inline int ly_scm2int (SCM x) { return scm_num2int (x, 0, "ly_scm2int"); }
-#define scm_to_int(x) (ly_scm2int (x))
-inline int ly_scm2unsigned (SCM x) { return scm_num2uint (x, 0, "ly_scm2unsigned"); }
-#define scm_to_unsigned(x) (ly_scm2unsigned (x))
-inline int ly_c_symbol_p (SCM x) { return SCM_SYMBOLP (x); }
-#define scm_is_symbol(x) ly_c_symbol_p (x)
-inline int ly_c_boolean_p (SCM x) { return SCM_BOOLP (x); }
-#define scm_is_bool(x) ly_c_boolean_p (x)
-inline int ly_c_eq_p (SCM x, SCM y) { return SCM_EQ_P (x, y); }
-#define scm_is_eq(x, y) (SCM_EQ_P ((x), (y)))
-
-#define scm_c_string_length(x) SCM_STRING_LENGTH (x)
-#define scm_is_pair(x) (SCM_CONSP (x))
-
-#define scm_c_vector_length(x) SCM_VECTOR_LENGTH (x)
-#define scm_c_vector_ref(x, y) SCM_VECTOR_REF (x, y)
-
-inline double ly_scm2double (SCM x) { return scm_num2dbl (x, "ly_scm2double"); }
-#define scm_to_double(x) (ly_scm2double (x))
-#define scm_from_double(x) (scm_make_real (x))
-
-#else /* !SCM_MINOR_VERSION < 7 */
-
-#define scm_to_unsigned(x) scm_to_uint32 (x)
+#if SCM_MAJOR_VERSION == 1
+#if SCM_MINOR_VERSION > 6 && SCM_MINOR_VERSION < 9
+/*
+  GUILE V1.7.0 - V1.8.n
+*/
 #define scm_from_unsigned(x) scm_from_unsigned_integer (x)
-
-#endif /* !SCM_MINOR_VERSION < 7 */
-
+#else  // SCM_MINOR_VERSION >= 9
+/*
+  GUILE V1.9.n
+*/
+#endif // SCM_MINOR_VERSION > 6 && SCM_MINOR_VERSION < 9
+#else  // SCM_MAJOR_VERSION != 1
+/*
+   Add any compatibility definitions here for Guile V2.n
+*/
+#endif // SCM_MAJOR_VERSION == 1
 #endif /* GUILE_COMPATIBILITY_HH */
diff --git a/lily/dispatcher.cc b/lily/dispatcher.cc
index b91b4fa..7507501 100644
--- a/lily/dispatcher.cc
+++ b/lily/dispatcher.cc
@@ -185,7 +185,7

Re: chord naming

2010-10-22 Thread Carl Sorensen




On 10/22/10 5:08 AM, "Janek Warchoł" 
wrote:

> Hi,
> 
> I'm from Poland and we use here a different chord naming convention: the main
> difference is that minor chords are written with lowercase and major chords
> are written with uppercase. I'd like to add this to Lily.

I believe this has already been added to the current development version.

> I found .ly files with alternative note names (used in other languages) in
> \LilyPond\usr\share\lilypond\current\ly and hoped that adding another chord
> naming style would be similar to adding another file with note names.

It required some different changes.  For information on what changed, you
can see



> Unfortunately all i found is four .scm files in
> \LilyPond\usr\share\lilypond\current\scm, but i'm not sure what should i do
> with them (i have only basic C and Pascal skills) especially because i cannot
> experiment on them (system prohibits modifying them). 

If you install LilyPond for just you, then you will have write access to all
of the files.  

> Can you give me some
> instructions? Or is it too complicated and it would be wasting your time?

The best place to go for instructions is the Contributors' Guide, chapter 9.

HTH,

Carl


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

Re: Doc: NR 4.1.2: Setting alist keys properly. (issue2670041)


On 2010/10/22 13:07:27, Mark Polesky wrote:


It will be, but that change is beyond me.  I'll need to ask
Joe to do it, but I wanted to clear up everything else that
I can do on my own first.  Besides, I've grown to dislike
even "base-distance" because it sounds too much like the
distance between "bases", however that might be
interpreted.  Even if that particular thought doesn't occur
to a user, it's still ambiguous.  What do you think about
"unstretched-distance"?


I like it.

Carl


http://codereview.appspot.com/2670041/

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

Re: Doc: NR 4.1.2: Setting alist keys properly. (issue2670041)

2010-10-22 Thread David Kastrup

carl.d.soren...@gmail.com writes:

> On 2010/10/22 13:07:27, Mark Polesky wrote:
>
>> It will be, but that change is beyond me.  I'll need to ask
>> Joe to do it, but I wanted to clear up everything else that
>> I can do on my own first.  Besides, I've grown to dislike
>> even "base-distance" because it sounds too much like the
>> distance between "bases", however that might be
>> interpreted.

basic-distance would likely not have that defect.

>> Even if that particular thought doesn't occur to a user, it's still
>> ambiguous.  What do you think about "unstretched-distance"?
>
> I like it.

That seems inappropriate when we are actually seeing a shrink.

-- 
David Kastrup


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

Re: remove RemoveEmptyStaffContext from docs

2010-10-22 Thread Jean-Charles Malahieude


Le 22/10/2010 02:20, Graham Percival disait :


Bonjour Jean-Charles,

Je ne pense pas que nous voudrons avoir @funindex
RemoveEmptyStaffContext dans la documentation, parce-que cette
commande est désapprouvé. Ligne sept cent, trente-un dans
Documentation/fr/notation/staff.itely

A votre santé, - Graham



Désolé, mais il apparaît à la ligne 716 dans la version originale, ce
qui est la raison pour laquelle je l'ai laissé en français.

Cordialement,
Jean-Charles


-- Translation:

yo, get rid of @funindex RemoveEmptyStaffContext on line 731 of
staff.itely in the french docs.

Cheers, - Graham


Sorry, but it appears in the original version on line 716;
this is the reason why I left it in French.

Sincerely,
Jean-Charles




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

Re: font defects in scripts.varsegno and accordion.push

2010-10-22 Thread Marc Hohl


Am 20.10.2010 15:30, schrieb Werner LEMBERG:
   

The README also says that we shouldn't apply transformations to
fills, but instead transform the path then fill the path.  The
current varsegno transforms the penstroke, which I think is contrary
to this instruction.
 

Yep.  For this glyph it works accidentally.  Thanks for noticing, I've
missed it.
   
Um - so what do  I have to do? Rewrite the glyph completely, as Carl 
suggested,

with a proper outline, and unfill the loops? Or is there a easier way out?

Marc

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

Re: comment in #{ ... #}

> This does work:
> 
> foo =
> #(define-music-function (parser location music) (ly:music?)
>#{ $music % comment
>#})
> 
> { \foo a }

Interesting.  This

  T = #(define-music-function (parser location music) (ly:music?)
#{
   \times 2/3 $music   % $
#}
  )   

  \relative {
\T { c c c }
  }

does *not* work.  Looks like a bug...


Werner

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

Re: chord naming

2010-10-22 Thread Janek Warchoł

W dniu 22 października 2010 16:47 użytkownik Carl Sorensen <
c_soren...@byu.edu> napisał:

> On 10/22/10 5:08 AM, "Janek Warchoł"  > wrote:
>
> > Hi,
> > I'm from Poland and we use here a different chord naming convention: the
> main
> > difference is that minor chords are written with lowercase and major
> chords
> > are written with uppercase. I'd like to add this to Lily.
>
> I believe this has already been added to the current development version.
>

Oh.
You are right.
I thought that every change is listed in
changes
-
this one isn't...
Well, thats good for me :)
Sorry for spam.

If you install LilyPond for just you, then you will have write access to all
> of the files.

Ok.
Thank you!
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Segfault with define-music-function

2010-10-22 Thread Patrick McCarty

On Fri, Oct 22, 2010 at 6:06 AM, Valentin Villenave
 wrote:
> On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen  wrote:
>> As near as I can tell, this code is triggering an infinite loop that fails
>> when the scheme heap overflows.
>
> Interesting.
>
>> arg is *not* a stream-event, it's a music-event.
>
> Indeed. But I wasn't expecting it to cause a segfault.
>
>> Segfaults are supposed to always be critical errors, but I think that in the
>> case of incorrect Scheme code, we shouldn't label it as a LilyPond error.
>
> I agree. That's why I didn't open a tracker page.

The segfault occurs in LilyPond code though, so we should exit gracefully.

Reported as #1355:

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

Thanks,
Patrick

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

Re: comment in #{ ... #}

2010-10-22 Thread Reinhold Kainhofer

Am Freitag, 22. Oktober 2010, um 20:30:29 schrieb Werner LEMBERG:
> Interesting.  This
> 
>   T = #(define-music-function (parser location music) (ly:music?)
> #{
>\times 2/3 $music   % $
> #}
>   )
> 
> does *not* work.  Looks like a bug...

It seems like the way to replace all $ variables in the #{ ... #} section 
is not foolproof: It tries to replace everything starting with $, even if it 
is inside a comment. In particular, try this out:

   T = #(define-music-function (parser location music) (ly:music?)
 #{
\times 2/3 $music   % $m
 #}
   )
This complains about Unbound variable: m

Cheers,
Reinhold

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

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

Re: font defects in scripts.varsegno and accordion.push

>>> The README also says that we shouldn't apply transformations to
>>> fills, but instead transform the path then fill the path.  The
>>> current varsegno transforms the penstroke, which I think is
>>> contrary to this instruction.
>>>  
>> Yep.  For this glyph it works accidentally.  Thanks for noticing,
>> I've missed it.
>
> Um - so what do I have to do?

Nothing.  It accidentally works :-)


Werner

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

Re: Distributions upgrading to Python 3

2010-10-22 Thread Matthias Kilian

On Tue, Oct 19, 2010 at 12:07:29AM +0100, Graham Percival wrote:
> >> python/ yes, since it's not something that people call manually.
> >> But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise
> >> it'll bork if you call it manually.
> >
> > But are those scripts supposed to be used without runnig autogen.sh
> > (and implied configure) first?
> 
> Anything that's used to build the website (as opposed to the html
> version of the docs) cannot rely on configure.  This affects
> scripts/build/ create-*.py website_post.py bib2texi.py
> 
> ... admittedly, those are getting called with
> python scripts/build/foo.py
> , probably precisely to avoid this problem.  So I guess that's not a concern.

Oh, it would still be better to use something like

PYTHON?=python
...
WEB_POST=${PYTHON} $(script-dir)/website_post.py

in files like make/website.make (but probably only of people using
this part start to complain about annoyances).

> > #!/usr/bin/env YOUR_FAVORITE_INTERPRETER
> >
> > should not be used ever. At least not for scripts that will be
> > installed system-wide.
> 
> Why not?  IIRC, we had to add this to work around some problem in OSX.
>  The discussion is in the email archives... hopefully somebody can dig
> it out for us.

I didn't dig it yet, but for OSX (and every system where people
have to rely on binary installers provided by lilypond.org) it may
be that different OSX versions have python installed in different
locations. If my guess is correct, it would be nice if someone could
hack on the OSX binary to do some post-install patching on the
installed python scripts.

> If there's a good reason not to do this, and a better way of solving
> whatever problem we solved with /usr/bin/env python, I welcome a
> change.

The good reason is: whatever you install system-wide with a
#!/usr/bin/env line is out of your control. It immediately depends
on the users PATH. Ignoring security issues for now, #!/usr/bin/env
may trigger completely unexpected (for lilypond developers, or OS
package maintainers) behaviour on a users system.

Ciao,
Kili

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

Re: comment in #{ ... #}

On Fri, Oct 22, 2010 at 8:30 PM, Werner LEMBERG  wrote:
> Interesting.  This
> [...]
> does *not* work.  Looks like a bug...

Sure does.

Added as http://code.google.com/p/lilypond/issues/detail?id=1356

Nice catch!

Valentin.

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

doc additions power chords (issue2686041)


Reviewers: ,

Message:
Patrick Schmidt has added two- and three-note power chords to the known
set of chord names.

He's provided both code and docs.

Please review.

Thanks,

Carl


Description:
doc additions power chords
additions to fretted-strings.itely description and examples for the use
of the new command \powerChords
addition of two new modifiers to notation-appendices.itely

power chord symbol
Added power chord definition, symbol and command to typeset this symbol.

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

Affected files:
  M Documentation/notation/fretted-strings.itely
  M Documentation/notation/notation-appendices.itely
  M ly/chord-modifiers-init.ly
  M ly/property-init.ly



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

Doc: NR 4.4.1: Rewrite. (issue2642043)


Reviewers: ,

Message:
Here's a completely rewritten version of
NR 4.4.1 Vertical spacing inside a system

Comments?

Thanks.
- Mark

Description:
Doc: NR 4.4.1: Rewrite.

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

Affected files:
  M Documentation/notation/spacing.itely



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

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

Mark,

I think this is a great start, and will greatly help.

The major issues I see are (1) repeating information (i.e. the meanings
of space, minimum-distance, padding, and stretchability), and (2)
introducing exhaustive lists into the NR.

Repeating information is prohibited by policy because it becomes very
difficult to keep two parallel sections in synch.

Exhaustive lists belong in the IR, instead of the NR. THat way they are
automatically updated.

Other than that, I have some editorial comments.

Great work!

Thanks,

Carl

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (left):

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#oldcode1697
Documentation/notation/spacing.itely:1697: A non-staff line at the
bottom of a system should have
I think that this section should not be removed.

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

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1501
Documentation/notation/spacing.itely:1501: @item @emph{staff-like
contexts} (such as @code{Lyrics}).
I would change this to "non-staff" contexts, I think. I liked the
previous terminology.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1506
Documentation/notation/spacing.itely:1506:
I think that you should explain the different grobs that are created by
each of the contexts at this point. I got lost while I was waiting.
I'd like to see:

Staff contexts create VerticalAxisGrouper grobs

StaffGroup contexts create StaffGrouper grobs

non-staff contexts create VerticalAxisGrouper grobs

Or maybe the word is "result in" instead of create.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1510
Documentation/notation/spacing.itely:1510: the staves.
WHen do the staff-groups get spaced?

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1529
Documentation/notation/spacing.itely:1529: @subsubheading Structure of
spacing alists for grob properties
"Structure of alists for vertical spacing properties" is a better name,
I think.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1554
Documentation/notation/spacing.itely:1554: @item @code{minimum-distance}
-- the minimum required vertical
I think I would change "minimum required" to "minimum allowable"

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1578
Documentation/notation/spacing.itely:1578: @subsubheading Modifying
spacing alists for grob properties
Reference to the between system spacing, instead of repeating. Just
introduce the new syntax as it applies to the in-system contexts.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1814
Documentation/notation/spacing.itely:1814: @item @code{ChoirStaff}
In general, we don't want to make exhaustive lists in the docs, because
maintaining them is a problem.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1836
Documentation/notation/spacing.itely:1836: The default value of
@code{next-staff-spacing} is a callback
This is too much talking through the code, I think.

Better to just say next-staff-spacing is a procedure that will return
after-last-staff-spacing if the staff is the last staff of a group, the
between-staff-spacing if the staff is not the last staff of a group,
and the default-next-staff-spacing if the staff is not part of a group.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1881
Documentation/notation/spacing.itely:1881: @item @code{ChordNames}
I don't think we want exhaustive lists. (But Graham will correct me if
I'm wrong.)

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1897
Documentation/notation/spacing.itely:1897: @item
@code{inter-loose-line-spacing}
Since the property name is inter-loose-line-spacing, we may want to call
these contexts "loose line contexts" instead of staff-like or non-staff
contexts.

http://codereview.appspot.com/2642043/

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

Re: remove RemoveEmptyStaffContext from docs

2010-10-22 Thread Graham Percival

On Fri, Oct 22, 2010 at 07:49:43PM +0200, Jean-Charles Malahieude wrote:
> Le 22/10/2010 02:20, Graham Percival disait :
> >
> >Je ne pense pas que nous voudrons avoir @funindex
> >RemoveEmptyStaffContext dans la documentation, parce-que cette
> >commande est désapprouvé. Ligne sept cent, trente-un dans
> >Documentation/fr/notation/staff.itely
> 
> Désolé, mais il apparaît à la ligne 716 dans la version originale, ce
> qui est la raison pour laquelle je l'ai laissé en français.

Pardonez-moi, ca c'est ma problemme.  J'ai correté la version à
ligne 765 dans l'anglais, mais j'ai oublié de changé ligne 716.
Ca c'est poussé.


> >-- Translation:
> >
> >yo, get rid of @funindex RemoveEmptyStaffContext on line 731 of
> >staff.itely in the french docs.
> >
> >Cheers, - Graham
> 
> Sorry, but it appears in the original version on line 716;
> this is the reason why I left it in French.

Whoops, I fixed line 765, but missed 716.  Fix pushed.

Could you warn other translators of this manual attention that's
needed for this particular convert-ly run?

Cheers,
- Graham

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

Re: doc additions power chords (issue2686041)

2010-10-22 Thread percival . music . ca


Looks mostly fine.


http://codereview.appspot.com/2686041/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/2686041/diff/1/Documentation/notation/fretted-strings.itely#newcode1416
Documentation/notation/fretted-strings.itely:1416: \clef "treble_8"
None of these lines should be indented.

http://codereview.appspot.com/2686041/diff/1/Documentation/notation/fretted-strings.itely#newcode1478
Documentation/notation/fretted-strings.itely:1478: \clef "treble_8"
None of these lines should be indented.  Also, remove the [fragment].

http://codereview.appspot.com/2686041/

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

Re: doc additions power chords (issue2686041)


On 2010/10/23 01:30:43, Graham Percival wrote:

Looks mostly fine.


Fixed all of these, plus another couple of lines of LilyPond code that
were incorrectly indented.


http://codereview.appspot.com/2686041/

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

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

On 2010/10/23 00:51:31, Carl wrote:

Mark,

I think this is a great start, and will greatly help.

The major issues I see are (1) repeating information
(i.e. the meanings of space, minimum-distance, padding,
and stretchability), and (2) introducing exhaustive lists
into the NR.

Carl,

(1) repeating information -- I'll try to fix this.
(1) repeating information -- I'll try to fix this.
(2) exhaustive lists -- see my replies to your code comments.

Thanks for looking over this so thoroughly!
- Mark

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (left):

I think that this section should not be removed.

I moved it to the staff-affinity description (l.1674).

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

I would change this to "non-staff" contexts, I think. I
liked the previous terminology.

The original "non-staff lines" is still better than
"non-staff contexts" (which can imply Voice and Score), but
"non-staff lines" reads like "the opposite of staff lines",
which is confusing. I suppose defining the term clearly at
the top will help. If I change it back to "non-staff
lines", I should change the others to "staves" and
"staff-groups".

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1506
Documentation/notation/spacing.itely:1506:
23 00:51:31, Carl wrote:

I think that you should explain the different grobs that
are created by each of the contexts at this point. I got
lost while I was waiting.

Already in the intro? I think just after the "Inter-system
spacing properties" heading is a better place. I'd prefer
to just change the previous sentence to:

"Each of these context types uses a slightly different
method for specifying the vertical spacing, which will be
explained below."

Did you really get lost while you were waiting? And do
users really need to know that different contexts create
different grobs? Wouldn't that be "talking through the
code" a little too much? Also, even though staff-group
contexts don't create the VerticalAxisGroup grob, their
constituent staves do, and this in turn influences their
spacing. I think your suggestion might be a little
misleading.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1510
Documentation/notation/spacing.itely:1510: the staves.
On 2010/10/23 00:51:31, Carl wrote:

When do the staff-groups get spaced?

This is trivial fix; I'll put it in the next patch set.

I think I would change "minimum required" to "minimum
allowable"

Huh. For me, the phrase associations are "minimum required"
and "maximum allowable". Such as "you must have at least x"
and "you are allowed no more than y".

Reference to the between system spacing, instead of
repeating. Just introduce the new syntax as it applies to
the in-system contexts.

You mean a link to NR 4.1.2 "Modifying spacing alists for
\paper variables"? That's not a bad idea, but that section
is a texinfo "subsubheading", which IIRC can't be a
cross-referencable node. I'll look into this.

This is too much talking through the code, I think.

I mostly copied this from the previous version. I explained
this from a user's perspective in the property descriptions
above, so I'm fine with just removing this paragraph.

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1881
Documentation/notation/spacing.itely:1881: @item @code{ChordNames}
On 2010/10/23 00:51:31, Carl wrote:

I don't think we want exhaustive lists. (But Graham will
correct me if I'm wrong.)

Hmm. One argument for an exhaustive list would be that it's
just good to know that FretBoards and FiguredBass are
"non-s

Re: doc additions power chords (issue2686041)

2010-10-22 Thread percival . music . ca


LGTM, go ahead and push.


http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely#newcode1422
Documentation/notation/fretted-strings.itely:1422: g-\rightHandFinger #3
c-\rightHandFinger #4 >1
The intent here was to show that the g was still part of the chord.

Since we don't have a formal input syntax style yet, I don't mind this
change.  Just thought I'd mention it; if you'd rather keep the original
version, that'd also be fine.

http://codereview.appspot.com/2686041/

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

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)