Re: Naming _another_ lacking puzzle piece
2012/10/13 David Kastrup d...@gnu.org:
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
In the Scheme layer, we have the distinction between
make-grob-property-set (corresponding to user command \override, pop+push)
make-grob-property-override (not available as user command, just push)
make-grob-property-revert (corresponding to user command \revert, just pop)
So we need something like
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\temporary\override Stem #'cross-staff = #cross-staff-connect
\temporary\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
and, as a corrollary, \temporary\whatever and \undo\whatever will be a
proper push/pop pair.
Now I find \temporary a fitting name. It is just a bit cumbersome to
type. \interim is hardly shorter, \adhoc seems a bit less descriptive.
Opinions? It might also be possible to do
\temporary { \override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag }
$notes
and have this apply matching push/pop pairs around $notes. It certainly
would at least cater for the most common need of a non-first-popping
push. Perhaps we don't need both (at the current point of time, we
don't have either, and the naming is inconsistent with
make-grob-property-*), but as the crossStaff example shows, we need at
least one of those options.
as a programmer I want a single push and wouldn't mind if pop+push
were two operations; I can't tell what a musician wants.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes:
So we need something like
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\temporary\override Stem #'cross-staff = #cross-staff-connect
\temporary\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
and, as a corrollary, \temporary\whatever and \undo\whatever will be a
proper push/pop pair.
I like the name \temporary. Is this of practical use outside of music
functions also?
The main point is to restore to a previous state after a temporary
override. This is of course also useful in music assigned to music
variables. In the context of a larger music piece, you can, of course,
just repeat any previous overrides that you want to see reestablished,
but this is not cutpaste friendly.
Maybe \push\override ... but this has the disadvantage that you never
actively see a \pop. Hm. Maybe we should rename \undo to \pop then?
Opinions? It might also be possible to do
\temporary { \override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag }
$notes
I like that too.
It is less versatile, though.
What about
\push { Stem.cross-staff = #cross-staff-connect
Flag.style = #'no-flag }
$notes
\pop { Stem.cross-staff
Flag.style }
[I'm using the `.' operator creatively; no idea whether this works,
and no need to discuss this in case it doesn't :-)]
It doesn't. And I don't even have an awfully twisted idea how to beat
LilyPond into supporting this in any meaningful manner.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
I like the name \temporary. Is this of practical use outside of music functions also? The main point is to restore to a previous state after a temporary override. This is of course also useful in music assigned to music variables. In the context of a larger music piece, you can, of course, just repeat any previous overrides that you want to see reestablished, but this is not cutpaste friendly. OK, for music functions and variable assignments. Then, I think, \temporary is indeed just fine. Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org writes: On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Technically impossible. At the time an \override is parsed, the valid set of contexts has not been established. OK. And the interpretation of the just parsed data (this is, checking the validity of contexts, properties, etc.) can't be delayed, right? Context validity can't be checked at that point of time. The system of available properties, however, is more or less considered static, so the basic consistency checks for overriding existing/non-existing properties are being done while parsing. However, I consider it a bad idea to use insider knowledge for parsing an override (meaning skip ahead until finding a word declared as a grob property and split the input backwards from there) since it means that understanding the input requires knowing _all_ prospective properties, whether it is a human, a LilyPond importer, a syntax highlighter, a cross referencing tool or LilyPond itself that is trying to interpret the input. But then most of those don't need to _understand_ the input really. And it turns out that _all_ decisions, whether we are talking tweak or override, can be made on the criterion is the first element in the list a grob name?, the decision that currently _can_ be made statically. Of course, the call interface of \override/\revert currently expects _two_ symbol chains. Conflating these chains (making \tweak and \override compatible again) is not really a backward compatibility problem for \override since its $#!? syntax demands conflating symbol lists before the '=' signs anyway. \revert, however, is a different matter. It currently needs exactly two symbol chains as argument. To accept only one, it would need to first accept one symbol chain, check it, and then _only_ in case that this symbol chain _ends_ in a grob name, parse another one. Very unpretty. But yes, it would likely get a load of users off our necks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
Hello Graham, Many thanks for the amazing amount of energy and work you've put in over the years. You certainly brought a very new style of leadership to the project after I have left. I hope we can count on you to stick around to give comments in the role of experienced emeritus. On Fri, Oct 12, 2012 at 9:01 AM, Graham Percival gra...@percival-music.ca wrote: I guess it's time to make it official: I'm stepping down as project manager. I'll stick around for a while to review patches on countdowns and participate in policy discussions, but don't be surprised if I'm gone for good in a few months. It's been quite a ride for the past 9 or 10 years (depending on which cvs commit is deemed to be my first contribution). I've gone from making trivial typo corrections, to organizing a directory of snippets, to reorganizing the whole documentation, to recruiting+training 20 doc editors over a single year, to building the binaries, and finally to trying to organize the team of developers. Over that time I've studied or worked at 5 different university on 3 continents. But nothing lasts forever; the time has come to leave. For most of 2012 I haven't been doing much with LilyPond, and in the past few weeks I've been doing even less -- but I find that I don't miss it. I've made some good friends while working on LilyPond, and Waltrop was great. I was really fired up about LilyPond when I left. But sadly the warm feelings from that meeting vanished rather quickly, and I was left feeling even more jaded than I had earlier in the year. Ultimately, I haven't used lilypond for my own music since 2004. I was hoping that I could get fired up about my old pieces if I could create a final version with a nice stable syntax, but that hasn't happened. After I'm finished my phd, I'll do the thing which every computer science student should do at least once in their life: I'll make my own language. I'm not comfortable with the level of abstractions that lilypond offers. Just like different programming languages make it easier (or harder) to write certain types of programs, a different sheet music language would make it easier to express the type of music that I write. I'll write a python script which transforms a text file into a .ly file. There's a number of things which can be done with text manipulation which will allow me to write music in a simpler fashion. I'll make the resulting script available under a Free license, of course, but the most important thing is that I'll be scratching an itch as the saying goes. Other than that, I'll be spending my time on other volunteer projects, either in the audio domain or scientific computing such as scipy or eigen. I think it would be good to challenge myself with some hardcore DSP or numerical software programming, as both areas tie directly to my probable research or job work. So what's next for lilypond? There's no immediate rush to change things. At some point somebody should clone the github lilypond repositories, but that's not a big deal. There's a mountain of miscellaneous tasks that I do and can't remember, so I guess that over the next few months I'll send emails to -devel whenever I discover something that needs to be done. I don't mind passing on advice or whatever I can remember to people taking on those tasks. The most immediate issue is building releases, but Phil's doing that. The most important thing is to have a new GNU co-maintainer. I feel a bit bad about dropping out only a few months after officially taking on that position, so I'll keep on doing it for the next few months. It would be great if somebody stepped forward for this -- start off by working on the known problems with our GNU compliance, and we'll see how things develop. The schedule for me leaving isn't at all fixed, but I imagine that I'd be ok with spending 1-2 hours a week for months or even years to come. The most important thing would be to keep it easy to participate meaningfully with only a small amount of time. The key to that are the patch countdowns and policy ideas coming as a formal proposal. Not to brag, but I really think that the 2011 summer GOP proposals were ideal. Topic were scheduled usually at least a week in advance, proposals were on the web, a draft existed for a week, then a firm proposal for another week. If there was significant disagreement, the discussion was extended and/or the policy was scrapped or rewritten. I'm not going to be reading -devel in detail, but if I knew that I could check my mail (or a webpage) once a week at a regular time to see a well-written proposal, I'd be happy to discuss it. I'm not the only senior developer with waning interest or time for lilypond; I think that such an arrangement could help keep all those people slightly involved in lilypond. However, I'm not going to be the person doing such organization any more. We've had a number of
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes: I like the name \temporary. Is this of practical use outside of music functions also? The main point is to restore to a previous state after a temporary override. This is of course also useful in music assigned to music variables. In the context of a larger music piece, you can, of course, just repeat any previous overrides that you want to see reestablished, but this is not cutpaste friendly. OK, for music functions and variable assignments. Then, I think, \temporary is indeed just fine. Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. The point is that it feels natural to use \push \some-override-sequence \pop \some-override-sequence in pairs, and both \push and \pop could complain if \some-override-sequence contained something unsuitable for complete reversal. And indeed, if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Each context has its own stack, so popping too much only makes a
difference if the stack actually was non-empty to start with.
Check out
\new Staff \with { autoBeaming = ##f }
{ \override Flag #'style = #'mensural c8 c \crossStaff c c c c c c }
After the crossStaff, the flag style has reverted to normal again rather
than mensural.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
[...] if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. But `push' means `to put something on the stack'. Having \omit Accidental however, does exactly the opposite, this is, it *removes* something (well, it pushes the `omit' property, so to say, but this can become very irritating if it gets more complicated). For this particular reason I prefer \undo for the example you've given above. I get the feeling that we have to completely reconsider how \set, \revert, and friends are named and used. Your clean-ups and reorganization of the syntax reveal more and more inconsistencies, and my head starts aching if I think of \once, \undo, and so on. Maybe it makes sense to map the corresponding Scheme functions anew to `simpler' lilypond commands which do less but in a more consistent manner. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes: [...] if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. But `push' means `to put something on the stack'. Having \omit Accidental however, does exactly the opposite, this is, it *removes* something Uh no, it doesn't. It pushed a ##f property to the stack of Accidental.stencil. (well, it pushes the `omit' property, so to say, but this can become very irritating if it gets more complicated). For this particular reason I prefer \undo for the example you've given above. I get the feeling that we have to completely reconsider how \set, \revert, and friends are named and used. Your clean-ups and reorganization of the syntax reveal more and more inconsistencies, and my head starts aching if I think of \once, \undo, and so on. Well, at least the \grob/\on/\tweakGrob things are tabled again. Changing \override Accidental color = #red to \override Accidental.color = #red and related changes make _those_ abominations redundant. Maybe it makes sense to map the corresponding Scheme functions anew to `simpler' lilypond commands which do less but in a more consistent manner. \once \push \pop \tweak \single _are_ rather minimal and do a single job each. \once changes overriding music into a push/pop pair, \push into push sequences, \pop into pop sequences, \tweak directly manipulates a grob, \single converts overriding music into a \tweak. The rest is tabled after discussion. \omit can be either tweak or override, depending on its last argument, same with \hide, same with \footnote. Just because this is a long discussion covering a lot of ground (and throwing stuff out again) does not mean that the _results_ are bad. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
- Original Message -
From: David Kastrup d...@gnu.org
To: Trevor Daniels t.dani...@treda.co.uk
Cc: lilypond-devel@gnu.org
Sent: Saturday, October 13, 2012 11:25 AM
Subject: Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Each context has its own stack, so popping too much only makes a
difference if the stack actually was non-empty to start with.
Check out
\new Staff \with { autoBeaming = ##f }
{ \override Flag #'style = #'mensural c8 c \crossStaff c c c c c c }
After the crossStaff, the flag style has reverted to normal again rather
than mensural.
--
David Kastrup
Surely this points to the pop operation in \override as being at fault? If
\override was simply push, rather than pop-push then the code above would
seem to work as intended.
The further implication of \override being pop-push would seem to be that if
you do something like (pseudo code):
{\override Flag style = mensural c8 c c c \override Flag color = red c c c
c}
Then you'd revert the mensural style when you change the color? That would
be wholly unexpected to me.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Phil Holmes m...@philholmes.net writes:
Surely this points to the pop operation in \override as being at
fault? If \override was simply push, rather than pop-push then the
code above would seem to work as intended.
Sure. The idea presumably was not to have stack buildup from things
like
\voiceOne c c \voiceTwo d d \voiceThree c c
The further implication of \override being pop-push would seem to be
that if you do something like (pseudo code):
{\override Flag style = mensural c8 c c c \override Flag color = red c
c c c}
Then you'd revert the mensural style when you change the color? That
would be wholly unexpected to me.
No, each property has its own stack.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 2012-10-13 07:30, Keith OHara wrote: Can anyone reading here (other than David who implemented it) give an example where he has used the grob-augmented \tweak syntax ? I had to use it to change the parentheses of \parenthesize, e.g. to use square brackets or to use only a left or right parenthesis (to indicate longer parenthesized parts, like multiple staccatos). See: http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00707.html Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: Surely this points to the pop operation in \override as being at fault? If \override was simply push, rather than pop-push then the code above would seem to work as intended. Sure. The idea presumably was not to have stack buildup from things like \voiceOne c c \voiceTwo d d \voiceThree c c It would appear that this behavior was implemented in lily/parser.yy with commit 39dd20959c8b3a143cfe41138a5c62749da54079 Author: Han-Wen Nienhuys han...@xs4all.nl Date: Mon Oct 17 00:04:45 2005 + * input/regression/override-nest.ly: new file. * python/convertrules.py (FatalConversionError.subber): conversion rule for #'callbacks * input/regression/override-nest.ly: new function. * lily/parser.yy (music_property_def): allow \override #'a #'b = #c too. * lily/context-property.cc (lookup_nested_property): new function. (evict_from_alist): new function. (general_pushpop_property): new function. (execute_general_pushpop_property): rewrite. Support nested properties too. There is no rationale for this change to be found in the patch, patch description or changelog entry. There is no rationale to be found on the developer list close to that date. But while searching there, finding URL:http://lists.gnu.org/archive/html/lilypond-devel/2005-10/msg4.html was amusing. Some things stay the same all over. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 09:32, Werner LEMBERG wrote: Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more into a programming language and away from being a description of music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: Buildup of unwanted data or no, it would be useful to be able to write something like \toLast Accidental #'color to restore the previous override But which is the previous override if you have several in a row? I see your point. I simply meant the immediately preceding override. So: \override Accidental color = #green \override Accidental color = #red \override Accidental color = #blue [...] \toLast Accidental color would restore red -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes: On 2012-10-13 09:32, Werner LEMBERG wrote: Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Uh, that is because they are a plastic visualization here? Lately, I have seen many suggestions that would turn lilypond more into a programming language and away from being a description of music. Reality check: LilyPond already _has_ stacks for properties. Nobody forces you to use any of the new commands if you don't care for stuff working in a better organized manner than flat variables would give you. One can call \push and \pop instead \temporary and \undo, but who are you going to do a favor with that? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Nalesnik david.nales...@gmail.com writes: On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: Buildup of unwanted data or no, it would be useful to be able to write something like \toLast Accidental #'color to restore the previous override But which is the previous override if you have several in a row? I see your point. I simply meant the immediately preceding override. So: \override Accidental color = #green \override Accidental color = #red \override Accidental color = #blue [...] \toLast Accidental color would restore red \override Accidental color = #green \override Accidental color = #red \push\override Accidental color = #blue [...] \revert Accidental color or, if you prefer \override Accidental color = #green \override Accidental color = #red \temporary\override Accidental color = #blue [...] \revert Accidental color \revert will go back to the value before the last \temporary/push override. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Nalesnik david.nales...@gmail.com writes: On Sat, Oct 13, 2012 at 8:29 AM, David Kastrup d...@gnu.org wrote: [...] \override Accidental color = #green \override Accidental color = #red \push\override Accidental color = #blue [...] \revert Accidental color or, if you prefer \override Accidental color = #green \override Accidental color = #red \temporary\override Accidental color = #blue [...] \revert Accidental color \revert will go back to the value before the last \temporary/push override. OK, I see, I'm definitely a fan of \temporary here. Well, if it makes people happier, we'll use \temporary/\undo instead of \push/\pop. Since one can pair \temporary not just with \undo but also with plain \revert, it might look less unbalanced. It is more typing, though. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On Sat, Oct 13, 2012 at 3:50 AM, David Kastrup d...@gnu.org wrote: Funny that you mention that. I was talking about the situation with my oldest friend (now a professional programmer for the past 11 years). He couldn't believe that I was spending so much energy arguing with people who argued against project requirements on the basis of the current implementation. There is a fine line between arguing on the basis of the current implementation, or arguing on the basis of the current _design_. Replacing arbitrary choices by other arbitrary choices is not progress. I think that Graham raised a very important subject here: it's important that we (developers as a whole) not only know what is being changed in Lily, but also *why* it's changing in this way and not another. In this case, my understanding is that David was arguing against some recent proposals because they would make it hard or impossible to achieve corehence of design. Unfortunately, from what i see Graham understood that David is arguing on the base of implementation (i.e. no, because we already wrote it the other way). This seems to me to be a serious misunderstanding. Unfortunately, David seems to be the only active developer that understands some parser subtleties - in other words, only he fully knows the whys. Explaining these whys to other devs again and again obviously can be frustrating for David, but as i wrote in another thread (http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00413.html) i don't see any better way :( best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 3:50 AM, David Kastrup d...@gnu.org wrote: Funny that you mention that. I was talking about the situation with my oldest friend (now a professional programmer for the past 11 years). He couldn't believe that I was spending so much energy arguing with people who argued against project requirements on the basis of the current implementation. There is a fine line between arguing on the basis of the current implementation, or arguing on the basis of the current _design_. Replacing arbitrary choices by other arbitrary choices is not progress. I think that Graham raised a very important subject here: it's important that we (developers as a whole) not only know what is being changed in Lily, but also *why* it's changing in this way and not another. That's supposedly what we are having discussions about and using the tracker for. In this case, my understanding is that David was arguing against some recent proposals because they would make it hard or impossible to achieve corehence of design. Unfortunately, from what i see Graham understood that David is arguing on the base of implementation (i.e. no, because we already wrote it the other way). This seems to me to be a serious misunderstanding. Well, those discussions are usually going along the lines let's replace x with y and/or do x in this manner -- that would not be how we do it elsewhere, how is that supposed to fit with everything else? -- I was not talking about everything else. You are changing the subject. It is not like it is _forbidden_ to think about changing everything else (I am doing some of that stuff right now with the symbolism patch), but there is nothing gained by _ignoring_ the problem. Now naturally I am not all too much interested in designing detailed approached for working around the shortcomings of proposals I consider going in the wrong direction in the first place. But since nobody else does it either, I am a single point of failure. Unfortunately, David seems to be the only active developer that understands some parser subtleties - in other words, only he fully knows the whys. Well, there is nothing magic about that as nobody else ever looks at the parser. It is like saying that somebody is the sole musician understanding the subtleties of playing a flute, simply because he is the only one who has ever bothered touching one. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 2:01 AM, David Kastrup d...@gnu.org wrote: There is a problem with that: in terms of stack operations, \override and \revert are not opposing pairs: \override is pop+push (so that multiple overrides in a row don't accrue cruft), \revert is pop. So the net effect of this sequence is pop, while it should be neutral. This looks strange indeed. I've skimmed this thread, but haven't found an answer to this question: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. We are going _nowhere_. We already are _there_. If people say they don't want to switch on the light, I am fine with that. It saves me work to ignore problems and tools in user documentation. But it does not make sense to keep the tools away from people working on LilyPond itself and say please don't provide simple, easy to use tools for fixing bugs which no one has ever noticed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: It would appear that this behavior was implemented in lily/parser.yy with commit 39dd20959c8b3a143cfe41138a5c62749da54079 Author: Han-Wen Nienhuys han...@xs4all.nl Date: Mon Oct 17 00:04:45 2005 + * input/regression/override-nest.ly: new file. * python/convertrules.py (FatalConversionError.subber): conversion rule for #'callbacks * input/regression/override-nest.ly: new function. * lily/parser.yy (music_property_def): allow \override #'a #'b = #c too. * lily/context-property.cc (lookup_nested_property): new function. (evict_from_alist): new function. (general_pushpop_property): new function. (execute_general_pushpop_property): rewrite. Support nested properties too. There is no rationale for this change to be found in the patch, patch description or changelog entry. There is no rationale to be found on the developer list close to that date. And I am learning the hard way why doing things in that stealthy manner is the smart way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. I recommend you do a poll to find out which commands the users should be spared from knowing about. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 12-10-13 10:23 AM, David Kastrup wrote: Trevor Daniels t.dani...@treda.co.uk writes: David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. I recommend you do a poll to find out which commands the users should be spared from knowing about. I wonder if David and Trevor are talking about the same commands here: David brought up the example of reading the source of \crossStaff while Trevor seems to be referring to \override, \tweak et al. FWIW, an uneducated bystander such as I agrees with David’s (implied) position: \crossStaff is a black box, and I only need to know what to put in for an expected output. Trevor raises (or at least, seems to me that he does) the diligent and wise caution that this whole set of paired functions will best be served by some well-organised carpentry in NR at least and probably at least passing mention in LM. 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: Naming _another_ lacking puzzle piece
David Kastrup dak at gnu.org writes: Trevor Daniels t.daniels at treda.co.uk writes: I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. So we should Track the bug in \crossStaff and \harmonicByFret Repair these 2 music functions by using the correct push/pop Scheme functions Improve the naming of the make-grob-property-* In general, make more of the Scheme layer documented and accessible *after* seeing a cases where it is useful. I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Keith OHara k-ohara5...@oco.net writes: David Kastrup dak at gnu.org writes: Trevor Daniels t.daniels at treda.co.uk writes: I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. So we should Track the bug in \crossStaff and \harmonicByFret Repair these 2 music functions by using the correct push/pop Scheme functions Improve the naming of the make-grob-property-* In general, make more of the Scheme layer documented and accessible *after* seeing a cases where it is useful. I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. It's basically the same use case as \once\override except that the temporary change lasts for more than a single timestep. You can always re-override to the preexisting value _iff_ you know it. For input intended to be reused, knowing it is not always possible. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Naming _another_ lacking puzzle piece
Keith OHara k-ohara5...@oco.net writes: I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. I love having the ability to write a music function that will set desired properties, and then put them back to their original state. For example, suppose I want to write a function that emphasizes the notes in the music argument by making all the noteheads red. But it should only apply to the music argument. Then, I want to set things back to what they were when the function exits. If I use revert, it will set the note heads back to black. But if I call the function from a voice that has green note heads, it won't set them back to green; it will always set them back to black. For a couple of years, I've wanted to have the ability to easily do a push/pop pair for use in writing music functions. I'm excited about this option, and fully support it. Thanks, David! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On Sat, Oct 13, 2012 at 1:22 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Hello Graham, Many thanks for the amazing amount of energy and work you've put in over the years. You certainly brought a very new style of leadership to the project after I have left. I hope we can count on you to stick around to give comments in the role of experienced emeritus. +1 Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On Sat, Oct 13, 2012 at 4:43 PM, David Kastrup d...@gnu.org wrote: Janek wrote: In this case, my understanding is that David was arguing against some recent proposals because they would make it hard or impossible to achieve corehence of design. Unfortunately, from what i see Graham understood that David is arguing on the base of implementation (i.e. no, because we already wrote it the other way). This seems to me to be a serious misunderstanding. Well, those discussions are usually going along the lines let's replace x with y and/or do x in this manner -- that would not be how we do it elsewhere, how is that supposed to fit with everything else? -- I was not talking about everything else. You are changing the subject. Hmm. I don't have such an impression, so we have a problem. Can we chat tomorrow? I can be online any time between 9 and 22 (your time). Now naturally I am not all too much interested in designing detailed approached for working around the shortcomings of proposals I consider going in the wrong direction in the first place. But since nobody else does it either, I am a single point of failure. Well, we need to find a solution to this problem. Unfortunately, David seems to be the only active developer that understands some parser subtleties - in other words, only he fully knows the whys. Well, there is nothing magic about that as nobody else ever looks at the parser. I understand that you're frustrated, but please note that i'm trying to read and review your syntax patches. Unfortunately i don't have time to study them until i understand how they work - I wish i could, but i don't have enough time now. I'm asking questions and i had learned some things about parser already. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? Good point. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. David, from your reaction i deduce that you felt attacked by me. I'm sorry as this wasn't my intent. I want to have this situation explained as soon as possible. Please, choose any voip software you like (i understand that you don't want a gmail account nor skype account because of their privacy policy) which can run on Ubuntu, and let's have a voice chat, ok? I can be online tomorrow 9-22 your time. worried Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 4:43 PM, David Kastrup d...@gnu.org wrote: Janek wrote: Unfortunately, David seems to be the only active developer that understands some parser subtleties - in other words, only he fully knows the whys. Well, there is nothing magic about that as nobody else ever looks at the parser. I understand that you're frustrated, but please note that i'm trying to read and review your syntax patches. I am not frustrated. I am just a central collection point for everybody's frustration, and blaming me for everything that is hard is just silly. Take a look at the recent proposal of \temporary. This basically goes like Here is a solution for a problem I encounter sometimes and that is also a problem in our codebase -- Oh no, not another solution. How are we supposed to keep track? Let's keep the problem instead. Nobody else noticed it so far anyhow, let's just ignore your demonstration of it. Now of course, this is how professional programmers would work. And to boot, if their company is large enough, they have a support department with people skilled and trained to be the punching ball taking on general customer frustration and passing the few bits of actually useful feedback on, assuming they even recognize it. When in doubt, they block both information and frustration and are still worth their pay in the combination of customer satisfaction and developer job satisfaction. Unfortunately i don't have time to study them until i understand how they work - I wish i could, but i don't have enough time now. There is not much point without at least reading the Bison manual regarding actual parser work. But usually I describe at least the consequences. That's not enough for a useful review, but it may be enough for how hard would it be to do xxx instead? questions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? Good point. In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. David, from your reaction i deduce that you felt attacked by me. No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. Nobody keeps them from staying ignorant and not taking control. It is their own business, and they are welcome to it, it remains a perfectly available and feasible option, but that does not mean that everybody else needs to be forced to do the same, and it is not like they suffer immensely when the tools they don't want to hear about get used to remove bugs they don't want to be bothered with. People have all the right to their personal choices, but that does not mean that each choice of them makes me equally enthusiastic. I'm sorry as this wasn't my intent. I want to have this situation explained as soon as possible. Janek, with all due respect: I just don't have the time and energy to talk two hours on the phone whenever something happens to annoy me. I get little enough done as it is, and being kept away from actually useful work by repeating what I already wrote makes things more rather than less frustrating. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
Am 13.10.2012 21:48, schrieb David Kastrup: Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 4:43 PM, David Kastrup d...@gnu.org wrote: Janek wrote: Unfortunately, David seems to be the only active developer that understands some parser subtleties - in other words, only he fully knows the whys. Well, there is nothing magic about that as nobody else ever looks at the parser. I understand that you're frustrated, but please note that i'm trying to read and review your syntax patches. I am not frustrated. I am just a central collection point for everybody's frustration, and blaming me for everything that is hard is just silly. Take a look at the recent proposal of \temporary. This basically goes like Here is a solution for a problem I encounter sometimes and that is also a problem in our codebase -- Oh no, not another solution. How are we supposed to keep track? Let's keep the problem instead. Nobody else noticed it so far anyhow, let's just ignore your demonstration of it. I think it is not meant as Oh no, not another solution – the problem I see here is that your work reveals the mess about lilypond's internal structures: the inconsistency about using the stack, the old context properties vs. grob properties, the \set/\override stuff (sorry for simplifying, you get the point). Combine that with a deep desire for something like change whatever property to value x change whatever property to value x for once revert whatever property to its predefined state revert whatever property to the value befor the latest change – I think that's how the Oh no ... message is meant. In either case, I think it is not meant as an accusation to your work. Let me try to formulate it another way: something like \push and \pop look like an ideal solution to write own lilypond functions that leave no trace after they finished their work (yet another simplification) so great! Let's have them! On the other side, a newbie on lilypond which just wants to color some note heads may be confused with the pop/push concept as he or she has never used a programming language – in this case, \temporary sounds a lot more friendly and familiar. So this should be considered – we don't want to scare users away, but provide a powerful tool for intermediate and advanced users (and, of course, proper redefinitions for already available functions like \crossStaff and the likes). Conclusion: I appreciate your latest work – it is just that I am not used to use \omit, \single, \undo and therefore bringing \temporary into line with the (yet unfamiliar) rest of the new stuff takes just some time. Perhaps I am not the only one who has these problems. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org wrote: No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, while Werner was complaining that the plethora of new context-manipulation functions have become confusing. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. Now, it's true that the comments may not have been entirely constructive as they didn't propose alternatives, but I also don't think anyone claimed that your proposal is worse than the status quo. For what it's worth, I think push, pop and clear (perhaps with more intuitive-to-non-programmer names) makes a nicer stack interface than push, pop-push and pop. I also think that undo should be rethought in light of this recent discussion. In particular, this discussion has made me realize that undo doesn't just reverse the effect of an override, since after \override Something #'color = #green \override Something #'color = #red \undo\override Something #'color = #red, then the color is not back to green as one might think. What if we gave the users a push, pop and clear interface and we made overrides use push and \oneVoice use clear? This solves the \voiceOne\voiceTwo\oneVoice problem and it lets \temporary be a shortcut for \override ... \undo \override. Since override is non-destructive, we could even get fancy and let \override Something #'color = #green \override Something #'color = #red \undo\override Something #'color = #green go back to the pre-green color. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com writes: On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org wrote: No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^ into a programming language and away from being a description of ^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. while Werner was complaining that the plethora of new context-manipulation functions have become confusing. That makes it sound like it would be a chaotic bunch. And what do we have? \override overwrites the last definition \revert throws it away/reestablishes the previous if not overwritten. Then we have modifiers for possibly multiple combined overrides, as those are for example available in large numbers in property-init.ly and we want to be able to use them for as many things as possible without having to retype them with modifications. \once \override non-destructively masks the definition for one time step, then restores \temporary \override non-destructively masks the last definition \undo \override drops like corresponding \reverts would A \tweak goes through a music object rather than through context properties, so we get \single \override (again an \override prefix) converts into one or more tweaks All those are separate tools, apply in the same manner to one or multiple overrides, to get a clear effect derived from the original \override-based command, and complementing each other in functionality. People shout I want fewer, but they are a set. It's like saying you want a smaller set of spanners, so you leave out every second one. But that means that you won't be able to do a random subset of required tasks because the spanners are a full set. You can't just randomly leave out some and expect to be able to still do every job. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. What's not orthogonal here? _Every_ modifier works on \overrides (granted, \undo will also work on \set but just because it does not make sense not to include this as well). \once allows a one-step temporary replacement, \temporary and \undo allow the start and stop of a temporary replacement to be separately specified. \single converts into a different grob modifier mechanism. No, the complaint was clear, from several parties: I get the feeling that we have to completely reconsider how \set, \revert, and friends are named and used. Your clean-ups and reorganization of the syntax reveal more and more inconsistencies, and my head starts aching if I think of \once, \undo, and so on. [...] In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting confusing, at least for me. I'd prefer to decrease the number of such functions, not increase them (without deleting functionality, of course). [...] Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. Now, it's true that the comments may not have been entirely constructive as they didn't propose alternatives, but I also don't think anyone claimed that your proposal is worse than the status quo. The last comment above states we're going too far in this direction now, calls the commands a confusing menagerie and states that nobody noticed the kind of bugs one can fix with that anyway. quite confused enough clearly strongly speaks against providing any more commands, preferring to stay with problems instead. For what it's worth, I think push, pop and clear (perhaps with more intuitive-to-non-programmer names) makes a nicer stack interface than push, pop-push and pop. What is clear supposed to be? I also think that undo
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 23:29, David Kastrup wrote: If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^ into a programming language and away from being a description of ^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. Sorry, maybe I wasn't clear enough in that last sentence. It would have been clearer if I wrote ... but using the names push and pop ... The thing about programming languages was intended to give a larger picture why I don't like pure programming concepts introduced to lilypond users, and using the names push and pop introduces stack concepts to the users, rather than providing a user-friendly (i.e. musician-friendly, not programmer-friendly) high-level API to the users. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Saturday, October 13, 2012 10:29 PM I wrote Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. The last comment above states we're going too far in this direction now, calls the commands a confusing menagerie and states that nobody noticed the kind of bugs one can fix with that anyway. quite confused enough clearly strongly speaks against providing any more commands, preferring to stay with problems instead. There is no doubt that explaining these concepts to musicians with no experience of programming will be difficult, and at the moment it seems no one is interested in writing documentation except me. I felt I was being forced into having to tackle this problem when I believed (and still believe) that most users have been and would continue to be quite unaware of the difficulties these extra commands are designed to solve. As a programmer myself I fully understand what you are doing; and I'm quite happy with that. So I shall have to find some way of documenting them so that non-programming users will not find learning LP even more difficult than they currently do. That was the basis of my concern. I'll sleep on it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
I completely agree that we need a function that changes a property in a non-destructive way. Me too, in case there was ever a doubt about this. If we were to completely re-design the lilypond language, I would suggest \override, \revert and \clear (as push, pop and clear stack), but they currently have a slightly different meaning. Yes! This is what I wanted to point out, apparently with bad wording which made David think into the wrong direction. The real problems we currently have are [...] Thanks for this! I fully agree with all your reasoning. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor On 13 October 2012 23:56, Trevor Daniels t.dani...@treda.co.uk wrote: David Kastrup wrote Saturday, October 13, 2012 10:29 PM I wrote Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. The last comment above states we're going too far in this direction now, calls the commands a confusing menagerie and states that nobody noticed the kind of bugs one can fix with that anyway. quite confused enough clearly strongly speaks against providing any more commands, preferring to stay with problems instead. There is no doubt that explaining these concepts to musicians with no experience of programming will be difficult, and at the moment it seems no one is interested in writing documentation except me. I felt I was being forced into having to tackle this problem when I believed (and still believe) that most users have been and would continue to be quite unaware of the difficulties these extra commands are designed to solve. As a programmer myself I fully understand what you are doing; and I'm quite happy with that. So I shall have to find some way of documenting them so that non-programming users will not find learning LP even more difficult than they currently do. That was the basis of my concern. I'll sleep on it. I have a patch coming that is trying to at least document \single \hide and \omit. i also have started to use \single to take the opportunity to better organize NR 5.3. I will post what I have tomorrow late afternoon - as 'needs work' as I have explained to David, that I have a bit of a grasp on these subtleties but am not a programmer to know how to articulate these important functions to non-programmers. Examples, at least _good_ examples of @lilyponds are what helps. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On 10/13/2012 11:44 PM, David Kastrup wrote: \once creates a one-time-step temporary change, \temporary an unterminated temporary change which can be terminated element-wise with \revert or, again using a converter, en bloc from the original overrides with \undo. Forgive me for coming into this without the background, but what's the difference between \temporary and the existing \override? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org wrote: No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^ into a programming language and away from being a description of ^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. while Werner was complaining that the plethora of new context-manipulation functions have become confusing. That makes it sound like it would be a chaotic bunch. And what do we have? \override overwrites the last definition \revert throws it away/reestablishes the previous if not overwritten. In other words, we have a pop-push and a pop. In the context of Reinhold's email, you were suggesting (although perhaps not seriously) adding a push. Now, I'm happy to have push and pop, but I think pop-push is a bad interface for a stack. The reason that we have gotten away with it for so long is because our interface ensures that the stack is almost always empty anyway (since the only way to push is with \once, and that always pops immediately). Once we start talking about composability, the deficiencies of pop-push become clear. So my proposed set of orthogonal commands would be push and pop (again, with more intuitive names). I also suggest adding clear for convenience. Everything else would be syntactic sugar on push and pop. Then we have modifiers for possibly multiple combined overrides, as those are for example available in large numbers in property-init.ly and we want to be able to use them for as many things as possible without having to retype them with modifications. \once \override non-destructively masks the definition for one time step, then restores \temporary \override non-destructively masks the last definition \undo \override drops like corresponding \reverts would A \tweak goes through a music object rather than through context properties, so we get \single \override (again an \override prefix) converts into one or more tweaks All those are separate tools, apply in the same manner to one or multiple overrides, to get a clear effect derived from the original \override-based command, and complementing each other in functionality. People shout I want fewer, but they are a set. It's like saying you want a smaller set of spanners, so you leave out every second one. But that means that you won't be able to do a random subset of required tasks because the spanners are a full set. You can't just randomly leave out some and expect to be able to still do every job. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. What's not orthogonal here? _Every_ modifier works on \overrides (granted, \undo will also work on \set but just because it does not make sense not to include this as well). \once allows a one-step temporary replacement, \temporary and \undo allow the start and stop of a temporary replacement to be separately specified. What isn't orthogonal is that you can't express, say, \temporary in terms of \override and \revert. If we switch to using push and pop instead of pop-push and pop, then push and pop become the orthogonal underpinnings of everything and \once, \temporary, and \undo become syntactic sugar. The sugar is then easy to explain to users because it can be expressed in terms of commands that they already know. \single converts into a different grob modifier mechanism. No, the complaint was clear, from several parties: I get the feeling that we have to completely reconsider how \set, \revert, and friends are named and used. Your clean-ups and reorganization of the syntax reveal more and more inconsistencies, and my head starts aching if I think of \once, \undo, and so on. [...] In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting
Re: stepping down as project manager
On 2012-10-14 01:07, Joseph Rushton Wakeling wrote:
On 10/13/2012 11:44 PM, David Kastrup wrote:
\once creates a one-time-step temporary change, \temporary an
unterminated temporary change which can be terminated element-wise with
\revert or, again using a converter, en bloc from the original overrides
with \undo.
Forgive me for coming into this without the background, but what's the
difference between \temporary and the existing \override?
\temporary\override would work the way you probably expect \override to
work now:
It sets the grob property to a new value and keeps the old value stored
so that after \revert the property takes the old value it had before the
\temporary\override.
The actual problem is that \override currently CLEARS (i.e. reverts) the
current value before setting the new one, so that the old value is not
stored anywhere any more, and a \revert thus reverts to the default value.
As an example, let's look at the following code. What color would you
expect the final b to have? red? (because the \revert clears the
previous override to blue, right?)
\version 2.16.0
\relative c' {
c4
\override NoteHead #'color = #red
f
\override NoteHead #'color = #blue
g
\revert NoteHead #'color
b
}
In reality, the \revert does not revert the override, but completely
clear the value to the black default. Currently, there is no way to
temporarily change a property and then change it back to its previous
value (except for \once\override, which only works for one timestep).
In fact, \override and \revert are currently misnamed, they work more
like \set and \unset.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still alive
2012/10/9 m...@mikesolomon.org m...@mikesolomon.org: Hey list, Just a quick ping to let you know that I'm not dead - I've been swamped w/ work recently and just got engaged so I'm planning out a wedding (w00t!). I'll be back in the swing of things around mid-November if not sooner. Mike, congratulations! I wish you both all happiness. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
