Re: Overview of copyright issues + Debian

[Joseph Wakeling]

Graham Percival wrote:
> The beginnings of the manuals.  In my restructuring, that's now in
> macros.itexi, although this may well move to a third macro file.
> Hmm, I just noticed that the copyright years are messed up... I'll
> fix that fairly soon.

Brilliant.  So as far as the docs are concerned that reduces my task to
'Who contributed to ... ?' rather than 'Do they agree to ... ?'

In that case I'll submit a patch with licensing notices for doc files.
I will still work on identifying who should be credited as authors on a
file-by-file basis.

Best wishes,

-- Joe


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

Re: Overview of copyright issues

[Jan Nieuwenhuizen]

Op donderdag 10-09-2009 om 23:47 uur [tijdzone +0100], schreef Graham
Percival:
> On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote:
> > 
> > On 9/10/09 4:02 PM, "Graham Percival"  wrote:
> > 
> > > On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote:

> Yes, but then the FSF went and royally screwed us by making GPLv3
> incompatible with v2.  For an organization that's supposed to
> encourage openness and collaboration, this was MONUMENTALLY
> stupid.

The FSF has always adviced and argued to use v2 or at your option
any later version.  I got tired of arguing with Han-Wen that being
paranoid does not bring you anything and gave in to strict v2, so
it was *me* who was monumentally stupid.

Jan.

-- 
Jan Nieuwenhuizen  | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl| http://lilypond.org



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

Re: Overview of copyright issues

[Joseph Wakeling]

Carl Sorensen wrote:
> Amen to that.  If only they had made some kind of an accomodation clause
> that would have allowed projects with mixed v2 and v3 licenses to go
> forward, as long as the v3 license terms were followed on the combined
> package (e.g. no tivoization, and following the patent stuff).  But they
> don't.

There was no way they could have done that, unfortunately. :-(  It's not
a matter of GPLv3 accommodating GPLv2 but the other way round -- GPLv2
has a 'no additional clauses' requirement and GPLv3 applies ...
additional clauses.


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

[PATCH] Doc: copyright/licensing notice for contemporary music section.

[Joseph Wakeling]

This one IS for inclusion in the main source tree, unless there is a
problem with it. :-)

I'll be adding the same licensing notice to all files in the docs unless
anyone objects.  (Debian-related comments particularly welcome.)

For COPYRIGHT notices I will take longer and try and identify concretely
who contributed what on a file-by-file basis.

Best wishes,

-- Joe
From ac8a3517383a3f5aea9ab9b6c0efb672b620800f Mon Sep 17 00:00:00 2001
From: Joseph Wakeling 
Date: Fri, 11 Sep 2009 10:58:26 +0200
Subject: [PATCH] Doc: copyright/licensing notice for contemporary music section.

---
 Documentation/notation/contemporary.itely |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/Documentation/notation/contemporary.itely 
b/Documentation/notation/contemporary.itely
index 34dda95..c92ea47 100644
--- a/Documentation/notation/contemporary.itely
+++ b/Documentation/notation/contemporary.itely
@@ -1,5 +1,22 @@
 @c -*- coding: utf-8; mode: texinfo; -*-
 @ignore
+Documentation/notation/contemporary.itely
+
+Copyright © 2009 Joseph Wakeling 
+
+This file is part of the documentation for GNU Lilypond.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1
+or any later version published by the Free Software Foundation;
+with no Invariant Sections, no Front-Cover Texts and no Back-Cover
+Texts.
+
+You should have received a copy of the GNU Free Documentation License
+along with this file.  If not, see .
+...@end ignore
+
+...@ignore
 Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
 
 When revising a translation, copy the HEAD committish of the
-- 
1.6.3.3

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

Re: Overview of copyright issues

[Joseph Wakeling]

Francisco Vila wrote:
> 2009/9/11 Francisco Vila :
>> Those stats are very old now.
> 
> They are now up to date, just in case.
> 
> http://paconet.org/lilypond-statistics/

Thanks very much for this! :-)

It leads to the question -- already in mind from browsing the git log --
who is 'fred'?  There is no full name and no email ('fred '), but
a lot of commits are in his name.  Is this someone responsible for much
code?  Or just someone responsible for managing the git or cvs repo in
the past?

And no, it seems docs are (fortunately) already 'or later', so we don't
have to worry on that account. :-)


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

Re: Overview of copyright issues

[John Mandereau]

Le jeudi 10 septembre 2009 à 00:24 +0200, Joseph Wakeling a écrit :
> But anyway, I'm willing to do the typing side of it.  I just need you to
> clarify exactly what I should put: presumably GPLv2 for code files and
> GFDLv1.1 for docs are the base licenses, but would you and Jan approve
> putting GPLv2 or later for your own contributions?  What are your
> thoughts (and recommendations) for code written by others?  I know that
> you ran into a paperwork issue some time back that has never been resolved.

For the record, I agree to license/relicense all my code contributions
(mostly Python scripts and makefiles) under GPLv2+ or GPLv3+, and
dual-license my doc contributions under GFDL1.1+ and GPLv2+.  I also
hope that I'll junk all dirty scripts I wrote before a copyright header
is added to them, but I'm not sure I can achieve this :-)

Cheers,
John


signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Overview of copyright issues

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Freitag, 11. September 2009 11:14:39 schrieb Joseph Wakeling:
> Francisco Vila wrote:
> > 2009/9/11 Francisco Vila :
> >> Those stats are very old now.
> >
> > They are now up to date, just in case.
> >
> > http://paconet.org/lilypond-statistics/
>
> Thanks very much for this! :-)

FWIW, I've now added a .mailcap file, so names like "wl" or "Andrew Hawyluk" or 
"Carl Sorensen" should now be combined with the correct names "Werner 
Lemberg", "Andrew Hawryluk" and "Carl D. Sorensen".

So "git shortlog" or "git shortlog -s" should now give less contributors and a 
better overview.

I've also added all adresses, which already use the correct name (I just took 
the output of "git shortlog -s -e" and corrected some apparently wrong or 
missing names). 

There are some open committers, though:

Maximiliano 
Maximiliano 
Lilypond GDP 
kroger 
reuter 
root 
andrew 
erik 
fred 
uid67283 


> It leads to the question -- already in mind from browsing the git log --
> who is 'fred'?  There is no full name and no email ('fred '), but
> a lot of commits are in his name.  Is this someone responsible for much
> code?  

IIRC, that's the name that Jan or Han-Wen used to import the old versions into 
git (or svn).

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKqhiLTqjEwhXvPN0RAt1/AKC2eg4shejENUxsFFNTJFC2rUVLKgCfY1vV
HvVtGe9lfprJD+a4s1lelbI=
=skRa
-END PGP SIGNATURE-


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

Unsecure assoc calls (was: Make default margin values depend on paper size)

[Michael Käppler]

Hi Carl,
(was it your intention to discuss this off-list? I ask because you 
didn't cc the list for the last two times.)

Hmmm -- I see your point.

Without looking into the code for each of those grep results, I couldn't
answer.  But assoc-get is defined in LilyPond, and was certainly recommended
by Han-Wen when I first started programming Scheme in LilyPOnd.

I wonder if I'm being overly sensitive, or if many of these assoc calls are
left over from before assoc-get was defined.
I would propose to modify assoc-get the way it is indicated in the 
attached patch and then migrate all assoc calls to assoc-get calls.

This assoc-get calls would be divided into two classes.
1. Silently set a default value, since there is nothing erroneous happening.
2. Set a default value and output a programming_error, showing the key 
which failed.


Of course that would also happen with chain-assoc-get.
I also recognized that some assoc-get or chain-assoc-get calls occur 
with #f set as default value, which I think is unnecessary since #f is 
the hardcoded default already.


Regards,
Michael
>From 5fb65494ecb7e25d87fdfea6ce2133a818631df8 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= 
Date: Fri, 11 Sep 2009 11:44:32 +0200
Subject: [PATCH] Proposal to change ly:assoc-get method.

---
 lily/general-scheme.cc |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lily/general-scheme.cc b/lily/general-scheme.cc
index 43ff745..d6dffb9 100644
--- a/lily/general-scheme.cc
+++ b/lily/general-scheme.cc
@@ -155,7 +155,7 @@ LY_DEFINE (ly_dir_p, "ly:dir?",
 
 LY_DEFINE (ly_assoc_get, "ly:assoc-get",
 	   2, 1, 0,
-	   (SCM key, SCM alist, SCM default_value),
+	   (SCM key, SCM alist, SCM default_value, SCM strict_checking),
 	   "Return value if @var{key} in @var{alist}, else @code{default-value}"
 	   " (or @code{#f} if not specified).")
 {
@@ -168,6 +168,9 @@ LY_DEFINE (ly_assoc_get, "ly:assoc-get",
   if (default_value == SCM_UNDEFINED)
 default_value = SCM_BOOL_F;
 
+  if (strict_checking == SCM_BOOL_T)
+programming_error ("Cannot find key ~S in alist, setting to ~S.", ly_scm2string (key), ly_scm2string (default_value));
+
   return default_value;
 }
 
-- 
1.6.0.2

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

Re: [PATCH] New margin handling - final version (updated)

[Michael Käppler]

Hi all,
I've just removed some code from page.scm that becomes obsolete through 
the patch.
I would be really happy if somebody could test this for regressions. The 
problem is that for me it takes more than 12 hours to run a "make doc" 
and for this time I can't do anything other.

(Just to give you an impression about my system's slowness)

Regards,
Michael
>From 7235a6af9fc738cea7e35d0e5063f772c7e94af1 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= 
Date: Fri, 11 Sep 2009 12:06:37 +0200
Subject: [PATCH] Introduce new handling for paper margin settings.

* Make default margins accessible in ly/paper-defaults-init.ly

* Introduce a new method: Output_def::normalize (). It checks,
  whether left-margin, right-margin and/or line-width are set.
  Afterwards it computes missing values or takes defaults, if
  necessary. There is no need to specify line-width manually now.

* Make right-margin work

* If only line-width is set, the current behaviour persists.
  (Systems are centered)

* Output a warning if the margin values don't fit with each other

* Modify lilypond-book to get rid of the
  (define line-width (- line-width 3\mm)) stuff and introduce
  line-width-cropping for compatibility.
---
 input/regression/paper-margins.ly |   60 +++
 lily/book.cc  |1 +
 lily/include/output-def.hh|3 +-
 lily/output-def.cc|   92 -
 lily/paper-book.cc|   11 ++-
 ly/paper-defaults-init.ly |  206 -
 scm/page.scm  |6 +-
 scm/paper.scm |   18 ++--
 scripts/lilypond-book.py  |2 +-
 9 files changed, 286 insertions(+), 113 deletions(-)
 create mode 100644 input/regression/paper-margins.ly

diff --git a/input/regression/paper-margins.ly b/input/regression/paper-margins.ly
new file mode 100644
index 000..2d9b5dc
--- /dev/null
+++ b/input/regression/paper-margins.ly
@@ -0,0 +1,60 @@
+\version "2.13.4"
+
+\header {
+  texidoc = "Paper margin settings don't have to be complete. Missing values are added automatically, finally 
+ everything is checked for consistency."
+}
+
+#(set-default-paper-size "a4")
+
+someNotes = \relative c' { \repeat unfold 40 { c4 d e f }}
+
+\book {
+  \bookpart {
+\paper { }
+\markup { If no paper settings are specified, default values are used. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  left-margin = 40 \mm
+}
+\markup { You may also specify only some margins. Missing values are added, if possible. }
+\markup { Here only left-margin is given, right-margin will remain default. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  right-margin = 40 \mm
+}
+\markup { Here only right-margin is given, left-margin will remain default. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  line-width = 100 \mm
+}
+\markup { If only line-width is given, the systems are vertically centered. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  left-margin = 20 \mm
+  right-margin = 40 \mm
+  line-width = 100 \mm
+}
+\markup { If you specify line-margin, right-margin and line-width, the values must be consistent. }
+\markup { In case they are not, default margins are set and a warning is printed. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  left-margin = 20 \mm
+  right-margin = 40 \mm
+  line-width = 200 \mm
+  check-consistency = ##f
+}
+\markup { You can avoid this check with settings check-consistency to false in the paper block. }
+\score { \someNotes }
+  }
+}
diff --git a/lily/book.cc b/lily/book.cc
index 303af1b..86eeda1 100644
--- a/lily/book.cc
+++ b/lily/book.cc
@@ -277,6 +277,7 @@ Book::process (Output_def *default_paper,
 }
   else
 {
+  paper_book->paper_->normalize ();
   /* Process scores */
   /* Render in order of parsing.  */
   for (SCM s = scm_reverse (scores_); scm_is_pair (s); s = scm_cdr (s))
diff --git a/lily/include/output-def.hh b/lily/include/output-def.hh
index b683cc6..9e28d18 100644
--- a/lily/include/output-def.hh
+++ b/lily/include/output-def.hh
@@ -58,13 +58,14 @@ public:
   SCM c_variable (string id) const;
   SCM lookup_variable (SCM sym) const;
   void set_variable (SCM sym, SCM val);
+  void normalize ();
   Real get_dimension (SCM symbol) const;
 };
 SCM get_font_table (Output_def *def);
 void assign_context_def (Output_def *m, SCM transdef);
 SCM find_context_def (Output_def const *m, SCM name);
 
-Interval line_dimensions_int (Output_def*def, int);
+Interval line_dimensions_int (Output_def *def, int);
  
 
 Font_metric *select_encoded_font (Output_def *layout, SCM chain);
diff --git a/lily/output-def.cc b/lily/output-def.cc
index f9fbda9..3f60861 100644
--- a/lily/output-def.cc
+++ b/lily/output-def.cc
@@ -11,6 +11,7 @@
 #include "context-def.hh"
 #inclu

Re: Overview of copyright issues

[Francisco Vila]

2009/9/11 Reinhold Kainhofer :
> FWIW, I've now added a .mailcap file, so names like "wl" or "Andrew Hawyluk" 
> or
> "Carl Sorensen" should now be combined with the correct names "Werner
> Lemberg", "Andrew Hawryluk" and "Carl D. Sorensen".
>
> So "git shortlog" or "git shortlog -s" should now give less contributors and a
> better overview.

Well, we have duplicated the effort. I mentioned this in this very thread.

There is no need to put names and addresses that are already correctly
spelt in the file; it only makes sense if names or addresses vary for
the same author.  Anyway, we now have a comprehensive e-mail
directory.

> There are some open committers, though:
...
> kroger 

Pedro Kroger 

> reuter 

Jürgen Reuter,  reuter [at] ipd [dot] uka [dot] de

> root 

Graham Percival.

> andrew 

this could be Andrew Hawryluk or A. Wilson

> erik 

Erik Sandberg 

> fred 

Han-Wen Nienhuys and Jan Nieuwenhuizen 

> uid67283 

Han-Wen Nienhuys , I think

>> It leads to the question -- already in mind from browsing the git log --
>> who is 'fred'?  There is no full name and no email ('fred '), but
>> a lot of commits are in his name.  Is this someone responsible for much
>> code?
>
> IIRC, that's the name that Jan or Han-Wen used to import the old versions into
> git (or svn).

I asked the same on February and here is the answer:

http://lists.gnu.org/archive/html/lilypond-devel/2009-02/msg00029.html
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com


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

Re: Overview of copyright issues

[Francisco Vila]

2009/9/11 Reinhold Kainhofer :
> So "git shortlog" or "git shortlog -s" should now give less contributors and a
> better overview.

Please add

  Francisco Vila 
  Francisco Vila 

so that Paco Vila gets redirected to me (that is the purpose of the
file as I understand it)

Other issues could arise; let's talk about them in private.  I could
also commit the changes that are necessary, directly.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com


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

Re: shortcut for creating new Staff "subclass" context?

[Kieren MacMillan]

Hi Dan,

it looks like "\Voice" starts you off with a copy of the previously  
defined

Voice settings.  If "\Voice" is absent, you start from scratch.
The context settings are saved by name.  If you do not change the  
name,
the modified settings replace the previous settings of the \Voice  
context.

If you change the name, a new kind of context is created.


That is a pretty clear explanation of what \Voice [\Staff, etc.] and  
\name "Foo" do — thank you!



I haven't looked into \alias.


On the doc page

  


it says

  “Since it is similar to the Voice, we want commands that work on
  (existing) Voices to remain working. This is achieved by
  giving the new context an alias Voice:
  \alias Voice”

Though not completely descriptive — for example, how would you define  
a context that accepts a brand new command (that isn't in some other  
existing context)? — at least we know we have to \alias if we want to  
duplicate the behaviour (as differentiated from the settings) of  
another context.


Now my question is... does the order of the lines matter at all? I'm  
assuming they do — e.g., if you don't change the \name until after  
changing some \override, there'll be confusion — but does anyone know  
for certain what the precedence must be?


Thanks,
Kieren.

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

Re: Switching to Waf instead of SCons?

[Travis Briggs]

I have a lot of experience with Apache Ant, so I'd be willing to help out too.

-Travis

On Thu, Sep 10, 2009 at 6:25 PM, Carl Sorensen  wrote:
>
>
>
> On 9/10/09 3:10 PM, "John Mandereau"  wrote:
>
>> Le mardi 08 septembre 2009 à 19:53 +0100, Graham Percival a écrit :
>>> The most important two factors, in my mind, are "how interested
>>> are you?" (very interested), and "will you have enough time to
>>> finish it?".  I'm not so concerned about using waf for everything,
>>> but do you think you can get the docs using waf before you become
>>> busy again?
>>
>> I hope so.  I read through the Waf book and put a quick draft of a
>> migration plan at http://wiki.lilynet.net/index.php/Switching_to_Waf
>> This plan mainly aims at helping me putting ideas in good order and
>> informing you of the goals and progress of the migration, but it would
>> be wonderful if it could also motivate some developers to help with this
>> migration :-)
>
> I'd be willing to give a hand if I can.  I read your wiki page, but didn't
> get anything from it in terms of how I could help.  Give me a ping if you
> get to the point that you can carve out some kind of task for me to try.
>
> I actually think that the build system is the current biggest weakness in
> LilyPond; it's hanging out there just waiting to crash, and not very many
> people understand it.
>
> Thanks,
>
> Carl
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>


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

Re: Unsecure assoc calls (was: Make default margin values depend on paper size)

[Carl Sorensen]

On 9/11/09 3:52 AM, "Michael Käppler"  wrote:

> Hi Carl,
> (was it your intention to discuss this off-list? I ask because you
> didn't cc the list for the last two times.)

No, I made a mistake the first time, and the second time I replied all to
your email that replied to mine.

>> Hmmm -- I see your point.
>> 
>> Without looking into the code for each of those grep results, I couldn't
>> answer.  But assoc-get is defined in LilyPond, and was certainly recommended
>> by Han-Wen when I first started programming Scheme in LilyPOnd.
>> 
>> I wonder if I'm being overly sensitive, or if many of these assoc calls are
>> left over from before assoc-get was defined.
> I would propose to modify assoc-get the way it is indicated in the
> attached patch and then migrate all assoc calls to assoc-get calls.
> This assoc-get calls would be divided into two classes.
> 1. Silently set a default value, since there is nothing erroneous happening.
> 2. Set a default value and output a programming_error, showing the key
> which failed.

I think this is a good idea, because it gives us an additional tool to
cleanly handle errors.

> LY_DEFINE (ly_assoc_get, "ly:assoc-get",
>   2, 1, 0,

This line is wrong; you need to have the total of these three numbers
be the total number of arguments.

If you change this to 2, 2, 0, then strict-checking will be an optional
argument, and all of the existing calls will work as is.

If you don't want to have strict-checking an optional argument, then the
line should be 3, 1, 0, and strict-checking will have to come before
default_value, as default_value is an optional argument.


> -  (SCM key, SCM alist, SCM default_value),
> +  (SCM key, SCM alist, SCM default_value, SCM strict_checking),
>   "Return value if @var{key} in @var{alist}, else
> @code{default-value}"
>   " (or @code{#f} if not specified).")
> 

IIRC, programming errors are not internationalized.  Is that your
understanding?


> Of course that would also happen with chain-assoc-get.
> I also recognized that some assoc-get or chain-assoc-get calls occur
> with #f set as default value, which I think is unnecessary since #f is
> the hardcoded default already.

It's probably not necessary, but if you really want the default value of #f,
it's probably best to include it in the code.  It conveys the intent more
clearly to the reader, and doesn't cost anything in performance, IMO.

Thanks,

Carl



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

Re: Overview of copyright issues

[Graham Percival]

On Fri, Sep 11, 2009 at 11:14:39AM +0200, Joseph Wakeling wrote:
> It leads to the question -- already in mind from browsing the git log --
> who is 'fred'?

Please get into the habit of searching -devel before asking such
questions.  The answer is on the top 10 results for "fred" on a
lilypond-devel search.

Cheers,
- Graham


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

Re: Overview of copyright issues

[Anthony W. Youngman]

In message <1252655677.8830.236.ca...@heerbeest>, Jan Nieuwenhuizen 
 writes

Op donderdag 10-09-2009 om 23:47 uur [tijdzone +0100], schreef Graham
Percival:

On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote:
>
> On 9/10/09 4:02 PM, "Graham Percival"  wrote:
>
> > On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote:



Yes, but then the FSF went and royally screwed us by making GPLv3
incompatible with v2.  For an organization that's supposed to
encourage openness and collaboration, this was MONUMENTALLY
stupid.


The FSF has always adviced and argued to use v2 or at your option
any later version.  I got tired of arguing with Han-Wen that being
paranoid does not bring you anything and gave in to strict v2, so
it was *me* who was monumentally stupid.

Jan.


Well, Han-Wen is in good company - Linus!

So I take this to mean all your code is v2+? Whatever Han-Wen said has 
no influence on YOUR code. And all we need is for Han-Wen to say he's 
happy with v3, and all your worries have gone away. (The problem is if 
Han-Wen goes away, but hopefully his will leaves all his copyrights to 
the FSF :-)


You may have been monumentally stupid, but it wasn't arguing about 
paranoia. It was trying to apply YOUR choice of licence to SOMEONE 
ELSE'S CODE. That's ALWAYS a stupid idea.


Cheers,
Wol
--
Anthony W. Youngman - anth...@thewolery.demon.co.uk



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

Re: Switching to Waf instead of SCons?

[John Mandereau]

Hi Carl,
Le jeudi 10 septembre 2009 à 16:25 -0600, Carl Sorensen a écrit :
> I'd be willing to give a hand if I can.  I read your wiki page, but didn't
> get anything from it in terms of how I could help.  Give me a ping if you
> get to the point that you can carve out some kind of task for me to try.

At this early stage, I've just found that Waf doesn't provide any
built-in generic function to check a program version, so I'm writing a
function to provide this feature, and I have started writing a Waf tool
for Texinfo.  The two tasks you could look at to begin are

- add attached wscript to top of the source directory, replace
hard-coded VERSION by some code that parses the VERSION file (Python std
lib has a module for parsing configuration files), and commit this
wscript to dev/waf branch;

- add configure (conf) function stub in wscript, that sets in Waf
environment the correct value of LILYPOND_BINARY, trying in the
following order:
  1) get and check value LILYPOND_EXTERNAL_BINARY from system
environment
  2) if GNUmakefile and config.make exist in the build tree (not in the
source tree!), and last line of config.log is "configure: exit 0", then
we can assume that the build tree has been configured for configuration
of LilyPond binary, so we set LILYPOND_BINARY to
"$(configure-builddir)/out/bin/lilypond --relocate"
  3) use conf.check_program ('lilypond', var='LILYPOND_BINARY') to try
to find lilypond binary in PATH

Just look at the relevant parts of the Waf book and/or in demos in Waf
sources (installed in /usr/share/doc/waf-x.y.z/demos/ if waf is provided
by your distro).


> I actually think that the build system is the current biggest weakness in
> LilyPond; it's hanging out there just waiting to crash, and not very many
> people understand it.

Indeed.  The web site would have certainly already been ready to be
released (including translations) if we had a more maintainable and
newcomers-friendly (if ever possible) build system.

Good luck,
John
VERSION='2.13.4'
APPNAME='lilypond'
srcdir = '.'
blddir = 'out'


signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unsecure assoc calls

[Michael Käppler]

Hi Carl,

LY_DEFINE (ly_assoc_get, "ly:assoc-get",
  2, 1, 0,



This line is wrong; you need to have the total of these three numbers
be the total number of arguments.
  

Yes, I forgot to adjust this.

If you change this to 2, 2, 0, then strict-checking will be an optional
argument, and all of the existing calls will work as is.
  

That's what I'd prefer.

-  (SCM key, SCM alist, SCM default_value),
+  (SCM key, SCM alist, SCM default_value, SCM strict_checking),
  "Return value if @var{key} in @var{alist}, else
@code{default-value}"
  " (or @code{#f} if not specified).")




IIRC, programming errors are not internationalized.  Is that your
understanding?
  

Yes, why do you ask?

Of course that would also happen with chain-assoc-get.
I also recognized that some assoc-get or chain-assoc-get calls occur
with #f set as default value, which I think is unnecessary since #f is
the hardcoded default already.



It's probably not necessary, but if you really want the default value of #f,
it's probably best to include it in the code.  It conveys the intent more
clearly to the reader, and doesn't cost anything in performance, IMO.
  
I don't have a clear opinion about this. If you say it makes it more 
clear to understand, I won't contradict you.


Attached is the revised version. Okay to apply?
The next step would be to change all assoc calls to assoc-get calls. 
That would be no great deal. More difficult will be to decide to which 
of the two classes the assoc-get calls belong. Maybe a task for Mark 
Polesky?


Regards,
Michael


>From 8fa96593e20a00107785b024201d30875afa54cc Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= 
Date: Fri, 11 Sep 2009 19:16:45 +0200
Subject: [PATCH] Improve error checking in ly:assoc-get and ly:chain-assoc-get.

* Introduce a new optional argument strict_checking

* When strict_checking is set to true, output a programming_error
  if the given key is not found in the given alist / achain.

* This patch does not change the current behaviour. It prepares
  a greater modification to remove all assoc calls through
  secure assoc-get calls.
---
 lily/general-scheme.cc |   28 +++-
 1 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/lily/general-scheme.cc b/lily/general-scheme.cc
index 43ff745..7ef8c0c 100644
--- a/lily/general-scheme.cc
+++ b/lily/general-scheme.cc
@@ -154,10 +154,12 @@ LY_DEFINE (ly_dir_p, "ly:dir?",
 }
 
 LY_DEFINE (ly_assoc_get, "ly:assoc-get",
-	   2, 1, 0,
-	   (SCM key, SCM alist, SCM default_value),
-	   "Return value if @var{key} in @var{alist}, else @code{default-value}"
-	   " (or @code{#f} if not specified).")
+	   2, 2, 0,
+	   (SCM key, SCM alist, SCM default_value, SCM strict_checking),
+	   "Return value if @var{key} in @var{alist}, else @var{default_value}"
+	   " (or @code{#f} if not specified). If @var{strict_checking} is set"
+   " to @code{#t} and @var{key} is not in @var{alist}, a programming_error"
+   " is outputted.")
 {
   LY_ASSERT_TYPE(ly_cheap_is_list, alist, 2);
   
@@ -168,6 +170,9 @@ LY_DEFINE (ly_assoc_get, "ly:assoc-get",
   if (default_value == SCM_UNDEFINED)
 default_value = SCM_BOOL_F;
 
+  if (strict_checking == SCM_BOOL_T)
+programming_error ("Cannot find key ~S in alist, setting to ~S.", ly_scm2string (key), ly_scm2string (default_value));
+
   return default_value;
 }
 
@@ -312,10 +317,11 @@ LY_DEFINE (ly_effective_prefix, "ly:effective-prefix",
 }
 
 LY_DEFINE (ly_chain_assoc_get, "ly:chain-assoc-get",
-	   2, 1, 0, (SCM key, SCM achain, SCM val),
+	   2, 2, 0, (SCM key, SCM achain, SCM default_value, SCM strict_checking),
 	   "Return value for @var{key} from a list of alists @var{achain}."
-	   "  If no entry is found, return @var{val} or @code{#f} if"
-	   " @var{val} is not specified.")
+	   "  If no entry is found, return @var{default_value} or @code{#f} if"
+	   " @var{default_value} is not specified. With @var{strict_checking}"
+   " set to @code{#t}, a programming_error is outputted in such cases.")
 {
   if (scm_is_pair (achain))
 {
@@ -323,9 +329,13 @@ LY_DEFINE (ly_chain_assoc_get, "ly:chain-assoc-get",
   if (scm_is_pair (handle))
 	return scm_cdr (handle);
   else
-	return ly_chain_assoc_get (key, scm_cdr (achain), val);
+	return ly_chain_assoc_get (key, scm_cdr (achain), default_value);
 }
-  return val == SCM_UNDEFINED ? SCM_BOOL_F : val;
+  
+  if (strict_checking == SCM_BOOL_T)
+programming_error ("Cannot find key ~S in achain, setting to ~S.", ly_scm2string (key), ly_scm2string (default_value));
+  
+  return default_value == SCM_UNDEFINED ? SCM_BOOL_F : default_value;
 }
 
 
-- 
1.6.0.2

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

Re: [PATCH] Doc: copyright/licensing notice for contemporary music section.

[Graham Percival]

I'll examine this in a day or two; I'm still sorting out basic
issues about how to live on the other side of the Atlantic.

Cheers,
- Graham

On Fri, Sep 11, 2009 at 11:02:56AM +0200, Joseph Wakeling wrote:
> This one IS for inclusion in the main source tree, unless there is a
> problem with it. :-)
> 
> I'll be adding the same licensing notice to all files in the docs unless
> anyone objects.  (Debian-related comments particularly welcome.)
> 
> For COPYRIGHT notices I will take longer and try and identify concretely
> who contributed what on a file-by-file basis.
> 
> Best wishes,
> 
> -- Joe

> From ac8a3517383a3f5aea9ab9b6c0efb672b620800f Mon Sep 17 00:00:00 2001
> From: Joseph Wakeling 
> Date: Fri, 11 Sep 2009 10:58:26 +0200
> Subject: [PATCH] Doc: copyright/licensing notice for contemporary music 
> section.
> 
> ---
>  Documentation/notation/contemporary.itely |   17 +
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/notation/contemporary.itely 
> b/Documentation/notation/contemporary.itely
> index 34dda95..c92ea47 100644
> --- a/Documentation/notation/contemporary.itely
> +++ b/Documentation/notation/contemporary.itely
> @@ -1,5 +1,22 @@
>  @c -*- coding: utf-8; mode: texinfo; -*-
>  @ignore
> +Documentation/notation/contemporary.itely
> +
> +Copyright ?? 2009 Joseph Wakeling 
> +
> +This file is part of the documentation for GNU Lilypond.
> +
> +Permission is granted to copy, distribute and/or modify this document
> +under the terms of the GNU Free Documentation License, Version 1.1
> +or any later version published by the Free Software Foundation;
> +with no Invariant Sections, no Front-Cover Texts and no Back-Cover
> +Texts.
> +
> +You should have received a copy of the GNU Free Documentation License
> +along with this file.  If not, see .
> +...@end ignore
> +
> +...@ignore
>  Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
>  
>  When revising a translation, copy the HEAD committish of the
> -- 
> 1.6.3.3
> 

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



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

Re: Unsecure assoc calls

[Neil Puttock]

2009/9/11 Michael Käppler :

> Attached is the revised version. Okay to apply?

There are a few problems with this:

You need to amend the definition of the method in lily-guile.hh, since
it's also used directly in the C++ code, with no optional arguments:

53 SCM ly_assoc_get (SCM key, SCM alist, SCM def);

+programming_error ("Cannot find key ~S in alist, setting to ~S.",
ly_scm2string (key), ly_scm2string (default_value));

I think what Carl is getting at here is that you can't pass these
string values using format with programming_error () without adding
the macro `(_f', but this shouldn't be used in this case since it
internationalizes the message.

There's a bigger problem here though, since it's not clear what the
value of the key is going to be before converting it: ly_scm2string
will only work if the scheme value is a string.  This naturally
applies to default_value too, which could conceivably be any scheme
object.

Regards,
Neil


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

Re: [PATCH] New margin handling - final version (updated)

[Neil Puttock]

2009/9/11 Michael Käppler :
> Hi all,
> I've just removed some code from page.scm that becomes obsolete through the
> patch.

Just a few comments:

Can you rebase your changes in paper-defaults-init.ly so they don't
revert the changes made since your original patch?

The regression test would probably benefit from being split into
several separate tests, particularly the final check-consistency
setting, which can then have #(ly:set-option 'warning-as-error #f)
added to it in anticipation of the mythical time when we can switch
this option on for regression testing. :)

+  line_width = line_width - robust_scm2double (c_variable
("line-width-cropping"), 0);

line_width -= robust_scm2double (c_variable ("line-width-cropping"), 0);

> I would be really happy if somebody could test this for regressions. The
> problem is that for me it takes more than 12 hours to run a "make doc" and
> for this time I can't do anything other.
> (Just to give you an impression about my system's slowness)

Ouch.

I'm happy to run the tests again.  I'll report back once it's completed.

Regards,
Neil


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

Re: Overview of copyright issues + Debian

[Trevor Daniels]

Joseph Wakeling wrote Thursday, September 10, 2009 2:10 PM

What would be good is if as many contributors as possible can 
reply to
this email just to OK (i) my putting copyright/licensing notices 
in the
files they have contributed to and (ii) their licensing 
preferences for

their contributions:


I really can't get excited about this issue.

I'm happy to donate my LilyPond contributions, which are almost 
entirely

documentation and snippets, to the public domain.  That should give
you freedom to license them in the LilyPond distributions as you see 
fit.


Trevor





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

Re: Unsecure assoc calls

[Ian Hulin]

Hi Michael,

Just one nit-pick: in the error message "outputted" -> "output".

Cheers,

Ian


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

Re: [PATCH] New margin handling - final version (updated)

[Neil Puttock]

2009/9/11 Neil Puttock :

> I'm happy to run the tests again.  I'll report back once it's completed.

Hmm, not for the first time recently, the regression tests came back
completely unchanged, which should be impossible (nothing to do with
your patch, I think).

There are some subtle spacing changes in the docs, but no breakages:
quite often the line width is slightly shorter, resulting in tighter
spacing (see the PNG for expressive-headword.ly attached, which is
eleven pixels shorter than the current example on kainhofer.com).

Regards,
Neil
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Change of line-width in docs

[Trevor Daniels]

I've just noticed that the line-width, set in
the paper block in ly fragments in the docs,
has changed recently.  The latest development
release on lilypond.org has

\paper {
 #(define dump-extents #t)
 line-width = 160\mm - 2.0 * 0.4\in
 ragged-right = ##t
 indent = 0\mm
 force-assignment = #""
 line-width = #(- line-width (* mm  3.00))
}

but the kainhofer server has

\paper {
 #(define dump-extents #t)
 line-width = 5\in - 2.0 * 0.4\in
 ragged-right = ##t
 indent = 0\mm
 force-assignment = #""
 line-width = #(- line-width (* mm  3.00))
}

The change from 160\mm to 5\in shortens the line
by around 33\mm, which wrecks at least one
example - the Real music example in LM 4.5.3 -
by splitting it onto two lines.  Part of the
text no longer correctly describes the appearance 
of the music.


I could fix this by specifying line-width in the 
@lilypond call, but before I do I'd like to

understand the reason for the change.  Was the
reduction in line-width intentional?  I've
searched for this change in git, but can't find 
it.


Trevor




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

Re: [PATCH] Doc: copyright/licensing notice for contemporary music section.

[Joseph Wakeling]

Graham Percival wrote:
> I'll examine this in a day or two; I'm still sorting out basic
> issues about how to live on the other side of the Atlantic.

No rush whatsoever -- I will need time to work on this stuff.  Currently
going through Notation Reference source one file at a time and tracking
down the user commits.

Good luck with the other-side-of-Atlantic issues!

Best wishes,

-- Joe



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

Re: [PATCH] New margin handling - final version (updated)

[Michael Käppler]

Hi Neil,
I'm fine with all your comments...

The regression test would probably benefit from being split into
several separate tests, particularly the final check-consistency
setting, which can then have #(ly:set-option 'warning-as-error #f)
added to it in anticipation of the mythical time when we can switch
this option on for regression testing. :)
  
...however, I don't really understand the benefit of splitting the 
regtest. Do you propose to have separate files for each combination of 
settings?


And if warning-as-error was set to true, the regtest would fail. I don't 
think that is intended, since the >absence< of the warning would be 
wrong behaviour, not the appearance.


Regards,
Michael

btw. thanks for running the tests.


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

Re: [PATCH] New margin handling - final version (updated)

[Patrick McCarty]

On Fri, Sep 11, 2009 at 3:33 PM, Michael Käppler  wrote:
> Hi Neil,
> I'm fine with all your comments...
>>
>> The regression test would probably benefit from being split into
>> several separate tests, particularly the final check-consistency
>> setting, which can then have #(ly:set-option 'warning-as-error #f)
>> added to it in anticipation of the mythical time when we can switch
>> this option on for regression testing. :)
>
> ...however, I don't really understand the benefit of splitting the regtest.
> Do you propose to have separate files for each combination of settings?
>
> And if warning-as-error was set to true, the regtest would fail. I don't
> think that is intended, since the >absence< of the warning would be wrong
> behaviour, not the appearance.

If you *want* the warning(s) for regtests, add

  #(ly:set-option 'warning-as-error #f)

as Neil suggested.  Eventually, this option will be set to #t for
regtest compilation, thus the need for overriding the default
behavior.

Thanks,
Patrick


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

Re: shortcut for creating new Staff "subclass" context?

[Dan Eble]

On 2009-09-11, at 06:44 , Kieren MacMillan wrote:

Now my question is... does the order of the lines matter at all? I'm  
assuming they do — e.g., if you don't change the \name until after  
changing some \override, there'll be confusion — but does anyone  
know for certain what the precedence must be?


The settings in the \context {} block are saved as a group at the same  
time, so the following example modifies Staff rather than Voice.


Inside the \context {} block, the settings take effect in order, so  
the following example turns the staff lines red.


\version "2.12.2"

\layout {
  \context {
\Staff
\override StaffSymbol #'color = #blue
\name Voice
\override StaffSymbol #'color = #red
\name Staff
} }

\relative c' { c }

Whatever you do, don't do this:

\version "2.12.2"

\layout {
  \context {
\Staff
\name Voice
} }

\relative c' { c }

I'm not sure what it's doing, but it is taking a long time. :-)
--
Dan



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

Re: Change of line-width in docs

[Graham Percival]

On Fri, Sep 11, 2009 at 11:16:28PM +0100, Trevor Daniels wrote:
> The change from 160\mm to 5\in shortens the line
> by around 33\mm, which wrecks at least one
> example

I have a vague notion that somebody did something to paper
definitions and margins, but maybe I'm thinking of Michael's (sp)
work which (judging from the PATCH thread) hasn't been committed
yet.

No... I still think there was something else that *was* committed,
in June or July.


It was not deliberate to change the docs lnie-width.

Cheers,
- Graham


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

Re: [PATCH] New margin handling - final version (updated)

[Michael Käppler]

There are some subtle spacing changes in the docs, but no breakages:
quite often the line width is slightly shorter, resulting in tighter
spacing (see the PNG for expressive-headword.ly attached, which is
eleven pixels shorter than the current example on kainhofer.com).
  

Maybe this is the same issue Trevor reported one hour ago?

Regards,
Michael


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

Re: RFC: new vertical layout engine

[Francisco Vila]

2009/8/4 Joe Neeman :
> The interaction between the different xxx-spacing variables is a little
> complex and I need to document it properly. In this case, the problem is
> that Lyrics are unaffected by between-staff-spacing (because they are
> non-spaceable) and so your override only forces there to be one staff
> unit of padding between adjacent _staves_, which is satisfied by your
> example. Unfortunately, there is not yet any way to control the spacing
> between Lyrics and the staff below it, which is where you really want
> the extra padding AFAICT.

Joe: is this already documented? Hot to control spacing from a lyrics
line and the staff below it?  Simple lyrics seem to almost collide.

<< \new Staff { a } \addlyrics { pain }
\new Staff { f' }
>>

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


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

Re: [PATCH] New margin handling - final version (updated)

[Michael Käppler]

Hi,
please look again.

Regards,
Michael
>From 33c05dd7df4000d7f25d2903e2555d9ca86c2e1f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= 
Date: Sat, 12 Sep 2009 01:47:00 +0200
Subject: [PATCH] Introduce new handling for paper margin settings.

* Make default margins accessible in ly/paper-defaults-init.ly

* Introduce a new method: Output_def::normalize (). It checks,
  whether left-margin, right-margin and/or line-width are set.
  Afterwards it computes missing values or takes defaults, if
  necessary. There is no need to specify line-width manually now.

* Make right-margin work

* If only line-width is set, the current behaviour persists.
  (Systems are centered)

* Output a warning if the margin values don't fit with each other

* Modify lilypond-book to get rid of the
  (define line-width (- line-width 3\mm)) stuff and introduce
  line-width-cropping for compatibility.
---
 input/regression/paper-margins-consistency.ly |   34 +
 input/regression/paper-margins.ly |   39 +++
 lily/book.cc  |1 +
 lily/include/output-def.hh|3 +-
 lily/output-def.cc|   92 -
 lily/paper-book.cc|   11 +++-
 ly/paper-defaults-init.ly |8 ++-
 scm/page.scm  |6 +--
 scm/paper.scm |   18 ++---
 scripts/lilypond-book.py  |2 +-
 10 files changed, 193 insertions(+), 21 deletions(-)
 create mode 100644 input/regression/paper-margins-consistency.ly
 create mode 100644 input/regression/paper-margins.ly

diff --git a/input/regression/paper-margins-consistency.ly b/input/regression/paper-margins-consistency.ly
new file mode 100644
index 000..0a809c5
--- /dev/null
+++ b/input/regression/paper-margins-consistency.ly
@@ -0,0 +1,34 @@
+\version "2.13.4"
+
+#(ly:set-option 'warning-as-error #f)
+
+\header {
+  texidoc = "Paper settings are checked for consistency, which can be avoided by the user."
+}
+
+#(set-default-paper-size "a4")
+
+someNotes = \relative c' { \repeat unfold 40 { c4 d e f }}
+
+\book {
+  \bookpart {
+\paper {
+  left-margin = 20 \mm
+  right-margin = 40 \mm
+  line-width = 100 \mm
+}
+\markup { If you specify line-margin, right-margin and line-width, the values must be consistent. }
+\markup { In case they are not, default margins are set and a warning is printed. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  left-margin = 20 \mm
+  right-margin = 40 \mm
+  line-width = 200 \mm
+  check-consistency = ##f
+}
+\markup { You can avoid this check with settings check-consistency to false in the paper block. }
+\score { \someNotes }
+  }
+}
diff --git a/input/regression/paper-margins.ly b/input/regression/paper-margins.ly
new file mode 100644
index 000..a97fa88
--- /dev/null
+++ b/input/regression/paper-margins.ly
@@ -0,0 +1,39 @@
+\version "2.13.4"
+
+\header {
+  texidoc = "Paper margin settings don't have to be complete. Missing values are added automatically."
+}
+
+#(set-default-paper-size "a4")
+
+someNotes = \relative c' { \repeat unfold 40 { c4 d e f }}
+
+\book {
+  \bookpart {
+\paper { }
+\markup { If no paper settings are specified, default values are used. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  left-margin = 40 \mm
+}
+\markup { You may also specify only some margins. Missing values are added, if possible. }
+\markup { Here only left-margin is given, right-margin will remain default. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  right-margin = 40 \mm
+}
+\markup { Here only right-margin is given, left-margin will remain default. }
+\score { \someNotes }
+  }
+  \bookpart {
+\paper {
+  line-width = 100 \mm
+}
+\markup { If only line-width is given, the systems are vertically centered. }
+\score { \someNotes }
+  }
+}
diff --git a/lily/book.cc b/lily/book.cc
index 303af1b..86eeda1 100644
--- a/lily/book.cc
+++ b/lily/book.cc
@@ -277,6 +277,7 @@ Book::process (Output_def *default_paper,
 }
   else
 {
+  paper_book->paper_->normalize ();
   /* Process scores */
   /* Render in order of parsing.  */
   for (SCM s = scm_reverse (scores_); scm_is_pair (s); s = scm_cdr (s))
diff --git a/lily/include/output-def.hh b/lily/include/output-def.hh
index b683cc6..9e28d18 100644
--- a/lily/include/output-def.hh
+++ b/lily/include/output-def.hh
@@ -58,13 +58,14 @@ public:
   SCM c_variable (string id) const;
   SCM lookup_variable (SCM sym) const;
   void set_variable (SCM sym, SCM val);
+  void normalize ();
   Real get_dimension (SCM symbol) const;
 };
 SCM get_font_table (Output_def *def);
 void assign_context_def (Output_def *m, SCM transdef);
 SCM find_context_def (Output_def const *m, SCM name);
 
-Interval line_dime

Re: Unsecure assoc calls

[Michael Käppler]

You need to amend the definition of the method in lily-guile.hh, since
it's also used directly in the C++ code, with no optional arguments:

53 SCM ly_assoc_get (SCM key, SCM alist, SCM def);
  
Hmm... I don't exactly understand the LY_DEFINE macro. Is it possible to 
implement this
with overloading or have all C++ calls of ly_assoc_get to be changed to 
use all four parameters?

+programming_error ("Cannot find key ~S in alist, setting to ~S.",
ly_scm2string (key), ly_scm2string (default_value));

I think what Carl is getting at here is that you can't pass these
string values using format with programming_error () without adding
the macro `(_f', but this shouldn't be used in this case since it
internationalizes the message.
  
programming_error (to_string ("Cannot find key %s in achain, setting to 
%s.",
   ly_scm2string (key), ly_scm2string 
(default_value)));


Is this basically the right way to do this?


There's a bigger problem here though, since it's not clear what the
value of the key is going to be before converting it: ly_scm2string
will only work if the scheme value is a string.  This naturally
applies to default_value too, which could conceivably be any scheme
object.
  
What about adding a type check to ly_scm2string and add the possibility 
to convert from symbols and numbers too?
Isn't there a guile built-in method for converting any scheme object in 
a readable string?


Regards,
Michael



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

Re: Unsecure assoc calls

[Carl Sorensen]

On 9/11/09 6:27 PM, "Michael Käppler"  wrote:

> 
> 
>> You need to amend the definition of the method in lily-guile.hh, since
>> it's also used directly in the C++ code, with no optional arguments:
>> 
>> 53 SCM ly_assoc_get (SCM key, SCM alist, SCM def);

Can't you just use 

  SCM ly_assoc_get (SCM key, SCM alist, SCM def,
 SCM strict_check = SCM_BOOL_F);

in lily-guile.hh?

And with this definition, all the 3-parameter calls to ly_assoc_get will
assume that strict_check is false?


>>  
> Hmm... I don't exactly understand the LY_DEFINE macro. Is it possible to
> implement this
> with overloading or have all C++ calls of ly_assoc_get to be changed to
> use all four parameters?
>> +programming_error ("Cannot find key ~S in alist, setting to ~S.",
>> ly_scm2string (key), ly_scm2string (default_value));
>> 
>> I think what Carl is getting at here is that you can't pass these
>> string values using format with programming_error () without adding
>> the macro `(_f', but this shouldn't be used in this case since it
>> internationalizes the message.

Actually, that wasn't what I was getting at, but you got the right answer
from Neil, anyway.

>>  
> programming_error (to_string ("Cannot find key %s in achain, setting to
> %s.",
> ly_scm2string (key), ly_scm2string
> (default_value)));
> 
> Is this basically the right way to do this?
> 
>> There's a bigger problem here though, since it's not clear what the
>> value of the key is going to be before converting it: ly_scm2string
>> will only work if the scheme value is a string.  This naturally
>> applies to default_value too, which could conceivably be any scheme
>> object.
>>  
> What about adding a type check to ly_scm2string and add the possibility
> to convert from symbols and numbers too?
> Isn't there a guile built-in method for converting any scheme object in
> a readable string?

Yes, there is.  It's object->string.  See
http://www.gnu.org/software/guile/manual/html_node/General-Conversion.html#G
eneral-Conversion

HTH,

Carl



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

Re: mugshots for web page? [WAS: The LilyPond Report, again!]

[Graham Percival]

On Mon, Sep 07, 2009 at 07:45:54PM +0200, Jan Nieuwenhuizen wrote:
> Op maandag 07-09-2009 om 14:43 uur [tijdzone +0100], schreef Graham
> Percival:
> > On Mon, Sep 07, 2009 at 11:50:44AM +0200, Jan Nieuwenhuizen wrote:
> 
> > However, I don't particularly want my photo on the lilypond
> > website.  This opens the possibility of having photos of some
> > developers but not others, which might seem a big ragged or
> > unbalanced.
> 
> Why not?

I have quibbles about privacy on the internet.  I've recently
accepted having certain photos of me available (such as on my
website)... 5 years ago I would have refused outright.  I think I
could find something to put there.

However, I absolutely don't want to pressure other developers to
put their photos online.  Even if we don't explicitly ask people
to do so, if there's only one developer without a photo, that
creates some implied "peer pressure".

OTOH, I guess we're all adults here; if somebody really doesn't
want their photo online, they probably have enough strength of
will to resist that implied pressure.  Especially if we found
another photo... for example, if I really refused, we could use
some image of a cello in place of a photo.


Developers: if anybody is uncomfortable with having their photo
online, and would also feel uncomfortable about sticking out by
having some animal picture or musical picture or wahtever instead
of an actual photo, I'm more than willing to dig in my heels about
this idea.  Send me a private email if you'd like.

> Or what about stealing a creative idea from
> 
>http://www.fotosearch.com/photos-images/anonymous.html
> 
> such as the profile.

Not bad.  At first, I thought the picture would be
http://upload.wikimedia.org/wikipedia/en/d/da/AnonymousDemotivator.jpg
which, although insanely cool, would be a trifle at odds with
our professional new website.  :)

Cheers,
- Graham


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

Re: Switching to Waf instead of SCons?

[Graham Percival]

On Thu, Sep 10, 2009 at 11:10:13PM +0200, John Mandereau wrote:
> Le mardi 08 septembre 2009 à 19:53 +0100, Graham Percival a écrit :
> > I absolutely do not want to have a half-completed switch to waf 
> > for documentation.
> [snip]
> > But I don't want to end up fumbling around in waf
> > because no active developers are familiar with it.
> 
> Is this complaint an attempt at discouraging us from switching to
> another build system?

It's a recognition that I royally screwed up over the summer in
attempting too many big things at once.  The new website, the doc
rearrangment, and learning GUB.  As a result, I failed to complete
*any* of them during the summer.

I now have a core2 quad with 4 gigs at my desk.  Unfortunately the
building is locked over the weekend, but on Monday I can seriously
tackle GUB.  We should get regular releases soon -- but the
translation infrastructure is still broken for the website.

>  Our current build system for the documentation
> sucks so much that even a half-finished set of Waf tools and wscripts
> will provide better building conditions.

Yes, but OTOH how much work is involved in making the current
build system function?

- some files need to be added to EXTRA_DIST (or whatever the
  equivalent is).  I can do this.
- the translations need to use WEB_TEXI2HTML_INIT and
  WEB_TEXI2HTML_SPLIT for general.  I've now spent an hour trying
  to do this to no avail... I've added "texinfo" to the
STEPMAKE_TEMPLATES, I've added 

$(outdir)/general/index.html: TEXI2HTML_INIT = $(WEB_TEXI2HTML_INIT)
$(outdir)/general/index.html: TEXI2HTML_SPLIT = $(WEB_TEXI2HTML_SPLIT)

and I've spent a lot of time trying to see any other difference
between Documentation/GNUmakefile and Documentation/fr/GNUmakefile.


I don't care about doc-clean, but I *would* like to have a
sensible set of created docs, and I *would* like to allow the
translators to start working on the new website as soon as the
content is finished.  If this could be done by the two of us
spending another 5 hours each on the old build system, I think
it's worth it.

Cheers,
- Graham


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

Re: Switching to Waf instead of SCons?

[Graham Percival]

On Fri, Sep 11, 2009 at 05:21:39PM +0200, John Mandereau wrote:
> Hi Carl,
> Le jeudi 10 septembre 2009 à 16:25 -0600, Carl Sorensen a écrit :
> > I'd be willing to give a hand if I can.  I read your wiki page, but didn't
> > get anything from it in terms of how I could help.  Give me a ping if you
> > get to the point that you can carve out some kind of task for me to try.
> 
> At this early stage, I've just found that Waf doesn't provide any
> built-in generic function to check a program version, so I'm writing a
> function to provide this feature, and I have started writing a Waf tool
> for Texinfo.

Hmm.  Could you / have you contacted the waf developers about
making the version-checking function part of their main distro?
That seems like a fairly fundamental feature for a configuring
system, so I'd like to make sure they agree that your solution is
good.  Otherwise we might have problems down the road if they add
a different version checking function.

Cheers,
- Graham


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

Re: Switching to Waf instead of SCons?

[Carl Sorensen]

On 9/11/09 9:21 AM, "John Mandereau"  wrote:

> Hi Carl,
> Le jeudi 10 septembre 2009 à 16:25 -0600, Carl Sorensen a écrit :
>> I'd be willing to give a hand if I can.  I read your wiki page, but didn't
>> get anything from it in terms of how I could help.  Give me a ping if you
>> get to the point that you can carve out some kind of task for me to try.
> 
> At this early stage, I've just found that Waf doesn't provide any
> built-in generic function to check a program version, so I'm writing a
> function to provide this feature, and I have started writing a Waf tool
> for Texinfo.  The two tasks you could look at to begin are
> 
> - add attached wscript to top of the source directory, replace
> hard-coded VERSION by some code that parses the VERSION file (Python std
> lib has a module for parsing configuration files), and commit this
> wscript to dev/waf branch;

In working on this, I found that the built-in ConfigureParser of Python
won't work with the VERSION file, because it requires sections (i.e. text
headers enclosed in []), and the VERSION has no sections.

I found a BSD-licensed python module, configobj.py, that provides the
ability to parse a config file without sections, like VERSION.

I've successfully written the script so that it works on my setup, but where
should I put configobj.py so that it will be available?  And should I even
try to go this way, or should I write my own parsing code?

Writing my own code seems like a waste of time, but if the license is going
to cause problems, I guess I could do so.

Carl



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