Re: error while running make check (g++ 4.7.0): missing include of unistd.h

[Frédéric Bron]

> I wanted to run regression tests and compare before and after a change.
> However, I obtained the error given below after make -j8 CPU_COUNT=8 check
>
> I suspect this is because I am compiling with gcc/g++ 4.7.0 (coming
> with Fedora 17) and its release notes say:
> "Avoid polluting the global namespace and do not include ."
> we should then include
>#include 
>#include 
> before using getpid and getcwd.

Who can review my patch?
http://codereview.appspot.com/6434048

Frédéric

> In file included from
> /home/fred/lilypond/flower/include/yaffut-parameters.hh:4:0,
>  from /home/fred/lilypond/flower/test-file-name.cc:3:
> /home/fred/lilypond/flower/include/yaffut.hh: In member function 'int
> yaffut::Factory::Main(int, const char**)':
> /home/fred/lilypond/flower/include/yaffut.hh:211:39: warning:
> conversion to 'int' from 'size_t {aka long unsigned int}' may alter
> its value [-Wconversion]
> In file included from /home/fred/lilypond/flower/test-string.cc:8:0:
> /home/fred/lilypond/flower/include/yaffut.hh: In member function 'int
> yaffut::Factory::Main(int, const char**)':
> /home/fred/lilypond/flower/include/yaffut.hh:211:39: warning:
> conversion to 'int' from 'size_t {aka long unsigned int}' may alter
> its value [-Wconversion]
> In file included from /home/fred/lilypond/flower/test-std.cc:13:0:
> /home/fred/lilypond/flower/include/yaffut.hh: In member function 'int
> yaffut::Factory::Main(int, const char**)':
> /home/fred/lilypond/flower/include/yaffut.hh:211:39: warning:
> conversion to 'int' from 'size_t {aka long unsigned int}' may alter
> its value [-Wconversion]
> /home/fred/lilypond/flower/include/yaffut.hh: In function 'int
> main(int, const char**)':
> /home/fred/lilypond/flower/include/yaffut.hh:401:34: error: 'getpid'
> was not declared in this scope
> In file included from /home/fred/lilypond/flower/test-file-path.cc:5:0:
> /home/fred/lilypond/flower/include/yaffut.hh: In member function 'int
> yaffut::Factory::Main(int, const char**)':
> /home/fred/lilypond/flower/include/yaffut.hh:211:39: warning:
> conversion to 'int' from 'size_t {aka long unsigned int}' may alter
> its value [-Wconversion]
> /home/fred/lilypond/flower/test-file-path.cc: In constructor
> '{anonymous}::Find::Find()':
> /home/fred/lilypond/flower/test-file-path.cc:13:29: error: 'getcwd'
> was not declared in this scope
> make[1]: *** [out/test-file-path.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: *** [out/test-std.o] Error 1

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

PATCH: Countdown to 20120731

[Colin Campbell]

For 20:00 MDT Tuesday July 31 (It can't be the end of July already: I 
haven't had time for June!)


Defect:
Issue 1650 
: using 
multiple \header in a block prints only the latest items - R 6445053 

Issue 1661 
: MIDI dynamics 
take effect one note too late - R 6428075 



Documentation:
Issue 673 : 
problem with order of \consists - R 6448063 

Issue 2640 
: doc 
enhancement for \headers - R 6456047 



Enhancement:
Issue 1320 
: Enhancement: 
user-customizable barlines through a Scheme interface - R 6305115 

Issue 2700 
: Patch: Change 
$ to # in docs where appropriate - R 6441066 



Cheers,
Colin


--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[David Kastrup]

David Kastrup  writes:

> Except that \-o can be a MARKUPCOMMAND but not a DASHED_KEY_WORD which
> can't start with a dash as first character after the backslash.  A
> DASHED_KEY_WORD can contain digits, but this is mostly useless since you
> can't use them except in INITIAL mode.
>
>>> One consequence is that if you can use \commandname in some
>>> context, it can
>>> be defined using
>>> commandname = ...
>>> without requiring quote marks since word syntax and command name
>>> syntax are
>>> in direct correspondence.
>>
>> I don't see this as a huge benefit.  What's wrong with
>>   commandname = { ... }
>> ?
>
> The difference is to the left of the equals sign.  You can write
> command-name = ...
> instead of
> "command-name" = ...
>
> Embarrassingly, you could actually always do this already,

I take that back because LilyPond is not in INITIAL mode initially, but
in notes mode with an empty list of note names.  It is in INITIAL mode
basically inside of context modifications, context and output
definitions.

> zip3 = 5\cm
>
> You could assign to variables with numbers in their name.  This feature
> has seen little use since you can't reference them in music short of
> using $.

Aaand you can only assign to them inside of context definitions, context
mods and output definitions.  So the above needs to be there, not at top
of file.

-- 
David Kastrup


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

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[David Kastrup]

David Kastrup  writes:

> Graham Percival  writes:
>
>> On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
>
>>> Being able to access every definition equally  
>>> well in every lexer mode is also an advantage.  The word definition is  
>>> palindromic: iff a character sequence is a word, so is its reverse.
>>
>> If this means what I think it means, then huh?  so I can do this
>> now?
>>   music = { c'4 d e f }
>>   { \cisum }
>> and have it compile?
>
> No.  If \music is a command to the lexer, then \cisum is a command to
> the lexer.  That does not mean that they have the same

or any

> definition.  Just the same kind of lexical unit.

That's not actually in any sense important.  Some languages are less
symmetric: a0 may be a word in those languages while 0a isn't.

-- 
David Kastrup


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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

David Kastrup  writes:

> "Phil Holmes"  writes:
>
>> - Original Message - 
>> From: 
>> To: ; 
>> Cc: ; 
>> Sent: Sunday, July 29, 2012 9:16 PM
>> Subject: Re: Set indent based on instrument name (issue 6457049)
>>
>>
>>> On 2012/07/29 18:20:16, PhilEHolmes wrote:
 My first attempt at coding in LilyPond.  Treat me gently...
>>>
>>> I think we should be able to do better than just counting characters in
>>> a string.  It should be possible calculating physical string width,
>>> shouldn't it?
>>>
>>> http://codereview.appspot.com/6457049/
>>
>> Absolutely.  Count this as phase 1.  FWIW, this very simple approach
>> works surprisingly well.
>>
>> How would I calculate the string size?
>
> Is there a proctologist in this room?
>
> I mean, someone with experience doctoring the backend?  That's not
> really my specialty.

Just remembered a few things: you would likely use interpret-markup to
turn your markup (this does not need to be a string, though that's the
simplest case) into a stencil, and then use
(ly:stencil-extent sten X) to get the X extent of the stencil (likely an
interval).  There are probably C++ interfaces for that as well.

-- 
David Kastrup


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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: 
> To: ; 
> Cc: ; 
> Sent: Sunday, July 29, 2012 9:16 PM
> Subject: Re: Set indent based on instrument name (issue 6457049)
>
>
>> On 2012/07/29 18:20:16, PhilEHolmes wrote:
>>> My first attempt at coding in LilyPond.  Treat me gently...
>>
>> I think we should be able to do better than just counting characters in
>> a string.  It should be possible calculating physical string width,
>> shouldn't it?
>>
>> http://codereview.appspot.com/6457049/
>
> Absolutely.  Count this as phase 1.  FWIW, this very simple approach
> works surprisingly well.
>
> How would I calculate the string size?

Is there a proctologist in this room?

I mean, someone with experience doctoring the backend?  That's not
really my specialty.

-- 
David Kastrup


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

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[David Kastrup]

Graham Percival  writes:

> On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
>> 
>> Forwarding this from the lilypond-auto list since this review concerns
>> an important syntax change.  GLISS material, in a manner.  Consider it a
>> proposal for word and command syntax across _all_ lexer modes.
>
> What's a "lexer mode" ?  I haven't gotten around to taking
> Coursea's compilers course.

The lexer turns character sequences into tokens.  LilyPond's lexer has
different internal modes in which it generates different tokens from the
same character sequences.  Tokens are the principal units in LilyPond's
grammar (the uppercase expressions in the "Grammar" appendix in the
Notation manual).

Usually, a lexer has only one mode or state in which it forms tokens.
LilyPond has the following modes:

INITIAL, extratoken, chords, figures, incl, lyrics, lyric_quote,
longcomment, markup, notes, quote, sourcefileline, sourcefilename,
version

Most of those are in some manner trivial or limited (producing zero or
one token), but
INITIAL, chords, figures, lyrics,  markup, notes
are fullblown modes triggered by the parser (rather than the lexer
itself) and producing a string of tokens using its respective own rules.

Commands and words are mode-dependent recognized in three different manners:

A   [a-zA-Z\200-\377]
AA  {A}|_
N   [0-9]
AN  {AA}|{N}
DASHED_WORD {A}({AN}|-)*
DASHED_KEY_WORD \\{DASHED_WORD}
ALPHAWORD   {A}+
NOTECOMMAND \\{A}+
MARKUPCOMMAND   \\({A}|[-_])+

In INITIAL mode, DASHED_WORD and DASHED_KEY_WORD recognize words and
keywords.  INITIAL mode is the only mode in which assignments are
allowed, so DASHED_WORD is the only permissible word syntax for
_defining_ a command via assignment (which has the form "string =
scalar" with string being represented by a quoted string or by a word).
NOTECOMMAND and MARKUPCOMMAND are specialized forms of DASHED_KEY_WORD.
Except that \-o can be a MARKUPCOMMAND but not a DASHED_KEY_WORD which
can't start with a dash as first character after the backslash.  A
DASHED_KEY_WORD can contain digits, but this is mostly useless since you
can't use them except in INITIAL mode.

>> One consequence is that if you can use \commandname in some context, it can  
>> be defined using
>> commandname = ...
>> without requiring quote marks since word syntax and command name syntax are  
>> in direct correspondence.
>
> I don't see this as a huge benefit.  What's wrong with
>   commandname = { ... }
> ?

The difference is to the left of the equals sign.  You can write
command-name = ...
instead of
"command-name" = ...

Embarrassingly, you could actually always do this already, but there are
snippets that don't know this.  Probably my fault to start this trend.
More importantly, you can reference \command-name in any mode, including
notes mode which is the default in #{ ... #}.

>> Being able to access every definition equally  
>> well in every lexer mode is also an advantage.  The word definition is  
>> palindromic: iff a character sequence is a word, so is its reverse.
>
> If this means what I think it means, then huh?  so I can do this
> now?
>   music = { c'4 d e f }
>   { \cisum }
> and have it compile?

No.  If \music is a command to the lexer, then \cisum is a command to
the lexer.  That does not mean that they have the same definition.  Just
the same kind of lexical unit.

>> If -  or _ is both preceded as well as followed by an alphabetic
>> character, it  integrates into a word.
>
> That sounds nice, although my time with programming languages
> kind-of discourages the notion of
>   violin-one
> instead of
>   violin_one
> .  However, if it's totally safe to write "violin-one" then that
> would certainly be nice for normal musicians!  It also saves one
> keypress.

It is not "totally safe".  Previously { c-flat } was a well-formed
LilyPond program.  Afterwards, it would not be.

>>  It turns out that this definition works with  
>> both "make test" as well as "make doc" without requiring any change in the  
>> LilyPond code base.
>
> That's certainly promising.
>
>> Discuss.  This is quite a consequential change regarding what word syntax  
>> is valid and what not, but the previous state was rather arbitrary to the  
>> degree of being wonky.
>
> Could I have some examples?  I just don't get this "word"
> business.  Is there any syntax which was previously
> (theoretically) supported, which this patch breaks?

zip3 = 5\cm

You could assign to variables with numbers in their name.  This feature
has seen little use since you can't reference them in music short of
using $.

{ c-flat }

A "word" is allowed as a string in music, and a string can be used as a
markup in most circumstances (when it does not happen to match a
notename).  I am not aware of anybody having used this, but if anybody
does a lot of experimentation and/or Flex code reading, it is
conceivable that code using this exists.  I mean, a

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: 

To: ; 
Cc: ; 
Sent: Sunday, July 29, 2012 9:16 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



On 2012/07/29 18:20:16, PhilEHolmes wrote:

My first attempt at coding in LilyPond.  Treat me gently...


I think we should be able to do better than just counting characters in
a string.  It should be possible calculating physical string width,
shouldn't it?

http://codereview.appspot.com/6457049/


Absolutely.  Count this as phase 1.  FWIW, this very simple approach works 
surprisingly well.


How would I calculate the string size?

--
Phil Holmes 



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

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[Graham Percival]

On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
> 
> Forwarding this from the lilypond-auto list since this review concerns
> an important syntax change.  GLISS material, in a manner.  Consider it a
> proposal for word and command syntax across _all_ lexer modes.

What's a "lexer mode" ?  I haven't gotten around to taking
Coursea's compilers course.

> One consequence is that if you can use \commandname in some context, it can  
> be defined using
> commandname = ...
> without requiring quote marks since word syntax and command name syntax are  
> in direct correspondence.

I don't see this as a huge benefit.  What's wrong with
  commandname = { ... }
?

> Being able to access every definition equally  
> well in every lexer mode is also an advantage.  The word definition is  
> palindromic: iff a character sequence is a word, so is its reverse.

If this means what I think it means, then huh?  so I can do this
now?
  music = { c'4 d e f }
  { \cisum }
and have it compile?  or maybe I don't understand what a "word" is
in this context?  presumably it's not 8 bytes.

> If -  or _ is both preceded as well as followed by an alphabetic
> character, it  integrates into a word.

That sounds nice, although my time with programming languages
kind-of discourages the notion of
  violin-one
instead of
  violin_one
.  However, if it's totally safe to write "violin-one" then that
would certainly be nice for normal musicians!  It also saves one
keypress.

>  It turns out that this definition works with  
> both "make test" as well as "make doc" without requiring any change in the  
> LilyPond code base.

That's certainly promising.

> Discuss.  This is quite a consequential change regarding what word syntax  
> is valid and what not, but the previous state was rather arbitrary to the  
> degree of being wonky.

Could I have some examples?  I just don't get this "word"
business.  Is there any syntax which was previously
(theoretically) supported, which this patch breaks?

- Graham

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

Re: Set indent based on instrument name (issue 6457049)

[dak]

On 2012/07/29 18:20:16, PhilEHolmes wrote:

My first attempt at coding in LilyPond.  Treat me gently...


I think we should be able to do better than just counting characters in
a string.  It should be possible calculating physical string width,
shouldn't it?

http://codereview.appspot.com/6457049/

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

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[David Kastrup]

Forwarding this from the lilypond-auto list since this review concerns
an important syntax change.  GLISS material, in a manner.  Consider it a
proposal for word and command syntax across _all_ lexer modes.
Reasonably simple, and somewhat surprisingly not requiring any changes
in the entire .ly codebase of LilyPond.  It will likely affect existing
scores.  Hopefully not many.

Comment #3 on issue 2702 by me:
Patch: Unify the lexer's idea of words and commands across all modes.
http://code.google.com/p/lilypond/issues/detail?id=2702

One consequence is that if you can use \commandname in some context, it can  
be defined using
commandname = ...
without requiring quote marks since word syntax and command name syntax are  
in direct correspondence.  Being able to access every definition equally  
well in every lexer mode is also an advantage.  The word definition is  
palindromic: iff a character sequence is a word, so is its reverse.  If -  
or _ is both preceded as well as followed by an alphabetic character, it  
integrates into a word.  It turns out that this definition works with  
both "make test" as well as "make doc" without requiring any change in the  
LilyPond code base.

That makes it somewhat likely that its adverse effects on typical LilyPond  
sources will be limited.  The previous mode-dependent rules for words and  
identifiers were not well-understood and completely undocumented, so people  
were not likely to drive them to their limits.

Discuss.  This is quite a consequential change regarding what word syntax  
is valid and what not, but the previous state was rather arbitrary to the  
degree of being wonky.

-- 
David Kastrup

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

Set indent based on instrument name (issue 6457049)

[PhilEHolmes]

Reviewers: dak, Graham Percival,

Message:
My first attempt at coding in LilyPond.  Treat me gently...

Description:
An attempt to set the line indent based upon the instrument name.  The
simple use of instrumentName.length() to add to the indent seems odd,
but works in practice.  Not tested with different fonts, and can be
improved a lot with more font heuristics, but it's a _lot_ better than
before.  Please review my approach and coding.

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

Affected files:
  M lily/include/output-def.hh
  M lily/instrument-name-engraver.cc
  M lily/output-def.cc


Index: lily/include/output-def.hh
diff --git a/lily/include/output-def.hh b/lily/include/output-def.hh
index  
3f44061513064044bf173a496e43c332ac8f8bcc..5613bdb36a426550a3b9ba0e764261c98caa4998  
100644

--- a/lily/include/output-def.hh
+++ b/lily/include/output-def.hh
@@ -76,7 +76,7 @@ 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);
-
+void set_inst_name_len (int, int);

 Font_metric *select_encoded_font (Output_def *layout, SCM chain);
 Font_metric *select_font (Output_def *layout, SCM chain);
Index: lily/instrument-name-engraver.cc
diff --git a/lily/instrument-name-engraver.cc  
b/lily/instrument-name-engraver.cc
index  
0abc7e432955bf8306b9f7f6704b02f9e4bdd766..b752c177bfcca484c7093465816aac4e2f0f  
100644

--- a/lily/instrument-name-engraver.cc
+++ b/lily/instrument-name-engraver.cc
@@ -20,6 +20,7 @@
 #include "align-interface.hh"
 #include "axis-group-interface.hh"
 #include "engraver.hh"
+#include "output-def.hh"
 #include "page-layout-problem.hh"
 #include "pointer-group-interface.hh"
 #include "side-position-interface.hh"
@@ -112,6 +113,10 @@ Instrument_name_engraver::start_spanner ()
   text_spanner_->set_property ("text", short_text_);
   text_spanner_->set_property ("long-text", long_text_);

+  string short_inst = ly_scm2string (short_text_);
+  string long_inst = ly_scm2string (long_text_);
+  set_inst_name_len (long_inst.length(), short_inst.length());
+
   /*
 UGH, should handle this in Score_engraver.
   */
Index: lily/output-def.cc
diff --git a/lily/output-def.cc b/lily/output-def.cc
index  
e425dbf4f93cd2dba5fc03172017a02f04ff63b4..2a7ef91e28be1c3b3118374d5ee21722569a496e  
100644

--- a/lily/output-def.cc
+++ b/lily/output-def.cc
@@ -35,6 +35,9 @@

 #include "string-convert.hh"

+int long_name_len = 0;
+int short_name_len = 0;
+
 Output_def::Output_def ()
 {
   scope_ = SCM_EOL;
@@ -254,10 +257,23 @@ Interval
 line_dimensions_int (Output_def *def, int n)
 {
   Real lw = def->get_dimension (ly_symbol2scm ("line-width"));
-  Real ind = n
-? def->get_dimension (ly_symbol2scm ("short-indent"))
-: def->get_dimension (ly_symbol2scm ("indent"));
+  Real ind = 0.0;
+  if (n == 0)
+  {
+ind = def->get_dimension (ly_symbol2scm ("indent"));
+ind += long_name_len;
+  }
+  else
+  {
+ind = def->get_dimension (ly_symbol2scm ("short-indent"));
+ind += short_name_len;
+  }
   return Interval (ind, lw);
 }

-
+void
+set_inst_name_len (int long_inst_name_len, int short_inst_name_len)
+{
+long_name_len = max (long_inst_name_len, long_name_len);
+short_name_len = max (short_inst_name_len, short_name_len);
+}



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

Re: Syntax change: REAL requires at least one digit before decimal point (issue 6446048)

[k-ohara5a5a]

This looks nice.
Cleaner code, and continues to accept -.3\cm, for now.

http://codereview.appspot.com/6446048/

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

Re: GOP2-3 - GLISS or not

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
>  wrote:
>> This summer hasn't been going as I'd hoped -- heh, who am I
>> kidding, this whole year hasn't been going as I'd hoped.  Anyway,
>> we seem to have radically different concepts of what "input
>> stabilization" might mean, or even if it's a good idea worth
>> doing.
>>
>> Hopefully we can settle those questions now.
>> http://lilypond.org/~graham/gop/gop_4.html
>>
>>
>> ** Summary
>>
>> Let’s decide whether to try to stabilize the syntax or not. What
>> type of project do we want LilyPond to be? What kinds of
>> guarantees (or at least firm intentions) do we want to give to
>> users with respect to lilypond 2 or 5 years from now being able to
>> read their current ly files?
>
>
> I think Lily is way past the point for us to decide that the language
> needs to be changed in any major way: syntax is not what stops people
> from using lilypond, and changing it in notable ways will only drive
> people away from Lily.

Yes and no.

I have just created
http://code.google.com/p/lilypond/issues/detail?id=2702>
Patch: Unify the lexer's idea of words and commands across all modes.

This a a change of LilyPond's syntax in a major way.  For example, the
previously working program

{ c-flat }

now no longer works.  Similarly

\paper { dim2 = 5\cm  dim3 = 2\dim2 }

stops working.


Will this cause an outcry?  Hardly.  You'll rather get "Wait, you mean
this worked?"  It is unlikely that there is a significant body of code
around that would have relied on this to work because while it "worked"
previously, it did so undocumentedly, under circumstances that are not
documented and are not even explainable in terms meaningful to a user.

This is a large and invasive syntax change, and it does not even affect
the regtests.

LilyPond has a "de facto" syntax that is more or less being used and
documented.  We won't be tying it down anytime soon.  But it is also
clear that some changes are an improvement.  With the above change in
place, I can write

\paper { paper-width = #(+ #{ 3\cm #} #{ \paper-width #} )}

and it works.  Even though #{...#} sets up \notemode nominally.

There is good reason to make such a change.  But of course there is also
"old code might have relied on this behavior".

And I agree with Graham that at some point of time we _should_ try to
settle just _what_ behavior people may rely on safely.

> As a corollorary, it is OK for a syntax change to invalidate previous
> .ly files, if it generates a warning at the problematic location.

You _can't_ reliably generate a warning for every undocumented detail
that may change its interpretation in future.

How would you even _start_ generating warning for a lexer change like
the one I pointed out?

Lexer changes are almost impossible to do with a proper deprecation
phase.  Parser changes are hard, but sometimes possible.  Music function
changes are often feasible.

The deeper the change is, the harder it is to do a deprecation phase
because in a deprecation phase, something needs to be interpreted in two
manners, and the whole point of the phase is presumably to arrive at a
completely different interpretation.

> Rather than "defining" some stable subset (and then getting into a lot
> of discussion on what that subset should look like), I think we should
> just take the overall decision on intent, that is: what are we trying
> to do? My suggestion is:
>
> * big changes: not OK
> * small changes, especially when they clean up things (I'm thinking of
> the 4. vs 4.0 change David is working on): in principle OK, but the
> upgrade path should either be automatic or cause failure on
> compilation.

Well, take the above lexer change.  It is a big change, but it is
unlikely many people will encounter its effects because they likely have
shied away from completely undocumented behavior only working in corner
cases.

I want fewer corner cases, and more documented behavior.  Fewer corner
cases means incompatibilities, but how many people actually have been
sitting in the unlighted corners anyway?

-- 
David Kastrup


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

Re: Email from Phil's patchy

[Marc Hohl]

Am 29.07.2012 11:16, schrieb David Kastrup:

Marc Hohl  writes:


Am 29.07.2012 10:10, schrieb David Kastrup:


Now it is true that we probably did not have a formal discussion of
this in any rate, and you are probably quite keeping with some sort
of de-facto standard and are in the unlucky position of standing next
when I am waking up to some problem wildly thrashing my arms.

Sorry for that.

No problem. I was a bit disappointed that this patch being into
staging has to be reworked, but I assumed that "make doc"
is covered within the "make test-redo; make check" cycle,
and I was proven wrong.

"make doc" is really expensive.

Yup.

   And the staging branch is our ultimate
safety net (more often than not, patches gone through testing and review
need rebasing before getting pushed, and we don't start a new
test-patchy for that), intended to catch unexpected kinds of problem.

Which this, in a way, was.


Meanwhile, "make doc" succeded. I had to insert a
check for glyph = #f in bar-line::compound-barline, too,
which was not covered before.

Well, it was more or less coincidence that made that problem turn up
(which should really have been discussed and resolved in review in a
perfect world), but if we are handed on a platter the chance to improve
a previous choice including an example of why that would be a good idea,
it would be a shame to waste it.

At least I learned from this incident that doing a "make doc"
after the tests are clean is not the worst option either.

Regards,

Marc


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

Re: Patchy email

[David Kastrup]

Marc Hohl  writes:

> Am 28.07.2012 14:08, schrieb David Kastrup:
>> [...]
>>
>> One thing that occured to me is that this contains a whole lot of public
>> functions without any DOC string.  No idea whether this might cause a
>> problem for the documentation run, but it certainly is not much of a
>> help for humans understanding the code.
> Good point. Since the current state is an intermediate one
> (well, kind of), I'll cover the doc strings in part 2 if that'll be ok.

I think there were no documentation strings before, and I don't think
that they would be extracted into user-readable documentations anyway,
which is a step backwards when the C implementation has them.

We'll need to think about that at some point of time in general.

I would still strongly suggest that the documentation strings are
maintained when stuff gets ported to Scheme: we'll likely make use of
them at some point of time, and they still help when actually reading
the code.

Now if I remember correctly, you diligently maintained every existing
documentation string (namely, none).  So we are not worse off than
before, and there is no point postponing matters on this front.

-- 
David Kastrup

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

Re: Email from Phil's patchy

[David Kastrup]

Marc Hohl  writes:

> Am 29.07.2012 10:10, schrieb David Kastrup:
>
>> Now it is true that we probably did not have a formal discussion of
>> this in any rate, and you are probably quite keeping with some sort
>> of de-facto standard and are in the unlucky position of standing next
>> when I am waking up to some problem wildly thrashing my arms.
>>
>> Sorry for that.
> No problem. I was a bit disappointed that this patch being into
> staging has to be reworked, but I assumed that "make doc"
> is covered within the "make test-redo; make check" cycle,
> and I was proven wrong.

"make doc" is really expensive.  And the staging branch is our ultimate
safety net (more often than not, patches gone through testing and review
need rebasing before getting pushed, and we don't start a new
test-patchy for that), intended to catch unexpected kinds of problem.

Which this, in a way, was.

> Meanwhile, "make doc" succeded. I had to insert a
> check for glyph = #f in bar-line::compound-barline, too,
> which was not covered before.

Well, it was more or less coincidence that made that problem turn up
(which should really have been discussed and resolved in review in a
perfect world), but if we are handed on a platter the chance to improve
a previous choice including an example of why that would be a good idea,
it would be a shame to waste it.

-- 
David Kastrup

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

Re: Patchy email

[Marc Hohl]

Am 28.07.2012 14:08, schrieb David Kastrup:

[...]

One thing that occured to me is that this contains a whole lot of public
functions without any DOC string.  No idea whether this might cause a
problem for the documentation run, but it certainly is not much of a
help for humans understanding the code.

Good point. Since the current state is an intermediate one
(well, kind of), I'll cover the doc strings in part 2 if that'll be ok.

Marc


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

Re: LilyPond developer&user meeting in Waltrop, August 24th to 28th

[David Kastrup]

Rodolfo Zitellini  writes:

> Hi All!
> is the meeting open to all users?

Yes.  We need to keep track of the head count and have to cater for
accommodation/food accordingly, but that does not seem like much of a
problem right now.

> I would be very interested in coming, as I would love to learn a bit
> more of the program's internals and how to interact with scheme. I can
> also help a bit for the releases (my c++ is a bit rusty, but well...)

At the current point of time, making releases would not appear to
require more than patience and problem solving skills in the area of
scripting.  And a lot of horse power.

> and I have no fear of the build system (well, mostly, but I had to
> compile stuff much more involved than Lilypond) Another thing I would
> like to talk about is using Lilypond in a professional print
> environment. In my University we are starting a new series of printed
> music books ("Musik aus Schweizer Klöstern") and Lily will be the tool
> for engraving all the music (well, "will be" at 90%, you never know
> what can happen in environments like this, but we are already making
> the layout of the next three books in Lily) - so discussions on long
> term archival of the music sources, how to setup a workflow with other
> people and like are all interesting to me.

I think that brainstorming around where we want LilyPond to go and how
to take along the work that has already been done on and with it is
certainly something worth doing.

-- 
David Kastrup

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

Re: Email from Phil's patchy

[Marc Hohl]

Am 29.07.2012 10:10, schrieb David Kastrup:

Marc Hohl  writes:


Am 29.07.2012 08:12, schrieb David Kastrup:

"Phil Holmes"  writes:


Sorry, Marc.  To do this completely, you will need to add the changed
file to snippets/new.  The files in snippets get over-written when we
import from the LSR, so this update would be lost.  However, to make
current git compile, you do also need to keep this change in snippets.

I realise this isn't completely straightforward, but that's the way
it is...

I repeat: why change all the function names of functions with a public
interface in the first place when they have the same functionality?
Without a convert-ly rule, this will break user code.  I cited some user
quote on the mailing list that will also break.


I misunderstood the ly: convention in function names.

It is used inconsistently.  It is _required_ (or possibly was at some
point of time, I don't quite remember) for LY_DEFINE.

At a point of time where pretty much everything concerning LilyPond
internal operation was done in C++, it may have had some correlation
with functionality and/or mangling.

But there is really very little sense in us having predicates ly:music?
as opposed to markup? since the user could care less what language some
functionality is, or has been, implemented in, possibly at some point in
history.

Personally, I would think that pretty much everything that looks like a
Scheme interface to a C++ callback (namely containing :: in its name)
should likely have the ly: prefix to preserve some predictability, but
it would appear that this train left station a long time ago.

We also have the situation that we autoextract documentation from
functions defined using LY_DEFINE into the manual (probably the main
incentive to have LY_DEFINE) The same is not done for functions defined
in Scheme as far as I can tell.

But the functions we are talking about were defined with some *CALLBACK*
macro, I think, and not documented anyway.

So it is an inconsistent historical mess we are dealing with here.  It
would be nice to provide some guarantees, like "everything starting with
ly: has a documentation in the internals manual", but those guarantees
should not be tied into the implementation language: that is a line
irrelevant to the user.

Somewhat more relevant would be "don't expect to change this in
mid-session or at all since other callers might have memoized the
location or called it directly".  However, LilyPond code memoizes a lot,
never mind the ly: prefix.


I renamed the concerned definitions and am currently doing make and
make doc.
The changes in Documentation/snippets were reverted.

If make doc succeeds, I'll upload another patch.

To me, I think for drop-in exported-function-by-function replacements,
that is the sanest way to proceed since for the caller, nothing has
changed.

+1


But at one point of time, we need to put down some explicit policies
here as well and come up with good guidelines users and developers can
depend on.  And "implementation language" is a terrible criterion for a
user-visible distinction in interfaces.

+1


In C, the equivalent would be to have to write
extern "FORTRAN"
not just in the respective headers of a library, but also for _every_
_single_ function call.  Now function call prefixes in naming are not
unusual, but they are ordered according to library, not according to
implementation language.  And I don't need yet_another_prefix if the
function has been rewritten in assembly language.

Now it is true that we probably did not have a formal discussion of this
in any rate, and you are probably quite keeping with some sort of
de-facto standard and are in the unlucky position of standing next when
I am waking up to some problem wildly thrashing my arms.

Sorry for that.

No problem. I was a bit disappointed that this patch being into
staging has to be reworked, but I assumed that "make doc"
is covered within the "make test-redo; make check" cycle,
and I was proven wrong.


We'll likely need something better than a raving core programmer as a
guideline.

;-)

  In the meantime, I consider it a good idea for drop-in
replacements of public interfaces to keep the name, or the drop-in idea
is no longer valid, meaning that it gets much harder to do comparisons
of before/after when necessary, and we get a user-visible
incompatibility that serves no discernible purpose.


Meanwhile, "make doc" succeded. I had to insert a
check for glyph = #f in bar-line::compound-barline, too,
which was not covered before.

Regards,

Marc

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

Re: Email from Phil's patchy

[David Kastrup]

Marc Hohl  writes:

> Am 29.07.2012 08:12, schrieb David Kastrup:
>> "Phil Holmes"  writes:
>>
>>> Sorry, Marc.  To do this completely, you will need to add the changed
>>> file to snippets/new.  The files in snippets get over-written when we
>>> import from the LSR, so this update would be lost.  However, to make
>>> current git compile, you do also need to keep this change in snippets.
>>>
>>> I realise this isn't completely straightforward, but that's the way
>>> it is...
>> I repeat: why change all the function names of functions with a public
>> interface in the first place when they have the same functionality?
>> Without a convert-ly rule, this will break user code.  I cited some user
>> quote on the mailing list that will also break.
>>
> I misunderstood the ly: convention in function names.

It is used inconsistently.  It is _required_ (or possibly was at some
point of time, I don't quite remember) for LY_DEFINE.

At a point of time where pretty much everything concerning LilyPond
internal operation was done in C++, it may have had some correlation
with functionality and/or mangling.

But there is really very little sense in us having predicates ly:music?
as opposed to markup? since the user could care less what language some
functionality is, or has been, implemented in, possibly at some point in
history.

Personally, I would think that pretty much everything that looks like a
Scheme interface to a C++ callback (namely containing :: in its name)
should likely have the ly: prefix to preserve some predictability, but
it would appear that this train left station a long time ago.

We also have the situation that we autoextract documentation from
functions defined using LY_DEFINE into the manual (probably the main
incentive to have LY_DEFINE) The same is not done for functions defined
in Scheme as far as I can tell.

But the functions we are talking about were defined with some *CALLBACK*
macro, I think, and not documented anyway.

So it is an inconsistent historical mess we are dealing with here.  It
would be nice to provide some guarantees, like "everything starting with
ly: has a documentation in the internals manual", but those guarantees
should not be tied into the implementation language: that is a line
irrelevant to the user.

Somewhat more relevant would be "don't expect to change this in
mid-session or at all since other callers might have memoized the
location or called it directly".  However, LilyPond code memoizes a lot,
never mind the ly: prefix.

> I renamed the concerned definitions and am currently doing make and
> make doc.
> The changes in Documentation/snippets were reverted.
>
> If make doc succeeds, I'll upload another patch.

To me, I think for drop-in exported-function-by-function replacements,
that is the sanest way to proceed since for the caller, nothing has
changed.

But at one point of time, we need to put down some explicit policies
here as well and come up with good guidelines users and developers can
depend on.  And "implementation language" is a terrible criterion for a
user-visible distinction in interfaces.

In C, the equivalent would be to have to write
extern "FORTRAN"
not just in the respective headers of a library, but also for _every_
_single_ function call.  Now function call prefixes in naming are not
unusual, but they are ordered according to library, not according to
implementation language.  And I don't need yet_another_prefix if the
function has been rewritten in assembly language.

Now it is true that we probably did not have a formal discussion of this
in any rate, and you are probably quite keeping with some sort of
de-facto standard and are in the unlucky position of standing next when
I am waking up to some problem wildly thrashing my arms.

Sorry for that.

We'll likely need something better than a raving core programmer as a
guideline.  In the meantime, I consider it a good idea for drop-in
replacements of public interfaces to keep the name, or the drop-in idea
is no longer valid, meaning that it gets much harder to do comparisons
of before/after when necessary, and we get a user-visible
incompatibility that serves no discernible purpose.

-- 
David Kastrup

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

Re: Email from Phil's patchy

[Marc Hohl]

Am 29.07.2012 08:12, schrieb David Kastrup:

"Phil Holmes"  writes:


Sorry, Marc.  To do this completely, you will need to add the changed
file to snippets/new.  The files in snippets get over-written when we
import from the LSR, so this update would be lost.  However, to make
current git compile, you do also need to keep this change in snippets.

I realise this isn't completely straightforward, but that's the way it is...

I repeat: why change all the function names of functions with a public
interface in the first place when they have the same functionality?
Without a convert-ly rule, this will break user code.  I cited some user
quote on the mailing list that will also break.


I misunderstood the ly: convention in function names.
I renamed the concerned definitions and am currently doing make and make 
doc.

The changes in Documentation/snippets were reverted.

If make doc succeeds, I'll upload another patch.

Marc

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