Re: Feature request

[David Kastrup]

Werner LEMBERG  writes:

>>> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
>>> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
>> 
>> or maybe:
>>   \beaming {
>> { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
>> { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
>>   }
>> 
>> It's probably easier to keep track of what's happening (in terms
>> of programming) if there's a single command call; otherwise it
>> wouldn't be clear if both beamings were supposed to apply, or
>> whether the second one should clear the first one.
>
> Since the second entry doesn't clear the first one (because the number
> of beats in entries is different) I'm against this additional,
> artificial grouping.

At the current point of time, we are bikeshedding.  Please note that the
implementation of this feature does not depend on "naked" rhythms, it
should work just the same as

\beaming { c8 [ c c c ] c [ c c c c c ] }

so if people care about the details, they can significantly increase the
impact of their opinion by writing the implementation.

-- 
David Kastrup

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

Re: Feature request

[Werner LEMBERG]

>> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
>> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
> 
> or maybe:
>   \beaming {
> { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
> { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
>   }
> 
> It's probably easier to keep track of what's happening (in terms
> of programming) if there's a single command call; otherwise it
> wouldn't be clear if both beamings were supposed to apply, or
> whether the second one should clear the first one.

Since the second entry doesn't clear the first one (because the number
of beats in entries is different) I'm against this additional,
artificial grouping.


Werner

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

PATCH: Countdown to 20121002

[Colin Campbell]

For 20:00 MDT (unless Mrs Patch Nanny has me recording choir parts, 
which could go later!) Tuesday October 2nd


Documentation:
Issue 2722 
: NR 2.4.1 
Default tablatures harmonics notes in Staff are one octave lower - R 
6588049 
Issue 2844 
: Patch: Doc: 
Improve documentation of \glissando. - R6567059 



Enhancement:
Issue 2859 
: Patch: 
Provide \hide and \no functions for transparent and void glyphs - R 
6575048 
Issue 2868 
: Patch: 
Various clean-ups in stems and beams. - R 6584045 

Issue 2869 
: Patch: 
Regularize lyrics lexer mode - R 6594047 



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: Feature request

[Graham Percival]

On Mon, Sep 24, 2012 at 12:37:32PM +0100, Phil Holmes wrote:
> Not necessarily.  An alternative would be:
> 
> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
> \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }

or maybe:
  \beaming {
{ 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
{ 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
  }

It's probably easier to keep track of what's happening (in terms
of programming) if there's a single command call; otherwise it
wouldn't be clear if both beamings were supposed to apply, or
whether the second one should clear the first one.

- Graham

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Thomas Morley]

2012/9/30  :
> On 2012/09/30 19:44:49, marc wrote:
>>
>> Am 30.09.2012 11:02, schrieb d...@gnu.org:
>> > [...]
>> > First, the define-public is asking for trouble. You are exposing an
>> > internal Scheme data structure to users and make it overwritable by
>
> the
>>
>> > user. If the user follows this invitation, the effects will bleed
>
> over
>>
>> > from session to session. Never do that.
>> Ok.
>
>
> No, it's not ok.  Hold your horses, this is another case too stupid for
> documenting and walking people through.  Give me two days, and then you
> replace your define-public for the alists with define-session, and
> that's it.  The rest of the code stays as it is.
>
> I'll make define-session do everything that is needed.
>

That would be very nice.
I can think of several functions/definitions currently destructively
changing internal Scheme data structures.
Perhaps they would work as expected then.


-Harm

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

Re: Issue 2869: Regularize lyrics lexer mode (issue 6594047)

[janek . lilypond]

I don't feel competent to speak about the code (and if i started asking
questions, it would take ages to answer them all), but the idea of the
change definitely LGTM.

http://codereview.appspot.com/6594047/

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

Re: Adds tick mark to scripts (issue 6568055)

[Janek Warchoł]

On Sun, Sep 30, 2012 at 4:32 PM, James  wrote:
> On 30 September 2012 13:27, Janek Warchoł  wrote:
>> On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes  wrote:
>>> Well, in the current version of the NR, the guidance for changing the breath
>>> sign is:
>>> \override BreathingSign #'text = \markup {\musicglyph
>>> #"scripts.caesura.straight"}
>>
>> Hmm.  I wouldn't do it this way,
>
> How would you do it?

Like i described in my previous email - with a dedicated command:

straightBreathe = {
  \override BreathingSign #'text = \markup {\musicglyph
#"scripts.caesura.straight"}
  \breathe
}

or have just the override inside the variable, like a style setting:

straightBreathe = {
  \override BreathingSign #'text = \markup {\musicglyph
#"scripts.caesura.straight"}
}

This way, if we ever change the name of the glyph or something like
that, we would just redefine this command and everything will /just
work/ - without convert-ly at all.

cheers,
Janek

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[dak]

On 2012/09/30 19:44:49, marc wrote:

Am 30.09.2012 11:02, schrieb d...@gnu.org:
> [...]
> First, the define-public is asking for trouble. You are exposing an
> internal Scheme data structure to users and make it overwritable by

the

> user. If the user follows this invitation, the effects will bleed

over

> from session to session. Never do that.
Ok.


No, it's not ok.  Hold your horses, this is another case too stupid for
documenting and walking people through.  Give me two days, and then you
replace your define-public for the alists with define-session, and
that's it.  The rest of the code stays as it is.

I'll make define-session do everything that is needed.

Just that it is possible to learn all the internals of LilyPond session
does not mean that it makes sense that you are required to do so just in
order to accomplish a simple task.

http://codereview.appspot.com/6498052/

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 30.09.2012 11:02, schrieb d...@gnu.org:

[...]
First, the define-public is asking for trouble. You are exposing an
internal Scheme data structure to users and make it overwritable by the
user. If the user follows this invitation, the effects will bleed over
from session to session. Never do that.

Ok.


Consider _everything_ written in a .scm file as readonly conceptually.
For an alist, you might want to define a _function_ returning the
initial list, and the accessors should not be modifying it destructively
(adding to the front of an alist does not change the original alist).

Then you assign this initial value to a session variable in something
included in init.ly, like
#(define bar-glyph-alist (initial-bar-glyph-alist))

Ok.


Your functions working with bar-glyph-alist have to take the version of
bar-glyph-alist defined in the parser module. That means that when you
call them from .ly files, you'll likely need to pass bar-glyph-alist
from the .ly file into your Scheme function. Or get them via
ly:parser-lookup via the parser variable.

I am not sure whether I understand this completely, but I'll give
it a try.


If you put a new bar line definition into a.ly, and when calling
lilypond a.ly b.ly
it is available in b.ly, then you have done something wrong.

I did this and can confirm that a bar line defined in a.ly *is*
available in b.ly.

So I have to replace all three public alists in bar-line.scm the way you
described it above.

[OT: it seems that I have a strong attraction to problems that look
not very difficult at first glance and turn out to involve *a lot of*
changes and obstacles until they get solved.
On the other hand, this is a *perfect* way to learn about the internals
of lilypond – in such situations where everything breaks, I remember
Jan working on GUB during Waltrop and his statement when the
compilation broke again: "That's nice." I admire such a serenity and
try to adopt it in situations where I am about to throw the computer
out of the window ;-) I am not in this state yet, but I am working on it...]

Regards,

Marc


http://codereview.appspot.com/6498052/




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

verify regression tests

[Marc Hohl]

Hello list,

I got strange results with the regression tests, and studying the
CG more carefully, I spotted some differences:

http://lilypond.org/doc/v2.17/Documentation/contributor/regtest-comparison

says that you should do

make test-baseline && make check

[changed the code; if needed 'make']

make test-redo && make check (the latter is rather implicitly hidden in 
the text)


After all looks good, do a

make test-clean && make check

to restore the system to a clean state.

http://lilypond.org/doc/v2.17/Documentation/contributor/verify-regression-tests

is more overviewish, but it lacks the final

make check

which is needed after make test-clean, IIUC.

I can cook up a patch for that, but I want to make sure that the changes are
correct.

Regards,

Marc

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

Re: Patch-testing-problem

[James]

Hello,

On 30 September 2012 16:06, Thomas Morley  wrote:
...

>>> Please see 
>>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>>
>>> make[2]: *** [out-test/collated-files.texi] Error 1
>>> make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>>> make[1]: *** [local-test] Error 2
>>> make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>>> make: *** [test] Error 2
>>> 
>>>
>>> Looking at:
>>>  
>>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>>
>>> The file contains nothing else than:
>>> GNU LilyPond 2.17.4
>>>
>>>
>>> Obviously I did sth wrong and again I've no clue what and how to proceed.
>>
>> Why do you think you did something wrong?
>
> Well, I'm still a newbie with this kind of tasks.
> If sth crashes my first thought is, damn, what did _I_ wrong.
>
>> That was exactly what I got when I tested the patch originally.
>>
>> You need to find the problem of why it failed to compile.
>>
>> See
>>
>> http://code.google.com/p/lilypond/issues/detail?id=2790#c33
>>
>> Did you get the same problem?
>
> I couldn't comprehend your own work.

The problem is that not all errors are the same - I am no expert but
after testing patches for the last year or so, you get a feel for this
I guess. Phil's work (et al) has helped simplify the log, but if you
see

http://code.google.com/p/lilypond/issues/detail?id=2790#c16

for instance, this was a differnet kind of failure and was easy to
spot simply because the log file references did point to a .ly file.

This instance here is different and so it was trickier to follow the
chain, in fact I couldn't. Phil's suggestion of looking at the latest
file generated is a good one, but I simply use basic grep commands

grep -r -C 10 "Error"

for instance, in the top level of the build dir.

I get a ton of hits, but the -C makes it easy to see if the return is
just a comment of the string 'Error' or a function call, rather than a
log file.

The trick here is to know the error message being generated in the log
file, "fatal" is one, or you can just do "Processing files" and the -C
gives you a few lines above and below so you can see a completed file
or an error.

> But after typing 'make check' the first two lines the terminal returns are:

>
> For tracking crashes: use
>
> grep sourcefilename `grep -L systems.texi
> out/lybook-testdb/*/*log|sed s/log/ly/g`

I can't comment on that but it seems awfully complicated.

>
> Trying to enter this (in the build-directory) returns:
> \sourcefilename
> "/home/harm/lilypond-git/input/regression/instrument-name-volta.ly"
>
> This is exactly the file Marc mentioned here:
> http://codereview.appspot.com/6498052/#msg13

OK but that ly file will also occur in a snippet*.log file. So you can
cross reference I guess but that would need another grep search.

I guess I am just used to looking at lines and lines of output to use
a simpler grep command, but not all crashes/compilation failures are
the same and don't generate the same error messages even if the
initial crash message looks the same.

At least from my experience.

However the offending log file *will* contain the error message (as if
you had run lilypond-book on the individual snippet)

Hence my comment

--snip--
lily-7dccbf09.log:programming error: number of pages is out of bounds
lily-7dccbf09.log:programming error: tried to space systems on a bad
number of pages
lily-7dccbf09.log:programming error: number of pages is out of bounds
lily-7dccbf09.log:programming error: tried to space systems on a bad
number of pages
--snip--

The file 'lily-7dccbf09.log' contained the error message (from the
grep command) and also in that log was the name of the snippet.

James

James

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

Re: Patch-testing-problem

[Thomas Morley]

2012/9/30 James :
> Thomas,
>
> On 30 September 2012 15:16, Thomas Morley  
> wrote:
>> 2012/9/29 Keith OHara :
>>> Thomas Morley  googlemail.com> writes:
>>>
 I wanted to test Marc's bar-line-patch somewhat closer, but I have a
 problem, not knowing what to do.

  git apply --index 0001-bar-line.patch

 error: patch failed:
 Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4
 error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:
 patch does not apply
>>>
>>> "patch does not apply" means that the code you have as a starting point is
>>> significantly different from the starting point of the patch.
>>>
>>> Phil ran an LSR update recently, which changes Documentation/snippets/*
>>> Marc's patch also changes many of those same files.  Phil's  LSR update was
>>> in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the
>>> state just before,
>>>git checkout 5c42908f^
>>> and then apply Marc's patch.
>>>
>>> Marc will probably rebase his patch pretty soon and repost it so that the
>>> diff applies to the codebase after the LSR update.
>>>
>>>
>>> ___
>>> lilypond-devel mailing list
>>> lilypond-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>> Hi Keith,
>>
>> thanks for your advice.
>> After
>>   git checkout 5c42908f^
>> I ran `make' and `make test-baseline' and was able to apply Marc's
>> patch successfully. :)
>> After doing that I ran a new `make'.
>>
>> And a new error arises after trying to do `make check'
>>
>> Terminal returns:
>>
>>  
>> [ ... ]
>> Child returned 1
>> Error ignored by lilylib
>> Error trapped by lilypond-book
>>
>> Please see 
>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>
>> make[2]: *** [out-test/collated-files.texi] Error 1
>> make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>> make[1]: *** [local-test] Error 2
>> make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>> make: *** [test] Error 2
>> 
>>
>> Looking at:
>>  /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>
>> The file contains nothing else than:
>> GNU LilyPond 2.17.4
>>
>>
>> Obviously I did sth wrong and again I've no clue what and how to proceed.
>
> Why do you think you did something wrong?

Well, I'm still a newbie with this kind of tasks.
If sth crashes my first thought is, damn, what did _I_ wrong.

> That was exactly what I got when I tested the patch originally.
>
> You need to find the problem of why it failed to compile.
>
> See
>
> http://code.google.com/p/lilypond/issues/detail?id=2790#c33
>
> Did you get the same problem?

I couldn't comprehend your own work.
But after typing 'make check' the first two lines the terminal returns are:

For tracking crashes: use

grep sourcefilename `grep -L systems.texi
out/lybook-testdb/*/*log|sed s/log/ly/g`

Trying to enter this (in the build-directory) returns:
\sourcefilename
"/home/harm/lilypond-git/input/regression/instrument-name-volta.ly"

This is exactly the file Marc mentioned here:
http://codereview.appspot.com/6498052/#msg13

>>
>> Do you have another hint?
>>
>> Sorry, to ask again and again stupid questions, but on my own, I can
>> see only two alternatives:
>> Deleting all /Documantation/snippets from the patch and then apply it
>> to current master or to stop any reviewing work as far as
>> /Documentation/snippets are concerned in any way.
>
> I don't really understand this, I assume you mean just to troubleshoot
> yourself on your own local git.

Yes! Take the other statements more as an expression of my frustration
not beeing able to solve the occuring problems on my own.


Regards,
  Harm

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

Re: Adds tick mark to scripts (issue 6568055)

[James]

Hello,

On 30 September 2012 13:27, Janek Warchoł  wrote:
> On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes  wrote:
>> Well, in the current version of the NR, the guidance for changing the breath
>> sign is:
>> \override BreathingSign #'text = \markup {\musicglyph
>> #"scripts.caesura.straight"}
>
> Hmm.  I wouldn't do it this way,

How would you do it?

James

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

Re: Patch-testing-problem

[James]

Thomas,

On 30 September 2012 15:16, Thomas Morley  wrote:
> 2012/9/29 Keith OHara :
>> Thomas Morley  googlemail.com> writes:
>>
>>> I wanted to test Marc's bar-line-patch somewhat closer, but I have a
>>> problem, not knowing what to do.
>>>
>>>  git apply --index 0001-bar-line.patch
>>>
>>> error: patch failed:
>>> Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4
>>> error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:
>>> patch does not apply
>>
>> "patch does not apply" means that the code you have as a starting point is
>> significantly different from the starting point of the patch.
>>
>> Phil ran an LSR update recently, which changes Documentation/snippets/*
>> Marc's patch also changes many of those same files.  Phil's  LSR update was
>> in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the
>> state just before,
>>git checkout 5c42908f^
>> and then apply Marc's patch.
>>
>> Marc will probably rebase his patch pretty soon and repost it so that the
>> diff applies to the codebase after the LSR update.
>>
>>
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
> Hi Keith,
>
> thanks for your advice.
> After
>   git checkout 5c42908f^
> I ran `make' and `make test-baseline' and was able to apply Marc's
> patch successfully. :)
> After doing that I ran a new `make'.
>
> And a new error arises after trying to do `make check'
>
> Terminal returns:
>
>  
> [ ... ]
> Child returned 1
> Error ignored by lilylib
> Error trapped by lilypond-book
>
> Please see 
> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>
> make[2]: *** [out-test/collated-files.texi] Error 1
> make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
> make[1]: *** [local-test] Error 2
> make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
> make: *** [test] Error 2
> 
>
> Looking at:
>  /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>
> The file contains nothing else than:
> GNU LilyPond 2.17.4
>
>
> Obviously I did sth wrong and again I've no clue what and how to proceed.

Why do you think you did something wrong?

That was exactly what I got when I tested the patch originally.

You need to find the problem of why it failed to compile.

See

http://code.google.com/p/lilypond/issues/detail?id=2790#c33

Did you get the same problem?


>
> Do you have another hint?
>
> Sorry, to ask again and again stupid questions, but on my own, I can
> see only two alternatives:
> Deleting all /Documantation/snippets from the patch and then apply it
> to current master or to stop any reviewing work as far as
> /Documentation/snippets are concerned in any way.

I don't really understand this, I assume you mean just to troubleshoot
yourself on your own local git.

James

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

Re: Patch-testing-problem

[Thomas Morley]

2012/9/29 Keith OHara :
> Thomas Morley  googlemail.com> writes:
>
>> I wanted to test Marc's bar-line-patch somewhat closer, but I have a
>> problem, not knowing what to do.
>>
>>  git apply --index 0001-bar-line.patch
>>
>> error: patch failed:
>> Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4
>> error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:
>> patch does not apply
>
> "patch does not apply" means that the code you have as a starting point is
> significantly different from the starting point of the patch.
>
> Phil ran an LSR update recently, which changes Documentation/snippets/*
> Marc's patch also changes many of those same files.  Phil's  LSR update was
> in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the
> state just before,
>git checkout 5c42908f^
> and then apply Marc's patch.
>
> Marc will probably rebase his patch pretty soon and repost it so that the
> diff applies to the codebase after the LSR update.
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Hi Keith,

thanks for your advice.
After
  git checkout 5c42908f^
I ran `make' and `make test-baseline' and was able to apply Marc's
patch successfully. :)
After doing that I ran a new `make'.

And a new error arises after trying to do `make check'

Terminal returns:

 
[ ... ]
Child returned 1
Error ignored by lilylib
Error trapped by lilypond-book

Please see 
/home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log

make[2]: *** [out-test/collated-files.texi] Error 1
make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
make[1]: *** [local-test] Error 2
make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
make: *** [test] Error 2


Looking at:
 /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log

The file contains nothing else than:
GNU LilyPond 2.17.4


Obviously I did sth wrong and again I've no clue what and how to proceed.

Do you have another hint?

Sorry, to ask again and again stupid questions, but on my own, I can
see only two alternatives:
Deleting all /Documantation/snippets from the patch and then apply it
to current master or to stop any reviewing work as far as
/Documentation/snippets are concerned in any way.


-Harm

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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

"m...@mikesolomon.org"  writes:

> It is true that line-breaking is a centralized option based on what
> the toplevel-book-handler is, but it should be as lightweight as
> possible.  I think that the smaller we can keep paper-book.cc and
> paper-score.cc, the better.  I've been saying this for a couple years,
> but I'd prefer for Book and PaperScore to be grobs so that even they
> could use the callback model.  At that point, line breaking could just
> be controlled by callbacks.

Distributing algorithms in that manner without central
control/arbitration means O(n^2) complexity at least.  It tends to lend
itself better to parallelizing, but when your average system does not
have thousands of processors, that advantage remains very limited.

Of course, a half-baked not-well-understood global hackery touching
stuff in lots of indiscriminate places is not what this is about.  The
interdependencies need to be stated as local relations, of course.  It
is just that the resolution is to be done globally.  Of course this
necessitates that the dependencies are formulated in a _systematic_
manner and in the same way everywhere, using well-crafted
interfaces/ways of specification rather than in willy-nilly adhoc
jumbles of callbacks.

-- 
David Kastrup


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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 30 sept. 2012, at 14:29, David Kastrup  wrote:

> "m...@mikesolomon.org"  writes:
> 
>> On 30 sept. 2012, at 14:16, Janek Warchoł  wrote:
>> 
>>> Hi,
>>> 
>>> interesting discussion, i learn a lot.
>>> 
>>> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup  wrote:
 Basically, a grob says "I want to have this and that information for
 making my positioning" and LilyPond says "You can't get it right now".
 Then the grob says "ok, I'll do a tentative positioning", and LilyPond
 will come back with more information later and ask again.
>> 
>> Just to clarify things for anyone following the thread: this is not
>> currently how LilyPond works, but I'm assuming what you're proposing
>> is a suggestion for a model.
>> 
>> It's an interesting idea for grobs to ping a sort of central hive
>> ("LilyPond" in your text above) to know what information they can
>> access and when.  This'd require a major change to the architecture -
>> currently, grobs specify in their request whether they want tentative
>> or permanent information via the use of functions like
>> Grob::pure_relative_y_coordinate versus Grob::relative_coordinate.
>> I'm worried about having a sort of centralized brain that tells grobs
>> what they can and can't know - sounds Kafka-esque.  I like the
>> decentralized model where grobs, via their callbacks, self-police for
>> what information they need from other grobs and when it's ok to get
>> it.
> 
> I have my doubts that you can do a sensible circular dependency
> resolution strategy in a purely local manner.  In fact, the current
> pure/unpure distinction is based on before/after linebreaking, a
> centralized operation.
> 

It is true that line-breaking is a centralized option based on what the 
toplevel-book-handler is, but it should be as lightweight as possible.  I think 
that the smaller we can keep paper-book.cc and paper-score.cc, the better.  
I've been saying this for a couple years, but I'd prefer for Book and 
PaperScore to be grobs so that even they could use the callback model.  At that 
point, line breaking could just be controlled by callbacks.  This would also 
pave the way for better Prob / Grob integration - it is currently difficult to 
get toplevel markups and systems to play nicely because they are outside of 
this callback model.

The current pure/unpure distinction is based on what people ask for and when.  
Pure offsets and extents are used until the dim_cache_ is filled, at which 
point real offsets and extents are used.  As a convention this is before and 
after line breaking, but there are places where pure properties are requested 
after linebreaking and non-pure properties are requested before.

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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

"m...@mikesolomon.org"  writes:

> On 30 sept. 2012, at 14:16, Janek Warchoł  wrote:
>
>> Hi,
>> 
>> interesting discussion, i learn a lot.
>> 
>> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup  wrote:
>>> Basically, a grob says "I want to have this and that information for
>>> making my positioning" and LilyPond says "You can't get it right now".
>>> Then the grob says "ok, I'll do a tentative positioning", and LilyPond
>>> will come back with more information later and ask again.
>
> Just to clarify things for anyone following the thread: this is not
> currently how LilyPond works, but I'm assuming what you're proposing
> is a suggestion for a model.
>
> It's an interesting idea for grobs to ping a sort of central hive
> ("LilyPond" in your text above) to know what information they can
> access and when.  This'd require a major change to the architecture -
> currently, grobs specify in their request whether they want tentative
> or permanent information via the use of functions like
> Grob::pure_relative_y_coordinate versus Grob::relative_coordinate.
> I'm worried about having a sort of centralized brain that tells grobs
> what they can and can't know - sounds Kafka-esque.  I like the
> decentralized model where grobs, via their callbacks, self-police for
> what information they need from other grobs and when it's ok to get
> it.

I have my doubts that you can do a sensible circular dependency
resolution strategy in a purely local manner.  In fact, the current
pure/unpure distinction is based on before/after linebreaking, a
centralized operation.

-- 
David Kastrup

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

Re: Adds tick mark to scripts (issue 6568055)

[Janek Warchoł]

On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes  wrote:
> Well, in the current version of the NR, the guidance for changing the breath
> sign is:
> \override BreathingSign #'text = \markup {\musicglyph
> #"scripts.caesura.straight"}

Hmm.  I wouldn't do it this way, it feels not Lilypondish to me (e.g.
a dedicated command is easier to maintain - you can redefine it if
necessary and there are no compatibility problems).  But this is just
my opinion (may be worth discussing separately though, as part of
GLISS).
I don't insist on moving the baseline; discussing this further seems
to be unproductive, so let's do it your way :)

thanks for your work and your patience!
Janek

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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 30 sept. 2012, at 14:16, Janek Warchoł  wrote:

> Hi,
> 
> interesting discussion, i learn a lot.
> 
> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup  wrote:
>> Basically, a grob says "I want to have this and that information for
>> making my positioning" and LilyPond says "You can't get it right now".
>> Then the grob says "ok, I'll do a tentative positioning", and LilyPond
>> will come back with more information later and ask again.
> 
> I have no idea whether there are any not-very-experienced developers
> (or users) following this thread, but if they are, i'm sure this is a
> very nice and helpful explanation for them :)
> 
> cheers,
> Janek

Just to clarify things for anyone following the thread: this is not currently 
how LilyPond works, but I'm assuming what you're proposing is a suggestion for 
a model.

It's an interesting idea for grobs to ping a sort of central hive ("LilyPond" 
in your text above) to know what information they can access and when.  This'd 
require a major change to the architecture - currently, grobs specify in their 
request whether they want tentative or permanent information via the use of 
functions like Grob::pure_relative_y_coordinate versus 
Grob::relative_coordinate.  I'm worried about having a sort of centralized 
brain that tells grobs what they can and can't know - sounds Kafka-esque.  I 
like the decentralized model where grobs, via their callbacks, self-police for 
what information they need from other grobs and when it's ok to get it.

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

Re: Project - Eliminating grob parents and outside-staff-priority

[Janek Warchoł]

Hi,

interesting discussion, i learn a lot.

On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup  wrote:
> Basically, a grob says "I want to have this and that information for
> making my positioning" and LilyPond says "You can't get it right now".
> Then the grob says "ok, I'll do a tentative positioning", and LilyPond
> will come back with more information later and ask again.

I have no idea whether there are any not-very-experienced developers
(or users) following this thread, but if they are, i'm sure this is a
very nice and helpful explanation for them :)

cheers,
Janek

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

Re: Recent LSR + Tarball checkin

[David Kastrup]

James  writes:

> Hello,
>
> I noticed that one of the changes in one of the snippets shows
>
> -  \consists "Mark_engraver"
> +  \consists Mark_engraver
>\consists "Staff_collecting_engraver"
>
> Is there a significance/preference using quotes or not?

http://lilypond.org/doc/v2.16/Documentation/contributor/lilypond-formatting>

All engravers should have double-quotes around them:

\consists "Spans_arpeggio_engraver"

LilyPond does not strictly require this, but it is a useful convention
to follow.

Whatever a "useful convention" may be, that's our current rule.

-- 
David Kastrup


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

Recent LSR + Tarball checkin

[James]

Hello,

I noticed that one of the changes in one of the snippets shows

-  \consists "Mark_engraver"
+  \consists Mark_engraver
   \consists "Staff_collecting_engraver"

Is there a significance/preference using quotes or not?

James

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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 30 sept. 2012, at 11:39, David Kastrup  wrote:

> David Kastrup  writes:
> 
>> "m...@mikesolomon.org"  writes:
>> 
>>> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>>> 
>>>On 29 sept. 2012, at 19:53, "Keith OHara" 
>>>wrote:
>>> 
>>>On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
>>> wrote:
>>> 
>>> 
>>>The way you're using "tentative" is almost exactly how
>>>pure properties are used in LilyPond.
>>> 
>>>Specifically, 'pure-height being the estimated vertical extent
>>>before line-breaking, while 'height is its extent after
>>>line-breaking.
>>> 
>>>If there are distinct properties to describe the position at
>>>different stages, then each property can be evaluated just
>>>once (as HanWen suggested, and as Mike agreed 100%).
>>> 
>>> More thinking. I'm not enthusiastic about stages - it is a top down
>>> approach that locks us into certain points of evaluation. What if we
>>> decided to add or get rid of a stage? Would we need to create things
>>> like unpure-pure-containers for various stages? What qualifies as a
>>> stage?
>> 
>> Dependencies, I should guess.  A "stage" is where we break circular
>> dependencies.
> 
> Basically, a grob says "I want to have this and that information for
> making my positioning" and LilyPond says "You can't get it right now".
> Then the grob says "ok, I'll do a tentative positioning", and LilyPond
> will come back with more information later and ask again.
> 
> Now the problem here is when we are getting oscillation or even just a
> converging process.  If there is convergence involved, we are better off
> calculation the _relation_ between the positionings.  In a linear
> optimization problem, those define the surface plane of a simplex (which
> has possible solutions inside, impossible solutions outside, and where
> we are looking for the furthest distance from 0 as the goal of
> optimization) as a constraint.  Intersecting with other
> surfaces/constraints gives us the total solution space, and travelling
> outside along its edges (which are the intersection of two planes) moves
> us to the optimal solution.
> 
> Doing this iteratively means jumping around on the inside of the
> simplex.  Each jump may be quite faster than determining the active
> boundaries of the simplex, but of course the simplex method focuses on
> _those_ pairings of parameters/positioning which are actually valid
> tradeoffs.  And since it is an efficient method, it does not get
> confused when the heuristics go wrong.

I'm not completely sure that I follow what you're saying (I don't know anything 
about the internals of the simplex method) but if you mean that recalculating 
tentative property values may result in a series of values that doesn't 
converge towards anything, then yes, you are right.

Most tentative properties will likely have convergent behavior, meaning that as 
more information becomes available, they'll get closer and closer to actual 
properties.  However, there is no systematic way to enforce this.  I've spent a 
lot of time thinking about making linear programming possible in LilyPond and 
have come to the conclusion that aspects of LilyPond's logic make it such that 
decisions are not linear.  The classic is:

--) We do outside staff positioning, at which point element A gets shifted up.
--) Element B, not being able to be placed between element A and the staff, 
gets placed above element A.
--) We redo outside staff positioning after cross-staff-grobs' vertical 
skylines are calculated.
--) Element A is now shifted higher up.
--) Element B is now able to be stashed between element A and the staff.

That is a leap in heights (we go from having element B in the skyline to not).  
So discussing convergence is really difficult - I think the best we can do are 
heuristics to decide when to settle on ok-enough values.

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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

David Kastrup  writes:

> "m...@mikesolomon.org"  writes:
>
>> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>>
>> On 29 sept. 2012, at 19:53, "Keith OHara" 
>> wrote:
>> 
>> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
>>  wrote:
>> 
>> 
>> The way you're using "tentative" is almost exactly how
>> pure properties are used in LilyPond.
>>
>> Specifically, 'pure-height being the estimated vertical extent
>> before line-breaking, while 'height is its extent after
>> line-breaking.
>> 
>> If there are distinct properties to describe the position at
>> different stages, then each property can be evaluated just
>> once (as HanWen suggested, and as Mike agreed 100%).
>>
>> More thinking. I'm not enthusiastic about stages - it is a top down
>> approach that locks us into certain points of evaluation. What if we
>> decided to add or get rid of a stage? Would we need to create things
>> like unpure-pure-containers for various stages? What qualifies as a
>> stage?
>
> Dependencies, I should guess.  A "stage" is where we break circular
> dependencies.

Basically, a grob says "I want to have this and that information for
making my positioning" and LilyPond says "You can't get it right now".
Then the grob says "ok, I'll do a tentative positioning", and LilyPond
will come back with more information later and ask again.

Now the problem here is when we are getting oscillation or even just a
converging process.  If there is convergence involved, we are better off
calculation the _relation_ between the positionings.  In a linear
optimization problem, those define the surface plane of a simplex (which
has possible solutions inside, impossible solutions outside, and where
we are looking for the furthest distance from 0 as the goal of
optimization) as a constraint.  Intersecting with other
surfaces/constraints gives us the total solution space, and travelling
outside along its edges (which are the intersection of two planes) moves
us to the optimal solution.

Doing this iteratively means jumping around on the inside of the
simplex.  Each jump may be quite faster than determining the active
boundaries of the simplex, but of course the simplex method focuses on
_those_ pairings of parameters/positioning which are actually valid
tradeoffs.  And since it is an efficient method, it does not get
confused when the heuristics go wrong.

-- 
David Kastrup


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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[dak]

On 2012/09/30 08:33:16, marc wrote:

Am 30.09.2012 10:01, schrieb d...@gnu.org:
>
> http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm
> File scm/bar-line.scm (right):
>
>

http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225


>
> scm/bar-line.scm:225: (define-public bar-glyph-alist '())
> This interface definition is asking for trouble.  It is an important
> feature of LilyPond that if you use standard commands, their effects

to

> not bleed over from one run to the next.  Information-carrying data
> structures, for that reason, should be initialized in a .ly file

loaded

> from init.ly.  Even then, the basic data structure should be one

that

> can be replaced by overwriting with a saved copy.  That means that
> hash-tables have to be either read/only, or start out as _empty_ in

a

> session (hash tables defined in the init.ly session get cleared at

the

> end of session IIRC).
I am not sure if I understand you correctly.



Do you propose that the initialisation of the alists should be moved
to ly/init.ly and that's it, more or less?


First, the define-public is asking for trouble.  You are exposing an
internal Scheme data structure to users and make it overwritable by the
user.  If the user follows this invitation, the effects will bleed over
from session to session.  Never do that.

Consider _everything_ written in a .scm file as readonly conceptually.
For an alist, you might want to define a _function_ returning the
initial list, and the accessors should not be modifying it destructively
(adding to the front of an alist does not change the original alist).

Then you assign this initial value to a session variable in something
included in init.ly, like
#(define bar-glyph-alist (initial-bar-glyph-alist))

Your functions working with bar-glyph-alist have to take the version of
bar-glyph-alist defined in the parser module.  That means that when you
call them from .ly files, you'll likely need to pass bar-glyph-alist
from the .ly file into your Scheme function.  Or get them via
ly:parser-lookup via the parser variable.

If you put a new bar line definition into a.ly, and when calling
lilypond a.ly b.ly
it is available in b.ly, then you have done something wrong.

http://codereview.appspot.com/6498052/

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 30.09.2012 10:01, schrieb d...@gnu.org:


http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm
File scm/bar-line.scm (right):

http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 


scm/bar-line.scm:225: (define-public bar-glyph-alist '())
This interface definition is asking for trouble.  It is an important
feature of LilyPond that if you use standard commands, their effects to
not bleed over from one run to the next.  Information-carrying data
structures, for that reason, should be initialized in a .ly file loaded
from init.ly.  Even then, the basic data structure should be one that
can be replaced by overwriting with a saved copy.  That means that
hash-tables have to be either read/only, or start out as _empty_ in a
session (hash tables defined in the init.ly session get cleared at the
end of session IIRC).

http://codereview.appspot.com/6498052/


Update: a 'git grep "(define-public .* '())" shows

scm/bar-line.scm:(define-public bar-glyph-alist '())
scm/bar-line.scm:(define-public span-bar-glyph-alist '())
scm/bar-line.scm:(define-public volta-bracket-allow-volta-hook-list '())
scm/define-context-properties.scm:(define-public 
all-translation-properties '())

scm/define-note-names.scm:(define-public pitchnames '())
scm/lily.scm:(define-public lilypond-declarations '())
scm/midi.scm:(define-public absolute-volume-alist '())
scm/midi.scm:(define-public instrument-equalizer-alist '())

Since the faulty regtest adds a function to the list provided by

(define-public bar-glyph-print-procedures `())

I assume that *this* declaration should be moved to ly/init.ly?

Regards,

Marc





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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[m...@mikesolomon.org]

On 30 sept. 2012, at 10:25, Marc Hohl  wrote:

> Am 30.09.2012 04:11, schrieb k-ohara5...@oco.net:
>> Now looking at the log files, I do get "undead" errors for our
>> regression test 'bar-line-define-bar-glyph.ly' but not from any other
>> files that I tried. (I don't know why the scripts from `make check` did
>> not flag it.)
> Keith, thanks for your work on this! It makes it much easier for me
> to see which file causes errors, especially in this case where these
> 'undead objects' messages seem to float around very randomly.
>> 
>> There are four messages, but the particular undead objects vary from run
>> to run.
>> 
> I can confirm that. When I compile the regtest above two times, the errors 
> disappear.
> When I compile another file and the regtest afterwards, I get different 
> messages.
> It looks as there are dynamics and/or articulations involved, which is 
> strange because
> neither the regtest nor the files I compiled in between have anything of that 
> kind.
> 
> I must admit that I am an absolute newbie with regard to C++ debugging.
> Can anyone help me here? I don't know where these undead objects come from –
> the function (add-bar-glyph-print-procedure ...) used in the regtest is used 
> in
> scm/bar-line.scm, too, and seems to cause no problems there.
> 
> Regards,
> 
> Marc
> 

These messages are annoying...they often have to do with marking objects for 
garbage collection (print_smob and mark_smob functions).  Given that you're not 
creating any new smobs in this patch, it is tough to see where things may be 
going wrong.  You can, however, do all sorts of stuff with the message itself 
to get more useful info.  It gets printed out in scm/lily.scm, so you can 
modify the printout to get more information about the object.

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 30.09.2012 10:01, schrieb d...@gnu.org:


http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm
File scm/bar-line.scm (right):

http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 


scm/bar-line.scm:225: (define-public bar-glyph-alist '())
This interface definition is asking for trouble.  It is an important
feature of LilyPond that if you use standard commands, their effects to
not bleed over from one run to the next.  Information-carrying data
structures, for that reason, should be initialized in a .ly file loaded
from init.ly.  Even then, the basic data structure should be one that
can be replaced by overwriting with a saved copy.  That means that
hash-tables have to be either read/only, or start out as _empty_ in a
session (hash tables defined in the init.ly session get cleared at the
end of session IIRC).

I am not sure if I understand you correctly.

Do you propose that the initialisation of the alists should be moved
to ly/init.ly and that's it, more or less?

Regards,

Marc


http://codereview.appspot.com/6498052/




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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 30.09.2012 04:11, schrieb k-ohara5...@oco.net:

Now looking at the log files, I do get "undead" errors for our
regression test 'bar-line-define-bar-glyph.ly' but not from any other
files that I tried. (I don't know why the scripts from `make check` did
not flag it.)

Keith, thanks for your work on this! It makes it much easier for me
to see which file causes errors, especially in this case where these
'undead objects' messages seem to float around very randomly.


There are four messages, but the particular undead objects vary from run
to run.

I can confirm that. When I compile the regtest above two times, the 
errors disappear.
When I compile another file and the regtest afterwards, I get different 
messages.
It looks as there are dynamics and/or articulations involved, which is 
strange because
neither the regtest nor the files I compiled in between have anything of 
that kind.


I must admit that I am an absolute newbie with regard to C++ debugging.
Can anyone help me here? I don't know where these undead objects come from –
the function (add-bar-glyph-print-procedure ...) used in the regtest is 
used in

scm/bar-line.scm, too, and seems to cause no problems there.

Regards,

Marc



http://codereview.appspot.com/6498052/




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

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

[David Kastrup]

Werner LEMBERG  writes:

>>> I prefer \single to \next.
>>>
>>> \justOne \onlyOne ?
>> 
>> It is, in a way, a complement to \once, so I would want to avoid
>> multiple-word approaches leading to CamelCase.
>
> Had someone already suggested \here?

Yes.

-- 
David Kastrup

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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

"m...@mikesolomon.org"  writes:

> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>
> On 29 sept. 2012, at 19:53, "Keith OHara" 
> wrote:
> 
> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
>  wrote:
> 
> 
> The way you're using "tentative" is almost exactly how
> pure properties are used in LilyPond.
>
> Specifically, 'pure-height being the estimated vertical extent
> before line-breaking, while 'height is its extent after
> line-breaking.
> 
> If there are distinct properties to describe the position at
> different stages, then each property can be evaluated just
> once (as HanWen suggested, and as Mike agreed 100%).
>
> More thinking. I'm not enthusiastic about stages - it is a top down
> approach that locks us into certain points of evaluation. What if we
> decided to add or get rid of a stage? Would we need to create things
> like unpure-pure-containers for various stages? What qualifies as a
> stage?

Dependencies, I should guess.  A "stage" is where we break circular
dependencies.

-- 
David Kastrup


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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:

> 
> On 29 sept. 2012, at 19:53, "Keith OHara"  wrote:
> 
>> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org 
>>  wrote:
>> 
>>> 
>>> The way you're using "tentative" is almost exactly how pure properties are 
>>> used in LilyPond.
>> 
>> Specifically, 'pure-height being the estimated vertical extent before 
>> line-breaking, while 'height is its extent after line-breaking.
>> 
>> If there are distinct properties to describe the position at different 
>> stages, then each property can be evaluated just once (as HanWen suggested, 
>> and as Mike agreed 100%).

More thinking.  I'm not enthusiastic about stages - it is a top down approach 
that locks us into certain points of evaluation.  What if we decided to add or 
get rid of a stage?  Would we need to create things like unpure-pure-containers 
for various stages?  What qualifies as a stage?  Could users make custom stages?

Furthermore, the idea of properties being pure in LilyPond is impossible to 
police.  The code almost guarantees that won't be pure, as once the dim_cache_ 
of a grob is filled, it gives that value instead of the result of a function 
call (see Grob::pure_relative_y_coordinate, specifically line 350 of grob.cc as 
of 9e605a1bb6644d89cf110f20cb6d46bb0339fca7).  I like Keith's idea of 
"tentative" and "permanent".  The model I'm thinking of is:

--) LilyPond evaluates all callbacks as permanent unless tentative is 
explicitly asked for.
--) Permanent properties are stashed in a cache that cannot be erased.
--) Tentative properties may (i.e. heights) or may not (i.e. color) be cached 
depending on how we choose to optimize LilyPond.  It is the responsibility of 
the coder, if she wants an uncached property, to wipe the cache.
--) Most importantly, all notions of pure callbacks disappear.  It is the job 
of functions to police themselves.  For example, a function Grob::has_full_x 
can be created to determine if a grob has an X position with respect to the 
system.  It'd check to see if the dim_cache_[X_AXIS].offset_ of a Paper_column 
pointing to a real location in memory.  The answer will be false if 
System::break_into_pieces has been called and true otherwise.  Then, we could 
do something like:

MAKE_SCHEME_CALLBACK_WITH_OPTARGS (Slur, height, 1, 2, "");
SCM
Slur::height (SCM smob, SCM begscm, SCM endscm)
{
  Grob *me = unsmob_grob (smob);
  if (me->has_full_x ())
return permanent_height (me);

  int beg = robust_scm2int (begscm, 0);
  int end = robust_scm2int (endscm, 0);
  return tentative_height (me, beg, end);
}

This'd allow to entirely get rid of all the pure callback lists as well as 
unpure-pure-containers.

--) Both permanent and tentative properties can result in calls to 
set_property, set_object, translate_axis, and suicide.  All setters should be 
used sparingly and internally to cache values (like we do for minimum 
translations, for example).  We can police this via warnings and errors.

Cheers,
MS

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[dak]

http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm
File scm/bar-line.scm (right):

http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225
scm/bar-line.scm:225: (define-public bar-glyph-alist '())
This interface definition is asking for trouble.  It is an important
feature of LilyPond that if you use standard commands, their effects to
not bleed over from one run to the next.  Information-carrying data
structures, for that reason, should be initialized in a .ly file loaded
from init.ly.  Even then, the basic data structure should be one that
can be replaced by overwriting with a saved copy.  That means that
hash-tables have to be either read/only, or start out as _empty_ in a
session (hash tables defined in the init.ly session get cleared at the
end of session IIRC).

http://codereview.appspot.com/6498052/

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